WO2014091666A1 - 車載電子制御装置 - Google Patents

車載電子制御装置 Download PDF

Info

Publication number
WO2014091666A1
WO2014091666A1 PCT/JP2013/006515 JP2013006515W WO2014091666A1 WO 2014091666 A1 WO2014091666 A1 WO 2014091666A1 JP 2013006515 W JP2013006515 W JP 2013006515W WO 2014091666 A1 WO2014091666 A1 WO 2014091666A1
Authority
WO
WIPO (PCT)
Prior art keywords
error
cpu
memory
abnormality
block
Prior art date
Application number
PCT/JP2013/006515
Other languages
English (en)
French (fr)
Inventor
雅人 久米
康志 神田
Original Assignee
株式会社デンソー
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 株式会社デンソー filed Critical 株式会社デンソー
Priority to US14/651,195 priority Critical patent/US9778970B2/en
Priority to DE112013005928.2T priority patent/DE112013005928T5/de
Publication of WO2014091666A1 publication Critical patent/WO2014091666A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0736—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function
    • G06F11/0739—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function in a data processing system embedded in automotive or aircraft systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/073—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a memory management context, e.g. virtual memory or cache management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0751—Error or fault detection not based on redundancy
    • G06F11/0754—Error or fault detection not based on redundancy by exceeding limits
    • G06F11/076—Error or fault detection not based on redundancy by exceeding limits by exceeding a count or rate limit, e.g. word- or bit count limit
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0766—Error or fault reporting or storing
    • G06F11/0784—Routing of error reports, e.g. with a specific transmission path or data flow
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0766—Error or fault reporting or storing
    • G06F11/0787—Storage of error reports, e.g. persistent data storage, storage using memory protection
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/079—Root cause analysis, i.e. error or fault diagnosis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0793—Remedial or corrective actions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/16—Protection against loss of memory contents
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1415—Saving, restoring, recovering or retrying at system level
    • G06F11/1433—Saving, restoring, recovering or retrying at system level during software upgrading

