Patent Description:
A constitution in which a microcomputer and a logic circuit are combined has been known. Since the microcomputer and the logic circuit have different times required from the turning-on of the power supply to the completion of initialization, for example, measures as disclosed in Patent Literature <NUM> are implemented.

Patent Literature <NUM> discloses an electronic apparatus having a functioning unit performing configuration that writes circuit data after a power supply is turned on for start-up and serving a circuit function according to the circuit data after the completion of the configuration, a first microcomputer started up substantially simultaneously with the functioning unit, performing initialization that reads an initial program after the start-up, and starting communication with the functioning unit after the completion of the initialization, and a configuration monitoring unit resetting the first microcomputer after the start-up of the first microcomputer, and after the completion of the configuration by the functioning unit, releasing the reset to allow the first microcomputer to start the initialization. Furthermore, Patent Literature <NUM> discloses a network for a fleet of vehicles, wherein a first vehicle in the first group is assigned as a supervisor of a second vehicle in the second group.

In the invention described in Patent Literature <NUM>, the operation of the microcomputer cannot be decided on the basis of the state of the logic circuit.

In order to solve the above-mentioned prolem, an on-vehicle gateway device having the features of independent claim <NUM> is provided, wherein a microcomputer connected to a logic circuit. The microcomputer includes a monitoring unit monitoring the state of the logic circuit, a storage unit storing a plurality of information processing items executed by the microcomputer, and a processing unit executing a process on the basis of the state of the logic circuit and at least one information processing item selected from the plurality of information processing items on the basis of a communication frame inputted to the microcomputer. Preferable embodiments are claimed by the dependent claims.

According to the present invention, the process of the microcomputer can be decided on the basis of the state of the logic circuit.

A first embodiment of an on-vehicle system will be described below with reference to <FIG>.

<FIG> is a diagram illustrating the overview of an on-vehicle system <NUM>. The on-vehicle system <NUM> includes an on-vehicle gateway device <NUM>, an engine control unit <NUM>, a brake control unit <NUM>, a power steering control unit <NUM>, an autonomous travel control unit <NUM>, a camera <NUM>, a radar <NUM>, and an own-vehicle position sensor <NUM>. The engine control unit <NUM>, the brake control unit <NUM>, the power steering control unit <NUM>, and the autonomous travel control unit <NUM> are connected to the on-vehicle gateway device <NUM> by CAN (Controller Area Network). The camera <NUM>, the radar <NUM>, and the own-vehicle position sensor <NUM> are connected to the on-vehicle gateway device <NUM> by IEEE802. <NUM>, that is, Ethernet (registered trademark).

The engine control unit <NUM> is a controller that controls an engine that generates the driving force of a vehicle. The brake control unit <NUM> is a controller that performs the brake control (braking force control) of the vehicle. The power steering control unit <NUM> is a controller that controls the power steering of the vehicle. The camera <NUM>, the radar <NUM>, and the own-vehicle position sensor <NUM> are outside recognition sensors for recognizing the outside state of the vehicle.

The on-vehicle gateway device <NUM> accommodates the CAN having a plurality of channels and the Ethernet having a plurality of ports, and performs, in addition to the CAN communication relay between the different channels and the Ethernet communication relay between the different ports, the communication relay from the CAN to the Ethernet and the communication relay from the Ethernet to the CAN. During the communication relay from the CAN to the Ethernet, the CAN frame is encapsulated by the Ethernet frame, and is relayed. During the communication relay from the Ethernet to the CAN, the CAN frame encapsulated by the Ethernet frame is taken out by decapsulation, and is relayed. For example, the sensor information from the camera <NUM>, the radar <NUM>, and the own-vehicle position sensor <NUM> is relayed to the autonomous travel control unit <NUM> by the on-vehicle gateway device <NUM>. Also, the steering information from the power steering control unit <NUM> is relayed to the own-vehicle position sensor <NUM> by the on-vehicle gateway device <NUM>.

<FIG> is a block diagram of the on-vehicle gateway device <NUM>. The on-vehicle gateway device <NUM> includes a microcomputer (hereinafter, called a "microcomputer") <NUM>, a first CAN IF 202A, a second CAN IF 202B, an FPGA (Field-Programmable Gate Array) <NUM>, a first Ethernet IF 251A, and a second Ethernet IF 251B. The microcomputer <NUM> is connected to the first CAN IF 202A and the second CAN IF 202B. The FPGA <NUM> is connected to the first Ethernet IF 251A and the second Ethernet IF 251B. In this embodiment, the microcomputer <NUM> and the FPGA <NUM> are independent members, each of the microcomputer <NUM> and the FPGA <NUM> is accommodated in a different package, and each of the microcomputer <NUM> and the FPGA <NUM> can be independently distributed. To function as the on-vehicle gateway device <NUM>, the microcomputer <NUM> and the FPGA <NUM> are physically connected by a wire, a pin and socket, a cable, and the like.

