WO2017129574A1

WO2017129574A1 - Message delay management in lighting control networks.

Info

Publication number: WO2017129574A1
Application number: PCT/EP2017/051454
Authority: WO
Inventors: Bjorn Christiaan Wouter KAAG
Original assignee: Philips Lighting Holding B.V.
Priority date: 2016-01-29
Filing date: 2017-01-25
Publication date: 2017-08-03

Abstract

The present invention relates to a system (200) for controlling lighting control components (301) within a lighting control network (300) comprising two or more lighting control components controllable in accordance with a lighting scene defined in a lighting plan (204). The system comprises a processing unit configured to determine a set of two or more lighting control components involved in a first lighting scene, map the set of two or more lighting control components onto the communication network (100) topology, determine a time delay for respective commands sent to the respective lighting control components of the set of two or more lighting control components; and compute a time offset for commands to the respective lighting control components of the set of two or more lighting control components to switch each lighting control component of the set of two or more lighting control components at a determined point in time.

Description

Message delay management in lighting control networks

FIELD OF THE INVENTION

The present invention relates to lighting control networks. The present invention is in particular dedicated to compensation approaches for time delays occurring during operation of a lighting network resulting in uneven execution of control commands communicated through an underlying communication network.

BACKGROUND OF THE INVENTION

In modern application control networks, such as - but not limited to - lighting control networks, network management systems control communication paths through the communication backbone network underlying the application network. When using a Software Defined Networking (SDN) system as management system, a properly programmed SDN controller is capable of automatically selecting for instance the path with the least number of hops or with the best quality of service out of the multiple paths available in the communication mesh between end nodes, and will program the correct filters to pass data through a cascading structure of data- forwarding devices as depicted in Fig. 10. However, an SDN system in itself does not have context knowledge about a (lighting) application that is controlled via the programmed data paths. Thus, communication paths are selected independently of application layer specific requirements.

A new approach is suggested in European patent application 15183126.0 and 15183131.0, where a Software Defined Application (SDA) system analyses the application scenes in the application network and together with the information about the available network topology provided by the SDN system optimized paths are selected. The

optimization may be performed with regard to a minimal power consumption. Based on the knowledge of both the network and the application layer, the Software Defined Control system (SDC), comprising SDN and SDA, may determine schedules for effectively configuring end nodes and data ports of data forwarding devices and within the network system, to be set to low power state for a duration in which they are not required.

In communication networks such as SDN controlled networks as well as in typical "always on" networks, such as for example but not limited to (PoE) Ethernet computer networks, different network paths to the plurality of electrical loads in an application scene may cause different run times. In most network topologies short distances between a plurality of sensors and actuators required in the same application scene introduce very short delays. In other network topologies or larger networks runtime delays may become observable when a common switching command is sent to respective devices and these devices switch at observably delayed points in time. An uneven delay through differences in runtime will cause observable effects which are not desirable or not acceptable. For instance, an application control network may desire electrical loads to be switched at the same time. An example is a lighting control network with an application scene to switch on a plurality of lights at exactly the same time, as this enhances the perceived quality of lighting. Other application control networks may desire electrical loads to be switched in a sequential manner one after another with a predetermined intervals. An example is a lighting control network with creative lighting effects, such as a light wave.

The problem of uneven delays is exaggerated in the aforementioned energy saving network, which may periodically power down interlinks and in efficio cause different network paths through the network all the time, creating different delays from one moment to the other.

Additionally, in a typical SDN controlled network, the first time data arrives at a data port on a data forwarding device such as e.g. a data switch, a lookup sequence is executed with an SDN controller, which results in a communication path definition. This lookup sequence introduces a further short delay.

Hence, different network topologies may cause communication paths with different length, causing electrical loads in an application scene not to be switched at desired times due to runtime delays. Lookup sequences with the SDN controller may also or additionally introduce minimal delays at unplanned intervals.

SUMMARY OF THE INVENTION

It is an object of the present invention to provide an improved system and method for accurately controlling lighting control components within a lighting control system.

In an aspect of the present invention there is provided a system for controlling lighting control components within a lighting control system comprising two or more lighting control components and a sensor component controllable in accordance with a lighting scene defined in a lighting plan. The system comprises a processing unit configured to determine a set of two or more lighting control components involved in a first lighting scene, map the set of two or more lighting control components onto the communication network topology, determine a time delay for respective commands sent to the respective lighting control components of the set of two or more lighting control components based at least in part on measurement data provided by the sensor component; and based on the determined time delay compute a time offset for commands to the respective lighting control components of the set of two or more lighting control components to switch each lighting control component of the set of two or more lighting control components at a determined point in time.

