NL2021582B1 - METHOD FOR IDENTIFYING MODULES LINKED TO A BUS SYSTEM, AND A BUILDING AUTOMATION SYSTEM - Google Patents

Abstract

A method (2500) for identifying a plurality of modules (D1, D2, D3) coupled to a wired communication bus and each containing a unique address (UA1, UA2, UA3) by a Data Collection Module (GV) which is also coupled to the communication bus, the method comprising the steps of: a) sending (2501) an identification request by the GV to the modules (D1-D3) to request their unique addresses; b) receiving (2502) the identification request from the modules (D1-D3); c) successfully sending (2510) an identification message through the modules (D1-D3) in response to the identification request, wherein each identification message contains the unique address of the relevant module. A method for configuring and interrogating the modules. A bus system, and a building automation system in which this method is used. A set of at least three interface modules (GV, D1, D2) that together perform this method.

Description

METHOD FOR IDENTIFYING MODULES LINKED TO A BUS SYSTEM, AND A BUILDING AUTOMATION SYSTEM

Domain of the invention

The present invention generally relates to a digital bus system such as can be used in a building automation system. The present invention relates more specifically to a method for identifying modules coupled to the bus system, and to a method for retrieving data from one or more modules of the bus system, and to a method for assigning a bus address to one or several modules of the bus system. The present invention also relates to such a building automation system, and a set of interface modules.

BACKGROUND OF THE INVENTION

Building automation systems are known in the art, and can for instance comprise one or more of the following subsystems: a lighting system, a sun protection system, a fire detection system, an air conditioning system, a heating system, an HVAC system, a parking control system, an access control system, etc. The subsystems can be implemented as separate systems, or as an integrated system.

Digital bus lighting systems in which lighting elements and / or switches and / or dimmers and the like function together in a functional manner are known in the prior art. A well-known bus system used for lighting applications is "DALI". DALI is an acronym and stands for "Digital Addressable Lighting Interface" (English) or "Digital Addressable Lighting Interface". It is an international standard intended for the interchangeability of dimmable ballasts from different manufacturers. The DALI interface is described in standard IEC 60929 under Appendix E. Interested readers who are not familiar with DALI can find an easily understandable introduction in the "DAU manual", published by "DALI AG (Digital Addressable Lighting Interface Activity Group) from ZVEI, Division Luminaires ", which dates from 2001. The main advantage over DALI is that over traditional fixed-wired lighting systems, it is possible to reconfigure the functionality of the lighting system without changing the wiring, eg by associating pressure switches with certain lighting elements in a different way .

Building automation systems with a digital bus, which may comprise such a lighting system, and / or other elements such as the control of sun blinds, air conditioning, etc., are also known in the prior art. A well-known bus system for building management applications is KNX. In fact, KNX is a system that specifies communication across different media, namely (a) KNX TP (abbreviation for "KNX Twisted Pair") where communication is carried out over a four-wire bus, (b) KNX PL (abbreviation for "KNX Powerline"), where a signal is superimposed on the 230V power cables in a building, (c) KNX RF (abbreviation for "KNX Radio Frequency") where wireless communication takes place, and (d) KNX IP (abbreviation for KNX Internet Protocol) where communication takes place over Ethernet. The KNX TP variant is the most relevant for the present invention. The reader who is not familiar with KNX can, for example, read the document [1] "The KNX standard - the basics" (20 pages), which can be downloaded at the time of drafting the present document via the following URL: http://www.knx.org/media/docs/Flyers/KNX-Basics/KNX-Basics_en.pdf.

In every bus system, certain "rules" are needed, better known as the "bus protocol", which all participants in the bus must adhere to. The protocol of a bus system describes aspects such as voltage levels, timing, frame structure, priorities, ways to detect collisions (English: "collision detection") and / or prevent collisions (English: "collision avoidance"), etc.

Before a lighting system according to DALI or a building automation system according to KNX can be put into operation, the necessary components (such as push buttons, lamps, sensors, actuators) must first be installed in the building, and via interface modules (whether or not built into the component) to be electrically coupled to the communication bus. Furthermore, these interface modules must be configured to interact with each other in a specific building in a specific building, by an action known as "commissioning". This includes, among other things, assigning local addresses to the various modules, which addresses are used during normal operation of the system to send messages from, for example, a light switch to an associated lamp. In DALI, for example, a 6-bit "bus address" is assigned to each component, and a 16-bit "group address" is assigned to KNX (more information can be found, for example, at URL: "https: // nl. wikipedia.org/wiki/KNX ")

In practice, the bus address or group address is assigned to the modules during the installation of the relevant module in the building, for example by making a physical connection between the relevant module and a portable computer via an RS232 connection, or as described above. said KNX document [1] (on page 18 column 4 to page 19 column 1, paragraph "Commissioning") by physically pressing a specially designed push button on the module and sending an "address" on the bus, wherein the module for which the said special push button was pressed, considers the address to be his. Of course, the system will only function correctly when it is put into operation if each module of the bus system has been assigned the correct address according to the plan (assuming the plan contains no errors).

However, human errors often occur with such an assignment, for example because one has forgotten to assign a bus address or group address to certain modules, or because an incorrect bus address or group address has been assigned (eg an address that was not provided on the plan ), or because the same address was mistakenly assigned to two different modules, etc. Such errors can be corrected afterwards, but it often takes a lot of time and effort to detect and correct them. This is a known problem (as confirmed by [1] biz 19 column 1 line 3). US 7606955 (B1) describes a wired bus system with a single master and 1 to 7 slaves connected to a so-called "open collector" architecture, where the bus is passively pulled to a high level via a resistor, and each of the participants the bus actively low. The protocol makes a distinction between, among other things, "data bits", a "reset" signal, and an "attention-request" signal from one of the slaves. In this system, therefore, each bus interface must detect four types of signals and respond accordingly. US8035529 (B2) describes a distributed ballast system with a protocol that is an extension to the DALI protocol, and that is backwards compatible with DALI, whereby 256 modules can be accessed (instead of only 64 with DALI), and where functionality can be added due to the longer instructions (3 bytes instead of just 2 bytes with DALI). The document does not describe in detail how the "initialization" 1 (English: commissioning) happens exactly, nor how any errors with this commissioning can be traced or corrected.

Summary of the invention

It is an object of the present invention to provide a bus system for a building automation system, and to provide a method for communicating in this bus system, and a building automation system with such a bus system, and a set of interface modules for use in such a bus system or such building automation system. .

More specifically, it is an object of the present invention to provide such a bus system and method that makes it possible to detect and / or correct errors (e.g. installation errors or more specifically errors in commissioning) faster or easier.

It is an object of the present invention to provide a method for identifying a plurality of bus system participants, and to provide a bus system with a bus protocol that supports such method.

It is an object of certain embodiments of the present invention to provide a method for querying data from one or more participants of the bus system, and to provide a bus system with a bus protocol that supports such a method.

It is an object of certain embodiments of the present invention to provide a method for configuring and / or reconfiguring one or more participants of the bus system, and to provide a bus system with a bus protocol that supports such a method.

According to a first aspect, the present invention provides a method for identifying a plurality of modules that are coupled to a wired communication bus and that each contain a unique address, by a Data Collection Module that is also coupled to the communication bus, wherein the method comprises the following steps: a) sending over the communication bus an identification request through the Data Collection Module to the plurality of modules, to request their unique addresses; b) receiving the identification request by each of the plurality of modules; c) successfully sending an identification message through each of the plurality of modules in response to the received identification request, each identification message containing the unique address of the relevant module; wherein step c) comprises for each of the plurality of modules the following steps: i) waiting for the bus to be free for at least a predetermined time; ii) trying to send the identification message of the relevant module, wherein trying to send the identification message comprises sequentially trying to send each bit of the identification message, and wherein trying to send each bit is controlling and monitoring the bus, and determining whether a collision has occurred on the bus; iii) and if a collision has occurred, stopping sending the relevant bit and all subsequent bits of the identification message, and repeating steps i) to iii) until the identification message is sent without collision; and if no collision has occurred, decide that the identification message has been successfully sent, and no longer participate in trying to send the identification message.

By "successful sending" it is meant that each module will continue to try to send its identification message until this is finally successful. This is guaranteed to work because every message is unique and because no messages are lost.

Briefly summarized, this method makes it possible to request the unique addresses of all modules that are connected to the communication bus in-situ. Once these unique addresses are known, they can be used to access specific modules individually, for example to request information, or to send information to the module, for example using absolute addressing.

It makes it possible for errors to be detected and even corrected more quickly, in particular errors related to the non-assignment or incorrect assignment of one or more bus addresses to the modules during installation ("commissioning"), for example by individualizing the modules one by one approach using absolute addressing commands based on the unique addresses thus obtained.

Moreover, the query itself can be carried out relatively quickly, even while the lighting system or building automation system can continue to work.

It is an advantage of this method that all unique addresses of all modules that are effectively connected to the bus (except that of the GV) can be automatically retrieved without human intervention, thereby excluding the risk of human error.

By requesting the unique addresses (which are already built into the modules during the production of the modules), all modules are unambiguously "discovered", even if no or an incorrect bus address was assigned to the module during installation (commissioning) ).

It is a great advantage that the method provides that only a single identification request will be sent, to which each of the other modules will respond, if necessary in multiple attempts, until it is ultimately successful. Because the GV will only send one message on the bus, a lot of time is saved.

It is a great advantage that the method is provided in such a way that, in principle, (unless "normal messages" intervene) exactly one identification message will be sent on the bus undamaged at every iteration.

Thanks to the collision detection at bit level and, if necessary, stopping sending, and automatically retrying when the bus is free for a sufficient length of time, no messages are lost, so no time is lost on the bus due to corrupted (English: corrupted) data and retransmissions. This means an important time saving.

It is a major advantage of this method that it can even be implemented in an operationally active bus system, which means that the building automation system or subsystem (eg lighting system, sun protection system, fire detection system, etc.) of which this bus system forms part , will continue to work while this address query is taking place. Moreover, this can happen with a not or hardly noticeable delay of "normal commands" such as switching on light elements, reading out fire detectors, etc.

It is a great advantage that this method can be carried out very quickly (e.g., 1.85 second order for a 150 ps bit period and a bus with 100 participants, and a unique 32-bit address, assuming the bus is not operational) charged). Such a short period of time is unseen, and its benefit should not be underestimated.

In one embodiment, step ii) of attempting to send is started as soon as the predetermined time "WJD" has elapsed.

In this embodiment, all modules wait in principle the same amount of time (except for tolerances of the local clock). Therefore, no use is made of random ("random") waiting times or the like for attempting to avoid collisions, quite the contrary. In this embodiment, all modules will thus start transmitting almost simultaneously, in other words, the chance of collisions is, as it were, maximized instead of minimized in this embodiment.

In one embodiment, the communication bus is a digital communication bus; and a first signal form is associated with a logical "1" bit, and a second signal form different from the first signal form is associated with a logical "0"bit; and the Data Collection Module and the plurality of modules are linked to the communication bus in a wired-AND or a wired-OR configuration.

Preferably the bus is pulled high by a (relatively large) pull-up resistor or by a (relatively weak) current source, and the bus can be pulled low by means of a (relatively strong) transistor configured as "open collector" or as "open collector" drain "(which means that it acts as an ON-OFF switch, with a very low impedance when the switch is closed, and with a very high impedance when the switch is open). In such a configuration, a low voltage level wins over a high voltage level. Depending on the signal form associated with a logical "1" or a logical "0", a logical "1" beats a logical "0", in which case the bus is called a "wired-OR" (as in the example of FIG. 3). In the reverse case, where a logical "0" beats a logical "1", the bus configuration is called a "wired-AND" configuration.

