JP7613073B2 - Repeater - Google Patents

Description

The technology disclosed here belongs to the technical field of relay devices mounted on vehicles.

In recent years, the development of autonomous driving systems has been progressing nationally, and almost all actuators installed in vehicles are now electronically controlled. The control devices that control these actuators often have software structures that comply with the AUTOSAR (AUTomotive Open System ARchitecture) standard.

For example, Patent Document 1 discloses a method for bypassing an AUTOSAR software element in an AUTOSAR software system having multiple AUTOSAR software elements connected via a runtime environment. Patent Document 2 discloses a method for setting a data destination in a communication network in a software structure conforming to AUTOSAR.

In addition, in-vehicle network devices are beginning to adopt a method in which a network configuration with ECUs (Electronic Control Units) corresponding to each component of the vehicle is eliminated, and instead an ECU that manages the operation of the entire vehicle is provided, with sensors and actuators in various locations on the vehicle being controlled by the ECU that manages the operation of the entire vehicle.

JP 2012-133786 A JP 2017-105362 A

However, when a network is configured around the central ECU as described above, if part of the network fails, there is a risk that signals from sensors, etc. will not be sent to the central ECU, and that commands, etc. from the central ECU to actuators will not be transmitted. For example, if communication fails in part of the network connecting the central ECU to the ignition switch and engine control unit (PCM), there is a risk that the engine cannot be turned off.

The technology disclosed here has been developed in light of these points, and its purpose is to enable rapid execution of fail-safe operations even in the event of a communication interruption between the central controller and the hub device, or when a relatively urgent abnormality is detected.

In order to solve the above problem, the technology disclosed herein is directed to a relay device in an in-vehicle network that relays communication between a central controller and an in-vehicle device, and includes a control unit that outputs a control signal received from the central controller via the in-vehicle network to the in-vehicle device. The control unit has, as a software configuration, a device driver layer that includes a hardware abstraction function and these device drivers, and a middleware layer that is provided above the device driver layer and relays between the in-vehicle network and the device driver layer to set up a communication path between them. When the specific abnormal state is detected, the middleware layer executes abnormality processing to output a predetermined specific signal to the in-vehicle device, regardless of the control signal from the central controller.

According to this embodiment, when a specific abnormal state is detected, the middleware layer executes abnormality processing to output a predetermined specific signal to the in-vehicle device without relying on a control signal from the central controller. As a result, when a specific abnormal state is detected, a fail-safe operation is automatically executed, so that the output device can immediately execute an operation in a safe direction (fail-safe operation) without waiting for a processing decision from the central controller.

In the relay device, the middleware layer may detect the specific abnormal state when a timeout occurs during which no signal is received from the central controller for a certain period of time.

As a result, even if communication between the central controller and the relay device in the in-vehicle network fails, it can be detected by the occurrence of a timeout. As a result, even if communication between the central controller and the relay device fails, a safety operation (fail-safe operation) can be quickly performed.

In the relay device, the in-vehicle device may include a sensor device and an actuator, the control unit may output measurement data of the sensor device to the in-vehicle network and output the control signal from the central controller to the actuator, and the middleware layer may detect a specific abnormal state when a measurement value deviating from a predetermined threshold is input from the sensor device.

This allows safe operation (fail-safe operation) to be performed based on abnormality detection in the sensor device without relying on processing by a central controller.

As described above, the technology disclosed herein makes it possible to quickly execute a safe operation when an abnormal condition, such as a partial interruption of the in-vehicle network, is detected.

FIG. 1 is a diagram illustrating an example of the configuration of a vehicle control system. FIG. 2 is a block diagram showing a configuration example of a central controller. FIG. 1 is a diagram illustrating an example of the configuration of an in-vehicle device control device according to an embodiment. FIG. 1 is a diagram illustrating an example of the configuration of an in-vehicle device control device according to an embodiment.

An exemplary embodiment will be described in detail below with reference to the drawings.

<Vehicle control system>
FIG. 1 is a diagram showing an example of the configuration of a vehicle control system.

