JP7600785B2 - Information processing device - Google Patents

Description

The present invention relates to an information processing device.

In recent years, cloud computing has become more prevalent in embedded devices. In this regard, Patent Document 1 discloses a navigation device that acquires necessary data from a server device by communicating with a network.

JP 2004-309382 A

The present disclosure aims to provide an information processing device that can perform stable operation even when the communication environment changes.

A first aspect of the present disclosure is an information processing device that is configured to be able to select between acquiring software required for operation from a first device via a network and acquiring the software from a second device different from the first device, and that switches between acquiring the software from the first device and acquiring the software from the second device based on the communication environment between the device itself and the network.

Other aspects include a program for causing a computer to execute the method executed by the information processing device described above, or a computer-readable storage medium that non-temporarily stores the program.

This disclosure makes it possible to provide an information processing device that can perform stable operation even when the communication environment changes.

1 is a system configuration diagram of a vehicle system according to an embodiment. FIG. 2 is a block diagram showing components of a vehicle. FIG. 2 is a block diagram showing the logical configuration of a control unit and a storage unit included in the DCM. FIG. 2 is a diagram showing software patterns used by DCM. FIG. 2 is a block diagram showing components of a center server. FIG. 2 is a block diagram showing components of a user terminal. 1 is a flowchart of a process executed by a DCM.

One aspect of the present disclosure is an information processing device mounted on a moving object.
Specifically, the device is configured to be able to select between obtaining the software required for operation from a first device via a network and obtaining the software from a second device different from the first device, and is characterized in that it switches between obtaining the software from the first device or the second device based on the communication environment between the device itself and the network.

The information processing device may be, for example, a computer mounted on a moving body (such as a vehicle). The information processing device acquires software required for operation via a network. The software required for operation is typically a boot image, firmware, system files, etc., but may also include other software (such as application software, etc.).
By obtaining this software via the network, it is possible to always operate the device in the latest environment, and it is also possible to reduce local storage costs.

On the other hand, if a network connection is required to start up a device, problems such as boot failure may occur depending on the communication environment of the mobile device (e.g., the electric field strength in communication with a base station). Therefore, the information processing device disclosed herein makes it possible to selectively obtain software required for operation from multiple devices, and determines from which device to obtain the software based on the communication environment of the device itself.

For example, if software is placed on a server device on a wide area network and a device is in a communication environment where it is difficult to obtain the software via the network, the device connects to another device that is locally connected and obtains alternative software. In this way, by configuring the software to be obtainable from multiple different devices, it is possible to provide a cloud computing system that is resistant to changes in the communication environment.

The first device and the second device may be devices connected to the same network, or may be devices connected to different networks. Furthermore, the second device may be a locally connected device (local device) rather than a network connected device. A locally connected device may be a device connected to the device by wire, or may be a storage device built into the device.

In addition, the software provided by the first device and the software provided by the second device may be different from each other. For example, the software provided by the first device may provide all the designed functions, and the software provided by the second device may provide only a part of the designed functions (limited functions).

Embodiments of the present disclosure will be described below with reference to the drawings. The configurations of the following embodiments are examples, and the present disclosure is not limited to the configurations of the embodiments.

First Embodiment
An overview of a vehicle system according to a first embodiment will be described with reference to Fig. 1. The vehicle system according to this embodiment includes a vehicle 1, a center server 2, and a user terminal 3.

The vehicle 1 is a connected car having a communication function. The vehicle 1 includes an on-board terminal, a plurality of electronic control units (also referred to as ECUs), and a data communication module (DCM) 1 which is a computer that manages the plurality of electronic control units.
0.

The DCM 10 has a function of mediating communications inside and outside the vehicle and a function of executing various application software. In this embodiment, the DCM 10 has only the minimum necessary storage device, and obtains software required for the operation of the DCM 10 from the center server 2 via the network every time the system is started.