According to a second aspect, the present invention provides a method for assigning at least one bus address or at least two bus addresses to a module to be configured from a plurality of modules that are coupled to a wired communication bus and that each have a unique address, the method comprising the steps of: a) determining the unique addresses of the plurality of modules coupled to the bus by identifying the modules according to the first aspect; b) sending a configuration message by the Data Collection Module, wherein the configuration message contains the unique address of the module to be configured to address the module, as well as at least one bus address to be assigned; c) receiving the configuration message by the plurality of modules coupled to the bus, and extracting the address contained in the configuration message, and comparing the extracted address with the internal unique address of the relevant module, and if the extracted address and the internal unique address are the same, proceed to step d), and if the extracted address and the internal unique address are different, skip step d); d) extracting the at least one bus address from the configuration message, and storing the at least one bus address in a memory of the module for later communication with other modules based on relative addressing.

Steps b) and c) actually mean that absolute addressing is used, based on the unique address of the module requested in step a).

This method makes it possible to remotely assign one or more bus address (s) to a specific module, without the need for physical access to the module. This method also makes it possible to change the bus address remotely.

According to a third aspect, the present invention provides a method for querying data from at least one module to be queried selected from a plurality of modules that are coupled to a communication bus, and each containing a unique address, comprising: a) the determining the unique addresses of each of the plurality of modules coupled to the bus, by identifying the modules according to the first aspect; b) sending a reading message by the Data Collection Module, wherein the reading message contains the unique address of the module to be interrogated to address the module, as well as one or more indicators of which information is requested; c) receiving the read message from the plurality of modules coupled to the bus, and extracting the address contained in the read message, and comparing the extracted address with the internal unique address of the relevant module, and if the extracted address and the internal unique address are the same, proceed to step d), and if the extracted address and the internal unique address are different, skip step d); d) sending an information message by the module to be interrogated to the Data Collection Module, the information message containing data in accordance with the one or more indicators; e) receiving the information message by the Data Collection Module.

This method offers the advantage that information can be retrieved about a specific module by addressing this module with its unique address. By retrieving additional information, e.g. the type of the module, or the bus address (s) stored therein, it is possible to detect errors related to the assignment of the bus address (s).

It is noted that the information message is intended for the GV, and that it can therefore be implemented as a "command", without the addressee having to add an address.

In a further embodiment of a method according to the first, second or third aspect, the unique address of at least one of the plurality of modules (D1, D2, D3) comprises at least 18 bits, or at least 20 bits, or at least 24 bits, or at least 32 bits, or at least 40 bits, or at least 48 bits.

According to certain standards, the units on the bus have a maximum of 6 address bits, and therefore a maximum of 64 units on the bus can be distinguished. In such systems it is perfectly possible to do the recognition of the units present by trying all possible addresses and checking if there is a reaction. However, this so-called "brute force" method is not suitable when the number of address bits becomes very large. After all, for each additional bit, the time required to try all addresses doubles.

In a further embodiment of a method according to the first, second or third aspect, all messages on the bus, including the identification request and the identification messages, are sent by sending one or more fixed-length frames, each frame having one start bit, sixteen data bits, and one stop bit.

It is an advantage that all communication on the bus uses the same frame structure. This can simplify the implementation.

In a further embodiment, a minimum wait time WT2F between two consecutive frames of the same message is smaller than a minimum wait time WT2B between frames of two different messages.

The minimum waiting times are part of the protocol according to which communication is via the bus. This means that when a particular module is sending a message that contains multiple frames, the train of frames will not be interrupted by another message. This can simplify the implementation.

In a further embodiment, the minimum wait time WJD before an identification message is greater than the minimum wait time WT2B before a message that is not an identification message.

This is a way to ensure that "normal messages" or "operational messages", such as communication between components of a lighting system or of another subsystem of a building automation system, are given priority over identification messages from the modules to the Data Collection Module.

According to a fourth aspect, the present invention provides a bus system for a building automation system, comprising: - a wired communication bus; - a plurality of modules that each have a unique address and that are linked to the communication bus; a Data Collection Module that is linked to the communication bus; wherein each of the plurality of modules and the Data Collection Module are provided for compiling a method according to the first, second or third aspect.

The wired communication bus preferably comprises at least one or at least two electrical conductors.

According to a fifth aspect, the present invention provides a building automation system comprising a bus system according to the fourth aspect, and further comprising one or more of the following features: i) and wherein the building automation system comprises at least one lighting system, at least one of the modules being adapted for controlling a lighting element or a dimmer, and / or at least one of the modules is adapted to read out at least one motion detector or presence detector or light sensor or switch; ii) and wherein the building automation system comprises at least one sun protection system, wherein at least one of the modules is adapted to control at least one motor of a sun protection, and / or at least one of the modules is adapted to read out at least one light sensor or switch or wind sensor; iii) and wherein the building automation system comprises at least one fire detection system, wherein at least one of the modules is adapted to read out at least one fire detector or smoke detector or temperature sensor; iv) and wherein the building automation system comprises at least one air conditioning system, wherein at least one of the modules is adapted to control an air conditioning module, and / or at least one of the modules is adapted to read out a temperature sensor or humidity sensor; v) and wherein the building automation system comprises at least one heating system, wherein at least one of the modules is adapted to control at least one valve or a pump or a heating element, and / or at least one of the modules is adapted for reading a temperature sensor; vi) and wherein the building automation system comprises at least one HVAC system, wherein at least one of the modules is adapted to control an air conditioning module or a heating element or a valve or a pump, and / or at least one of the modules is adapted for reading out of a temperature sensor or a humidity sensor; vii) and wherein the building automation system comprises at least one parking guidance system, wherein at least one of the modules is adapted to control at least one lighting element, and / or at least one of the modules is adapted to read out at least one motion detector or presence detector or switch; viii) and wherein the building automation system comprises at least one access control system, wherein at least one of the modules is adapted to control a door or an access, and / or at least one of the modules is adapted to read out at least one motion detector or presence detector or switch or identification module.

In one embodiment, the building automation system further comprises at least one of the above-mentioned actuators and / or at least one of the above-mentioned sensors.

In one embodiment, the wired bus comprises at least two electrical conductors which are galvanically isolated from each other, but which are functionally coupled to each other by means of at least one signal amplifier with an optical coupling, which signal amplifier also forms part of the bus system.

According to a sixth aspect, the present invention also provides a set of at least three interface modules for use in a bus system according to the fourth aspect, or for use in a building automation system according to the fifth aspect, wherein one interface module is provided for performing step a) provided with a method according to the first, second or third aspect, and at least two other interface modules are provided for performing steps b) and c) of the method according to the first, second or third aspect.

In one embodiment, at least one of the interface modules further comprises an IR transceiver, and the controller of the interface module in question is further provided with an IR protocol software for sending and receiving messages via the IR transceiver.

In one embodiment, at least one of the interface modules further comprises an RF transceiver, and the controller of the relevant interface module is further provided with an RF protocol software for sending and receiving messages via the RF transceiver.

In one embodiment, at least one of the interface modules further comprises a fiber optic transceiver, and the controller of the relevant interface module is further provided with a fiber optic protocol software for sending and receiving messages via the fiber optic transceiver.

In one embodiment, at least one of the interface modules further comprises a second bus interface, and the controller of the relevant interface module is provided for both communicating over the first bus interface via a first protocol according to the first, second or third aspect , as well as via a second protocol that is different from the first protocol over the second bus interface.

In one embodiment, at least one of the interface modules further comprises at least one built-in actuator for controlling a component of a building automation, and / or at least one built-in sensor or detector for reading out a component of a building automation.

Specific and preferred aspects of the invention are included in the appended independent and dependent claims. Features of the dependent claims can be combined with features of the independent claims and with features of other dependent claims as appropriate and not merely as explicitly stated in the claims.

To summarize the invention and the advantages achieved over the prior art, certain objects and advantages of the invention have been described above. It is, of course, understood that not all of these objectives or advantages can be achieved by any specific embodiment of the invention. Thus, for example, those skilled in the art will recognize that the invention may be embodied or implemented in a manner that has one benefit or a group of benefits as provided herein, without necessarily achieving other objectives or benefits that may be offered or suggested herein.

These and other aspects of the invention will be apparent from and clarified with reference to the embodiment (s) described below.

Brief description of the figures

The invention will now be further described, by way of example, with reference to the accompanying drawings in which: FIG. 1 is a replica of FIG. 1 of US8035529 (B2), and shows an example of a prior art ballast system based on the DALI protocol. FIG. 2 is a replica of FIG. 2A of US 7606955 (B1), and shows an example of a bus system with a master-slave architecture, where the bus is passively pulled high by a pull-up resistor, and the participants of the bus have a bus interface with a so-called "open collector" or a so-called "open drain" to actively lower the can if desired. FIG. 3 is an exemplary block diagram of a participant of the bus according to the present invention, hereinafter also referred to as "interface module" or simply "module". FIG. 4 is a schematic representation of an exemplary bus system and building automation system according to the present invention. FIG. 5 is a schematic representation of a second exemplary bus system and building automation system according to the present invention wherein the digital bus comprises a backbone and two physical conductors. FIG. 6 is a schematic representation of a third exemplary bus system and building automation system according to the present invention, as a variant of the bus system of FIG. 5, further comprising signal amplifiers. FIG. 7 to FIG. 9 show some examples of wired buses known in the art. Bus systems according to the present invention can be used with any of the wired buses shown in FIG. 7 to FIG. 9, but don't have to. FIG. 7 shows an example of a two-wire bus with two conductors, one conductor serving as a reference (ground), and the other conductor being used for data transfer, but not for feeding other modules. FIG. 8 shows an example of a three-wire bus with three conductors, one conductor serving as reference (ground), a second conductor being used for data transfer, and a third conductor being used to feed at least one participant of the bus. FIG. 9 shows an example of a two-wire bus with two conductors, one conductor serving as a reference (ground), and the other conductor being used for both data transfer and for feeding at least one participant of the bus. FIG. 10 shows two exemplary waveforms that can be used by embodiments of the present invention to transmit a logic bit "1" and a logic bit "0", or vice versa. FIG. 11 shows two other exemplary waveforms that can be used by embodiments of the present invention to transmit a logic bit "1" and a logic bit "0", known as "Manchester" coding. FIG. 12 to FIG. 19 illustrate, on the basis of a simplified example, a method for identifying a plurality of identifiable modules of a bus system according to the present invention, wherein one module was added to the bus system to act as "Data Collection Module".

In FIG. 12, the "Data Collection Module" sends a special identification request to the modules to be identified, with the request to send their unique address on the bus.

In FIG. 13 all participants of the bus (except the Data Collection Module) begin sending an identification message containing their unique address almost simultaneously, while the Data Collection Module receives the identification message sent over the bus. FIG. 14 shows the waveforms that the three participants try to send via their bus interface, in which only participant D1 succeeds, at least in the first attempt.

In FIG. 15, the remaining participants D2 and D3 simultaneously begin to send an identification message containing their unique address, while the "Data Collection Module" receives the identification message sent over the bus. FIG. 16 shows the waveforms that the two remaining participants D2 and D3 attempt to send via their bus interface, as a second attempt to send their unique address, in which only participant D2 succeeds.