The vehicle control system is configured with an in-vehicle network (hereinafter referred to as the in-vehicle network CN) centered around a central controller 10 that manages the operation of the entire vehicle. The communication method of the in-vehicle network CN is not particularly limited, but it is configured, for example, as a network that complies with the communication protocol of CAN (Controller Area Network) or Ethernet (registered trademark).

In a vehicle control system, for example, a vehicle 1 is divided into multiple zones, and a hub device 30 is provided in each zone to connect electronic devices such as sensors and actuators (hereinafter also referred to as in-vehicle devices 20). The hub device 30 has a function of relaying information transmitted via the in-vehicle network CN.

In the example of FIG. 1, a front hub device 31 is placed at the front of the vehicle 1, and side hub devices 32 are placed near the doors on both sides of the vehicle as hub devices 30. The central controller 10 and the front hub device 31 are connected by a communication cable CN1 that constitutes the in-vehicle network CN. The central controller 10 and the side hub device 32 on the right side of the vehicle are connected by a communication cable CN2 that constitutes the in-vehicle network CN. The central controller 10 and the side hub device 32 on the left side of the vehicle are connected by a communication cable CN3 that constitutes the in-vehicle network CN.

- In-vehicle equipment -
The in-vehicle device 20 includes an input device including a sensor device and a signal receiving device, and an output device including an actuator. The input device and the output device to which the present disclosure is directed are not particularly limited as long as they are devices that can be mounted on a vehicle.

Although specific illustrations are omitted, the input devices include, for example, a camera for capturing images of the interior and exterior environments of the vehicle, a plurality of radars for detecting obstacles outside the vehicle, a vehicle position sensor using a Global Positioning System (GPS), vehicle state sensors for detecting the behavior of the vehicle such as a vehicle speed sensor, an acceleration sensor, and a yaw rate sensor, an occupant state sensor for acquiring the state of the occupants of the vehicle 1, a driving operation sensor for detecting the driving operation of the driver, a keyless entry sensor, a human presence sensor, and the like. The input devices also include switches for detecting operations by the occupants. Examples of the switches include a door opening/closing switch for the occupant to open and close an electric door, a power window opening/closing switch for operating an electric power window, a washer level switch, a hood switch, and the like.

Although specific illustrations are omitted, actuators include drive system actuators, steering system actuators, braking system actuators, etc. Examples of drive system actuators include engines, transmissions, and motors. An example of a braking system actuator is a brake. An example of a steering system actuator is a steering wheel. In addition, actuators include, for example, door lock devices for locking side doors, door opening and closing devices for electrically opening and closing doors, window opening and closing devices for opening and closing electric power windows, lighting control devices for controlling the lighting of headlights, etc., airbag devices, audio devices, etc.

In FIG. 1, an example is shown in which an ignition switch 41 is connected to the front hub device 31 as the input device 4, and an electric power window opening/closing switch 42 and an entrapment detection unit 43 that detects entrapment of the electric power window are connected to each side hub device 32. The entrapment detection unit 43 is an example of a sensor device.

In addition, FIG. 1 shows an example in which an engine control unit 51 (hereinafter referred to as PCM 51) is connected to the front hub device 31 as an output device, and a window opening/closing device 53 is connected to each side hub device 32. The window opening/closing device 53 is an example of an actuator.

-Central Controller-
2, the central controller 10 includes a CPU 100, a memory 160, and a connection unit 170. The central controller 10 may be configured with a single IC (Integrated Circuit), or may be configured with multiple ICs.

As described above, the central controller 10 is connected to the in-vehicle device 20 via the hub device 30 serving as a relay device. The number of hub devices 30 connected to the central controller 10 is not particularly limited. In addition, multiple hub devices 30 may be interposed between the central controller 10 and the in-vehicle device 20. In other words, the central controller 10 and the in-vehicle device 20 may be connected via multiple hub devices 30.

[CPU]
The CPU 100 performs various processes by reading and executing programs from the memory 160. Specifically, for example, the CPU 100 reads data acquired or detected by an input device such as a sensor, performs various arithmetic processes to realize various functions, and generates and outputs control signals for controlling actuators. The CPU 100 may be realized by a microcomputer (a so-called microcomputer) or a SoC (System-on-Chip).

