EP3443454A1 - Fire detection system with automatic firmware updating - Google Patents

Fire detection system with automatic firmware updating

Info

Publication number
EP3443454A1
EP3443454A1 EP17717877.9A EP17717877A EP3443454A1 EP 3443454 A1 EP3443454 A1 EP 3443454A1 EP 17717877 A EP17717877 A EP 17717877A EP 3443454 A1 EP3443454 A1 EP 3443454A1
Authority
EP
European Patent Office
Prior art keywords
firmware
newly
slave unit
master module
fire
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP17717877.9A
Other languages
German (de)
French (fr)
Inventor
Robert W. Farley
James Ogier
Shachak Zaarur
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Johnson Controls Fire Protection LP
Original Assignee
Johnson Controls Fire Protection LP
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Johnson Controls Fire Protection LP filed Critical Johnson Controls Fire Protection LP
Publication of EP3443454A1 publication Critical patent/EP3443454A1/en
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • A—HUMAN NECESSITIES
    • A62—LIFE-SAVING; FIRE-FIGHTING
    • A62C—FIRE-FIGHTING
    • A62C3/00—Fire prevention, containment or extinguishing specially adapted for particular objects or places
    • A62C3/07—Fire prevention, containment or extinguishing specially adapted for particular objects or places in vehicles, e.g. in road vehicles
    • A—HUMAN NECESSITIES
    • A62—LIFE-SAVING; FIRE-FIGHTING
    • A62C—FIRE-FIGHTING
    • A62C37/00—Control of fire-fighting equipment
    • A62C37/36—Control of fire-fighting equipment an actuating signal being generated by a sensor separate from an outlet device
    • A62C37/38—Control of fire-fighting equipment an actuating signal being generated by a sensor separate from an outlet device by both sensor and actuator, e.g. valve, being in the danger zone
    • A62C37/40—Control of fire-fighting equipment an actuating signal being generated by a sensor separate from an outlet device by both sensor and actuator, e.g. valve, being in the danger zone with electric connection between sensor and actuator
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G06F8/654—Updates using techniques specially adapted for alterable solid state memories, e.g. for EEPROM or flash memories
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G—PHYSICS
    • G08—SIGNALLING
    • G08B—SIGNALLING OR CALLING SYSTEMS; ORDER TELEGRAPHS; ALARM SYSTEMS
    • G08B17/00—Fire alarms; Alarms responsive to explosion