In lighting control networks, such as - but not limited to - lighting control networks, different run times may be determined for data, e.g. control commands, sent via the network to respective lighting control components, e.g. sensors and actuators, required in accordance with a predefined lighting scene. To correct time delays for respective lighting control components, the system first determines the lighting control components required in accordance with one or more lighting scenes. The lighting control components are subsequently mapped onto the network topology, meaning that one or more network components, such as data forwarding devices, are determined which are required to forward data from the control system to the respective lighting control components. The control system may select a preferred path in accordance with a predetermined criterion, e.g. path, length transmission quality, etc. For each path through the network, the control system may determine a time delay for data sent to the respective lighting control components. Based on the time delay information, the control system may compute time offsets for commands to the respective lighting control components to enable execution of the respective commands at a determined point in time. By actively controlling time offsets for respective lighting control components, the control system can assure, for instance simultaneous switching of a group of lighting control components or switching of two or more lighting control components in a predetermined sequence to provide certain effects. The determined delay times may take into account the current status of the various lighting control components (idle, off) and the time required to reactivate them.

In a preferred embodiment the respective time offsets are used to determine an order in which the commands are transmitted to the respective lighting control components. The computation of respective time offsets for different lighting control components required in a lighting scene may be selected to influence or minimize the overall delay offsets, e.g. the command with the longest run time should be transmitted first in order to keep the necessary overall time offset as low as possible. For instance, in a lighting control lighting as a preferred embodiment a lighting scene may require to switch two or more lighting control components at the same time. The lighting control component, for which the largest time delay has been determined, may be addressed first by the control system, when transmitting the required commands to the lighting control components. For the remaining lighting components, time offsets are calculated such that the respective time delays plus the calculated time offsets result in receipt and execution of the command at the remaining lighting control components at the same time as for the first lighting component.

In a preferred embodiment the processing unit is configured to provide augmentation data based on the computed time offsets with the corresponding commands to the respective lighting control components. In addition or alternatively to using the time offsets to order a transmission queue, the control system may also determine augmentation data provided in the commands, such that execution of the command itself may be delayed to ensure execution of all commands provided to respective lighting control components at the desired points in time, e.g. simultaneously or staggered.

Augmentation data is additional data which provides additional information to base data. In the context of the invention, base data are commands, and augmentation data may include time offsets or some additional information (e.g. power ramp profile, duration).

In a preferred embodiment the respective time offsets and/or augmentation data computed in accordance with the first lighting scene are stored at the respective lighting control components. In case, a lighting scene is frequently used and the timing requirements are stable, e.g. in case the network topology and resulting path definitions according to predetermined selection criteria do not change much over time, calculated time offsets and/or augmentation data may be stored at the respective lighting control component and/or the control system to avoid recomputation and retransmission each time the lighting scene is triggered.

In a preferred embodiment the processing unit is further configured to initiate the submission of test messages to compute and/or validate the time offset for respective lighting control components in accordance with a received response to the test message. Test messages may be used in a commissioning phase or during operations to determine respective time offsets and/or validate determined time offsets after first computation or over time to detect changes in the required run times. Alternatively, the system may be implemented as data logger wherein the lighting control components are triggered by a (roving) test device and, thus, provide test messages for the control system. For instance, in a lighting control network the test device may trigger a sensor to fire up a corresponding actuator to generate data to be send to the control system.

In a preferred embodiment the respective determined points in time are exactly the same for all lighting control components. In order to simultaneously switch all lighting control components required in a lighting scene, the offsets have to be chosen such that all commands may arrive at their destination at the same point in time. For instance, in a lighting control lighting as a preferred embodiment, the simultaneous switching on of all lights in a room may be desired in order to enhance the perceived light quality.

In a preferred embodiment the respective determined points in time are delayed by predetermined intervals. In some lighting control network it may be desired to have respective lighting control components react in a staggered manner. For instance, in a lighting control lighting as a preferred embodiment, the staggered switching on of lights in a room may be desired in order to create a certain lighting effect, e.g. a running light or light wave, etc.