The center server 2 is a server device that manages the vehicle 1. The center server 2 stores software for operating the DCM 10 installed in the vehicle 1, and distributes the software via a network (e.g., a mobile communication network) in response to a request.

The user terminal 3 is a portable computer carried by the user of the vehicle 1. In this embodiment, the user terminal 3 is wirelessly connected to the DCM 10 in the vehicle cabin and functions as a backup device in case a problem occurs in communication between the vehicle 1 and the center server 2.

The components of the system will be explained in detail.
Fig. 2 is a block diagram showing an example of a hardware configuration of the vehicle 1 shown in Fig. 1. The vehicle 1 includes a DCM 10, an in-vehicle terminal 20, and a plurality of ECUs (ECU 30A, ECU 30B, ECU 30C, etc.). Examples of the plurality of ECUs included in the vehicle include an engine ECU, a body ECU, a powertrain ECU, and a hybrid ECU. Although Fig. 2 shows an example of a plurality of ECUs, these are collectively referred to as ECU 30 when there is no need to distinguish between them.

These components are interconnected by an in-vehicle network (CAN bus). In this embodiment, the vehicle 1 is equipped with a CAN bus 40, to which multiple ECUs are connected. The connected ECUs transmit and receive data to each other via the CAN bus 40. Note that while FIG. 2 illustrates an example of a single CAN bus, the vehicle 1 may have multiple CAN buses. These multiple CAN buses may be connected to each other using the DCM 10 as a gateway.

DCM10 functions as a device (communication module) that connects the components of vehicle 1 to a network. Through DCM10, the in-vehicle terminal 20 or multiple ECUs 30 of vehicle 1 can communicate with an external network.

In this embodiment, a mobile communication network and a local network are exemplified as external networks. The mobile communication network is a network for wireless communication with a computer (e.g., the center server 2) on a wide area network using mobile communication standards such as 3G, 4G (LTE), and 5G. The local network is a network for communication with a computer (e.g., the user terminal 3) in the vehicle cabin using wireless communication standards such as Wi-Fi (registered trademark) and Bluetooth (registered trademark). In this embodiment, the DCM 10 has a configuration that allows communication with both the mobile communication network and the local network.

DCM 10 is composed of a control unit 11, a memory unit 12, a communication unit 13A which is an interface for communicating with multiple CAN buses, and communication units 13B and 13C which are interfaces for communicating with an external network.

The DCM 10 can be configured as a computer having a processor such as a CPU (Central Processing Unit) or a GPU (Graphics Processing Unit), a main storage device such as a RAM or a ROM, and an auxiliary storage device such as an EPROM, a disk drive, or a removable medium. However, some or all of the functions may be realized by a hardware circuit such as an ASIC or an FPGA.

The control unit 11 is a computing unit (processor) that realizes various functions of the DCM 10 by executing predetermined programs.
The storage unit 12 is a memory device including a main storage device and an auxiliary storage device. The auxiliary storage device stores an operating system (OS), various programs, various tables, etc., and the programs stored therein can be loaded into the main storage device and executed to realize various functions that meet specific purposes, as described below.

The control unit 11 performs a function of mediating communication between an external network and components of the vehicle 1. For example, when the in-vehicle terminal 20 needs to communicate with an external network, the DCM 10 relays data transmitted from the in-vehicle terminal 20 to the external network. It also receives data transmitted from the external network and transfers the data to the in-vehicle terminal 20.

In addition, the control unit 11 can execute functions specific to the device itself. For example, the DCM 10 has a security system monitoring function, a call function, an emergency call function, etc., and can make security calls, emergency calls, etc. based on a trigger that occurs inside the vehicle.

