NL2021582B1 - Werkwijze voor het identificeren van modules gekoppeld aan een bussysteem, en een gebouwautomatiseringssysteem - Google Patents

Abstract

Een werkwijze (2500) voor het identificeren van een veelheid van modules (D1, D2, D3) die aan een bedrade communicatie—bus gekoppeld zijn en die elk een uniek adres (UA1, UA2, UA3) bevatten, door een GegevensVerzamellVlodule (GV) die eveneens aan de communicatie—bus gekoppeld is, waarbij de 10 werkwijze de volgende stappen omvat: a) het versturen (2501) van een identificatieverzoek door de GV naar de modules (D1-D3) voor het opvragen van hun unieke adressen; b) het ontvangen (2502) van het identificatieverzoek door de modules (D1-D3); c) het succesvol versturen (2510) van een identificatiebericht door de modules (D1—D3) als reactie op het identificatieverzoek, waarbij ieder identificatiebericht het uniek adres van de betreffende module bevat. Een werkwijze voor het 15 configureren en ondervragen van de modules. Een bussysteem, en een gebouwautomatiseringssysteem waarin deze werkwijze wordt gebruikt. Een set van minstens drie interface—modules (GV, D1, D2) die samen deze werkwijze uitvoeren.

Description

WERKWIJZE VOOR HET IDENTIFICEREN VAN MODULES GEKOPPELD AAN EEN BUSSYSTEEM, EN EEN GEBOUWAUTOMATISERINGSSYSTEEM

Domein van de uitvinding

De onderhavige uitvinding heeft in het algemeen betrekking op een digitaal bussysteem zoals gebruikt kan worden in een gebouwautomatiseringssysteem. De onderhavige uitvinding heeft meer specifiek betrekking op een werkwijze voor het identificeren van modules gekoppeld aan het bussysteem, en op een werkwijze voor het opvragen van gegevens van één of meerdere modules van het bussysteem, en op een werkwijze voor het toekennen van een busadres aan één of meerdere modules van het bussysteem. De onderhavige uitvinding heeft tevens betrekking op zulk gebouwautomatiseringssysteem, en een set van interface-modules.

Achtergrond van de uitvinding

Gebouwautomatiseringssystemen zijn gekend in de stand der techniek, en kunnen bv. één of meerdere van de volgende deelsystemen omvatten: een verlichtingssysteem, een zonnewerings-systeem, een branddetectiesysteem, een airconditioningsysteem, een verwarmingssysteem, een HVAC-systeem, een parkeergeleidingssysteem, een toegangscontrolesysteem, enz. De deelsystemen kunnen als afzonderlijke systemen geïmplementeerd worden, of als een geïntegreerd systeem.

Verlichtingssystemen met een digitale bus waarbij verlichtingselementen en/of schakelaars en/of dimmers en dergelijke functioneel met elkaar samenwerken, zijn gekend in de stand der techniek. Een zeer bekend bussysteem dat gebruikt wordt voor verlichtingstoepassingen is "DALI". DALI is een acroniem en staat voor "Digital Addressable Lighting Interface" (Engels) of "Digital Addresseerbare Verlichtingsinterface". Het is een internationale norm bedoeld voor de uitwisselbaarheid van dimbare ballasten van verschillende fabrikanten. De DALI-interface is beschreven in standaard IEC 60929 onder bijlage E. Geïnteresseerde lezers niet vertrouwd met DALI, kunnen een eenvoudig begrijpbare introductie vinden in de "DAU manual", uitgegeven door "DALI AG (Digital Addressable Lighting Interface Activity Group) van ZVEI, Division Luminaires", daterend van 2001. DALI heeft als voornaamste voordeel ten opzichte van klassieke verlichtingssystemen met vaste bedrading dat het toeiaat de functionaliteit van het verlichtingssysteem te herconfigureren zonder de bedrading te wijzigen, bv. door drukschakelaars op een andere manier te associëren met bepaalde verlichtingselementen.

Gebouwautomatiseringssystemen met een digitale bus, die een dergelijk verlichtingssysteem kunnen omvatten, en/of andere elementen zoals de aansturing van zonneweringen, airconditioning, enzovoorts, zijn eveneens gekend in de stand der techniek. Een zeer gekend bussysteem voor gebouwbeheerstoepassingen is KNX. In feite is KNX een systeem dat communicatie over verschillende media specifieert, namelijk (a) KNX TP (afkorting voor "KNX Twisted Pair") waarbij gecommuniceerd wordt over een vierdraadsbus, (b) KNX PL (afkorting voor "KNX Powerline"), waarbij een signaal gesuperponeerd wordt op de 230V voedingskabels in een gebouw, (c) KNX RF (afkorting voor "KNX Radio Frequency") waarbij draadloos wordt gecommuniceerd, en (d) KNX IP (afkorting voor KNX Internet Protocol) waarbij gecommuniceerd wordt over Ethernet. De KNX TP-variant is het meest relevant voor de onderhavige uitvinding. De lezer niet vertrouwd met KNX kan bv. het document [1] "The KNX standard - the basics" (20 blzn), lezen als korte introductie, dat op het moment van opstellen van het onderhavig document kan gedownload worden via de volgende URL: http://www.knx.org/media/docs/Flyers/KNX-Basics/KNX-Basics_en.pdf.

In elk bussysteem zijn er bepaalde "regels" nodig, beter gekend als het "busprotocol", waaraan aiie deelnemers van de bus zich dienen te houden. Het protocol van een bussysteem beschrijft aspecten als spanningsniveaus, timing, frame-structuur, prioriteiten, manieren om botsingen te detecteren (Engels: "collision detection”) en/of botsingen te voorkomen (Engels: "collision avoidance"), enz.

Alvorens een verlichtingssysteem volgens DALI of een gebouwautomatiseringssysteem volgens KNX in werking kan gesteld worden, dienen uiteraard eerst de nodige componenten (zoals bv. drukknoppen, lampen, sensoren, actuatoren) geïnstalleerd te worden in het gebouw, en via interfacemodules (al dan niet ingebouwd in de component) elektrisch gekoppeld te worden aan de communicatie-bus. Verder dienen deze interface-modules geconfigureerd te worden om op een specifieke manier met elkaar samen te werken in een specifiek gebouw, door een handeling die bekend staat onder de naam "commissioning". Dit omvat onder meer het toekennen van lokale adressen aan de verschillende modules, welke adressen tijdens de normale werking van het systeem worden gebruikt om boodschappen te versturen van bv. een lichtknop naar een bijhorende lamp. Zo wordt er bij DALI aan iedere component een 6-bits "busadres" toegekend, en wordt er bij KNX een 16-bits "groepadres " toegekend, (meer informatie hierover kan bv. gevonden worden op URL: "https://nl.wikipedia.org/wiki/KNX")

In de praktijk wordt het busadres of groepsadres toegekend aan de modules tijdens de installatie van de betreffende module in het gebouw, bv. door een fysieke verbinding te maken tussen de betreffende module en een draagbare computer via een RS232 connectie, of zoals beschreven in het hoger genoemde KNX-document [1] (op blz 18 kolom 4 tot blz 19 kolom 1, paragraaf "Commissioning") door het fysiek indrukken van een daartoe speciaal voorziene drukknop op de module en het versturen van een "adres" over de bus, waarbij de module waarvan de genoemde speciale drukknop werd ingedrukt, het adres beschouwt als het zijne. Uiteraard zal het systeem bij ingebruikname alleen correct functioneren wanneer aan elke module van het bussysteem het juiste adres is toegekend volgens het plan (en aannemend dat het plan geen fouten bevat).

Vaak treden er echter menselijke fouten op bij een dergelijke toekenning, bijvoorbeeld omdat men vergeten is om een busadres of groepsadres toe te kennen aan bepaalde modules, of omdat een verkeerd busadres of groepsadres werd toegekend (bv. een adres dat niet voorzien was op het plan), of omdat per vergissing eenzelfde adres werd toegekend aan twee verschillende modules, enz. Zulke fouten kunnen achteraf wel gecorrigeerd worden, maar het kost vaak veel tijd en moeite, om ze op te sporen, en te corrigeren. Dit is een gekend probleem (zoals bevestigd door [1] biz 19 kolom 1 lijn 3). US7606955(Bl) beschrijft een bedraad bussysteem met één enkele meester en 1 tot 7 slaven verbonden met een zgn. "open collector"-architectuur, waarbij de bus passief naar een hoog niveau wordt getrokken via een weerstand, en elk van de deelnemers de bus actief laag kan trekken. Het protocol maakt een onderscheid tussen onder andere "databits", een ”reset"-signaal, en een "attention-request” signaal van één van de slaven. In dit systeem moet elke businterface dus vier soorten signalen detecteren, en overeenkomstig reageren. US8035529(B2) beschrijft een gedistribueerd ballastsysteem met een protocol dat een uitbreiding is op het DALI-protocol, en dat achterwaarts compatibel is met DALI, waarbij 256 modules kunnen aangesproken worden (in plaats van slechts 64 bij DALI), en waarbij functionaliteit kan toegevoegd worden vanwege de langere instructies (3 bytes in plaats van slechts 2 bytes bij DALI). Het document beschrijft niet in detail hoe de "initialisatie'1 (Engels: commissioning) precies gebeurt, noch hoe eventuele fouten bij deze commissioning kunnen opgespoord of gecorrigeerd worden.

Samenvatting van de uitvinding

Het is een doei van de onderhavige uitvinding om een bussysteem te verschaffen voor een gebouwautomatiseringssysteem, en om een werkwijze te verschaffen om te communiceren in dit bussysteem, en een gebouwautomatiseringssysteem met zulk bussysteem, en een set van interfacemodules voor gebruik in zulk bussysteem of zulk gebouwautomatiseringssysteem.

Meer specifiek is het een doel van de onderhavige uitvinding om een dergelijk bussysteem en werkwijze te verschaffen, die het mogelijk maken om fouten (bv. installatiefouten of meer specifiek fouten bij de commissioning) sneller of eenvoudiger op te sporen en/of te corrigeren.

Het is een doel van de onderhavige uitvinding om een werkwijze te verschaffen voor het identificeren van een veelheid van deelnemers van een bussysteem, en om een bussysteem te verschaffen met een busprotocol dat zulke werkwijze ondersteunt.

Het is een doel van bepaalde uitvoeringsvormen van de onderhavige uitvinding om een werkwijze te verschaffen voor het opvragen van gegevens van één of meerdere deelnemers van het bussysteem, en om een bussysteem te verschaffen met een busprotocol dat een dergeiijke werkwijze ondersteunt.

Het is een doel van bepaalde uitvoeringsvormen van de onderhavige uitvinding om een werkwijze te verschaffen voor het configureren en/of het herconfigureren van één of meerdere deelnemers van het bussysteem, en om een bussysteem te verschaffen met een busprotocol dat een dergelijke werkwijze ondersteunt.

Volgens een eerste aspect, verschaft de onderhavige uitvinding een werkwijze voor het identificeren van een veelheid van modules die aan een bedrade communicatie-bus gekoppeld zijn en die elk een uniek adres bevatten, door een GegevensVerzamelModule die eveneens aan de communicatie-bus gekoppeld is, waarbij de werkwijze de volgende stappen omvat: a) het versturen over de communicatie-bus van een identificatieverzoek door de GegevensVerzamelModule naar de veelheid van modules, voor het opvragen van hun unieke adressen; b) het ontvangen van het identificatieverzoek door elk van de veelheid van modules; c) het succesvol versturen van een identificatiebericht door elk van de veelheid van modules als reactie op het ontvangen identificatieverzoek, waarbij iedere identificatiebericht het uniek adres van de betreffende module bevat; waarbij stap c) voor ieder van de veelheid van modules de volgende stappen omvat: i) het wachten tot de bus vrij is gedurende minstens een vooraf bepaalde tijd; ii) het trachten te verzenden van het identificatiebericht van de betreffende module, waarbij het trachten te verzenden van het identificatiebericht het achtereenvolgens trachten te verzenden van iedere bit van het identificatiebericht omvat, en waarbij het trachten te verzenden van iedere bit het aansturen en monitoren van de bus omvat, en het bepalen of een botsing op de bus opgetreden is; iii) en indien een botsing opgetreden is, het stoppen met het verzenden van de betreffende bit en van alle volgende bits van het identificatiebericht, en het herhalen van stappen i) tot iii) totdat de identificatiebericht verzonden is zonder botsing; en indien geen botsing opgetreden is, besluiten dat het identificatiebericht succesvol verzonden is, en niet meer deelnemen aan het trachten te verzenden van het identificatiebericht.

Met "succesvol versturen" wordt bedoeld dat iedere module zal blijven proberen zijn identificatiebericht te versturen, totdat dit uiteindeiijk gelukt is. Dit zal gegarandeerd lukken, omdat ieder bericht uniek is, en omdat er geen berichten verloren gaan.

Kort samengevat laat deze werkwijze toe de unieke adressen van alle modules die aan de communicatiebus gekoppeld zijn, in-situ op te vragen. Eens deze unieke adressen gekend zijn, kunnen deze gebruikt worden om bepaalde modules individueel te benaderen, bijvoorbeeld om informatie op te vragen, of om informatie naar de module te zenden, bv. gebruikmakend van absolute addressering.

Ze maakt mogelijk dat fouten sneller gedetecteerd en zelfs gecorrigeerd kunnen worden, met name fouten gerelateerd aan het niet of verkeerdelijk toekennen van één of meerdere busadressen aan de modules tijdens de installatie ("commisioning"), bv. door de modules één voor één individueel te benaderen gebruik makend van commando's met absolute addressering op basis van de aldus verkregen unieke adressen.

De opvraging zelf kan bovendien relatief snel uitgevoerd worden, zelfs terwijl het verlichttingssysteem of gebouwautomatiseringssysteem kan blijven werken.

Het is een voordeel van deze werkwijze dat alle unieke adressen van alle modules die effectief met de bus verbonden zijn (behalve dat van de GV) automatisch kunnen opgevraagd worden zonder tussenkomst van menselijke handelingen, waardoor de kans op menselijke fouten wordt uitgesloten.

Door de unieke adressen (die reeds bij de productie van de modules ingebouwd worden in de modules) op te vragen, worden alle modules ondubbelzinnig "ontdekt", zelfs indien er geen, of een verkeerd busadres werd toegekend aan de module tijdens de installatie (commissioning).

Het is een groot voordeel dat de werkwijze voorziet dat er slechts één enkel identificatieverzoek zal verstuurd worden, waarop ieder van de andere modules zal antwoorden, desnoods in meerdere pogingen, totdat het uiteindelijk gelukt is. Omdat de GV slechts één bericht zal versturen over de bus, wordt veel tijd gewonnen.

Het is een groot voordeel dat de werkwijze zo voorzien is dat er in principe, (tenzij er "normale boodschappen" tussendoor komen) bij iedere iteratie precies één identificatiebericht ongeschonden over de bus zal verstuurd worden.

Dankzij de botsingsdetectie op bitniveau en het desgevallend stoppen met zenden, en het automatisch opnieuw proberen wanneer de bus voldoende lang vrij is, gaan er geen berichten verloren, en wordt er dus geen tijd verloren op de bus vanwege verminkte (Engels: corrupt) gegevens en heruitzendingen. Dit betekent een belangrijke tijdswinst.

Het is een groot voordeel van deze werkwijze dat ze zelfs uitgevoerd kan worden in een operationeel actief bussysteem, wat bv. wil zeggen dat het gebouw-automatiseringssysteem of deelsysteem (bv. verlichtingssysteem, zonneweringssysteem, branddetectiesysteem, enz.) waar dit bussysteem deel van uitmaakt, zal blijven werken terwijl deze adresopvraging plaats vindt. Bovendien kan dit gebeuren met een niet of nauwelijks merkbare vertraging van "normale commando's" zoals het aanschakelen van lichtelementen, het uitlezen van branddetectoren, enz.

Het is een groot voordeel dat deze werkwijze zeer snel kan uitgevoerd worden (bv. grootte-orde 1,85 seconden voor een bitperiode van 150 ps en een bus met 100 deelnemers, en een uniek adres van 32 bits, aannemend dat de bus niet operationeel belast is). Zulke korte tijd is ongezien, en het voordeel ervan mag niet onderschat worden.

In een uitvoeringsvorm wordt stap ii) van het trachten te verzenden gestart van zodra de vooraf bepaalde tijd "WJD" verstreken is.

In deze uitvoeringsvorm wachten alle modules in principe even lang, (op toleranties van de locale klok na). Er wordt dus geen gebruik gemaakt van willekeurige ("random") wachttijden of dergelijke voor het trachten vermijden van botsingen, integendeel. In deze uitvoeringsvorm zullen alle modules dus nagenoeg tegelijkertijd beginnen met zenden, met andere woorden, de kans op botsingen wordt in deze uitvoeringsvorm als het ware gemaximaliseerd in plaats van geminimaliseerd.

In een uitvoeringsvorm, is de communicatie-bus een digitale communicatie-bus; en wordt een eerste signaalvorm geassocieerd met een logische "l"-bit, en een tweede signaalvorm verschillend van de eerste signaalvorm geassocieerd met een logische "O"-bit; en zijn de GegevensVerzamelModule en de veelheid van modules gekoppeld aan de communicatie-bus in een wired-AND of een wired-OR configuratie.

Bij voorkeur wordt de bus hoog wordt getrokken door een (relatief grote) optrekweerstand of door een (relatief zwakke) stroombron, en kan de bus laag getrokken worden door middel van een (relatief sterke) transistor geconfigureerd als "open collector" of als "open drain" (wat betekent dat hij fungeert als AAN-UIT schakelaar, met een zeer lage impedantie wanneer de schakelaar gesloten is, en met een zeer hoge impedantie wanneer de schakelaar open is). In zulke configuratie wint een laag spanningsniveau het van een hoog spanningsniveau. Afhankelijk van de signaalvorm die geassocieerd wordt met een logische "1" of een logische "0", wint een logische "1" het van een logische "0", in welk geval de bus een ”wired-OR” wordt genoemd (zoals in het voorbeeld van FIG. 3). In het omgekeerde geval, waarbij een logische "0" het wint van een logische "1", wordt de busconfiguratie een "wired-AND" configuratie genoemd.