(Hardware)
The CPU 100 includes, as a hardware configuration, a calculation processing unit that executes various types of calculation processing in accordance with programs stored in a memory 160 .

The connection unit 170 has multiple communication ports (not shown) and is configured to be connectable to the communication cables CN1 to CN3 that make up the aforementioned in-vehicle network CN. The connection unit 170 functions as a front-end circuit for two-way communication with the zone ECU 40, and includes, for example, an analog/digital conversion circuit, a driver circuit, a receiver circuit, etc.

(software)
The CPU 100 has, as its software configuration, a top-level application layer 110 , a runtime environment 140 below the application layer 110 , and a device driver layer 150 below the runtime environment 140 .

The CPU 100 may adopt a software structure that complies with the so-called AUTOSAR. In this case, the application layer 110 corresponds to the application layer of AUTOSAR and is composed of, for example, one or more SWC (Software Component) modules. The runtime environment 140 corresponds to the RTE of AUTOSAR. And the device driver layer 150 corresponds to BSW (Basic Software) including the Complex Driver and MCAL (Microcontroller Abstraction Layer) of AUTOSAR.

Application Layer
The application layer 110 is implemented with applications for implementing various functions for the in-vehicle device 20. The applications include an exterior environment recognition module 113, a driving operation recognition module 114, a vehicle behavior estimation module 115, an input operation recognition module 116, a peripheral device control module 117, and a driving control module 120.

The exterior environment recognition module 113 recognizes the external environment of the vehicle based on the outputs of the camera, radar, position sensor, exterior communication unit, and vehicle behavior estimation module 115. The driving operation recognition module 114 recognizes driving operations applied to the vehicle based on the outputs of the driving operation sensors. The vehicle behavior estimation module 115 estimates the vehicle behavior (e.g., speed, acceleration, yaw rate, etc.) based on the outputs of the vehicle state sensors.

The driving control module 120 outputs a control signal for controlling the output device 5 related to driving control based on the output of the external environment recognition module 113, the driving operation recognition module 114, the vehicle behavior estimation module 115, etc. Specifically, the driving control module 120 generates a target route for the vehicle 1 to travel, determines a target motion based on the target route, and derives a target driving force, a target braking force, and a target steering amount, which are a driving force, a braking force, and a steering amount for achieving the target motion. Furthermore, the driving control module 120 generates a control signal for controlling an actuator based on the determined target motion, and outputs it to the runtime environment 140. Specifically, the driving control module 120 generates a driving command value indicating a target driving force to be transmitted to an actuator of the driving system, a braking command value indicating a target braking force to be transmitted to an actuator of the braking system, and a steering command value indicating a target steering amount to be transmitted to an actuator of the steering system, and outputs them to the runtime environment 140.

Runtime Environment
The runtime environment 140 is configured to abstract and connect the software implemented in the application layer 110 and the device driver layer 150. The runtime environment 140 may have a known configuration.

<Device driver layer>
The device driver layer 150 includes, for example, an operating system and device drivers. The device drivers include a communication driver (not shown) that complies with the communication protocol of the in-vehicle network CNW. For example, if the in-vehicle network CN is a network that complies with CAN, a CAN driver is provided as the communication driver. The software implemented in the device driver layer 150 may be of a known configuration.

[Memory]
Memory 160 includes, as storage areas, a code area in which programs for operating CPU 100 are stored, and a rewritable data area in which data such as results of processing by CPU 100 is stored. Specifically, the code area stores programs for operating the above-mentioned applications, runtime environment 140, operating system, and device drivers.

- Vehicle-mounted device control device -
The in-vehicle equipment control device 400 is mounted on one or more hub devices 30. That is, the in-vehicle equipment control device 400 may be mounted on all of the hub devices 30, or on some of the hub devices 30.

Figures 3 and 4 are block diagrams showing an example of the configuration of the vehicle-mounted device control device 400. The vehicle-mounted device control device 400 is composed of, for example, a CPU 450 (processor) and a memory 460. In this embodiment, the vehicle-mounted device control device 400 in Figure 3 is mounted on the front hub device 31, and the vehicle-mounted device control device 400 in Figure 4 is mounted on the side hub 32. In the following description, common components are denoted by common reference symbols in Figures 3 and 4, and duplicate or individual descriptions may be omitted.