In a preferred embodiment the processing unit is further configured to compute the time offset for respective commands sent to the respective lighting control components of the set of two or more lighting control components in dependence of a type of the respective lighting control components. Different lighting control components may show a different responsiveness with regard to processing commands, especially, when previously set to a lower power mode (e.g. idle or off). The type of a lighting control component may be reported by the lighting control component itself during commissioning or operation or may be (manually) input to the control system.

In an aspect of the present invention there is provided a method for controlling lighting control components within a lighting control system comprising two or more lighting control components and a sensor component controllable in accordance with a lighting scene defined in a lighting plan. The method comprises determining a set of two or more lighting control components involved in a first lighting scene, mapping the set of two or more lighting control components onto the communication network topology, determining a time delay for respective commands sent to the respective lighting control components of the set of two or more lighting control components based at least in part on measurement data provided by the sensor component; and based on the determined time delay computing a time offset for commands to the respective lighting control components of the set of two or more lighting control components to switch each lighting control component of the set of two or more lighting control components at a determined point in time. In a preferred embodiment the method further comprises determining an order in which the commands are transmitted to the respective lighting control components based on the respective time offsets.

In a preferred embodiment the method further comprises augmentation data based on the computed time offsets with the corresponding commands to the respective lighting control components.

In a preferred embodiment the method further comprises storing the respective time offsets computed in accordance with the first lighting scene at the respective lighting control components.

In a preferred embodiment the method further comprises initiating the submission of test messages to compute and/or validate the time offset for respective lighting control components in accordance with a received response to the test message.

In a preferred embodiment the respective determined points in time are exactly the same for all lighting control components. Alternatively, the respective determined points in time are delayed by predetermined intervals.

In a preferred embodiment the method further comprises computing the time offset for respective commands sent to the respective lighting control components of the set of two or more lighting control components in dependence of a type of the respective lighting control components.

In an aspect of the present invention there is provided a computer program executable in an processing unit, the computer program comprising program code means for causing the processing unit to carry out a method as defined in the previous aspect of the invention when the computer program is executed in the processing unit.

It shall be understood that the system of claim 1, the method of claim 8 and the computer program of claim 15 have similar and/or identical preferred embodiments, in particular, as defined in the dependent claims.

It shall be understood that a preferred embodiment of the present invention can also be any combination of the dependent claims or above embodiments with the respective independent claim.

These and other aspects of the invention will be apparent from and elucidated with reference to the embodiments described hereinafter.

BRIEF DESCRIPTION OF THE DRAWINGS

In the following drawings: Figure 1 shows a domain model of an application network controlled by a software defined control network.

Figure 2 shows a flow diagram of a method for iterative computation of time offsets according to a preferred embodiment of the present invention.

Figure 3 shows a flow diagram of a method for executing time offset correction according to a preferred embodiment of the present invention.

Figure 4 shows an exemplary network topology with optimized path selection.

Figure 5 shows an exemplary integration of two software defined control systems.

Figures 6a-f show different alignment scenarios for lighting applications.

Figures 7a-c show a lighting applications with sequentially timed lights at equidistant intervals.

Figures 8a-c show a lighting applications with sequentially timed lights at increasing intervals.

Figure 9 shows a preferred embodiment of an application control network with different border network components.

Figure 10 shows a cascade of data forwarding devices.

Figure 11 shows a hybrid wired and wireless network in an application control network in accordance with a preferred embodiment of the present invention.

DETAILED DESCRIPTION OF EMBODIMENTS

Some embodiments are exemplary described in the context of lighting control applications as preferred embodiments. However, it is to be understood that the embodiments are not restricted to lighting control applications. The person skilled in the art will appreciate that the methods and systems may be exploited for any other control application system requiring a similar system topology.

In the following a software defined application (SDA) system provides knowledge about application specific requirements and instructions as stipulated in an application plan comprising one or more application scenes. For instance, an example of an SDA system is a software defined lighting (SDL) system that defines a lighting plan comprising one or more lighting scenes. A lighting scene may for example define

dependencies or interactions between application control components, e.g. which lamps are to be switched on, if a particular sensor is triggered. The lighting scenes may be defined for specific timeslots, such a day or night, weekdays, weekends, and so on. A network management system such as a software defined networking (SDN) system provides knowledge about the respective network components present in a mesh network constituting the backbone network of the application system and may control configuration of forwarding tables and the like. However, the network management system does not know about application specific connections between certain network components.