The communication unit 13A is a communication interface that connects the DCM 10 to an in-vehicle network. The communication unit 13A executes a process of converting a message of a predetermined format generated by the control unit 11 into CAN data, and a process of converting received CAN data into a message of a predetermined format and transmitting the message to the control unit 11.
The communication units 13B and 13C are communication interfaces that connect the DCM 10 to an external network. The communication units 13B and 13C execute a process of converting a message of a predetermined format generated by the control unit 11 into a communication packet, and a process of converting a received communication packet into a message of the predetermined format and transmitting the message to the control unit 11.
The communication unit 13B connects to a mobile communication network, and the communication unit 13C connects to a local network. The functions of the communication units are the same, except for the communication destination.

FIG. 3 is a diagram showing the logical configuration of the control unit 11 and the storage unit 12. As shown in FIG.
The control unit 11 has, as functional modules, an OS execution unit 11A, a communication environment detection unit 11B, and a software acquisition unit 11C. Each functional module may be realized by executing a program stored in the storage unit 12 by a processor or the like.

The functional modules of the control unit 11 will be described.
The OS execution unit 11A executes an operating system. In this embodiment, the control unit 11 executes a predetermined operating system (OS) and executes application software on the OS, thereby providing various functions.
In this specification, the system software including the operating system executed by the control unit 11 is referred to as firmware.

The firmware required to start up the DCM 10 is configured so as to be obtainable from an external device.
The communication environment detection unit 11B and the software acquisition unit 11C execute a process of acquiring firmware from an external device when the device itself is started. Specifically, based on the communication environment detected by the communication environment detection unit 11B, the software acquisition unit 11C acquires firmware from an appropriate device.

The communication environment detection unit 11B detects the communication environment in which the DCM 10 is located. Specifically, the communication environment detection unit 11B measures the electric field strength of the radio waves used in the mobile communication network and the electric field strength of the radio waves used in the local network. The measurement results are transmitted to the software acquisition unit 11C.
The software acquisition unit 11C determines the device from which to acquire the software based on the measured electric field strength, and acquires the software. A specific method will be described later.

In the following explanation, the software acquired by DCM10 includes both firmware and application software.

The storage unit 12 stores first-type firmware. The first-type firmware is firmware that provides only the minimum necessary functions as a communication module, out of firmware that can be used by the DCM 10.
The first type firmware is lightweight but provides only the minimum functions required as a communication module (for example, an emergency call function, a security function, etc.).

Here, the types of software that can be used by the DCM 10 and the method of acquiring the software will be described.
4 is a diagram illustrating the difference between the types of software acquired by the DCM 10 and the functions provided. When only the first type firmware is available, the operating system executed by the control unit 11 provides only the minimum necessary functions. When only the second type firmware is available, the operating system executed by the control unit 11 provides all pre-designed functions. Furthermore, when application software is available, the control unit 11 can execute various software created by vendors in addition to the functions of the operating system.

In this embodiment, the center server 2 provides both the second type firmware and the application software, and the user terminal 3 provides only the second type firmware.

When DCM10 starts up, communication environment detection unit 11B judges whether the communication environment of the device is suitable for downloading software. Then, based on the result of this judgment, it decides from which device to acquire the software, and software acquisition unit 11C acquires the software.

Specifically, when the communication environment between the DCM 10's own device and the center server 2 is good, the software acquisition unit 11C acquires the second type firmware and application software from the center server 2. When the communication environment between the DCM 10's own device and the center server 2 is not good, the software acquisition unit 11C acquires only the second type firmware from the user terminal 3. When communication with the user terminal 3 is also not possible, the DCM 10 starts up the system using the first type firmware stored in the DCM 10's own device. This makes it possible to slim down the storage device and provide a variety of functions.
The communication environment detection unit 11B and the software acquisition unit 11C are configured to be able to operate independently of the operating system.

Returning to FIG. 2, the explanation will be continued.
The in-vehicle terminal 20 is an information terminal mounted on the vehicle 1. The in-vehicle terminal 20 is also called an infotainment terminal, and has a function of providing information (e.g., traffic information and route guidance) and entertainment (e.g., music and videos) to the vehicle occupants.