[CPU]
3 and 4, the CPU 450 performs various processes by reading and executing a program 462 from the memory 460. Specifically, the CPU 450 reads input data (e.g., detection data detected by a sensor device) from the input device 4 and transmits it to the central controller 10, or receives a signal from the central controller 10 and generates and outputs a control signal for controlling the output device 5 (e.g., an actuator). The CPU 450 is an example of a control unit. Note that the specific form of the CPU 450 is not particularly limited. For example, the CPU 450 may be realized by a microcomputer (a so-called microcomputer) or by a SoC (System-on-Chip).

Hardware
3 and 4, the CPU 450 includes, as hardware configuration, an arithmetic processing unit that executes various arithmetic processing according to programs stored in the memory 460, and a peripheral function unit 480. The peripheral here refers to the in-vehicle device 20 that is used in combination with the central controller 10 and/or the hub device 30.

The peripheral function unit 480 includes one or more peripheral function sections 481 for causing the peripheral, i.e., the in-vehicle device 20, to function.

The peripheral function unit 481 includes, for example, an analog-to-digital converter 481a (hereinafter referred to as ADC 481a), a digital input unit 481b, a digital output unit 481c, and a PWM control unit 481d. Note that the peripheral function unit 481 may be equipped with some of the above 481a to 481d, or may include other configurations. Note that in the following, when the peripheral functions of the ADC 481a, the digital input unit 481b, the digital output unit 481c, and the PWM control unit 481d are described without making any particular distinction, they will simply be referred to as the peripheral function unit 481.

Each of the peripheral function units 481 has a plurality of channels. Each channel is configured so that an input/output unit (e.g., a connector for I/O connection) of the in-vehicle device 20 can be connected to the input/output unit. FIG. 3 shows an example in which the ADC 481a is provided with input channels CHa1 and CHa2, the digital input unit 481b is provided with input channels CHb1 and CHb2, the digital output unit 481c is provided with output channels CHc1 and CHc2, and the PWM control unit 481d is provided with output channels CHc1 and CHc2. The number of channels is not limited to two, and may be three or more. A single peripheral function unit 481 may be provided with both input and output channels.

"software"
3 and 4, the CPU 450 has, as a software configuration, a middleware layer 430 and a device driver layer 440. Note that since the technology of the present disclosure can operate without an application layer, the application layer is omitted in the configurations of Fig. 3 and Fig. 4. However, an application layer may be provided.

For example, the CPU 450 may employ a software structure that complies with the so-called AUTOSAR. In this case, the device driver layer 440 and the middleware layer 430 correspond to the BSW (Basic Software) of AUTOSAR, and the device driver layer 440 corresponds to the MCAL (Microcontroller Abstraction Layer) of AUTOSAR. The middleware layer may be implemented as a Complex Driver. When an application layer is implemented in the CPU 450, for example, one or more SWC (Software Component) module configurations that correspond to the application layer of AUTOSAR can be employed.

The device driver layer 440 implements a device driver unit 441 that converts software commands processed in the middleware layer 430 into commands for hardware.

The device driver unit 441 is implemented with a device driver for each peripheral function unit 481 included in the peripheral function unit 480. As described above, in the example of FIG. 3 and FIG. 4, the peripheral function unit 481 includes the ADC 481a, the digital input unit 481b, the digital output unit 481c, and the PWM control unit 481d. Therefore, the device driver unit 441 includes the ADC driver 441a which is a device driver for the ADC 481a, the DIO driver 441b which is a device driver for the digital input unit 481b and the digital output unit 481c, and the PWM driver 441d which is a device driver for the PWM control unit 481d. That is, the ADC driver 441a is connected to the ADC 481a, the DIO driver 441b is connected to the digital input unit 481b and the digital output unit 481c, and the PWM driver 441d is connected to the PWM control unit 481d.

The device driver unit 441 also includes a communication driver 441e for connecting to the in-vehicle network CN. The communication driver 441e complies with the communication protocol of the in-vehicle network CN. For example, if the in-vehicle network is CAN, a CAN driver is provided as the communication driver 441e. Note that the communication protocol of the in-vehicle network to which the technology disclosed herein can be applied is not limited to CAN, and may be, for example, another communication protocol such as Ethernet.