Definitions

  • Fire systems such as fire detection systems, fire suppression systems or combination fire detection and suppression systems, typically comprise a master module and a series of slave units. Slave units have elements that are designed to perform specific tasks related to fire detection, notification, and suppression, such as detecting information about the environment and communicating the information to the master module, or, upon receiving instructions from the master module, performing a fire suppression function or generating an audible and/or visual alert to occupants.
  • Fire systems for premises typically include fire sensors, pull stations, and alarms.
  • fire systems for vehicles typically include a variety of sensors, release modules, annunciators, and manual override switches.
  • Fire systems are installed on large vehicles such as those used in the mining, forestry, landfill and mass transit industries to prevent or mitigate damage to complex and expensive equipment.
  • a mining dump truck could feature a reciprocating engine driving a generator, which in turn provides power to electric motors that drive the wheels. Any one of these components can overheat and catch on fire, causing extensive damage to complex and expensive equipment.
  • the fire systems are employed to minimize such losses.
  • the master modules and slave units of fire systems are typically installed on a common bus.
  • Each of these modules and units will typically include micro controllers, nonvolatile memory (for example, flash memory) and transceivers for communicating on the bus.
  • Master modules send instructions to and receive information from slave units through their respective transceivers.
  • the microcontrollers execute firmware instructions stored in memory.
  • the invention features a method for updating the firmware of slave units.
  • This method comprises determining a version of the firmware for a newly-installed slave unit and updating the firmware of the newly-installed slave unit or the previously-installed slave units based on the version of the firmware of the newly-installed slave unit.
  • the master module might update the firmware of the newly- installed slave unit if a more-recent version of the firmware is present on the previously- installed slave units of the same type as the newly-installed slave unit and/or is accessible to master module.
  • a stored firmware image file can further be updated with the firmware of the newly-installed slave unit if a more -recent version of the firmware is present on the newly-installed slave unit.
  • the master module updates the firmware of the previously- installed slave units of the same type as the newly-installed slave unit if a more-recent version of the firmware is present on the newly -installed slave units.
  • the master module reads and validates the firmware image read from the newly-installed slave unit.
  • the master module first updates a firmware image file with the firmware of the newly -installed slave unit if a more-recent version of the firmware is present on the newly-installed slave unit; and then the master module updates the firmware of the previously-installed slave units of the same type as the newly-installed slave unit based on the updated firmware image file.
  • This method can be applied to fire systems installed on vehicles.
  • the invention features a fire system comprising slave units and a master module determining a version of the firmware for a newly-installed slave unit and updating the firmware of the newly-installed slave unit or previously-installed slave units based on the version of the firmware of the newly-installed slave unit.
  • Fig. 1 is a block diagram of a fire system installed on a vehicle, for example
  • Fig. 2A is a schematic diagram of a generic slave unit
  • Fig. 2B is a schematic diagram of a master module
  • Fig. 2C is a schematic diagram of a battery unit
  • Fig. 2D is a schematic diagram of a display unit
  • Fig. 3 is a flow diagram illustrating the method for updating firmware of older modules from a newer found version
  • Fig. 4 is a diagram of the memory for each of a master module, a battery unit, a display unit, and two fire sensor units installed on a fire system;
  • Fig. 5 is a diagram of a device index stored on the master nonvolatile memory
  • Fig. 6 illustrates the read slave memory location instruction
  • Fig. 7 illustrates the memory data response packet
  • Fig. 8 illustrates the memory for each of the master module, the battery unit, the display unit, and the two fire sensor units installed on the fire system, after the
  • Fig. 9 illustrates the memory for each of the master module, the battery unit, the display unit, and the two fire sensor units installed on the fire system, after the backup copy of the fire sensor unit firmware (v4) has been stored in the file system;
  • Fig. 10 illustrates the memory for each of the master module, the battery unit, the display unit, and the two fire sensor units installed on the fire system, after the previously-installed fire sensor unit is updated with the new firmware;
  • Fig. 11 illustrates the device index after it has been updated.
  • the term “and/or” includes any and all combinations of one or more of the associated listed items. Further, the singular forms and the articles “a”, “an” and “the” are intended to include the plural forms as well, unless expressly stated otherwise. It will be further understood that the terms: includes, comprises, including and/or comprising, when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements,
  • Fig. 1 is a block diagram of a fire system 100, such as a fire detection system, a fire suppression system or a combination fire detection and suppression system, installed on a vehicle 108, for example, to which the present invention is applicable.
  • a fire system 100 such as a fire detection system, a fire suppression system or a combination fire detection and suppression system, installed on a vehicle 108, for example, to which the present invention is applicable.
  • the system comprises a master module 102 and a series of slave units 106 installed on a common bus 104.
  • the master module 102 sends instructions to and receives information from the slave units 106, and the slave units 106 receive instructions from the master module 102 and send information (for example, information about the environment detected by a slave unit 106) to the master module 102.
  • the data bus 104 is preferably common from a logical perspective.
  • the master module 102 preferably uses a common address space to communicate with the various slave units 106 using the data bus 104. That said, the bus 104 is currently implemented as several physical data buses/wiring interfaces (ports) on the master module 102. This helps to ensure proper and repeatable installation by having specific units be connected to specific wiring interfaces or ports on the master module 102.
  • the installed slave units include a display unit 106-1, which displays information about the state of the fire system 100, a battery unit 106-2, which supplies power to the fire system 100, two linear heat detector units 106-3, which detect heat and communicate information to the master module 102, two manual activation switch units 106-4, which, when activated by an operator (for example, a driver of the vehicle) trigger a fire suppression function, two IR detector units 106-5, which detect infrared radiation and communicate information to the master module 102, two fire sensor units 106-6, which detect the presence of fire and communicate information to the master module 102, and two release units 106-7, which perform a fire suppression function.
  • a display unit 106-1 which displays information about the state of the fire system 100
  • a battery unit 106-2 which supplies power to the fire system 100
  • two linear heat detector units 106-3 which detect heat and communicate information to the master module 102
  • two manual activation switch units 106-4 which, when activated by an operator (for example, a driver of the vehicle) trigger a fire suppression function
  • the fire sensor 106-6 could detect that a fire is present and send the information to the master module 102.
  • the master module 102 could then send instructions to the release module 106-7 to perform a fire suppression function, and/or instructions to the display 106-1 to display an alert.
  • FIGs. 2A-2D are schematic diagrams of various units of the fire system 100.
  • Each unit similarly includes a controller 202, 214, 228, 244, a transceiver 204, 216, 230, 246, volatile random access memory (RAM) 206, 218, 232, 248, nonvolatile memory 208, 220, 236, 252, and ROM 210, 222, 238, 254.
  • Each unit 106, 102, 106-2, 106-1 connects to the common bus 104 through its transceiver 204, 216, 230, 246.
  • the controllers 202, 214, 228, 244 execute firmware instructions stored on the nonvolatile memory 208, 220, 236, 252. In addition to firmware, the nonvolatile memory of each unit also stores data associated with maintaining state.
  • Fig. 2A is a schematic diagram of a generic slave unit 106. Examples include fire sensor units 106-6.
  • Each of the slave units typically includes a slave element 205, which is typically different for each type of slave.
  • the slave element 205 is a smoke sensor that detects smoke, with the slave controller monitoring the detected smoke levels by the element and communicating those levels to the master module.
  • the slave element 205 might be a thermistor that detects ambient temperature with the slave controller monitoring the detected temperature levels and communicating those levels to the master module or triggering an alarm condition itself.
  • the slave element 205 might be a relay that controls the release of fire suppressant. The slave controller in this case waits for a release instruction from the master module 102 and then operates the relay accordingly.
  • Fig. 2B is a schematic diagram of the master module 102.
  • the master nonvolatile memory 220 In addition to firmware and data associated with maintaining state, the master nonvolatile memory 220 also stores file metadata 224.
  • Fig. 2C is a schematic diagram of a battery unit 106-2, which is a particular type of slave unit 106 that supplies power to the fire system 100.
  • the battery control unit 234 performs the functions of a battery management system (e.g. preventing the battery from operating outside its Safe Operating Area, monitoring its state, etc.).
  • the battery 240 provides electrical power to the fire system 100.
  • Fig. 2D is a schematic diagram of a display unit 106-1, which is a particular type of slave unit 106 that displays information about the state of the fire system 100.
  • the display driver unit 250 renders information to be displayed on the display 256.
  • the USB port 258 receives data from external memory and communicates the information to the display controller 244.
  • the memory stick 259 is an example of external memory, and is a portable device with nonvolatile memory (for example, flash memory) and a USB output.
  • the memory stick 259 could contain, for example, updates to slave firmware.
  • Fig. 3 is a flow diagram illustrating the method for updating firmware of older modules from a newer found version.
  • step 302 it is determined or detected whether a new slave unit has been installed on the fire system 100.
  • a new fire sensor unit 106-6 is newly installed on a fire system 100 on which a battery unit 106-2, a display unit 106-1, and a fire sensor unit 106-6 were previously installed.
  • Fig. 4 is a diagram of the memory for each of the master module 102, the battery unit 106-2, the display unit 106-1, and the two fire sensor units 106-6. Included are a master nonvolatile memory 220, battery nonvolatile memory 236, display nonvolatile memory 252, and fire sensor unit nonvolatile memory 208.
  • the first fire sensor unit nonvolatile memory 208-1 pertains to the previously-installed fire sensor unit 106-6, while the second fire sensor unit nonvolatile memory 208-2 pertains to a newly-installed fire sensor unit 106-6.
  • the master nonvolatile memory 220 includes master module firmware 402
  • the battery nonvolatile memory 236 includes battery unit firmware (v2) 404, which is version two of the firmware for battery units
  • the display module nonvolatile memory 252 includes display unit firmware (v5) 406
  • the previously-installed first fire sensor unit nonvolatile memory 208-1 includes fire sensor unit firmware (v3) 408
  • the newly-installed fire sensor unit nonvolatile memory 208-2 includes fire sensor unit firmware (v4) 410.
  • the master nonvolatile memory 220 includes a file system 412, which is a system of files maintained by the master module 102.
  • the file system 412 is a distributed file system such as that described in related U.S. Application No. 15/095,691, entitled "Fire detection system with distributed file system".
  • the file system 412 is stored, for example, on the master nonvolatile memory 220.
  • the file system 412 includes a battery unit firmware (v2) image 414, which is a backup copy of version two of the firmware for battery units, a display unit firmware (v5) image 416, and a fire sensor unit firmware (v3) image 418.
  • a device index 420 is also included on the master nonvolatile memory 220.
  • Fig. 5 is a diagram of the device index 420 stored on the master nonvolatile memory 220.
  • the device index 420 includes information about the various modules installed on the fire system 100, including a device address, which is a unique address assigned to each installed module, a serial number, which is a unique number assigned to each module when the module is manufactured, the type of module and the version of the firmware of the module.
  • the battery unit 106-2 has a device address of "1", a serial number of "0100", a module type of "battery”, and a firmware version of two.
  • step 304 the firmware version of the newly-installed slave unit is determined.
  • step 306 the device index 420 is accessed to determine the version of the firmware for any previously-installed slave units of the same type and/or the backup copy of the firmware stored by the master module 102. It is then determined whether the newly-installed slave unit's firmware is a more recent version than the firmware of the previously-installed slave units of the same type in step 308.
  • step 312 the size of the firmware of the newly-installed slave unit is determined.
  • step 314 it is determined whether there is adequate space in the file system 412. If not, in step 316, the new file is not downloaded into the file system 412. If, on the other hand, there is adequate space, in step 318, the older version of the corresponding file backup is erased.
  • Steps 320 through 328 illustrate the process for the master module 102 reading the firmware from a slave unit 106.
  • the firmware is read from the slave nonvolatile memory 208, 236, 252 using a series of instructions sent between the master module 102 and the slave unit 106.
  • Fig. 6 illustrates the read slave memory location instruction 502, which is sent by the master module 102 to the newly-installed slave unit 106.
  • the read slave memory location instruction 502 includes a header with a format code, the high byte of the most significant word of the start address, the low byte of the most significant word of the start address, the high byte of the least significant word of the start address, the low byte of the least significant word of the start address, and the number of bytes to read.
  • Fig. 7 illustrates the memory data response packet 504, which is sent from the newly-installed slave unit 106 to the master module 102 in response to the read slave memory location instruction 502.
  • the memory data response packet 512 includes a header with a format code, the number of bytes of data included, and the data starting at the start address indicated in the read slave memory location instruction 502 and ending after the number of bytes indicated in the read slave memory location instruction 502 is included.
  • the master module 102 sends a read slave memory location instruction 502 to the newly-installed slave unit 106, indicating the start address, which is the address where the firmware of the slave unit 106 begins, and indicating that the first 128 bytes of the firmware should be read.
  • a memory data response packet 504 is received by the master module 102 from the slave unit 106, including the data at the start address.
  • step 326 the address is then incremented to the next address, which is the address where the next 128 bytes of the firmware of the slave unit 106 begins.
  • the process returns to step 320, at which point the next address is sent to the slave unit 106, and the next 128 bytes of the firmware is read.
  • step 328 it is determined whether the read process was successful. This can be implemented using, among other methods, a checksum or CRC value, which is a value calculated from a portion of data used to verify the integrity of the data. If the read process was not successful, an error flag is set in step 330.
  • step 332 the firmware image read from the newly-installed slave unit 106 is then stored in the file system 412 as a new backup copy of firmware, in one embodiment.
  • step 334 the checksum/CRC of the firmware image newly-written to the file system 412 is then read and compared with that of the firmware of the newly-installed slave unit 106.
  • step 336 previously-installed slave units 106 of the same type as the newly-installed slave unit 106 are updated with the newly written firmware image stored on the file system 412.
  • the device index 420 is updated with the new firmware version of any updated slave units 106.
  • the fire sensor unit 106-6-2 is detected by the master module 102 as a newly-installed slave unit. It is then determined that the fire sensor unit firmware (v4) 410 installed on the newly-installed fire sensor unit nonvolatile memory 208-2 is version four of the fire sensor unit firmware. The file index 420 is then accessed, and it is determined that a previously-installed fire sensor unit 106-6 exists with a firmware version of three. It is also determined that the backup copy of the fire sensor firmware stored by the master module 102, which is the fire sensor unit firmware (v3) image 418, is also version three.
  • Fig. 8 illustrates the memory for each of the master module 102, the battery unit 106-2, the display unit 106-1, and the two fire sensor units 106-6 installed on the fire system 100 after the corresponding older version of the backup copy of the firmware has been erased.
  • the fire sensor unit firmware (v3) image 418 is no longer stored in the file system 412 on the master nonvolatile memory 220.
  • the fire sensor unit firmware (v4) 410 is then read from the fire sensor unit nonvolatile memory 208-2 of the newly-installed fire sensor unit 106-6 and stored as a backup in the file system 412.
  • Fig. 9 illustrates the memory for each of the master module 102, the battery unit 106-2, the display unit 106-1, and the two fire sensor units 106-6 installed on the fire system 100, after the backup copy of the fire sensor unit firmware (v4) 410 has been stored in the file system 412.
  • the file system 412 now contains a fire sensor unit firmware (v4) image 422.
  • Fig. 10 illustrates the memory for each of the master module 102, the battery unit 106-2, the display unit 106-1, and the two fire sensor units 106-6 installed on the fire system 100, after the previously-installed fire sensor unit 106-6 is updated with the new firmware.
  • the fire sensor unit nonvolatile memory 208-1 now contains the fire sensor unit firmware (v4) 410.
  • FIG. 11 illustrates the device index 420, after it has been updated.
  • the previously-installed fire sensor unit 106-6 (with device address 3 and serial number 0101) is now listed as having firmware version four.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Health & Medical Sciences (AREA)
  • Public Health (AREA)
  • Business, Economics & Management (AREA)
  • Emergency Management (AREA)
  • Stored Programmes (AREA)