Together the SDA system and the network management system constitute a software defined control (SDC) system which combines both layers (application and network). The SDC system maps the application/lighting components onto the network topology and thus has the knowledge to decide which components or component parts may be switched off without degrading the capability of the (lighting) control network to execute a (lighting) application.

Figure 1 illustrates a domain model of a lighting control system 300 as a preferred embodiment of the present invention. SDC system 200 comprising SDA system 210 managing application plan 204 and the application scenes stipulated therein can consult a network management system 231 and dynamically configure communication paths 180 through a communication network 100 to a data port of a border network component 110 that is connected to a lighting control component 301. An (optional) energy source or energy storage 330 provides power to the application control component 301, if the border network component 110 does not provide power to the end node 301, e.g. via Power over Ethernet (PoE).

The SDA system is configured to compute offsets for network runtime delays for each application control component 301 specified in an application scene.

First, the SDA system analyzes a respective application scene or application scenes to determine the collaborating application control components, in a lighting control system. These application control components are usually actuators and sensors.

Then, the collaborating application control components are mapped onto the communication network such that the actual communication paths through the network are defined. Since the SDA system has knowledge about all required application control components and thus potential application control component that may be switched off, the actual communication paths may not necessarily be the path, the SDN system would have programmed under the premises of for instance least number of data forwarding devices (e.g. hops).

For each actual communication paths determined in the previous step, the SDA system determines time delays for application commands addressed to respective application control components stipulated in the application scene(s). Based on the determined delays, the system may organize transmission sequences and/or define time delay offsets for each command to compensate for the time delays.

The time delay offsets may be chosen such that the application control components change status at the same moment in time or at a predetermined exact sequence.

The system can be implemented in "always on" communication networks as well as in energy saving communication networks as explained herein below.

The collection of data about the time it takes to pass a command to each application control component collaborating in an application control scene may be based on the run time of a command, the number of hops it takes, or other data. In a preferred embodiment the SDA system will compensate determined differences in the runtime attempting to minimize the overall delay offset by either one or a combination of:

1. Selecting data paths with equal runtimes.

2. Reordering the sequence of the commands to be transmitted. The message with the longest transmission times are send first, followed by commands requiring shorter transmission times.

3. Incorporating a time offset in the message. This time offset is used by the receiving actuator as a run-down timer to wait until the actuator can switch the attached load. For instance, the largest time delay determined for an application control component within a group of commonly controlled application control components may determine the time delay offsets, such that, when compensated, all collaborating application control components switch a plurality of actuators at the desired time, that is, in this case the largest delay time.

In a preferred embodiment the SDA system is a software defined lighting (SDL) system. The SDL system first determines all actuators and sensors defined in a respective lighting scene. Then, the actuators and sensors are mapped onto the underlying communication network, e.g. backbone network of the lighting control network. In case the source node providing a particular lighting command is not in the vicinity of the end node, a plurality of data forwarding devices may be engaged in forwarding the command to the addressed end node. Depending on the runtime for the respective commands, the SDL system computes time offsets for the commands defined in the application control scene, to minimize the overall delay offset by for instance ordering of the command transmission in a predetermined sequence beginning with the command having the longest runtime and ending with the command having the shortest runtime. This will enable that the plurality of actuators is switched at almost exactly the same time or if desired in a specific desired sequence so as to create an enhanced lighting effect.

Fig. 2 and 3 show flow diagrams of exemplary implementations of preferred embodiments of the present invention, thereby not excluding different sequence of steps or alternative checks to achieve the result of the present invention.

As shown in Fig. 2, the system can learn and store delay offsets. After starting the method 1001 the system shall collect path updates 1002 of potential, available