The microcomputer <NUM> includes a CPU, a ROM, and a RAM. In the RAM, a storage area for standby that temporarily stores the received communication frame is secured. The CPU of the microcomputer <NUM> to which a power supply voltage is applied copies the program stored in the ROM to the RAM to execute the program. Hereinafter, developing the program stored in the ROM to the RAM by the CPU of the microcomputer <NUM> to execute the program is called "the initialization of the microcomputer <NUM>". That is, when the initialization is completed, the microcomputer <NUM> can exhibit the function achieved by the program. The microcomputer <NUM> also includes a nonvolatile memory, and records the log into the nonvolatile memory, as described later.

The FPGA <NUM> is a programmable logic circuit that includes a volatile SRAM. The electric power is supplied, then, the FPGA <NUM> reads the program file into the SRAM to constitute the logic circuit. Hereinafter, reading the program file by the FPGA <NUM> to constitute the logic circuit is called "the configuration of the FPGA <NUM>" or "the initialization of the FPGA <NUM>". Also, hereinafter, the "configuration" is sometimes called "config". The FPGA <NUM> cannot exhibit the later-described function until the configuration is completed.

The time required for the configuration of the FPGA <NUM> is longer than the time required for the initialization of the microcomputer <NUM>. When applied to the on-vehicle gateway device <NUM>, the power supply voltage is applied to both of the microcomputer <NUM> and the FPGA <NUM> substantially simultaneously, so that the configuration of the FPGA <NUM> is completed after the initialization of the microcomputer <NUM> is completed. Therefore, the microcomputer <NUM> starts to operate earlier than the FPGA <NUM>.

The microcomputer <NUM> and the FPGA <NUM> are connected by a monitoring bus <NUM> and a data bus <NUM>. The monitoring bus <NUM> and the data bus <NUM> are, for example, wires and contacts. It should be noted that each of the number of the CAN IFs and the number of the Ethernet IFs is not limited to two, and each of the number of the CAN IFs and the number of the Ethernet IFs is at least one. Also, the communication standards may be other standards, such as FlexRay (registered trademark) and LIN (registered trademark). Further, any apparatuses may be connected to each network, and at least one apparatus is connected to each network. The communication between the CAN and the Ethernet is relayed between the microcomputer <NUM> and the FPGA <NUM> via the data bus <NUM>, and is transmitted from the destination network interface.

The microcomputer <NUM> includes, as its functions, a monitoring process <NUM> and a communication process <NUM>, the communication process <NUM> including a flow table <NUM>. The monitoring process <NUM> monitors the state of the FPGA <NUM>, that is, the configuration state, the failure state, and the like, through the monitoring bus <NUM>, and determines in what state the FPGA <NUM> is. For example, the monitoring process <NUM> monitors, via the monitoring bus <NUM>, the state of the pin that is included in the FPGA <NUM> and represents the completion of the configuration, and determines, when the voltage level of the pin exceeds a predetermined threshold value, that the configuration has been completed.

The communication process <NUM> processes the communication frame inputted from each of the first CAN IF 202A and the second CAN IF 202B to the microcomputer <NUM> on the basis of the flow table <NUM>. The constitution of the flow table <NUM> will be described later. Also, the communication process <NUM> transfers the CAN frame outputted from the FPGA <NUM> to each of the first CAN IF 202A and the second CAN IF 202B. The process executed by the communication process <NUM> includes large-load processes, such as a filtering process that discards a frame having a particular pattern, an encoding process, and a decoding process. Some of these large-load processes are sometimes executed by the FPGA <NUM>, as described later. In this embodiment, allowing the FPGA <NUM> to execute the process originally executed by the microcomputer <NUM> is called "offload".

The FPGA <NUM> includes a communication circuit <NUM>, the communication circuit <NUM> including a forwarding database (hereinafter, called an "FDB") <NUM>, and a conversion DB <NUM>. The constitutions of the FDB <NUM> and the conversion DB <NUM> will be described later. The communication circuit <NUM> executes the switching process of the Ethernet, the CAN-Ethernet conversion process that is the relay of the CAN and the Ethernet, and further, the offload that executes some processes of the communication process <NUM>. The communication frame inputted from each of the first Ethernet IF 251A and the second Ethernet IF 251B to the FPGA <NUM> is processed on the basis of the FDB <NUM> by the communication circuit <NUM>.

During the CAN-Ethernet conversion process that encapsulates the CAN frame by the Ethernet frame, the communication circuit <NUM> refers to the conversion DB <NUM> to generate the header of the Ethernet frame. That is, an MAC address is designated on the basis of the CAN ID of the CAN frame, and the header of the Ethernet frame in which the designated MAC address is stored is then generated. It should be noted that although the CAN-Ethernet conversion process may be executed by the microcomputer <NUM>, the CAN-Ethernet conversion process that is executed by the FPGA <NUM> can be performed for a shorter time.