Definitions

  • This disclosure relates to an on-vehicle electronic control device.
  • An on-vehicle electronic control device mounted on a vehicle includes a microcomputer including a memory in which various programs are stored and a CPU, and the CPU controls each part of the vehicle by executing the various programs.
  • a nonvolatile memory such as a flash memory or an EEPROM is generally used so that a program can be rewritten (hereinafter referred to as “reprogramming”).
  • Memory reprogramming is generally performed by a CPU executing a reprogramming program (hereinafter referred to as “reprogramming software”) stored as one of various programs (for example, Patent Documents). 1).
  • Patent Document 1 describes the following technique. That is, the reprogramming software is configured to set an identification ID indicating that reprogramming is being performed during reprogramming, and to set an identification ID indicating that reprogramming is completed normally.
  • the CPU first looks at the identification ID at the time of start-up, and if an identification ID indicating that reprogramming has been normally completed is set, the CPU proceeds to execution of a normal control program (hereinafter referred to as “ECU software”). If the identification ID indicating that programming is in progress remains set, the reprogramming software is activated again to wait for another reprogramming operation.
  • ECU software normal control program
  • the above technology can be realized with the following configuration. That is, in addition to the reprogramming software, a storage area for the identification ID is provided in the memory and the activation determination processing program is stored, and the address of the activation determination processing program is set in the reset vector. After the reset, the CPU first acquires an address set in the reset vector and executes a program (that is, a start determination processing program) at that address. In the activation determination process, it is determined whether the identification ID indicates reprogramming in progress or reprogramming completion. If the identification ID indicates reprogramming completion, normal ECU software is activated. If it indicates that programming is in progress, the reprogramming software is activated.
  • the memory programming error occurs due to the above-described reprogramming failure, it can occur due to various factors such as data corruption due to noise and hardware failure. That is, even if the reprogramming is completed normally, the program in the memory may be in an abnormal state depending on the subsequent use state of the ECU or environment (especially electromagnetic environment).
  • a software memory check eg, ROM sum check
  • ROM sum check a software memory check
  • the microcomputer continues to operate (generally, intermittent operation) while the vehicle engine is stopped, and continues to consume power from the on-vehicle battery. For this reason, if a program abnormality occurs when the engine is stopped, the ECU software is not normally executed, and in addition to that, the battery power may continue to decrease due to repeated resets, and the battery may run out.
  • the present disclosure has been made in view of the above problems, and even if a program abnormality occurs in a vehicle-mounted electronic control device configured to reset the CPU (microcomputer) itself when a program abnormality is determined by a memory check, power is wasted. It aims at providing the technique which can perform an appropriate process, suppressing consumption.
  • the on-vehicle electronic control device includes a memory, a CPU, an abnormality frequency storage unit, an abnormality frequency update unit, an abnormality determination unit, and an abnormality response unit.
  • the memory is a non-volatile memory in which a plurality of programs including a control program for controlling the vehicle are stored.
  • the CPU executes a plurality of programs stored in the memory, periodically performs a memory check to determine whether the memory contents are normal, and determines that the memory contents are abnormal by the memory check. If so, it is configured to reset itself.
  • the abnormality number storage unit stores the number of abnormalities that is the number of times the memory content is determined to be abnormal by the memory check.
  • the abnormality number updating unit updates the abnormality number stored in the abnormality number storage unit before the CPU is reset every time the memory content is determined to be abnormal by the memory check.
  • the abnormality determination unit determines whether or not the number of abnormalities stored in the abnormality number storage unit is equal to or greater than a predetermined abnormality determination threshold before the first memory check is performed after the CPU is reset.
  • the abnormality handling unit causes the CPU to execute a specific error handling processing program among the plurality of programs when the abnormality determination unit determines that the number of abnormalities is equal to or greater than the abnormality determination threshold.
  • the CPU does not perform a memory check or a reset based on the memory check while the error handling program is being executed.
  • the on-vehicle electronic control device configured as described above, whenever the memory check determines that the program is abnormal, the number of abnormalities is stored (updated) before the CPU is reset, and the number of abnormalities after the reset is equal to or greater than the abnormality determination threshold value. If so, an error handling program is executed. When the error handling program is executed, reset by memory check is not performed. For this reason, even if an abnormality occurs in the storage contents of the memory, it is possible to perform appropriate processing while suppressing unnecessary power consumption.
  • the abnormality frequency storage unit, the abnormality determination unit, and the abnormality handling unit can be configured by hardware different from the memory and the CPU. By configuring these units with hardware separate from the memory and CPU, the reliability of updating the number of abnormalities in memory checks and the execution of error handling processing programs based on the number of abnormalities is high regardless of the state of the memory. Will be realized quickly.
  • FIG. 1 is a block diagram illustrating a schematic configuration of the vehicle control system of the embodiment.
  • FIG. 2 is an explanatory diagram showing an arrangement of programs and the like of the flash memory according to the first embodiment.
  • FIG. 3 is a block diagram illustrating a schematic configuration of the error determination module according to the first embodiment.
  • FIG. 4 is a flowchart showing the operation of the CPU of the first embodiment.
  • FIG. 5 is an explanatory diagram showing the arrangement of programs and the like of the flash memory according to the second embodiment.
  • FIG. 6 is a block diagram illustrating a schematic configuration of the error determination module according to the second embodiment.
  • FIG. 7 is a flowchart showing the operation of the CPU of the second embodiment.
  • a vehicle control system 10 of this embodiment shown in FIG. 1 is a system that is mounted on a vehicle and controls each part of the vehicle, and includes a plurality of ECUs 11, 12, 13,. Are configured to be able to perform data communication with each other via an in-vehicle network (for example, CAN) 20.
  • an in-vehicle network for example, CAN
  • each ECU11,12,13 various ECUs, such as engine ECU, body ECU, navigation ECU, are mentioned, for example.
  • the in-vehicle network 20 is connected with a connector 14 for connecting the program rewriting tool 15.
  • a connector 14 for connecting the program rewriting tool 15.
  • Each ECU 11, 12, 13... Includes a microcomputer, and the microcomputer executes various control processes to realize control of each part of the vehicle.
  • the microcomputer executes various control processes to realize control of each part of the vehicle.
  • at least one ECU 11 has a characteristic configuration including an error determination module 26 (details will be described later). Therefore, in the following description, the configuration and function of the ECU 11 will be described in detail.
  • the ECU 11 includes a CPU 21, a RAM 22, a flash memory 23, a communication interface (communication I / F) 24, a timer 25, an error determination module 26, and the like.
  • the CPU 21, RAM 22, flash memory 23, communication I / F 24, timer 25, and error determination module 26 are integrated in one semiconductor integrated circuit as a one-chip microcomputer.
  • the configuration is not limited to a one-chip microcomputer.
  • the CPU 21 realizes control of each part of the vehicle by executing various programs stored in the flash memory 23.
  • the CPU 21 has a general configuration including various registers and a program counter (not shown).
  • the CPU 21 of the present embodiment causes the error determination module 26 to execute error determination processing as described later at the start of startup immediately after reset. Then, by jumping to the address of the flash memory 23 designated by the error determination module 26, processing based on various programs in the flash memory 23 is started.
  • the flash memory 23 is a nonvolatile memory capable of electrically rewriting stored contents.
  • the flash memory 23 stores various programs as shown in FIG. Specifically, the flash memory 23 includes a reset vector, a start determination processing program, reprogramming software, ROM sum check value, rewrite status, OS (scheduler), program A, program B,... Program m (fail safe) Software).
  • the reset vector is a head address of a program that is set in a memory in a general microcomputer and starts executing by the CPU. Note that the memory address of the reset vector is 0x0000.
  • the activation determination processing program determines whether or not the previously executed reprogramming has been normally completed based on the rewrite status. If the reprogramming is normally completed, the normal ECU software is activated and is not normally completed. The case is a program configured to start reprogramming software. The start address of this activation determination processing program is set in the reset vector.
  • the normal ECU software is a general term for each program that substantially controls the vehicle, such as the OS and the programs A, B,.
  • the OS starts processing, and after passing through initialization processing and ROM sum check, monitoring each input information input to the microcomputer, the programs A, B,. ⁇ Schedule.
  • the reprogramming software is a program for reprogramming each program in the flash memory 23. That is, when the reprogramming software is executed, reprogramming is performed by acquiring an updated version program of the program to be reprogrammed via the in-vehicle network 20 and writing it into the flash memory 23.
  • the update version program can be transmitted from the program rewriting tool 15 by connecting the program rewriting tool 15 to the connector 14, for example. More specific functions and the like of the reprogramming software are described in detail in Patent Document 1. Note that reprogramming may be performed collectively for the entire flash memory 23, or may be performed in units of programs or blocks.
  • the reprogramming software When the reprogramming software starts reprogramming, it sets the rewrite status to “Rewriting” (actually sets binary data indicating “Rewriting”). When reprogramming is normally completed, the rewrite status is set to “rewrite complete”. After reprogramming is started, the rewrite status remains “rewriting” unless reprogramming is normally completed.
  • the ROM sum check value is a check code (check code) when performing a memory check using a check sum.
  • the ROM sum check value of the present embodiment is a value set for the entire storage contents of the flash memory 23.
  • the ROM sum check value is updated to a value corresponding to the stored contents after reprogramming every time reprogramming is performed.
  • Program m (corresponding to an example of the error handling processing program of the present disclosure) is fail-safe software that is executed when an error is determined by error determination processing by the error determination module 26 immediately after reset.
  • the ECU software is not normally executed, and various fail-safe processes based on the fail-safe software are performed.
  • the memory address of the fail-safe software is 0xYYYY.
  • the error determination module 26 is configured by hardware provided independently of the CPU 21 and the flash memory 23.
  • the address (0xXXXX) of the error determination module 26 is first set in the program counter immediately after the reset. Based on this, the CPU 21 first operates the error determination module 26.
  • the conventional CPU generally has a configuration in which the memory address of the reset vector is first set in the program counter after the reset and jumps to the reset vector.
  • the CPU 21 of the present embodiment first has the error determination module 26 first after the reset. Is set in the program counter, and the process proceeds to the error determination module 26.
  • the error determination module 26 includes an error determination start register 31, an error count storage register 32, an error determination threshold register 33, a comparator 34, an error determination start destination register 35, and a start destination determiner 36.
  • the error determination activation register 31 is a register in which a predetermined error determination activation flag is set by the CPU 21 immediately after the CPU 21 is reset.
  • the error determination activation register 31 activates the comparator 34 when the CPU 21 sets an error determination activation flag. For example, while clearing the error determination activation flag, “0” is output to stop the comparator 34, and when the error determination activation flag is set, “1” is output to activate the comparator 34.
  • the error count storage register 32 is determined to be abnormal by the CPU 21 each time it is determined to be abnormal in the ROM sum check that is executed when the CPU 21 starts the normal ECU software and periodically during execution of the normal ECU software. This is a register in which the number of times of error (corresponding to an example of the number of abnormalities of the present disclosure) is cumulatively stored (updated). The initial value of the error count in the error count storage register 32 is 0, and the CPU 21 increments the error count by one every time it is determined as abnormal by the ROM sum check.
  • the error count storage register 32 can correspond to an example of an abnormal count storage means and an abnormal count storage section.
  • the error determination threshold value register 33 is a register that stores an error determination threshold value (corresponding to an example of the abnormality determination threshold value of the present disclosure).
  • the error determination threshold is a determination reference value for determining whether an error has occurred in the flash memory 23 based on the number of errors stored in the error number storage register 32.
  • the error determination threshold can be determined as appropriate, but is preferably a value of 2 or more. In this embodiment, the error determination threshold is set to 10, for example.
  • the comparator 34 compares the error count stored in the error count storage register 32 with the error determination threshold stored in the error determination threshold register 33, and generates error determination data indicating the comparison result as the activation destination determiner 36. Output to. Specifically, when the number of errors is less than the error determination threshold, “0” indicating that no error has occurred is output as error determination data, and when the number of errors is greater than or equal to the error determination threshold, an error is generated as error determination data. “1” is output.
  • the comparator 34 can correspond to an example of an abnormality determination unit and an abnormality determination unit.
  • the activation destination determination unit 36 sets the activation destination address of the CPU 21 in the flash memory 23 based on the error determination data from the comparator 34 and outputs it to the CPU 21. Specifically, when the error determination data is “0” (no error has occurred), the reset vector address (0x0000) is set as the activation destination and the activation destination address is output to the CPU 21. Specifically, the activation destination address (0x0000) is set in the program counter in the CPU 21. When the error determination data is “1” (error occurrence), the error determination start address stored in advance in the error determination start destination register 35 (in this example, 0xYYYY, which is the start address of the failsafe software) Is set as the activation destination, and the activation destination address is output to the CPU 21. Specifically, the activation destination address (0xYYYY) is set in the program counter in the CPU 21.
  • the activation destination determination unit 36 can correspond to an example of an abnormality handling unit and an abnormality handling unit.
  • the CPU 21 jumps to the address (reset vector or fail-safe software) set in the program counter.
  • the error count storage register 32, the error determination threshold register 33, and the error determination start destination register 35 are different from registers (not shown) in the CPU 21 and the stored contents are maintained even when the microcomputer is reset.
  • the CPU 21 operates the error determination module 26 as described above and waits for an error determination result. That is, the comparator 34 determines whether or not the error count in the error count storage register 32 is equal to or greater than the error determination threshold value in the error determination threshold register 33 (S110).
  • the activation destination determination unit 36 sets the reset vector address (0x0000) in the program counter of the CPU 21 (S120).
  • the activation destination determination unit 36 sets the error determination activation destination address (0xYYYY in this example) stored in the error determination activation destination register 35 in the program counter of the CPU 21. (S130).
  • S110 to S130 are not processes directly executed by the CPU 21, but are processes of the error determination module 26 that operates according to a command from the CPU 21, and in a broad sense, can also be regarded as processes that are executed indirectly by the CPU 21. Therefore, in FIG. 4, the process of the error determination module 26 is also included in the process of the CPU 21.
  • the CPU 21 jumps to the reset vector in the flash memory 23 in S140. If the activation destination address at the time of error determination is set in the program counter at S130, the CPU 21 jumps to the activation destination address at the time of error determination (that is, fail-safe software at address 0xYYYY of the flash memory 23) at S150.
  • the processing of S110 to S150 is processing realized as hardware processing by the CPU 21 and the error determination module 26 before the CPU 21 performs various processing based on the program in the flash memory 23.
  • the CPU 21 prior to performing software processing based on the program, the CPU 21 performs error determination, jump destination address setting, and the like by hardware processing. After jumping to the jump destination address set by the hardware process, the process proceeds to S160 or later or S280 software process.
  • the program of the address set in the reset vector that is, the activation determination process is executed.
  • S170 it is determined whether or not the rewriting status is determined to be “rewriting complete” in the activation determination process. If it is not determined to be “rewriting complete” (that is, “rewriting is still in progress”), the process proceeds to S260. .
  • the reprogramming software is activated, waits for the connection of the program rewriting tool 15, and when connected, the existing program is rewritten with the updated version program.
  • the ECU software is normally activated by starting the initialization process by the OS in S180, and the ROM sum check (OS disclosed in this disclosure) is started in S190. Equivalent to an example of a memory check).
  • the ROM sum check (OS disclosed in this disclosure) is started in S190. Equivalent to an example of a memory check).
  • S200 it is determined whether or not the result of the ROM sum check in S190 is OK (normal). If it is OK, the normal ECU software is executed as it is in S210.
  • ROM sum check is performed periodically as shown in S220 to S240. That is, when the ROM sum check execution timing comes, the ROM sum check is executed in S220, and it is determined in S230 whether the result of the ROM sum check in S220 is OK. If it is determined to be OK in S230, the normal ECU software is continuously executed (continue) in S240, and when the ROM sum check execution timing comes again, the process returns to S220 to execute the ROM sum check.
  • the error count is written in the error count storage register 32 in the error determination module 26 in S250. That is, the currently stored error count is updated (incremented by one).
  • the CPU 21 itself resets the CPU 21 (that is, resets the microcomputer).
  • the CPU 21 that executes S250 can correspond to an example of an abnormal number update unit and an abnormal number update unit.
  • failsafe processing is performed in S280. That is, the fail-safe software stored in 0xYYYY that is the activation destination address at the time of error determination is executed.
  • the number of errors is updated before the CPU 21 is reset every time it is determined that the ROM sum check is abnormal (S250). If the number of errors is equal to or greater than the error determination threshold, failsafe processing software is executed (S280).
  • the fail safe processing software is executed independently of the normal processing flow starting from the jump to the reset vector, and the ROM sum check is not performed during the execution of the fail safe processing software. That is, the microcomputer reset due to the abnormality of the ROM sum check is not repeatedly performed. Therefore, even if an abnormality occurs in the storage contents of the flash memory 23, appropriate processing (fail-safe processing in the present embodiment) can be performed while suppressing wasteful power consumption.
  • the fail-safe processing software is executed at the time of error determination only as an example, and what kind of processing is specifically executed at the time of error determination can be appropriately determined.
  • the reprogramming software may be activated to transition to a reprogramming wait.
  • the occurrence of a failure may be notified to the user (vehicle driver or the like) by some method.
  • the ROM sum check even if it is determined as abnormal by the ROM sum check, it does not immediately shift to fail-safe processing by only one abnormality determination, and the number of times determined as abnormal (number of errors) is equal to or greater than the error determination threshold. When it becomes, it is going to shift to fail safe processing. Therefore, the accuracy of error determination can be increased.
  • the number of errors is stored / updated using the error number storage register 32 provided separately from the RAM 22 and the flash memory 23. Therefore, the number of errors can be reliably stored regardless of the state of the RAM 22 or the flash memory 23, thereby further improving the accuracy of error determination.
  • the error determination immediately after the CPU 21 is reset is realized by hardware processing by the error determination module 26 instead of software processing. Therefore, error determination can be performed quickly and with high reliability. Further, if the error determination is to be realized by software processing, the storage area of the flash memory 23 is required correspondingly, which may increase the cost. However, the error determination may be realized by hardware processing as in the present embodiment. Such problems can be suppressed.
  • the ECU according to the second embodiment will be described by focusing on portions different from the ECU 11 according to the first embodiment shown in FIG.
  • the main parts of the ECU (not shown) of the present embodiment that are different from the ECU 11 of the first embodiment are the storage contents of the flash memory and the configuration of the error determination module.
  • the storage area is divided into a plurality of blocks, and a check code for ROM sum check (that is, ROM sum check value) is set for each block. Note that how the flash memory 23 is specifically divided into blocks can be determined as appropriate.
  • the error determination module 40 of the present embodiment is as shown in FIG. 6, and as apparent from the error determination module 26 of the first embodiment shown in FIG. 3, the error count storage register 32 and the error determination threshold value.
  • the configuration of the register 33 is different.
  • an error occurrence block register 41 is newly provided between the comparator 34 and the activation destination determination unit 36.
  • the error number storage register 32 of the present embodiment is individually provided for each block of the flash memory. That is, there are provided a plurality of error count storage registers for each block such as an error count storage register 32A corresponding to block 0, an error count storage register 32B corresponding to block 1, an error count storage register 32C corresponding to block 2, and so on. It has been.
  • the error determination threshold value register 33 is also provided for each block of the flash memory. That is, a plurality of error determination threshold registers for each block are provided, such as an error determination threshold register 33A corresponding to block 0, an error determination threshold register 33B corresponding to block 1, an error determination threshold register 33C corresponding to block 2, and so on. It has been.
  • the comparison between the number of errors and the error determination threshold by the comparator 34 is also performed individually for each block. For example, for block 0, the error count stored in the error count storage register 32A corresponding to block 0 is compared with the error determination threshold stored in the error determination threshold register 33A corresponding to block 0.
  • the comparator 34 performs the above comparison individually for each of the blocks 0 to n. If there is a block in which an error has occurred (that is, a block whose error count is equal to or greater than the error determination threshold value), the comparator 34 Set the error block flag.
  • the error occurrence block register 41 a flag indicating whether or not an error has occurred is set for each block.
  • the comparator 34 determines that an error has occurred for a certain block, the flag of the corresponding block in the error occurrence block register 41 is set by the comparator 34. That is, by referring to the error occurrence block register 41, it is possible to know which block is normal and which block has an error.
  • the error occurrence block register 41 While any block is normal, the error occurrence block register 41 outputs “0” indicating that no error has occurred as error determination data to the activation destination determination unit 36, but the flag of any one block is set. Then (that is, when any one of the blocks is determined to be an error), “1” indicating an error occurrence is output to the activation destination determination unit 36 as error determination data.
  • the CPU of the present embodiment operates the error determination module 40 and waits for an error determination result. That is, the comparator 34 compares the error count and the error determination threshold for each block (S310). As a result of the comparison, if there is no block whose error count is equal to or greater than the error determination threshold, the process proceeds to S320. If any one of the blocks is equal to or greater than the error determination threshold, the process proceeds to S325.
  • a flag indicating an error occurrence block is set in the error occurrence block register 41.
  • the processes of S330 and S350 are the same as the processes of S130 and S150 of FIG.
  • the fail-safe process of S480 is slightly different from the fail-safe process of S280 of FIG. That is, in the fail-safe process (S480) of this embodiment, the program of one or a plurality of other blocks is accessed (referenced) as appropriate and executed. However, the setting value of the error occurrence block register 41 is read and the program in the block is not accessed for the error occurrence block.
  • S320 to S380, S400, S410, S430, S440, and S460 are the same as the processes of S120 to S180, S200, S210, S230, S240, and S260 in FIG. 4, respectively.
  • the ROM sum check in S390 and S420 is different from the first embodiment in that it is executed individually for each block.
  • the error count write (increment) to the error count storage register 32 in S450 is also different from the first embodiment in that the error count corresponding to the block determined to be abnormal by the ROM sum check is incremented for each block.
  • the CPU 21 that executes S450 can correspond to an example of an abnormal number update unit and an abnormal number update unit.
  • error determination is performed for each block, and if any one of the blocks is determined to be error, the process proceeds to fail-safe processing. And an appropriate response (fail-safe process) to the occurrence of an error can be taken more quickly.
  • blocks with errors can be distinguished from blocks without errors, blocks that cannot be accessed in fail-safe processing can be minimized, and degradation of fail-safe processing can be suppressed. be able to.
  • error determination immediately after reset is realized by hardware processing by the error determination module (see FIGS. 3 and 6), but the function of the error determination module is realized by software processing. May be.
  • a configuration realized by hardware processing as in the above embodiment is preferable.
  • the ROM sum check is used as a method for checking the stored contents of the flash memory 23.
  • this is only an example, and the memory check is performed using other various methods (for example, CRC). It may be.
  • the comparator 34 compares the error count and the error determination threshold for all the blocks. However, any one or a predetermined number (plural) (the error of the present disclosure) When error determination (corresponding to an example of the number of corresponding reference blocks) is performed (error count ⁇ error determination threshold), the comparison is stopped at that time, and the flag of the error occurrence block register 41 is set for these error determination blocks. Also good.
  • ROM sum check in S390 and S420 either one or a predetermined number of ROM sum checks are sequentially performed for each block instead of performing the ROM sum check for all the blocks and then proceeding to S450. If an abnormality is determined in the ROM sum check for a block (corresponding to an example of the number of reset reference blocks of the present disclosure), the ROM sum check may be stopped at that time and the process may proceed to S450.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Health & Medical Sciences (AREA)
  • Biomedical Technology (AREA)
  • Debugging And Monitoring (AREA)
  • Techniques For Improving Reliability Of Storages (AREA)
  • Retry When Errors Occur (AREA)