communication paths 1003 through the present communication network. The system identifies an application scene 1004 to be instantiated, including all application control components defined therein. The application scene is mapped onto the network system i.e. a plurality of sensors and/or actuators that is defined by the application scene is mapped onto the available paths through the communication network 1005. The system may select a "best" path or plurality of paths 1006 according to predefined criteria, such as for example, but not limited to, an acceptable runtime with minimal overall differences between the plurality of paths required to support all sensors and actuators is the specific application scene. The system then transmits a test message into the network 1007. The targeted sensor or actuator shall answer with a response message 1008. When all sensors and/or actuators in the application scene have been addressed with a test message and transmitted a response back 1009, the system will analyze the overall delay 1010. The system shall decide if the delta between the overall delay is deemed acceptable against predetermined criterialOl 1. If the delta between the overall delay is not acceptable against said criteria, the system will compute a corresponding transmission sequence 1012 and/or compute augmentation data 1013 which is e.g. time offsets. The system then defines control messages with the augmentation data carried in the messages 1014. Another round of test 1007 and response 1008 will give feedback data to subsequent analysis of the overall delay 1010. If the delta between the overall delay is acceptable against the predefined criteria, the system stores the time offset(s) 1015, which shall include the transmission sequence of the messages for the components in the application control scene, and the augmentation data per message (i.e. the computed correction in time offset, an identifier to and/or the specific path corresponding to the specific sensor or actuator that the message has to travel, the delay for the actuator type), and finishes 1016 the procedure. The information may be stored onto the SDA system for later reference or on a remote system in communication with the SDA system. Alternatively, the information may be post processed and distributed into the network to a location close to the application components of a specific application scene. In that case a subset of the information specifically for the DfD 101 or application component 301 may be sent thereto.

Alternatively, the method may be implemented without a previous determination of communication paths updates and a best path analysis. Fig. 3 shows a corresponding flow diagram of such a simpler implementation as another preferred embodiment. After starting 1020 the method, an application control scene may be triggered 1021, that is the application control components are already mapped to the network topology. In a next step it is determined whether the available paths are the same as set out in the application control scene 1022. If the available paths are the same as set out in the application control scene, control messages are defined 1023 using previously determined and/or applied delay offsets 1024. If the available paths are not the same as set out in the application control scene, a transmission sequence is determined 1025 either aiming for equal or staggered time offsets. Alternatively or in addition, augmentation data may be determined 1026, inform of time offsets for respective commands to be sent through the network. Based on the transmission sequence and/or the augmentation data, a control message is defined 1023 and corresponding sequentially delayed and/or messages with augmentation data are transmitted 1027 and the method is finished.

It shall be understood that the method can work with or without previous augmentation data. The mechanism can work with messages received momentarily and directly compute the delay offset required or the mechanism can reuse information from previously used and well known paths.

In typical legacy lighting control applications, which may use an exclusive communication network with fixed communication paths, there is not much difference in the application scenes that are defined and/or the communication paths available within the network that are used over time.

However, in modern communication networks using power down functionality, which may be managed by an SDC system, the available or desirable communication paths through the network could differ considerably over time. In

2015PF0831 and 2015PF1070 the SDC system optimizes the selected paths based on predefined criteria such as an overall energy consumption etc.

The computation of delay offset values is explained based on the example network topology depicted in Fig. 4. According to an application scene actuators L10-L21 in room B shall be switched simultaneously. Actuators L14-L21, i.e. lights, are connected to data forwarding device S10, i.e. a data switch. Actuators L10 to L13 , i.e. lights, are connected to data forwarding device S4, i.e. a further switch. Actuators L10 to L12 are supposed to be of type A with a start-up delay time of 30 ms and actuators L13 to L21 shall have a start-up delay time of 200ms. An arbitrary transmission delay between messages is supposed to be 1 ms. After having sent test messages to all actuators L10-L21 and having received all response messages from the actuator, the system may collect the data in a table as shown for example in Table 1 below, so as to determine the runtime of the required commands.