The FPGA <NUM> further includes a failure detection circuit, not illustrated, detecting the failure of the FPGA <NUM> itself. When detecting a failure, the failure detection circuit transmits the occurrence of the failure to the microcomputer <NUM> via the monitoring bus <NUM>. It should be noted that examples of the cause of the failure occurring in the FPGA <NUM> include a soft error caused by radiation, operation failure due to the lowering of the power supply, damage due to latch-up, and the like.

<FIG> is a diagram illustrating an example of the flow table <NUM>. The flow table <NUM> includes a plurality of records having three fields. The fields that the flow table <NUM> has are a CAN ID <NUM>, an output port <NUM>, and an information processing item <NUM>. The CAN ID <NUM> represents the CAN ID included in the header of the CAN frame inputted from each of the first CAN IF 202A and the second CAN IF 202B. The output port <NUM> represents the port for output from the microcomputer <NUM>. The information processing item <NUM> represents the process executed by the communication process <NUM>. However, the item described as the "offload" is allowed to be executed by the FPGA <NUM>.

The first record indicated by the reference numeral <NUM> represents that when the CAN frame in which the CAN ID is "<NUM>" is inputted, the decoding process is allowed to be executed by the FPGA <NUM> to output the CAN frame to the second CAN IF 202B. The second record indicated by the reference numeral <NUM> represents that when the CAN frame in which the CAN ID is "<NUM>" is inputted, the CAN frame is outputted to the FPGA <NUM>. The third record indicated by the reference numeral <NUM> represents that when the CAN frame in which the CAN ID is "<NUM>" is inputted, the encoding process is allowed to be executed by the FPGA <NUM> and the CAN frame is outputted to the first CAN IF 202A. The fourth record indicated by the reference numeral <NUM> represents that when the CAN frame in which the CAN ID is "<NUM>" is inputted, the communication process <NUM> itself executes the encoding process to output the CAN frame to the first CAN IF 202A.

<FIG> is a diagram illustrating an example of the FDB <NUM>. The FDB <NUM> includes a plurality of records having three fields. The fields that the FDB <NUM> has are a destination MAC address <NUM> included in the Ethernet frame, an output port <NUM> that represents the port for output from the FPGA <NUM>, and processing contents <NUM> in which the processing contents with respect to the communication frame are described.

The first record indicated by the reference numeral <NUM> represents that when the Ethernet frame in which the destination MAC address <NUM> is "<NUM>:<NUM>:<NUM>:<NUM>:<NUM>:<NUM>" is inputted, the communication circuit <NUM> relays the Ethernet frame to the first Ethernet IF 251A. The second record indicated by the reference numeral <NUM> represents that when the Ethernet frame in which the destination MAC address <NUM> is "<NUM>:<NUM>:<NUM>:<NUM>:<NUM>:<NUM>" is inputted, the communication circuit <NUM> relays the Ethernet frame to the second Ethernet IF 251B. The third record indicated by the reference numeral <NUM> represents that when the Ethernet frame in which the destination MAC address <NUM> is "<NUM>:<NUM>:<NUM>:<NUM>:<NUM>:<NUM>" is inputted, the communication circuit <NUM> relays the Ethernet frame to the microcomputer <NUM>. The fourth record indicated by the reference numeral <NUM> represents that when the Ethernet frame in which the destination MAC address <NUM> is "<NUM>:<NUM>:<NUM>:<NUM>:<NUM>:<NUM>" is inputted, the communication circuit <NUM> performs the filtering process to relay the Ethernet frame to the microcomputer <NUM>.

<FIG> is a diagram illustrating an example of the conversion DB <NUM>. The conversion DB <NUM> includes a plurality of records having two fields of a CAN ID <NUM> and a destination MAC address <NUM>. The conversion DB <NUM> is referred to when the CAN frame is encapsulated into the Ethernet frame.

The first record indicated by the reference numeral <NUM> represents that when the CAN frame in which the CAN ID is "<NUM>" is inputted, the CAN frame is encapsulated into the Ethernet frame in which the destination MAC address is "<NUM>:<NUM>:<NUM>:<NUM>:<NUM>:<NUM>". The second record indicated by the reference numeral <NUM> represents that when the CAN frame in which the CAN ID is "<NUM>" is inputted, the CAN frame is encapsulated into the Ethernet frame in which the destination MAC address is "<NUM>:<NUM>:<NUM>:<NUM>:<NUM>:<NUM>". It should be noted that other information necessary for the encapsulation, that is, the transmission source address, the EtherType, and the like, take a method for setting such the information from the outside to the internal register of the communication circuit <NUM>.

<FIG> is a flowchart illustrating the process of the microcomputer <NUM> when the first CAN IF 202A or the second CAN IF 202B receives the CAN frame. The CPU, not illustrated, constituting the microcomputer <NUM> mainly executes each step described below.

In step S601, the communication frame is received from the first CAN IF 202A or the second CAN IF 202B. In subsequent step S602, the CAN ID of the received communication frame is obtained. In subsequent step S603, the flow table <NUM> is searched for on the basis of the obtained CAN ID, and the output port and the information processing item, that is, the processing contents, are designated.