Abstract

A system and method for updating the firmware of slave units in a fire system detects whether a new slave unit has been installed and compares the version of the firmware in the newly-installed slave unit with that of previously-installed slave units of the same type (including any backup copies of firmware stored by the master module in a file system). If the newly-installed slave unit's firmware is more recent, any backup copies of the firmware stored by the master module are replaced with an image of the new version of the firmware. Additionally, slave units with older versions of the firmware are updated to the newest version.

Description

FIRE DETECTION SYSTEM WITH AUTOMATIC FIRMWARE UPDATING
RELATED APPLICATIONS
[ 0001 ] This application claims priority to U.S. Application No. 15/095,680, filed on April 11, 2016, and is related to U.S. Application No. 15/095,691, filed on April 11, 2016, and U.S. Application No. 15/095,697, filed on April 11, 2016, all of which are
incorporated herein by reference in their entirety.
BACKGROUND OF THE INVENTION
[ 0002 ] Fire systems, such as fire detection systems, fire suppression systems or combination fire detection and suppression systems, typically comprise a master module and a series of slave units. Slave units have elements that are designed to perform specific tasks related to fire detection, notification, and suppression, such as detecting information about the environment and communicating the information to the master module, or, upon receiving instructions from the master module, performing a fire suppression function or generating an audible and/or visual alert to occupants.
[ 0003 ] Different types of slave units or combinations of slave units are typically deployed based on the specific application. Fire systems for premises typically include fire sensors, pull stations, and alarms. On the other hand, fire systems for vehicles typically include a variety of sensors, release modules, annunciators, and manual override switches.
[ 0004 ] Fire systems are installed on large vehicles such as those used in the mining, forestry, landfill and mass transit industries to prevent or mitigate damage to complex and expensive equipment. For example, a mining dump truck could feature a reciprocating engine driving a generator, which in turn provides power to electric motors that drive the wheels. Any one of these components can overheat and catch on fire, causing extensive damage to complex and expensive equipment. The fire systems are employed to minimize such losses.
[ 0005 ] The master modules and slave units of fire systems are typically installed on a common bus. Each of these modules and units will typically include micro controllers, nonvolatile memory (for example, flash memory) and transceivers for communicating on the bus. Master modules send instructions to and receive information from slave units through their respective transceivers. Within each module or unit, the microcontrollers execute firmware instructions stored in memory. SUMMARY OF THE INVENTION
[ 0006 ] As the operational lifetimes of the fire systems are often measured in decades, new versions of modules' firmware are typically released throughout the systems' lifetimes. New firmware is installed to fix bugs, improve performance, or enable compatibility with new devices. Some systems require using portable computers or other tools to update firmware. Another approach is to enable the fire systems to read firmware updates from memory sticks via ports on the systems. In these cases, the firmware on the slave units is updated with the firmware stored on the memory sticks. In some systems, images of the firmware for slave units can be saved by the master module and used to replace the slave units' firmware if they become corrupted or if they are outdated.
[ 0007 ] Throughout the lifetime of fire systems, it is not uncommon for new slave units to be installed, for example, to replace an old, malfunctioning slave unit. In another example, a new slave unit could be installed in addition to existing slave units to expand the capabilities of the fire system.
[ 0008 ] The problem that these situations present is that newly installed slave units could have been manufactured well before or well after the manufacture of the slave units previously installed on the system. For example, a spare slave unit that is several years old but unused could be installed, or a brand new slave unit could be purchased and installed on a system with previously-installed slave units that are several years old. This could result in different versions of slave unit firmware simultaneously operating on the same system. Moreover, not all units may have the most up-to-date firmware.
[ 0009 ] In general, according to one aspect, the invention features a method for updating the firmware of slave units. This method comprises determining a version of the firmware for a newly-installed slave unit and updating the firmware of the newly-installed slave unit or the previously-installed slave units based on the version of the firmware of the newly-installed slave unit.
[ 0010 ] In embodiments, the master module might update the firmware of the newly- installed slave unit if a more-recent version of the firmware is present on the previously- installed slave units of the same type as the newly-installed slave unit and/or is accessible to master module. A stored firmware image file can further be updated with the firmware of the newly-installed slave unit if a more -recent version of the firmware is present on the newly-installed slave unit. [ 0011 ] In one example, the master module updates the firmware of the previously- installed slave units of the same type as the newly-installed slave unit if a more-recent version of the firmware is present on the newly -installed slave units.
[ 0012 ] Typically, the master module reads and validates the firmware image read from the newly-installed slave unit. In a current example, the master module first updates a firmware image file with the firmware of the newly -installed slave unit if a more-recent version of the firmware is present on the newly-installed slave unit; and then the master module updates the firmware of the previously-installed slave units of the same type as the newly-installed slave unit based on the updated firmware image file.
[ 0013 ] This method can be applied to fire systems installed on vehicles.
[ 0014 ] In general, according to another aspect, the invention features a fire system comprising slave units and a master module determining a version of the firmware for a newly-installed slave unit and updating the firmware of the newly-installed slave unit or previously-installed slave units based on the version of the firmware of the newly-installed slave unit.
[ 0015 ] The above and other features of the invention including various novel details of construction and combinations of parts, and other advantages, will now be more particularly described with reference to the accompanying drawings and pointed out in the claims. It will be understood that the particular method and device embodying the invention are shown by way of illustration and not as a limitation of the invention. The principles and features of this invention may be employed in various and numerous embodiments without departing from the scope of the invention.
BRIEF DESCRIPTION OF THE DRAWINGS
[ 0016 ] In the accompanying drawings, reference characters refer to the same parts throughout the different views. The drawings are not necessarily to scale; emphasis has instead been placed upon illustrating the principles of the invention. Of the drawings:
[ 0017 ] Fig. 1 is a block diagram of a fire system installed on a vehicle, for example;
[ 0018 ] Fig. 2A is a schematic diagram of a generic slave unit;
[ 0019 ] Fig. 2B is a schematic diagram of a master module;
[ 0020 ] Fig. 2C is a schematic diagram of a battery unit; [ 0021 ] Fig. 2D is a schematic diagram of a display unit;
[ 0022 ] Fig. 3 is a flow diagram illustrating the method for updating firmware of older modules from a newer found version;
[ 0023 ] Fig. 4 is a diagram of the memory for each of a master module, a battery unit, a display unit, and two fire sensor units installed on a fire system;
[ 0024 ] Fig. 5 is a diagram of a device index stored on the master nonvolatile memory;
[ 0025 ] Fig. 6 illustrates the read slave memory location instruction;
[ 0026 ] Fig. 7 illustrates the memory data response packet;
[ 0027 ] Fig. 8 illustrates the memory for each of the master module, the battery unit, the display unit, and the two fire sensor units installed on the fire system, after the
corresponding older version of the backup copy of the firmware has been erased.
[ 0028 ] Fig. 9 illustrates the memory for each of the master module, the battery unit, the display unit, and the two fire sensor units installed on the fire system, after the backup copy of the fire sensor unit firmware (v4) has been stored in the file system;
[ 0029 ] Fig. 10 illustrates the memory for each of the master module, the battery unit, the display unit, and the two fire sensor units installed on the fire system, after the previously-installed fire sensor unit is updated with the new firmware; and
[ 0030 ] Fig. 11 illustrates the device index after it has been updated.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[ 0031 ] The invention now will be described more fully hereinafter with reference to the accompanying drawings, in which illustrative embodiments of the invention are shown. This invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art.
[ 0032 ] As used herein, the term "and/or" includes any and all combinations of one or more of the associated listed items. Further, the singular forms and the articles "a", "an" and "the" are intended to include the plural forms as well, unless expressly stated otherwise. It will be further understood that the terms: includes, comprises, including and/or comprising, when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements,
components, and/or groups thereof. Further, it will be understood that when an element, including component or subsystem, is referred to and/or shown as being connected or coupled to another element, it can be directly connected or coupled to the other element or intervening elements may be present.
[ 0033 ] Fig. 1 is a block diagram of a fire system 100, such as a fire detection system, a fire suppression system or a combination fire detection and suppression system, installed on a vehicle 108, for example, to which the present invention is applicable.
[ 0034 ] The system comprises a master module 102 and a series of slave units 106 installed on a common bus 104. The master module 102 sends instructions to and receives information from the slave units 106, and the slave units 106 receive instructions from the master module 102 and send information (for example, information about the environment detected by a slave unit 106) to the master module 102.
[ 0035 ] The data bus 104 is preferably common from a logical perspective. The master module 102 preferably uses a common address space to communicate with the various slave units 106 using the data bus 104. That said, the bus 104 is currently implemented as several physical data buses/wiring interfaces (ports) on the master module 102. This helps to ensure proper and repeatable installation by having specific units be connected to specific wiring interfaces or ports on the master module 102.
[ 0036 ] In the illustrated example, the installed slave units include a display unit 106-1, which displays information about the state of the fire system 100, a battery unit 106-2, which supplies power to the fire system 100, two linear heat detector units 106-3, which detect heat and communicate information to the master module 102, two manual activation switch units 106-4, which, when activated by an operator (for example, a driver of the vehicle) trigger a fire suppression function, two IR detector units 106-5, which detect infrared radiation and communicate information to the master module 102, two fire sensor units 106-6, which detect the presence of fire and communicate information to the master module 102, and two release units 106-7, which perform a fire suppression function.
[ 0037 ] In one example, the fire sensor 106-6 could detect that a fire is present and send the information to the master module 102. The master module 102, in turn, could then send instructions to the release module 106-7 to perform a fire suppression function, and/or instructions to the display 106-1 to display an alert.
[ 0038 ] Figs. 2A-2D are schematic diagrams of various units of the fire system 100. Each unit similarly includes a controller 202, 214, 228, 244, a transceiver 204, 216, 230, 246, volatile random access memory (RAM) 206, 218, 232, 248, nonvolatile memory 208, 220, 236, 252, and ROM 210, 222, 238, 254. Each unit 106, 102, 106-2, 106-1 connects to the common bus 104 through its transceiver 204, 216, 230, 246. The controllers 202, 214, 228, 244 execute firmware instructions stored on the nonvolatile memory 208, 220, 236, 252. In addition to firmware, the nonvolatile memory of each unit also stores data associated with maintaining state.
[ 0039 ] Fig. 2A is a schematic diagram of a generic slave unit 106. Examples include fire sensor units 106-6. Each of the slave units typically includes a slave element 205, which is typically different for each type of slave. For example for a smoke detector slave unit, the slave element 205 is a smoke sensor that detects smoke, with the slave controller monitoring the detected smoke levels by the element and communicating those levels to the master module. In another example, for a fire detector slave unit, the slave element 205 might be a thermistor that detects ambient temperature with the slave controller monitoring the detected temperature levels and communicating those levels to the master module or triggering an alarm condition itself. In the case of a release unit, the slave element 205 might be a relay that controls the release of fire suppressant. The slave controller in this case waits for a release instruction from the master module 102 and then operates the relay accordingly.
[ 004 0 ] Fig. 2B is a schematic diagram of the master module 102. In addition to firmware and data associated with maintaining state, the master nonvolatile memory 220 also stores file metadata 224.
[ 004 1 ] Fig. 2C is a schematic diagram of a battery unit 106-2, which is a particular type of slave unit 106 that supplies power to the fire system 100. The battery control unit 234 performs the functions of a battery management system (e.g. preventing the battery from operating outside its Safe Operating Area, monitoring its state, etc.). The battery 240 provides electrical power to the fire system 100.
[ 0042 ] Fig. 2D is a schematic diagram of a display unit 106-1, which is a particular type of slave unit 106 that displays information about the state of the fire system 100. The display driver unit 250 renders information to be displayed on the display 256. The USB port 258 receives data from external memory and communicates the information to the display controller 244. The memory stick 259 is an example of external memory, and is a portable device with nonvolatile memory (for example, flash memory) and a USB output. The memory stick 259 could contain, for example, updates to slave firmware.
[ 0043 ] Fig. 3 is a flow diagram illustrating the method for updating firmware of older modules from a newer found version.
[ 0044 ] In step 302, it is determined or detected whether a new slave unit has been installed on the fire system 100.
[ 0045 ] In one example, a new fire sensor unit 106-6 is newly installed on a fire system 100 on which a battery unit 106-2, a display unit 106-1, and a fire sensor unit 106-6 were previously installed.
[ 0046 ] Illustrating this example, Fig. 4 is a diagram of the memory for each of the master module 102, the battery unit 106-2, the display unit 106-1, and the two fire sensor units 106-6. Included are a master nonvolatile memory 220, battery nonvolatile memory 236, display nonvolatile memory 252, and fire sensor unit nonvolatile memory 208. The first fire sensor unit nonvolatile memory 208-1 pertains to the previously-installed fire sensor unit 106-6, while the second fire sensor unit nonvolatile memory 208-2 pertains to a newly-installed fire sensor unit 106-6. In the illustrated example, the master nonvolatile memory 220 includes master module firmware 402, the battery nonvolatile memory 236 includes battery unit firmware (v2) 404, which is version two of the firmware for battery units, the display module nonvolatile memory 252 includes display unit firmware (v5) 406, the previously-installed first fire sensor unit nonvolatile memory 208-1 includes fire sensor unit firmware (v3) 408, and the newly-installed fire sensor unit nonvolatile memory 208-2 includes fire sensor unit firmware (v4) 410.
[ 0047 ] In addition to firmware, the master nonvolatile memory 220 includes a file system 412, which is a system of files maintained by the master module 102. In the preferred embodiment, the file system 412 is a distributed file system such as that described in related U.S. Application No. 15/095,691, entitled "Fire detection system with distributed file system". In the illustrated embodiment, the file system 412 is stored, for example, on the master nonvolatile memory 220. The file system 412 includes a battery unit firmware (v2) image 414, which is a backup copy of version two of the firmware for battery units, a display unit firmware (v5) image 416, and a fire sensor unit firmware (v3) image 418. Also included on the master nonvolatile memory 220 is a device index 420.
[ 0048 ] Fig. 5 is a diagram of the device index 420 stored on the master nonvolatile memory 220. The device index 420 includes information about the various modules installed on the fire system 100, including a device address, which is a unique address assigned to each installed module, a serial number, which is a unique number assigned to each module when the module is manufactured, the type of module and the version of the firmware of the module. For example, the battery unit 106-2 has a device address of "1", a serial number of "0100", a module type of "battery", and a firmware version of two.
[ 0049 ] Returning to Fig. 3, once a newly-installed slave unit is detected, in step 304 the firmware version of the newly-installed slave unit is determined. In step 306, the device index 420 is accessed to determine the version of the firmware for any previously-installed slave units of the same type and/or the backup copy of the firmware stored by the master module 102. It is then determined whether the newly-installed slave unit's firmware is a more recent version than the firmware of the previously-installed slave units of the same type in step 308. In step 312, the size of the firmware of the newly-installed slave unit is determined. In step 314, it is determined whether there is adequate space in the file system 412. If not, in step 316, the new file is not downloaded into the file system 412. If, on the other hand, there is adequate space, in step 318, the older version of the corresponding file backup is erased.
[ 0050 ] Steps 320 through 328 illustrate the process for the master module 102 reading the firmware from a slave unit 106. The firmware is read from the slave nonvolatile memory 208, 236, 252 using a series of instructions sent between the master module 102 and the slave unit 106.
[ 0051 ] Fig. 6 illustrates the read slave memory location instruction 502, which is sent by the master module 102 to the newly-installed slave unit 106. The read slave memory location instruction 502 includes a header with a format code, the high byte of the most significant word of the start address, the low byte of the most significant word of the start address, the high byte of the least significant word of the start address, the low byte of the least significant word of the start address, and the number of bytes to read.
[ 0052 ] Fig. 7 illustrates the memory data response packet 504, which is sent from the newly-installed slave unit 106 to the master module 102 in response to the read slave memory location instruction 502. The memory data response packet 512 includes a header with a format code, the number of bytes of data included, and the data starting at the start address indicated in the read slave memory location instruction 502 and ending after the number of bytes indicated in the read slave memory location instruction 502 is included.
[ 0053 ] Returning to Fig. 3, the master module 102 sends a read slave memory location instruction 502 to the newly-installed slave unit 106, indicating the start address, which is the address where the firmware of the slave unit 106 begins, and indicating that the first 128 bytes of the firmware should be read. In step 322, a memory data response packet 504 is received by the master module 102 from the slave unit 106, including the data at the start address. Then, in step 324, it is determined whether all of the bytes of the firmware of the slave unit 106 have been read. If so, the process proceeds to step 328. If not, in step 326, the address is then incremented to the next address, which is the address where the next 128 bytes of the firmware of the slave unit 106 begins. The process returns to step 320, at which point the next address is sent to the slave unit 106, and the next 128 bytes of the firmware is read.
[ 0054 ] When all of the bytes of the firmware of the newly-installed slave unit 106 have been read, in step 328 it is determined whether the read process was successful. This can be implemented using, among other methods, a checksum or CRC value, which is a value calculated from a portion of data used to verify the integrity of the data. If the read process was not successful, an error flag is set in step 330.
[ 0055 ] If the read process was successful, on the other hand, in step 332, the firmware image read from the newly-installed slave unit 106 is then stored in the file system 412 as a new backup copy of firmware, in one embodiment.
[ 0056 ] In step 334, the checksum/CRC of the firmware image newly-written to the file system 412 is then read and compared with that of the firmware of the newly-installed slave unit 106.
[ 0057 ] Then, in step 336, previously-installed slave units 106 of the same type as the newly-installed slave unit 106 are updated with the newly written firmware image stored on the file system 412.
[ 0058 ] Finally, in step 338, the device index 420 is updated with the new firmware version of any updated slave units 106. [ 0059 ] In the illustrated example, the fire sensor unit 106-6-2 is detected by the master module 102 as a newly-installed slave unit. It is then determined that the fire sensor unit firmware (v4) 410 installed on the newly-installed fire sensor unit nonvolatile memory 208-2 is version four of the fire sensor unit firmware. The file index 420 is then accessed, and it is determined that a previously-installed fire sensor unit 106-6 exists with a firmware version of three. It is also determined that the backup copy of the fire sensor firmware stored by the master module 102, which is the fire sensor unit firmware (v3) image 418, is also version three. Because the firmware version of the newly-installed fire sensor unit 106-6 (four) is more recent than that of the previously-installed fire sensor unit 106-6 (three) and the backup copy (three), it is determined that firmware for the previously- installed fire sensor units, and the corresponding backup copy, should be updated. It is then determined that there is adequate space on the file system 412, so the fire sensor unit firmware (v3) image 418 is erased.
[ 0060 ] Fig. 8 illustrates the memory for each of the master module 102, the battery unit 106-2, the display unit 106-1, and the two fire sensor units 106-6 installed on the fire system 100 after the corresponding older version of the backup copy of the firmware has been erased. In the illustrated example, the fire sensor unit firmware (v3) image 418 is no longer stored in the file system 412 on the master nonvolatile memory 220.
[ 0061 ] The fire sensor unit firmware (v4) 410 is then read from the fire sensor unit nonvolatile memory 208-2 of the newly-installed fire sensor unit 106-6 and stored as a backup in the file system 412.
[ 0062 ] Fig. 9 illustrates the memory for each of the master module 102, the battery unit 106-2, the display unit 106-1, and the two fire sensor units 106-6 installed on the fire system 100, after the backup copy of the fire sensor unit firmware (v4) 410 has been stored in the file system 412. The file system 412 now contains a fire sensor unit firmware (v4) image 422.
[ 0063 ] The previously installed fire sensor unit 106-6, containing the older version of the firmware, is then updated with the new firmware.
[ 0064 ] Fig. 10 illustrates the memory for each of the master module 102, the battery unit 106-2, the display unit 106-1, and the two fire sensor units 106-6 installed on the fire system 100, after the previously-installed fire sensor unit 106-6 is updated with the new firmware. The fire sensor unit nonvolatile memory 208-1 now contains the fire sensor unit firmware (v4) 410.
[ 0065 ] Finally, the device index 420 is updated.
[ 0066 ] Fig. 11 illustrates the device index 420, after it has been updated. The previously-installed fire sensor unit 106-6 (with device address 3 and serial number 0101) is now listed as having firmware version four.
[ 0067 ] While this invention has been particularly shown and described with references to preferred embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the scope of the invention encompassed by the appended claims.