The SDA system adds a type specific start-up delay time for type A and B, sorts the table from longest to shortest transmission time and corrects for the transmission delay between messages. Since there are 12 messages to be sent to the respective actuators, the last message is transmitted 12 ms after the first message. As a last step augmentation data is computed, which may, for example, be the difference between each message and the longest message (e.g. absolute value of (ABS)of ((message transmission time)-(maximum transmission time)). This augmentation data may be incorporated in a message and be transmitted to the receiver(s), e.g. the actuators.

The resulting message sequence with corresponding delays is shown in Table

2 below: msg actuator runtime Type +type delay + Tx-delay augment data

1 L13 195 B 395 395 0

2 L21 95 B 295 297 98

3 L14 90 B 290 294 101

4 L20 90 B 290 296 99

5 L15 85 B 285 293 102

6 L19 80 B 280 290 105

7 L18 75 B 275 287 108

8 L17 70 B 270 284 111

9 L16 50 B 250 266 129

10 L10 210 A 240 258 137

11 L12 205 A 235 255 140

12 Ll l 200 A 230 252 143

It shall be understood that different combinations of the above described steps can be performed to minimize differences in start-up times between actuators, e.g. ordering, adding augmentation data, etc. Start-up delay times are optional input data and may be known for specific component types and fed to the SDA system in advance or be measured by the SDA system during commissioning or operation. In a preferred embodiment of the present invention an SDL system of a lighting control network may discriminate between known typical startup times for different types of actuators in an application scene, e.g. Compact Fluorescent Light (CFL) usually have a longer start up time than for Light Emitting Diode (LED) lamps. The SDL system may alternatively or in addition discriminate between measured startup times for specific lamps, which may change over time. Example measurements are power, voltage or current measurements, measurement of the light intensity level with an irradiance sensor or measurements by an imaging system.

In a preferred embodiment of the present invention the SDC system may switch one or more ports of a data forwarding device instead of the actuator performing the action to switch the electrical load attached thereto. By switching the data port the actuator attached to the data port is switched off in efficio. Switchable data forwarding devices are in detail described in EP patent application 15183131.0. The SDA system can analogously configure the delay offset for one or more data ports of a data forwarding device. In a preferred embodiment of the present invention the SDA system deploys machine learning techniques to gather information on past usage and derive optimized decisions for future applications.

In a preferred embodiment of the present invention the application control network may support PoE. However, typically only the "last drop" cable before the application control component, such as a lamp may be a PoE data-switch. Depending on the building architecture and desired installation of cabling, all or only parts of the

communication network's data- forwarding devices would be PoE. Instead of a data-switch (or router or gateway) supporting PoE, alternative technologies can be used to power an electrical load attached to said data-switch. Fig. 9 shows different implementations of border network component 101 of the domain model in Fig. 1. A power scheduling data forwarding device 102 can implement more than one way to switch off the electrical load 301 that is attached thereto. One method is to switch of power to the application control component 301 and thus power it down "in efficio", since application control component 301 relies on the power delivered via the communication cable to data forwarding device 102, as is for example the case with PoE.

In another embodiment, a single or a plurality of (lighting) application control component(s) 301 may be powered by another energy source 330 (a DC or AC power grid or an energy storage), but switching the application control components on and off is controlled via a wireless communication link between a wireless bridge 103 and 301.

In another embodiment, a single or a plurality of (lighting) application control component(s) 301 may be powered via the AC or DC grid but switching the application control components on or off is controlled by an EIB/K X actuator 302, connected to the SDA system by an EIB/KNX gateway 105. In addition, communication commands could be sent via the EIB actuator or alternatively via a wired link between the data forwarding device 104 and application control component 301.

In another embodiment, the data forwarding device 104 can be switched on or off via a EIB/KNX gateway 302, which is connected via a EIB gateway 105 to the communication network 100. All these embodiments are examples how an application control component 301 may be connected to the communication network 100.

The time offset information may be locally stored on the border network component directly communicatively coupled to the application control component ,e.g. data forwarding device 102 in Fig.9, while for other implementations, e.g. wireless bridge 103, data forwarding device 104 and EIB/RnX gateway 105/302, the information may preferably reside at the SDA system 210, or in the application control component 301 or a combination thereof. The SDA system can manage the location(s) where to store the time offset information for a(ny) application scene and a(ny) application control component 301 therein.

In a preferred embodiment of the present invention the communication network may exploit power down functionality. In large networks the SDC system can be positioned on one side of the network while the specific sensor(s) and/or actuator(s) required by a specific application scene are positioned far away on the opposite side of the

communication network. In order to communicate commands from the SDC system to the respective application control components, the intermediate network components, e.g. data forwarding devices in the communication network, cannot be powered down (idle/switched off) but have to remain constantly active. The network almost never rests. To improve the situation, the SDC system could distribute the calculated augmentation data to be stored locally by application control components or network components required in an application scene. For example, the SDL system may compute the time offsets for transmission between the sensors and actuators required by an application scene. The actuators and sensors can use local paths directly in between the sensors and actuators, without exchanging commands with or via the SDL. The SDL system will assist and compute overall time offsets and provide them to the sensors that triggers the application scene. The responsible sensors may store the information and reuse it on future occasions. The SDL system, having knowledge about changes in a.) the (non)availability of the communication network paths and b.) any application scene or changes therein, may choose to update the distributed data, if this is deemed necessary.

