Parallel programming and updating of lighting technology for bus passengers

Description

Introduction

[0001] The present invention relates to a method for programming or updating software versions, in particular firmware, of lighting technology bus participants with update software.

[0002] Lighting technology bus devices are devices connected via a bus, especially a two-wire bus, such as sensors, actuators, especially control gear for lamps, and user interfaces. Of course, other lighting technology bus devices that are at least partially operated and / or controlled by software can also be updated. Background of the invention

[0003] To eliminate errors in the firmware of a lighting bus device or to provide new / different features to the lighting bus device, it may be desirable to replace the firmware, i.e., the software used to operate and / or control the lighting bus device, with a new or different firmware version (software update with update software). However, the described method is not limited to updating firmware; it can also be used to update other software components of the lighting bus device.

[0004] From WO 2006 / 066884 A1, a method for programming an individual operating device for lamps is known, in which the firmware of an operating device for lamps is updated or changed via an interface.

[0005] US 2010 / 0122245 A1 discloses a field device for downloading new software from a host system via a fieldbus and replacing current software currently being executed with the new software. The field device includes a history generation and management section that generates and stores history information of the current software when the new software is downloaded from the host system.

[0006] US 2008 / 0184151 A1 provides a system and / or method for facilitating the management of a device in a radio frequency identification (RFID) network. A radio frequency identification (RFID) network may include at least one device that receives data from a tag. An upgrade component may evaluate at least one device and, based on the evaluation, identify an applicable portion of firmware for the device. The applicable portion of firmware may be deployed independently on the device.

[0007] In contrast, the present invention relates in particular to the parallel updating of a plurality of lighting technology bus participants.

[0008] For this purpose, available lighting bus devices on a bus are identified, e.g., by a connected central unit, and then a selection of lighting bus devices to be updated is made. The available lighting bus devices can be grouped for an update according to various criteria. For example, lighting bus devices of the same type are divided into classes. The invention then allows software updates to be provided for a large number of different lighting bus devices, e.g., for all lighting bus devices of different classes, to be transmitted efficiently, and to be uploaded to the respective lighting bus devices.

[0009] The lighting technology bus devices are connected to one or more central units, which control the update process. In particular, the central unit can select individual or multiple lighting technology bus devices, one or more lighting technology bus device classes, or even all connected lighting technology bus devices for an update. The central unit can provide update software, i.e., a computer program product with which the lighting technology bus devices can be operated, and transmit this software update to the selected lighting technology bus devices.

[0010] The transmission of the update software, as described in more detail below, can be controlled by a user, for example to specify when an update software is to be installed on a selected lighting technology bus device. For example, it can be specified that certain lighting technology bus devices are to be supplied with the update software at night or within certain time periods. The central unit can, for example, also make a prediction about how much time it will take to install an update software on the selected lighting technology bus devices. If the determined time lies outside an available time window, for example, the central unit can divide the installation of the update software into several time windows or suggest such a division to a user.

[0011] In a first step, the central unit can identify and list lighting technology bus participants. The update software is then installed, e.g., block by block, via the bus on the previously selected lighting technology bus participants based on an update ID assigned by the central unit for a software update.

[0012] When transmitting the update software in blocks, after each block is transmitted, the system determines which bus devices have correctly received the block. If one or more lighting technology bus devices experience an error transmitting the update software, only the blocks that were incorrectly received or not received are retransmitted in a subsequent step.

[0013] While the software update is being transmitted to the selected lighting bus devices, the lighting bus devices that are not being updated can continue to operate normally and be controlled by control commands transmitted via the bus.

[0014] Each selected lighting bus device is identified by a unique ID. This unique ID can be read by the lighting bus device. A detection service, a so-called poll manager, which runs on the central unit, for example, identifies all devices connected to the bus, allowing a list of all connected devices to be compiled for a user. The user then defines tasks that determine which lighting bus devices receive a software update.

[0015] As already mentioned, lighting bus devices can be selected. Similar lighting bus devices, i.e., lighting bus devices that, for example, have similar hardware and can therefore be updated with the same update software, can be assigned a single update identifier and / or grouped into lighting bus device classes. Lighting bus devices of one class are then provided with one update software, while other lighting bus devices / lighting bus device classes can be provided with different software updates.

[0016] The lighting technology bus devices can also be selected based on their location within a building. This makes it possible, for example, to update all lighting actuators (operating devices for lamps) on one floor, while not updating lighting actuators elsewhere. Selection based on other criteria is also possible. For example, lighting technology bus devices in different rooms (e.g., unoccupied rooms in a hotel) can be selected for a software update.