Volgens een tweede aspect, verschaft de onderhavige uitvinding een werkwijze voor het toekennen van minstens één busadres of minstens twee busadressen aan een te configureren module van een veelheid van modules die aan een bedrade communicatie-bus gekoppeld zijn, en die elk een uniek adres hebben, waarbij de werkwijze de volgende stappen omvat: a) het bepalen van de unieke adressen van de veelheid van modules die aan de bus gekoppeld zijn door het identificeren van de modules volgens het eerste aspect; b) het versturen van een configuratiebericht door de GegevensVerzamelModule, waarbij het configuratiebericht het uniek adres van de te configureren module bevat om de module te addresseren, alsook minstens één toe te kennen busadres; c) het ontvangen van het configuratiebericht door de veelheid van modules die aan de bus gekoppeld zijn, en het extraheren van het adres vervat in het configuratiebericht, en het vergelijken van het geëxtraheerde adres met het interne unieke adres van de betreffende module, en indien het geëxtraheerde adres en het interne unieke adres gelijk zijn, verder gaan met stap d), en indien het geëxtraheerde adres en het interne unieke adres verschillend zijn, stap d) overslaan; d) het extraheren van het minstens één busadres uit het configuratiebericht, en het opslaan van het minstens één busadres in een geheugen van de module voor latere communicatie met andere modules op basis van relatieve adressering.

Stap b) en c) betekenen eigenlijk dat een "absolute adressering wordt gebruikt, op basis van het uniek adres van de module, die opgevraagd werd in stap a).

Deze werkwijze maakt het mogelijk om vanop afstand één of meerdere busadres(sen) toe te kennen aan een bepaalde module, zonder dat fysieke toegang tot de module nodig is. Deze werkwijze maakt het ook mogelijk om vanop afstand het busadres te wijzigen.

Volgens een derde aspect, verschaft de onderhavige uitvinding een werkwijze voor het opvragen van gegevens van minstens één te ondervragen module gekozen uit een veelheid van modules die aan een communicatie-bus gekoppeld zijn, en die elk een uniek adres bevatten, omvattende: a) het bepalen van de unieke adressen van elk van de veelheid van modules die aan de bus gekoppeld zijn, door het identificeren van de modules volgens het eerste aspect; b) het versturen van een leesbericht door de GegevensVerzamelModule, waarbij het leesbericht het unieke adres van de te ondervragen module bevat om de module te addresseren, alsook één of meer indicatoren over welke informatie opgevraagd wordt; c) het ontvangen van het leesbericht door de veelheid van modules die aan de bus gekoppeld zijn, en het extraheren van het adres vervat in het leesbericht, en het vergelijken van het geëxtraheerde adres met het interne unieke adres van de betreffende module, en indien het geëxtraheerde adres en het interne unieke adres gelijk zijn, verder gaan met stap d), en indien het geëxtraheerde adres en het interne unieke adres verschillend zijn, stap d) overslaan; d) het versturen van een informatiebericht door de te ondervragen module naar de GegevensVerzamelModule, waarbij het informatiebericht gegevens bevat overeenkomstig de één of meer indicatoren; e) het ontvangen van het informatiebericht door de GegevensVerzamelModule.

Deze werkwijze biedt het voordeel dat informatie kan opgehaald worden over een welbepaalde module, door deze module te adresseren met zijn uniek adres. Door het ophalen van bijkomende informatie, bv. het type van de module, of het/de daarin opgeslagen busadres(sen), is het mogelijk fouten te detecteren gerelateerd aan de toekenning van het/de busadres(sen).

Er wordt opgemerkt dat het informatiebericht bestemd is voor de GV, en dat dit dus als een "commando" kan geïmplementeerd worden, waarbij geen adres hoeft toegevoegd te worden van de bestemmeling.

In een verder uitvoeringsvorm van een werkwijze volgens het eerste, tweede of derde aspect, omvat het uniek adres van minstens één van de veelheid van modules (Dl, D2, D3) minstens 18 bits omvat, of minstens 20 bits, of minstens 24 bits, of minstens 32 bits, of minstens 40 bits, of minstens 48 bits.

Volgens bepaalde standaarden hebben de eenheden op de bus maximaal 6 adres-bits, en kunnen er dus maximaal 64 eenheden op de bus worden onderscheiden. In dergelijke systemen is het perfect mogeiijk om de herkenning van de aanwezige eenheden te doen door alle mogelijke adressen te proberen en na te gaan of er reactie komt. Deze zgn. "brute force" methode is echter niet geschikt wanneer het aantal adresbits erg groot wordt. Immers, voor elke extra bit verdubbelt de tijd die nodig is om alle adressen te proberen.

In een verder uitvoeringsvorm van een werkwijze volgens het eerste, tweede of derde aspect, worden alle berichten over de bus, met inbegrip van het identificatieverzoek en de identificatieberichten, verstuurd door het versturen van één of meerdere frames met een vaste lengte, waarbij ieder frame één startbit, zestien databits, en één stopbit bevat.

Het is een voordeel dat alle communicatie over de bus eenzelfde frame-structuur gebruikt. Hierdoor kan de implementatie vereenvoudigd worden.

In een verdere uitvoeringsvorm, is een minimale wachttijd WT2F tussen twee opeenvolgende frames van eenzelfde bericht kleiner dan een minimale wachttijd WT2B tussen frames van twee verschillende berichten.

De minimale wachttijden maken deel uit van het protocol volgens hetwelke gecommuniceerd wordt over de bus. Dit betekent dat wanneer een bepaalde module een bericht aan het verzenden is dat meerdere frames bevat, dat de trein van frames niet onderbroken zal worden door een ander bericht. Hierdoor kan de implementatie vereenvoudigd worden.

In een verdere uitvoeringsvorm, is de minimale wachttijd WJD voorafgaand aan een identicatiebericht, groter is dan de minimale wachttijd WT2B voorafgaand aan een bericht dat geen identificatiebericht is.

Dit is een manier om ervoor te zorgen dat "normale berichten" of "operationele berichten", zoals de communicatie tussen componenten van een verlichtingssysteem of van een ander deelsysteem van een gebouwautomatiseringssysteem onderling voorrang krijgen op identificatieberichten van de modules naar de GegevensVerzamelModule.

Volgens een vierde aspect verschaft de onderhavige uitvinding een bussysteem voor een gebouwautomatiseringssysteem, omvattende: - een bedrade communicatiebus; - een veelheid van modules die elk een uniek adres hebben en die gekoppeld zijn aan de communicatiebus; een GegevensVerzamelModule die gekoppeld is aan de communicatiebus; waarbij elk van de veelheid van modules en de GegevensVerzamelModule voorzien zijn om samen een werkwijze volgens het eerste, tweede of derde aspect.

De bedrade communicatiebus omvat bij voorkeur minstens één of minstens twee elektrische geleiders.

Volgens een vijfde aspect verschaft de onderhavige uitvinding een gebouwautomatiseringssysteem dat een bussysteem volgens het vierde aspect omvat, en dat verder één of meer van de volgende kenmerken omvat: i) en waarbij het gebouwautomatiseringssysteem minstens een verlichtingssysteem omvat, waarbij minstens één van de modules aangepast is voor het aansturen van een verlichtingselement of een dimmer, en/of minstens één van de modules aangepast is voor het uitlezen van minstens één bewegingsdetector of aanwezigheidsdetector of lichtsensor of schakelaar; ii) en waarbij het gebouwautomatiseringssysteem minstens een zonneweringssysteem omvat, waarbij minstens één van de modules aangepast is voor het aansturen van minstens één motor van een zonnewering, en/of minstens één van de modules aangepast is voor het uitlezen van minstens één lichtsensor of schakelaar of windsensor; iii) en waarbij het gebouwautomatiseringssysteem minstens een branddetectiesysteem omvat, waarbij minstens één van de modules aangepast is voor het uitlezen van minstens één branddetector of rookdetector of temperatuursensor; iv) en waarbij het gebouwautomatiseringssysteem minstens een airconditioningsysteem omvat, waarbij minstens één van de modules aangepast is voor het aansturen van een airconditioningsmodule, en/of minstens één van de modules aangepast is voor het uitlezen van een temperatuursensor of vochtigheidssensor; v) en waarbij het gebouwautomatiseringssysteem minstens een verwarmingssysteem omvat, waarbij minstens één van de modules aangepast is voor aansturen van minstens één ventiel of een pomp of een verwarmingselement, en/of minstens één van de modules aangepast is voor het uitlezen van een temperatuursensor; vi) en waarbij het gebouwautomatiseringssysteem minstens een HVAC-systeem omvat, waarbij minstens één van de modules aangepast is voor het aansturen van een airconditioningsmodule of een verwarmingselement of een ventiel of een pomp, en/of minstens één van de modules aangepast is voor het uitlezen van een temperatuursensor of een vochtigheidssensor; vii) en waarbij het gebouwautomatiseringssysteem minstens een parkeergeleidingssysteem omvat, waarbij minstens één van de modules aangepast is voor het aansturen van minstens één verlichtingselement, en/of minstens één van de modules aangepast is voor het uitlezen van minstens één bewegingsdetector of aanwezigheidsdetector of schakelaar; viii) en waarbij het gebouwautomatiseringssysteem minstens een toegangscontrolesysteem omvat, waarbij minstens één van de modules aangepast is voor het aansturen van een deur of een toegang, en/of minstens één van de modules aangepast is voor het uitlezen van minstens één bewegingsdetector of aanwezigheidsdetector of schakelaar of identificatiemodule.

In een uitvoeringsvorm omvat het gebouwautomatiseringssysteem verder minstens één van de hoger genoemde actuatoren en/of minstens één van de hoger genoemde sensoren.

In een uitvoeringsvorm, omvat de bedrade bus minstens twee elektrische geleiders die galvanisch van elkaar gescheiden zijn, maar functioneel met elkaar gekoppeld zijn door middel van minstens één signaalversterker met een optische koppeling, welke signaalversterker eveneens deel uitmaakt van het bussysteem.

Volgens een zesde aspect verschaft de onderhavige uitvinding tevens een set van minstens drie interface-modules voor gebruik in een bussysteem volgens het vierde aspect, of voor gebruik in een gebouwautomatiseringssysteem volgens het vijfde aspect, waarbij één interface-module voorzien is voor het uitvoeren van stap a) van een werkwijze volgens het eerste, tweede of derde aspect, en minstens twee andere interface-modules voorzien zijn voor het uitvoeren van de stappen b) en c) van de werkwijze volgens het eerste, tweede of derde aspect.

In een uitvoeringsvorm omvat minstens één der interface-modules verder een IR-zendontvanger, en is de controller van de betreffende interface-module verder voorzien van een IR-protocol software voor het zenden en ontvangen van boodschappen via de IR-zendontvanger.

In een uitvoeringsvorm omvat minstens één der interface-modules verder een RF-zendontvanger, en is de controller van de betreffende interface-module verder voorzien van een RF-protocol software voor het zenden en ontvangen van boodschappen via de RF-zendontvanger.

In een uitvoeringsvorm omvat minstens één der interface-modules verder een glasvezel-zendontvanger, en is de controller van de betreffende interface-module verder voorzien van een glasvezel-protocol software voor het zenden en ontvangen van boodschappen via de glasvezel-zendontvanger.

In een uitvoeringsvorm omvat minstens één der interface-modules verder een tweede bus-interface, en is de controller van de betreffende interface-module voorzien om zowel te communiceren over de eerste bus-interface via een eerste protocol volgens het eerste, tweede of derde aspect, alsook via een tweede protocol dat verschillend is van het eerste protocol over de tweede bus-interface.

In een uitvoeringsvorm omvat minstens één der interface-modules verder minstens één ingebouwde actuator voor het aansturen van een component van een gebouwautomatisering, en/of minstens één ingebouwde sensor of detector voor het uitlezen van een component van een gebouwautomatisering.

Specifieke en voorkeursdragende aspecten van de uitvinding zijn opgenomen in de aangehechte onafhankelijke en afhankelijke conclusies. Kenmerken van de afhankelijke conclusies kunnen worden gecombineerd met kenmerken van de onafhankelijke conclusies en met kenmerken van andere afhankelijke conclusies zoals aangewezen en niet enkel zoals uitdrukkelijk in de conclusies naar voor gebracht.

Voor het samenvatten van de uitvinding en de bereikte voordelen ten opzichte van de stand van de techniek werden bepaalde doelstellingen en voordelen van de uitvinding hierboven beschreven. Het is uiteraard te begrijpen dat niet noodzakelijk al deze doelstellingen of voordelen kunnen bereikt worden door elke specifieke uitvoeringsvorm van de uitvinding. Dus, bijvoorbeeld, vakmensen zullen onderkennen dat de uitvinding kan worden belichaamd of uitgevoerd op een wijze die één voordeel of een groep van voordelen heeft zoals hierin aangereikt, zonder daarbij noodzakelijk andere doelstellingen of voordelen te bereiken die hierin kunnen aangereikt of gesuggereerd zijn.

Deze en andere aspecten van de uitvinding zuilen duidelijk zijn aan de hand van en verhelderd worden met verwijzing naar de hiernavolgende beschreven uitvoeringsvorm(en).

Korte beschrijving van de figuren

De uitvinding zal nu verder worden beschreven, bij wijze van voorbeeld, met verwijzing naar de bijhorende figuren waarin: FIG. 1 is een replica van FIG. 1 van US8035529(B2), en toont een voorbeeld van een ballastsysteem uit de stand der techniek, gebaseerd op het DALI-protocol. FIG. 2 is een replica van FIG. 2A van US7606955(Bl), en toont een voorbeeld van een bussysteem met een meester-slaaf architectuur, waarbij de bus passief hoog getrokken wordt door een optrekweerstand, en de deelnemers van de bus een bus-interface hebben met een zgn. "opencollector" of een zgn. "open drain" om de bus desgewenst actief laag te trekken. FIG. 3 is een voorbeeldmatig blokdiagram van een deelnemer van de bus volgens de onderhavige uitvinding, hierin verder ook "interface-module" of kortweg "module" genoemd. FIG. 4 is een schematische voorstelling van een voorbeeldmatig bussysteem en gebouwautomatiseringssysteem volgens de onderhavige uitvinding. FIG. 5 is een schematische voorstelling van een tweede voorbeeldmatig bussysteem en gebouwautomatiseringssysteem volgens de onderhavige uitvinding waarbij de digitale bus een backbone en twee fysieke geleiders omvat. FIG. 6 is een schematische voorstelling van een derde voorbeeldmatig bussysteem en gebouwautomatiseringssysteem volgens de onderhavige uitvinding, als variant van het bussysteem van FIG. 5, dat verder signaalversterkers omvat. FIG. 7 tot FIG. 9 tonen enkele voorbeelden van bedrade bussen gekend in de stand der techniek. Bussystemen volgens de onderhavige uitvinding kunnen gebruikt worden met elk van de bedrade bussen getoond in FIG. 7 tot FIG. 9, maar hoeven dat niet. FIG. 7 toont een voorbeeld van een tweedraadsbus met twee geleiders, waarbij één geleider fungeert als referentie (grond), en de andere geleider gebruikt wordt voor data-overdracht, maar niet om andere modules te voeden. FIG. 8 toont een voorbeeld van een driedraadsbus met drie geleiders, waarbij één geleider fungeert als referentie (grond), een tweede geleider gebruikt wordt voor data-overdracht, en een derde geleider gebruikt wordt voor het voeden van minstens één deelnemer van de bus. FIG. 9 toont een voorbeeld van een tweedraadsbus met twee geleiders, waarbij één geleider fungeert als referentie (grond), en de andere geleider gebruikt wordt voor zowel data-overdracht als voor het voeden van minstens één deelnemer van de bus. FIG. 10 toont twee voorbeeldmatige golfvormen die kunnen gebruikt worden door uitvoeringsvormen van de onderhavige uitvinding voor het doorsturen van een logische bit "1" en een logische bit "0", of omgekeerd. FIG. 11 toont twee andere voorbeeldmatige golfvormen die gebruikt kunnen worden door uitvoeringsvormen van de onderhavige uitvinding voor het doorsturen van een logische bit "1" en een logische bit "0", gekend onder de naam "Manchester"-coding. FIG. 12 tot FIG. 19 illustreren aan de hand van een vereenvoudigd voorbeeld een werkwijze voor het identificeren van een veelheid van te identificeren modules van een bussysteem volgens de onderhavige uitvinding, waarbij één module werd toegevoegd aan het bussysteem om te fungeren als "GegevensVerzamelModule".

In FIG. 12 stuurt de "GegevensVerzamelModule" een speciaal identificatieverzoek naar de te identificeren modules, met het verzoek hun uniek adres te verzenden over de bus.

In FIG. 13 beginnen alle deelnemers van de bus (behalve de GegevensVerzamelModule) nagenoeg tegelijkertijd met het versturen van een identificatiebericht dat hun uniek adres bevat, terwijl de GegevensVerzamelModule het identificatiebericht dat over de bus wordt verstuurd ontvangt. FIG. 14 toont de golfvormen die de drie deelnemers trachten te versturen via hun bus-interface, waarin enkel deelnemer Dl slaagt, althans in de eerste poging.

In FIG. 15 beginnen de overblijvende deelnemers D2 en D3 tegelijk een identificatiebericht te versturen dat hun uniek adres bevat, terwijl de "GegevensVerzamelModule" het identificatiebericht dat over de bus wordt verstuurd ontvangt. FIG. 16 toont de golfvormen die de twee overblijvende deelnemers D2 en D3 trachten te versturen via hun bus-interface, als tweede poging om hun uniek adres te versturen, waarin enkel deelnemer D2 slaagt.