In a preferred embodiment of the present invention the SDC system may also be implemented as a data logger talking to a roving test device. The test device may trigger sensors to fire up the actuators to generate analysis data for the system. This data can be used to compute and/or validate delay offsets and give due feedback on potential optimizations.

In a preferred embodiment of the present invention the communication network 100 may be shared with other control applications. Control applications may interact with one another to improve decisions to limit overall delays in respective application scenes as depicted ion Fig. 5. Naturally, a system comprising network control system 231, SDA system 210 and application plan 204 may interact with one or more other systems, e.g.

comprising network control system 232, SDA system 211 and application plan 205 from other building works, wherein interfaces may be defined between the network control systems 231 and 232 and/or SDA system 210 and 211. An example is the integration of the building work "lighting" with the building works "solar shading" or "HVAC" or entirely different building works. In that case the SDL system (e.g.210) could be required to obtain knowledge about certain communication paths through the network 100 that could be required for the sensors and actuators in an application scene from another building work. The SDL system may communicate with another SDC system, for example with the SDA 211 system, the network control system or both, to exchange information. It shall be clear that many interfaces, present or newly defined can be used to integrate systems, to achieve that multiple SDC systems can align each other with respect to time delay optimizations.

By determining a specific order, in which commands are provided to the application control components, or by specifying time offsets for respective application control components a variety of lighting effects may be realized, of which some examples will be described in the following.

Fig. 6a-c show a plurality of actuators (i.e. lights) which in accordance with the same application scene shall be commanded to change status at strictly the same time. Wherein different runtime delays and/or startup times may lead to different switching times as depicted in Fig. 6b, the SDL system may compensate for these differences and switch all lamps at exactly the same time as shown in Fig. 6c. The plurality of lights can also be grouped, for example in one or more application scenes, to be switched at subsequent times, as shown in Fig. 6d-f. Again, different runtime delays and/or startup times may lead to blurred switching times as depicted in Fig. 6e. The SDL system may compensate for the differences and switch for each group the first group of lamps at exactly the same time and the second group of lamps at exactly a second time following the first time as shown in Fig. 6f.

An SDL systems as of a preferred embodiment of the present invention can align (quantize) the times for the status change of a plurality of actuators, which would switch at irregular times as shown in Fig. 7b, to switch with equidistant intervals in between, as shown in Fig. 7c and thus result in a running light effect at a constant "velocity".

The intervals between the switches may also be dynamically adapted to create an accelerating/slowing running effect. As an example a corridor is shown in Fig 8a having a plurality of lights installed at equidistant spots. Uncorrected, the lights would switch as depicted in Fig. 8b without a recognizable pattern. The SDL system may program time delay offsets to achieve that upon entering the dark corridor the light LI furthest away from the moving actor is lit first and the subsequent lights are lit in a dynamic effect running or rolling towards the moving actor. The interval a between the first status changes of lights LI and L2 is evenly increased until the last interval β between lights LI 1 and LI 2.

Figure 11 shows an exemplary hybrid communication network. An application scene may require the usage of application control components (e.g. 303..308, 501..502) that are connected to the SDC system 200, comprising network management system 231 and SDA system 210, via a wired or wireless communication link. In a wired network the application control components 303-306 may be connected via data forwarding devices S51- S55 with well known run time delays. For application control components 307, 308 and 600 connected via a star network topology (as is for example possible with WiFi and Bluetooth), there is only a single hop 400. Although under certain conditions there could be a spread in runtime delays, an average could be computed to increase the likeliness that a plurality of (lighting) application control components is switched at the respective, desired points in time. For application control components connected via a mesh wireless network topology (as is for example possible with Zigbee or the WiFi 802.1 IS version), source routing may be used in accordance with a preferred embodiment to increase the likeliness that future

communication sessions will reuse communication paths and therefore reduce the amount of path options for which a time delays offset must be computed and maintained.

Procedures like determining delay times, computing delay time offsets, determining available data paths and programming and adapting data paths, et cetera performed by one or several units or devices can be performed by any other number of units or devices. These procedures and/or the control of the application control system in accordance with the method for controlling application control components can be implemented as program code means of a computer program and/or as dedicated hardware.

A computer program may be stored/distributed on a suitable medium, such as an optical storage medium or a solid-state medium, supplied together with or as part of other hardware, but may also be distributed in other forms, such as via the Internet or other wired or wireless telecommunication systems.