[0017] The user can provide a configuration for the software update for each task. Such a configuration can consist of specifying additional parameters for the software update. Furthermore, it can be specified which software version the selected lighting technology bus devices should be updated to, depending on the existing software version.

[0018] After creating the task, a control program running on the central unit, such as an update tool, sends an initialization command with the unique update identifier to each of the selected lighting bus devices. The update identifier can be used to place the lighting bus devices that are to be updated with the software update into a so-called bootloader mode. The update identifier can vary from task to task.

[0019] After sending the initialization command, the central unit begins transmitting a software update, e.g., transmitting the update software block by block to the selected lighting technology bus devices. The update software does not have to be located on the central unit; it can also be stored on a connected storage medium or a memory device also connected to the bus.

[0020] With block-by-block transmission, data is transmitted periodically, including software update data and update identification. This allows each lighting technology bus device on the bus to determine whether received data should be evaluated or discarded. Data is sent continuously until all software update data has been transmitted. After transmission is complete, a check is performed on each lighting technology bus device, which concludes with an "end of update" message to the central unit.

[0021] For example, a checksum is calculated on the lighting bus device and transmitted to the central unit. Using this checksum information, the central unit can determine whether a lighting bus device has correctly received the entire software update. The data or blocks are also provided with checksum information, and when a lighting bus device receives data, it can thus be determined whether the lighting bus device has correctly received the transmitted data. After receiving data / blocks, a message / response can then be sent to the central unit. This message can indicate whether the transmission was successful or not.

[0022] The feedback from the lighting technology bus participants enables the central unit to display correctly received blocks and log incorrectly received blocks and display corresponding information to the user.

[0023] Using the described method, lighting technology bus devices of different classes can be supplied with software updates in parallel. Prior to the software update, the tasks can be prepared, which are then executed automatically by the central unit. By checking individual blocks during block-by-block transmission, correct transmission can be determined. Furthermore, it is possible to identify incorrectly transmitted blocks and retransmit only the incorrectly transmitted blocks to the lighting technology bus device.

[0024] The invention is therefore based on the object of providing a novel possibility for updating lighting technology bus participants. Summary of the invention

[0025] This object is achieved by the invention claimed in the independent claims. Further developments of the present invention are the subject of the dependent claims.

[0026] According to a first aspect of the invention, a method for programming lighting technology bus participants is specified, comprising the steps of: determining available lighting technology bus participants, e.g. sensors and / or actuators, by a central unit connected to the lighting technology bus participants via a bus, selecting, by means of the central unit, at least one lighting technology bus participant from the available lighting technology bus participants, putting the selected lighting technology bus participants into an update mode, allocating an update identification (update ID) to the lighting technology bus participants and transmitting update software, in particular firmware, provided with the update identification to the selected lighting technology bus participants.

[0027] Lighting technology bus participants are: Control gear for lighting devices such as gas discharge lamps, LEDs, OLEDs, halogen lamps, etc. Sensors such as motion, smoke, or light sensors and control units, possibly designed as user interfaces (e.g., dimmers, touchscreens, etc.)

[0028] It can be determined whether the update software was transferred without errors.

[0029] A lighting technology bus device can be put into operating mode as soon as the update software has been transmitted without errors and has been completely written.

[0030] A lighting technology bus participant can be operated in update mode by a bootloader.

[0031] The update software can be delivered in blocks.

[0032] It can be determined whether the update software / update software blocks were transmitted without errors and the determination result can be logged for each selected lighting technology bus participant.

[0033] After the transmission of the entire update software has been completed, the update software or the update software blocks can be transmitted again to the lighting technology bus participants for which an error-free / non-transmission was logged.

[0034] The programming of selected lighting technology bus participants can be time-controlled.

[0035] The lighting technology bus participants can be selected according to type, hardware version and / or location / installation site.

[0036] The selection of lighting technology bus participants can include lighting technology bus participants of different types.

[0037] Each lighting technology bus device type can be assigned an update identifier.

[0038] An update software can be transmitted for each lighting technology bus participant type.

[0039] The transmitted update software / transmitted update software blocks for a lighting bus participant can be written into a buffer of the lighting bus participant and the buffer can hold at least more than one block.

[0040] All update software blocks present in a buffer of a lighting technology bus participant can be written into an update software memory.

[0041] All update software blocks present in the buffer can be written to the update software memory before new update software blocks are received.

[0042] After writing the update software / one or more update software blocks, feedback about the success of the writing can be sent to a central unit.