In FIG. 17 begint de enig overblijvende deelnemer D3 een bericht te versturen dat zijn uniek adres bevat, terwijl de GegevensVerzamelModule het identificatiebericht dat over de bus wordt verstuurd ontvangt. FIG. 18 toont de golfvorm van het identificatiebericht dat deelnemer D3 verstuurt via zijn bus-interface, als derde poging om zijn uniek adres te versturen, waarin hij ditmaal slaagt. FIG. 19 toont de golfvorm die wordt waargenomen op de bus. FIG. 20 tot FIG. 23 tonen een voorbeeldmatige berichtenstructuur met één of meerdere frames, die gebruikt kan worden door een bussysteem en door werkwijzen volgens de onderhavige uitvinding. FIG. 20 toont een voorbeeldmatig tijdsdiagram van een boodschap bestaande uit één enkel frame. FIG. 21 toont een voorbeeldmatige bitsstructuur van dit ene frame. FIG. 22 toont een voorbeeldmatig tijdsdiagram van een boodschap bestaande uit twee frames die na elkaar worden verstuurd, gescheiden door een wachttijd. FIG. 23 is een schematische weergave van een boodschap bestaande uit drie frames. FIG. 24 toont een werkwijze voor het identificeren van een veelheid van deelnemers van het bussysteem, volgens een uitvoeringsvorm van de onderhavige uitvinding. FIG. 25 toont de werkwijze van FIG. 24, inclusief stappen die uitgevoerd worden door de veelheid van te identificeren modules van de bus.

De figuren zijn enkel schematisch en niet limiterend. In de figuren kunnen de afmetingen van sommige onderdelen overdreven en niet op schaal zijn voorgesteld voor illustratieve doeleinden. De afmetingen en de relatieve afmetingen komen soms niet overeen met de actuele praktische uitvoering van de uitvinding.

Referentienummers in de conclusies mogen niet worden geïnterpreteerd om de beschermingsomvang te beperken.

In de verschillende figuren verwijzen dezelfde referentienummers naar dezelfde of gelijkaardige elementen.

Gedetailleerde beschrijving van uitvoeringsvormen van de uitvinding

De huidige uitvinding zal beschreven worden met betrekking tot bijzondere uitvoeringsvormen en met verwijzing naar bepaalde tekeningen, echter de uitvinding wordt daartoe niet beperkt, maar wordt enkel beperkt door de conclusies.

Het dient opgemerkt te worden dat de term "omvat", zoals gebruikt in de conclusies, niet als beperkt tot de erna beschreven middelen dient geïnterpreteerd te worden; deze term sluit geen andere elementen of stappen uit. Hij is zodoende te interpreteren als het specificeren van de aanwezigheid van de vermelde kenmerken, waarden, stappen of componenten waarnaar verwezen wordt, maar sluit de aanwezigheid of toevoeging van één of meerdere andere kenmerken, waarden, stappen of componenten, of groepen daarvan niet uit. Dus, de omvang van de uitdrukking "een inrichting omvattende middelen A en B" dient niet beperkt te worden tot inrichtingen die slechts uit componenten A en B bestaan. Het betekent dat met betrekking tot de huidige uitvinding, A en B de enige relevante componenten van de inrichting zijn.

Verwijzing doorheen deze specificatie naar "één uitvoeringsvorm" of "een uitvoeringsvorm" betekent dat een specifiek kenmerk, structuur of karakteristiek beschreven in verband met de uitvoeringsvorm is opgenomen in tenminste één uitvoeringsvorm van de onderhavige uitvinding. Dus, voorkomen van de uitdrukkingen "in één uitvoeringsvorm" of "in een uitvoeringsvorm" op diverse plaatsen doorheen deze specificatie hoeven niet noodzakelijk allemaal naar dezelfde uitvoeringsvorm te refereren, maar kunnen dit wel doen. Voorts, de specifieke kenmerken, structuren of karakteristieken kunnen gecombineerd worden op eender welke geschikte manier, zoals duidelijk zou zijn voor een gemiddelde vakman op basis van deze bekendmaking, in één of meerdere uitvoeringsvormen.

Vergelijkbaar dient het geapprecieerd te worden dat in de beschrijving van voorbeeldmatige uitvoeringsvormen van de uitvinding verscheidene kenmerken van de uitvinding soms samen gegroepeerd worden in één enkele uitvoeringsvorm, figuur of beschrijving daarvan met als doel het stroomlijnen van de openbaarmaking en het helpen in het begrijpen van één of meerdere van de verscheidene inventieve aspecten. Deze methode van openbaarmaking dient hoe dan ook niet geïnterpreteerd te worden als een weerspiegeling van een intentie dat de uitvinding meer kenmerken vereist dan expliciet vernoemd in iedere conclusie. De conclusies volgend op de gedetailleerde beschrijving zijn hierbij expliciet opgenomen in deze gedetailleerde beschrijving, met iedere op zichzelf staande conclusie als een afzonderlijke uitvoeringsvorm van deze uitvinding.

Voorts, terwijl sommige hierin beschreven uitvoeringsvormen sommige, maar niet andere, in andere uitvoeringsvormen inbegrepen kenmerken bevatten, zijn combinaties van kenmerken van verschillende uitvoeringsvormen bedoeld als gelegen binnen de reikwijdte van de uitvinding, en vormen deze verschillende uitvoeringsvormen, zoals zou begrepen worden door de vakman. Bijvoorbeeld, in de volgende conclusies kunnen eender welke van de beschreven uitvoeringsvormen gebruikt worden in eender welke combinatie.

In de hier voorziene beschrijving worden talrijke specifieke details naar voren gebracht. Het is hoe dan ook te begrijpen dat uitvoeringsvormen van de uitvinding kunnen uitgevoerd worden zonder deze specifieke details. In andere gevallen zijn welgekende werkwijzen, structuren en technieken niet in detail getoond om deze beschrijving helder te houden.

In de onderhavige uitvinding wordt de term "boodschap" en "bericht" als synoniem gebruikt.

In de onderhavige uitvinding worden de termen "grond" en "massa" als synoniem gebruikt.

In de onderhavige uitvinding verwijst de term "communicatie-bus" of kortweg "bus" naar een bedrade bus met minstens twee elektrische geleiders, of een bedrade bus met één elektrische geleider en een massa.

In de onderhavige uitvinding worden de termen "deelnemer van de bus" of kortweg "deelnemer", en "interface-module" of kortweg "module" als synoniem gebruikt. Ze verwijzen naar een inrichting die minstens een controle-eenheid (bv. een programmeerbare processor) en een bus-interface voor het zenden en ontvangen van berichten over de communicatie-bus omvat. In de context van de onderhavige uitvinding kan de module een uitlezingsmodule zijn (voor het uitlezen van één of meerdere sensoren), of een aansturingsmodule (voor het aansturen van één of meerdere actuatoren), of een combinatie van zowel een uitlezingsmodule als een aansturingsmodule.

In de onderhavige uitvinding wordt met "identificatieverzoek" een specifiek of bedrijfseigen (Engels: "proprietary") bericht bedoeld dat door één van de modules, namelijk de module die fungeert als "GegevensVerzamelModule" (verder afgekort als GV), wordt verstuurd in de vorm van een broadcast-commando naar de overige modules van de bus (d.i. de veelheid van de modules die geïdentificeerd dienen te worden) met het verzoek (of het commando) om hun "uniek adres" kenbaar te maken op de bus.

In de onderhavige uitvinding verwijst de term "absoluut uniek adres" of "uniek adres" naar een adres of serienummer dat doorgaans tijdens de productie van de interface-module aan de betreffende interface-module wordt toegekend, en dat daarna niet meer gewijzigd wordt, en waarvan de waarde uniek is (d.w.z. slechts één keer voorkomt) ongeacht de bus waarin deze module gebruikt wordt. Dit uniek adres bevat minstens 17 bits, of minstens 20 bits, of minstens 24 bits, of minstens 28 bits, of minstens 32 bits, of minstens 40 bits, of minstens 48 bits.

In de onderhavige uitvinding verwijst de term "bus-adres" naar een adres dat minder bits heeft dan het absoluut uniek adres, en dat toegekend wordt aan een "interface-module" na de productie, (bv. tijdens een zogenaamde "commissioning") om efficiënter te communiceren over de communicatie-bus. Dit is het adres dat meestal gebruikt wordt tijdens de normale werking van het bussysteem, en waarmee componenten met elkaar communiceren.

In uitvoeringsvormen van de onderhavige uitvinding kan een "interface-module" méér dan één bus-adres hebben, bv. één bus-adres voor iedere ingang en iedere uitgang van de "interfacemodule" (zoals verder zal toegelicht worden bij FIG. 3).

In de onderhavige uitvinding wordt de term "identificatiebericht" gebruikt om te verwijzen naar een specifiek en bedrijfseigen bericht dat verstuurd wordt door elk van de overige modules (d.i. de modules die geïdentificeerd dienen te worden) als antwoord op het "identificatieverzoek".

In dit document wordt de term "component" gebruikt om te verwijzen naar inrichtingen zoals bijvoorbeeld drukknoppen, deursloten, aanwezigheidssensoren, bewegingssensoren, windsensoren, temperatuur-sensoren, lampen, relais, airconditioning, branddetectoren, rookdetectoren, HVAC, sirenes, verwarmingselementen, sproeisystemen, enz, die deel uitmaken van een verlichttingssysteem of een gebouwautomatiseringssysteem.

In dit document worden "component" en "interface-module" als aparte inrichtingen beschouwd, maar het is uiteraard ook mogelijk om beide inrichtingen te groeperen in één inrichting, die hierin dan eveneens ais "interface-module" of "module" wordt aangeduid.

In dit document verwijst "normale werking" of "normale berichten" of "operationele berichten” naar berichten die over de bus verstuurd worden tijdens de normale werking van het systeem, bv. tussen een sensor en een bijhorende actuator. Het "identificatieverzoek" verstuurd door de GV en de "identificatieberichten" verstuurd door de andere modules worden niet als "operationele berichten” gezien.

De onderhavige uitvinding heeft betrekking op een digitaal bussysteem zoals bv. gebruikt kan worden in een verlichtingssysteem of een gebouwautomatiseringssysteem, en op werkwijzen om te communiceren over een dergelijk bussysteem, waaronder een werkwijze voor het identificeren van een veelheid van deelnemers van een bussysteem, bv. alle "interface-modules" gekoppeld aan het bussysteem behalve de GegevensVerzamelModule.

Zoals reeds aangegeven in de achtergrondsectie, bestaan er diverse bussystemen voor gebouwen, zoals een bussysteem volgens het DALI-protocol voor het aansturen van een verlichtingssysteem, of een bussysteem volgens het KNX protocol voor het besturen van een gebouwautomatiseringssysteem met "componenten" die doorgaans worden ingedeeld in twee categorieën: sensoren (of detectoren) en actuatoren, maar andere componenten zijn ook mogelijk, zoals bv. klokken of logische bouwstenen. De groep van sensoren bevat onder meer: schakelaars, drukknoppen, aanwezigheidsmelders, temperatuurvoelers, enz. De groep van actuatoren bevat onder meer relais, zonneweringen, air-conditionings, enz. Deze "componenten" worden aan de digitale bus gekoppeld via een "interface-module" (hierin verder kortweg "module" genoemd) die fungeert als deelnemer van de bus.

De architectuur van de interface-modules (zie bv. FIG. 3) kan verschillen afhankelijk van het type component dat ermee verbonden wordt (bv. het aansturen van een lamp of een relais vereist andere functionaliteit dan het uitlezen van een drukknop), maar allen hebben ze een bus-interface 303 en een controller 301 (bv. een programmeerbare processor), en zijn ze voorzien voor het versturen en ontvangen van boodschappen volgens een bepaald protocol. Het protocol dat hierin beschreven zal worden is een bedrijfseigen protocol (Engels: "proprietary protocol"), dat deel uitmaakt van het bussysteem volgens de onderhavige uitvinding.

Ontwerpers van een verlichtingssysteem of van een gebouwautomatiseringssysteem dienen dus "componenten" en "interface-modules" te kiezen, en installateurs dienen deze in het gebouw te plaatsen en aan te sluiten volgens een vooraf bepaald plan. Zoals beschreven in de achtergrondsectie, wordt door de installateur aan iedere module minstens één bus-adres toegekend, verwijzend naar het adres dat toegekend wordt aan iedere module tijdens de "commissioning", en waarmee de componenten onderling met elkaar communiceren tijdens de normale werking van het verlichttingssysteem of het gebouwautomatiseringssysteem, en dat minder bits heeft dan het absoluut uniek adres.

In bepaalde uitvoeringsvormen van de onderhavige uitvinding worden aan sommige interfacemodules minstens twee, of minstens drie, of minstens vier busadressen toegekend, namelijk één busadres voor iedere ingang en uitgang. In het specifiek voorbeeld van FIG. 3 zouden bv. vijf busadressen worden toegekend aan de getoonde module 300, namelijk twee voor de ingangen IN1, IN2, en drie voorde uitgangen UIT1, UIT2, UIT3.

In de praktijk is gebleken dat het installeren en monteren en aansluiten van de componenten (wat acties vereist als bv. boren, schroeven, kabel trekken, vals plafond losmaken, isolatie verwijderen, enz.) een heel andere taak is dan het toekennen van een adres aan een module, en totaal andere apparatuur vereist. Het is dan ook niet verwonderlijk dat er vaak menselijke fouten optreden bij een dergelijke adres-toekenning, zoals het vergeten om een adres toe te kennen aan één of meerdere modules, of het toekennen van een verkeerd adres, of het per vergissing toekennen van eenzelfde busadres aan twee verschillende modules, enz.

Het kost vaak veel tijd en moeite om alle fouten op te sporen en te corrigeren, vooral wanneer de modules ingebouwd zijn in een vals plafond of in een holte in een muur, of zich bevinden in een lokaal dat afgesloten is.

Dit probleem is des te moeilijker wanneer het gebouw reeds in gebruik is, en treedt bv. ook op wanneer er modules worden bijgeplaatst in een bestaand gebouw. Het zal duidelijk zijn dat men niet zomaar de verlichting of de airconditioning of de verwarming of dergelijke van het ganse gebouw gedurende lange tijd (bijvoorbeeld meerdere uren) kan onderbreken voor het opsporen en/of het corrigeren van een fout. Het bestaande systeem moet blijven werken.

Geconfronteerd met dit probleem, en zoekend naar een oplossing om de fouten sneller en/of eenvoudiger te kunnen opsporen en/of corrigeren, en rekening houdend met de randvoorwaarde dat het systeem (bv. verlichtingssysteem of gebouwautomatisatiesysteem waarin ze gebruikt wordt) moet blijven werken, kwamen de uitvinders van de onderhavige uitvinding op het idee om een werkwijze te verschaffen voor het identificeren van een veelheid van modules die aan een communicatie-bus gekoppeld zijn, door het opvragen van de unieke adressen UA1, UA2, UA3 van de veelheid van te identificeren modules, en die de volgende stappen omvat: (zoals geïllustreerd in FIG. 24, FIG. 25 en FIG. 12 tot FIG. 17) a) het versturen over de communicatie-bus van een identificatieverzoek BO door de GegevensVerzamelModule GV naar de veelheid van modules Dl, D2, D3, voor het opvragen van het unieke adres UA1, UA2, UA3 van deze modules; b) het ontvangen van het identificatieverzoek BO door elk van de veelheid van modules Dl, D2, D3; c) het succesvol versturen van een identificatiebericht BI, B2, B3 door elk van de veelheid van modules Dl, D2, D3 als reactie op het ontvangen identificatieverzoek BO, waarbij ieder identificatiebericht BI, B2, B3 het uniek adres UA1, UA2, UA3 van de betreffende module bevat, waarbij stap c) voor ieder van de veelheid van modules Dl, D2, D3 de volgende stappen omvat: i) het wachten tot de bus vrij is gedurende minstens een vooraf bepaalde tijd W_ID; ii) het trachten te verzenden van het identificatiebericht BI, B2, B3 van de betreffende module, waarbij het trachten te verzenden van het identificatiebericht het achtereenvolgens trachten te verzenden van iedere bit van het identificatiebericht omvat, en waarbij het trachten te verzenden van iedere bit het aansturen en monitoren van de communicatie-bus omvat, en het bepalen of een botsing op de communicatie-bus opgetreden is, iii) en indien een botsing opgetreden is, het stoppen met het verzenden van de betreffende bit en van alle volgende bits van het identificatiebericht, en het herhalen van stappen i) tot iii) totdat het identificatiebericht verzonden is zonder botsing; en indien geen botsing opgetreden is, besluiten dat het identificatiebericht BI, B2, B3 succesvol verzonden is, en niet meer deelnemen aan het trachten te verzenden van het identificatiebericht.

Met "succesvol versturen" wordt bedoeld dat iedere module zal blijven proberen zijn identificatiebericht te versturen, totdat dit gelukt is.

Het is een voordeel van deze werkwijze dat alle unieke adressen van alle modules die effectief met de bus verbonden zijn (behalve dat van de GV, maar de GV hangt meestal rechtstreeks aan een PC, en kan dus rechtstreeks benaderd worden) automatisch kunnen worden opgevraagd zonder tussenkomst van menselijke handelingen, waardoor de kans op menselijke fouten wordt uitgesloten. Door de unieke adressen (die reeds bij de productie van de modules ingebouwd worden in de modules) op te vragen, worden alle modules ondubbelzinnig "ontdekt", ongeacht of het minstens één voorziene bus-adres correct werd toegekend aan de module tijdens de installatie.