In FIG. 17, the only remaining participant D3 begins to send a message containing its unique address, while the Data Collection Module receives the identification message sent over the bus. FIG. 18 shows the waveform of the identification message that participant D3 sends through his bus interface, as a third attempt to send his unique address, which he succeeds this time. FIG. 19 shows the waveform observed on the bus. FIG. 20 to FIG. 23 show an exemplary message structure with one or more frames that can be used by a bus system and by methods according to the present invention. FIG. 20 shows an exemplary time diagram of a message consisting of a single frame. FIG. 21 shows an exemplary bit structure of this one frame. FIG. 22 shows an exemplary time diagram of a message consisting of two frames sent one after the other, separated by a waiting time. FIG. 23 is a schematic representation of a message consisting of three frames. FIG. 24 shows a method for identifying a plurality of participants in the bus system, according to an embodiment of the present invention. FIG. 25 shows the method of FIG. 24, including steps performed by the plurality of identifiable modules of the bus.

The figures are only schematic and non-limiting. In the figures, the dimensions of some parts may be exaggerated and not represented to scale for illustrative purposes. The dimensions and the relative dimensions sometimes do not correspond to the current practical embodiment of the invention.

Reference numbers in the claims may not be interpreted to limit the scope of protection.

In the various figures, the same reference numbers refer to the same or similar elements.

Detailed description of embodiments of the invention

The present invention will be described with reference to particular embodiments and with reference to certain drawings, however, the invention is not limited thereto, but is only limited by the claims.

It is to be noted that the term "comprises", as used in the claims, is not to be interpreted as being limited to the means described thereafter; this term does not exclude other elements or steps. It can therefore be interpreted as specifying the presence of the listed features, values, steps or components referred to, but does not exclude the presence or addition of one or more other features, values, steps or components, or groups thereof. Thus, the scope of the expression "a device comprising means A and B" should not be limited to devices that consist only of components A and B. It means that with regard to the present invention, A and B are the only relevant components of the device.

Reference throughout this specification to "one embodiment" or "an embodiment" means that a specific feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, occurrence of the expressions "in one embodiment" or "in an embodiment" at various places throughout this specification may not necessarily all refer to the same embodiment, but may do so. Furthermore, the specific features, structures, or characteristics may be combined in any suitable manner, as would be apparent to those skilled in the art based on this disclosure, in one or more embodiments.

Similarly, it should be appreciated that in the description of exemplary embodiments of the invention, various features of the invention are sometimes grouped together into a single embodiment, figure, or description thereof for the purpose of streamlining disclosure and assisting in understanding one or several of the various inventive aspects. This method of disclosure should not be interpreted in any way as a reflection of an intention that the invention requires more features than explicitly mentioned in each claim. The claims following the detailed description are hereby explicitly included in this detailed description, with each independent claim as a separate embodiment of the present invention.

Furthermore, while some embodiments described herein include some, but not other, features included in other embodiments, combinations of features of different embodiments are intended to be within the scope of the invention, and constitute different embodiments, as would be understood by those skilled in the art . For example, in the following claims, any of the described embodiments can be used in any combination.

Numerous specific details are set forth in the description provided here. It is, however, understood that embodiments of the invention can be practiced without these specific details. In other cases, well-known methods, structures and techniques have not been shown in detail to keep this description clear.

In the present invention, the term "message" and "message" is used as a synonym.

In the present invention, the terms "soil" and "mass" are used as synonyms.

In the present invention, the term "communication bus" or simply "bus" refers to a wired bus with at least two electrical conductors, or a wired bus with one electrical conductor and a ground.

In the present invention, the terms "participant of the bus" or simply "participant", and "interface module" or simply "module" are used as synonyms. They refer to a device that comprises at least one control unit (e.g., a programmable processor) and a bus interface for sending and receiving messages over the communication bus. In the context of the present invention, the module can be a read-out module (for reading one or more sensors), or a control module (for controlling one or more actuators), or a combination of both a read-out module and a control module.

In the present invention, "identification request" means a specific or proprietary (English: "proprietary") message sent by one of the modules, namely the module that acts as "Data Collection Module" (hereinafter abbreviated as GV), in the form of a broadcast command to the other modules of the bus (ie the plurality of modules to be identified) with the request (or command) to make their "unique address" known on the bus.

In the present invention, the term "absolutely unique address" or "unique address" refers to an address or serial number that is usually assigned to the interface module in question during production of the interface module, and that is no longer changed thereafter, and whose value is unique (ie occurs only once) regardless of the bus in which this module is used. This unique address contains at least 17 bits, or at least 20 bits, or at least 24 bits, or at least 28 bits, or at least 32 bits, or at least 40 bits, or at least 48 bits.

In the present invention, the term "bus address" refers to an address that has fewer bits than the absolutely unique address, and that is assigned to an "interface module" after production, (e.g., during so-called "commissioning") to communicate more efficiently on the communication bus. This is the address that is usually used during the normal operation of the bus system, and with which components communicate with each other.

In embodiments of the present invention, an "interface module" may have more than one bus address, e.g., one bus address for each input and each output of the "interface module" (as will be further explained in FIG. 3).

In the present invention, the term "identification message" is used to refer to a specific and proprietary message sent by each of the remaining modules (i.e., the modules to be identified) in response to the "identification request".

In this document the term "component" is used to refer to devices such as, for example, push buttons, door locks, presence sensors, motion sensors, wind sensors, temperature sensors, lamps, relays, air conditioning, fire detectors, smoke detectors, HVAC, sirens, heating elements, spray systems, etc. , which are part of a lighting system or a building automation system.

In this document, "component" and "interface module" are considered as separate devices, but it is of course also possible to group both devices into one device, which is also referred to herein as "interface module" or "module".

In this document, "normal operation" or "normal messages" or "operational messages" refers to messages sent on the bus during the normal operation of the system, for example, between a sensor and an associated actuator. the RR and the "identification messages" sent by the other modules are not considered "operational messages".

The present invention relates to a digital bus system such as can be used, for example, in a lighting system or a building automation system, and to methods of communicating about such a bus system, including a method of identifying a plurality of participants of a bus system, e.g. all "interface modules" linked to the bus system except the Data Collection Module.

As already indicated in the background section, there are various bus systems for buildings, such as a bus system according to the DALI protocol for controlling a lighting system, or a bus system according to the KNX protocol for controlling a building automation system with "components" that are usually classified in two categories: sensors (or detectors) and actuators, but other components are also possible, such as clocks or logical building blocks. The group of sensors includes: switches, push buttons, presence detectors, temperature sensors, etc. The group of actuators includes relays, sun blinds, air-conditioning, etc. These "components" are connected to the digital bus via an "interface" module "(hereinafter also referred to simply as" module ") which acts as a bus participant.

The architecture of the interface modules (see, for example, FIG. 3) may differ depending on the type of component that is connected to it (eg controlling a lamp or a relay requires functionality other than reading a push button), but all they have a bus interface 303 and a controller 301 (e.g. a programmable processor), and they are provided for sending and receiving messages according to a certain protocol. The protocol that will be described herein is a proprietary protocol (English: "proprietary protocol"), which is part of the bus system of the present invention.

Designers of a lighting system or of a building automation system must therefore choose "components" and "interface modules", and installers must place these in the building and connect them according to a predetermined plan. As described in the background section, the installer assigns at least one bus address to each module, referring to the address assigned to each module during commissioning, and with which the components communicate with each other during normal operation of the lighting system or the building automation system, and which has fewer bits than the absolutely unique address.

In certain embodiments of the present invention, some interface modules are assigned at least two, or at least three, or at least four bus addresses, namely, one bus address for each input and output. In the specific example of FIG. 3, for example, five bus addresses would be assigned to the module 300 shown, namely two for the inputs IN1, IN2, and three for the outputs OUT1, OUT2, OUT3.

In practice it has been found that installing and assembling and connecting the components (which requires actions such as drilling, screwing, pulling cables, loosening false ceiling, removing insulation, etc.) is a very different task than assigning an address to a module, and totally different equipment is required. It is therefore not surprising that human errors often occur with such an address assignment, such as forgetting to assign an address to one or more modules, or assigning a wrong address, or assigning the same bus address by mistake. to two different modules, etc.

It often takes a lot of time and effort to detect and correct all errors, especially when the modules are installed in a false ceiling or in a cavity in a wall, or in a room that is locked.

This problem is all the more difficult when the building is already in use, and also occurs, for example, when modules are added to an existing building. It will be clear that it is not possible to interrupt the lighting or the air conditioning or the heating or the like of the entire building for a long time (for example several hours) to detect and / or correct an error. The existing system must continue to work.

Faced with this problem, and looking for a solution to detect and / or correct the errors faster and / or easier, and taking into account the precondition that the system (eg lighting system or building automation system in which it is used) must continue to work, the inventors of the present invention came up with the idea of providing a method for identifying a plurality of modules coupled to a communication bus by retrieving the unique addresses UA1, UA2, UA3 of the plurality of identifiable modules, and which comprises the following steps: (as illustrated in FIG. 24, FIG. 25 and FIG. 12 to FIG. 17) a) sending over the communication bus an identification request BO through the Data Collection Module GV to the plurality of modules D1, D2, D3, for requesting the unique address UA1, UA2, UA3 of these modules; b) receiving the identification request BO by each of the plurality of modules D1, D2, D3; c) successfully sending an identification message B1, B2, B3 by each of the plurality of modules D1, D2, D3 in response to the received identification request BO, each identification message B1, B2, B3 having the unique address UA1, UA2, UA3 of the module in question comprises, wherein step c) comprises the following steps for each of the plurality of modules D1, D2, D3: i) waiting for the bus to be free for at least a predetermined time W_ID; ii) trying to send the identification message B1, B2, B3 of the relevant module, wherein trying to send the identification message comprises sequentially trying to send each bit of the identification message, and wherein trying to send each bit is the comprises controlling and monitoring the communication bus, and determining whether a collision has occurred on the communication bus, iii) and if a collision has occurred, stopping the transmission of the relevant bit and of all subsequent bits of the identification message and repeating steps i) to iii) until the identification message is sent without collision; and if no collision has occurred, decide that the identification message B1, B2, B3 has been successfully sent, and no longer participate in trying to send the identification message.

By "sending successfully" is meant that each module will continue to try to send its identification message until it is successful.

It is an advantage of this method that all unique addresses of all modules that are effectively connected to the bus (except that of the GV, but the GV usually hangs directly on a PC, and can therefore be accessed directly) can be automatically retrieved without human intervention, which excludes the risk of human error. By requesting the unique addresses (which are already built into the modules during the production of the modules), all modules are unambiguously "discovered", regardless of whether the at least one provided bus address was correctly assigned to the module during installation.

It is a great advantage that the protocol (and therefore also methods that operate according to this protocol, and therefore also bus systems to which devices that perform these methods are linked) provides that only one single identification request will be sent, on which each of the other modules will answers, if necessary in multiple attempts, until it is finally achieved. Because the GV will only send one message on the bus, a lot of time is saved.

It is a great advantage that the protocol is provided in such a way that (in principle, unless "normal messages" come through), exactly one identification message will be sent on the bus undamaged at every iteration. This is mainly due to the fact that the modules will stop transmitting immediately after the detection of a bit-level collision (which they do not only do when sending identification messages, but when sending all messages). Since the unique address is contained in the identification message, and no two modules are produced with the same unique address, all identification messages from the multitude of modules are by definition different, and so every time several modules start sending an identification message, exactly one "winning" identification message. The protocol is provided in such a way that this still applies, even if the identification message contains several frames (as will be explained below).

Thanks to the collision detection at bit level and, if necessary, stopping sending, and automatically retrying when the bus is free for a sufficient length of time, no messages are lost, so no time is lost on the bus due to corrupted (English: corrupted) data and retransmissions. This means an important time saving.

It is a great advantage of this method that it can even be implemented in an operational bus system, which means, for example, that the lighting system or the building automation system in which this bus system forms part will continue to work while this address request takes place. Moreover, this can happen with a not or hardly noticeable delay (provided that an appropriate choice of waiting times and / or priorities of messages and / or bit assignments to the available commands).