In subsequent step S604, it is determined whether or not the output port and the information processing item designated in step S603 satisfy particular conditions. That is, it is determined whether the output port is the FPGA <NUM> or the offload is included in the information processing item. When it is determined that at least one of the conditions is satisfied, the routine goes to step S605, and it is determined that neither of the conditions is satisfied, the routine goes to step S612.

In step S605, the state of the FPGA <NUM> is obtained from the monitoring process <NUM>. In subsequent step S606, it is determined whether or not the FPGA <NUM> is in the config state. When it is determined that the FPGA <NUM> is in the config state, the routine goes to step S607, and when it is determined that the FPGA <NUM> is not in the config state, the routine goes to step S656. It should be noted that the process in step S656 and thereafter will be described later with reference to <FIG>.

In step S607, since the FPGA <NUM> is in the config state and cannot receive the communication frame, the process for responding to the config state, that is, the storage of the received communication frame in the standby memory, is performed. In subsequent step S608, like step S605, the state of the FPGA <NUM> is obtained from the monitoring process <NUM>. In subsequent step S610, like step S606, it is determined whether or not the FPGA <NUM> is in the config state. When it is determined that the FPGA <NUM> is in the config state, the routine returns to step S608, and when it is determined that the FPGA <NUM> is not in the config state, the routine goes to step S611.

In step S611, it is determined whether or not the process for responding to configuration completion, that is, the information processing item designated in step S603, is the relay process. When it is determined that the information processing item is the relay process, the routine goes to step S612, and when it is determined that the information processing item is not the relay process, the routine goes to step S613. In step S612, the communication frame is transmitted from the output port, and the flowchart in <FIG> is ended. In step S613, the process is offloaded to the FPGA <NUM>. In other words, in place of the microcomputer <NUM>, the FPGA <NUM> is allowed to execute the encoding process, the decoding process, and the filtering process. Then, when the FPGA <NUM> completes these processes, the routine goes to step S612 to transmit the communication frame from the output port. The detail of step S613 will be described later with reference to <FIG>.

<FIG> is a subroutine illustrating a process when the negative determination is made in step S606 in <FIG>.

In step S656, from the obtaining of the state in step S605, it is determined whether or not the failure of the FPGA <NUM> has been detected. When it is determined that the failure has been detected, the routine goes to step S657, and when it is determined that the failure has not been detected, the routine goes to step S661. In step S657, like step S607, the communication frame is stored in the standby memory. In subsequent step S658, the recovery of the FPGA <NUM> is tried. In subsequent step <NUM>, the state of the FPGA <NUM> is obtained again, and the routine goes to step S660.

In step S660, from the obtaining of the state in step S659, it is determined whether or not the failure of the FPGA <NUM> has been detected. When it is determined that the failure has been detected, the routine goes to step S664, and when it is determined that the failure has not been detected, the routine goes to step S661.

In step S661 executed when in step S656 or step S660, the negative determination is made, it is determined whether or not the information processing item designated in step S603 is the relay process. When it is determined that the information processing item is the relay process, the routine goes to step S612, and when it is determined that the information processing item is not the relay process, the routine goes to step S613. In step S612, like <FIG>, the communication frame is transmitted from the output port, and the flowchart in <FIG> is ended. In step S613, like <FIG>, the process is offloaded to the FPGA <NUM>, and when the FPGA <NUM> completes these processes, the routine goes to step S612 to transmit the communication frame from the output port.

In step S664 executed when the positive determination is made in step S660, the failure information of the FPGA <NUM> is stored in the log, and the flowchart illustrated in <FIG> is ended. However, in this step, further, the failure may be notified to the external device connected to the on-vehicle gateway device <NUM>. By immediately notifying the failure, the external device can make appropriate response, so that the safety can be improved.

<FIG> is a flowchart of assistance in explaining a subroutine illustrating the detail of step S613 in <FIG> and <FIG> in which the microcomputer <NUM> offloads the process to the FPGA <NUM>.

In step S801, a loop counter i is initialized to <NUM>, and the routine goes to step S802. This loop counter is used for repeatedly executing the process in step S802 and thereafter N times at the maximum, as described later. In step S802, the microcomputer <NUM> transmits the communication frame to be offloaded to the FPGA <NUM>, and the routine goes to step S804. In step S804, the offload result is received from the FPGA <NUM>, and the routine goes to step S806. However, in step S804, the microcomputer <NUM> is standby until the offload result is received from the FPGA <NUM>.

In step S806, it is determined, on the basis of the offload result received in step S804, whether or not the offload process has been normally completed. When it is determined that the offload process has been normally completed, the flowchart in <FIG> is ended, and when it is determined that the offload process has not been normally completed, the routine goes to step S807. In step S807, the recovery of the FPGA <NUM> is tried. In subsequent step S808, the state of the FPGA <NUM> is obtained again, and the routine goes to step S809.