Het is een groot voordeel dat het protocol (en dus ook werkwijzen die volgens dit protocol werken, en dus ook bussystemen waaraan inrichtingen gekoppeld zijn die deze werkwijzen uitvoeren) voorziet dat er slechts één enkel identificatieverzoek zal verstuurd worden, waarop ieder van de andere modules zal antwoorden, desnoods in meerdere pogingen, totdat het uiteindelijk gelukt is. Omdat de GV slechts één bericht zal versturen over de bus, wordt veel tijd gewonnen.

Het is een groot voordeel dat het protocol zo voorzien is dat er (in principe, tenzij er "normale boodschappen" tussendoor komen) bij iedere iteratie precies één identificatiebericht ongeschonden over de bus zal verstuurd worden. Dit is vooral te danken aan het feit dat de modules onmiddellijk na het vaststellen van een botsing op bitniveau zullen stoppen met zenden, (wat ze overigens niet alleen doen bij het verzenden van identificatieberichten, maar bij het verzenden van alle berichten). Aangezien het uniek adres vervat zit in het identificatiebericht, en er geen twee modules geproduceerd worden met hetzelfde uniek adres, zijn alle identificatieberichten afkomstig van de veelheid van modules per definitie verschillend, en zal er dus telkens wanneer meerdere modules tegelijk een identificatiebericht beginnen te versturen, precies één identificatiebericht "winnen". Het protocol is zo voorzien dat dit nog steeds geldt, ook als het identificatiebericht meerdere frames bevat (zoals verder zal worden toegeiicht).

Dankzij de botsingsdetectie op bitniveau en het desgevallend stoppen met zenden, en het automatisch opnieuw proberen wanneer de bus voldoende lang vrij is, gaan er geen berichten verloren, en wordt er dus geen tijd verloren op de bus vanwege verminkte (Engels: corrupt) gegevens en heruitzendingen. Dit betekent een belangrijke tijdswinst.

Het is een groot voordeel van deze werkwijze dat ze zelfs uitgevoerd kan worden in een operationeel bussysteem, wat bv. wil zeggen dat het verlichtingssysteem of het gebouwautomatiseringssysteem waarin dit bussysteem deel van uitmaakt, zal blijven werken terwijl deze adresopvraging plaats vindt. Bovendien kan dit gebeuren met een niet of nauwelijks merkbare vertraging (mits een gepaste keuze van wachttijden en/of prioriteiten van berichten en/of bittoewijzigen aan de beschikbare commando's).

Het is een groot voordeel dat deze werkwijze zeer snel kan uitgevoerd worden (bv. grootte-orde in 1,85 a 2,28 seconden voor een bitperiode van 150 ps en een bus met 100 deelnemers, en een uniek adres van 32 bits, aannemend dat de bus niet belast was), omdat bij elke iteratie exact één uniek adres van de modules naar de GegevensVerzamelModule wordt verstuurd. Zulke korte tijd is ongezien, en het voordeel ervan mag niet onderschat worden.

Deze snelheid is vooral te danken aan: 1) het feit dat een "botsing" op de bus niet betekent dat de informatie verloren is gegaan, in tegenstelling tot bijvoorbeeld draadloze communicatie waar een botsing betekent dat beide boodschappen verloren gaan. In de onderhavige uitvinding daarentegen zal zelfs in het geval van een botsing één boodschap correct op de bus worden gezet (zonder verminkt te worden door botsende boodschappen). Dit impliceert dat de tijd die nodig is om alle unieke adressen te versturen nagenoeg lineair toeneemt met het aantal modules gekoppeld aan de bus, en dus niet exponentieel zal toenemen omdat de kans op botsingen zal toenemen. 2) de werkwijze vereist geen speciale ingrepen om botsingen trachten te vermijden (Engels: "collision avoidance"). Integendeel, alle te ontdekken modules mogen perfect tegelijk beginnen met zenden. Omdat er geen variabele wachttijd hoeft voorzien te worden gebaseerd op een pseudo-willekeurige waarde, kan de implementatie vereenvoudigd worden, en kunnen de berichten gemiddeld gezien sneller verstuurd worden. 3) omdat de GegevensVerzamelModule slechts één identificatieverzoek op de bus zal te versturen, waarna alle andere modules vanzelf zullen antwoorden, en vanzelf opnieuw zullen proberen als het niet gelukt is; 4) omdat de GegevensVerzamelModule het uniek adres vraagt, en de "andere modules" hun adres geven, in tegenstelling tot binaire benaderingstechnieken zoals bv. gekend bij DALI, waarbij de meester een adresbereik opgeeft, en de slaven moeten antwoorden of ze binnen dat bereik vallen, of niet; 5) optioneel kan dit nog verder versneld worden door alle andere modules op nagenoeg hetzelfde ogenblik te laten starten (bv. op 1 bitperiode na), door een vaste, vooraf bepaalde wachttijd te gebruiken, bv WJD=l,90 ms. 6) optioneel kan dit nog verder versneld worden door het gebruik van minstens één stroombron in plaats van een passieve optrekweerstand, waardoor de signaalflanken op de digitale bus zeer stijl kunnen zijn (bv. een stijgtijd en daaltijd van minder dan 10 ps, of minder dan 7 ps, of minder dan 5 ps, of minder dan 3 ps, of minder dan 2 ps), zelfs voor een kabel van meer dan 100 m, wat op zijn beurt een kleinere bitperiode toelaat, en dus een hogere bitsnelheid (Engels: bitrate);

In de praktijk wordt een PC of een laptop of dergelijke gekoppeld aan de GV, voor het opslaan en/of weergeven van de unieke adressen, en voor verdere analyse.

Er wordt opgemerkt dat in eerste instantie alleen de unieke adressen worden opgevraagd aan de veelheid van deelnemers, maar dit is de meest cruciale stap. Éénmaal de unieke adressen UA gekend zijn, kunnen de modules individueel geadresseerd worden, door gebruik van specifieke commando's binnen het protocol, waarbij het uniek adres UA gebruikt wordt om één module individueel te adresseren, in plaats van de gebruikelijke (en kortere) busadressen. Deze berichten waarbij het UA wordt gebruikt voor de adressering zijn weliswaar langer dan de "normale berichten" die tijdens de "normale werking" van het systeem tussen de modules worden verstuurd (bv. van een lichtknop naar een lamp), maar zijn bijzonder handig om fouten in het bussysteem op te sporen, en zelfs te corrigeren.

Hierbij wordt opgemerkt dat het op het eerste gezicht misschien triviaal lijkt om lees- en schrijfcommando's op basis van het uniek adres te voorzien in het protocol, maar dat is absoluut niet zo, precies omdat deze adressen niet gekend zijn voor de installateur (bv. omdat ze in gekende werkwijzen niet voorzien worden op het plan), dus zelfs als die functies zouden bestaan in de stand der techniek, zou hij ze niet kunnen gebruiken.

En het was evenmin triviaal om een functie te bedenken om deze adressen op te vragen op de manier zoals hierboven voorgesteld, omdat er duidelijk een vooroordeel bestaat dat men botsing op de bus zoveel mogelijk dient te vermijden.

De unieke adressen laten reeds een eerste analyse toe. Zo is het bv. mogelijk om aan de hand van de structuur van het uniek adres, of door na te gaan in welk bereik het uniek adres valt, of door het uniek adres op te zoeken in een database die tijdens de productie werd opgesteld, bijkomende informatie over de betreffende modules te achterhalen of op te halen, bv. om te bepalen om welk type van module het gaat. Aan de hand van een lijst met functies die correct werken, kan bv. reeds een selectie worden gemaakt voor welke modules bijkomende informatie dient opgevraagd te worden via de bus, en welke niet. Alternatief kan deze informatie ook opgevraagd worden over de bus, bv. door een lees-commando te sturen naar iedere module, waarbij absolute adressering wordt gebruikt in plaats van het lokale busadres.

Verdere details en voordelen zullen duidelijk worden bij de gedetailleerde bespreking van de figuren. FIG. 1 is een replica van FIG. 1 van US8035529(B2), en toont een voorbeeld van een ballastsysteem uit de stand der techniek, gebaseerd op het welgekende "DAU"-protocol. Hoewel de onderhavige uitvinding niet beperkt is tot verlichtingssystemen met een ballast, is dit document uit de stand der techniek interessant als achtergrond informatie voor lezers niet vertrouwd met dergelijke bussystemen, of met het DALI-protocol, of met "commissioning".

Voor de onderhavige uitvinding volstaat het te weten dat FIG. 1 een meester-slaafsysteem 100 toont met een meester-module 20 die berichten over de bus 16 verstuurt (volgens het DALI- protocol) naar de veelheid van modules 12 voor het apart of in groep aansturen van lampen 44. Bij de installatie wordt aan elke module een 6-bits busadres toegekend, bv. gebruik makend van afstandsbediening 18 en infrarood ontvanger 24. De lezer kan meer details lezen in het betreffende document. FIG. 2 is een replica van FIG. 2A van US76O6955(B1), en toont een voorbeeld van een (extreem eenvoudig voorgesteld) bussysteem 200 met een meester-slaaf architectuur, waarbij de bus 203 passief hoog getrokken wordt door een externe 204 of interne 205 optrekweerstand. De modules 201, 211 hebben een bus-interface met een ingangsbuffer 207, 217 en een uitgangsbuffer 206, 216 die aan elkaar gekoppeld zijn. De uitgangsbuffer 206, 216 heeft een "open-collector uitgang" of een "open drain uitgang" waarmee de bus 203 actief laag getrokken kan worden. De werking van zulke bus-interface is welgekend in de stand der techniek, en hoeft daarom niet verder in detail besproken te worden.

De modules 201, 211 van FIG. 2 zijn zodanig verbonden dat de bus 203 een laag spanningsniveau (bv. 0V) zal aannemen wanneer minstens één van de modules 201, 211 de bus laag trekt, en dat de bus 203 een hoog spanningsniveau zal aannemen (bv. 3V) wanneer geen enkele module 201, 211 de bus laag trekt maar de bus wordt hoog getrokken door de optrekweerstand.

Hoewel niet expliciet getoond, bevat de meester 201 en de slaaf 211 elk een controller die een te verzenden signaal aanbiedt aan de uitgangsbuffer 206, 216, en die een signaal ontvangt via de ingangsbuffer 207, 217.

Tijdens het verzenden van een signaal monitort elke module 201, 211 of het te verzenden signaal inderdaad op de bus 203 verschijnt. Een zogenaamde "botsing" treedt op wanneer één van de modules een (passief) hoog niveau op de bus wil zetten, terwijl de bus actief laag wordt getrokken door een andere module. Zulke botsing kan eenvoudig gedetecteerd worden door het signaal van de ingangsbuffer 207, 217 te vergelijken met het te versturen signaal dat aangeboden wordt aan de uitgangsbuffer 206, 216. De bus 203 wordt een "digitale bus" genoemd omdat er slechts twee signaalniveaus onderscheiden dienen te worden: "laag" wanneer de busspanning in een eerste spanningsbereik ligt of hoog "hoog" wanneer de busspanning in een tweede spanningsbereik ligt, dat niet overlapt met het eerste spanningsbereik. FIG. 3 toont een voorbeeldmatig blokdiagram van een interface-module 300 (of kortweg "module") volgens de onderhavige uitvinding. De interface-module 300 bevat minstens één bus-interface 303 en een controller of processor 301.

De bus-interface 303 van FIG. 3 heeft een uitgangsbuffer (niet getoond) om signalen te kunnen verzenden, en heeft een ingangsbuffer (niet getoond) om signalen te kunnen ontvangen. De module 300 heeft verder middelen (niet getoond) om een botsing te detecteren op de bus, en heeft middelen om de uitgangsbuffer uit te schakelen (wat betekent dat er gestopt wordt met zenden) zodra een botsing wordt gedetecteerd.

De controller of processor 301 kan bijvoorbeeld een toestandsmachine (Engels: "statemachine") zijn, of kan een programmeerbare processor zijn, bv. een programmeerbare microprocessor, met een intern of extern werkgeheugen (bv. RAM), en met een intern of extern niet-vluchtig geheugen (bv. ROM, FLASH, EEPROM) voor het opslaan van programma-instructies die uitgevoerd dienen te worden door de processor. Deze programma-instructies zorgen ervoor dat communicatie over de bus gebeurt volgens een specifiek protocol.

Optioneel kan de module 300 een interne optrekweerstand 305 bevatten, al dan niet via een schakelaar (niet getoond) verbonden aan de voedingsspanning VDD, om de bus passief hoog te trekken.

Optioneel kan de module 300 een interne stroombron 304 bevatten, al dan niet via een schakelaar (niet getoond) verbonden aan de voedingsspanning VDD, om de bus actief hoog te trekken, maar met een (relatief zwakke) stroom die kleiner is dan de (relatief sterke) stroom die afgevoerd kan worden door de uitgangsbuffers. Een voordeel van het gebruik van een stroombron 304 in plaats van een optrekweerstand 305 is dat de spanning op de bus nagenoeg lineair kan stijgen (of dalen) als functie van de tijd in plaats van exponentieel. Hierdoor kunnen stijlere flanken bekomen worden, wat toelaat om de bitperiode te verkleinen.

In voorkeursuitvoeringsvormen van de onderhavige uitvinding wordt de bus 311 passief hoog getrokken door middel van minstens één interne optrekweerstand 305 , of door middel van minstens één interne stroombron 304, of door middel van een externe optrekweerstand (zoals in FIG. 2).

Optioneel bevat de module 300 nog één of meer bijkomende blokken zoals een IR (infrarood) zendontvanger 306, een RF zendontvanger 307, een temperatuursensor 308, een bewegingsdetector 309, een glasvezel-zendontvanger (niet getoond), enzovoorts.

Verder kan de module één of meerdere externe ingangen "IN” en/of één of meerdere externe uitgangen "UIT" hebben, afhankelijk van de component waaraan deze interface-module 300 verbonden dient te worden. In het voorbeeld van FIG. 3 wordt een module 300 met twee ingangen en drie uitgangen getoond, maar uiteraard is de uitvinding daartoe niet beperkt, en bepaalde modules kunnen bv. slechts één enkele ingang hebben en geen uitgang, of slechts één uitgangen geen ingang.

In voorkeursuitvoeringsvormen van de onderhavige uitvinding wordt aan iedere ingang en aan iedere uitgang van de module 300 een uniek busadres toegekend, waarbij het busadres ongeveer dezelfde functie heeft als een busadres bij DALI, met ais verschil dat bij DALI één module slechts één busadres heeft terwijl een module 300 volgens de onderhavige uitvinding meerdere busadressen kan hebben, en dat een DALI-adres slechts 6 bits lang is (max. 64 componenten), terwijl een busadres in voorkeursuitvoeringsvormen van de onderhavige uitvinding minstens 10 bits (max. 1024 componenten), of minstens 12 bits (max. 4048 componenten) of minstens 14 bits of minstens 16 bits of minstens 20 bits lang is.

Als voorbeeld, wanneer er bv. een dimmer aan uitgang UIT1 hangt, en aan deze dimmer is bv. busadres "500" toegekend volgens het plan, dan dient de module 300 overeenkomstig geconfigureerd te worden door de installateur, bv. door het opslaan van getal "500" op een specifieke plaats in een niet-vluchtig geheugen. Dit kan eventueel hetzelfde flash-geheugen 314 zijn als dat waarin de uitvoerbare code is opgeslagen, of het kan een apart niet-vluchtig geheugen zijn, bv. EEPROM 302. Na het opslaan van het getal "500" als busadres voor uitgang UIT1 (in dit voorbeeld) zal de module 300 berichten bestemd voor busadres "500" ontvangen en decoderen, en de uitgang UIT1 overeenkomstig aansturen.

Indien bv. ingang IN2 verbonden is met een drukknop met busadres "188", dan kan op een gelijkaardige manier door het opslaan van getal "188" in een niet-vluchtig geheugen van de module 300, de module geconfigureerd worden om een bericht te verzenden afkomstig van "busadres 188" wanneer de betreffende drukknop wordt ingedrukt.

In de context van de onderhavige uitvinding dient tijdens de "commissioning" in principe een uniek busadres toegekend te worden aan iedere ingang en aan iedere uitgang van de module (in zoverre dat die gebruikt wordt), waarbij het busadres alleen uniek hoeft te zijn binnen één bepaald bussysteem (meestal één gebouw). Indien de module 300 slechts één ingang of slechts één uitgang bevat, dan kan dat ene busadres beschouwd worden als het busadres van de module (zoals bij DALI).

De functie van het dimmen en het nagaan van de status van een drukknop (in het voorbeeld van hierboven) is eigen aan het type van module 300, en zal doorgaans verschillen per type. In voorkeursuitvoeringsvormen van de onderhavige uitvinding kan informatie, waaronder het type van de module, opgevraagd worden via de bus-interface.

Optioneel bevat de module 300 verder een seriële interface, bv. een I2C of een RS232 of een SPI-interface, die bijvoorbeeld gebruikt kan worden om de busadressen te programmeren tijdens de hoger genoemde "commissioning". Alternatief kan er bv. een drukknop voorzien worden (niet getoond) verbonden met een daartoe bestemde ingang PROG van de controller 301, om ervoor te zorgen dat de module 300 een speciale routine uitvoert waarbij hij een speciaal daartoe bestemd bericht met daarin minstens één busadres zal ontvangen en zal opslaan, om later te gebruiken als busadres. In het voorbeeld van hierboven zou dat speciale bericht bv. het busadres "500" bevatten bestemd voor uitgang UIT1 en het busadres "188" bestemd voor ingang IN2, en eventueel andere busadressen voor de andere ingangen en uitgangen.

De seriële interface kan ook gebruikt worden om te communiceren met een gebruikersinrichting, bv. een computer 401, zoals getoond in het voorbeeld van FIG. 4, waar de module D01 fungeert als GegevensVerzamelModule GV en informatie kan doorsturen of uitwisselen met de PC 401. Alternatief kan communicatie met de gebruikersinrichting 401 (bv. PC) ook gebeuren via de IR zendontvanger 306 (indien aanwezig), of via de RF zendontvanger 307 (bv. Wifi of Bluetooth), of via een andere geschikte interface, zoals een USB-poort (niet getoond).