[0043] After successfully writing the update software / all update software blocks, the bootloader of a lighting technology bus participant can check whether the update software is error-free, e.g. by determining and / or comparing a checksum.

[0044] According to a further aspect, the invention provides a lighting technology bus subscriber, comprising: a first memory area in which a bootloader is stored, a second memory area for receiving update software, a means for receiving data, a means for transmitting data.

[0045] The lighting technology bus participant can have a buffer for receiving update software or update software blocks.

[0046] The update software can put the lighting technology bus device into update mode upon receiving an initialization command.

[0047] The bootloader can receive an update identification.

[0048] The bootloader can determine whether a received update software / received update software blocks are intended for the lighting technology bus participant or not based on an update identification, a hardware ID and / or other parameters.

[0049] The bootloader can be active in update mode and receive an update software / update software blocks from a central unit and write them to the second memory area.

[0050] The bootloader can check whether the update software was received without errors.

[0051] The bootloader can send a feedback message to a central unit indicating that the update software / update software blocks were not transmitted correctly.

[0052] In a further aspect, the invention provides a computer-based central unit configured to execute control software, determine available lighting technology bus participants, determine suitable update software for the determined lighting technology bus participants, provide a user interface for selecting lighting technology bus participants, put selected lighting technology bus participants into an update mode by transmitting an initialization command, and transmit update software to the selected lighting technology bus participants.

[0053] The computer-based central unit may further be configured to receive messages / feedback regarding the transmission of the update software.

[0054] The computer-based central unit may further be configured to log messages about the transmission of the update software.

[0055] The update software can be delivered in update software blocks.

[0056] The computer-based central unit can further be configured to put the corresponding lighting technology bus participant into an operating mode after successful transmission of the update software / update software blocks.

[0057] The computer-based central unit can further be configured to resend unsuccessfully transmitted update software / update software blocks to the corresponding lighting technology bus participants.

[0058] The update software can be delivered on a time-controlled basis.

[0059] The computer-based central unit can assign an update identification to each lighting technology bus device type.

[0060] The computer-based central unit can transmit update software for each lighting technology bus participant type.

[0061] Finally, the invention provides a system comprising at least one lighting technology bus subscriber, as described above, and a computer-based central unit, as described above, which is configured to carry out a method as described above. Short description of the characters

[0062] Fig. 1 shows an example division of the memory of a lighting technology bus participant into a memory for the bootloader, firmware (update software / application) and RAM memory. Fig. 2 shows an example of logging by the central unit. Fig. 3 shows a rough flow chart for the inventive process. Fig. 4a shows a more detailed flowchart representation of the inventive method from the perspective of the central unit. Fig. 4brepresents a flowchart that shows the step "Perform update" from Fig. 4a clarified. Detailed description of the invention

[0063] The invention allows the use of lighting technology bus devices whose software can be updated and which therefore do not have to be replaced for error corrections or to provide functional extensions.

[0064] To do this, a lighting technology bus device must be equipped with a bootloader that allows a firmware update. Where reference is made below to a firmware update using update software, it should be understood that software updates for other software, especially applications, can also be performed in a similar manner, and that other software components can also be updated. Updating the firmware is also referred to as "flashing," which specifically refers to writing the update software to a memory designated for the update software.

[0065] First, the hardware-related aspects of the bootloader are described.

[0066] The bootloader is implemented as generically as possible to allow for easy adaptation to different hardware platforms. At least minor adjustments to the bootloader can be made for each lighting technology bus device, thus creating device-specific bootloaders.

[0067] The bootloader uses an abstraction layer, a so-called hardware abstraction layer (HAL), on which the firmware / application is built, to fundamentally control the hardware for which it is used.

[0068] Corresponding drivers for different hardware variants (e.g., LM3SXXX controller versions, etc.) may also be available. The bootloader can also include protocol implementations for various supported interfaces (serial, Ethernet, USB, etc.) as well as low-level routines for accessing various hardware elements. The bootloader can also use existing protocols (e.g., a protocol stack for the Luxmate bus).

[0069] The bootloader also has access to memory (e.g., flash memory) and provides the firmware with appropriate functions for accessing this memory. For a software update, the bootloader accesses the memory via a memory controller and its registers. One or more of the following functions are available, among others: Selecting a time for refreshing to match a clock frequency of a processor in use, erasing a memory page (e.g., a one-kilobyte (kB) flash memory page), writing a block to memory.

