To eliminate errors in the firmware of a lighting bus user or for providing new/other features at the lighting bus user, it may be desirable to replace the firmware, that is to say the software by means of which the lighting bus user is operated and/or controlled, with a new or different firmware software status (software update using update software). However, the method described is not restricted to updating firmware but can also be used for updating other software components of the lighting bus user.
From WO 2006/066884 A1, a method for programming an individual operating device for light-emitting means is known in this context in which the firmware of an operating device for light-emitting means is updated or changed, respectively, via an interface.
In comparison, the present invention relates especially to the parallel updating of a multiplicity of lighting bus users.
For this purpose, lighting bus users available at a bus are determined, e.g. by a connected central processing unit, and subsequently lighting bus users are selected which are intended to be updated. In this context, the available lighting bus users can be combined for an update in accordance with various criteria. For example, lighting bus users of the same type are divided into classes. The invention then allows software updates to be provided for a multiplicity of different lighting bus users, e.g. for all lighting bus users of different classes, efficiently transmitted and imported to the respective lighting bus users.
In this context, the lighting bus users are connected to one or more central processing units via which the update process is controlled. In particular, individual or several lighting bus users, one or more lighting bus user classes or also all connected lighting bus users can be selected for an update via the central processing unit. The central processing unit can provide an update software, i.e. a computer program product, by means of which lighting bus users can be operated, and transmit this software update to the selected lighting bus users.
Transmitting the update software, which will be described in greater detail in the text which follows, can be controlled by a user in order to establish, for example, when update software is to be imported to a selected lighting bus user. Thus, for example, it can be established that certain lighting bus users are to be supplied with the update software at night or within certain periods of time. In this context, the central processing unit can also predict, e.g., how much time is consumed by importing update software to the selected lighting bus users. If the time determined is, e.g., outside an available time window, the central processing unit can divide the importing of the update software over several time windows or propose such a division to a user.
In a first step, the central processing unit can identify and list lighting bus users. After that, the update software is imported, e.g. block by block, via the bus to the lighting bus users previously selected by means of an update identification (update ID) issued by the central processing unit for a software update.
During a block-by-block transmission of the update software, it is determined, after one block has been transmitted, which bus users have received the block correctly. If a disturbance occurs during the transmission of the update software in the case of one or more lighting bus users, only the blocks received defectively or not received will be retransmitted in a subsequent step.
During the transmission of the software update to the selected lighting bus users, the lighting bus users which are not updated can continue to be operated regularly and controlled by control commands transmitted via the bus.
Each selected lighting bus user is identifiable by an unambiguous ID. The unambiguous ID can be read out by the lighting bus user. A detection service, a so-called poll manager, which is executed, for example, on the central processing unit, identifies all devices connected to the bus so that a list of all connected devices can be set up for a user. The user then determines tasks by means of which it is determined which lighting bus users are supplied with a software update.
In this context, lighting bus users can be selected as already mentioned. Similar lighting bus users, i.e. lighting bus users which have, e.g., similar hardware and can therefore be updated with the same update software, can be provided with a single update identification and/or combined in lighting bus user classes. Lighting bus users of one class are then supplied with update software whilst other lighting bus users/lighting bus user classes can be supplied with other software updates.
The lighting bus users can also be selected in accordance with their location/their position in a building. It is thus possible, e.g., to provide all lighting actuators (operating devices for light-emitting means) on one storey with update software whilst lighting actuators at another location are not updated. A selection according to other criteria is also possible. Thus, for example, lighting bus users in different rooms (e.g. unrented rooms in a hotel) can also be selected for a software update.
The user can provide a configuration for the software update depending on the task. Such a configuration can consist in specifying additional parameters for the software update. In addition, it can be specified which software version the selected lighting bus users are to be updated to also in dependence on the software status already present.
After the task has been created, a control program, an update tool, executed on the central processing unit sends out, e.g., an initialization command with the unambiguous update identification to each of the selected lighting bus users. By means of the update identification, the lighting bus users which are to be updated with the software update can be placed into a so-called boot loader mode. In this context, the update identification can differ from task to task.
After sending out the initialization command, the central processing unit begins with transmitting a software update, i.e. with the, e.g., block-by-block transmitting of the update software to the selected lighting bus users. In this context, the update software does not need to be present in the central processing unit but can also be stored in a connected storage medium or a memory also connected to the bus.
In the block-oriented transmission, data are periodically transmitted which comprise software update data and the update identification. By this means, each lighting bus user on the bus can detect whether received data are to be evaluated or can be discarded. Data are sent out until all software update data have been transmitted. After conclusion of the transmission, a check takes place in each lighting bus user which is terminated with an update end message to the central processing unit.
In this process, e.g., a checksum is calculated at the lighting bus user and transmitted to the central processing unit. By means of the checksum information, the central processing unit can determine whether a lighting bus user has received the entire software update correctly. The data or blocks are also provided with checksum information and on reception of data by a lighting bus user it is thus possible to determine whether the lighting bus user has received sent data correctly. After the reception of data/blocks, a message/return message can then be sent to the central processing unit. In this message, it is possible to convey whether the transmission was successful or not.
By means of the return message of the lighting bus users, the central processing unit can indicate blocks received correctly and log blocks not received correctly and display corresponding information to the user.
By means of the method described, lighting bus users of different classes can be supplied in parallel with software updates. As a precursor to the software update, the tasks can be prepared which are then performed automatically by the central processing unit. Due to the checking of individual blocks in the block-oriented transmission, a correct transmission can be determined. It is also possible to determine blocks transmitted incorrectly and only to retransmit the blocks transmitted incorrectly to the lighting bus user.
The invention is therefore based on the object of providing a novel option for updating lighting bus users.