Abstract

　プログラム異常が発生しても、電力の無駄な消費を抑えつつ適切な処理を行うことができる車載電子制御装置を提供する。ＣＰＵは、メモリチェックを定期的に行い、メモリの記憶内容が異常と判断した場合は、その異常と判断した回数（エラー回数）をエラー回数記憶部３２に書き込んで、自身をリセットする。ＣＰＵのリセット直後、最初にメモリチェックが行われる前に、異常判定部が、エラー回数記憶部３２に記憶されているエラー回数がエラー判定閾値以上か否かを判定する。エラー回数がエラー判定閾値以上だった場合、異常対応部３６が、メモリ内の各プログラムのうち特定のエラー対応処理プログラムをＣＰＵに実行させる。

Description

車載電子制御装置 関連出願の相互参照
　本出願は、２０１２年１２月１２日に出願された日本国特許出願２０１２－２７１４６４号に基づくものであり、ここにその開示を参照により援用する。
　本開示は、車載電子制御装置に関する。
　車両に搭載される車載電子制御装置（以下「ＥＣＵ」という）は、各種プログラムが記憶されたメモリやＣＰＵなどからなるマイコンを備え、ＣＰＵが各種プログラムを実行することで車両の各部を制御する。メモリとしては、一般に、プログラムの書き換え（以下「リプログラミング」という）ができるよう、フラッシュメモリやＥＥＰＲＯＭなどの不揮発性メモリが用いられる。メモリのリプログラミングは、各種プログラムの１つとして記憶されているリプログラミング用のプログラム（以下「リプログラミングソフト」という）をＣＰＵが実行することにより行われることが一般的である（例えば、特許文献１参照。）。
　メモリのリプログラミングが行われる際に、例えばＥＣＵの電源遮断やリプログラミング処理の異常などの様々な要因によって、そのリプログラミングが失敗するおそれがある。そのようなリプログラミングの失敗を想定して、特許文献１には、次のような技術が記載されている。即ち、リプログラミングソフトを、リプログラミング中はリプログラミング中である旨の識別ＩＤを設定し、リプログラミングが正常に完了したらその旨の識別ＩＤを設定するよう構成する。そして、ＣＰＵは、起動時にまず上記識別ＩＤをみて、リプログラミングが正常に完了した旨の識別ＩＤが設定されていれば通常の制御用プログラム（以下「ＥＣＵソフト」という）の実行に移り、リプログラミング中である旨の識別ＩＤが設定されたままならば再びリプログラミングソフトを起動して再度のリプログラミング作業を待つ。
　上記技術は、より具体的には、次のような構成で実現できる。即ち、メモリ内に、リプログラミングソフトの他に識別ＩＤの記憶領域を設けると共に起動判定処理プログラムを格納し、リセットベクタにはその起動判定処理プログラムのアドレスを設定しておく。ＣＰＵは、リセット後まずリセットベクタに設定されているアドレスを取得してそのアドレスのプログラム（即ち起動判定処理プログラム）を実行する。起動判定処理は、識別ＩＤがリプログラミング中を示すものであるかそれともリプログラミング完了を示すものであるかを判断して、リプログラミング完了を示すものならば通常のＥＣＵソフトを起動させるが、リプログラミング中を示すものならばリプログラミングソフトを起動させるという処理である。
　このような技術により、仮にリプログラミングに失敗してメモリのプログラムが異常な状態になったとしても、その後リセットされた際に起動判定処理によりリプログラミングの成否が判定され、リプログラミングが正常に完了していない場合は再びリプログラミング待ちに遷移させることができる。
　ところで、メモリのプログラム異常は、上述したリプログラミングの失敗により発生するケース以外にも、例えばノイズによるデータ化けやハードウェア故障などの様々な要因で発生し得る。つまり、リプログラミングは正常に完了したとしても、その後のＥＣＵの使用状態や環境（特に電磁環境）などによって、メモリ内のプログラムが異常状態になる可能性がある。
　そこで、一般的なＥＣＵのマイコンにおいては、起動直後（リプログラミングの正常完了を確認後）、及びＥＣＵソフト実行中に定期的に、ソフトウェアによるメモリチェック（例えばＲＯＭサムチェック）を行い、異常と判断したら自身にリセットをかけるように構成されている。つまり、リプログラミングの失敗への対応に加え、通常使用中に発生するプログラム異常にも適切に対応できるよう構成されている。
日本国特許掲載公報第４５７７０７５号
　しかし、本願発明者の検討によれば、上記のように定期的にメモリチェックを行うよう構成されたマイコンでは、一旦メモリのプログラムが異常になると、メモリチェックにより異常と判断されてリセットされ、リセット直後のメモリチェックでまた異常と判断されてまたリセットされるという、リセットの永続的繰り返しが発生する。
　このようにプログラム異常によりリセットが繰り返されると、その分、電力も無駄に消費されてしまうことになる。特に、近年のＥＣＵは、車両のエンジンが停止している間もマイコンは動作を継続（ただし一般的には間欠動作）して、車載バッテリの電力を消費し続けている。そのため、エンジン停止時にプログラム異常が発生すると、ＥＣＵソフトが正常に実行されないのはもちろん、それに加えて、リセットの繰り返しによってバッテリの電力は低下の一途を辿り、バッテリ上がりが発生するおそれがある。
　本開示は上記課題に鑑みなされたものであり、メモリチェックによりプログラム異常を判定したらＣＰＵ（マイコン）自らリセットするよう構成された車載電子制御装置において、プログラム異常が発生しても、電力の無駄な消費を抑えつつ適切な処理を行うことができる技術を提供することを目的とする。
　本開示の一例に係る車載電子制御装置は、メモリと、ＣＰＵと、異常回数記憶部と、異常回数更新部と、異常判定部と、異常対応部とを備える。
　メモリは、車両を制御するための制御プログラムを含む複数のプログラムが記憶された不揮発性のメモリである。ＣＰＵは、メモリに記憶された複数のプログラムを実行するものであって、メモリの記憶内容が正常であるか否かのメモリチェックを定期的に行い、メモリチェックによりメモリの記憶内容が異常と判断した場合は自身をリセットするよう構成されている。異常回数記憶部は、メモリチェックによってメモリの記憶内容が異常と判断された回数である異常回数が記憶される。異常回数更新部は、メモリチェックによりメモリの記憶内容が異常と判断される毎に、ＣＰＵのリセット前に、異常回数記憶部に記憶されている異常回数を更新する。異常判定部は、ＣＰＵのリセット後、最初のメモリチェックが行われる前に、異常回数記憶部に記憶されている異常回数が所定の異常判定閾値以上か否かを判定する。異常対応部は、異常判定部により異常回数が異常判定閾値以上と判定された場合に、複数のプログラムのうち特定のエラー対応処理プログラムをＣＰＵに実行させる。そしてＣＰＵは、エラー対応処理プログラムの実行中は、メモリチェック又はメモリチェックに基づくリセットは行わない。
　このように構成された車載電子制御装置によれば、メモリチェックでプログラム異常と判断される毎に、ＣＰＵのリセット前に異常回数を記憶（更新）し、リセット後にその異常回数が異常判定閾値以上だった場合は、エラー対応処理プログラムが実行される。エラー対応処理プログラムが実行される際は、メモリチェックによるリセットは行われない。そのため、メモリの記憶内容の異常が発生しても、電力の無駄な消費を抑えつつ適切な処理を行うことができる。
　上記車載電子制御装置において、異常回数記憶部、異常判定部及び異常対応部は、メモリ及びＣＰＵとは別のハードウェアで構成することができる。これら各部をメモリ及びＣＰＵとは別のハードウェアで構成することで、メモリチェックの異常回数の更新、及びその異常回数に基づくエラー対応処理プログラムの実行が、メモリの状態に依存せず高い信頼度で迅速に実現される。
　本開示についての上記および他の目的、特徴や利点は、添付の図面を参照した下記の詳細な説明から、より明確になる。添付図面において
図１は、実施形態の車両制御システムの概略構成を表すブロック図であり、 図２は、第１実施形態のフラッシュメモリのプログラム等配置を表す説明図であり、 図３は、第１実施形態のエラー判定モジュールの概略構成を表すブロック図であり、 図４は、第１実施形態のＣＰＵの動作を表すフローチャートであり、 図５は、第２実施形態のフラッシュメモリのプログラム等配置を表す説明図であり、 図６は、第２実施形態のエラー判定モジュールの概略構成を表すブロック図であり、 図７は、第２実施形態のＣＰＵの動作を表すフローチャートである。
　以下に、本開示の実施形態を図面に基づいて説明する。なお、本開示の実施形態は、下記の実施形態によって何ら限定して解釈されない。下記の実施形態の構成の一部を省略した態様も本開示の実施形態であり、下記の複数の実施形態を適宜組み合わせて構成される態様も本開示の実施形態に含まれる。
　（第１実施形態）
　（１）車両制御システム全体の概略構成
　図１に示す本実施形態の車両制御システム１０は、車両に搭載され、車両の各部を制御するためのシステムであり、複数のＥＣＵ１１，１２，１３・・・が車載ネットワーク（例えばＣＡＮ）２０を介して相互にデータ通信できるよう構成されている。各ＥＣＵ１１，１２，１３としては、例えばエンジンＥＣＵ、ボデーＥＣＵ、ナビゲーションＥＣＵなどの各種のＥＣＵが挙げられる。
　車載ネットワーク２０には、プログラム書換ツール１５を接続するためのコネクタ１４が接続されている。このコネクタ１４にプログラム書換ツール１５を接続することで、後述するようにプログラム書換ツール１５によるリプログラミングを行うことができる。
　各ＥＣＵ１１，１２，１３・・・はいずれも、マイコンを備え、マイコンが各種制御処理を実行することで車両の各部の制御が実現される。これらのうち特に、少なくとも１つのＥＣＵ１１は、エラー判定モジュール２６（詳細は後述）を備えた特徴的構成となっている。そこで、以下の説明では、このＥＣＵ１１についてその構成や機能等を詳しく説明する。
　ＥＣＵ１１は、ＣＰＵ２１、ＲＡＭ２２、フラッシュメモリ２３、通信インタフェース（通信Ｉ／Ｆ）２４、タイマ２５及びエラー判定モジュール２６などを備えている。なお、これらＣＰＵ２１、ＲＡＭ２２、フラッシュメモリ２３、通信Ｉ／Ｆ２４、タイマ２５及びエラー判定モジュール２６は、本実施形態では１チップマイコンとして１つの半導体集積回路内に集積された構成となっている。ただし、１チップマイコンとしての構成に限定されるものではない。
　ＣＰＵ２１は、フラッシュメモリ２３に記憶されている各種プログラムを実行することにより車両の各部の制御を実現する。ＣＰＵ２１は、図示しない各種レジスタやプログラムカウンタなどを備えた一般的な構成である。ただし、本実施形態のＣＰＵ２１は、リセット直後の起動開始時に、後述するようにエラー判定モジュール２６にエラー判定処理を実行させる。そして、エラー判定モジュール２６から指定されたフラッシュメモリ２３のアドレスにジャンプすることで、フラッシュメモリ２３の各種プログラムに基づく処理を開始する。
　フラッシュメモリ２３は、記憶内容を電気的に書き換え可能な不揮発性のメモリである。フラッシュメモリ２３には、図２に示すように各種プログラム等が記憶されている。具体的には、フラッシュメモリ２３には、リセットベクタ、起動判定処理プログラム、リプログラミングソフト、ＲＯＭサムチェック値、書換ステータス、ＯＳ（スケジューラ）、プログラムＡ、プログラムＢ、・・・プログラムｍ（フェールセーフ用ソフト）などが記憶されている。
　リセットベクタは、一般的なマイコンにおいてメモリにセットされる、ＣＰＵが実行開始するプログラムの先頭アドレスである。なお、リセットベクタのメモリアドレスは０ｘ００００である。
　起動判定処理プログラムは、前回実行されたリプログラミングが正常に完了したか否かを書換ステータスに基づいて判定し、正常に完了している場合は通常ＥＣＵソフトを起動させ、正常に完了していない場合はリプログラミングソフトを起動させるよう構成されたプログラムである。リセットベクタにはこの起動判定処理プログラムの先頭アドレスがセットされている。
　なお、通常ＥＣＵソフトとは、ＯＳや各プログラムＡ、Ｂ・・・など、実質的に車両の制御を担う各プログラム等の総称である。通常ＥＣＵソフトの実行に移ると、まずＯＳが処理を開始し、初期化処理やＲＯＭサムチェックを経た上で、マイコンに入力される各種入力情報等を監視しながら、各プログラムＡ，Ｂ・・・のスケジューリングを行う。
　リプログラミングソフトは、フラッシュメモリ２３の各プログラム等をリプログラミングするためのプログラムである。即ち、リプログラミングソフトが実行されると、リプログラミング対象のプログラムの更新バージョンプログラムを車載ネットワーク２０を介して取得し、フラッシュメモリ２３に書き込むことで、リプログラミングが行われる。更新バージョンプログラムは、例えば、コネクタ１４にプログラム書換ツール１５を接続してプログラム書換ツール１５から送信することができる。リプログラミングソフトのより具体的な機能等については、特許文献１に詳しく記載されている。なお、リプログラミングは、フラッシュメモリ２３全体を対象に一括して行うようにしてもよいし、プログラム単位或いはブロック単位で行うようにしてもよい。
　リプログラミングソフトは、リプログラミングを開始すると、書換ステータスを「書換中」にセット（実際には「書換中」を示す二値データをセット）する。そして、リプログラミングが正常に完了したら、書換ステータスを「書換完」にセットする。リプログラミング開始後、リプログラミングが正常に完了しない限り、書換ステータスは「書換中」のままとなる。
　ＲＯＭサムチェック値は、チェックサムによるメモリチェックを行う際のチェック用の符号（チェックコード）である。本実施形態のＲＯＭサムチェック値は、フラッシュメモリ２３の記憶内容全体を対象として設定される値である。ＲＯＭサムチェック値は、リプログラミングが行われる度に、リプログラミング後の記憶内容に対応した値に更新される。
　プログラムｍ（本開示のエラー対応処理プログラムの一例に相当）は、リセット直後のエラー判定モジュール２６によるエラー判定処理によってエラーが判定された場合に実行されるフェールセーフ用ソフトである。エラー判定モジュール２６によりエラーが判定されてフェールセーフ用ソフトが実行されると、通常ＥＣＵソフトは実行されず、フェールセーフ用ソフトに基づく各種のフェールセーフ処理が行われる。なお、フェールセーフ用ソフトのメモリアドレスは、０ｘＹＹＹＹである。
　（２）エラー判定モジュールの概略構成
　次に、ＣＰＵ２１のリセット直後にエラー判定処理を行うエラー判定モジュール２６の構成について、図３を用いて説明する。エラー判定モジュール２６は、ＣＰＵ２１やフラッシュメモリ２３とは別に独立して設けられたハードウェアにより構成されている。
　ＣＰＵ２１がリセットすると、リセット直後にまずプログラムカウンタにエラー判定モジュール２６のアドレス（０ｘＸＸＸＸ）がセットされる。これに基づき、ＣＰＵ２１は、まずエラー判定モジュール２６を動作させる。つまり、従来のＣＰＵは、リセット後はまずプログラムカウンタにリセットベクタのメモリアドレスがセットされてリセットベクタにジャンプする構成が一般的であるが、本実施形態のＣＰＵ２１は、リセット後にまずエラー判定モジュール２６のアドレスがプログラムカウンタにセットされてエラー判定モジュール２６に処理を移す。
　エラー判定モジュール２６は、エラー判定起動レジスタ３１と、エラー回数記憶レジスタ３２と、エラー判定閾値レジスタ３３と、比較器３４と、エラー判定時起動先レジスタ３５と、起動先判定器３６とを備える。
　エラー判定起動レジスタ３１は、ＣＰＵ２１のリセット直後にＣＰＵ２１により所定のエラー判定起動フラグがセットされるレジスタである。エラー判定起動レジスタ３１は、ＣＰＵ２１によりエラー判定起動フラグがセットされると、比較器３４を起動させる。例えば、エラー判定起動フラグのクリア中は「０」を出力して比較器３４を停止させておき、エラー判定起動フラグがセットされたら「１」を出力して比較器３４を起動させる。
　エラー回数記憶レジスタ３２は、ＣＰＵ２１が通常ＥＣＵソフトを起動した時に実行、及び通常ＥＣＵソフトの実行中に定期的に実行するＲＯＭサムチェックにおいて異常と判断される毎に、ＣＰＵ２１によりその異常と判断された回数であるエラー回数（本開示の異常回数の一例に相当）が累積記憶（更新）されるレジスタである。このエラー回数記憶レジスタ３２のエラー回数の初期値は０であり、ＲＯＭサムチェックにより異常と判断される毎にＣＰＵ２１によりエラー回数が１つずつインクリメントされていく。エラー回数記憶レジスタ３２は、異常回数記憶手段および異常回数記憶部の一例に相当できる。
　エラー判定閾値レジスタ３３は、エラー判定閾値（本開示の異常判定閾値の一例に相当）が記憶されるレジスタである。エラー判定閾値は、フラッシュメモリ２３にエラーが発生しているか否かをエラー回数記憶レジスタ３２に記憶されているエラー回数に基づいて判定するための判定基準値である。エラー判定閾値は適宜決めることができるが、２以上の値とすることが望ましい。本実施形態では、エラー判定閾値は例えば１０に設定されている。
　比較器３４は、エラー回数記憶レジスタ３２に記憶されているエラー回数とエラー判定閾値レジスタ３３に記憶されているエラー判定閾値とを比較し、その比較結果を示すエラー判定データを起動先判定器３６へ出力する。具体的には、エラー回数がエラー判定閾値未満の場合は、エラー判定データとしてエラー未発生を示す「０」を出力し、エラー回数がエラー判定閾値以上の場合は、エラー判定データとしてエラー発生を示す「１」を出力する。比較器３４は、異常判定手段および異常判定部の一例に相当できる。
　起動先判定器３６は、比較器３４からのエラー判定データに基づき、フラッシュメモリ２３におけるＣＰＵ２１の起動先アドレスを設定し、ＣＰＵ２１へ出力する。具体的には、エラー判定データが「０」（エラー未発生）の場合は、リセットベクタアドレス（０ｘ００００）を起動先に設定してその起動先アドレスをＣＰＵ２１へ出力する。詳しくは、ＣＰＵ２１内のプログラムカウンタにその起動先アドレス（０ｘ００００）をセットする。エラー判定データが「１」（エラー発生）の場合は、エラー判定時起動先レジスタ３５に予め記憶されているエラー判定時起動先アドレス（本例では、フェールセーフ用ソフトの先頭アドレスである０ｘＹＹＹＹ）を起動先に設定してその起動先アドレスをＣＰＵ２１へ出力する。詳しくは、ＣＰＵ２１内のプログラムカウンタにその起動先アドレス（０ｘＹＹＹＹ）をセットする。起動先判定器３６は、異常対応手段および異常対応部の一例に相当できる。
　このようにして起動先判定器３６により起動先アドレスが出力され、ＣＰＵ２１のプログラムカウンタにセットされると、ＣＰＵ２１は、そのプログラムカウンタにセットされたアドレス（リセットベクタ又はフェールセーフ用ソフト）にジャンプして処理を開始することとなる。なお、エラー回数記憶レジスタ３２、エラー判定閾値レジスタ３３及びエラー判定時起動先レジスタ３５は、ＣＰＵ２１内の図示しないレジスタと異なり、マイコンがリセットされても記憶内容は維持される。
　（３）ＣＰＵの動作
　次に、ＣＰＵ２１の動作の基本的流れを図４を用いて説明する。ＣＰＵ２１は、リセット後、既述のようにエラー判定モジュール２６を動作させて、エラー判定結果を待つ。即ち、比較器３４によりエラー回数記憶レジスタ３２のエラー回数がエラー判定閾値レジスタ３３のエラー判定閾値以上か否か判断する（Ｓ１１０）。
　エラー回数がエラー判定閾値未満の場合は、起動先判定器３６が、リセットベクタのアドレス（０ｘ００００）をＣＰＵ２１のプログラムカウンタにセットする（Ｓ１２０）。エラー回数がエラー判定閾値以上の場合は、起動先判定器３６が、エラー判定時起動先レジスタ３５に記憶されているエラー判定時起動先アドレス（本例では０ｘＹＹＹＹ）をＣＰＵ２１のプログラムカウンタにセットする（Ｓ１３０）。
　Ｓ１１０～Ｓ１３０は、ＣＰＵ２１が直接実行する処理ではなく、ＣＰＵ２１からの指令によって動作するエラー判定モジュール２６の処理であり、広義には、ＣＰＵ２１が間接的に実行する処理であると捉えることもできる。そのため、図４では、エラー判定モジュール２６の処理もＣＰＵ２１の処理に含めて図示している。
　Ｓ１２０でリセットベクタのアドレスがプログラムカウンタにセットされた場合は、ＣＰＵ２１は、Ｓ１４０でフラッシュメモリ２３のリセットベクタにジャンプする。Ｓ１３０でエラー判定時起動先アドレスがプログラムカウンタにセットされた場合は、ＣＰＵ２１は、Ｓ１５０でエラー判定時起動先アドレス（即ちフラッシュメモリ２３のアドレス０ｘＹＹＹＹのフェールセーフ用ソフト）にジャンプする。
　Ｓ１１０～Ｓ１５０の処理は、ＣＰＵ２１がフラッシュメモリ２３のプログラムに基づいて各種処理を行う前に、ＣＰＵ２１及びエラー判定モジュール２６によるハードウェア処理として実現される処理である。つまり、ＣＰＵ２１は、プログラムに基づくソフトウェア処理を行うのに先立って、ハードウェア処理によりエラー判定やジャンプ先アドレスの設定等を行う。そして、そのハードウェア処理により設定されたジャンプ先アドレスにジャンプした後は、Ｓ１６０以降又はＳ２８０のソフトウェア処理に移行する。
　Ｓ１６０では、リセットベクタに設定されているアドレスのプログラム、即ち起動判定処理を実行する。Ｓ１７０では、起動判定処理において書換ステータスが「書換完」であると判定されたか否か判断し、「書換完」と判定されなかった場合（即ち「書換中」のままの場合）はＳ２６０に進む。Ｓ２６０では、リプログラミングソフトを起動し、プログラム書換ツール１５の接続を待ち、接続されたら更新バージョンプログラムによる既存プログラムの書き換えを行う。
　Ｓ１７０で書換ステータスが「書換完」と判定された場合は、Ｓ１８０でＯＳによる初期化処理を開始することにより通常ＥＣＵソフトを起動し、Ｓ１９０で、ＯＳの機能としてのＲＯＭサムチェック（本開示のメモリチェックの一例に相当）を実行する。Ｓ２００では、Ｓ１９０のＲＯＭサムチェックの結果がＯＫ（正常）か否か判断し、ＯＫならばＳ２１０で通常ＥＣＵソフトをそのまま実行する。
　通常ＥＣＵソフトの実行中も、Ｓ２２０～Ｓ２４０に示すように定期的にＲＯＭサムチェックを行う。即ち、ＲＯＭサムチェックの実行タイミングが到来したら、Ｓ２２０でＲＯＭサムチェックを実行し、Ｓ２３０で、Ｓ２２０のＲＯＭサムチェックの結果がＯＫか否か判断する。Ｓ２３０でＯＫと判断した場合は、Ｓ２４０で引き続き通常ＥＣＵソフトを実行（継続）し、再びＲＯＭサムチェックの実行タイミングが到来したらＳ２２０に戻ってＲＯＭサムチェックを実行する。
　Ｓ２００又はＳ２３０で、ＲＯＭサムチェックの結果が異常と判断した場合は、Ｓ２５０で、エラー判定モジュール２６内のエラー回数記憶レジスタ３２にエラー回数を書き込む。即ち、現在記憶されているエラー回数を更新（１つインクリメント）する。エラー回数の書き込み後は、ＣＰＵ２１自ら、ＣＰＵ２１をリセット（即ちマイコンをリセット）する。Ｓ２５０を実行するＣＰＵ２１は、異常回数更新部および異常回数更新手段の一例に相当できる。
　起動先としてエラー判定時起動先アドレスが設定された場合は（Ｓ１５０）、Ｓ２８０で、フェールセーフ処理を行う。即ち、エラー判定時起動先アドレスである０ｘＹＹＹＹに記憶されているフェールセーフ用ソフトを実行する。
　（４）第１実施形態の効果等
　以上説明した本実施形態のＥＣＵ１１によれば、ＲＯＭサムチェックで異常と判断される毎に、ＣＰＵ２１のリセット前にエラー回数を更新し（Ｓ２５０）、リセット後にそのエラー回数がエラー判定閾値以上だった場合は、フェールセーフ処理ソフトが実行される（Ｓ２８０）。フェールセーフ処理ソフトは、リセットベクタへのジャンプに始まる通常の処理の流れとは独立して実行され、フェールセーフ処理ソフトの実行中はＲＯＭサムチェックは行われない。つまり、ＲＯＭサムチェックの異常によるマイコンリセットが繰り返し永続的に行われることはない。そのため、フラッシュメモリ２３の記憶内容に異常が発生しても、電力の無駄な消費を抑えつつ適切な処理（本実施形態ではフェールセーフ処理）を行うことができる。
　なお、エラー判定時にフェールセーフ処理ソフトを実行するのはあくまでも一例であり、エラー判定時に具体的にどのような処理を実行するかについては適宜決めることができる。例えば、リプログラミングソフトを起動してリプログラミング待ちに遷移してもよい。また例えば、所定のフェールセーフ処理の実行に加えてユーザ（車両の運転者等）に対して何らかの方法で故障発生を通知するようにしてもよい。
　また、本実施形態では、ＲＯＭサムチェックで異常と判断されても、１回の異常判断だけですぐにフェールセーフ処理に移行せず、異常と判断された回数（エラー回数）がエラー判定閾値以上となった場合にフェールセーフ処理に移行するようにしている。そのため、エラー判定の精度を高めることができる。しかも、エラー回数の記憶・更新は、ＲＡＭ２２でもフラッシュメモリ２３でもなく、これらとは別に設けたエラー回数記憶レジスタ３２を用いて行うようにしている。そのため、ＲＡＭ２２やフラッシュメモリ２３の状態にかかわらずエラー回数を確実に記憶させておくことができ、これによりエラー判定の精度をより一層高めることができる。
　また、本実施形態では、ＣＰＵ２１のリセット直後のエラー判定を、ソフトウェア処理ではなく、エラー判定モジュール２６によるハードウェア処理により実現している。そのため、エラー判定を迅速且つ高い信頼度で行うことができる。また、仮にエラー判定をソフトウェア処理で実現しようとすると、その分、フラッシュメモリ２３の記憶領域が必要となってコスト高を招くおそれがあるが、本実施形態のようにハードウェア処理で実現することで、そういった課題を抑制することができる。
　（第２実施形態）
　第２実施形態のＥＣＵについて、図１に示した第１実施形態のＥＣＵ１１と異なる部分に絞って説明する。本実施形態のＥＣＵ（図示略）が第１実施形態のＥＣＵ１１と異なる主な部分は、フラッシュメモリの記憶内容とエラー判定モジュールの構成である。
　本実施形態のフラッシュメモリにおいては、図５に示すように、記憶領域が複数のブロックに分割され、ブロックごとにＲＯＭサムチェック用のチェックコード（即ちＲＯＭサムチェック値）が設定されている。なお、フラッシュメモリ２３を具体的にどのようにブロック分けするかについては適宜決めることができる。
　本実施形態のエラー判定モジュール４０は、図６に示す通りであり、図３に示した第１実施形態のエラー判定モジュール２６と比較して明らかなように、エラー回数記憶レジスタ３２とエラー判定閾値レジスタ３３の構成が異なっている。また、本実施形態では比較器３４と起動先判定器３６との間に新たにエラー発生ブロックレジスタ４１が設けられている　。
　本実施形態のエラー回数記憶レジスタ３２は、フラッシュメモリのブロック毎に個別に設けられている。即ち、ブロック０対応のエラー回数記憶レジスタ３２Ａ、ブロック１対応のエラー回数記憶レジスタ３２Ｂ、ブロック２対応のエラー回数記憶レジスタ３２Ｃ、・・・というように、ブロック毎の複数のエラー回数記憶レジスタが設けられている。
　これと全く同じように、エラー判定閾値レジスタ３３についても、フラッシュメモリのブロック毎に個別に設けられている。即ち、ブロック０対応のエラー判定閾値レジスタ３３Ａ、ブロック１対応のエラー判定閾値レジスタ３３Ｂ、ブロック２対応のエラー判定閾値レジスタ３３Ｃ、・・・というように、ブロック毎の複数のエラー判定閾値レジスタが設けられている。
　比較器３４による、エラー回数とエラー判定閾値との比較も、ブロック毎に個別に行われる。例えば、ブロック０についてはブロック０対応のエラー回数記憶レジスタ３２Ａに記憶されているエラー回数とブロック０対応のエラー判定閾値レジスタ３３Ａに記憶されているエラー判定閾値とを比較する。
　比較器３４は、各ブロック０～ｎについてそれぞれ個別に上記比較を行い、エラーが発生しているブロック（即ちエラー回数がエラー判定閾値以上のブロック）があった場合は、エラー発生ブロックレジスタ４１における当該エラー発生ブロックのフラグをセットする。
　エラー発生ブロックレジスタ４１は、エラーが発生しているか否かを示すフラグがブロック毎に設定されるものである。あるブロックについて比較器３４によりエラーが発生していると判断されると、エラー発生ブロックレジスタ４１における該当ブロックのフラグが比較器３４によりセットされる。つまり、エラー発生ブロックレジスタ４１を参照すればどのブロックが正常でどのブロックがエラー発生しているかを知ることができる。
　エラー発生ブロックレジスタ４１は、何れのブロックも正常である間は、エラー判定データとしてエラー未発生を示す「０」を起動先判定器３６へ出力するが、何れか１つのブロックのフラグがセットされると（つまり各ブロックのうち何れか１つでもエラーと判定されると）、エラー判定データとしてエラー発生を示す「１」を起動先判定器３６へ出力する。
　このように構成された本実施形態のＥＣＵにおけるＣＰＵの動作について、図７を用いて概略説明する。本実施形態のＣＰＵは、リセット後、エラー判定モジュール４０を動作させて、エラー判定結果を待つ。即ち、比較器３４によりブロック毎にエラー回数とエラー判定閾値の比較が行われる（Ｓ３１０）。その比較の結果、エラー回数がエラー判定閾値以上のブロックがない場合はＳ３２０に進み、何れか１つでもエラー回数がエラー判定閾値以上のブロックがあれば、Ｓ３２５に進む。
　Ｓ３２５では、エラー発生ブロックレジスタ４１に対してエラー発生ブロックを示すフラグをセットする。Ｓ３３０，Ｓ３５０の処理はそれぞれ図４のＳ１３０，Ｓ１５０の処理と同じである。Ｓ４８０のフェールセーフ処理は、図４のＳ２８０のフェールセーフ処理と若干異なる。即ち、本実施形態のフェールセーフ処理（Ｓ４８０）では、適宜、１又は複数の他のブロックのプログラムにアクセス（参照）して実行する。ただし、エラー発生ブロックレジスタ４１の設定値を読み出して、エラー発生ブロックについてはそのブロック内のプログラムにはアクセスしない。
　Ｓ３２０～Ｓ３８０，Ｓ４００，Ｓ４１０，Ｓ４３０，Ｓ４４０，Ｓ４６０の各処理はそれぞれ図４のＳ１２０～Ｓ１８０，Ｓ２００，Ｓ２１０，Ｓ２３０，Ｓ２４０，Ｓ２６０の各処理と同じである。
　Ｓ３９０及びＳ４２０のＲＯＭサムチェックは、ブロック毎に個別に実行する点で、第１実施形態と異なる。Ｓ４５０のエラー回数記憶レジスタ３２へのエラー回数書き込み（インクリメント）についても、ブロック毎に、ＲＯＭサムチェックで異常と判断されたブロックに対応したエラー回数をインクリメントする点で、第１実施形態と異なる。Ｓ４５０を実行するＣＰＵ２１が、異常回数更新手段および異常回数更新手段の一例に相当できる。
　上記のように構成された本実施形態のＥＣＵによれば、ブロック毎にエラー判定が行われ、何れか１つでもエラー判定されたブロックがあればフェールセーフ処理に移行するため、エラー判定の精度をより高めることができ、エラー発生に対して適切な対応（フェールセーフ処理）をより迅速にとることができる。また、エラーが発生しているブロックとエラーが発生していないブロックを区別することができるため、フェールセーフ処理においてアクセスできないブロックを必要最小限に抑えることができ、フェールセーフ処理の機能低下を抑えることができる。
　（変形例）
　以上、本開示の実施の形態について説明したが、本開示の実施の形態は、上記実施形態に何ら限定されるものではなく、種々の形態を採り得ることはいうまでもない。
　例えば、上記実施形態では、リセット直後のエラー判定を、エラー判定モジュール（図３，図６参照）によるハードウェア処理で実現するようにしたが、エラー判定モジュールの機能をソフトウェア処理で実現するようにしてもよい。ただし、処理速度やコストを考慮すると、上記実施形態のようにハードウェア処理で実現する構成が好ましい。
　また、上記実施形態では、フラッシュメモリ２３の記憶内容のチェック方法として、ＲＯＭサムチェックを用いたが、これはあくまでも一例であり、他の各種の方法（例えばＣＲＣ）を用いてメモリチェックを行うようにしてもよい。
　また、上記第２実施形態では、比較器３４において、全てのブロックについてそれぞれエラー回数とエラー判定閾値との比較を行うようにしたが、何れか１つ又は所定数（複数）（本開示のエラー対応基準ブロック数の一例に相当）のブロックについてエラー判定（エラー回数≧エラー判定閾値）されたら、その時点で比較をやめて、それらエラー判定ブロックについてエラー発生ブロックレジスタ４１のフラグをセットするようにしてもよい。
　Ｓ３９０やＳ４２０のＲＯＭサムチェックについても、全てのブロックについてＲＯＭサムチェックを行ってからＳ４５０に進むのではなく、ブロックごとに順次ＲＯＭサムチェックを行っていく過程の中で何れか１つ又は所定数（複数）（本開示のリセット基準ブロック数の一例に相当）のブロックについてＲＯＭサムチェックで異常が判断されたら、その時点でＲＯＭサムチェックをやめてＳ４５０に進むようにしてもよい。
　以上、本開示に係る実施の形態および構成を例示したが、本開示に係る実施の形態および構成は、上述した各実施の形態および各構成に限定されるものではない。異なる実施の形態および構成にそれぞれ開示された技術的要素を適宜組み合わせて得られる実施の形態および構成についても本開示に係る実施の形態および構成の範囲に含まれる。