[0070] The block can, for example, begin with an address divisible by four and be a multiple of 4 bytes long. It can be designed to write a memory address a maximum of twice before a corresponding memory page for the memory address is erased.

[0071] It is also planned to protect the firmware memory in blocks from accidental overwriting. However, it should be noted that if the protection is stored persistently, the bootloader may no longer be able to be updated, as the write protection cannot be reversed. Therefore, the write protection is set via the bootloader every time the lighting technology bus device is reset, and persistent storage is avoided. The protection can be activated by setting a value in a register.

[0072] To signal the current bootloader operating state, a signaling device, e.g., an LED, is preferably provided on the lighting bus device. This can be used to signal the state of the software running on the lighting bus device, e.g., whether the firmware is defective and / or the bootloader is actively waiting for a software update. This can be done, for example, by a visually and / or acoustically perceptible signal. A signal distinguishable from these is generated when the bootloader has been placed into an initialization state via an initialization command.

[0073] The lighting technology bus device can contain multiple memory units and / or memory areas. Generally, the bootloader and firmware share a memory (e.g., flash memory) in which the program code of both components, as well as any other parameters (e.g., configurations), are stored. During operation, an additional memory (e.g., RAM, SRAM) or memory area is available for executing the bootloader or firmware, respectively, with the components normally being executed exclusively. An example memory allocation is shown in Fig. 1 shown.

[0074] Care must be taken to ensure that safeguards are in place to prevent the two components from overwriting each other.

[0075] In order for the bootloader of a lighting technology bus participant to be addressed individually and to provide information relevant for a software update, it must provide certain information independently of the functioning of the firmware / application.

[0076] These are for example: Version number of the bootloader and a bootloader protocol, Serial number (base P number) of the lighting technology bus participant to enable the bootloader to receive data addressed via the serial number, A hardware ID to be able to decide whether a software update is suitable for the current lighting technology bus participant and to be able to reject unsuitable software updates, A memory size to be able to reject invalid memory addresses for a software update, A start address of the firmware area to be able to calculate a checksum, The size of the update software to specify the memory area in which the update software is written, A checksum of the firmware to check each time the controller is started whether a valid firmware is present by comparing a checksum, e.g.stored and / or transmitted in the bootloader, with a firmware checksum, an entry point of the firmware to enable the firmware to start.

[0077] To ensure that appropriate update software is loaded into a device, the hardware used, the currently installed software, and its current configuration must be taken into account. For example, it is important to avoid loading update software for a lighting technology bus device onto a lighting technology bus device with a completely different I / O configuration.

[0078] However, a software update can also convert lighting technology bus devices with the same hardware into other devices with the same hardware. For example, an IR receiver can be 'converted' into an AWS sensor if the underlying hardware is prepared for it, meaning a functionality can be modified accordingly.

[0079] In addition to the bootloader and the firmware, a basic configuration must also be saved on the lighting technology bus device and protected against accidental overwriting. The basic configuration may be empty / not initialized after a software update. However, if necessary, the firmware / update software can, under certain conditions, e.g. the first start after the software update, define certain values ​​for the basic configuration. Values ​​contained in the basic configuration include a P number, a module ID, a hardware version, and possibly a MAC address for Ethernet-capable devices. For example, one kilobyte can be allocated for this basic configuration. The firmware / update software can also overwrite the basic configuration after a restart. It is also intended to save a backup copy of the basic configuration in a different memory area in order to be able to restore the basic configuration in the event of an error.

[0080] To enable the most efficient storage of the basic configuration, key-value pairs can be stored sequentially in memory pages, with changes appended to each page until the memory page is full or a reboot occurs. The most recently written key-value pair can be defined as the current one. A checksum (magic number) can be changed as soon as data is appended. An incorrect checksum can also indicate a defect.

[0081] If a memory page is fragmented, the key-value pairs can be copied to another memory page. If the memory page is corrupted, value-key pairs can be copied from a backup copy or another memory page to the corrupted page (defective here refers to incorrect storage of key-value pairs). A search for a key pair can be terminated when a special, distinguished key pair is found.

[0082] To enable efficient access to keys that are not stored in a continuous ascending order, key-value pairs can be cached in RAM. This approach has the advantage that a memory page does not have to be erased and rewritten every time a change occurs. This results in a speed advantage when multiple key-value pairs are changed.

[0083] The bootloader implements as few commands as possible to save memory space for the update software / application. However, commands for testing the respective lighting technology bus device, for example, can be implemented in the bootloader.

[0084] If a lighting technology bus participant has several bootloaders and firmware, it is also possible to update the firmware of individual components of one or more lighting technology bus participants separately.