It is a great advantage that this method can be carried out very quickly (e.g., order of magnitude in 1.85 to 2.28 seconds for a bit period of 150 ps and a bus with 100 participants, assuming a unique address of 32 bits) that the bus was not loaded), because with each iteration exactly one unique address of the modules is sent to the Data Collection Module. Such a short period of time is unseen, and its benefit should not be underestimated.

This speed is mainly due to: 1) the fact that a "collision" on the bus does not mean that the information has been lost, in contrast to, for example, wireless communication where a collision means that both messages are lost. In the present invention, on the other hand, even in the event of a collision, one message will be correctly put on the bus (without being mutilated by colliding messages). This implies that the time required to send all unique addresses increases almost linearly with the number of modules connected to the bus, and therefore will not increase exponentially because the chance of collisions will increase. 2) the method does not require any special measures to avoid collisions (English: "collision avoidance"). On the contrary, all modules to be discovered may perfectly start sending simultaneously. Because no variable waiting time needs to be provided based on a pseudo-random value, the implementation can be simplified, and the messages can on average be sent faster. 3) because the Data Collecting Module will only send one identification request on the bus, after which all other modules will respond automatically, and will try again if they have not succeeded; 4) because the Data Collection Module requests the unique address, and the "other modules" give their address, as opposed to binary approximation techniques such as those known to DALI, where the master specifies an address range, and the slaves must answer if they fall within that range , or not; 5) Optionally, this can be accelerated even further by having all other modules start at virtually the same time (eg except for 1 bit period), by using a fixed, predetermined waiting time, eg WJD = 1.90 ms. 6) Optionally, this can be further accelerated by the use of at least one current source instead of a passive pull-up resistor, so that the signal flanks on the digital bus can be very steep (e.g., a rise and fall time of less than 10 ps, or less than 7 ps, or less than 5 ps, or less than 3 ps, or less than 2 ps), even for a cable of more than 100 m, which in turn allows a smaller bit period, and therefore a higher bit rate );

In practice, a PC or a laptop or the like is coupled to the GV, for storing and / or displaying the unique addresses, and for further analysis.

It is noted that initially only the unique addresses are requested from the multitude of participants, but this is the most crucial step. Once the unique UA addresses are known, the modules can be addressed individually, using specific commands within the protocol, the unique UA address being used to address one module individually, instead of the usual (and shorter) bus addresses. These messages where the UA is used for addressing are indeed longer than the "normal messages" that are sent between the modules during the "normal operation" of the system (e.g. from a light switch to a lamp), but are particularly useful for detect and even correct errors in the bus system.

It is noted here that it may seem trivial at first sight to provide read and write commands based on the unique address in the protocol, but that is absolutely not true, precisely because these addresses are not known to the installer (eg because they are not provided in known methods on the plan), so even if those functions existed in the prior art, he would not be able to use them.

Nor was it trivial to think of a function to request these addresses in the way suggested above, because there is clearly a bias that one should avoid collision with the bus as much as possible.

The unique addresses already allow an initial analysis. For example, it is possible, based on the structure of the unique address, or by checking into which range the unique address falls, or by looking up the unique address in a database that was created during production, additional retrieve or retrieve information about the relevant modules, eg to determine which type of module is involved. On the basis of a list of functions that work correctly, for example, a selection can already be made for which modules additional information should be requested via the bus, and which not. Alternatively, this information can also be requested on the bus, for example by sending a read command to each module, using absolute addressing instead of the local bus address.

Further details and advantages will become apparent in the detailed discussion of the figures. FIG. 1 is a replica of FIG. 1 of US8035529 (B2), and shows an example of a prior art ballast system based on the well-known "DAU" protocol. Although the present invention is not limited to ballasted lighting systems, this prior art document is interesting as background information for readers not familiar with such bus systems, or with the DALI protocol, or with "commissioning."

For the present invention, it is sufficient to know that FIG. 1 shows a master-slave system 100 with a master module 20 that sends messages over the bus 16 (according to the DALI protocol) to the plurality of modules 12 for controlling lamps 44 separately or in groups. module is assigned a 6-bit bus address, eg using remote control 18 and infrared receiver 24. The reader can read more details in the relevant document. FIG. 2 is a replica of FIG. 2A of US766955 (B1), and shows an example of an (extremely simply proposed) bus system 200 with a master-slave architecture, where the bus 203 is passively pulled high by an external 204 or internal 205 pull-up resistor. The modules 201, 211 have a bus interface with an input buffer 207, 217 and an output buffer 206, 216 which are coupled to each other. The output buffer 206, 216 has an "open collector output" or an "open drain output" with which the bus 203 can be actively pulled low. The operation of such a bus interface is well known in the art, and therefore does not need to be discussed in further detail.

The modules 201, 211 of FIG. 2 are connected such that the bus 203 will assume a low voltage level (e.g., 0V) when at least one of the modules 201, 211 pulls the bus low, and that the bus 203 will assume a high voltage level (e.g., 3V) when none module 201, 211 pulls the bus low but the bus is pulled high by the pull-up resistor.

Although not explicitly shown, the master 201 and the slave 211 each include a controller that provides a signal to be sent to the output buffer 206, 216, and which receives a signal through the input buffer 207, 217.

During the transmission of a signal, each module 201, 211 monitors whether the signal to be transmitted indeed appears on the bus 203. A so-called "collision" occurs when one of the modules wants to set a (passive) high level on the bus, while the bus is actively pulled low by another module. Such a collision can be easily detected by comparing the signal from the input buffer 207, 217 with the signal to be transmitted that is applied to the output buffer 206, 216. The bus 203 is called a "digital bus" because only two signal levels have to be distinguished. become "low" when the bus voltage is in a first voltage range or high "high" when the bus voltage is in a second voltage range that does not overlap with the first voltage range. FIG. 3 shows an exemplary block diagram of an interface module 300 (or simply "module") according to the present invention. The interface module 300 includes at least one bus interface 303 and a controller or processor 301.

The bus interface 303 of FIG. 3 has an output buffer (not shown) to be able to send signals, and has an input buffer (not shown) to be able to receive signals. The module 300 further has means (not shown) to detect a collision on the bus, and has means to disable the output buffer (which means that transmission is stopped) as soon as a collision is detected.

The controller or processor 301 may be, for example, a state machine (English: "status machine"), or may be a programmable processor, e.g., a programmable microprocessor, with an internal or external working memory (e.g. RAM), and with an internal or external not volatile memory (eg ROM, FLASH, EEPROM) for storing program instructions to be executed by the processor. These program instructions ensure that communication on the bus is according to a specific protocol.

Optionally, the module 300 may include an internal pull-up resistor 305, optionally via a switch (not shown) connected to the supply voltage VDD, to passively raise the bus.