Elke module 300 volgens de onderhavige uitvinding heeft een uniek adres UA, bv. een serienummer, zo gekozen dat er geen twee modules 300 met hetzelfde uniek adres bestaan. Dit uniek adres wordt doorgaans tijdens de productie van de module 300 opgeslagen in een niet vluchtig geheugen van de module, bv. in Flash of EEPROM, of liever nog in een OTP geheugen (One-Time-Programmabie).

Uiteraard heeft elke module 300 ook een poort voor connectie met een voeding Vdd en een referentiepotentiaal Gnd. In het voorbeeld van FIG. 3 kan de voeding bv. een gelijkspanning VDD zijn die geleverd wordt door een externe transformator (niet getoond), maar deze voeding kan ook geleverd worden via één van de draden van de bus (zoals verder zal besproken worden in FIG. 7 tot FIG. 9).

Verder bevat de module 300 bij voorkeur een klokcircuit 310, voor het genereren van één of meerdere interne kloksignalen. Klokcircuits zijn gekend in de stand der techniek, en kunnen bv. gebaseerd zijn op een interne RC-vertraging, of zijn bij voorkeur gebaseerd op de oscillatiefrequentie van een extern kristal 315. Indien de bus 311 zelf een kloksignaal aanlevert (niet getoond), dan kan het kristal 315 eventueel weggelaten worden, anders dient de module 300 zijn timing te synchroniseren met de flanken van het data-signaal op de bus 311, op gekende manieren.

Optioneel kan de module 300 een zgn. ware-tijd-klok (Engels: "Real Time Clock") 313 bevatten, dat is meestal een chip gevoed door een lokale batterij, welke chip de datum en de tijd bijhoudt (bv. in uren, minuten en seconden), zoals bv. gekend in de PC-wereld. Deze ware-tijd-klok kan bv. handig zijn om tijdstempels (Engels: "time-stamps") toe te voegen aan logboekberichten die opgeslagen worden in een logboek in een niet-vluchtig geheugen.

Bij voorkeur omvat de module 300 ook een zgn. "watchdog-timer" 312, of een bewakingcircuit, dat bv. zorgt voor een interne reset van de module 300 bij het opkomen van de spanning, of wanneer er gedurende een vooraf bepaalde tijd geen activiteit van de controller meer wordt vastgesteld.

De module 300 volgens de onderhavige uitvinding is nieuw ten opzichte van de stand der techniek, onder meer omdat de controller 301 voorzien is, bv. geprogrammeerd is voor het uitvoeren van communicaties over de bus 311 volgens een specifiek protocol dat minstens de werkwijze bevat waarbij de module 300 bij het ontvangen van het identificatieverzoek, herhaaldelijk zal trachten zijn uniek adres te versturen via een identificatieboodschap (getoond aan de rechterkant van FIG. 25). FIG. 4 is een schematische voorstelling van een voorbeeld van een (zeer eenvoudig) "verlichtingssysteem" of een "gebouwautomatiseringssysteem" 420, omvattende vier componenten COMP1, COMP2, COMP3, COMP4 (bijvoorbeeld gekozen uit de verzameling bestaande uit een lichtknop, een lamp, een bewegingsdetector, en een zonnewering), en drie interface-modules Dl, D2, D3 en een digitale bus 404 met draden (Engels: "wired bus"). In het voorbeeld van FIG. 4 is module Dl verbonden met slechts één component Dl, en is module D2 verbonden met slechts één component D2, maar is module D3 verbonden met twee componenten D3, D4. Elke module Dl, D2, D3 heeft een uniek adres of serienummer, respectievelijk UA1, UA2, UA3. Deze unieke adressen worden echter niet gebruikt tijdens de "normale werking" van het verlichttingssysteem of het gebouwautomatiseringssysteem, maar wel busadres BA1 dat toegekend wordt aan module Dl en geassocieerd wordt de ingang of uitgang waaraan de eerste component COMP1 gekoppeld is, busadres BA2 dat toegekend wordt aan module D2 en geassocieerd wordt met de ingang of uitgang waaraan de tweede component COM2 gekoppeld is, en busadressen BA3 en BA4 die beiden toegekend worden aan module D3, waarbij busadres BA3 geassocieerd wordt met de ingang of uitgang waaraan de derde component COMP3 is verbonden, en busadres BA4 geassocieerd wordt met de ingang of uitgang waaraan de vierde component COMP4 is verbonden

Het deelsysteem dat de interface-modules Dl, D2, D3 en de digitale bus 404 omvat, wordt het "bussysteem" genoemd. De modules Dl, D2 en D3 kunnen slaven op de bus zijn, maar kunnen ook meesters zijn, d.w.z. dat ze autonoom een bericht over de bus kunnen versturen, zonder dat daarom gevraagd werd door een andere module.

Aan de bus 404 kan optioneel ook een module DO gekoppeld zijn, tijdelijk of permanent. In het voorbeeld van FIG. 4 is deze module DO niet gekoppeld met één van de hoger genoemde componenten COMP1, COMP2, COMP3, maar is verbindbaar of functioneel verbonden met een gebruikersinrichting 401, bv. een PC met invoerorganen 403 en een scherm 402, of een Laptop of een tablet of een smartphone. De module DO kan bv. gebruikt worden voor het configureren of herconfigureren van het bussystem en/of voor het monitoren van traffiek over de bus 404, enz. De PC 401 kan bv. informatie over het bussysteem opvragen via de interface-module DO, waarmee hij functioneel verbonden is, bv. door middel van een seriële of draadloze interface, en kan deze informatie bv. weergeven op een scherm 402, of opslaan op een opslagmedium (niet getoond), enz.

In de context van de onderhavige uitvinding fungeert de module DO als "GegevensVerzamelModule", afgekort: "GV", wat betekent dat dit de module is die het hoger beschreven "identificatieverzoek" op de bus verstuurt, en die de "identificatieberichten" ontvangt van de andere modules Dl, D2, D3 met daarin respectievelijk de unieke adressen UA1, UA2, UA3. De GV kan deze identificatieberichten of deze unieke adressen doorsturen naar de gebruikersinrichting 401 voor verdere verwerking, bv. voor weergave op een scherm 402. De term "GegevensVerzamelModule" wordt in dit document gebruikt om een onderscheid te maken met de gekende begrippen van "meester" en "slaaf".

Een mogelijk scenario om het bussysteem van FIG. 4 correct te installeren in een gebouw verloopt bv. als volgt: - een installateur legt een kabel 404 met meerdere draden van een controlekamer naar een bepaalde kamer van een gebouw, volgens een plan; - de installateur monteert de componenten COMP1, COMP2, COMP3, COMP4 en monteert de modules Dl, D2, D3, en verbindt de componenten met de bijhorende modules, en verbindt de modules met de kabel 404; - de installateur programmeert (op gekende wijze) het busadres BA1 voor component COMP1 in module Dl, en programmeert het busadres BA2 voor component COMP2 in module D2, en programmeert de busadressen BA3 en BA4 voor COMP3 en COMP4 in module D3, zoals voorzien in het plan. Iedere module Dl, D2, D3 slaat het/de aan hem toegekende busadres(sen) op in een intern niet-vluchtig geheugen (bv. in flash of eeprom).

Stel nu bij wijze van voorbeeld dat de installateur correct busadres BA1="1" toekent aan module Dl, maar per vergissing niet busadres BA2="22" in module D2 heeft opgeslagen, maar een foutief adres (bv. adres "23"), en wel correct busadres BA3="33" opslaat in module D3, maar per vergissing heeft vergeten het busadres BA4="43" op te slaan in de module D3. Uiteraard zal het verlichtingssysteem of het gebouwautomatiseringssysteem waarin het bussysteem wordt gebruikt dan niet werken zoals voorzien in het plan. Om deze fout(en) te detecteren en te corrigeren dient de installateur zich fysiek naar elk van de modules Dl, D2 en D3 te begeven (want hij weet niet welke modules correct, en welke modules niet correct geprogrammeerd zijn), en dient bv. de toekenning van het busadres/de busadressen alsnog of opnieuw uit te voeren, of toch minstens extra handelingen uit te voeren om het busadres dat opgeslagen is in de module (of de fabriekswaarde) op de een of andere manier op te vragen (bv. in het geval van een lamp is het soms mogelijk een gemoduleerd lichtsignaal te versturen, aan de hand waarvan het busadres kan bepaald worden). Dit is tijdrovend, en soms heel lastig of zelfs onmogelijk, bv. omdat de betreffende kamer waarin de module zich bevindt afgesloten is.

Volgens de onderhavige uitvinding kunnen tenminste sommige van deze problemen veel sneller, en/of eleganter gedetecteerd worden, en eventueel zelfs vanop afstand opgelost worden, bij voorbeeld als volgt (verwijzend naar FIG. 4 en FIG. 24): - indien de module DO nog niet aanwezig is, dan wordt ze toegevoegd, en (tijdelijk of permanent) verbonden met de digitale bus 404, zoals getoond in FIG. 4; - indien de gebruiksinrichting 401, bv. PC of laptop of dergelijke nog niet aanwezig is in het systeem, wordt ook deze toegevoegd, en functioneel verbonden met de module DO, zoals getoond in FIG. 4 (bv. via Bluetooth); - de module DO fungeert als GegevensVerzamelModule GV en verstuurt een identificatieverzoek BO (zie ook FIG. 12) naar de andere modules DI, D2, D3, bv. na het drukken op een knop (niet getoond), of na het ontvangen van een opdracht vanuit de PC 401, of op een andere geschikte wijze.

Dit identificatieverzoek BO is een zgn. "query-commando" of "broadcast-commando", wat betekent dat het een bericht is dat bestemd is voor alle andere modules, ongeacht hun busadres(sen). Dit bericht bevat een vooraf bepaald bitpatroon om aan te duiden dat dit bericht een identificatieverzoek is, vastgelegd in het protocol. Het bericht B0 zai ontvangen worden door de andere modules Dl, D2, D3. De modules Dl, D2 en D3 zullen dit commando ontvangen zelfs indien hun busadres(sen) nog niet, of verkeerd geprogrammeerd is/zijn.

Vervolgens zullen de andere modules Dl, D2, D3, als reactie op het identificatieverzoek, elk een eigen identificatiebericht terugsturen over de bus, bestemd voor de GegevensVerzamelModule GV. Deze identificatieberichten BI, B2, B3 bevatten een eerste gedeelte dat dient om aan te geven dat dit bericht een identificatiebericht is, en een tweede gedeelte dat het uniek adres UA1, UA2, UA3 van de betreffende module bevat. Het eerste gedeelte is een vooraf bepaald bitpatroon dat gelijk is voor alle modules. Het tweede gedeelte is verschillend.

De GegevensVerzamelModule GV herkent deze identificatieberichten aan de hand van het specifieke bitpatroon dat aangeeft dat dit een identificatiebericht is, en ontvangt de berichten met de unieke adressen van alle andere modules Dl, D2, D3. In FIG. 12 tot FIG. 19 zal aan de hand van een vereenvoudigd voorbeeld in meer detail toegelicht worden hoe dit kan gebeuren, zowel op bit-niveau als op frame-niveau. Eén van de onderliggende ideeën van de onderhavige uitvinding is erop gebaseerd dat elk uniek adres UA1, UA2, UA3 waarlijk uniek is, en dat bijgevolg ook de identificatieberichten uniek zijn, waardoor het gegarandeerd is dat elk identificatiebericht precies één keer ongeschonden over de bus zal verstuurd worden, zelfs wanneer honderden of zelfs duizend of meer modules "nagenoeg tegelijk” beginnen met hun identificatiebericht te verzenden, en zelfs wanneer het systeem reeds operationeel was op het moment dat het identificatieverzoek wordt verstuurd, en er "normale berichten" tussen de identificatieberichten worden verstuurd.

Er wordt opgemerkt dat de module DO die fungeert als GV slechts één enkel query-commando zal versturen, en dat de andere modules Dl, D2, D3 vanzelf opnieuw zullen proberen om hun identificatiebericht BI, B2, B3 te verzenden, mocht het niet van de eerste poging lukken. Doordat de GV slechts één commando zal versturen, wordt de trafiek op de bus beperkt, en wordt veel tijd gewonnen. Wanneer de bus inactief blijft over minstens een vooraf bepaalde time-out periode WJD, dan weet de module DO dat alle identificatieberichten verstuurd zijn.

Het is belangrijk om op te merken dat de herhaalde pogingen wei als "heruitzendingen" voor de betreffende module mogen worden beschouwd, maar niet als "heruitzending" op de bus vanwege verminkte boodschappen veroorzaakt door botsingen. Het protocol is zo gedefinieerd dat er wel botsingen zullen voorkomen wanneer twee (of meer) modules tegelijk een verschillende bit op de bus trachten te zetten, maar de module waarvan de informatie verminkt wordt, stopt meteen met zenden, en de module waarvan de data ongeschonden blijft, gaat verder met verzenden. Dit aspect an sich is weliswaar gekend, maar niet in combinatie met het opvragen van de unieke addressen die automatisch het ene na het andere worden verstuurd, waardoor een grote snelheidswinst wordt bereikt. En ook niet in combinatie met het optioneel kenmerk dat er geen pseudo-random tijd wordt gewacht alvorens de identificatieberichten te versturen.

Terug verwijzend naar FIG. 4, zullen alle unieke adressen UA1, UA2, UA3 dus verzonden worden naar het gebruikerstoestel 401, bv. een PC met een scherm 402 en invoerorgangen 403 (bv. een toetsenbord en een muis). Deze unieke adressen zijn de basis voor verdere analyse.

Wanneer de unieke adressen gekend zijn, kan er bv. een commando verstuurd worden naar iedere module Dl, D2, D3 afzonderlijk, om meer details op te vragen, zoals bv. het type van de module, en/of het busadres of de busadressen die opgeslagen zijn in de module, enz.

Daartoe kan het protocol van een bussysteem volgens de onderhavige uitvinding tevens commando's bevatten om bepaalde informatie op te vragen van één bepaalde module die geadresseerd wordt aan de hand van zijn uniek adres, en kan het protocol ook commando's bevatten om deze informatie te versturen vanuit de betreffende module naar de GV, om eventueel daarin opgeslagen te worden in een niet-vluchtig geheugen. In de stand der techniek kan weliswaar informatie opgevraagd worden aan de modules (inclusief het serienummer), maar die communicatie gebeurt op basis van het toegekende busadres, en werkt dus pas nadat de busadressen correct zijn toegekend, en werkt niet als er geen of een foutief busadres is toegekend. De bijkomende functie van de onderhavige uitvinding, waarmee modules individueel kunnen geadresseerd worden gebruik makend van hun uniek adres, zijn dus uitermate geschikt om fouten op te sporen en/of te corrigeren, maar pas nadat de unieke adressen gekend zijn.

Eventueel kan de PC 401 ook een gegevensbestand consulteren, waarin extra informatie is opgeslagen van de geproduceerde modules, op basis van het unieke adres. Zo kan bv. het type van iedere module eenvoudig opgehaaid worden uit een gegevensbestand.

Terug verwijzend naar het voorbeeld van hierboven, kan de installateur bepalen dat: (a) de module Dl van het type is om te interfacen met COMP1 (bv. een drukknop), en dat het busadres BA1 correct geprogrammeerd is, en dat (b) de module D2 van het type is om te interfacen met COMP2 (bv. een lamp), en dat het busadres BA2 verkeerd geprogrammeerd is, en dat (c) de module D3 van het type is om te interfacen met COMP3 (bv. een relais voor een motor van een zonnewering) en COMP4 (bv. een windsensor), en dat het busadres BA3 correct geprogrammeerd is, maar het busadres BA4 niet geprogrammeerd is.

Deze fouten kunnen vervolgens eenvoudig gecorrigeerd worden door het versturen van een correct busadres naar module D2 en D3, gebruik makend van een schrijf-commando met absolute addressering (d.w.z. waarbij het unieke adres wordt gebruikt om de module te addresseren en niet het busadres).

Uit het voorbeeld van hierboven blijkt dat het niet altijd noodzakelijk is de fysieke locatie van de modules te kennen, en dat het niet altijd nodig is om naar de fysieke locatie te gaan waar de betreffende component zich bevindt, maar soms is dat wel nodig. Maar zelfs dan is de onderhavige uitvinding bijzonder handig, omdat het aantal componenten dat handmatig geverifieerd dient te worden drastisch kan verminderd worden.

Samengevat laat de onderhavige uitvinding dus toe om op een snelle manier alle unieke adressen te vinden (met slechts één query-commando), en laat vervolgens toe om iedere module individueel te adresseren aan de hand van hun uniek adres, om bijkomende informatie te lezen en/of te schrijven. Eventueel kan ook een gegevensbestand geraadpleegd worden om bepaalde informatie op te vragen op basis van het uniek adres. Aan de hand van deze informatie kan de installateur een diagnose maken van de fouten, en kan zeer gericht de nodige correcties uitvoeren. FIG. 5 is een schematische voorstelling van een tweede voorbeeld van een bussysteem volgens de onderhavige uitvinding, en van een verlichtingssysteem of een gebouwautomatiseringssysteem dat het bussysteem omvat.

Het bussysteem van FIG. 5 omvat een eerste fysieke geleider VO die modules DOI, D02 en D03 gesitueerd op een gelijkvloers van een gebouw verbindt, voor het interfacen met bijhorende componenten COMPOl, COMP02, COM03, en omvat een tweede fysieke geleider VI die modules Dll, D12 en D13 gesitueerd op een eerste verdieping van het gebouw verbindt, voor het interfacen met bijhorende componenten COMP11, COMP12, COMP13. De eerste geleider VO en de tweede geleider VI zijn elektrisch met elkaar verbonden via een zogenaamde "backbone" BB.