In step S809, it is determined, on the basis of the state of the FPGA <NUM> obtained in step S808, whether the failure of the FPGA <NUM> has been detected. When it is determined that failure of the FPGA <NUM> has been detected, the routine goes to step S812, and when it is determined that the failure of the FPGA <NUM> has not been detected, the routine goes to step S810. In step S810, it is determined whether or not the value of the loop counter i is equal to or more than N that is a defined number of repetitions. When it is determined that the i is equal to or more than N, the flowchart in <FIG> is ended, and when it is determined that the i is less than N, the routine goes to step S811. In step S811, the i is incremented, that is, the value of the i is increased by "<NUM>", and the routine returns to step S802.

In step S812 executed when the positive determination is made in step S809, the failure information of the FPGA <NUM> is stored in the log, and the flowchart illustrated in <FIG> is ended.

According to the first embodiment, the following operation and effect can be obtained.

Since the FPGA <NUM> cannot receive the communication frame until the configuration is completed, when the communication frame is transmitted before the configuration is completed, the communication frame disappears. However, the microcomputer <NUM> monitors the state of the FPGA <NUM>, and executes the process for responding to the config state when the FPGA <NUM> is in the config state, so that the communication frame received from the CAN network in the config state is not lost.

The on-vehicle gateway device <NUM> may use ASIC that is a logic circuit in which the circuit constitution is fixed, in place of the FPGA <NUM> that is a programmable logic circuit. When the ASIC is used for the on-vehicle gateway device <NUM> in place of the FPGA <NUM>, the configuration is not required, so that in step S606 in <FIG>, the negative determination is always made. However, following step S605, the routine may go to step S656 in <FIG>.

According to the first modification, in the combination of the microprocessor that reads and executes the previously stored program and the ASIC in which the circuit constitution is fixed, the microprocessor can select the received communication frame according to the state of the failure of the ASIC.

In the first embodiment, the microcomputer <NUM> and the FPGA <NUM> are independent members, and are connected by the wire. However, the microcomputer <NUM> and the FPGA <NUM> may be integrated in the manufacturing process to be accommodated in one package. In this case, the microcomputer <NUM> and the FPGA <NUM> may be formed on different silicon dies, or may be integrally formed on the same silicon die. When the microcomputer <NUM> and the FPGA <NUM> are formed on different silicon dies, like the first embodiment, the monitoring bus <NUM> and the data bus <NUM> are wires and contacts. When the microcomputer <NUM> and the FPGA <NUM> are formed on the same silicon die, the monitoring bus <NUM> and the data bus <NUM> do not have clear physical constitutions. Also, in this case, the microcomputer <NUM> and the FPGA <NUM> are always in connected state.

In the first embodiment, both of the determination of whether or not the FPGA <NUM> is in the config state and the determination of whether or not the FPGA <NUM> is failed are performed. However, only one of such the determinations may be performed. That is, in the case of performing only the former determination, when in step S606 in <FIG>, the negative determination is made, the routine goes to step S661. And, in the case of performing only the latter determination, step S656 in <FIG> is executed following step S605 in <FIG>.

The monitoring process <NUM> may determine whether or not the configuration of the FPGA <NUM> has been completed as follows. That is, after the signal indicating the configuration completion is outputted from the FPGA <NUM>, when the reset signal of the FPGA <NUM> is normally released, the monitoring process <NUM> may determine that the configuration has been completed. Specifically, when the signal indicating the configuration completion is simply outputted, without determining in step S606 in <FIG> that the config has been completed, the negative determination may be made in step S606 at the time of further normally releasing the reset signal. This reset signal is the signal outputted from the FPGA <NUM> via the monitoring bus <NUM> to the microcomputer <NUM>, and is released after the preparation of the operation of the FPGA <NUM> is completed.

In the first embodiment, the microcomputer <NUM> transmits the entire communication frame to be processed to the FPGA <NUM> for the offload process, but may extract only the data necessary for the offload process from the communication frame to transmit the extracted data to the FPGA <NUM>. Like this, for the result of the offload process, the FPGA <NUM> may transmit, of the information included in the communication frame, only the information that has been processed, not the entire communication frame, to the microcomputer <NUM>.

According to the fifth modification, since the entire communication frame is not transmitted and received, the communication data amount can be reduced, and the time to wait for the data transfer can be improved by the reduction in the data transfer time and the release of the band load between the FPGA <NUM> and the microcomputer <NUM>, so that the communication processing time of the on-vehicle gateway device <NUM> can be shortened.

In the first embodiment, the process for responding to the config state is the storage of the communication frame in the standby memory. However, the process for responding to the config state is not limited to this. For example, the counter provided in the communication process <NUM> may be counted up and store its value in the standby memory. In this case, the value of the counter is used as the value indicating the number of communication frames received in the config state. Also, the process for responding to the config state may count up the counter and discard the received communication frame. Further, the process for responding to the config state may discard the received communication frame, and transmit the retransmission request after the elapse of a predetermined time.