Claims (5)

  1. 　車両を制御するための制御プログラムを含む複数のプログラムが記憶された不揮発性のメモリ（２３）と、
    　前記複数のプログラムを実行するＣＰＵであって、前記メモリ（２３）の記憶内容が正常であるか否かのメモリチェックを定期的に行い、前記メモリチェックにより前記メモリ（２３）の記憶内容が異常と判断した場合は自身をリセットするよう構成されたＣＰＵ（２１）と、
    　前記メモリチェックによって前記メモリ（２３）の記憶内容が異常と判断された回数である異常回数が記憶される異常回数記憶部（３２）と、
    　前記メモリチェックにより前記メモリ（２３）の記憶内容が異常と判断される毎に、前記ＣＰＵ（２１）のリセット前に、前記異常回数記憶部（３２）に記憶されている前記異常回数を更新する異常回数更新部（２１、Ｓ２５０、Ｓ４５０）と、
    　前記ＣＰＵ（２１）のリセット後、最初の前記メモリチェックが行われる前に、前記異常回数記憶部（３２）に記憶されている前記異常回数が所定の異常判定閾値以上か否かを判定する異常判定部（３４）と、
    　前記異常判定部（３４）により前記異常回数が前記異常判定閾値以上と判定された場合に、前記複数のプログラムのうち特定のエラー対応処理プログラムを前記ＣＰＵ（２１）に実行させる異常対応部（３６）と、
    　を備え、
    　前記ＣＰＵ（２１）は、前記エラー対応処理プログラムの実行中は、前記メモリチェック又は前記メモリチェックに基づく前記リセットは行わない
    　車載電子制御装置。
  2. 　請求項１に記載の車載電子制御装置であって、
    　前記異常回数記憶部（３２）、前記異常判定部（３４）及び前記異常対応部（３６）は、前記メモリ（２３）及び前記ＣＰＵ（２１）とは別のハードウェアで構成されている
    　車載電子制御装置。
  3. 　請求項２に記載の車載電子制御装置であって、
    　前記異常対応部（３６）は、前記ＣＰＵ（２１）が有するプログラムカウンタに前記メモリ（２３）における前記エラー対応処理プログラムのアドレスを格納することによって、前記エラー対応処理プログラムを前記ＣＰＵ（２１）に実行させる
    　車載電子制御装置。
  4. 　請求項１～請求項３の何れか１項に記載の車載電子制御装置であって、
    　前記ＣＰＵ（２１）は、前記メモリチェックを所定のブロック単位で実行し、１又は複数の所定のリセット基準ブロック数以上の前記ブロックについて記憶内容が正常ではないと判断した場合にリセットするよう構成されており、
    　前記異常回数記憶部（３２）は、前記ブロック毎に前記異常回数が記憶され、
    　前記異常回数更新部（２１、Ｓ２５０、Ｓ４５０）は、前記ブロック毎に前記異常回数を更新し、
    　前記異常判定部（３４）は、前記ブロック毎に前記異常回数が前記異常判定閾値以上か否かを判定し、
    　前記異常対応部（３６）は、前記異常判定部（３４）により１又は複数の所定のエラー対応基準ブロック数以上の前記ブロックについて前記異常回数が前記異常判定閾値以上と判定された場合に、前記エラー対応処理プログラムをＣＰＵ（２１）に実行させる
    　車載電子制御装置。
  5. 　請求項４に記載の車載電子制御装置であって、
    　前記エラー対応処理プログラムは、当該エラー対応処理プログラムが記憶されている前記ブロック以外の他の少なくとも１つの前記ブロックを参照するよう構成されていると共に、その参照先の前記ブロックが前記異常判定部（３４）により前記異常回数が前記異常判定閾値以上と判定されたブロックである場合はそのブロックは参照しないよう構成されている
    　車載電子制御装置。