Claims

CLAIMS What is claimed is:
1. A method for updating firmware of slave units in a fire system, the method comprising:
a master module determining a version of the firmware for a newly-installed slave unit; and
the master module updating the firmware of the newly-installed slave unit or previously-installed slave units based on the version of the firmware of the newly-installed slave unit.
2. The method as claimed in claim 1, wherein the master module updates the firmware of the newly-installed slave unit if a more-recent version of the firmware is present on the previously-installed slave units of the same type as the newly- installed slave unit.
3. The method as claimed in claim 1, wherein the master module updates the firmware of the newly-installed slave unit if a more-recent version of the firmware is accessible to master module.
4. The method as claimed in claim 1, wherein the master module updates a firmware image file with the firmware of the newly-installed slave unit if a more- recent version of the firmware is present on the newly-installed slave unit.
5. The method as claimed in claim 1, wherein the master module updates the firmware of the previously-installed slave units of the same type as the newly- installed slave unit if a more-recent version of the firmware is present on the newly- installed slave units.
6. The method as claimed in claim 5, wherein the master module reads and validates the firmware image read from the newly-installed slave unit.
7. The method as claimed in claim 1, wherein the master module first updates a firmware image file with the firmware of the newly-installed slave unit if a more- recent version of the firmware is present on the newly-installed slave unit; and then the master module updates the firmware of the previously-installed slave units of the same type as the newly-installed slave unit based on the updated firmware image file.
8. The method as claimed in claim 1, wherein the fire system is installed on a vehicle.
9. A fire system, comprising:
slave units of the fire system;
a master module determining a version of the firmware for a newly-installed slave unit and updating the firmware of the newly-installed slave unit or previously-installed slave units based on the version of the firmware of the newly-installed slave unit.
10. The system as claimed in claim 9, wherein the master module updates the firmware of the newly-installed slave unit if a more-recent version of the firmware is present on the previously-installed slave units of the same type as the newly- installed slave unit.
11. The system as claimed in claim 9, wherein the master module updates the firmware of the newly-installed slave unit if a more-recent version of the firmware is accessible to master module.
12. The system as claimed in claim 9, wherein the master module updates a firmware image file with the firmware of the newly-installed slave unit if a more- recent version of the firmware is present on the newly-installed slave unit.
13. The system as claimed in claim 9, wherein the master module updates the firmware of the previously-installed slave units of the same type as the newly- installed slave unit if a more-recent version of the firmware is present on the newly- installed slave units.
14. The system as claimed in claim 9, wherein the master module reads and validates the firmware image read from the newly-installed slave unit.
15. The system as claimed in claim 9, wherein the master module first updates a firmware image file with the firmware of the newly-installed slave unit if a more- recent version of the firmware is present on the newly-installed slave unit; and then the master module updates the firmware of the previously-installed slave units of the same type as the newly-installed slave unit based on the updated firmware image file.
16. The system as claimed in claim 9, wherein the fire detection system is installed on a vehicle.
EP17717877.9A 2016-04-11 2017-04-11 Fire detection system with automatic firmware updating Withdrawn EP3443454A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US15/095,680 US20170293478A1 (en) 2016-04-11 2016-04-11 Fire detection system with automatic firmware updating
PCT/IB2017/052095 WO2017178975A1 (en) 2016-04-11 2017-04-11 Fire detection system with automatic firmware updating