A device driver is software that is hardware-dependent. Generally, hardware-independent software (such as an operating system) is also implemented in the device driver layer 440, but as this has little relevance to the present invention, illustrations and explanations of this are omitted in this embodiment.

The middleware layer 430 implements a routing module 434 that includes one or more first communication packets 431 provided on the upper side (for example, for connecting to an application layer if there is an application layer), one or more second communication packets 432 for exchanging data with a device driver, and an external communication packet 433 for exchanging data with the in-vehicle network CN.

Here, an example is shown in which IO_1, IO_2, ... IO_X (X is a natural number) are implemented as the first communication packet 431. In addition, as the second communication packet 432, (1) ADC_1, ADC_2, ... ADC_L (L is a natural number) for exchanging data with the ADC driver 441a, (2) DI_1, DI_2, ... DI_M (M is a natural number) and DO_1, DO_2, ... DO_N (N is a natural number) for exchanging data with the DIO driver 441b, and (3) PWM_1, PWM_2, ... PWN_Q (Q is a natural number) for exchanging data with the PWM driver 441d are implemented. As the external communication packet 433, SIG_A, SIG_B, SIG_C are implemented. In the following explanation, for convenience, external communication packets SIG_A, SIG_B, and SIG_C may be collectively referred to as external communication packet 433.

Here, the external communication packet 433 has a packet configuration suitable for the in-vehicle network CN in order to transfer data to the in-vehicle network CN. For example, when the in-vehicle network CN is CAN, the external communication packet 433 is configured to be able to communicate with the central controller 10 or other hub devices 30 in accordance with the CAN communication protocol via the communication driver 441e. More specifically, in the external communication packet 433, for example, in order to create a data frame of the "standard format" or "extended format" of CAN communication, data acquired from the input device 4 is subjected to size adjustment processing and data processing such as format conversion and stored. In addition, when the external communication packet 433 receives a signal via the CAN bus, data acquisition processing is performed to extract information required to operate the output device 5 from the data frame, and the data is transmitted to the first communication packet 431. The above size adjustment processing, data processing processing, and/or data acquisition processing may each be defined, for example, in the code area 461 described later, or may be stored in a rewritable format in the data area 465 described later.

Although not specifically illustrated, the following connections exist:

The communication packet ADC_1 is connected to channel CHa1 of the ADC 481a, and the communication packet ADC_2 is connected to channel CHa2 of the ADC 481a. The communication packet DI_1 is connected to channel CHb1 of the digital input unit 481b, and the communication packet DI_2 is connected to channel CHb2 of the digital input unit 481b. The communication packet DO_1 is connected to channel CHc1 of the digital output unit 481c, and the communication packet DO_2 is connected to channel CHc2 of the digital output unit 481c. The communication packet PWM_1 is connected to channel CHd1 of the PWM control unit 481d, and the communication packet PWM_2 is connected to channel CHd2 of the PWM control unit 481d.

The routing module 434 generates communication paths between communication packets in the routing module 434 based on the mapping module. Examples of generating individual communication paths will be described later.

Although not shown, when an application layer is provided, a runtime environment (RTE) may be implemented between the application layer and the routing module 434. The runtime environment is configured to abstract and connect the application layer and the software implemented in the device driver layer 440.

[Memory]
Common to both Figures 3 and 4, the memory 460 has, as storage areas, a code area 461 in which a program 462 for operating the CPU 450 is stored, and a rewritable data area 465 in which the processing results of the CPU 450 and data such as a mapping module 466 and a determination module 468 are stored.

Code Area
In the code area 461, for example, a program 462 created in advance in the design stage of the in-vehicle equipment control device 400 is compiled and implemented. For example, the code area 461 in Fig. 3 stores a basic framework of the routing module 434 in the front hub device 31 and a program 462 constituting each driver of the device driver unit 441. Similarly, for example, the code area 461 in Fig. 4 stores a basic framework of the routing module 434 in the side hub device 32 and a program 462 constituting each driver of the device driver unit 441. Note that when an application layer is provided in the hub device 30, a program for operating an application of the application layer is stored in the code area 461.