In the first embodiment, the process for responding to the config completion transmits the communication frame stored in the standby memory to the FPGA <NUM> for the offload process or the relay process with respect to the communication frame. However, the process for responding to the config completion is not limited to this. For example, the process for responding to the config completion may transmit the retransmission request of the communication frame. Also, when the count-up of the counter is included in the process for responding to the config state, the process for responding to the config completion may be the process using its count value.

A second embodiment of the on-vehicle system will be described with reference to <FIG>. In the following description, the same components as the first embodiment are indicated by the same reference numerals, and the different points will be mainly described. The points that are not particularly described are the same as the first embodiment. This embodiment is different from the first embodiment mainly in that the function is degraded according to the degree of the failure of the FPGA.

<FIG> is a block diagram of the on-vehicle gateway device <NUM> according to the second embodiment.

In the microcomputer <NUM>, the communication process <NUM> further includes a priority DB <NUM>, in addition to the constitution of the first embodiment. The priority DB <NUM> is a database that stores information about the priority of communication, and will be described later in detail. Also, the monitoring process <NUM> includes the function of discriminating the degree of the failure of the FPGA <NUM>. The degree of the failure can be discriminated in at least three stages of no failure, partial failure, and overall failure. The no failure is the state where the FPGA <NUM> is not failed, the partial failure is the state where part of the FPGA <NUM> has some problems and has more deteriorated processing ability than the no failure, and the overall failure is the state where the FPGA <NUM> cannot perform processing at all.

Further, the communication process <NUM> also includes the function of calculating the load acceptance capacity of the FPGA <NUM> as load acceptance capacity prediction. The calculation of the load acceptance capacity prediction is achieved by a method for previously measuring the load for each information processing item to store the load in the communication process <NUM>, a method for predicting the load from the size of the communication frame and the like, and the like. The load acceptance capacity prediction is expressed as, for example, an integer between <NUM> and <NUM>, and represents that as the numerical value is larger, the acceptance capacity that accepts the load is higher. At the initial value of the load acceptance capacity prediction, that is, at the time of the completion of the initialization of the FPGA <NUM>, when the FPGA <NUM> is not failed, the load acceptance capacity prediction is calculated as "<NUM>" that is the maximum value. Also, the program stored in the ROM, not illustrated, included in the microcomputer <NUM> is different from the first embodiment, and its operation is different, as descried later.

The FPGA <NUM> includes, in place of the communication circuit <NUM> according to the first embodiment, a first communication circuit 252A and a second communication circuit 252B. The first communication circuit 252A and the second communication circuit 252B are the same in constitution and function as the communication circuit <NUM> according to the first embodiment. That is, although not illustrated in <FIG>, both of the first communication circuit 252A and the second communication circuit 252B each include the FDB <NUM> and the conversion DB <NUM>. Each of the first communication circuit 252A and the second communication circuit 252B may have the same processing ability as the communication circuit <NUM>, or may have a lower processing ability than the communication circuit <NUM>. The first communication circuit 252A and the second communication circuit 252B exhibit the function of the FPGA <NUM> by typically sharing and executing the process.

Also, when one of the first communication circuit 252A and the second communication circuit 252B cannot be operated due to failure, the other of the first communication circuit 252A and the second communication circuit 252B can even singly exhibit the function of the FPGA <NUM>. For example, typically, the communication frames inputted to the FPGA <NUM> are alternately processed, the inputted first communication frame is processed by the first communication circuit 252A, and the inputted second communication frame is processed by the second communication circuit 252B. Then, for example, when the first communication circuit 252A is failed, the second communication circuit 252B processes all the inputted communication frames. However, since the processing ability of the FPGA <NUM> is lowered due to failure, the function is degraded, as described later, and only the communication frame that satisfies the condition is processed. It should be noted that the function sharing of the first communication circuit 252A and the second communication circuit 252B in normal operation is an example, and the first communication circuit 252A and the second communication circuit 252B may share the function in any manner.

The failure detection circuit, not illustrated, included in the FPGA <NUM> monitors the operation state of the first communication circuit 252A and the second communication circuit 252B, and when detecting a failure, transmits the occurrence of the failure to the microcomputer <NUM> via the monitoring bus <NUM>. For example, when the occurrence of the failures of both of the first communication circuit 252A and the second communication circuit 252B is transmitted, the monitoring process <NUM> determines this as the overall failure. When the occurrence of the failure of one of the first communication circuit 252A and the second communication circuit 252B is transmitted, the monitoring process <NUM> determines this as the partial failure. When the occurrence of the failures of both of the first communication circuit 252A and the second communication circuit 252B is not transmitted, the monitoring process <NUM> determines this as the no failure.