[0085] It may also be possible to update the firmware incrementally, so that not the entire firmware but only parts of it need to be updated during a software update.

[0086] It may also be provided to provide a mechanism for resuming an interrupted update. Preferably, however, for block-by-block transmission, a log is kept of which blocks were successfully written and which were not. Only blocks that were not successfully written need to be rewritten. It may also be provided that the lighting technology bus participant also logs which parts of the update software were successfully written. This allows the lighting technology bus participant itself to be queried as to whether and to what extent the update was performed and which data needs to be retransmitted.

[0087] At the start of an update process, the bootloader or the firmware / application of the lighting bus device receives an initialization command that activates the bootloader and assigns an update ID to the lighting bus device. The lighting bus device then switches to bootloader mode. The bootloader saves the update ID for subsequent commands. The update ID defines which update software is intended for the lighting bus device. For example, different classes of lighting bus devices can be assigned different update IDs in order to update them in parallel with a software update but with different update software. However, as already described above, all, individual, or classes / groups of lighting bus devices can also be selected.

[0088] If a bootloader fails to receive any update software for a certain period of time after initialization, it restarts the existing firmware / application. The bootloader itself can only be updated using a special procedure, since, for example, a power failure during the bootloader update would render the corresponding lighting technology bus device unusable.

[0089] A reset command is also available, which can also be transmitted together with the update identification in order to abort an update process.

[0090] A command is also available for querying bootloader information. The firmware / application version can be queried even before the controller is put into bootloader mode. The bootloader can transmit the relevant information, for example, to the central processing unit, in response to a query command.

[0091] The bootloader also provides a write command with which the update software / update software blocks are written to the designated memory (area). The transmitted data is compressed (e.g. with RLE) and provided with a header and a trailer. This allows, for example, repeating byte sequences to be encoded without explicitly sending them. Compression means more data can be transmitted at once. When the software update starts, the firmware / application can also be marked as invalid. This means that in the event of a faulty update, the lighting technology bus device remains in bootloader mode and the firmware does not start even after a reset. After a successful update, it can also be saved that an update has taken place. This allows, for example, special functions to be executed on the next start, such as updating the basic configuration.

[0092] Since the update of lighting technology bus devices is performed via a bus, it is necessary to adapt the transmission speed appropriately for simultaneous / parallel update processes on multiple devices. The influence of the update speed on the lighting technology bus device without confirmation from the corresponding devices is particularly problematic here, as there is no indication as to whether the update software is being sent to the respective lighting technology bus devices too quickly. If the update software is sent too quickly, devices may not be able to accept new data.

[0093] The present invention solves this problem by decoupling data transmission and the actual writing of the software update into the corresponding memory of the lighting technology bus participant. Depending on the memory space, several data blocks can be transmitted in one go without the acceptance of the update software blocks being delayed by the execution of update routines on the lighting technology bus participants. The writing of the software update can only occur upon a separate request. Devices that have completed the software update send a message, e.g., to the central unit. The central unit waits before retransmitting until responses are received from all devices to be updated or a timeout has occurred. The responses from the devices to be updated can be success messages or error messages.

[0094] The central unit registers error messages or timeouts, but does not immediately retry the update to avoid delaying the update of the remaining devices. Faulty software updates are handled later, once successfully updated devices have been released from bootloader mode.

[0095] To prevent the bus from becoming a bottleneck, the number of messages received from the devices must be small compared to the amount of update software to be transmitted. Therefore, a relatively large buffer, e.g., 4-8 kilobytes, is provided in the lighting technology bus participants. This reduces the number of update processes at the lighting technology bus participants. Multiple update software blocks can be transmitted before writing of the software update is initiated at the lighting technology bus participant. With a buffer size of, e.g., 8 kilobytes, an update software can be transmitted and written to the respective memory in 8 steps, for example, if the update software is 64 kilobytes in size.

[0096] If a lighting technology bus participant has several addresses via which it can be addressed by the central unit, it is intended that the lighting technology bus participant always only responds to an update request with a predetermined address in order to prevent multiple transmission of the software update to the lighting technology bus participant.

[0097] The central unit can run control software that monitors and controls the software update.

[0098] The control software provides the user with a graphical user interface, for example, which they can use to select which devices should be updated. The devices available on the bus and their types, as well as hardware and / or software versions, are determined by the control software polling the bus. It is also possible to return a message to the control software for lighting bus devices whose firmware is no longer functioning and which are in bootloader mode. From the responses received, the control software creates a list of the lighting bus devices available on the two-wire bus. The responses to the control software contain, for example, a hardware ID, which the control software can use to create a list of compatible update software versions for a hardware base identified by the hardware ID.For lighting technology bus devices that are functioning correctly, additional information can also be returned by the firmware.