The ECUs (ECU 30A, ECU 30B, etc.) are electronic control units that control the vehicle. The vehicle 1 may have multiple ECUs, such as an engine ECU, a body ECU, a powertrain ECU, and a hybrid ECU, each of which manages multiple vehicle components.

The CAN bus 40 is a communication bus that constitutes an in-vehicle network based on the CAN (Controller Area Network) protocol. In this example, a single CAN bus 40 is illustrated, but the in-vehicle network may have two or more communication buses. In this case, the multiple CAN buses may be connected to each other by the DCM 10.

Next, the center server 2 will be described.
The center server 2 is a device that provides software to the DCM 10 included in the vehicle 1. The center server 2 can transmit and receive data to and from a plurality of vehicles via wireless communication.

The center server 2 can be configured as a general-purpose computer. That is, the center server 2 can be configured as a computer having a processor such as a CPU or GPU, a main memory such as a RAM or ROM, and an auxiliary memory such as an EPROM, a hard disk drive, or a removable media. The auxiliary memory stores an operating system (OS), various programs, various tables, etc., and by executing the programs stored therein, various functions that match a specific purpose, as described below, can be realized. However, some or all of the functions may be realized by hardware circuits such as an ASIC or FPGA.

FIG. 5 is a block diagram showing an example of the configuration of the center server 2 shown in FIG.
The center server 2 is configured to include a control unit 21, a storage unit 22, and a communication unit 23.

The control unit 21 is a unit that controls the center server 2. The control unit 21 is configured with an information processing unit such as a central processing unit (CPU) and a graphics processing unit (GPU), for example.
The control unit 21 has a distribution unit 211 as a functional module. The functional module may be realized by causing a CPU to execute a program stored in a storage unit such as a ROM.

The distribution unit 211 distributes software required for the operation of the DCM 10 online in response to a request from the vehicle 1 (DCM 10) under its management.

The storage unit 22 is a means for storing information, and is composed of storage media such as RAM, a magnetic disk, and a flash memory. The storage unit 22 stores various programs executed by the control unit 21, data used by the programs, and the like. The storage unit 22 also stores software (second type firmware and application software) to be distributed to the DCM 10.

As described above, the second type firmware is firmware that allows the use of all the functions of the operating system. The storage unit 22 may store a plurality of second type firmware according to the type of the DCM 10 (e.g., according to the operating system).
The storage unit 22 also stores a set of application software executed by the DCM 10. The storage unit 22 may store a plurality of application software and provide a combination of a plurality of application software for each type of DCM 10 and/or each vehicle.

The communication unit 23 is an interface for connecting the center server 2 to a network. The communication unit 23 can communicate with the DCM 10 (communication unit 13B) of the vehicle 1 via, for example, the Internet or a mobile communication network.

Next, the user terminal 3 will be described.
The user terminal 3 is a small computer carried by the user of the vehicle 1. The user terminal 3 stores software (second type firmware) used by the DCM 10, and provides the second type firmware to the DCM 10 on behalf of the center server 2 when a failure occurs in communication between the DCM 10 and the center server 2.

The user terminal 3 functions as a backup for the center server 2. For this reason, the user terminal 3 has a function of acquiring and storing the latest type-2 firmware from the center server 2. The user terminal 3 may have a function of, for example, periodically inquiring the center server 2 and, if the type-2 firmware has been updated, downloading it and storing it in the memory unit. However, since this requires management costs, the user terminal 3 does not manage or provide application software.

The user terminal 3 can be configured as a general-purpose computer, similar to the center server 2. In other words, the center server 2 can be configured as a computer having a processor such as a CPU or GPU, a main memory device such as a RAM or ROM, and an auxiliary memory device such as an EPROM, a hard disk drive, or a removable media.

FIG. 6 is a block diagram showing an example of a configuration of the user terminal 3 shown in FIG.
The user terminal 3 is configured to include a control unit 31 , a storage unit 32 , and a communication unit 33 .