Op een gelijkaardige manier als beschreven in het voorbeeld van FIG. 4, kan de GegevensVerzamelModule 504 een identificatieverzoek sturen naar elk van de modules DOI, D02, D03, Dll, D12, D13, en zal elke module antwoorden met een identificatiebericht dat het unieke adres van de betreffende module bevat.

Daarna kan de GegevensVerzamelModule GV desgewenst bijkomende informatie opvragen van de modules door deze te adresseren aan de hand van hun uniek adres (hierin "absolute addressering genoemd"), en/of kan de GegevensVerzamelModule GV één of meerdere busadressen vanop afstand programmeren in de betreffende module.

Hierboven werd beschreven hoe het identificatieverzoek en de identificatieberichten kunnen gebruikt worden om fouten te detecteren gemaakt bij de initiële toekenning van één of meer busadressen bij de installatie van het systeem, maar de onderhavige uitvinding is daartoe niet beperkt, en kan bv. ook gebruikt worden bij pannes, bijvoorbeeld om te detecteren of alle modules nog reageren, of kan bijvoorbeeld ook gebruikt worden om een up-to-date lijstte genereren met de unieke adressen met de toegekende busadressen (bv. om te bepalen welke busadressen nog vrij zijn wanneer een module wordt toegevoegd aan het systeem), enz.

In een voorkeursuitvoeringsvorm van de onderhavige uitvinding is het busprotocol zodanig ontworpen dat het versturen van het identificatieverzoek door de GegevensVerzamelModule 504, en het daarop antwoorden door alle andere modules DOI, D02, D03, D04, D05, D06 kan uitgevoerd worden terwijl het systeem "in werking" is als verlichttingssysteem of als gebouwautomatiseringssysteem. Wanneer er bijvoorbeeld twee modules (niet getoond) en twee componenten (niet getoond) worden bijgeplaatst op de eerste verdieping, dan is het wenselijk dat de verlichting en/of de functies zoals airconditioning en/of zonnewering op het gelijkvloers blijven werken. Zoals verder zal toegelicht worden is dit mogelijk omdat het identificatieverzoek en de identificatieberichten gebruik maken van eenzelfde framestructuur als de framestructuur die gebruikt wordt voor het verzenden van "normale" boodschappen tussen componenten (bv. van een drukknop naar een verlichting, of van een lichtsensor naar een zonnewering, enz.). Dat geldt ook voor de lees- en schrijfoperaties met absolute addressering.

Het zal duidelijk zijn dat een relatief snelle detectie van alle unieke adressen, en vooral een communicatie waarbij de andere modules kunnen blijven werken, des te belangrijker wordt naarmate het gebouw meer modules en/of meer componenten heeft, bijvoorbeeld minstens 17, of minstens 33, of minstens 50, of minstens 65, of minstens 100, of minstens 129, of minstens 150, of minstens 200, of minstens 257.

In een uitvoeringsvorm van de onderhavige uitvinding hebben identificatieberichten een lagere prioriteit op de bus dan andere berichten zoals bv. berichten voor het versturen van een bericht van een drukknop naar een lamp (hierin "normale berichten" of ook "operationele berichten" genoemd). Op die manier wordt voorkomen dat de identificatieberichten de bus volledig innemen totdat alle modules geïdentificeerd zijn. Dit kan bv. eenvoudig geïmplementeerd worden door de minimale wachttijd W_ID (zie FIG. 19) voorafgaand aan een identificatiebericht groter te kiezen dan de minimale wachttijd voorafgaand aan een "normaal bericht", bv. minstens 2.1 ms in plaats van minstens 1.95 ms.

Bij voorkeur zijn de modules zo uitgevoerd dat, wanneer de module zowel een identificatiebericht moet verzenden alsook een "normaal bericht" (bv. een bericht vanwege het indrukken van een drukknop of vanwege een detector gekoppeld aan de module), dat het "normale bericht" eerder verstuurd wordt dan het identificatiebericht. Dit is een kwestie van het bepalen van welk te versturen bericht voorrang krijgt in de module. In het geval van een programmeerbare controller, kan deze functionaliteit eenvoudig voorzien worden in het programma dat uitgevoerd wordt door de controller.

Uiteraard moeten alle modules ten allen tijde luisteren naar de bus, en de nodige actie uitvoeren indien een bericht ontvangen wordt dat voor hem bestemd is, bv. het aanschakelen van een bepaalde lamp die verbonden is met deze module, zelfs indien de module nog een identificatiebericht moet versturen. Dit kan bv. eenvoudig geïmplementeerd worden door bv. een microcontroller te gebruiken die aan een voldoend hoge kloksnelheid wordt geklokt. FIG. 6 is een derde schematisch voorbeeld van een bussysteem volgens de onderhavige uitvinding. Het is een variant van het bussysteem van FIG. 5. De componenten zijn niet weergegeven om de tekening niet te overladen. Het voornaamste verschil met het bussysteem van FIG. 5 is dat er signaalversterkers Rl, R2 zijn toegevoegd op de bus, om de impedantie van de bus te verlagen. De signaalversterkers kunnen bv. twee deelcircuits omvatten, verbonden met een optische koppeling.

De deelcircuits zijn bij voorkeur zo uitgevoerd dat wanneer de bus aan de ene kant van de signaalversterkers laag is (bv. aan de kant van de backbone BB), dat de signaalversterker de bus aan de andere kant (bv. deelbus VO) ook laag trekt, en omgekeerd. Dankzij de optische koppeling in de signaalversterkers is de impedantie van de bus drastisch verlaagd, wat de steilheid van de flanken ten goede komt, waardoor een hogere bitsnelheid kan gekozen worden, en kunnen alle modules functioneel met elkaar praten alsof ze allemaal aan eenzelfde draad hingen. Zulk bussysteem biedt een enorme flexibiliteit qua herconfiguratie, zonder de nadelen die gepaard gaan met lange leidingen, zoals trage flanken en lage bitsnelheid. FIG. 7 tot FIG. 9 tonen enkele voorbeelden van bedrade bussen (Engels: "wired bus"), gekend in de stand der techniek. Deze figuren dienen onder meer om aan te geven dat de voeding voor de modules van de bus kan komen of lokaal kan gegenereerd worden, en/of om aan te geven dat de bus bv. een tweedraads of driedraads bus kan zijn, maar de uitvinding is daartoe niet beperkt. FIG. 7 toont een voorbeeld van een tweedraadsbus met twee elektrische geleiders waarbij één geleider "GND" fungeert als referentie (grond), en een andere geleider "DATA" gebruikt wordt voor data-overdracht. In dit geval dienen de modules Dl, D2, D3 zelfstandig gevoed te worden, bijvoorbeeld vanuit een lokale transformator of vanuit een batterij (niet getoond). FIG. 8 toont een voorbeeld van driedraadsbus met drie elektrische geleiders waarbij één geleider "GND" fungeert als referentie (grond), een tweede geleider "DATA" gebruikt wordt voor dataoverdracht, en een derde geleider "VDD" gebruikt wordt om ten minste sommige andere deelnemers te voeden via de bus. De spanning VDD is bij voorkeur een gelijkspanning. FIG. 9 toont een voorbeeld van een tweedraadsbus met twee elektrische geleiders waarbij één geleider "GND" fungeert als referentie (grond), en de tweede geleider "DATA/VDD" gebruikt wordt voor zowel data-overdracht als voor het voeden van andere deelnemers. Deze deelnemers dienen dan wel speciale voorzieningen te hebben zoals bv. een diode en een capaciteit, maar dergelijke circuits zijn bekend in de stand der techniek, en hoeven dus niet verder toegelicht worden.

Bussystemen volgens de onderhavige uitvinding kunnen gebruikt worden met elk van de configuraties getoond in FIG. 7 of FIG. 8 of FIG. 9, maar zijn daartoe niet beperkt. Zo kan een bussysteem volgens de onderhavige uitvinding bv. ook werken met tweepolige signalen (Engels: "dual ended signals"), of met synchrone signalen (in dit geval bevat de bus bv. een extra geleider met een klok-signaal). FIG. 10 toont enkele voorbeelden van signalen die gebruikt kunnen worden in uitvoeringsvormen van de onderhavige uitvinding. De modules van een bussysteem volgens de onderhavige uitvinding hoeven slechts drie verschillende signalen te onderscheiden op de bus: - een "databitl-signaal" (of kortweg "databitl") overeenkomstig een logische "1", - een "databitO-signaal" (of kortweg "databitO") overeenkomstig een logische "0", - een "leeg signaal" (Engels: "idle", dat aangeeft dat de bus vrij is). Deze vorm wordt gebruikt tussen verschillende sequenties van bits (verder "frame" genoemd).

In een voorkeursuitvoeringsvorm van de onderhavige uitvinding, heeft het "databitl-signaal" een vooraf bepaalde bitperiode (bv. 150 ps) en een vooraf bepaalde vorm met één spanningstransitie van een laag niveau (bv. 0V) naar een hoog niveau (bv. 24V) na ongeveer 2/3 van de bitperiode (bv. 100 ps), zoals weergegeven in FIG. 10(a); en heeft het "databitO-signaal" een vooraf bepaalde bitperiode gelijk aan de duur van het databitl-signaal (bv. 150 ps), en een vooraf bepaalde vorm met één spanningstransitie van het laag niveau (bv. 0V) naar het hoog niveau (bv. 24V) na ongeveer 1/3 van de bitperiode (bv. 50 ps), zoals weergegeven in FIG. 10(b); en heeft het "vrij-signaal" een signaalvorm gelijk aan het hoog niveau (bv. 24V), zoals weergegeven in FIG. 10(c), met een onbepaalde duur; maar de uitvinding is hiertoe niet beperkt, en zal ook werken met andere signaalvormen en/of andere spanningswaarden en/of een andere timing, op voorwaarde dat de signalen toelaten dat een botsing van een databitl-signaal en een databitO-signaal op bitniveau kan gedetecteerd worden, en dat één van de bits zelfs bij botsing ongeschonden verstuurd wordt, aannemende dat alle zenders van de niet-dominante bit stoppen met zenden vóór het einde van de bitperiode.

Hierbij dient opgemerkt te worden dat de signalen getoond in FIG. 10 ideaal zijn voorgesteld. In de praktijk zal het signaal niet exact OV of 24V zijn, maar zulke aspecten zijn gekend, en hoeven niet verder toegelicht te worden.

Bij voorkeur is het bussysteem volgens de onderhavige uitvinding een bussysteem waarbij de bus (zwak) hoog wordt getrokken door middel van een (relatief grote) optrekweerstand (Engels: "puli-up resistor") of een relatief zwakke stroombron, en waarbij iedere module de bus actief laag kan trekken door middel van een (relatief sterke) laagtrektransistor (Engels: pull-down-transistor). In zulke busconfiguratie is databitl de dominante bit en databitO de niet-dominante bit, omdat de transistor een sterkere stroom kan leveren dan de zwakke pull-up weerstand of de zwakke stroombron, maar de uitvinding is hiertoe niet beperkt, en andere configuraties kunnen eveneens gebruikt worden, bv. een busconfiguratie waarbij de bus (zwak) wordt laag getrokken door middel van een relatief grote weerstand, en actief hoog kan getrokken worden door een (relatief sterke) transistor in de modules.

In een andere uitvoeringsvorm van de onderhavige uitvinding stelt de signaalvorm van FIG. 10(a) een logische "0" voor, en stelt de signaalvorm van FIG. 10(b) een logische "1" voor. In dat geval is databitO de dominante bit, en is databitl de niet-dominante bit. FIG. 11 toont twee andere voorbeeldmatige golfvormen die eveneens kunnen gebruikt worden door uitvoeringsvormen van de onderhavige uitvinding, gekend onder de naam "Manchester"-coding. In de variant aangeduid met "Manchesterl" (gekend in de stand der techniek als Manchester volgens G.E.Thomas) wordt een logische "0" voorgesteld door een spanningstransitie van laag naar hoog na 50% van de bitperiode, en wordt een logische "1" voorgesteld door een spanningstransitie van hoog naar laag na 50% van de bitperiode. In de variant aangeduid met "Manchester" (gekend in de stand der techniek als Manchester volgens IEEE 802.3) is dat net omgekeerd.

Een voordeel van de signalen van FIG. 10 t.o.v. de signalen van FIG. 11 is dat de start van iedere bitperiode samenvalt met de dalende flank van het signaal, waardoor de synchronisatie nauwkeuriger kan zijn.

Sommige bussystemen uit de stand der techniek maken gebruik van bijkomende signaaltypes zoals een "resetsignaai" of een "aandachtsverzoeksignaal" (Engels: "attention request signal"), maar dat is niet nodig voor de onderhavige uitvinding. De drie hoger genoemde signalen (databitO, databitl en vrij) volstaan. Dit kan meehelpen om de complexiteit van de modules voor een bussysteem volgens de onderhavige uitvinding te reduceren. FIG. 12 tot FIG. 19 illustreren aan de hand van een vereenvoudigd voorbeeld, in meer detail de werkwijze voor het identificeren van de modules van een bussysteem volgens de onderhavige uitvinding. In het vereenvoudigd voorbeeld bestaat ieder identificatiebericht uit één frame van 5 bits, en bevat het frame een eerste gedeelte met de vooraf bepaalde sequentie "101" om aan te geven dat het bericht een identificatiebericht is, en bevat het frame verder 2 bits die overeenkomen met het uniek adres. In het voorbeeld van FIG. 12 tot FIG. 19 heeft module Dl uniek adres UA1="11", heeft module D2 uniek adres UA2="10" en heeft module D3 uniek adres UA3-O0".

Het voornaamste doel van FIG. 12 tot FIG. 19 is om het principe aan te tonen dat, zelfs wanneer alle modules, na het ontvangen van het identificatiecommando, tegelijkertijd starten met het verzenden van hun identificatiebericht met daarin hun uniek adres, dat in elke iteratie precies één module erin slaagt zijn uniek adres te versturen, zonder dat een boodschap verloren gaat.

In FIG. 12 stuurt de "GegevensVerzamelModule" een identificatieverzoek BO naar de "andere" deelnemers Dl, D2, D3 van het bussysteem, met het verzoek zich kenbaar te maken. Dit is een broadcast-commando bestemd voor alle "andere modules", ongeacht hun busadres(sen). (met "andere modules" wordt bedoeld alle modules behalve de "GegevensVerzamelModule" die het identificatieverzoek heeft verzonden). Dit bericht wordt ontvangen door de "andere" deelnemers Dl, D2, D3 zoals gesuggereerd door de pijltjes.

Het identificatieverzoek wordt gedecodeerd door elk van de modules Dl, D2, D3, en na een zekere wachttijd (gemeten vanaf het einde van de laatste bit op de bus) zal elke "andere" module trachten zijn identificatiebericht te versturen dat zijn uniek adres bevat. Zo bevat het identificatiebericht BI dat verzonden zal worden door module Dl het uniek adres UA1, en bevat het identificatiebericht B2 dat verzonden zal worden door module D2 het uniek adres UA2, en bevat het identificatiebericht B3 dat verzonden zai worden door module D3 het uniek adres UA3.

In het voorbeeld van FIG. 13 starten de drie modules Dl, D2, D3 allemaal tegelijk met het versturen van hun bericht naar de bus. Voor zover als bekend bij de uitvinders is het alles behalve triviaal om een identificatieverzoek te versturen naar alle andere modules, wetende dat vervolgens alle modules nagenoeg tegelijkertijd zullen antwoorden. Integendeel, in de stand der techniek wordt er meestal alles aan gedaan om botsingen trachten te vermijden (Engels: "collision avoidance) bv. door er trachten voor te zorgen dat er geen twee modules tegelijkertijd zullen starten met zenden, laat staan dat er een commando zou gedefinieerd worden waarop alle modules (op één na) tegelijk zullen starten met zenden.

Bovendien lijkt er een vooroordeel te bestaan dat het wel mogelijk en praktisch doenbaar is om adressen van deelnemers te bepalen voor adressen met ten hoogste een 6-tal of een 8-tal bits, (desnoods door alle mogelijke adressen te proberen, en na te gaan of er iemand reageert), maar er lijkt een vooroordeel te bestaan dat het ondoenbaar is om "rechtstreeks" adressen op te vragen aan modules wanneer die adressen meer dan 10 bits bevatten, laat staan meer dan 20 bits of zelfs 32 bits, minstens in het vakgebied van gebouwautomatiseringssystemen.

De uitvinders van de onderhavige uitvinding gaan dus regelrecht in tegen het vooroordeel dat het niet mogelijk of niet praktisch doenbaar zou zijn om adressen op te vragen met meer dan pakweg 10 bits, en tegen de gangbare opinie dat botsingen ten allen prijze moeten vermeden worden, en doen precies het omgekeerde, want idealiter (als alle modules perfect synchroon zouden lopen), zullen alle "andere" modules op het precies hetzelfde moment starten met het verzenden van hun identificatiebericht. Inderdaad, in voorkeursuitvoeringsvormen van de onderhavige uitvinding wordt er geen willekeurige (random) tijd gewacht door de verschillende modules na het ontvangen van het identificatieverzoek, maar starten ze allemaal na eenzelfde vooraf bepaalde tijd WJD die minstens gelijk is aan 1,5 bitperiode (in het voorbeeld van FIG. 10, dus minstens 225 ps), of minstens 2,0 bitperiodes, of minstens 2,5 bitperiodes, of minstens 3,0 bitperiodes, of minstens 5,0 bitperiodes, of minstens 10 bitperiodes (in het voorbeeld 1,50 ms), bv. 2,10 ms na de laatste bit van het identificatieverzoek. De tolerantie op de genoemde timing is afhankelijk van de implementatie, en is typisch een waarde tussen 1 interne klokperiode van de module en 1 bitperiode of de bus, en ligt typisch in het bereik van ongeveer 16,6 ns tot ongeveer 250 ns, overeenkomstig een interne klok van 4MHz tot 60MHz), maar de uitvinding is hiertoe niet beperkt, en de interne klok kan ook een frequentie hebben die groter is dan 60 MHz, bv. die in het bereik ligt van 60 MHz tot 2 GHz.