[0099] In order for the control software to determine which update software versions are compatible with a lighting technology bus participant, the following data is stored in the update software: the hardware IDs for which the update software can be used, a precise device name, a precise update software identification, a version number of the update software, a checksum, a size specification for the update software (number of bytes of the update software), a maximum supported block size (this can alternatively be specified by the update software data divided into appropriate blocks) and / or the actual update software data.

[0100] Once the control software has identified all lighting technology bus devices available on the bus, the acquired data can be displayed to the user. Based on the displayed information, the user can then select individual lighting technology bus devices or classes / groups of lighting technology bus devices for a software update using appropriate / selected update software versions. The control software performs a version check to determine whether a software update is even advisable, for example, from which firmware can be updated to which other firmware.

[0101] A software update can therefore include one or more of the following steps: Selecting the lighting bus devices to be updated in the software control system, selecting an update function, querying the lighting bus devices available on the bus by the control software, receiving responses from the lighting bus devices on the bus by the control software, with each of the lighting bus devices providing an address, forming an intersection of the selected lighting bus devices and the lighting bus devices that responded to the query by the control software, displaying the lighting bus devices that can be updated, whereby the lighting bus devices that cannot be updated can also be displayed in a distinguishable manner, starting the update process after confirmation by the user, whereby the user can also specify that the software update should occur at a specific time,Logging the progress of the update process(es) to determine which update of which lighting bus device is (partially) successful / failed.

[0102] The logging of the update progress can be done, for example, as in Fig. 2shown. The figure shows that 12 complete buffer contents have been transmitted. Lighting bus nodes 2, 6, and 7 have already positively confirmed the writing of the corresponding blocks. No further confirmations have been received from lighting bus node 3 since the blocks for the seventh buffer filling were transmitted (this may indicate that the corresponding lighting bus node has been disconnected from the bus). Lighting bus node 5 has only received negative confirmation messages since the fifth buffer filling (this may indicate communication problems). Lighting bus node 7 sent a negative confirmation for the sixth and ninth buffer fillings (this may indicate a checksum error).

[0103] After the update process has been completed, the lighting technology bus devices with incorrectly transmitted blocks can be put back into bootloader mode individually or in groups in order to make another attempt to retransmit the blocks for which negative messages or no messages at all were transmitted to the control software.

[0104] The logging information can be saved so that if the control software crashes, the update progress can be restored without additional bus communication.

[0105] If a lighting bus device fails during the update process, the update can be resumed as follows: Special attention must be paid to ensuring that the control software can restore the update identification for the software update. To achieve this, the control software re-enters a lighting bus device selected for the update into bootloader mode if it reports a faulty firmware error to the control software. The control software then transmits the update identification to the corresponding device, which then participates in the update process again. Blocks not transmitted to the lighting bus device (for example, those that were "missed" due to re-entering bootloader mode) are re-sent as described above after the initial update process is completed.

[0106] It should be understood, of course, that the update software transmitted to a lighting technology bus device does not have to be written sequentially into the designated memory, but can also be written in a non-contiguous manner, depending on the transmitted blocks. Only when all blocks have been successfully transmitted and written into memory is the new update software complete and coherent. Fig. 3 shows a schematic of a corresponding update process. Fig. 4a schematically shows the update process from the perspective of the control software / central unit. Fig. 4b describes in more detail how the update step works.

[0107] In order to be able to start a bootloader at any time using a corresponding command and to retrieve information about the bootloader, various services must be provided by the firmware. These include: service Purpose Query the version number of the bootloader etc. Allows you to answer questions about the bootloader version. Starting the bootloader Allows you to enter bootloader mode. Restart device without memory protection This service is required, among other things, to enable bootloader update software to update the bootloader. After setting a special marker (magic number) in RAM, the bootloader will not activate temporary memory protection after a reset, thus allowing a bootloader update. There are various memory areas that can be unlocked independently of one another.