PCT/JP2013/006515 2012-12-12 2013-11-05 車載電子制御装置 WO2014091666A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US14/651,195 US9778970B2 (en) 2012-12-12 2013-11-05 Memory check, abnormality threshold count, and reset in an onboard electronic control unit
DE112013005928.2T DE112013005928T5 (de) 2012-12-12 2013-11-05 Bordeigene elektronische Steuerungseinheit

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2012-271464 2012-12-12
JP2012271464A JP6044316B2 (ja) 2012-12-12 2012-12-12 車載電子制御装置

Publications (1)

Publication Number Publication Date
WO2014091666A1 true WO2014091666A1 (ja) 2014-06-19

Family

ID=50933975

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2013/006515 WO2014091666A1 (ja) 2012-12-12 2013-11-05 車載電子制御装置

Country Status (4)

Country Link
US (1) US9778970B2 (ja)
JP (1) JP6044316B2 (ja)
DE (1) DE112013005928T5 (ja)
WO (1) WO2014091666A1 (ja)

Families Citing this family (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5880687B2 (ja) * 2012-03-27 2016-03-09 富士通株式会社 データ処理装置およびデータ処理方法
US10235232B2 (en) 2014-02-10 2019-03-19 Via Alliance Semiconductor Co., Ltd Processor with approximate computing execution unit that includes an approximation control register having an approximation mode flag, an approximation amount, and an error threshold, where the approximation control register is writable by an instruction set instruction
US9588845B2 (en) * 2014-02-10 2017-03-07 Via Alliance Semiconductor Co., Ltd. Processor that recovers from excessive approximate computing error
US9384081B2 (en) * 2014-07-01 2016-07-05 Gogo Llc Delayed disk recovery
JP6295928B2 (ja) * 2014-11-21 2018-03-20 株式会社デンソー 制御装置
DE102015204337A1 (de) * 2015-03-11 2016-09-15 Siemens Aktiengesellschaft Sicherheitsrelevantes Computersystem
CN106469108A (zh) * 2016-09-30 2017-03-01 惠州市德赛西威汽车电子股份有限公司 一种车载系统异常处理装置及方法
JP7169340B2 (ja) 2017-07-25 2022-11-10 オーロラ ラブズ リミテッド 車両ｅｃｕソフトウェアのためのソフトウェアデルタ更新の構築およびツールチェーンに基づく異常検出
CN108279916B (zh) * 2017-12-28 2021-12-07 宁德时代新能源科技股份有限公司 电子控制单元程序更新方法和装置
JP2020003516A (ja) 2018-06-25 2020-01-09 セイコーエプソン株式会社 表示ドライバー、電子機器及び移動体
JP2020029243A (ja) * 2018-08-24 2020-02-27 クラリオン株式会社 通信端末、通信端末の異常確認方法、通信端末用プログラム
JP7115330B2 (ja) * 2019-01-16 2022-08-09 トヨタ自動車株式会社 車載システム、無線通信装置、及び制御方法
EP3941078A4 (en) 2019-03-13 2022-12-07 Hisense Visual Technology Co., Ltd. RESET DEVICE AND INDICATOR
JP7143797B2 (ja) * 2019-03-20 2022-09-29 株式会社デンソー 車載カメラモジュールの電源制御装置
JP7243459B2 (ja) * 2019-05-31 2023-03-22 株式会社デンソー 車両用装置
US11345358B2 (en) 2020-02-17 2022-05-31 Honda Motor Co., Ltd. Engine electronic control unit for a vehicle
WO2021261113A1 (ja) * 2020-06-25 2021-12-30 住友電気工業株式会社 車両監視プログラム、車載装置、および車両監視方法
KR20220028692A (ko) 2020-08-31 2022-03-08 주식회사 엘엑스세미콘 플래시 메모리의 리셋 기능을 갖는 모바일 폰 및 그의 플래시 메모리 제어 장치
JP7472817B2 (ja) 2021-02-12 2024-04-23 株式会社デンソー データ処理システム
CN117149478B (zh) * 2023-06-14 2024-06-04 杭州迪为科技有限公司 汽车电子控制器的复位管理方法、装置和汽车电子控制器

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0596976A (ja) * 1991-10-07 1993-04-20 Nissan Motor Co Ltd 自動車用マイクロコンピユータのデータプロテクト装置
JPH1139231A (ja) * 1997-07-17 1999-02-12 Unisia Jecs Corp 車両用電子制御装置
WO2009078145A1 (ja) * 2007-12-14 2009-06-25 Kabushiki Kaisha Toshiba 制御装置
JP2011081617A (ja) * 2009-10-07 2011-04-21 Toshiba Tec Corp 情報処理端末および起動プログラム

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6505305B1 (en) * 1998-07-16 2003-01-07 Compaq Information Technologies Group, L.P. Fail-over of multiple memory blocks in multiple memory modules in computer system
EP1736995A1 (en) * 1999-11-15 2006-12-27 Autonetworks Technologies, Ltd. Check method of temporary storage circuit in electronic control unit
US6775609B2 (en) * 2001-09-27 2004-08-10 Denso Corporation Electronic control unit for vehicle having operation monitoring function and fail-safe function
EP1607865B1 (en) * 2004-06-14 2013-08-14 Micron Technology, Inc. Data control unit capable of correcting boot errors, and corresponding method
JP3969494B2 (ja) * 2004-08-31 2007-09-05 三菱電機株式会社 車載電子制御装置
US8661289B2 (en) * 2005-02-18 2014-02-25 Hewlett-Packard Development Company, L.P. Systems and methods for CPU repair
US7523346B2 (en) * 2005-02-18 2009-04-21 Hewlett-Packard Development Company, L.P. Systems and methods for CPU repair
JP4066381B2 (ja) * 2005-03-01 2008-03-26 三菱電機株式会社 車載電子制御装置
CN100507866C (zh) * 2005-03-18 2009-07-01 富士通株式会社 使用服务处理器的cpu退缩系统和cpu退缩方法
US7350007B2 (en) * 2005-04-05 2008-03-25 Hewlett-Packard Development Company, L.P. Time-interval-based system and method to determine if a device error rate equals or exceeds a threshold error rate
JP4577075B2 (ja) 2005-04-22 2010-11-10 株式会社デンソー 自動車用制御ユニット
US20060259207A1 (en) 2005-04-20 2006-11-16 Denso Corporation Electronic control system for automobile
JP4736828B2 (ja) * 2006-02-03 2011-07-27 株式会社デンソー 電子制御装置
JP4630327B2 (ja) * 2007-05-03 2011-02-09 日本ビクター株式会社 ナビゲーション装置
JP4363471B2 (ja) * 2007-08-03 2009-11-11 株式会社デンソー 故障コード記憶管理装置、及び記憶管理装置
JP4489127B2 (ja) * 2008-02-29 2010-06-23 株式会社東芝 半導体記憶装置
TW201118554A (en) * 2009-11-18 2011-06-01 Inventec Corp Computer and system for detecting memory error signal
US8509989B2 (en) * 2009-12-18 2013-08-13 Conti Temic Microeletronic GMBH Monitoring concept in a control device

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0596976A (ja) * 1991-10-07 1993-04-20 Nissan Motor Co Ltd 自動車用マイクロコンピユータのデータプロテクト装置
JPH1139231A (ja) * 1997-07-17 1999-02-12 Unisia Jecs Corp 車両用電子制御装置
WO2009078145A1 (ja) * 2007-12-14 2009-06-25 Kabushiki Kaisha Toshiba 制御装置
JP2011081617A (ja) * 2009-10-07 2011-04-21 Toshiba Tec Corp 情報処理端末および起動プログラム

Also Published As

Publication number Publication date
US20150317198A1 (en) 2015-11-05
JP6044316B2 (ja) 2016-12-14
JP2014115950A (ja) 2014-06-26
US9778970B2 (en) 2017-10-03
DE112013005928T5 (de) 2015-09-10

Similar Documents

Publication Publication Date Title
WO2014091666A1 (ja) 車載電子制御装置
US20140136826A1 (en) Method and apparatus for updating boot loader
JP4227149B2 (ja) 電子制御装置の情報記憶方法
JP2014035730A (ja) 車両用制御装置
JP6011162B2 (ja) 電子制御装置
JP4552982B2 (ja) 電子制御装置
US20180329774A1 (en) Processing System, Related Integrated Circuit, Device and Method
US10108469B2 (en) Microcomputer and microcomputer system
JP4001088B2 (ja) 電子制御装置
US20160162358A1 (en) Microcontroller
US7386714B2 (en) Transmitting data from a single storage unit between multiple processors during booting
JP2002323902A (ja) 電子制御装置
JP2007316800A (ja) 車載プログラム書換え制御装置
JP4955417B2 (ja) 電子制御ユニットのメモリチェックシステム
WO2019064644A1 (ja) 電子制御装置及び制御プログラム検証方法
US7475212B2 (en) Method for reallocation of a memory of a subsystem, and subsystem
JP2002236503A (ja) 車両用電子制御装置
JP6946954B2 (ja) 監視システム
JP2009223435A (ja) データ記憶方法及び装置、並びにプログラム
JP6624005B2 (ja) 相互監視システム
JP2020035503A (ja) 自動車用電子制御装置
JP6887277B2 (ja) 自動車用電子制御装置
JP5029123B2 (ja) 電子制御装置及び通信システム
US20220342653A1 (en) Ota master, center, system, update method, non-transitory storage medium, and vehicle
JP2008071084A (ja) マイクロプロセッサ及び画像形成装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 13862308

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 14651195

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 112013005928

Country of ref document: DE

Ref document number: 1120130059282

Country of ref document: DE

122 Ep: pct application non-entry in european phase

Ref document number: 13862308

Country of ref document: EP

Kind code of ref document: A1