Optionally, the module 300 may include an internal power source 304, whether or not via a switch (not shown) connected to the supply voltage VDD, to actively pull the bus high, but with a (relatively weak) current that is smaller than the (relatively strong current that can be discharged through the output buffers. An advantage of using a current source 304 instead of a pull-up resistor 305 is that the voltage on the bus can rise (or fall) almost linearly as a function of time rather than exponentially. In this way, more stylish edges can be obtained, which makes it possible to reduce the bit period.

In preferred embodiments of the present invention, the bus 311 is raised passively by means of at least one internal pull-up resistor 305, or by means of at least one internal current source 304, or by an external pull-up resistor (as in FIG. 2).

Optionally, the module 300 includes one or more additional blocks such as an IR (infrared) transceiver 306, an RF transceiver 307, a temperature sensor 308, a motion detector 309, a fiber optic transceiver (not shown), and so on.

Furthermore, the module may have one or more external inputs "IN" and / or one or more external outputs "OUT", depending on the component to which this interface module 300 is to be connected. In the example of FIG. 300 with two inputs and three outputs, but of course the invention is not limited thereto, and certain modules may, for example, only have one single input and no output, or only one output no input.

In preferred embodiments of the present invention, each input and each output of the module 300 is assigned a unique bus address, the bus address having approximately the same function as a bus address at DALI, with the difference that in DALI one module has only one bus address while a module 300 according to the present invention can have multiple bus addresses, and that a DALI address is only 6 bits long (max. 64 components), while a bus address in preferred embodiments of the present invention is at least 10 bits (max. 1024 components), or at least 12 bits (max. 4048 components) or at least 14 bits or at least 16 bits or at least 20 bits long.

For example, if a dimmer is connected to output OUT1, for example, and this dimmer is assigned bus address "500" according to the plan, then the module 300 must be configured accordingly by the installer, eg by storing the number "500" at a specific location in a non-volatile memory. This may optionally be the same flash memory 314 as the one in which the executable code is stored, or it may be a separate non-volatile memory, eg EEPROM 302. After saving the number "500" as the bus address for output OUT1 (in this example), the module 300 will receive and decode messages destined for bus address "500", and control the output OUT1 accordingly.

For example, if input IN2 is connected to a push button with bus address "188", then by storing the number "188" in a non-volatile memory of the module 300, the module can be configured to send a message originating from "bus address 188" when the corresponding push button is pressed.

In the context of the present invention, during commissioning, a unique bus address should in principle be assigned to each input and to each output of the module (insofar as it is used), the bus address only having to be unique within one certain bus system (usually one building). If the module 300 contains only one input or only one output, then that one bus address can be considered as the bus address of the module (as with DALI).

The function of dimming and checking the status of a push button (in the example above) is peculiar to the type of module 300, and will usually differ per type. In preferred embodiments of the present invention, information, including the type of the module, can be retrieved via the bus interface.

Optionally, the module 300 further comprises a serial interface, e.g. an I2C or an RS232 or an SPI interface, which can be used, for example, to program the bus addresses during the aforementioned "commissioning". Alternatively, a push button may be provided (not shown) connected to a dedicated input PROG of the controller 301, to ensure that the module 300 performs a special routine in which it will send a special intended message with at least one bus address therein received and will save, for later use as a bus address. In the example above, that special message would contain, for example, the bus address "500" intended for output OUT1 and the bus address "188" intended for input IN2, and possibly other bus addresses for the other inputs and outputs.

The serial interface can also be used to communicate with a user device, e.g., a computer 401, as shown in the example of FIG. 4, where the module D01 acts as a Data Collection Module GV and can transmit or exchange information with the PC 401. Alternatively, communication with the user device 401 (e.g., PC) can also be via the IR transceiver 306 (if present), or via the RF transceiver 307 (eg Wifi or Bluetooth), or via another suitable interface, such as a USB port (not shown).

Each module 300 according to the present invention has a unique address UA, e.g. a serial number, chosen so that no two modules 300 with the same unique address exist. During the production of the module 300, this unique address is usually stored in a non-volatile memory of the module, for example in Flash or EEPROM, or rather in an OTP memory (One-Time Programming).

Of course, each module 300 also has a port for connection to a power supply Vdd and a reference potential Gnd. In the example of FIG. 3, the power supply may be, for example, a DC voltage VDD supplied by an external transformer (not shown), but this power supply may also be supplied via one of the bus wires (as will be further discussed in FIGS. 7 to FIG. 9).

Furthermore, the module 300 preferably comprises a clock circuit 310, for generating one or more internal clock signals. Clock circuits are known in the art, and may, for example, be based on an internal RC delay, or are preferably based on the oscillation frequency of an external crystal 315. If the bus 311 itself supplies a clock signal (not shown), then the crystal 315 may be omitted, otherwise, the module 300 must synchronize its timing with the edges of the data signal on the bus 311, in known ways.

Optionally, the module 300 may contain a so-called real-time clock 313, that is usually a chip powered by a local battery, which chip keeps track of the date and time (e.g. in hours, minutes and seconds), as is known in the PC world for example. This real-time clock can, for example, be useful for adding time stamps (English: "time-stamps") to log messages that are stored in a log in a non-volatile memory.

Preferably, the module 300 also comprises a so-called "watchdog timer" 312, or a monitoring circuit, which causes, for example, an internal reset of the module 300 when the voltage comes on, or when there is no activity for a predetermined time. of the controller.

The module 300 according to the present invention is new to the prior art, inter alia because the controller 301 is provided, e.g., is programmed to execute communications on the bus 311 according to a specific protocol that includes at least the method in which the module 300 upon receiving the identification request, will repeatedly attempt to send its unique address via an identification message (shown on the right of FIG. 25). FIG. 4 is a schematic representation of an example of a (very simple) "lighting system" or a "building automation system" 420, comprising four components COMP1, COMP2, COMP3, COMP4 (for example selected from the set consisting of a light button, a lamp, a motion detector and a sun blind), and three interface modules D1, D2, D3 and a digital bus 404 with wires (English: "wired bus"). In the example of FIG. 4, module D1 is connected to only one component D1, and module D2 is connected to only one component D2, but module D3 is connected to two components D3, D4. Each module D1, D2, D3 has a unique address or serial number, respectively UA1, UA2, UA3. However, these unique addresses are not used during the "normal operation" of the lighting system or the building automation system, but bus address BA1 assigned to module D1 and associated with the input or output to which the first component COMP1 is linked, bus address BA2 assigned to module D2 and is associated with the input or output to which the second component COM2 is linked, and bus addresses BA3 and BA4 which are both assigned to module D3, where bus address BA3 is associated with the input or output to which the third component COMP3 is connected, and bus address BA4 is associated with the input or output to which the fourth component COMP4 is connected

The subsystem comprising the interface modules D1, D2, D3 and the digital bus 404 is called the "bus system". The modules D1, D2 and D3 can be slaves on the bus, but can also be masters, ie they can send a message autonomously on the bus, without being requested by another module.

Optionally, a module DO can be coupled to the bus 404, temporarily or permanently. In the example of FIG. 4, this module DO is not coupled to one of the above-mentioned components COMP1, COMP2, COMP3, but is connectable or functionally connected to a user device 401, e.g. a PC with input devices 403 and a screen 402, or a laptop or tablet or a smartphone. The DO module can be used, for example, to configure or reconfigure the bus voice and / or to monitor traffic on the bus 404, etc. The PC 401 can, for example, request information about the bus system via the DO interface module, with which it is functionally connected, e.g. via a serial or wireless interface, and can display such information on a screen 402, for example, or store it on a storage medium (not shown), etc.

In the context of the present invention, the module DO functions as "Data Collection Module", abbreviated as "GV", which means that it is the module that sends the "identification request" described above on the bus, and which receives the "identification messages" from the other modules D1, D2, D3 containing the unique addresses UA1, UA2, UA3, respectively. The GV can forward these identification messages or these unique addresses to the user device 401 for further processing, e.g. for display on a screen 402. The term "Data Collection Module" is used in this document to distinguish the known concepts of "master" and "slave".

A possible scenario for the bus system of FIG. 4 to be correctly installed in a building proceeds, for example, as follows: - an installer lays a cable 404 with several wires from a control room to a specific room of a building, according to a plan; the installer assembles the components COMP1, COMP2, COMP3, COMP4 and assembles the modules D1, D2, D3, and connects the components with the associated modules, and connects the modules with the cable 404; - the installer programs (in known manner) the bus address BA1 for component COMP1 in module D1, and programs the bus address BA2 for component COMP2 in module D2, and programs the bus addresses BA3 and BA4 for COMP3 and COMP4 in module D3, as provided in the plan. Each module D1, D2, D3 stores the bus address (s) assigned to it in an internal non-volatile memory (eg in flash or eeprom).

Now assume, for example, that the installer correctly assigns bus address BA1 = "1" to module D1, but mistakenly has not stored bus address BA2 = "22" in module D2, but an incorrect address (eg address "23"), and correctly stores bus address BA3 = "33" in module D3, but by mistake has forgotten to store bus address BA4 = "43" in module D3. Of course, the lighting system or the building automation system in which the bus system is used will not work as provided for in the plan. To detect and correct this error (s), the installer must physically go to each of modules D1, D2 and D3 (because he does not know which modules are correct, and which modules are not programmed correctly), and eg. still or re-execute the assignment of the bus address / bus addresses, or at least perform additional actions to request the bus address stored in the module (or the factory value) in one way or another (eg in in the case of a lamp it is sometimes possible to send a modulated light signal, on the basis of which the bus address can be determined). This is time-consuming, and sometimes very difficult or even impossible, for example because the room in which the module is located is locked.

According to the present invention at least some of these problems can be detected much faster, and / or more elegantly and possibly even remotely solved, for example as follows (referring to FIG. 4 and FIG. 24): - if the module DO is still is not present, then it is added, and (temporarily or permanently) connected to the digital bus 404, as shown in FIG. 4; if the user device 401, e.g. PC or laptop or the like is not yet present in the system, this is also added, and functionally connected to the module DO, as shown in FIG. 4 (e.g. via Bluetooth); - the module DO functions as Data Collection Module GV and sends an identification request BO (see also FIG. 12) to the other modules DI, D2, D3, e.g. after pressing a button (not shown), or after receiving a command from the PC 401, or in another suitable manner.

This identification request BO is a so-called "query command" or "broadcast command", which means that it is a message intended for all other modules, regardless of their bus address (s). This message contains a predetermined bit pattern to indicate that this message is an identification request recorded in the protocol. The message B0 will be received by the other modules D1, D2, D3. The modules D1, D2 and D3 will receive this command even if their bus address (s) have not yet been programmed or have been programmed incorrectly.

Subsequently, the other modules D1, D2, D3, each responding to the identification request, will each send back their own identification message on the bus intended for the Data Collection Module GV. These identification messages B1, B2, B3 contain a first part that serves to indicate that this message is an identification message, and a second part that contains the unique address UA1, UA2, UA3 of the relevant module. The first part is a predetermined bit pattern that is the same for all modules. The second part is different.

The Data Collection Module GV recognizes these identification messages on the basis of the specific bit pattern indicating that this is an identification message, and receives the messages with the unique addresses of all other modules D1, D2, D3. In FIG. 12 to FIG. 19 it will be explained in more detail on the basis of a simplified example how this can be done, both at bit level and at frame level. One of the underlying ideas of the present invention is based on the fact that each unique address UA1, UA2, UA3 is truly unique, and that consequently the identification messages are also unique, thus guaranteeing that each identification message will be sent on the bus exactly once undamaged. even when hundreds or even a thousand or more modules start sending their identification message "almost simultaneously", and even when the system was already operational at the time the identification request is sent, and "normal messages" are sent between the identification messages .

It is noted that the module DO acting as GV will only send a single query command, and that the other modules D1, D2, D3 will automatically retry sending their identification message BI, B2, B3 if it is not of the first attempt. Because the GV will only send one command, the traffic on the bus is limited and a lot of time is saved. If the bus remains inactive for at least a predetermined timeout period WJD, the module DO knows that all identification messages have been sent.

It is important to note that the repeated attempts may be regarded as "retransmissions" for the relevant module, but not as "retransmission" on the bus due to corrupted messages caused by collisions. The protocol is defined in such a way that collisions will occur when two (or more) modules try to put a different bit on the bus at the same time, but the module whose information is mutilated immediately stops sending, and the module whose data is intact continues to send. This aspect in itself is known, but not in combination with requesting the unique addresses that are automatically sent one after the other, as a result of which a large speed gain is achieved. And also not in combination with the optional feature that no pseudo-random time is waited before sending the identification messages.

Referring back to FIG. 4, all unique addresses UA1, UA2, UA3 will thus be sent to the user device 401, e.g. a PC with a screen 402 and input means 403 (e.g. a keyboard and a mouse). These unique addresses are the basis for further analysis.

When the unique addresses are known, for example, a command can be sent to each module D1, D2, D3 separately to request more details, such as the type of the module, and / or the bus address or bus addresses that are are stored in the module, etc.

To that end, the protocol of a bus system according to the present invention may also include commands to request certain information from one particular module that is addressed by its unique address, and the protocol may also include commands to send this information from the relevant module to the GV, to possibly be stored therein in a non-volatile memory. In the state of the art, although information can be requested from the modules (including the serial number), that communication takes place on the basis of the assigned bus address, and therefore only works after the bus addresses have been correctly assigned, and does not work if none or an incorrect bus address has been assigned. The additional function of the present invention, with which modules can be individually addressed using their unique address, is therefore extremely suitable for detecting and / or correcting errors, but only after the unique addresses are known.

Optionally, the PC 401 can also consult a data file, in which additional information is stored from the modules produced, based on the unique address. For example, the type of each module can easily be retrieved from a data file.

Referring back to the example above, the installer can determine that: (a) the module D1 is of the type to interface with COMP1 (e.g., a push button), and that the bus address BA1 is correctly programmed, and that (b) the module D2 is of the type to interface with COMP2 (eg a lamp), and that the bus address BA2 is incorrectly programmed, and that (c) the module D3 is of the type to interface with COMP3 (eg a relay) for a sunblind motor) and COMP4 (eg a wind sensor), and that the bus address BA3 is correctly programmed, but the bus address BA4 is not programmed.

These errors can then be easily corrected by sending a correct bus address to modules D2 and D3, using a write command with absolute addressing (ie where the unique address is used to address the module and not the bus address).

The example above shows that it is not always necessary to know the physical location of the modules, and that it is not always necessary to go to the physical location where the component in question is located, but sometimes it is necessary. But even then, the present invention is particularly useful because the number of components that must be verified manually can be drastically reduced.

In summary, the present invention thus allows to quickly find all unique addresses (with only one query command), and then allows each module to be individually addressed based on their unique address, to read additional information and / or to write. A data file can also be consulted to request specific information based on the unique address. On the basis of this information, the installer can make a diagnosis of the errors and can make the necessary corrections in a very targeted manner. FIG. 5 is a schematic representation of a second example of a bus system according to the present invention, and of a lighting system or a building automation system comprising the bus system.

The bus system of FIG. 5 comprises a first physical conductor VO connecting modules DO1, D02 and D03 situated on a ground floor of a building, for interfacing with associated components COMP0l, COMP02, COM03, and a second physical conductor VI which links modules D11, D12 and D13 connects on a first floor of the building, for interfacing with associated components COMP11, COMP12, COMP13. The first conductor VO and the second conductor VI are electrically connected to each other via a so-called "backbone" BB.

In a similar manner as described in the example of FIG. 4, the Data Collection Module 504 can send an identification request to each of the modules DO1, D02, D03, D11, D12, D13, and each module will respond with an identification message containing the unique address of the relevant module.

Thereafter, the Data Gathering Module GV can, if desired, request additional information from the modules by addressing it based on their unique address (referred to herein as "absolute addressing"), and / or the Data Gathering Module GV can remotely program one or more bus addresses in the relevant module .

It was described above how the identification request and the identification messages can be used to detect errors made during the initial assignment of one or more bus addresses at the installation of the system, but the present invention is not limited thereto, and can also be used e.g. breakdowns, for example to detect whether all modules are still responding, or can for example also be used to generate an up-to-date list with the unique addresses with the assigned bus addresses (eg to determine which bus addresses are still free when a module is added to the system), etc.