[0108] Furthermore, parameters must be able to be passed from the firmware / update software to the bootloader. The difficulty here is that starting the bootloader requires a reset of the lighting technology bus device. However, persistent storage of such parameters, for example, in an EEPROM, is not practical, as this would require integrating an EEPROM driver into the bootloader, which would increase its size. Therefore, a transfer via, for example, RAM memory is provided. This transfer can be performed as described below: The firmware / update software writes certain parameters to predefined memory addresses, then the firmware / update software triggers a reset (software reset), the bootloader starts and recognizes that the restart is the result of an explicitly triggered reset (software reset) (for other reset causes, the contents of the memory are ignored), the bootloader reads the corresponding parameters from the RAM and resets it immediately afterwards.

[0109] Persistent storage of the update ID also has the disadvantage that it requires storage space, and if stored in EEPROM, an additional corresponding driver would be required in the bootloader. Furthermore, the update ID could already be outdated when the device is rebooted. In the worst case, another software update could be in progress with a reused update ID that isn't even intended for the device. Managing the update ID through the control software is therefore preferable.

[0110] To ensure secure updates, various security mechanisms are provided. First, the bootloader must be initiated each time the lighting technology bus device is started, for which the corresponding vectors in the memory must be set appropriately. By initiating the bootloader, it is possible to restore the device to operation with a software update in the event of a faulty firmware / update software.

[0111] To ensure the error-free operation of a lighting technology bus device, the firmware / update software used must be in a fault-free state. The bootloader therefore checks the consistency of the firmware / update software at every startup. This can be done, for example, by creating a signature for a specific location in memory using a simple arithmetic checksum, or by comparing or determining a complete checksum for the firmware / update software (CRC). Should an error occur despite a successful firmware / update software check, i.e., when the firmware / update software appears to be flawless according to the checksum, the bootloader uses a processor "watchdog" to register a faulty firmware / update software loading process.

[0112] It is also necessary to check whether a software update is actually intended for a lighting technology bus device. Therefore, the bootloader must be able to determine whether a software update is intended for it. For this purpose, the update software contains the above-mentioned header, which contains the exact type of lighting technology bus device, including any hardware revisions. The bootloader then determines whether it is permitted to perform the update based on a comparison of the header with device-specific information.

[0113] To initiate a software update during normal operation, the firmware / update software must have a way to start the bootloader after receiving a corresponding request. For example, the firmware / update software sets a "flag" in memory and activates the bootloader by performing a watchdog reset. The flag is then evaluated at startup and prevents the bootloader from starting the firmware / update software, instead waiting for further bootloader commands. If the firmware / update software is functional, the bootloader can be exited again using a specific command.

[0114] If a firmware / update software is not able to start a bootloader, the bootloader will still load the firmware / update software if it is shown to be error-free, for example based on a checksum.

[0115] To prevent the constant loading of firmware / update software that has been determined to be error-free but is nevertheless faulty, the bootloader waits for an initialization command for a predetermined period during the boot process. If the bootloader receives an initialization command within this period, it does not start the firmware / update software but instead enters bootloader mode. If no initialization command is received, the firmware / update software starts normally. To prevent the predetermined time from elapseing in vain, a checksum is also simultaneously generated during this time to check the consistency of the firmware / update software. A predetermined delay can be, for example, 1-3 seconds.

[0116] Additional security during transmission is achieved by assigning a sequence number to the sent data. This prevents incorrect assignments or mix-ups. Furthermore, the data and the transmitted blocks are secured with a checksum (CRC). Furthermore, the update software integrity is secured and verified by a checksum (CRC, CRC32).

[0117] It may also be provided to ensure permanent verification of the firmware / update software by cyclical generation of a checksum.

[0118] An update of the actual bootloader may also be planned. Since a bootloader update is particularly critical and an incorrect bootloader update renders the lighting technology bus device unusable, the following update mechanisms are provided: First, bootloader update software is transferred to the memory of the lighting technology bus device and written as described above for update software. After a reboot, the bootloader update software checks whether it is error-free and in perfect working order. The bootloader update software then sets a start address, the start vector, so that it is started after a device reboot. After the bootloader update software starts, it rewrites the bootloader and checks whether it was written correctly and without errors.The bootloader update software then resets the boot vector so that the bootloader starts when the device is rebooted. If the bootloader is ensured to be working (for example, through watchdog resets), the bootloader update software can render itself unusable. CRC

[0119] Cyclic Redundancy Check, a checksum procedure.

[0120] See also http: / / de.wikipedia.org / wiki / Cyclic Redundancy Check Update ID

[0121] Unique number for a simultaneous download to multiple similar devices. Up to 15 such downloads to different devices can be processed in parallel with different download IDs. (4 bits; valid value range 1...15) HAL