Publications (1)

Publication Number Publication Date
EP3443454A1 true EP3443454A1 (en) 2019-02-20

Family

ID=58548784

Family Applications (1)

Application Number Title Priority Date Filing Date
EP17717877.9A Withdrawn EP3443454A1 (en) 2016-04-11 2017-04-11 Fire detection system with automatic firmware updating

Country Status (13)

Country Link
US (1) US20170293478A1 (en)
EP (1) EP3443454A1 (en)
CN (1) CN109564506B (en)
AU (2) AU2017250616A1 (en)
BR (1) BR112018070911A2 (en)
CA (1) CA3018298A1 (en)
CL (1) CL2018002817A1 (en)
CO (1) CO2018011788A2 (en)
MX (1) MX2018012452A (en)
PE (1) PE20190074A1 (en)
RU (1) RU2731319C2 (en)
WO (1) WO2017178975A1 (en)
ZA (1) ZA201806278B (en)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10453320B2 (en) 2016-04-11 2019-10-22 Johnson Controls Fire Protection LP Addressing method for slave units in fire detection system
US10860541B2 (en) * 2016-04-11 2020-12-08 Johnson Controls Fire Protection LP Fire detection system with distributed file system
CN111142917A (en) * 2019-12-18 2020-05-12 广东美的厨房电器制造有限公司 Household appliance multi-MCU system online upgrading method, electronic equipment and medium
US11150889B1 (en) 2020-05-29 2021-10-19 Honeywell International Inc. Usage profile based remote firmware upgrade for fire alarm system gateway
CN112540781A (en) * 2020-12-15 2021-03-23 东莞新能安科技有限公司 Software upgrading method of battery management system, electric equipment and storage medium
PL4046692T3 (en) * 2020-12-25 2024-09-09 Contemporary Amperex Technology Co., Limited Firefighting switch device and firefighting system