In a preferred embodiment of the present invention, the bus protocol is designed such that sending the identification request by the Data Collection Module 504, and responding to it by all other modules DO1, D02, D03, D04, D05, D06 can be performed while the system is "in" operation "is as a lighting system or as a building automation system. For example, if two modules (not shown) and two components (not shown) are installed on the first floor, then it is desirable that the lighting and / or functions such as air conditioning and / or sun blinds continue to work on the ground floor. As will be further explained, this is possible because the identification request and identification messages use the same frame structure as the frame structure used to send "normal" messages between components (e.g. from a push button to a light, or from a light sensor to a sunblind, etc.). This also applies to read and write operations with absolute addressing.

It will be clear that a relatively fast detection of all unique addresses, and especially a communication whereby the other modules can continue to work, becomes all the more important as the building has more modules and / or more components, for example at least 17 or at least 33, or at least 50, or at least 65, or at least 100, or at least 129, or at least 150, or at least 200, or at least 257.

In an embodiment of the present invention, identification messages have a lower priority on the bus than other messages such as e.g. messages for sending a message from a push button to a lamp (herein referred to as "normal messages" or also "operational messages"). In this way, the identification messages are prevented from completely occupying the bus until all modules have been identified. This can, for example, be easily implemented by selecting the minimum wait time W_ID (see FIG. 19) prior to an identification message greater than the minimum wait time before a "normal message", e.g. at least 2.1 ms instead of at least 1.95 ms.

Preferably, the modules are designed such that, if the module is to send both an identification message and a "normal message" (e.g. a message due to pressing a push button or due to a detector linked to the module), the "normal message" is sent before the identification message. This is a matter of determining which message to send is given priority in the module. In the case of a programmable controller, this functionality can easily be provided in the program executed by the controller.

Naturally, all modules must listen to the bus at all times, and take the necessary action if a message is received for them, eg switching on a specific lamp connected to this module, even if the module still has an identification message must send. This can be easily implemented, for example, by using a microcontroller that is clocked at a sufficiently high clock speed. FIG. 6 is a third schematic example of a bus system according to the present invention. It is a variant of the bus system of FIG. 5. The components are not shown not to overload the drawing. The main difference with the bus system of FIG. 5 is that signal amplifiers R1, R2 have been added on the bus to lower the impedance of the bus. The signal amplifiers may, for example, comprise two sub-circuits connected to an optical coupling.

The sub-circuits are preferably designed in such a way that when the bus on one side of the signal amplifiers is low (e.g. on the backbone BB side), the signal amplifier also pulls the bus on the other side (e.g. sub-bus VO) low , and vice-versa. Thanks to the optical coupling in the signal amplifiers, the impedance of the bus has been drastically reduced, which improves the steepness of the edges, allowing a higher bit rate to be selected, and all modules can functionally talk to each other as if they were all hanging on the same wire. Such a bus system offers enormous flexibility in terms of reconfiguration, without the disadvantages associated with long pipes, such as slow flanks and low bit rates. FIG. 7 to FIG. 9 show some examples of wired buses (English: "wired bus"), known in the art. These figures serve, inter alia, to indicate that the power supply for the modules can come from the bus or can be generated locally, and / or to indicate that the bus can be, for example, a two-wire or three-wire bus, but the invention is not limited to that. FIG. 7 shows an example of a two-wire bus with two electrical conductors in which one conductor "GND" acts as a reference (ground), and another conductor "DATA" is used for data transfer. In this case, the modules D1, D2, D3 must be supplied independently, for example from a local transformer or from a battery (not shown). FIG. 8 shows an example of three-wire bus with three electrical conductors in which one conductor "GND" acts as a reference (ground), a second conductor "DATA" is used for data transfer, and a third conductor "VDD" is used to at least some other participants. feeding via the bus. The voltage VDD is preferably a direct voltage. FIG. 9 shows an example of a two-wire bus with two electrical conductors where one conductor "GND" acts as a reference (ground), and the second conductor "DATA / VDD" is used for both data transfer and for feeding other participants. These participants must have special facilities such as, for example, a diode and a capacitance, but such circuits are known in the art, and therefore need not be further explained.

Bus systems according to the present invention can be used with any of the configurations shown in FIG. 7 or FIG. 8 or FIG. 9, but are not limited thereto. For example, a bus system according to the present invention can also work with two-pole signals (English: "dual ended signals"), or with synchronous signals (in this case the bus contains, for example, an additional conductor with a clock signal). FIG. 10 shows some examples of signals that can be used in embodiments of the present invention. The modules of a bus system according to the present invention need only distinguish three different signals on the bus: - a "data bit signal" (or simply "data bit") according to a logical "1", - a "data bit signal" (or simply "databitO") according to a logical "0", - an "empty signal" (English: "idle", indicating that the bus is free). This form is used between different sequences of bits (hereinafter referred to as "frame").

In a preferred embodiment of the present invention, the "data bit signal" has a predetermined bit period (e.g., 150 ps) and a predetermined shape with one voltage transition from a low level (e.g., 0V) to a high level (e.g., 24V) ) after about 2/3 of the bit period (e.g., 100 ps), as shown in FIG. 10 (a); and the "data bit" signal has a predetermined bit period equal to the duration of the data bit signal (e.g., 150 ps), and a predetermined shape with one voltage transition from the low level (e.g., 0V) to the high level ( e.g., 24V) after about 1/3 of the bit period (e.g., 50 ps), as shown in FIG. 10 (b); and the "free signal" has a signal form equal to the high level (e.g., 24V), as shown in FIG. 10 (c), of indefinite duration; but the invention is not limited thereto, and will also work with other signal forms and / or other voltage values and / or a different timing, provided that the signals allow a collision of a data bit signal and a data bit signal to be detected at bit level and that one of the bits is sent undamaged even in the event of a collision, assuming that all transmitters of the non-dominant bit stop transmitting before the end of the bit period.

It should be noted here that the signals shown in FIG. 10 have been ideally proposed. In practice, the signal will not be exactly OV or 24V, but such aspects are known, and need not be further explained.

The bus system according to the present invention is preferably a bus system in which the bus is pulled (weakly) high by means of a (relatively large) pull-up resistor (English: "puli-up resistor") or a relatively weak power source, and wherein each module has the bus can actively pull low by means of a (relatively strong) low-pull transistor (English: pull-down transistor). In such a bus configuration, data bit is the dominant bit and data bit is the non-dominant bit, because the transistor can provide a stronger current than the weak pull-up resistor or the weak current source, but the invention is not limited thereto, and other configurations can also be used eg a bus configuration in which the bus is (weakly) pulled low by means of a relatively large resistance, and can be pulled high by a (relatively strong) transistor in the modules.

In another embodiment of the present invention, the signal form of FIG. 10 (a) represents a logical "0", and represents the signal form of FIG. 10 (b) a logical "1" for. In that case, data bit is the dominant bit, and data bit is the non-dominant bit. FIG. 11 shows two other exemplary waveforms that can also be used by embodiments of the present invention, known as "Manchester" coding. In the variant designated "Manchester1" (known in the art as Manchester according to GEThomas), a logical "0" is represented by a voltage transition from low to high after 50% of the bit period, and a logical "1" is represented by a voltage transition from high to low after 50% of the bit period. In the variant referred to as "Manchester" (known in the prior art as Manchester according to IEEE 802.3) that is just the opposite.

An advantage of the signals of FIG. 10 with respect to the signals of FIG. 11 is that the start of each bit period coincides with the falling edge of the signal, whereby the synchronization can be more accurate.

Some state-of-the-art bus systems use additional signal types such as a "reset signal" or an "attention request signal", but this is not necessary for the present invention. The three signals mentioned above (data bit, data bit and free) are sufficient. This can help to reduce the complexity of the modules for a bus system according to the present invention. FIG. 12 to FIG. 19 illustrate in more detail the method for identifying the modules of a bus system according to the present invention on the basis of a simplified example. In the simplified example, each identification message consists of one frame of 5 bits, and the frame contains a first part with the predetermined sequence "101" to indicate that the message is an identification message, and the frame further comprises 2 bits corresponding to the unique address. In the example of FIG. 12 to FIG. 19, module D1 has unique address UA1 = "11", module D2 has unique address UA2 = "10" and module D3 has unique address UA3-O0 ".

The main purpose of FIG. 12 to FIG. 19 is to demonstrate the principle that even when all modules, after receiving the identification command, simultaneously start sending their identification message containing their unique address, that exactly one module in each iteration succeeds in sending its unique address , without losing a message.

In FIG. 12, the "Data Collection Module" sends an identification request BO to the "other" participants D1, D2, D3 of the bus system, with the request to make themselves known. This is a broadcast command intended for all "other modules", regardless of their bus address (s). ("other modules" means all modules except the "Data Collection Module" that sent the identification request). This message is received by the "other" participants D1, D2, D3 as suggested by the arrows.

The identification request is decoded by each of the modules D1, D2, D3, and after a certain waiting time (measured from the end of the last bit on the bus) each "other" module will attempt to send its identification message containing its unique address. Thus, the identification message B1 that will be sent by module D1 contains the unique address UA1, and the identification message B2 that will be sent by module D2 contains the unique address UA2, and the identification message B3 that will be sent by module D3 contains the unique address UA3 .

In the example of FIG. 13, the three modules D1, D2, D3 all start simultaneously with sending their message to the bus. As far as known to the inventors, it is anything but trivial to send an identification request to all other modules, knowing that subsequently all modules will respond almost simultaneously. On the contrary, in the state of the art, everything is usually done to try to avoid collisions (English: "collision avoidance"), for example by making sure that no two modules will start sending at the same time, let alone a command would be defined on which all modules (except one) will start sending at the same time.

Moreover, there seems to be a bias that it is possible and practicable to determine participants' addresses for addresses with a maximum of 6 or 8 bits (if necessary by trying all possible addresses and checking them) whether someone responds), but there seems to be a bias that it is not possible to request "direct" addresses from modules when those addresses contain more than 10 bits, let alone more than 20 bits or even 32 bits, at least in the field of building automation systems.

The inventors of the present invention thus directly contradict the premise that it would be impossible or practicable to request addresses with more than, say, 10 bits, and against the current opinion that collisions should be avoided at all costs, and do exactly the opposite, because ideally (if all modules would run perfectly synchronously), all "other" modules will start sending their identification message at exactly the same time. Indeed, in preferred embodiments of the present invention, no random (random) time is waited by the different modules after receiving the identification request, but they all start after the same predetermined time WJD that is at least equal to 1.5 bit period (in the example of FIG. 10, so at least 225 ps), or at least 2.0 bit periods, or at least 2.5 bit periods, or at least 3.0 bit periods, or at least 5.0 bit periods, or at least 10 bit periods (in the example 1, 50 ms), e.g. 2.10 ms after the last bit of the identification request. The tolerance at said timing depends on the implementation, and is typically a value between 1 internal clock period of the module and 1 bit period or bus, and is typically in the range of about 16.6 ns to about 250 ns, according to a internal clock from 4 MHz to 60 MHz), but the invention is not limited thereto, and the internal clock may also have a frequency greater than 60 MHz, e.g. in the range of 60 MHz to 2 GHz.