Aangezien eenzelfde formaat wordt gebruikt voor alle identificatieberichten BI, B2, B3, en aangezien de unieke adressen UA verschillend zijn, zal (indien er geen andere trafiek is over de bus) telkens precies één module erin slagen om zijn identificatiebericht "ongeschonden" over de bus te versturen, en zullen de andere modules een botsing op de bus vaststellen, waarna ze onmiddellijk de verzending van hun identificatiebericht afbreken, en zullen wachten tot de bus weer vrij is voor minstens de vooraf bepaalde periode WJD, waarna ze opnieuw zullen proberen hun identificatiebericht te versturen, net zolang tot alle identificatieberichten verstuurd zijn. Maar zelfs indien er wel andere trafiek is over de bus, dan nog zal ieder identificatiebericht precies één keer ongeschonden over de bus worden verstuurd, en de module kan zelf bepalen of dat gelukt is, en zal net zolang blijven proberen tot het gelukt is. Dit is een belangrijk onderliggend principe van deze werkwijze volgens de onderhavige uitvinding. FIG. 14 toont de golfvormen van de berichten BI, B2, B3 die de drie modules Dl, D2, en D3 respectievelijk willen versturen via hun bus-interface. In het voorbeeld zijn de eerste drie bits van de drie boodschappen gelijk (en geven aan dat dit bericht een "identificatiebericht" is). Pas bij het versturen van de vierde bit zal de module D3 een botsing vaststellen, omdat hij zelf een databitO-signal op de bus wil zetten, maar dat kan niet omdat de bus laag getrokken wordt door databitl van zowel module D2 als D3. Zodra module D3 de botsing detecteert, stopt hij met zenden, uiterlijk op het einde van de vierde bitperiode, maar liefst eerder. Module Dl en D2 merken geen botsing en gaan gewoon verder met het versturen van de vierde bit, en beginnen daarna aan het versturen van hun vijfde bit.

Tijdens het versturen van de vijfde bit detecteert de module D2 een botsing op de bus, en stopt met het verzenden van bericht B2. Module Dl detecteert geen conflict, en gaat verder met het versturen van zijn bericht BI, en concludeert na het versturen van alle bits van het bericht BI, dat hij daarin geslaagd is, en doet niet meer mee in de volgende iteratie. De modules D2 en D3 zijn er niet in geslaagd hun identificatiebericht (respectievelijk B2 en B3) te versturen, en zullen later opnieuw proberen, zoals getoond in FIG. 15 en FIG. 16.

Er wordt opgemerkt dat (volgens het protocol van een bussysteem volgens de onderhavige uitvinding) de GegevensVerzamelModule niet opnieuw een bericht zal versturen, maar dat de modules die er nog niet in geslaagd zijn hun identificatiebericht ongeschonden te versturen, vanzelf opnieuw zullen proberen hun identificatiebericht te versturen.

In FIG. 15 starten de overblijvende deelnemers D2 en D3 dus tegelijk met het verzenden van hun identificatiebericht, respectievelijk bericht B2 en bericht B3, terwijl de GegevensVerzamelModule luistert naar het bericht dat over de bus wordt verstuurd, zoals gesuggereerd door de pijltjes. Volledigheidshalve dient vermeld te worden dat module Dl eveneens het signaal dat op de bus wordt geplaatst zal ontvangen en zal decoderen, want alle modules moeten altijd luisteren naar de bus, maar de module Dl zal hieraan geen gevolg geven, omdat identificatieberichten bestemd zijn voor de GV. FIG. 16 toont de golfvormen van het bericht B2 en B3 dat de module D2 en D3 respectievelijk trachten te versturen via hun bus-interface, in een tweede poging om hun identificatiebericht te versturen. Op een gelijkaardige manier als hierboven beschreven zal de module D3 bij het versturen van de vierde bit een botsing op de bus detecteren, en stoppen met het verzenden van zijn bericht B3, zoals gesuggereerd door de stippellijn. In deze tweede iteratie zal module D2 erin slagen zijn bericht B2 ongeschonden te verzenden en besluiten niet langer deel te nemen aan de iteraties. Dus enkel module D3 blijft over.

In FIG. 17 stuurt de enig overblijvende module D3 het bericht B3 dat zijn uniek adres UA3 bevat, terwijl de GegevensVerzamelModule GV luistert naar het bericht dat over de bus wordt verstuurd zoals gesuggereerd door de pijltjes. De modules Dl en D2 zullen meeluisteren op de bus, en zullen de boodschap decoderen, maar zullen verder geen gevolg geven aan de boodschap B3 die verstuurd wordt door module D3, en bestemd is voor de GegevensVerzamelModule. FIG. 18 toont de golfvorm van het bericht B3 dat module D3 verstuurt via zijn bus-interface, als derde poging om zijn identificatiebericht te versturen, waarin hij ditmaal slaagt. FIG. 19 toont de totale golfvorm die wordt waargenomen op de bus na het versturen van het identificatieverzoek. De getoonde golfvorm is in feite een opeenvolging van de signalen van FIG. 14 (van tijdstip tl tot t2), gevolgd door een wachttijd WJD, dan de signalen van FIG. 16 (van tijdstip t3 tot tijdstip t4), wederom gevolgd door de wachttijd WJD, en tenslotte de signalen van FIG. 18 (van tijdstip t5 tot tijdstip t6).

Zoals hoger beschreven is in voorkeursuitvoeringsvormen van de onderhavige uitvinding de minimale wachttijd WJD om te antwoorden op het identificatieverzoek dezelfde voor alle modules, en dus niet gebaseerd op een willekeurige waarde, maar de uitvinding zal ook werken als de wachttijden verschillend zouden zijn.

In het voorbeeld van FIG. 19 hebben op tijdstip t6 alle "andere" modules Dl, D2 en D3 hun identificatiebericht verstuurd, en zal de bus "vrij" blijven na t6. Na het verstrijken van een vooraf bepaalde time-out waarde voor identificatieberichten TOJB, zal de GegevensVerzamelModule besluiten dat alle identificatieberichten BI, B2, B3 van alle andere modules Dl, D2, D3 ontvangen zijn. Deze time-out is bij voorkeur een factor 1,05 tot 2,00 groter dan WJD, bv. TOJB=2,25 ms, maar de uitvinding is daartoe niet beperkt.

In het voorbeeld van FIG. 12 tot FIG. 19 werd aangenomen dat er geen "normale" of "operationele" berichten over de bus werden verstuurd, maar mocht dat wel het geval zijn, dan zou bv. reeds een botsing vastgesteid kunnen worden in het eerste gedeelte "deell" van het bericht. De vakman zal begrijpen dat de keuze van het bitpatroon van de commando's, alsook de wachttijd tussen verschillende soorten berichten zullen bepalen welke berichten voorrang krijgen op andere berichten.

In voorkeursuitvoeringsvormen van de onderhavige uitvinding is het niet wenselijk dat de identificatieberichten voorrang krijgen op "normale" berichten, omdat dit de responstijd van het verlichttingssysteem of het gebouwautomatiseringssysteem zou verslechteren. Dit nadeel kan eenvoudig opgelost worden door een gepaste keuze van het bitpatroon van de identificatieberichten (in het voorbeeld van FIG. 12 tot FIG. 19 kan dit bv. bekomen worden door de waarde "000" toe te kennen aan het eerste gedeelte, dus als commando van de identificatieberichten), en/of door een gepaste keuze van de wachttijd WJD voor identificatieberichten te gebruiken (in het voorbeeld van FIG. 12 tot FIG. 19 kan dit bv. bekomen worden door de wachttijd WJD minstens 3,0 bitperiodes langer te kiezen dan de wachttijd voor "normale" berichten). Een combinatie is eveneens mogelijk. De vakman kan met de bijkomende inzichten verkregen uit dit document, een geschikte set van commando's en bijhorende bitpatronen vinden, desnoods proefondervindelijk. Dit hoeft niet verder toegelicht te worden.

Zoals reeds gezegd, zijn FIG. 12 tot FIG. 19 een sterk vereenvoudigde voorstelling van de situatie, en vooral bedoeld om het principe aan te tonen dat elke module (behalve de GV zelf) er uiteindelijk zal in slagen zijn identificatiebericht met zijn uniek adres op te sturen, en dat er geen berichten verloren gaan. De hierboven vermelde iteraties zijn dus geen "heruitzendingen" omdat een bericht verloren is gegaan, en dienen dus niet gezien te worden als "verloren tijd", maar eerder als "uitstel" omdat een ander bericht voorrang kreeg.

In voorkeursuitvoeringsvormen van de onderhavige uitvinding worden alle berichten over de bus, dus ook het identificatieverzoek en de identificatieberichten, verpakt in een frame-structuur bestaande uit één of meerdere frames van een vaste lengte, bv. de framestructuur zoals weergegeven in FIG. 20, en zal het uniek adres minstens 16 bits bevatten, of minstens 20 bits, of minstens 24 bits, of minstens 28 bits, of minstens 32 bits, of minstens 36 bits, of minstens 40 bits, of minstens 48 bits, verspreid over meerdere frames, bij voorkeur op elkaar volgende frames, maar de werkingsprincipes en voordelen blijven geldig. FIG. 20 toont een voorbeeldmatig tijdsdiagram van een bericht bestaande uit één enkel frame. In voorkeursuitvoeringsvormen van de onderhavige uitvinding bestaat één frame uit 18 tijdstots of bitperiodes. Elk tijdslot kan bijvoorbeeld 150 ps lang zijn, maar een andere waarde kan eveneens gebruikt worden, bv. een tijdslot in het bereik van 5 ps tot 1500 ps, of in het bereik van 8 ps tot 1500 ps, of in het bereik van 10 ps tot 1250 ps, of van 15 ps tot 1250 ps, of van 20 ps tot 1000 ps, of van 30 ps tot 750 ps, of van 50 ps tot 500 ps, of van 75 ps tot 300 ps, of van 100 ps tot 250 ps, bv. ongeveer gelijk aan 125 of 150 of 175 of 200 of 225 ps. De vakman kan een geschikte waarde vinden rekening houdend met bv. de stijg- en daaltijd van de signalen (voornamelijk bepaald door de busimpedantie en de waarde van de optrekweerstand of de uitgangsimpedantie van de optrekstroombron), robuustheid (bit-error-rate), en datasnelheid. De bitperiode "Tbit" moet dezelfde zijn voor alle modules die rechtstreeks (zie FIG. 4) of onrechtstreeks via een repeater zonder noemenswaardige vertraging (zie FIG. 5) aangesloten zijn op de communicatiebus, maar kan in principe verschillen van gebouw tot gebouw.

Het frame van FIG. 20 begint met een "startbit" met de logische waarde ”1", dan volgen 16 databits, en eindigt met een "stopbit" met de logische waarde "0". De ontvangers van de modules zullen steeds trachten deze frame-structuur van 18 bits te herkennen, en zuilen bit-sequenties die niet aan deze structuur voldoen, negeren. De verdere verwerking van de boodschap wordt bij voorkeur door de controller 301 (zie FIG. 3) uitgevoerd, op gekende manieren.

In bussystemen volgens de onderhavige uitvinding kan één bericht één of meerdere frames omvatten, bv. van 1 tot 20 frames, maar meer frames zijn eveneens mogeiijk. De combinatie van relatief korte frames (16 databits in plaats van 24) en één of meerdere frames per bericht, biedt het voordeel dat korte berichten efficiënt kunnen vestuurd worden, maar lange berichten eveneens mogelijk zijn, waardoor de functionaliteit van een bussysteem volgens de onderhavige uitvinding zeer uitgebreid kan zijn, veel ruimer bv. dan de beperkte functionaliteit geboden door een bussysteem met het DALI-protocol. Bussystemen volgens de onderhavige uitvinding zijn danook zeer geschikt om gebruikt te worden in een verlichtingsysteem of een gebouwautomatiseringssysteem. FIG. 21 toont een voorbeeldmatige bitsstructuur van het frame van FIG. 20. De precieze betekenis van iedere bit valt buiten het bestek van dit document, en is niet nodig om de onderhavige uitvinding te begrijpen.

Indien een bericht meerdere frames bevat, kunnen gekende technieken gebruikt worden om ervoor te zorgen dat de frames aan de ontvangstzijde correct samengevoegd worden, zoals bv. door het vermelden van het aantal frames in het eerste frame, en/of door het vermelden van een volgnummer in ieder frame, enz. FIG. 22 toont een voorbeeldmatig tijdsdiagram van een boodschap bestaande uit twee frames die na elkaar worden verstuurd, gescheiden door een wachttijd WT2F (afkorting voor wachttijd tussen twee frames van eenzelfde bericht).

Hoewel niet strikt noodzakelijk, worden frames van eenzelfde bericht bij voorkeur als een serie of als een trein verstuurd over de bus, wel met de nodige wachttijd WT2F tussen de frames, maar zonder tussenkomst van frames van andere berichten. Dit kan bv. bekomen worden door de wachttijd WT2F tussen frames van eenzelfde bericht kleiner te kiezen dan de wachttijd WT2B tussen twee "normale" berichten. FIG. 23 is een schematische weergave van de tijd nodig om een bericht bestaande uit drie frames te versturen. Na het derde frame moet de bus minstens gedurende WT2B (wat staat voor "wachttijd tussen twee berichten”) vrij zijn, dus eigenlijk neemt het bericht van drie frames in totaal 13,65 ms in beslag.

In de voorbeelden hierboven werden de volgende waarden gebruikt:

maar andere waarden zijn eveneens mogelijk, bv. waarden die voldoen aan de volgende set van voorwaarden:

Bij voorkeur is bovendien WT2F <= 100 x Tbit (11), al is dat niet strict noodzakelijk. FIG. 24 toont (op hoog-niveau) een werkwijze voor het identificeren van een veelheid van modules van een bussysteem, (bij voorkeur alle modules behalve de module die fungeert als GegevensVerzamelModule), volgens een uitvoeringsvorm van de onderhavige uitvinding.

In optionele stap 2401 wordt één van de modules aangeduid als GegevensVerzamelModule, of in stap 2402 wordt een module toegevoegd om te fungeren als GegevensVerzamelModule. De GV wordt bij voorkeur functioneel verbonden (bv. door middel van een elektrische kabel, bv. een RS232 kabel, een USB-kabel, een UTP-kabel, een FTP kabel, een Ethernet kabel, een coax kabel of een glasvezelkabel, of een ander soort netwerkkabel of draadloos, bv. via een infraroodverbinding, of een RF verbinding zoals Wifi of Bluetooth) met een gebruikersinrichting 401, 501, 601 (zoals in FIG. 4 tot FIG. 6), bv. een PC met een scherm 402, 502, 602 en met invoerorganen 403, 503, 603 zoals bv. een toetsenbord en/of een muis; of een smartphone, of een laptop, of dergelijke. De GV is voorzien om te communiceren met de gebruikersinrichting, bv. om opdrachten te ontvangen van de gebruikersinrichting, zoals het starten met opvragen van de unieke adressen, of het opvragen van bijkomende informatie van een module met een bepaald uniek adres, en voor het doorsturen van informatie naar de gebruikersinrichting.

In stap 2403 verstuurt de GegevensVerzamelModule een identificatieverzoek naar alle andere modules op de bus. Dit verzoek kan bv. geïnitieerd worden door een timer of een real-time-clock (bv. iedere nacht op een vooraf bepaald tijdstip, bv. om 24u00), of kan bv. geïnitieerd worden door een verzoek vanuit de gebruikersinrichting, of door het indrukken van een daartoe voorziene drukknop op de GegevensVerzamelModule (niet getoond), of op een andere geschikte manier.

In stap 2404 ontvangt de GegevensVerzamelModule een identificatiebericht van een module, met daarin het uniek adres van de betreffende module. Deze boodschap kan bv. tijdelijk of permanent opgeslagen worden in RAM van de GV, en/of in niet-vluchtig geheugen van de GV (bv. flash).

In stap 2405 gaat de GegevensVerzamelModule na of de bus langer dan een vooraf bepaalde time-out tijd TOJB vrij is, en indien dat het geval is, besluit de GegevensVerzamelModule dat alle identificatieberichten ontvangen zijn. Indien dat niet het geval is, worden stappen 2404 en 2405 opnieuw uitgevoerd, voor het ontvangen van bijkomende identificatieberichten.

In optionele stap 2406, kan de GegevensVerzamelModule de identificatieberichten verwerken (bv. door de Unieke Adressen eruit te halen), en/of als dusdanig doorsturen naar de gebruikersinrichting (bv. de PC). De PC kan deze unieke adressen eventueel opslaan in een gegevensbestand, en/of weergeven op een scherm.

In een alternatieve uitvoeringsvorm van de werkwijze, worden de unieke adressen niet pas verwerkt en/of verstuurd naar de gebruikersinrichting nadat ze allemaal aangekomen zijn bij de GegevensVerzamelModule, maar worden ze reeds tussentijds verwerkt en/of verstuurd, bv. als onderdeel van stap 2404.

Indien gewenst kan de gebruikersinrichting (bv. de PC) ook het uniek adres van de GegevensVerzamelModule opvragen, maar meestal is dat niet nodig. FIG. 25 is een schematische voorstelling van de werkwijze die wordt uitgevoerd door de GegevensVerzamelModule (linkerkant van FIG. 25), en de werkwijze die wordt uitgevoerd door elk van de "andere" modules (rechterkant van FIG. 25) van een bussysteem volgens de onderhavige uitvinding.

In stap 2501 verstuurt de GegevensVerzamelModule een identificatieverzoek op de bus. Deze stap is dezelfde als stap 2403 van FIG. 24.

In stap 2502 ontvangt iedere "andere" module het identificatieverzoek, waarna iedere "andere" module een identificatiebericht met daarin zijn uniek adres of uniek serienummer zal versturen. Dit gaat als volgt (stappen 2510):

In stap 2511 wacht iedere "andere" module tot de bus vrij is voor minstens een vooraf bepaalde periode W_ID (de "minimale wachttijd voor het versturen van het identificatiebericht")

In stap 2512 zal iedere "andere" module die er nog niet in geslaagd is zijn identificatiebericht correct te versturen, (in de eerste iteratie zijn dat alle andere modules), starten met het verzenden van zijn identificatiebericht, waarbij tijdens het verzenden van iedere bit wordt nagegaan (stap 2513) of er botsing optreedt, en indien er botsing wordt vastgesteld, dan stopt de module waarvan het te verzenden signaal afwijkt van het signaal op de bus onverwijld met zenden (stap 2514), en zal later opnieuw proberen door de stappen i) tot iii) opnieuw uit te voeren. Iedere module zal blijven proberen, totdat de module er uiteindelijk in geslaagd is zijn identificatiebericht ongeschonden te versturen.