The control unit 31 is a unit that controls the user terminal 3. The control unit 31 is configured with an information processing unit such as a CPU (Central Processing Unit) and a GPU (Graphics Processing Unit), for example.
The control unit 31 has a distribution unit 311 as a functional module. The functional module may be realized by causing a CPU to execute a program stored in a storage unit such as a ROM.

The distribution unit 311 distributes software required for the operation of the DCM 10 in response to a request from the vehicle 1 (DCM 10) under its management, but differs from the distribution unit 211 in that it distributes only the second type firmware.

The memory unit 32 is a means for storing information. The memory unit 32 has a similar configuration to the memory unit 22, but differs from the memory unit 22 in that it does not store application software.

The communication unit 33 is an interface for connecting the user terminal 3 to a network. The communication unit 33 can communicate with the DCM 10 (communication unit 13C) of the vehicle 1, for example, via any wireless connection standard.

Next, the processing performed by DCM10 will be described. The processing performed by DCM10 can be broadly divided into processing for downloading software required for operation at startup (first processing), and processing for starting the operating system and providing services (second processing).

7 is a flowchart illustrating a first process. The process shown in the figure is executed by the control unit 11 when the system power supply of the vehicle 1 is turned on.
First, in step S11, the communication environment detection unit 11B evaluates the communication environment of the mobile communication network. The communication environment may be evaluated based on, for example, the electric field strength of the wireless radio waves used by the communication unit 13B, or based on the communication speed when communicating with the center server 2.

In step S12, it is determined whether communication using the mobile communication network can be performed satisfactorily. If the current communication environment is evaluated as not suitable for software transfer (for example, if the electric field strength is below a predetermined value or the effective communication speed is below a predetermined value), the process proceeds to step S15. If the current communication environment is evaluated as suitable for software transfer, the process proceeds to step S13.

In step S13, the software acquisition unit 11C acquires (downloads) the second type firmware and application software from the center server 2.
When the download is complete, the process is handed over to the OS execution unit 11A, which starts the system by using the downloaded second type firmware to start the second process (step S14). This allows the operating system to operate with all functions available. In addition, application software that runs on the operating system can be used.

If the determination in step S12 is negative, in step S15, the communication environment detection unit 11B evaluates the communication environment of the local network. The communication environment may be evaluated, for example, based on the electric field strength of the wireless radio waves used by the communication unit 13C, or based on the communication speed when communicating with the user terminal 3. It may also be evaluated based on whether or not a wireless connection with the user terminal 3 is possible.

In step S16, it is determined whether communication using the local network can be performed satisfactorily. If the current communication environment is evaluated as not suitable for software transfer (including a case where connection to the user terminal 3 is not possible), the process proceeds to step S18. If the current communication environment is evaluated as suitable for software transfer, the process proceeds to step S17.

In step S<b>17 , the software acquisition unit 11</b>C acquires (downloads) the second type firmware from the user terminal 3 .
When the download is complete, the process is handed over to the OS execution unit 11A, which starts the system by using the downloaded second type firmware to start the second process (step S14). This allows the operating system to operate with all functions available.
On the other hand, if the determination in step S16 is negative, in step S18, the software acquisition unit 11C acquires the first type firmware stored in the storage unit 12. When the acquisition is completed, the process is handed over to the OS execution unit 11A, which starts the system using the first type firmware to start the second process (step S14). This starts the operation of the operating system with limited functions.

Thus, in the first embodiment, DCM 10 selects, based on the communication environment with the center server 2, whether to obtain the software required for operation from the center server 2, whether to obtain it from the user terminal 3, or whether not to obtain the software.
If communication with the center server 2 is good, the second type firmware and application software become available. If communication with the center server 2 is not good, communication with the user terminal 3 is attempted as a backup means. Here, if communication with the user terminal 3 is good, only the second type firmware becomes available. If good communication with both the center server 2 and the user terminal 3 is not possible, the DCM 10 starts up the system using the stored first type firmware.
According to this configuration, when a suitable communication environment is not available, it is possible to boot up the device with limited functions.