Since the same format is used for all identification messages B1, B2, B3, and since the unique addresses UA are different, exactly (if there is no other traffic on the bus) exactly one module will succeed each time to send its identification message "intact" on the bus and the other modules will detect a collision on the bus, immediately interrupting the sending of their identification message, and will wait until the bus is free again for at least the predetermined period of time WJD, after which they will again try to send their identification message until all identification messages have been sent. But even if there is other traffic on the bus, then each identification message will be sent on the bus exactly once undamaged, and the module can determine if it has succeeded, and will continue to try until it has succeeded. This is an important underlying principle of this method according to the present invention. FIG. 14 shows the waveforms of the messages B1, B2, B3 that the three modules D1, D2, and D3 want to send via their bus interface, respectively. In the example, the first three bits of the three messages are the same (and indicate that this message is an "identification message"). Only when the fourth bit is sent will the module D3 detect a collision, because it wants to put a data bit signal on the bus itself, but that is not possible because the bus is pulled low by data bit from both modules D2 and D3. As soon as module D3 detects the collision, it stops transmitting, no later than the end of the fourth bit period, preferably earlier. Module D1 and D2 do not notice a collision and just continue to send the fourth bit, and then start sending their fifth bit.

During the sending of the fifth bit, the module D2 detects a collision on the bus, and stops sending message B2. Module D1 does not detect a conflict, and continues to send its message BI, and concludes after sending all the bits of the message BI that it has succeeded, and no longer participates in the next iteration. The modules D2 and D3 have failed to send their identification message (B2 and B3, respectively), and will try again later, as shown in FIG. 15 and FIG. 16.

It is noted that (according to the protocol of a bus system according to the present invention) the Data Collection Module will not send a message again, but that the modules that have not yet succeeded in sending their identification message undamaged will automatically try to send their identification message again .

In FIG. Thus, the remaining participants D2 and D3 start simultaneously with sending their identification message, message B2 and message B3, respectively, while the Data Collection Module listens for the message sent over the bus, as suggested by the arrows. For the sake of completeness, it should be mentioned that module D1 will also receive and decode the signal that is placed on the bus, because all modules must always listen to the bus, but the module D1 will not respond to this because identification messages are intended for the GV . FIG. 16 shows the waveforms of the message B2 and B3 that the modules D2 and D3 attempt to send via their bus interface, respectively, in a second attempt to send their identification message. In a similar manner to that described above, the module D3 will detect a collision on the bus upon sending the fourth bit and stop sending its message B3, as suggested by the dotted line. In this second iteration, module D2 will succeed in sending its message B2 undamaged and decide to no longer participate in the iterations. So only module D3 remains.

In FIG. 17, the only remaining module D3 sends the message B3 containing its unique address UA3, while the Data Collection Module GV listens for the message sent over the bus as suggested by the arrows. The modules D1 and D2 will listen in on the bus, and will decode the message, but will further not respond to the message B3 sent by module D3, and intended for the Data Collection Module. FIG. 18 shows the waveform of the message B3 sending module D3 via its bus interface, as a third attempt to send its identification message, which it succeeds this time. FIG. 19 shows the total waveform observed on the bus after sending the identification request. The waveform shown is in fact a sequence of the signals of FIG. 14 (from time t1 to t2), followed by a wait time WJD, then the signals of FIG. 16 (from time t3 to time t4), again followed by the waiting time WJD, and finally the signals of FIG. 18 (from time t5 to time t6).

As described above, in preferred embodiments of the present invention, the minimum waiting time WJD to respond to the identification request is the same for all modules, and thus not based on any value, but the invention will also work if the waiting times are different.

In the example of FIG. 19 at time t6 all "other" modules D1, D2 and D3 have sent their identification message, and the bus will remain "free" after t6. After a predetermined time-out value for identification messages TOJB has elapsed, the Data Collection Module will decide that all identification messages B1, B2, B3 of all other modules D1, D2, D3 have been received. This timeout is preferably a factor of 1.05 to 2.00 greater than WJD, e.g. TOJB = 2.25 ms, but the invention is not limited thereto.

In the example of FIG. 12 to FIG. 19 it was assumed that no "normal" or "operational" messages were sent on the bus, but if that were the case, a collision could already be detected in the first part of the message. Those skilled in the art will understand that the choice of the bit pattern of the commands, as well as the waiting time between different types of messages, will determine which messages take precedence over other messages.

In preferred embodiments of the present invention, it is not desirable that the identification messages take precedence over "normal" messages, as this would degrade the response time of the lighting system or the building automation system. This drawback can be easily solved by an appropriate choice of the bit pattern of the identification messages (in the example of FIG. 12 to FIG. 19, this can be achieved, for example, by assigning the value "000" to the first part, i.e. as command of the identification messages), and / or by using an appropriate choice of the waiting time WJD for identification messages (in the example of FIG. 12 to FIG. 19 this can be achieved, for example, by making the waiting time WJD at least 3.0 bit periods longer choose the waiting time for "normal" messages). A combination is also possible. The person skilled in the art can, with the additional insights obtained from this document, find a suitable set of commands and associated bit patterns, if necessary experimentally. This does not need to be explained further.

As already stated, FIG. 12 to FIG. 19 a greatly simplified representation of the situation, and primarily intended to demonstrate the principle that each module (except the GV itself) will ultimately succeed in sending its identification message with its unique address, and that no messages will be lost. The iterations mentioned above are therefore not "retransmissions" because a message has been lost, and should therefore not be seen as "lost time", but rather as "delay" because another message was given priority.

In preferred embodiments of the present invention, all messages over the bus, thus also the identification request and the identification messages, are packaged in a frame structure consisting of one or more frames of a fixed length, e.g. the frame structure as shown in FIG. 20, and the unique address will contain at least 16 bits, or at least 20 bits, or at least 24 bits, or at least 28 bits, or at least 32 bits, or at least 36 bits, or at least 40 bits, or at least 48 bits, spread over several frames, preferably consecutive frames, but the operating principles and benefits remain valid. FIG. 20 shows an exemplary time diagram of a message consisting of a single frame. In preferred embodiments of the present invention, one frame consists of 18 time dots or bit periods. For example, each time slot can be 150 ps in length, but a different value can also be used, e.g. a time slot in the range of 5 ps to 1500 ps, or in the range of 8 ps to 1500 ps, or in the range of 10 ps up to 1250 ps, or from 15 ps to 1250 ps, or from 20 ps to 1000 ps, or from 30 ps to 750 ps, or from 50 ps to 500 ps, or from 75 ps to 300 ps, or from 100 ps to 250 ps, e.g., approximately equal to 125 or 150 or 175 or 200 or 225 ps. The person skilled in the art can find a suitable value taking into account, for example, the rise and fall time of the signals (mainly determined by the bus impedance and the value of the pull-up resistor or the output impedance of the pull-up current source), robustness (bit-error rate), and data rate. The "Tbit" bit period must be the same for all modules that are connected directly to the communication bus (see FIG. 4) or indirectly via a repeater without significant delay (see FIG. 5), but may in principle differ from building to building.

The frame of FIG. 20 starts with a "start bit" with the logical value "1", then 16 data bits follow, and ends with a "stop bit" with the logical value "0." The receivers of the modules will always attempt this 18-bit frame structure and ignore column sequences that do not conform to this structure The further processing of the message is preferably performed by the controller 301 (see FIG. 3) in known ways.

In bus systems according to the present invention, one message may comprise one or more frames, e.g. from 1 to 20 frames, but more frames are also possible. The combination of relatively short frames (16 data bits instead of 24) and one or more frames per message offers the advantage that short messages can be sent efficiently, but long messages are also possible, whereby the functionality of a bus system according to the present invention can be very extensive, much wider, for example, than the limited functionality offered by a bus system with the DALI protocol. Bus systems according to the present invention are therefore very suitable for use in a lighting system or a building automation system. FIG. 21 shows an exemplary bit structure of the frame of FIG. 20. The precise meaning of each bit is beyond the scope of this document, and is not necessary to understand the present invention.

If a message contains several frames, known techniques can be used to ensure that the frames on the receiving side are correctly merged, such as by stating the number of frames in the first frame, and / or by stating a sequence number in each frame, etc. FIG. 22 shows an exemplary time diagram of a message consisting of two frames sent one after the other, separated by a waiting time WT2F (abbreviation for waiting time between two frames of the same message).

Although not strictly necessary, frames of the same message are preferably sent as a series or as a train on the bus, with the necessary waiting time WT2F between the frames, but without the intervention of frames of other messages. This can be achieved, for example, by making the waiting time WT2F between frames of the same message smaller than the waiting time WT2B between two "normal" messages. FIG. 23 is a schematic representation of the time required to send a message consisting of three frames. After the third frame, the bus must be free for at least WT2B (which stands for "wait time between two messages"), so the message of three frames takes 13.65 ms in total.

In the examples above, the following values were used:

but other values are also possible, eg values that meet the following set of conditions:

In addition, it is preferably WT2F <= 100 x Tbit (11), although this is not strictly necessary. FIG. 24 shows (at a high level) a method for identifying a plurality of modules of a bus system, (preferably all modules except the module that acts as a Data Collection Module), according to an embodiment of the present invention.

In optional step 2401, one of the modules is referred to as Data Collecting Module, or in step 2402, a module is added to act as Data Collecting Module. The GV is preferably functionally connected (e.g. by means of an electrical cable, e.g. an RS232 cable, a USB cable, a UTP cable, an FTP cable, an Ethernet cable, a coax cable or a fiber optic cable, or a other kind of network cable or wireless, e.g. via an infrared connection, or an RF connection such as WiFi or Bluetooth) with a user device 401, 501, 601 (as in FIG. 4 to FIG. 6), e.g. a PC with a screen 402, 502, 602 and with input means 403, 503, 603 such as e.g. a keyboard and / or a mouse; or a smartphone, or a laptop, or the like. The GV is provided to communicate with the user device, e.g., to receive commands from the user device, such as starting to request the unique addresses, or requesting additional information from a module with a particular unique address, and for forwarding of information to the user device.

In step 2403, the Data Collecting Module sends an identification request to all other modules on the bus. This request can, for example, be initiated by a timer or a real-time clock (e.g. every night at a predetermined time, e.g. at midnight), or can be initiated by, for example, a request from the user device, or by the pressing a provided push button on the Data Collection Module (not shown), or in any other suitable manner.

In step 2404, the Data Collection Module receives an identification message from a module, containing the unique address of the relevant module. This message can, for example, be stored temporarily or permanently in RAM of the GV, and / or in non-volatile memory of the GV (eg flash).

In step 2405, the Data Collecting Module checks whether the bus is free for a predetermined time-out time TOJB, and if so, the Data Collecting Module decides that all identification messages have been received. If not, steps 2404 and 2405 are performed again to receive additional identification messages.

In optional step 2406, the Data Collection Module can process the identification messages (e.g., by extracting the Unique Addresses), and / or forward it as such to the user device (e.g., the PC). The PC can possibly store these unique addresses in a data file and / or display them on a screen.

In an alternative embodiment of the method, the unique addresses are not processed and / or sent to the user device until they have all arrived at the Data Collection Module, but are already processed and / or sent in the meantime, e.g. as part of step 2404.

If desired, the user device (e.g. the PC) can also request the unique address of the Data Collection Module, but this is usually not necessary. FIG. 25 is a schematic representation of the method performed by the Data Collection Module (left side of FIG. 25), and the method performed by each of the "other" modules (right side of FIG. 25) of a bus system according to the present invention .

In step 2501, the Data Collecting Module sends an identification request on the bus. This step is the same as step 2403 of FIG. 24.

In step 2502, each "other" module receives the identification request, whereafter each "other" module will send an identification message containing its unique address or unique serial number. This is done as follows (steps 2510):

In step 2511, each "other" module waits for the bus to be free for at least a predetermined period of W_ID (the "minimum wait time for sending the identification message")

In step 2512, any "other" module that has not yet succeeded in sending its identification message correctly (in the first iteration it is all other modules) will start sending its identification message, during which each bit is transmitted it is checked (step 2513) whether a collision occurs, and if a collision is detected, the module whose signal to be transmitted deviates from the signal on the bus stops transmitting immediately (step 2514), and will try again later by steps i ) to iii). Each module will keep trying until the module has finally succeeded in sending its identification message intact.