Terwijl de modules hun identificatiebericht trachten te verzenden (stappen 2510) luistert de GegevensVerzamelModule naar de bus, en ontvangt in stap 2503 telkens één identificatiebericht, dat eventueel kan bestaan uit één of meerdere frames, zoals hoger toegelicht.

Indien de GegevensVerzamelModule vaststelt (stap 2504) dat de bus langer vrij is dan een vooraf bepaalde time-out waarde TOJB, dan gaat hij ervan uit dat alle identificatieberichten zijn ontvangen.

Hoewel niet getoond in FIG. 25 voeren de modules in parallel steeds een ontvangstroutine uit, waarbij ze het signaal van de bus decoderen, en indien het signaal bestemd is voor de betreffende module, voeren ze die opdracht ook uit, bv. door een bepaalde uitgang laag of hoog te zetten om een lamp aan of uit te schakelen, of om een relais te openen of te sluiten, of dergelijke.

Hoewel het hoofddoel van de GegevensVerzamelModule zoals hierin beschreven gericht is op het opvragen en ontvangen van de unieke adressen, en eventueel het opvragen van bijkomende informatie gebruik makend van absolute adressering, en de GegevensVerzamelModule na de ingebruikname van het verlichttingssysteem of gebouwautomatiseringssysteem in principe kan verwijderd worden, omdat ze niet nodig is voor de normale werking van het systeem, kan het handig zijn om deze toch in het gebouw achter te laten, en eventueel te gebruiken voor het monitoren van bustraffiek, bv. voor veiligheidsdoeleinden of voor visualisatie.

Samengevat, beschrijft de onderhavige uitvinding een bussysteem en een werkwijze volgens een bedrijfseigen protocol dat een speciale functie of broadcast-commando bevat, hierin "identificatieverzoek" genoemd, voor het opvragen van de unieke adressen van een veelheid van modules gekoppeld aan de communicatie-bus, en een functie voor het doorsturen van deze unieke adressen over de communicatie-bus, (hierin "identificatiebericht" genoemd). Éénmaal deze unieke adressen gekend zijn, kunnen de modules individueel benaderd worden door lees- en schrijfcommando's met absolute adressering. Het grote voordeel hiervan is dat deze lees- en/of schrijfopdrachten ook zullen werken, zelfs als het busadres (of de busadressen) in de module foutief of helemaal niet geprogrammeerd is/zijn.

Het opvragen van de unieke adressen verloopt razend snel. Stel bv. dat er 100 modules zijn, en dat elk identificatiebericht verstuurd wordt door middel van 4 frames. Met de hoger genoemde bitperiode van 150 ps, en frame-periode van 2,7 ms, en drie wachttijden WT2F van 1,80 ms, en een wachttijd W_ID van 1,95 ms tussen de berichten, bedraagt de totale tijd ongeveer: 100 x 18,15 ms = slechts ongeveer 1,8 seconden in totaal. En voor 1000 modules bedraagt de totale tijd voor het opvragen en ontvangen van alle unieke adressen slechts ongeveer 18,1 s.

Een bussysteem met modules die communiceren volgens dit protocol laat toe om de unieke adressen op te vragen, en vervolgens minstens sommige fouten en/of vergissingen die plaatsvonden tijdens de "commissioning" (de toekenning van busadressen) vanop afstand te corrigeren over de bus.

De digitale bedrade bus kan een totale lengte hebben van minstens 10 m, of minstens 20 m, of minstens 30 m of minstens 50 m. De afstand tussen de GegevensVerzamelModule en de interfacemodules kan groter zijn dan 10 m, of groter dan 20 m, of groter dan 30 m, of groter dan 50 m.

Claims (16)

1. Een werkwijze (2500) voor het identificeren van een veelheid van modules (Dl, D2, D3) die aan een bedrade communicatie-bus gekoppeld zijn en die elk een uniek adres (UA1, UA2, UA3) bevatten, door een GegevensVerzamelModule (GV) die eveneens aan de communicatie-bus gekoppeld is, waarbij de werkwijze de volgende stappen omvat: a) het versturen (2501) over de communicatie-bus van een identificatieverzoek (B0) door de GegevensVerzamelModule (GV) naar de veelheid van modules (Dl, D2, D3), voor het opvragen van hun unieke adressen (UA1, UA2, UA3); b) het ontvangen (2502) van het identificatieverzoek (BO) door elk van de veelheid van modules (Dl, D2, D3); c) het succesvol versturen (2510) van een identificatiebericht (BI, B2, B3) door elk van de veelheid van modules (Dl, D2, D3) als reactie op het ontvangen identificatieverzoek (B0), waarbij iedere identificatiebericht (BI, B2, B3) het uniek adres (UA1, UA2, UA3) van de betreffende module (Dl, D2, D3) bevat; waarbij stap c) voor ieder van de veelheid van modules (Dl, D2, D3) de volgende stappen omvat: i) het wachten (2511) tot de bus vrij is gedurende minstens een vooraf bepaalde tijd (WJD); ii) het trachten te verzenden (2512) van het identificatiebericht (BI, B2, B3) van de betreffende module, waarbij het trachten te verzenden (2512) van het identificatiebericht het achtereenvolgens trachten te verzenden van iedere bit van het identificatiebericht omvat, en waarbij het trachten te verzenden van iedere bit het aansturen en monitoren van de bus omvat, en het bepalen (2513) voor iedere bit of een botsing op de bus opgetreden is, iii) en indien een botsing opgetreden is, het stoppen (2514) met het verzenden van de betreffende bit en van alle volgende bits van het identificatiebericht, en het herhalen van stappen i) tot iii) totdat de identificatiebericht verzonden is zonder botsing; en indien geen botsing opgetreden is, besluiten dat het identificatiebericht (Bl, B2, B3) succesvol verzonden is, en niet meer deelnemen aan het trachten te verzenden van het identificatiebericht.

2. De werkwijze volgens conclusie 1, waarbij stap ii) van het trachten te verzenden (2512) wordt gestart van zodra de vooraf bepaalde tijd (WJD) verstreken is.

3. De werkwijze volgens conclusie 1 of 2, waarbij de communicatie-bus een digitale communicatie-bus is; en waarbij een eerste signaalvorm (101) wordt geassocieerd met een logische "l"-bit, en een tweede signaalvorm (102) verschillend van de eerste signaalvorm, wordt geassocieerd met een logische "O"-bit; en waarbij de GegevensVerzamelModule (GV) en de veelheid van modules (Dl, D2, D3) gekoppeld zijn aan de communicatie-bus in een wired-AND of een wired-OR configuratie.

4. Een werkwijze voor het toekennen van minstens één busadres (BA1) of minstens twee busadressen (BA3, BA4) aan een te configureren module (Dl; D3) van een veelheid van modules (Dl, D2, D3) die aan een bedrade communicatie-bus gekoppeld zijn, en die elk een uniek adres hebben (UA1, UA2, UA3), waarbij de werkwijze de volgende stappen omvat: a) het bepalen van de unieke adressen (UA1, UA2, UA3) van de veelheid van modules (Dl, D2, D3) die aan de bus gekoppeld zijn door het identificeren van de modules volgens één der voorgaande conclusies; b) het versturen van een configuratiebericht door de GegevensVerzamelModule (GV), waarbij het configuratiebericht het uniek adres (UA1; BA3, BA4) van de te configureren module (Dl; D3) bevat om de module te addresseren, alsook minstens één toe te kennen busadres (BAI; BA3, BA4); c) het ontvangen van het configuratiebericht door de veelheid van modules (Dl, D2, D3) die aan de bus gekoppeld zijn, en het extraheren van het adres (UA1; UA3) vervat in het configuratiebericht, en het vergelijken van het geëxtraheerde adres (UA1) met het interne unieke adres (UA1, UA2, UA3) van de betreffende module (Dl, D2, D3), en indien het geëxtraheerde adres (UA1) en het interne unieke adres gelijk zijn, verder gaan met stap d), en indien het geëxtraheerde adres (UA1) en het interne unieke adres verschillend zijn, stap d) overslaan; d) het extraheren van het minstens één busadres (BAI; BA3, BA4) uit het configuratiebericht, en het opslaan van het minstens één busadres (BAI; BA3, BA4) in een geheugen van de module (Dl; D3) voor latere communicatie met andere modules op basis van relatieve adressering.

5. Een werkwijze voor het opvragen van gegevens van minstens één te ondervragen module (Dl) gekozen uit een veelheid van modules (Dl, D2, D3) die aan een communicatie-bus gekoppeld zijn, en die elk een uniek adres (UA1, UA2, UA3) bevatten, omvattende: a) het bepalen van de unieke adressen (UA1, UA2, UA3) van elk van de veelheid van modules (Dl, D2, D3) die aan de bus gekoppeld zijn, door het identificeren van de modules volgens één der voorgaande conclusies; b) het versturen van een leesbericht door de GegevensVerzamelModule (GV), waarbij het leesbericht het unieke adres (UA1) van de te ondervragen module (Dl) bevat om de module te addresseren, alsook één of meer indicatoren over welke informatie opgevraagd wordt; c) het ontvangen van het leesbericht door de veelheid van modules (Dl, D2, D3) die aan de bus gekoppeld zijn, en het extraheren van het adres (UA1) vervat in het leesbericht, en het vergelijken van het geëxtraheerde adres (UA1) met het interne unieke adres (UA1, UA2, UA3) van de betreffende module (Dl, D2, D3), en indien het geëxtraheerde adres (UA1) en het interne unieke adres gelijk zijn, verder gaan met stap d), en indien het geëxtraheerde adres (UA1) en het interne unieke adres verschillend zijn, stap d) overslaan; d) het versturen van een informatiebericht door de te ondervragen module (Dl) naar de GegevensVerzamelModule (GV), waarbij het informatiebericht gegevens bevat overeenkomstig de één of meer indicatoren; e) het ontvangen van het informatiebericht door de GegevensVerzamelModule (GV).

6. Een werkwijze volgens één der voorgaande conclusies, waarbij het uniek adres van minstens één van de veelheid van modules (Dl, D2, D3) minstens 18 bits omvat, of minstens 20 bits, of minstens 24 bits, of minstens 32 bits, of minstens 40 bits, of minstens 48 bits.

7. Een werkwijze volgens één der voorgaande conclusies, waarbij alle berichten over de bus, met inbegrip van het identificatieverzoek en de identificatieberichten, verstuurd worden door het versturen van één of meerdere frames met een vaste lengte, waarbij ieder frame één startbit, zestien databits, en één stopbit bevat.

8. Een werkwijze volgens conclusie 7, waarbij een minimale wachttijd (WT2F) tussen twee opeenvolgende frames van eenzelfde bericht kleiner is dan een minimale wachttijd (WT2B) tussen frames van twee verschillende berichten.

9. Een werkwijze volgens conclusie 8, waarbij de minimale wachttijd (W_ID) voorafgaand aan een identicatiebericht groter is dan de minimale wachttijd (WT2B) voorafgaand aan een bericht dat geen identificatiebericht is.

10. Een bussysteem voor een gebouwautomatiseringssysteem, omvattende; - een bedrade communicatiebus; - een veelheid van modules (Dl, D2, D3) die elk een uniek adres (UA1, UA2, UA3) hebben en die gekoppeld zijn aan de communicatiebus; - een GegevensVerzamelModule (GV) die gekoppeld is aan de communicatiebus; waarbij elk van de veelheid van modules (Dl, D2, D3) en de GegevensVerzamelModule (GV) voorzien zijn om samen de werkwijze uit te voeren volgens één der conclusies 1-9.

11. Een gebouwautomatiseringssysteem dat een bussysteem volgens conclusie 10 omvat, en dat verder één of meer van de volgende kenmerken omvat: i) en waarbij het gebouwautomatiseringssysteem minstens een verlichtingssysteem omvat, waarbij minstens één van de modules aangepast is voor het aansturen van een verlichtingselement of een dimmer, en/of minstens één van de modules aangepast is voor het uitlezen van minstens één bewegingsdetector of aanwezigheidsdetector of lichtsensor of schakelaar; ii) en waarbij het gebouwautomatiseringssysteem minstens een zonneweringssysteem omvat, waarbij minstens één van de modules aangepast is voor het aansturen van minstens één motor van een zonnewering, en/of minstens één van de modules aangepast is voor het uitlezen van minstens één lichtsensor of schakelaar of windsensor; iii) en waarbij het gebouwautomatiseringssysteem minstens een branddetectiesysteem omvat, waarbij minstens één van de modules aangepast is voor het uitlezen van minstens één branddetector of rookdetector of temperatuursensor; iv) en waarbij het gebouwautomatiseringssysteem minstens een airconditioningsysteem omvat, waarbij minstens één van de modules aangepast is voor het aansturen van een airconditioningsmodule, en/of minstens één van de modules aangepast is voor het uitlezen van een temperatuursensor of vochtigheidssensor; v) en waarbij het gebouwautomatiseringssysteem minstens een verwarmingssysteem omvat, waarbij minstens één van de modules aangepast is voor aansturen van minstens één ventiel of een pomp of een verwarmingselement, en/of minstens één van de modules aangepast is voor het uitlezen van een temperatuursensor; vi) en waarbij het gebouwautomatiseringssysteem minstens een HVAC-systeem omvat, waarbij minstens één van de modules aangepast is voor het aansturen van een airconditioningsmodule of een verwarmingselement of een ventiel of een pomp, en/of minstens één van de modules aangepast is voor het uitlezen van een temperatuursensor of een vochtigheidssensor; vii) en waarbij het gebouwautomatiseringssysteem minstens een parkeergeleidingssysteem omvat, waarbij minstens één van de modules aangepast is voor het aansturen van minstens één verlichtingselement, en/of minstens één van de modules aangepast is voor het uitlezen van minstens één bewegingsdetector of aanwezigheidsdetector of schakelaar; viii) en waarbij het gebouwautomatiseringssysteem minstens een toegangscontrolesysteem omvat, waarbij minstens één van de modules aangepast is voor het aansturen van een deur of een toegang, en/of minstens één van de modules aangepast is voor het uitlezen van minstens één bewegingsdetector of aanwezigheidsdetector of schakelaar of identificatiemodule.

12. Een gebouwautomatiseringssysteem volgens conclusie 11, dat verder minstens één van de actuatoren en/of minstens één van de sensoren vernoemd in conclusie 11 omvat.

13. Een gebouwautomatiseringssysteem volgens conclusie 11 of 12, waarbij de bedrade bus minstens twee elektrische geleiders (BB, VO) omvat die galvanisch van elkaar gescheiden zijn, maar functioneel met elkaar gekoppeld zijn door middel van minstens één signaalversterker (Rl) met een optische koppeling, welke signaalversterker eveneens deel uitmaakt van het bussysteem.

14. Een set van minstens drie interface-modules voor gebruik in een bussysteem volgens conclusie 10, of voor gebruik in een gebouwautomatiseringssysteem volgens conclusie 11, waarbij één interface-module (GV) voorzien is voor het uitvoeren van stap a) van een werkwijze volgens één der conclusies 1 tot 9, en minstens twee andere interface-modules (Dl, D2) voorzien zijn voor het uitvoeren van de stappen b) en c) van de werkwijze volgens één der conclusies 1 tot 9.

15. Een set van minstens drie interface-modules volgens conclusie 14, waarbij minstens één der interface-modules (GV, Dl, D2) verder een IR-zendontvanger (306) omvat, en waarbij de controller (301) van de betreffende interface-module verder voorzien is van een IR-protocol software voor het zenden en ontvangen van boodschappen via de IR-zendontvanger; waarbij minstens één der interface-modules (GV, Dl, D2) verder een RF-zendontvanger (306) omvat, en waarbij de controller (301) van de betreffende interface-module verder voorzien is van een RF-protocol software voor het zenden en ontvangen van boodschappen via de RF-zendontvanger; waarbij minstens één der interface-modules (GV, Dl, D2) verder een glasvezel-zendontvanger omvat, en waarbij de controller (301) van de betreffende interface-module verder voorzien is van een protocol software voor het zenden en ontvangen van boodschappen via de glasvezel-zendontvanger; waarbij minstens één der interface-modules (GV, Dl, D2) verder een tweede bus-interface omvat, en waarbij de controller (301) van de betreffende interface-module voorzien is om zowel te communiceren over de eerste bus-interface via een eerste protocol volgens één der conclusies 1 tot 9, alsook via een tweede protocol dat verschillend is van het eerste protocol over de tweede bus-interface.

16. Een set van minstens drie interface-modules volgens conclusie 14 of 15, waarbij minstens één der interface-modules (GV, Dl, D2) verder minstens één ingebouwde actuator omvat voor het aansturen van een component van een gebouwautomatisering, en/of minstens één ingebouwde sensor of detector omvat voor het uitlezen van een component van een gebouwautomatisering.