[0122] Hardware Abstraction Layer. To be as independent as possible from a specific controller version of a lighting technology bus device, all hardware-related access is encapsulated in a separate software layer. The application then accesses these low-level functionalities via defined interfaces. If a controller class changes, ideally only the HAL needs to be adapted, and the rest will function immediately without any further changes. Hardware ID

[0123] A unique identifier for the underlying hardware of a device (e.g., 3 bytes). Essentially, this identifier must be assigned for each new device and, if applicable, for each hardware revision that affects the software. This ensures that only compatible software is written to the devices.

[0124] For practical reasons, the hardware ID is formed from a module ID and the hardware version. For lighting technology bus devices with multiple module IDs, one of these is chosen as the base module ID to form the hardware ID. RLE

[0125] Run-length encoding. This is a simple compression technique for representing a number of repeated bytes in a space-saving manner. See also http: / / de.wikipedia.org / wiki / RLE

Claims

1. A method for programming lighting bus subscribers, wherein the lighting subscribers are connected via a two-wire bus, comprising the steps of: a. determining available lighting bus subscribers, e.g., sensors and / or actuators such as operating devices for lighting means, by a central unit connected to the lighting bus subscribers via the two-wire bus, b. selecting at least one lighting bus subscriber by means of the central unit from the available lighting bus subscribers, c. setting the selected lighting bus subscribers into an update mode by means of the central unit via the two-wire bus and allocating an update identification by means of the central unit via the two-wire bus to the selected lighting bus subscribers, wherein the central unit transmits the update identification to the selected lighting bus subscribers via the two-wire bus, and d. transmitting update software, in particular firmware, provided with the update identification via the two-wire bus to the selected lighting bus subscribers, wherein each selected lighting bus subscriber in update mode recognizes on the basis of the previously transmitted update identification whether the update software transmitted via the two-wire bus and provided with the update identification is intended for it.

2. The method according to claim 1, wherein it is determined whether the update software has been transmitted without errors.

3. The method according to either claim 1 or claim 2, wherein the lighting bus subscriber is set into an operating mode as soon as the update software has been transmitted without errors and completely written.

4. The method according to any of the preceding claims, wherein the lighting bus subscriber is operated in update mode by a bootloader.

5. The method according to any of the preceding claims, wherein the update software is transmitted block by block.

6. The method according to any of the preceding claims, wherein it is determined whether the update software / update software blocks has / have been transmitted without errors and the determination result is logged for each selected lighting bus subscriber.

7. The method according to any of the preceding claims, wherein the programming of selected lighting bus subscribers is time-controlled.

8. The method according to any of the preceding claims, wherein the selection of the lighting bus subscribers is made according to type, hardware version and / or position / installation location.

9. The method according to any of the preceding claims, wherein each lighting bus subscriber type is assigned an update identification.

10. The method according to claim 9, wherein an update software is transmitted for each lighting bus subscriber type.

11. The method according to any of the preceding claims, wherein the transmitted update software / transmitted update software blocks for the lighting bus subscriber are written to a buffer of the lighting bus subscriber and the buffer accommodates at least more than one update software block.

12. The method according to any of the preceding claims, wherein all update software blocks present in a buffer of a lighting bus subscriber are written to an update software memory.

13. A lighting bus subscriber comprising: a. a first memory area in which a bootloader is stored, b. a second memory area for storing update software, c. a means for receiving data and d. a means for sending data, wherein the lighting bus subscriber is configured - to be connected to a two-wire bus, - to be set into an update mode via the two-wire bus, and - to receive an update identification via the two-wire bus, and the bootloader is configured to determine in update mode, on the basis of the received update identification, whether an update software / update software blocks received via the two-wire bus is / are intended for the lighting bus subscriber.

14. A computer-based central unit which is configured - to run control software, - to be connected to a two-wire bus, - to determine available lighting bus subscribers that are connected to the two-wire bus, - to determine suitable update software for the determined lighting bus subscribers, - to provide a user interface for selecting lighting bus subscribers from the determined lighting bus subscribers, - to set selected lighting bus subscribers into an update mode by transmitting an initialization command via the two-wire bus, - before transmitting update software via the two-wire bus to the selected lighting bus subscribers, to allocate an update identification via the two-wire bus to the selected lighting bus subscribers by transmitting the update identification via the two-wire bus to the selected lighting bus subscribers, and - to transmit update software provided with the update identification to the selected lighting bus subscribers via the two-wire bus.

15. A system comprising at least one lighting bus subscriber according to claim 13 and at least one computer-based central unit according to claim 14, which system is configured to carry out a method according to any of claims 1-12.