<FIG> is a diagram illustrating an example of the priority DB <NUM>. The priority DB <NUM> includes a plurality of records having two fields. The fields that the priority DB <NUM> has are a CAN ID <NUM> and priority <NUM>. The CAN ID <NUM> represents the CAN ID included in the header of the CAN frame inputted from each of the first CAN IF 202A and the second CAN IF 202B, and corresponds to the CAN ID <NUM> in the flow table <NUM> in <FIG>. The priority <NUM> is an integer between <NUM> and <NUM> that represents that for the information processing item <NUM> in the flow table <NUM> associated with the CAN ID indicated by the CAN ID <NUM>, as the numerical value is smaller, the priority of the process is higher. Although described later in detail, only when the load acceptance capacity prediction of the FPGA <NUM> is higher than the priority, the information processing item <NUM> in the flow table <NUM> is executed. That is, the priority DB <NUM> represents a threshold value that is the processing condition with respect to each of the information processing items <NUM> in the flow table <NUM>.

<FIG> is a flowchart illustrating the operation of the microcomputer according to the second embodiment. In <FIG>, the steps for performing the same process as <FIG> and <FIG> are indicated by the same step numbers, and the description thereof is omitted. It should be noted that as described above, immediately after the start-up of the on-vehicle gateway device <NUM>, the load acceptance capacity prediction is calculated as the maximum value, for example, <NUM>. The the CPU, not illustrated, constituting the microcomputer <NUM> mainly executes each step described below.

After the start of the flowchart illustrated in <FIG>, steps S601 to S605 are the same as <FIG>, and the description thereof is omitted. In step S1106 executed following step S605, the failure level of the FPGA <NUM> outputted by the monitoring process <NUM> is determined. At the time of the determination as the no failure, that is, when it is determined that the FPGA <NUM> is not failed, the routine goes to step S661. When it is determined that the FPGA <NUM> is partially failed, the routine goes to step S1107. When it is determined that the overall FPGA <NUM> is failed, the routine goes to step S657.

In step S1107, the priority DB <NUM> is referred to on the basis of the CAN ID obtained in step S602 to obtain the priority. For example, in the case where the priority DB <NUM> is the value illustrated in <FIG>, when the CAN ID is "<NUM>", "<NUM>" is obtained as the priority. In subsequent step S1108, the load acceptance capacity prediction is calculated on the basis of the degree of the failure of the FPGA <NUM> and the contents of the process executed by the FPGA <NUM>, and the routine goes to step S1109. In step S1109, the priority obtained in step S1107 and the load acceptance capacity prediction calculated in step S1108 are compared in magnitude, and it is determined whether or not the value of the load acceptance capacity prediction is equal to or less than the value of the priority. When it is determined that the value of the load acceptance capacity prediction is equal to or less than the value of the priority, the routine goes to step S657. When it is determined that the value of the load acceptance capacity prediction is more than the value of the priority, the routine goes to step S661.

In the case of the determination as the overall failure in step S1106, and when the positive determination is made in step S1109, like the first embodiment, steps S657 to S660 are executed. It should be noted that in step S658, the overall FPGA <NUM> may be recovered, but only the part in which the failure has been detected may be recovered to perform the configuration. Further, so-called dynamic reconfiguration that performs the configuration while the FPGA <NUM> is operated may be performed. In the case of the determination as the overall failure or the partial failure in step S660, the routine goes to step S664, and in the case of the determination as the no failure, the routine goes to step S661. The process in step S661 and thereafter is the same as the first embodiment, and the description thereof is omitted.

According to the second embodiment, the following operation and effect can be obtained.

When the FPGA <NUM> is partially failed, the communication process <NUM> obtains the threshold value with respect to the selected information processing item <NUM> on the basis of the priority database <NUM>, and decides, on the basis of the obtained threshold value and the load acceptance capacity of the FPGA <NUM>, whether or not the selected information processing item <NUM> is executed.

Therefore, at the time of the failure of the FPGA <NUM>, the process can be decided according to the CAN ID of the received communication frame in consideration of the load of the FPGA <NUM>.

(<NUM>) The microcomputer <NUM> stores the priority database <NUM> in which the identifier of the communication frame and the threshold value that is the processing condition, that is, the priority, are associated. The monitoring process <NUM> determines the degree of the failure of the FPGA <NUM>. When the communication process <NUM> determines, on the basis of the CAN ID of the received communication frame and the flow table <NUM>, that at least part of the received communication frame is required to be transmitted to the FPGA <NUM> (step S604 in <FIG>: YES), and determines that the degree of the failure of the FPGA <NUM> determined by the monitoring process <NUM> is the partial failure (step S1106 in <FIG>: the partial failure), the following process is performed. That is, the priority is obtained on the basis of the identifier of the received communication frame and the priority database <NUM> (step S1107), and it is decided, on the basis of the priority and the load acceptance capacity prediction, whether or not the FPGA <NUM> is allowed to execute the process about the communication frame (step S1108).

Therefore, at the time of the failure of the FPGA <NUM>, the information processing item stored in the flow table <NUM> is selected and executed on the basis of the CAN ID of the received communication frame, the degree of the failure, and the priority DB <NUM>, so that the limit of the communication process can be minimized, and thus, the communication process can be executed within the required time. Specifically, for example, even when the FPGA <NUM> is failed, and when such the failure is the partial failure, the communication process of the communication frame having high priority can be continued.