While the modules attempt to send their identification message (steps 2510), the Data Collection Module listens to the bus, and in step 2503 receives one identification message each time, which may possibly consist of one or more frames, as explained above.

If the Data Collection Module determines (step 2504) that the bus is free longer than a predetermined time-out value TOJB, then it assumes that all identification messages have been received.

Although not shown in FIG. 25 the modules always execute a reception routine in parallel, decoding the signal from the bus, and if the signal is intended for the relevant module, they also execute that command, e.g. by setting a certain output low or high to to switch a lamp on or off, or to open or close a relay, or the like.

Although the main purpose of the Data Collection Module as described herein is aimed at requesting and receiving the unique addresses, and possibly requesting additional information using absolute addressing, and the Data Collection Module can in principle be removed after commissioning the lighting system or building automation system , because it is not necessary for the normal operation of the system, it may be useful to leave it in the building anyway, and possibly use it for monitoring bus traffic, for example for safety purposes or for visualization.

In summary, the present invention describes a bus system and method according to a proprietary protocol that contains a special function or broadcast command, referred to herein as "identification request", for querying the unique addresses of a plurality of modules coupled to the communication bus, and a function for forwarding these unique addresses over the communication bus, (herein referred to as "identification message"). Once these unique addresses are known, the modules can be accessed individually by read and write commands with absolute addressing. The big advantage of this is that these read and / or write commands will also work, even if the bus address (or bus addresses) in the module is / are incorrectly programmed or not at all.

Requesting the unique addresses is extremely fast. For example, suppose there are 100 modules, and that each identification message is sent through 4 frames. With the above-mentioned bit period of 150 ps, and a frame period of 2.7 ms, and three waiting times WT2F of 1.80 ms, and a waiting time W_ID of 1.95 ms between the messages, the total time is approximately: 100 x 18.15 ms = only about 1.8 seconds in total. And for 1000 modules, the total time for requesting and receiving all unique addresses is only around 18.1 s.

A bus system with modules that communicate according to this protocol makes it possible to request the unique addresses, and then remotely correct some errors and / or mistakes that took place during commissioning (the assignment of bus addresses) remotely over the bus.

The digital wired bus can have a total length of at least 10 m, or at least 20 m, or at least 30 m or at least 50 m. The distance between the Data Collection Module and the interface modules can be greater than 10 m, or greater than 20 m, or larger than 30 m, or larger than 50 m.

Claims (16)

A method (2500) for identifying a plurality of modules (D1, D2, D3) coupled to a wired communication bus and each containing a unique address (UA1, UA2, UA3) by a Data Collection Module ( GV) which is also coupled to the communication bus, the method comprising the steps of: a) sending (2501) over the communication bus an identification request (B0) through the Data Collection Module (GV) to the plurality of modules ( D1, D2, D3), to request their unique addresses (UA1, UA2, UA3); b) receiving (2502) the identification request (BO) by each of the plurality of modules (D1, D2, D3); c) successfully sending (2510) an identification message (B1, B2, B3) by each of the plurality of modules (D1, D2, D3) in response to the received identification request (B0), each identification message (B1, B2, B3) contains the unique address (UA1, UA2, UA3) of the relevant module (D1, D2, D3); wherein step c) for each of the plurality of modules (D1, D2, D3) comprises the following steps: i) waiting (2511) for the bus to be free for at least a predetermined time (WJD); ii) trying to send (2512) the identification message (B1, B2, B3) of the relevant module, wherein trying to send (2512) the identification message comprises sequentially trying to send each bit of the identification message, and wherein attempting to transmit each bit includes driving and monitoring the bus, and determining (2513) for each bit whether a collision has occurred on the bus, iii) and if a collision has occurred, stopping (2514) the sending the relevant bit and all subsequent bits of the identification message, and repeating steps i) to iii) until the identification message is sent without collision; and if no collision has occurred, decide that the identification message (B1, B2, B3) has been successfully sent, and no longer participate in trying to send the identification message. The method of claim 1, wherein step ii) of attempting to send (2512) is started as soon as the predetermined time (WJD) has elapsed. The method of claim 1 or 2, wherein the communication bus is a digital communication bus; and wherein a first signal form (101) is associated with a logical "1" bit, and a second signal form (102) different from the first signal form is associated with a logical "0" bit; and wherein the Data Collection Module (GV) and the plurality of modules (D1, D2, D3) are coupled to the communication bus in a wired-AND or a wired-OR configuration. A method for assigning at least one bus address (BA1) or at least two bus addresses (BA3, BA4) to a configurable module (D1; D3) of a plurality of modules (D1, D2, D3) that are connected to a wired communication -bus are coupled, each having a unique address (UA1, UA2, UA3), the method comprising the steps of: a) determining the unique addresses (UA1, UA2, UA3) of the plurality of modules (D1 , D2, D3) coupled to the bus by identifying the modules of any one of the preceding claims; b) sending a configuration message by the Data Collection Module (GV), wherein the configuration message contains the unique address (UA1; BA3, BA4) of the module to be configured (D1; D3) for addressing the module and assigning at least one bus address (BAI; BA3, BA4); c) receiving the configuration message by the plurality of modules (D1, D2, D3) coupled to the bus, and extracting the address (UA1; UA3) contained in the configuration message, and comparing the extracted address ( UA1) with the internal unique address (UA1, UA2, UA3) of the relevant module (D1, D2, D3), and if the extracted address (UA1) and the internal unique address are the same, proceed with step d), and if the extracted address (UA1) and the internal unique address are different, skip step d); d) extracting the at least one bus address (BAI; BA3, BA4) from the configuration message, and storing the at least one bus address (BAI; BA3, BA4) in a memory of the module (D1; D3) for later communication with other modules based on relative addressing. 5. A method for requesting data from at least one module to be interrogated (D1) selected from a plurality of modules (D1, D2, D3) which are coupled to a communication bus and which each have a unique address (UA1, UA2 (UA3), comprising: a) determining the unique addresses (UA1, UA2, UA3) of each of the plurality of modules (D1, D2, D3) coupled to the bus, by identifying the modules according to one of the preceding claims; b) sending a read message by the Data Collection Module (GV), wherein the read message contains the unique address (UA1) of the module to be interrogated (D1) to address the module, as well as one or more indicators of which information is requested; c) receiving the read message from the plurality of modules (D1, D2, D3) coupled to the bus, and extracting the address (UA1) contained in the read message, and comparing the extracted address (UA1) with the internal unique address (UA1, UA2, UA3) of the relevant module (D1, D2, D3), and if the extracted address (UA1) and the internal unique address are the same, proceed with step d), and if the extracted address (UA1) and the internal unique address are different, skip step d); d) sending an information message by the module to be interrogated (D1) to the Data Collection Module (GV), the information message containing data in accordance with the one or more indicators; e) receiving the information message from the Data Collection Module (GV). A method according to any one of the preceding claims, wherein the unique address of at least one of the plurality of modules (D1, D2, D3) comprises at least 18 bits, or at least 20 bits, or at least 24 bits, or at least 32 bits, or at least 40 bits, or at least 48 bits. A method according to any one of the preceding claims, wherein all messages over the bus, including the identification request and the identification messages, are sent by sending one or more fixed-length frames, each frame having one start bit, sixteen data bits, and one stop bit. A method according to claim 7, wherein a minimum wait time (WT2F) between two consecutive frames of the same message is less than a minimum wait time (WT2B) between frames of two different messages. A method according to claim 8, wherein the minimum wait time (W_ID) prior to an identification message is greater than the minimum wait time (WT2B) prior to a message that is not an identification message. A bus system for a building automation system, comprising; - a wired communication bus; - a plurality of modules (D1, D2, D3) which each have a unique address (UA1, UA2, UA3) and which are coupled to the communication bus; - a Data Collection Module (GV) that is linked to the communication bus; wherein each of the plurality of modules (D1, D2, D3) and the Data Collection Module (GV) are provided to jointly perform the method of any one of claims 1-9. A building automation system comprising a bus system according to claim 10, and further comprising one or more of the following features: i) and wherein the building automation system comprises at least one lighting system, wherein at least one of the modules is adapted to control a lighting element or a dimmer and / or at least one of the modules is adapted to read out at least one motion detector or presence detector or light sensor or switch; ii) and wherein the building automation system comprises at least one sun protection system, wherein at least one of the modules is adapted to control at least one motor of a sun protection, and / or at least one of the modules is adapted to read out at least one light sensor or switch or wind sensor; iii) and wherein the building automation system comprises at least one fire detection system, wherein at least one of the modules is adapted to read out at least one fire detector or smoke detector or temperature sensor; iv) and wherein the building automation system comprises at least one air conditioning system, wherein at least one of the modules is adapted to control an air conditioning module, and / or at least one of the modules is adapted to read out a temperature sensor or humidity sensor; v) and wherein the building automation system comprises at least one heating system, wherein at least one of the modules is adapted to control at least one valve or a pump or a heating element, and / or at least one of the modules is adapted for reading a temperature sensor; vi) and wherein the building automation system comprises at least one HVAC system, wherein at least one of the modules is adapted to control an air conditioning module or a heating element or a valve or a pump, and / or at least one of the modules is adapted for reading out of a temperature sensor or a humidity sensor; vii) and wherein the building automation system comprises at least one parking guidance system, wherein at least one of the modules is adapted to control at least one lighting element, and / or at least one of the modules is adapted to read out at least one motion detector or presence detector or switch; viii) and wherein the building automation system comprises at least one access control system, wherein at least one of the modules is adapted to control a door or an access, and / or at least one of the modules is adapted to read out at least one motion detector or presence detector or switch or identification module. A building automation system according to claim 11, further comprising at least one of the actuators and / or at least one of the sensors mentioned in claim 11. A building automation system according to claim 11 or 12, wherein the wired bus comprises at least two electrical conductors (BB, VO) that are galvanically isolated from each other but functionally coupled to each other by means of at least one signal amplifier (R1) with an optical coupling , which signal amplifier is also part of the bus system. A set of at least three interface modules for use in a bus system according to claim 10, or for use in a building automation system according to claim 11, wherein one interface module (GV) is provided for performing step a) of a method according to one of claims 1 to 9, and at least two other interface modules (D1, D2) are provided for performing steps b) and c) of the method according to one of claims 1 to 9. A set of at least three interface modules according to claim 14, wherein at least one of the interface modules (GV, D1, D2) further comprises an IR transceiver (306), and wherein the controller (301) of the interface interface in question the module is further provided with an IR protocol software for sending and receiving messages via the IR transceiver; wherein at least one of the interface modules (GV, D1, D2) further comprises an RF transceiver (306), and wherein the controller (301) of the relevant interface module is further provided with an RF protocol software for transmitting and receiving messages via the RF transceiver; wherein at least one of the interface modules (GV, D1, D2) further comprises a fiber optic transceiver, and wherein the controller (301) of the relevant interface module is further provided with a protocol software for sending and receiving messages via the fiber optic transceiver; wherein at least one of the interface modules (GV, D1, D2) further comprises a second bus interface, and wherein the controller (301) of the relevant interface module is provided to communicate both over the first bus interface via a first protocol according to any one of claims 1 to 9, as well as via a second protocol that is different from the first protocol over the second bus interface. A set of at least three interface modules according to claim 14 or 15, wherein at least one of the interface modules (GV, D1, D2) further comprises at least one built-in actuator for controlling a component of a building automation, and / or at least one built-in sensor or detector for reading a component of a building automation.