If the storage capacity of DCM10 is reduced and all software is configured to be obtained from a center server, booting up the DCM becomes impossible if an abnormality occurs in communication with the mobile communication network (for example, if the vehicle is outside the communication service area). On the other hand, according to the first embodiment, the source from which the software is obtained can be dynamically switched based on the communication environment, so that even if an abnormality occurs in communication with some networks, it is possible to boot up the device while maintaining the minimum necessary functions.

(Modification of the first embodiment)
In the first embodiment, a plurality of devices provide software via different networks, but the same device may provide software via different networks. For example, the center server 2 may be configured to communicate via a mobile communication network (first network) and a wireless LAN network (second network). When the DCM 10 determines that the communication quality in the first network is insufficient, the DCM 10 may switch the communication line and acquire the software via the second network.

In the first embodiment, the user terminal 3 stores only the second type firmware, but the software stored in the center server 2 and the software stored in the user terminal 3 may be the same.

In the first embodiment, the user terminal 3 provides firmware in place of the center server 2, but other devices may also replace the center server 2. For example, the vehicle-mounted terminal 20 may be made to play the role of the user terminal 3 in the first embodiment. In this case, the vehicle-mounted terminal 20 may, for example, periodically inquire the center server 2, and if the second type firmware has been updated, download and store it. In addition, any online storage may replace the center server 2.

In addition, when the DCM 10 boots up with restrictions, after the operating system starts up, the communication environment may be periodically monitored, and software may be acquired when communication with the center server 2 (or the user terminal 3) is restored.
In this case, for example, a system started with the first type firmware may be restarted using the second type firmware. Also, application software may be added to a system started with the second type firmware. This makes it possible to recover functions while the system is still running.

(Other Modifications)
The above-described embodiment is merely an example, and the present invention can be modified and implemented as appropriate without departing from the scope of the present invention.
For example, the processes and means described in this disclosure can be freely combined and implemented as long as no technical contradiction occurs.

In addition, a process described as being performed by one device may be shared and executed by multiple devices. Or, a process described as being performed by different devices may be executed by one device. In a computer system, the hardware configuration (server configuration) by which each function is realized can be flexibly changed.

The present disclosure can also be realized by supplying a computer program that implements the functions described in the above embodiments to a computer, and having one or more processors of the computer read and execute the program. Such a computer program may be provided to the computer by a non-transitory computer-readable storage medium that can be connected to the system bus of the computer, or may be provided to the computer via a network. Non-transitory computer-readable storage media include, for example, any type of disk, such as a magnetic disk (floppy disk, hard disk drive (HDD), etc.), an optical disk (CD-ROM, DVD disk, Blu-ray disk, etc.), a read-only memory (ROM), a random access memory (RAM), an EPROM, an EEPROM, a magnetic card, a flash memory, an optical card, or any type of medium suitable for storing electronic instructions.

Reference Signs List 1 vehicle 2 center server 3 user terminal 10 DCM
REFERENCE SIGNS LIST 11: Control unit 12: Storage unit 13: Communication unit 20: In-vehicle terminal 30: ECU
21, 31: control unit; 22, 32: storage unit; 23, 33: communication unit

Claims (1)

A storage unit that stores the first type firmware, and
A control unit is provided.
An information processing device,
The control unit is
acquiring the second type firmware and the application software from the first device via the wide area network when the communication environment of the wide area network is good ;
When the communication environment of the wide area network is not good and the communication environment of the local network is good, acquiring the second type firmware from a second device different from the first device via the local network; and
When a communication environment of the wide area network and the local network is not good, the first type firmware is acquired from the storage unit;
Run
The first type firmware is configured to have a smaller amount of data than the second type firmware, in exchange for restricting some functions of the operating system.
Information processing device.

Images