Also in the second embodiment, like the first embodiment, the microcomputer <NUM> determines whether or not the FPGA <NUM> is in the config state, and when determining that the FPGA <NUM> is in the config state, may execute the process for responding to the config state. Specifically, the process of step S606 and thereafter in <FIG> may be executed following step S605 in <FIG>, and when in step S606, it is determined that the FPGA <NUM> is not in the config state, the process in step S1106 and thereafter in <FIG> may be executed.

When the microcomputer <NUM> does not include the priority DB <NUM>, and determines that the degree of the failure of the FPGA <NUM> is the partial failure, only part of the communication frame may be transmitted to the FPGA <NUM>. For example, in place of step S1107 to step S1109 in <FIG>, the presence or absence of the process may be randomly decided, and only when it is determined that the process is performed, the routine may go to step S661, and otherwise, the routine may go to step S657. Further, the probability to perform the process may be increased or decreased according to the degree of the failure of the FPGA <NUM>, and in that case, as the degree of the failure is lower, the probability to perform the process becomes higher. Also, it may be determined, on the basis of the contents of the process allowed to be performed by the FPGA <NUM> and the magnitude of the processing load, whether or not the communication frame is transmitted to the FPGA <NUM>.

In the second embodiment, the load acceptance capacity prediction is calculated on the basis of the communication frame transmitted from the microcomputer <NUM> to the FPGA <NUM> and its processing contents. However, the degree of the failure of the FPGA <NUM> may be further considered, and when the FPGA <NUM> has the function of outputting the current load, its output may be used.

In the second embodiment, in place of performing the classification by case according to the degree of the failure of the FPGA <NUM>, the degree of the failure of the FPGA <NUM> may be reflected in the comparison of the load acceptance capacity prediction and the priority. For example, in the flowchart in <FIG>, the routine goes to step S1107 following step S605. Then, at least one of the load acceptance capacity prediction and the priority is adjusted so that when the degree of the failure of the FPGA <NUM> is the no failure, the negative determination is made in step S1108, and when the degree of the failure of the FPGA <NUM> is the overall failure, the positive determination is made in step S1108, and the routine goes to step S1108.

For example, when the degree of the failure of the FPGA <NUM> is the no failure, regardless of the execution result in step S1107, the priority is set to a value smaller than the minimum value of the load acceptance capacity prediction, for example, "-<NUM>", or the load acceptance capacity prediction is set to a value larger than the maximum value of the priority, for example, "<NUM>".

The monitoring process <NUM> may determine the degree of the failure of the FPGA <NUM> only on the basis of whether or not each of the first communication circuit 252A and the second communication circuit 252B is operated. In this case, the determination as the partial failure in step S1106 in <FIG> is made when only one of the first communication circuit 252A and the second communication circuit 252B is operated. At this time, the maximum value of the load acceptance capacity prediction is the previously set value, for example, "<NUM>".

The program of the microcomputer <NUM> is stored in the ROM, not illustrated, but the program may be stored in the nonvolatile memory, not illustrated, included in the microcomputer <NUM>. Also, the microcomputer <NUM> may include the input-output interface, not illustrated, and the program may be read from another device via a medium that can be used by the input-output interface and the microcomputer <NUM>, when necessary. Here, the medium is referred to as, for example, a storage medium that can be provided to and removed from the input-output interface, or a communication medium, that is, a network, for example, a wired network, a wireless network, and an optical network, or a carrier wave and a digital signal carried on the network. Also, part or all of the function achieved by the program may be achieved by the hardware circuit and the FPGA.

Claim 1:
An on-vehicle gateway device (<NUM>), comprising:
a microcomputer (<NUM>) that is connected to a logic circuit (<NUM>), wherein the logic circuit (<NUM>) is comprising a communication circuit (<NUM>) having a forwarding database (<NUM>) and a conversion database (<NUM>), wherein
a monitoring unit is monitoring the state of the logic circuit (<NUM>),
a storage unit is storing a plurality of information processing items (<NUM>) executed by the microcomputer (<NUM>), wherein the plurality of information processing items (<NUM>) involves relaying with or without en-ide-coding and offloading, wherein
a processing unit is executing a process with regard to the state of the logic circuit (<NUM>) and at least one information processing item selected from the plurality of information processing items (<NUM>) with regard to a communication frame inputted to the microcomputer (<NUM>
wherein the logic circuit (<NUM>) is subject to config to be capable of constituting a circuit constitution,
wherein the monitoring unit monitors whether or not the logic circuit (<NUM>) is in config state,
wherein when the logic circuit (<NUM>) is not in the config state, the processing unit executes the selected information processing item, and
wherein when the logic circuit (<NUM>) is in the config state, the processing unit executes a process different from the selected information processing item, wherein
the microcomputer (<NUM>) and the logic circuit (<NUM>) are included in one gateway device (<NUM>) that connects CAN with Ethernet, and wherein
the microcomputer (<NUM>) is connected to the CAN, and the logic circuit (<NUM>) is connected to the Ethernet.