Data Area
As described above, the data area 465 stores data including a mapping module 466 and a determination module 468 .

The mapping module 466 is a module that specifies the connection relationship between the first communication packet 431, the second communication packet 432, and/or the external communication packet 433.

As a process (hereinafter referred to as "normal process") during normal operation (hereinafter referred to as "normal operation") in which no specific abnormal state is confirmed, the mapping module 466 outputs input data input from the input device 4 via the second communication packet 432 to the communication driver 441e via the external communication packet 433. In addition, in the relay process, the mapping module 466 outputs received data received from the central controller 10 or another hub device 30 via the external communication packet 433 to the device driver unit 441 connected to the output device 5 controlled by the received data via the second communication packet 432.

On the other hand, the mapping module 466 outputs a predetermined specific signal to the device driver unit 441 to which the output device 5 to be controlled by the specific signal is connected as a process to be performed when a specific abnormal state is detected (hereinafter referred to as "abnormal process"). This abnormal process is executed regardless of whether or not there is data received from the central controller 10 or another hub device 30.

The specific abnormal state is not particularly limited. For example, a specific abnormal state may be a communication abnormality with the central controller 10, such as a communication path from the central controller 10 to the hub device 30 being interrupted. A specific abnormal state may also be discovered based on input data from the input device 4, such as input data from the input device 4 exceeding a specific threshold.

[Operation example (1) of the in-vehicle device control device]
Next, an example of the operation of the vehicle-mounted device control device 400 will be described with reference to Fig. 3. As described above, it is assumed that the vehicle-mounted device control device 400 in Fig. 3 is mounted on the front hub device 31.

In this operation example, the external communication packet 433 of the front hub device 31 is configured to be able to send and receive communication packets to and from the central controller 10 via the in-vehicle network CN.

Here, in the front hub device 31, when a specific reception signal is not received from the central controller 10 for a predetermined fixed period of time, i.e., when a so-called timeout occurs, a value different from the on control signal and the off control signal (e.g., "2") is set as a timeout value in the external communication packet SIG_C.

Note that well-known technologies can be applied to bidirectional communication (mutual transmission and reception of data) using external communication packets 433. Specifically, for example, when the in-vehicle network uses CAN communication, (1) communication packets are sent periodically regardless of the presence or absence of data, or (2) communication packets are sent in response to a predetermined trigger. External communication packets 433 can support both (1) and (2) above, and are configured to support such packet communication.

First, the process when the ignition switch 41 is turned on/off in the front hub device 31 in FIG. 3 will be described. When the ignition switch 41 is turned on, a "1 (on control signal)" is input from the central controller 10, and when the ignition switch 41 is turned off, a "0 (off control signal)" is input from the central controller 10.

In normal operation, assume that the driver turns on the ignition switch 41. Then, in the front hub device 31, the on operation signal is input to the DIO driver 441b via the digital input unit 481b, and is sent to the routing module 434 as a communication packet DI_1.

Then, the mapping module 466 is applied and the external communication packet SIG_A is sent via the communication packet IO_1. The external communication packet SIG_A is sent to the connection unit 170 of the central controller 10 via the communication driver 441e.

When the central controller 10 receives an ON operation signal for the ignition switch 41 from the front hub device 31, the ON operation signal is input to the input operation recognition module 116. Based on the operation information indicated by the ON operation signal, the central controller 10 outputs an ON control signal for controlling the PCM 51 to ON to the communication cable CN1.

When the front hub device 31 receives an ON control signal from the PCM 51, the ON control signal is stored in a communication packet SIG_C via the communication driver 441e, and the mapping module 466 is applied. As described above, a "1" is input as the ON control signal, so the abnormality determination module determines "TRUE". Then, the communication packet SIG_C is sent to a communication packet DO_1 via a communication packet IO_3. The communication packet DO_1 is then output to the PCM 51 via the DIO driver 441b and channel CHc1 of the digital output unit 481c. When the ON control signal is received, the PCM 51 executes the engine start process.