Family Cites Families (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE4315494C1 (en) * 1993-05-10 1994-09-29 Daimler Benz Ag Arrangement and method for programming at least one motor vehicle control unit
US6892256B1 (en) * 2001-05-01 2005-05-10 Cisco Technology, Inc. Automated system for storing revision information from slave programmable devices in a master programmable device
US7028177B2 (en) * 2002-01-31 2006-04-11 Hewlett-Packard Development Company, L.P. Array controller ROM cloning in redundant controllers
EP1494125A1 (en) * 2003-07-03 2005-01-05 Thomson Licensing S.A. Method and data structure for random access via a bus connection
WO2005093567A1 (en) * 2004-03-09 2005-10-06 Bayerische Motoren Werke Aktiengesellschaft Updating and/or enlarging the functionality of the operating control of at least one control device
US7185191B2 (en) * 2004-05-05 2007-02-27 International Business Machines Corporation Updatable firmware having boot and/or communication redundancy
JP4668645B2 (en) * 2005-02-24 2011-04-13 パナソニック株式会社 DMA controller and data transfer control method
US7600055B2 (en) * 2006-01-03 2009-10-06 International Business Machines Corporation Apparatus, system, and method for firmware update of redundant controllers
KR100782080B1 (en) * 2006-09-07 2007-12-04 삼성전자주식회사 Updating method for mobile communication terminal and system
JP2008269395A (en) * 2007-04-23 2008-11-06 Fujitsu Ten Ltd Multimedia system and navigation unit terminal
DE102007024737A1 (en) * 2007-05-25 2008-11-27 Robert Bosch Gmbh Data transfer method between master and slave devices
US8255896B2 (en) * 2008-04-01 2012-08-28 Honeywell International Inc. Network software normalization and installation in a fire detection system
KR100951622B1 (en) * 2008-05-02 2010-04-09 강릉원주대학교산학협력단 Method for updating firmware of sensor nodes on a wireless sensor network and firmware updater using for the same method
KR101029758B1 (en) * 2008-12-31 2011-04-19 노틸러스효성 주식회사 A method for firmware updating in remote
US8966101B2 (en) * 2009-08-10 2015-02-24 Sling Media Pvt Ltd Systems and methods for updating firmware over a network
US9098450B2 (en) * 2012-03-20 2015-08-04 Google Inc. Automated application update checks based on unexpected errors and crashes
CN103377057B (en) * 2012-04-20 2016-05-25 上海通用汽车有限公司 A kind of system and method for the software that refreshes user's Car Electronic Control module
CN102707976B (en) * 2012-05-14 2017-02-08 中兴通讯股份有限公司 ATCA (advanced telecom computing architecture) system and method for managing firmware versions by ATCA system
CN102779057A (en) * 2012-06-29 2012-11-14 浪潮(北京)电子信息产业有限公司 Base board management controller and automatic upgrade system and method thereof
US20140068561A1 (en) * 2012-09-05 2014-03-06 Caterpillar Inc. Control system having automatic component version management
JP5961081B2 (en) * 2012-09-06 2016-08-02 キヤノン株式会社 Monitoring device, management system, firmware update method, and program
US9307067B2 (en) * 2014-07-30 2016-04-05 Google Technology Holdings LLC Contextually updating wireless device firmware
CN104636166B (en) * 2015-02-06 2018-02-09 福建实达电脑设备有限公司 A kind of NandFlash firmware burnings device and method for burn-recording
CN104915237B (en) * 2015-06-24 2019-02-15 深圳市海蕴新能源有限公司 Upgrading, upgrade control method and the equipment of bluetooth equipment firmware program

Also Published As

Publication number Publication date
WO2017178975A1 (en) 2017-10-19
RU2018139565A (en) 2020-05-12
CA3018298A1 (en) 2017-10-19
PE20190074A1 (en) 2019-01-14
CN109564506A (en) 2019-04-02
AU2017250616A1 (en) 2018-10-04
MX2018012452A (en) 2019-09-09
US20170293478A1 (en) 2017-10-12
BR112018070911A2 (en) 2019-01-29
CN109564506B (en) 2022-06-03
RU2018139565A3 (en) 2020-06-29
AU2022202316A1 (en) 2022-04-28
CL2018002817A1 (en) 2019-01-25
ZA201806278B (en) 2019-12-18
CO2018011788A2 (en) 2019-03-18
RU2731319C2 (en) 2020-09-01

Similar Documents

Publication Publication Date Title
AU2022202316A1 (en) Fire detection system with automatic firmware updating
AU2017250617B2 (en) Fire detection system with distributed file system
US11308739B2 (en) Automatic driving system, vehicle control method and device
US11017091B2 (en) Firmware map data
CN110244958B (en) Method and device for updating calibration data of a vehicle
EP3009308B1 (en) Control device that controls protection device for protecting vehicle passenger or pedestrian, and control system
US11084462B2 (en) Method for modifying safety and/or security-relevant control devices in a motor vehicle
EP3293659A1 (en) Network monitoring device, network system and computer-readable medium
CN109017810B (en) Vehicle chassis fault detection method and device, vehicle-mounted equipment and storage medium
EP3805918B1 (en) Program update system, program transmission device, and program transmission method
CN114489500A (en) Fault data processing method, system, equipment and computer readable storage medium
CN108924835B (en) Vehicle control system, method and safety control unit
US8095262B2 (en) Vehicular control apparatus and program storage medium
JP4367275B2 (en) Data storage device
KR101207342B1 (en) Car digital tachograph apparatus having auto upgrade function
CN107861740A (en) Method for refreshing, storage medium and the car body control module of power windows demarcating file
CN116414622A (en) MDVR system repairing method, MDVR and driving monitoring system
CN115298064A (en) Software update device, software update method, and software update processing program
JP2007176337A (en) Failure data storage device and erasing method therefor

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20181005

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20191125

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN WITHDRAWN

18W Application withdrawn

Effective date: 20220628