While the invention has been illustrated and described in detail in the drawings and foregoing description, such illustration and description are to be considered illustrative or exemplary and not restrictive; the invention is not limited to the disclosed embodiments. Other variations to the disclosed embodiments can be understood and effected by those skilled in the art in practicing the claimed invention, from a study of the drawings, the disclosure, and the appended claims. In the claims, the word "comprising" does not exclude other elements or steps, and the indefinite article "a" or "an" does not exclude a plurality. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage. Any reference signs in the claims should not be construed as limiting the scope.

Claims

CLAIMS:

1. System (200) for controlling lighting control components (301, LI -LI 6) within a lighting control system comprising two or more lighting components (LI -LI 6) and a sensor component controllable in accordance with a lighting scene defined in a lighting plan (204), the system comprising a processing unit configured to

determine a set of two or more lighting control components (LI -LI 6) involved in a first lighting scene,

map the set of two or more lighting control components onto the communication network (100) topology,

determine a time delay for respective commands sent to the respective lighting control components (L 1 , ... ,L 16) of the set of two or more lighting control components based at least in part on measurement data provided by the sensor component; and

based on the determined time delay compute a time offset for commands to the respective lighting control components (L 1 , ... ,L 16) of the set of two or more lighting control components to switch each lighting control component of the set of two or more lighting control components at a determined point in time (tl , t2, ...tl 6).

2. System (200) according to claim 1, wherein the respective time offsets are used to determine an order in which the commands are transmitted to the respective lighting control components.

3. System (200) according to claim 1 or 2, wherein the processing unit is configured to provide augmentation data based on the computed time offsets with the corresponding commands to the respective lighting control components.

4. System (200) according to claim 1, wherein the respective time offsets computed in accordance with the first lighting scene are stored at the respective lighting control components.

5. System (200) according to claim 1, wherein the processing unit is further configured to initiate the submission of test messages to compute and/or validate the time offset for respective lighting control components in accordance with a received response to the test message.

6. System (200) according to claim 1-3, wherein the respective determined points in time

(i) are exactly the same (tl; t2) for all lighting control components; or

(ii) are delayed (t 1 -t 16) by predetermined intervals (α, β).

7. System (200) according to claim 1, wherein the processing unit is further configured to compute the time offset for respective commands sent to the respective lighting control components of the set of two or more lighting control components in dependence of a type of the respective lighting control components.

8. Method for controlling lighting control components (301, LI -LI 6) within a lighting control system comprising two or more lighting control components and a sensor component controllable in accordance with a lighting scene defined in a lighting plan (204), the method comprising

determining a set of two or more lighting control components (LI -LI 6) involved in a first lighting scene,

mapping the set of two or more lighting control components onto the communication network topology,

determining a time delay for respective commands sent to the respective lighting control components (L 1 , ... ,L 16) of the set of two or more lighting control components based at least in part on measurement data provided by the sensor component; and

based on the determined time delay computing a time offset for commands to the respective lighting control components (L 1 , ... ,L 16) of the set of two or more lighting control components to switch each lighting control component of the set of two or more lighting control components at a determined point in time (tl, t2,...tl6).

9. Method according to claim 8, further comprising determining an order in which the commands are transmitted to the respective lighting control components based on the respective time offsets.

10. Method according to claim 8 or 9, further comprising augmentation data based on the computed time offsets with the corresponding commands to the respective lighting control components.

11. Method according to claim 8, further comprising storing the respective time offsets computed in accordance with the first lighting scene at the respective lighting control components.

12. Method according to claim 8, further comprising initiating the submission of test messages to compute and/or validate the time offset for respective lighting control components in accordance with a received response to the test message.

13. Method according to claim 8-10, wherein the respective determined points in time

(i) are exactly the same for all lighting control components; or (ii) are delayed by predetermined intervals (α, β).

14. Method according to claim 8, further comprising computing the time offset for respective commands sent to the respective lighting control components of the set of two or more lighting control components in dependence of a type of the respective lighting control components.

15. A computer program for controlling lighting control components (301, LI - LI 6) within a lighting control system comprising two or more lighting control components controllable in accordance with an lighting scene defined in an lighting plan (204), the computer program being executable in an processing unit, the computer program comprising program code means for causing the processing unit to carry out a method as defined in claims 8-14 when the computer program is executed in the processing unit.