When the ignition switch 41 is turned off, the same process as when the ignition switch 41 is turned on is executed. Specifically, when the ignition switch 41 is turned off, an off operation signal is sent from the front hub device 31 to the central controller 10 in the same manner as when the ignition switch 41 is turned on. When the central controller 10 receives the off operation signal, it outputs an off control signal to the communication cable CN1 for controlling the PCM 51 on. As described above, the front hub device 31 receives "0" as the off control signal, so the abnormality determination module determines "TRUE". Then, the external communication packet SIG_C is sent to the communication packet DO_1 via the communication packet IO_3 and output to the PCM 51. When the PCM 51 receives the off control signal, it executes the engine stop process.

In this way, in normal operation, the on/off operation signal of the ignition switch 41 connected to the front hub device 31 is sent to the central controller 10, and the engine start/stop process is executed under the control of the central controller 10.

Here, a specific abnormal state is assumed to be when the communication cable CN1 connecting the central controller 10 and the front hub device 31 is interrupted while the engine is running. When this happens, the off operation signal of the ignition switch 41 is no longer transmitted to the central controller 10. Then, when a predetermined time has elapsed and a timeout occurs, a timeout value of "2" is set in the external communication packet SIG_C.

Then, the abnormality determination module makes a "FAULT" determination, and the external communication packet SIG_C is set to "0" (engine stop instruction signal) as a fail-safe value indicating an OFF control signal, without relying on a control signal from the central controller 10, i.e., without input of a control signal from the central controller 10. This external communication packet SIG_C is sent to communication packet DO_1 via communication packet IO_3, and output to PCM 51. Then, in PCM 51, engine stop processing is executed in the same manner as when an OFF control signal is received from the central controller 10.

As described above, according to this embodiment, even if communication is interrupted between the central controller 10 and the hub device 30, a fail-safe operation is performed based on abnormality detection (here, a timeout) without being based on the processing of the central controller 10. As a result, even if communication between the central controller 10 and the hub device 30 or communication between the hub devices 30 is interrupted, a safe operation is quickly performed, preventing the loss of key functions. Furthermore, because the fail-safe processing can be set simply by changing the data area, the software design process and verification process can be simplified, and the software development man-hours can be significantly reduced.

[Operation example (2) of the in-vehicle device control device]
Next, another example of the operation of the vehicle-mounted equipment control device 400 will be described with reference to Fig. 4. As described above, it is assumed that the vehicle-mounted equipment control device 400 in Fig. 4 is mounted on the side hub device 32.

In this operation example, the external communication packet 433 of the side hub device 32 is configured to be able to send and receive communication packets to and from the central controller 10 via the in-vehicle network CN.

First, the process when the electric window opening/closing switch 42 is operated in the side hub device 32 in FIG. 4 will be described. It is assumed that an opening/closing control signal for the window opening/closing device 53 is input from the central controller 10 in response to the operation of the opening/closing switch 42. It is also assumed here that the electric window is initially in the open state.

In normal operation, assume that the driver closes the open/close switch 42. In this case, in the side hub device 32, the close operation signal is input to the DIO driver 441b via the digital input unit 481b, and is sent to the routing module 434 as a communication packet DI_2.

Then, the mapping module 466 is applied and the external communication packet SIG_B is sent via the communication packet IO_2. The external communication packet SIG_B is sent to the connection unit 170 of the central controller 10 via the communication driver 441e.

When the central controller 10 receives an electric window closing operation signal from the side hub device 32, it is input to the input operation recognition module 116. Based on the operation information indicated by the closing operation signal, the central controller 10 outputs a closing control signal for controlling the electric window to close to the communication cable CN1.

When the side hub device 32 receives a close control signal for the electric window, the close control signal is stored in an external communication packet SIG_C via the communication driver 441e, and the mapping module 466 is applied. Here, no abnormality is determined, i.e., the abnormality determination module determines "TRUE", and the external communication packet SIG_C is sent to a communication packet DO_1 via a communication packet IO_3. The communication packet DO_1 is then output to the window opening and closing device 53 via the DIO driver 441b and the channel CHc1 of the digital output unit 481c. When the window opening and closing device 53 receives the close control signal, the closing operation process for the electric window is executed.

The pinch detection unit 43 detects whether or not something is pinched in the electric window when the electric window is opened or closed. The detection result of the pinch detection unit 43 is input to the ADC driver 441a via the ADC 481a and transmitted to the routing module 434 as a communication packet ADC_1.

Then, the mapping module 466 is applied and the external communication packet SIG_A is sent via the communication packet IO_1. The external communication packet SIG_A is sent to the connection unit 170 of the central controller 10 via the communication driver 441e.

Here, we consider a case where a specific abnormal state with a relatively high priority that may affect human safety is detected, such as when there is an abnormality in the detection data from the entrapment detection unit 43. In such a case, if the detection data is sent to the central controller 10, the central controller 10 judges the data, and the central controller 10 receives a control signal based on the judgment result before carrying out control, the processing may not be completed in time.

Therefore, in this embodiment, when a specific abnormal condition is detected, for example, when a measurement value that deviates from a predetermined threshold is input from a specific pre-set sensor device, it is determined that a specific abnormal condition has been detected, and abnormality processing is executed to output a predetermined specific signal to the in-vehicle device 20 without relying on a control signal from the central controller 10.

For example, suppose that while the window opening/closing device 53 is controlling the central controller 10 to close the electric window, the pinch detection unit 43 detects a value exceeding the predetermined threshold value PTH, i.e., pinch is detected.

Then, the abnormality determination module determines "FAULT", and SIG_C is set to "OPEN", indicating an "open control instruction" as a fail-safe setting for the electric window, regardless of a control signal from the central controller. This external communication packet SIG_C is sent to communication packet DO_1 via communication packet IO_3, and output to the window opening/closing device 53. The window opening/closing device 53 then executes the electric window opening operation process in the same manner as when an electric window opening control signal is received from the central controller 10.

As described above, according to this embodiment, the actuator connected to the hub device 30 is configured to execute a safe operation (fail-safe operation) based on abnormality detection (in this case, pinching) without being based on processing by the central controller 10. This allows a predetermined fail-safe operation to be executed even for processing that would be too late if the central controller 10 were to judge and process the input data from the sensor device. In other words, when an electric window is pinched, a safe operation of opening the window can be executed quickly. Furthermore, because the fail-safe processing can be set by simply changing the data area, the software design and verification processes can be simplified, and the software development man-hours can be significantly reduced.

The technology disclosed herein is not limited to the above-described embodiments, and may be substituted to the extent that does not deviate from the spirit of the claims. Furthermore, the above-described embodiments are merely examples, and should not be interpreted in a restrictive manner to the scope of this disclosure. The scope of this disclosure is defined by the claims, and all modifications and changes that fall within the scope of the claims are within the scope of this disclosure.

For example, in the operation example (2) of the in-vehicle equipment control device, the abnormality determination module performs fail-safe processing for a single actuator based on input information from a single sensor device, but this is not limited to the above. For example, the abnormality determination module may perform fail-safe processing for a single or multiple actuators based on input information from multiple sensor devices.

The technology disclosed here is extremely useful when configuring vehicle control led by a central controller.

20. In-vehicle equipment (in-vehicle devices)
30 Hub device (control unit)
400 Vehicle-mounted equipment control device (relay device)
430 Middleware layer 440 Device driver layer CN Vehicle network

Claims (1)

A relay device that relays communication between a central controller and an in-vehicle device in an in-vehicle network,
a control unit that outputs a control signal received from the central controller via the in-vehicle network to the in-vehicle device;
The control unit has a software configuration as follows:
a device driver layer including the hardware abstraction functions and these device drivers;
a middleware layer that is provided above the device driver layer and relays between the in-vehicle network and the device driver layer to set up a communication path therebetween;
The middleware layer includes:
When a specific abnormal state is detected, an abnormality process is executed to output a predetermined specific signal to the in-vehicle device regardless of the control signal received from the central controller ;
the in-vehicle device includes a sensor device and an actuator;
The control unit outputs the measurement data of the sensor device to the in-vehicle network and outputs the control signal from the central controller to the actuator;
The relay device is characterized in that the middleware layer determines that the specific abnormal state has been detected when a measurement value deviating from a predetermined threshold is input from the sensor device .

Images