JP6993870B2 - Server device and in-vehicle device deployment management method - Google Patents

Description

The present invention relates to a technique of a server device and an in-vehicle device deployment management method.

"A control system that controls a plurality of in-vehicle devices mounted on a vehicle. The control system is divided into a plurality of domains in advance according to the functions of the plurality of in-vehicle devices, and the control system is divided into a plurality of domains, respectively. The device control unit for controlling the in-vehicle device and the domain control unit for controlling the device control unit are layered, and the control system is positioned above each domain control unit of the plurality of domains. , Each domain control unit is provided with an integrated control unit, and at least the integrated control unit and the domain control unit have information on their own control function and control of their own lower control unit as configuration information of the control system. Patent Document 1 describes a technique relating to "a control system configured to possess information related to a function and having the configuration information of the control system distributed between the integrated control unit and the domain control unit." Are listed.

Japanese Unexamined Patent Publication No. 2017-061278

In the above-mentioned technology, change management related to information control between in-vehicle devices is performed, but deployment management of in-vehicle devices is not considered. When managing a large number of commercial vehicles, there is a demand for vehicle failure management, in-vehicle device failure management, and in-vehicle device mounting destination management, but this requires complicated management information input operations. In many cases, management omissions and mistakes occur frequently, and problems such as loss of the removed in-vehicle device tend to occur.

An object of the present invention is to provide a server device and an in-vehicle device deployment management method that do not require complicated management information input operations.

The present invention includes a plurality of means for solving at least a part of the above problems, and examples thereof are as follows. In order to solve the above problems, the server device according to the present invention has a storage unit and a communication unit that store vehicle state information that specifies the usage state of the vehicle and vehicle state information that specifies the usage state of the vehicle-mounted device. The notification receiving unit that receives the vehicle identification information and the vehicle-mounted device identification information associated with the vehicle identification information from an external device via the communication unit, and the vehicle-mounted device. A state estimation unit that estimates the usage state of the vehicle and the in-vehicle device according to the communication history, and a state that creates the vehicle state information and the in-vehicle device state information according to the usage state estimated by the state estimation unit. It is characterized by including an information creating unit and a state information updating unit that stores the vehicle state information and the vehicle-mounted device state information in the storage unit.

According to the present invention, it is possible to provide a server device and an in-vehicle device deployment management method that do not require complicated management information input operations. Issues, configurations and effects other than those described above will be clarified by the description of the following embodiments.

It is a figure which shows the structure of the in-vehicle device deployment management system to which the embodiment which concerns on this invention is applied. It is a figure which shows the hardware structure example of an in-vehicle device. It is a figure which shows the hardware structure example of a server apparatus. It is a figure which shows the data structure example of the vehicle state information. It is a figure which shows the example of the data structure of the in-vehicle device state information. It is a figure which shows the example of the data structure of the state transition table. It is a figure which shows the flow of the process at the time of mounting an in-vehicle device. It is a figure which shows the flow of a state determination process. It is a figure which shows the example of the state confirmation screen.

Hereinafter, an in-vehicle device deployment management system including an in-vehicle device, a server device, and a management terminal according to the present invention will be described with reference to the drawings. It should be noted that FIGS. 1 to 9 do not show all the configurations of the on-board unit deployment management system 1, and for the sake of easy understanding, some of the configurations are omitted as appropriate. In addition, in all the drawings for explaining the embodiment, in principle, the same members are designated by the same reference numerals, and the repeated description thereof may be omitted. Further, in the following embodiments, the constituent elements (including element steps and the like) are not necessarily essential unless otherwise specified or clearly considered to be essential in principle. Needless to say. In addition, when saying "consisting of A", "consisting of A", "having A", and "including A", other elements are excluded unless it is clearly stated that it is only that element. It goes without saying that it is not something to do. Similarly, in the following embodiments, when the shape, positional relationship, etc. of the constituent elements are referred to, the shape is substantially the same, except when it is clearly stated or when it is considered that it is not clearly the case in principle. Etc., etc. shall be included.

FIG. 1 shows a structure of an in-vehicle device deployment management system to which an embodiment of the present invention is applied. In the vehicle-mounted device deployment management system 1 to which the embodiment of the present invention is applied, control by application software is included as a part of control of the vehicle-mounted device 100, the management terminal 200, and the server device 300 serving as the management server. Further, in the in-vehicle device 100, the function of the application software is realized by controlling the hardware by an application software program that operates under the control of the OS (Operating System) of the in-vehicle device 100. On the other hand, in the management terminal 200 and the server device 300, the functions of the application software are realized by controlling the hardware by the application software program that operates under the control of the OS and the like of the management terminal 200 and the server device 300. do.

The on-board unit 100 is an information processing device mounted on a vehicle and capable of executing various software. In the present embodiment, the in-vehicle device 100 is provided with an OS, and contents such as a plurality of software can be used in a web browser or the like, and contents such as application software can be executed in parallel. However, the present invention is not limited to this, and may be realized by hardware such as ASIC (Application Specific Integrated Circuit). However, the in-vehicle device 100 is not limited to a dedicated device used in an in-vehicle state, and may be various independently operable devices such as a personal computer, a smartphone, and a tablet terminal.

The vehicle-mounted device 100 includes a storage unit 110, a control unit 120, a communication unit 130, a touch panel 140, and a display 150. The storage unit 110 includes on-board vehicle information 111 and on-board unit identification information 112. The control unit 120 includes a processing unit of an input control unit 121, a screen control unit 122, a use start processing unit 123, a vehicle control processing unit 124, and an alive notification unit 125.

The mounted vehicle information 111 includes information for identifying a vehicle on which the vehicle-mounted device 100 is mounted. Specifically, the mounted vehicle information 111 includes the license plate of the vehicle on which the vehicle-mounted device 100 is mounted, the chassis number, and other registered identifiable numbers. The mounted vehicle information 111 may include information such as a vehicle type and an introduction date, but it is not always necessary.

The on-board unit identification information 112 includes identification information that can distinguish the on-board unit 100 from other on-board units. Specifically, the vehicle-mounted device identification information 112 includes a serial number unique to the vehicle-mounted device 100 and other registered identifiable numbers. The on-board unit identification information 112 may include information such as a model number and an introduction date, but it is not always necessary.

The input control unit 121 accepts input from the touch panel 140 or a hardware key (not shown). The screen control unit 122 controls the screen display on the display 150. The use start processing unit 123 performs processing at the time of mounting the in-vehicle device, which will be described later. Specifically, it receives the identification information of the vehicle to be attached and requests the server device 300 to associate the vehicle-mounted device with the vehicle.

The vehicle control processing unit 124 is responsible for the control processing of the attached vehicle or a part thereof. For example, the vehicle control processing unit 124 performs auxiliary processing for automatic driving of the vehicle and guides the traveling route. Alternatively, the vehicle control processing unit 124 carries out auxiliary processing for brake control.

The alive notification unit 125 transmits predetermined alive information to the server device 300 via the communication unit 130 when the vehicle-mounted device 100 is started. The alive information includes information for identifying the vehicle-mounted device 100 (vehicle-mounted device identification information 112).

The communication unit 130 communicates with the server device 300 via a mobile phone network (LTE: Long Term Evolution), a wireless LAN (WiFi: registered trademark), or the like. The touch panel 140 can specify the position on the touch-input panel by using an electrostatic or pressure-sensitive sensor. The display 150 is a display device such as an organic EL (Electroluminescence) or a liquid crystal display. By incorporating the touch panel 140 on the display 150, it is possible to detect a touch input to a display object on the display screen.

The server device 300 is communicably connected to the vehicle-mounted device 100 and the management terminal 200 via a network such as the Internet. The server device 300 is a so-called computer server device, and includes a storage unit 310, a control unit 320, and a communication unit 330.

The storage unit 310 stores the vehicle state information 311, the on-board unit state information 312, and the state transition table 313. The control unit 320 includes a usage start notification receiving unit 321, an alive notification receiving unit 322, a state estimation unit 323, a state information creating unit 324, a state information updating unit 325, and a management service unit 326. ..

FIG. 4 is a diagram showing an example of a data structure of vehicle state information. The vehicle state information 311 includes a vehicle identifier 311a, an on-board unit identifier 311b, a state 311c, a final communication date 311d, and a state update date 311e.

The vehicle identifier 311a is information for identifying the vehicle on which the vehicle-mounted device 100 is mounted. The vehicle-mounted device identifier 311b is information for identifying the vehicle-mounted device 100 mounted on the vehicle specified by the vehicle identifier 311a. The state 311c is information indicating the state of use of the vehicle. For example, the state 311c is information that distinguishes the usage status according to the status such as "normal operation" and "vehicle failure estimation". The final communication date 311d is information for specifying the date of the last communication (including alive notification) from the vehicle-mounted device 100 mounted on the vehicle. The state update date 311e is information for specifying the date when the state of the vehicle was last updated.

FIG. 5 is a diagram showing an example of a data structure of vehicle-mounted device state information. The on-board unit state information 312 includes the on-board unit identifier 312a, the state 312b, the last communication date 312c, and the state update date 312d.

The vehicle-mounted device identifier 312a is information for identifying the vehicle-mounted device 100. The state 312b is information indicating the state of use of the vehicle-mounted device 100. For example, the state 312b is "normal operation", "state confirmation required", "removal", "repairing", "repair completed", etc., or as an estimated state, "stored item (not in use state, in-vehicle device repair). It is information that distinguishes the usage status according to the status such as "the item in the storage state held by the person)" and "the spare part (the item in the spare state held by the vehicle owner, not in the used state)". The final communication date 312c is information for specifying the date of the last communication (including alive notification) from the vehicle-mounted device 100. The state update date 312d is information for specifying the date when the state of the in-vehicle device was last updated.

FIG. 6 is a diagram showing an example of the data structure of the state transition table. The state transition table 313 mainly has the state 313a of the in-vehicle device on the vertical axis and the generated event (313b to 313f) on the horizontal axis, and what kind of event occurs in what state and what kind of state transitions to. That is, it is information expressing a combination of state changes on a matrix. The state transition table 313 is not limited to such a data structure and may be another data structure, but in this embodiment, it is stored in the form of the table shown in FIG.

Events include communication 313b, non-delivery deadline 313c, installation of another on-board unit on the vehicle 313d, repair input 313e, and repair completion input 313f. The event "with communication" 313b is when some communication such as registration request for start of use, alive notification, and other communication for normal use is made to the server device 300 within a predetermined period (for example, within 1 business day). Applicable.

In the event "non-delivery deadline" 313c, any communication including registration request for start of use, alive notification, and other communication for normal use is made to the server device 300 within the predetermined non-delivery deadline (for example, within 5 business days). It corresponds to the case where it is not (that is, when it is in a non-communication state).

The event "There is another in-vehicle device attached to the attached vehicle" 313d is a case where a registration request for start of use is made for a vehicle already associated with the in-vehicle device 100, and the in-vehicle device is different from the in-vehicle device 100. Corresponds to the case of a registration request for mapping. The event "with repair input" 313e corresponds to the case where the in-vehicle device 100 receives an input from the management terminal 200 that it is in a repair state. The event "with repair completion input" 313f corresponds to the case where the in-vehicle device 100 receives an input indicating that the repair has been completed from the management terminal 200.

For example, in FIG. 6, when the event of "passing the deadline" 313c occurs in the "normal operation" state, the state of the in-vehicle device 100 changes to the state of "state confirmation required" which is the intersection of the two. Shows. In addition, even if the event of "passing the deadline" 313c occurs in "under repair", the state is "-", that is, the state does not change (the state is maintained as "under repair").

Further, for example, in the "normal operation" state, when the event of "another in-vehicle device is attached to the attached vehicle" 313d occurs, that is, when a registration request for association with another in-vehicle device is received, the original in-vehicle device is received. The machine 100 transitions to the "removed" state. In normal operation, in such a case, "removal" due to the failure of the in-vehicle device is assumed, so that the failure of the in-vehicle device is estimated during the period of interruption immediately before that.

The use start notification receiving unit 321 of the control unit 320 receives the registration request notified in the in-vehicle device mounting time processing and reflects it in the vehicle state information 311 and the in-vehicle device state information 312. The alive notification receiving unit 322 receives the alive notification notified by the alive notification unit 125 of the vehicle-mounted device 100, and updates the final communication date of the vehicle status information 311 and the vehicle-mounted device status information 312.

The state estimation unit 323 estimates the usage state of the vehicle and the vehicle-mounted device 100 according to the communication history from the vehicle-mounted device 100. Specifically, the state estimation unit 323 reads out the vehicle state information 311, the vehicle-mounted device state information 312, and the state transition table 313, and detects the occurrence of an event based on the communication history from the vehicle-mounted device 100. , The state of the transition destination corresponding to the state transition table 313 is specified according to the state and the event that has occurred, and the states of the on-board unit and the vehicle are estimated.

Based on the estimation of the current state and the past state estimated by the state estimation unit 323, the state information creation unit 324 provides vehicle state information 311 and on-board unit state information 312 according to the state including the period of the state and the like. Generates the given information for updating.

The state information update unit 325 updates the vehicle state information 311 and the on-board unit state information 312 by using the predetermined information created by the state information creation unit 324.

The management service unit 326 generates and returns the information on the response screen in response to the reference request of the vehicle status information 311 and the vehicle-mounted device status information 312 from the management terminal 200. Specifically, the management service unit 326 accepts the input of the vehicle identifier and returns the information on the vehicle status and the screen information for displaying the status information of the mounted on-board unit to the management terminal 200. Further, the screen for accepting manual input regarding the change in the state of the vehicle or the in-vehicle device is returned to the management terminal 200, and each state information is updated using the input state information.

The communication unit 330 communicates with the in-vehicle device 100 and the management terminal 200 via a mobile phone network (LTE: Long Term Evolution), a wireless LAN (WiFi: registered trademark), or the like.

The management terminal 200 is communicably connected to the server device 300 via a network such as the Internet. The management terminal 200 is a so-called computer device, and includes at least a control unit 220 and a communication unit 230.

The control unit 220 includes a state information presentation unit 221, a state information update unit 222, an input control unit 223, and a screen control unit 224. The state information presenting unit 221 requests the server device 300 for the state information of the vehicle and the on-board unit, generates an output screen for presenting the received state information, and outputs the output screen from the screen control unit 224.

When the state information update unit 222 receives an update input when there is an update regarding the state of the vehicle or the in-vehicle device, the state information update unit 222 sends the update to the server device 300 and requests the state information update unit 325 to update the state of the vehicle or the in-vehicle device. do.

The input control unit 223 accepts input / output from hardware keys and displays (not shown). The screen control unit 224 controls the screen display on the display. The communication unit 230 communicates with the in-vehicle device 100 and the server device 300 via a mobile phone network, a wireless LAN (WiFi: registered trademark), or the like.

FIG. 2 is a diagram showing an example of the hardware structure of the in-vehicle device. The vehicle-mounted device 100 includes an input receiving device 101, an arithmetic unit 102, a communication device 103, a main storage device 104, an external storage device 105, a display device 106, and a bus 109 connecting them. To.

The input receiving device 101 is various input devices such as hardware buttons and a touch panel. The arithmetic unit 102 is, for example, an arithmetic unit such as a CPU (Central Processing Unit).

The communication device 103 is a device such as a network module that establishes a communication path with another device and transmits / receives information via a mobile phone network, a wireless network, or the like.

The main storage device 104 is, for example, a memory device such as a RAM (Random Access Memory).

The external storage device 105 is a device that writes information to, for example, a hard disk, SSD (Solid State Drive), or other various non-volatile storage media, or reads predetermined information from the non-volatile storage medium.

The display device 106 is a device that outputs a display such as a liquid crystal display or an organic EL (Electroluminescence) display.

Each function unit of the control unit 120 described above, that is, the input control unit 121, the screen control unit 122, the use start processing unit 123, the vehicle control processing unit 124, and the alive notification unit 125, the arithmetic unit 102 reads and executes a predetermined program. It is built by. Therefore, the main storage device 104 stores a program for realizing the processing of each functional unit.

The storage unit 110 described above is the main storage device 104 or the external storage device 105, the touch panel 140 is the input reception device 101, the display 150 is the display device 106, and the communication unit 130 is the communication device 103. It will be realized.

It should be noted that each of the above-mentioned components is a classification of the configuration of the vehicle-mounted device 100 according to the main processing contents in order to facilitate understanding. Therefore, the invention of the present application is not limited by the method of classifying the components and the name thereof. The configuration of the vehicle-mounted device 100 can be further classified into more components according to the processing content. It can also be categorized so that one component performs more processing.

Further, each functional unit of the control unit 120 is not limited to the CPU, and may be constructed by hardware (ASIC, GPU (Graphics Processing Unit), etc.). Further, the processing of each functional unit may be executed by one hardware or may be executed by a plurality of hardware.

FIG. 3 is a diagram showing an example of the hardware structure of the server device 300. The server device 300 includes an input receiving device 301, an arithmetic unit 302, a communication device 303, a main storage device 304, an external storage device 305, a display device 306, and a bus 309 connecting them. To.

The input receiving device 301 is various input devices such as hardware buttons and a touch panel. The arithmetic unit 302 is, for example, an arithmetic unit such as a CPU.

The communication device 303 is a device such as a network module that establishes a communication path with another device and transmits / receives information via a mobile phone network, a wireless network, or the like.

The main storage device 304 is a memory device such as a RAM.

The external storage device 305 is a device that writes information to, for example, a hard disk, SSD, or other various non-volatile storage media, or reads predetermined information from the non-volatile storage medium.

The display device 306 is a device that outputs a display such as a liquid crystal display or an organic EL display.

Each functional unit of the control unit 320 described above, that is, the usage start notification receiving unit 321, the alive notification receiving unit 322, the state estimation unit 323, the state information creating unit 324, the state information updating unit 325, and the management service unit 326 are the arithmetic units 302. Is constructed by reading and executing a predetermined program. Therefore, the main storage device 304 stores a program for realizing the processing of each functional unit.

Further, the storage unit 310 described above is realized by the main storage device 304 or the external storage device 305, and the communication unit 330 is realized by the communication device 303.

It should be noted that each of the above-mentioned components is a classification of the configuration of the server device 300 according to the main processing contents in order to facilitate understanding. Therefore, the invention of the present application is not limited by the method of classifying the components and the name thereof. The configuration of the server device 300 can be further classified into more components according to the processing content. It can also be categorized so that one component performs more processing.

Further, each functional unit of the control unit 320 is not limited to the CPU and may be constructed by hardware. Further, the processing of each functional unit may be executed by one hardware or may be executed by a plurality of hardware. The management terminal 200 also has basically the same hardware configuration as the server device 300.

[Explanation of operation] Next, the operation related to the processing at the time of mounting the in-vehicle device will be described. FIG. 7 is a diagram showing a flow of processing when the on-board unit is attached. The process at the time of mounting the vehicle-mounted device is started at the first time when the vehicle-mounted device 100 is mounted on the vehicle, and after the mounting, at the first startup of the vehicle-mounted device 100.

First, the usage start processing unit 123 determines whether or not the vehicle identifier setting input has been accepted (step S001). Specifically, the use start processing unit 123 displays a predetermined setting input screen for accepting the input of the vehicle identifier for the vehicle on which the on-board unit 100 is mounted, and accepts the input. Then, the usage start processing unit 123 determines whether or not the input has been accepted. When the usage start processing unit 123 does not accept the setting input of the vehicle identifier (in the case of "No" in step S001), the in-vehicle device mounting time processing is terminated.

When the vehicle identifier setting input is accepted (in the case of "Yes" in step S001), the use start processing unit 123 stores the vehicle identifier in the mounted vehicle information 111 (step S002).

Then, the usage start processing unit 123 transmits a registration request including the vehicle identifier and the vehicle-mounted device identifier to the server device 300 (step S003). Specifically, the usage start processing unit 123 reads the vehicle identifier from the mounted vehicle information 111, reads the vehicle-mounted device identification information from the vehicle-mounted device identification information 112, generates predetermined registration request information including both, and generates the server device 300. Send to.

The usage start notification receiving unit 321 receives the registration request including the vehicle identifier and the vehicle-mounted device identifier, and reflects the registration request in the vehicle status information (step S004). Specifically, the usage start notification receiving unit 321 receives a registration request including a vehicle identifier and an in-vehicle device identifier, stores the received vehicle identifier in the vehicle identifier 311a of the vehicle status information 311, and corresponds to the in-vehicle device identifier. The in-vehicle device identifier received is stored in 311b, and the immediately preceding in-vehicle device identifier is saved in the buffer. Then, the usage start notification receiving unit 321 stores information for specifying the date at the time of processing in the final communication date 311d and the state update date 311e, respectively.

Then, the use start notification receiving unit 321 determines whether or not there is a change from the on-board unit identifier immediately before associated with the vehicle identifier (step S005). Specifically, the usage start notification receiving unit 321 compares the vehicle-mounted device identifier saved in the buffer in step S004 with the vehicle identifier received in step S004, and determines whether or not there is a change. If there is no change (in the case of "No" in step S005), the usage start notification receiving unit 321 clears the buffer and ends the processing on the server device side.

When there is a change (in the case of "Yes" in step S006), the state estimation unit 323 estimates that the state of the original in-vehicle device is "removed" and the state of the new in-vehicle device is "normal operation". It is reflected in the in-vehicle device status information (step S006). Specifically, the state estimation unit 323 estimates that the state of the original in-vehicle device is "removed" for the in-vehicle device associated with the in-vehicle device identifier saved in the buffer. Then, based on the estimation, the state information creation unit 324 stores the in-vehicle device identifier in the in-vehicle device identifier 312a of the in-vehicle device state information 312, stores the "removal" in the state 312b, and updates the state on the final communication date 312c. Information for specifying the date at the time of processing is created on the day 312d. Further, the state estimation unit 323 stores the in-vehicle device identifier in the in-vehicle device identifier 312a of the in-vehicle device state information 312 and stores the "normal operation" in the state 312b for the in-vehicle device associated with the new in-vehicle device identifier. Then, information for specifying the date at the time of processing is created on the last communication date 312c and the status update date 312d, respectively. Then, the state information update unit 325 updates the on-board unit state information 312 using the created information.

The above is the flow of processing when installing the in-vehicle device. According to the in-vehicle device mounting time processing, the association with the vehicle is stored by mounting the in-vehicle device. Further, when the conventionally attached in-vehicle device is replaced, the state of the conventionally attached in-vehicle device can be recorded as "removal" without requiring any special input work.

FIG. 8 is a diagram showing the flow of the state determination process. The state determination process is started each time the alive notification receiving unit 322 receives the notification from the alive notification unit 125, or periodically (for example, once a day).

First, the state estimation unit 323 selects an unprocessed in-vehicle device (step S101). Specifically, the state estimation unit 323 identifies one unprocessed in-vehicle device with reference to the in-vehicle device identifier 312a of the in-vehicle device state information 312.

Then, the state estimation unit 323 determines whether or not the on-board unit can communicate at less than a predetermined interval (step S102). Specifically, the state estimation unit 323 determines whether or not the vehicle-mounted device state information 312 of the vehicle-mounted device selected in step S101 is within a predetermined period from the processing time point with reference to the final communication date 312c. If it is within a predetermined period (in the case of "Yes" in step S102), the state estimation unit 323 determines that the on-board unit is communicating within a predetermined interval, and proceeds to control to step S103.

The state estimation unit 323 acquires the current state (latest state) of the in-vehicle device (step S103). Specifically, the state estimation unit 323 reads the latest state 312b related to the vehicle-mounted device selected in step S101 with reference to the vehicle-mounted device state information 312, and sets the current state.

Then, the state estimation unit 323 transitions from the current state to the state corresponding to the event “with communication” (step S104). Specifically, the state estimation unit 323 refers to the state transition table 313 and specifies the state corresponding to the case where the event “with communication” 313b occurs from the current state 313a which is the current state acquired in step S103. , This is estimated as the state of the vehicle and the on-board unit 100. In addition to estimating the state of the in-vehicle device 100, in the case of a combination in which the state of the vehicle can be estimated, the state of the vehicle is also included in the state transition table 313, so that the state of the vehicle and the in-vehicle device 100 can be determined. Estimates and transitions are possible.

Then, the state information creation unit 324 is based on the estimation of the state estimation unit 323, and the information for changing the state information for each state of the vehicle state and the in-vehicle device state (for example, the in-vehicle device identifier and its own). Create a vehicle identifier and its state, information that identifies the start and end, etc., such as the state, start and end, etc.). Then, the state information update unit 325 creates information for changing the state information, and updates the state information of the vehicle and the in-vehicle device, respectively. The state information update unit 325 also updates the state information about the past non-delivery state as long as it includes the estimation of the past non-delivery state.

When the on-board unit is not able to communicate within the predetermined interval, that is, when the final communication date 312c is not within the predetermined period from the processing time (when "No" in step S102), the state estimation unit 323 may use the state estimation unit 323. It is determined whether or not the predetermined non-delivery deadline (the limit of the period during which communication is interrupted) has been passed (step S105). Specifically, the state estimation unit 323 refers to the final communication day 312c of the vehicle-mounted device state information 312, and determines whether or not five business days have passed since the last communication date. If the non-delivery deadline has not been passed (in the case of "No" in step S105), the state estimation unit 323 ends the state determination process.

When the non-delivery deadline has passed (in the case of "Yes" in step S105), the state estimation unit 323 acquires the current state (latest state) of the in-vehicle device (step S106). Specifically, the state estimation unit 323 reads the latest state 312b related to the vehicle-mounted device selected in step S101 with reference to the vehicle-mounted device state information 312, and sets the current state.

Then, the state estimation unit 323 transitions from the current state to the state corresponding to the event “passing the deadline” (step S107). Specifically, the state estimation unit 323 refers to the state transition table 313, and from the current state 313a, which is the current state acquired in step S103, changes the state corresponding to the case where the event “non-delivery deadline” 313c occurs. It is specified and estimated as the state of the vehicle and the on-board unit 100. In addition to estimating the state of the in-vehicle device 100, in the case of a combination in which the state of the vehicle can be estimated, the state of the vehicle is also included in the state transition table 313, so that the state of the vehicle and the in-vehicle device 100 can be determined. Estimates and transitions are possible.

Then, the state information creation unit 324 is based on the estimation of the state estimation unit 323, and the information for changing the state information for each state of the vehicle state and the in-vehicle device state (for example, the in-vehicle device identifier and its own). Create a vehicle identifier and its state, information that identifies the start and end, etc., such as the state, start and end, etc.). Then, the state information update unit 325 creates information for changing the state information, and updates the state information of the vehicle and the in-vehicle device, respectively. The state information update unit 325 also updates the state information about the past non-delivery state as long as it includes the estimation of the past non-delivery state.

The above is the flow of the state determination process. According to the state determination process, the state of the vehicle and the in-vehicle device is determined according to the communication status of the in-vehicle device. Therefore, it is possible to record the state of the vehicle and the on-board unit without requiring any special input work. For example, even if the in-vehicle device is operating normally, if the non-delivery period becomes long, it will be necessary to check the status (“status confirmation required”), so if you refer to this, you may not be able to manage the status. It can be suppressed. In particular, in the "removed" state, if the non-delivery period becomes longer than the specified period, it may be left unattended, that is, it may not be attached to the vehicle and it may not be repaired. It can be prevented from happening.

FIG. 9 is a diagram showing an example of a state confirmation screen. The status confirmation screen 400 is a screen created by the management service unit 326 when a request is received from the status information presentation unit 221 of the management terminal 200, and is transmitted to the management terminal 200 by the communication unit 330. The state confirmation screen 400 includes a vehicle identifier input area 401, a vehicle state display area 402, an on-board unit state display area 403, and a history display instruction input area 410. The vehicle identifier input area 401 is an area that accepts the input of the vehicle identifier. The vehicle state display area 402 is an area for displaying a list of vehicle state information 311 which is a state and a history of the state of the vehicle identified by the vehicle identifier input to the vehicle identifier input area 401. The on-board unit status display area 403 is an on-board unit state information that is a state and a history of each of the in-vehicle devices 100 that have been associated with the vehicle identified by the vehicle identifier input to the vehicle identifier input area 401. This is an area for displaying a list of 312.

Upon receiving the input, the history display instruction input area 410 transfers control to the management service unit 326. The management service unit 326 is configured to display the current state and history of the vehicle state in the vehicle state display area 402 with reference to the vehicle state information 311 for the vehicle having the vehicle identifier input in the vehicle identifier input area 401. Further, the management service unit 326 identifies all of the on-board units 100 mounted on the vehicle having the vehicle identifier input to the vehicle identifier input area 401 with reference to the vehicle state information 311. Then, the management service unit 326 configures the screen information so as to display the current state and history of the state of the in-vehicle device in the in-vehicle device state display area 403 with reference to the in-vehicle device state information 312. Then, the management service unit 326 instructs the communication unit 330 to transmit the status confirmation screen 400 to the management terminal 200.

The above is the in-vehicle device deployment management system 1 to which the embodiment according to the present invention is applied. According to the in-vehicle device deployment management system 1, it is possible to provide a server device and an in-vehicle device deployment management method that do not require complicated management information input operations.

However, the present invention is not limited to the above embodiment. The above embodiments can be variously modified within the scope of the technical idea of the present invention. For example, the "state" defined in the state transition table 313 may be variously subdivided or integrated according to the management purpose. Alternatively, the position information of the vehicle may be used to improve the accuracy of estimating the failure of the vehicle. For example, the history of vehicle position information is recorded in the server device 300, and if the distance traveled in a predetermined period is extremely short, it is highly likely that the repair shop is performing repairs. You may.

1 ... In-vehicle device deployment management system, 100 ... In-vehicle device, 110 ... Storage unit, 111 ... Installed vehicle information, 112 ... In-vehicle device identification information, 120 ... Control unit, 121.・ ・ Input control unit, 122 ・ ・ ・ screen control unit, 123 ・ ・ ・ use start processing unit, 124 ・ ・ ・ vehicle control processing unit, 125 ・ ・ ・ alive notification unit, 130 ・ ・ ・ communication unit, 140 ・ ・-Touch panel, 150 ... Display, 200 ... Management terminal, 220 ... Control unit, 221 ... Status information presentation unit, 222 ... Status information update unit, 223 ... Input control unit, 224 ... screen control unit, 230 ... communication unit, 300 ... server device, 310 ... storage unit, 311 ... vehicle status information, 312 ... in-vehicle device status information, 313 ... status Transition table, 320 ... Control unit, 321 ... Usage start notification reception unit, 322 ... Alive notification reception unit, 323 ... State estimation unit, 324 ... State information creation unit, 325 ... Status information update department, 326 ... Management service department, 330 ... Communication department

Claims (10)

At least, the in-vehicle device state information that specifies the usage state of the in-vehicle device including any of the normal operation state, the confirmation required state, and the removal state is stored for each identification information of the in-vehicle device, and the identification information of the in-vehicle device is stored. And a storage unit that stores the identification information of the vehicle on which the in-vehicle device is mounted in association with each other.
Communication department and
A notification receiving unit that receives the vehicle identification information and the vehicle-mounted device identification information associated with the vehicle identification information from an external device via the communication unit.
The normal operating state when there is communication from the in-vehicle device, and the confirmation required state when the period of non-communication from the in-vehicle device exceeds a predetermined period, are set with respect to the identification information of the vehicle. A state estimation unit that estimates the removed state as the usage state of the in-vehicle device when there is a change in the associated identification information of the in -vehicle device, and
A state information creation unit that creates the on-board unit state information according to the usage state estimated by the state estimation unit, and a state information creation unit.
A state information update unit that stores the on-board unit state information in the storage unit,
A server device characterized by being equipped with. The server device according to claim 1.
The storage unit further stores vehicle state information that specifies the usage state of the vehicle, and stores the vehicle state information.
In the state estimation unit, when the in-vehicle device is in the confirmation required state and there is communication from the in-vehicle device, the in-vehicle device is in the normal operating state even during the period when the communication is interrupted. It is estimated that the vehicle was in a state of failure.
The state information creating unit creates the vehicle state information according to the usage state of the vehicle estimated by the state estimation unit.
The state information updating unit stores the vehicle state information in the storage unit.
A server device that features that. The server device according to claim 1.
The state estimation unit determines that the on-board unit is in the storage state when the state of the on-board unit is after the repair is completed and the period during which communication from the on-board unit is not available exceeds a predetermined period. presume,
A server device that features that. The server device according to claim 1.
The storage unit further stores vehicle state information that specifies the usage state of the vehicle, and stores the vehicle state information.
When the on-board unit is in the removed state from the vehicle and communication is continued, the state estimation unit is in the normal operating state of the on-board unit in the removed state. , It is estimated that the vehicle was in a state of failure,
The state information creating unit creates the vehicle state information according to the usage state of the vehicle estimated by the state estimation unit.
The state information updating unit stores the vehicle state information in the storage unit.
A server device that features that. The server device according to claim 1.
Corresponding to each of the usage states of the in-vehicle device, at least when there is communication from the in-vehicle device, when the period of non-communication from the in-vehicle device exceeds a predetermined period, and when the vehicle Depending on whether there is a change in the identification information of the in-vehicle device associated with the identification information, or the usage state to be transitioned to next, the normal operation state and the confirmation required state, respectively. A state transition table that defines the removed state and the above-mentioned removed state is further provided.
The state estimation unit estimates the usage state to be transitioned next as the usage state of the in-vehicle device with reference to the state transition table.
A server device that features that. It is a method of managing the deployment of in-vehicle devices using a server device.
The server device is
At least, the in-vehicle device state information that specifies the usage state of the in-vehicle device including any of the normal operation state, the confirmation required state, and the removal state is stored for each identification information of the in-vehicle device, and the identification information of the in-vehicle device is stored. It is provided with a storage unit, a communication unit, and a control unit that store the identification information of the vehicle on which the on-board unit is mounted in association with each other.
The control unit
A notification / reception step of receiving the vehicle identification information and the vehicle-mounted device identification information associated with the vehicle identification information from an external device via the communication unit.
The normal operating state when there is communication from the in-vehicle device, and the confirmation required state when the period of non-communication from the in-vehicle device exceeds a predetermined period, are set with respect to the identification information of the vehicle. A state estimation step for estimating the removed state as the usage state of the in-vehicle device when there is a change in the associated identification information of the in -vehicle device, and
A state information creation step for creating the on-board unit state information according to the usage state estimated in the state estimation step, and a state information creation step.
A state information update step for storing the on-board unit state information in the storage unit, and
An in-vehicle device deployment management method characterized by implementing. The in-vehicle device deployment management method according to claim 6 .
The storage unit further stores vehicle state information that specifies the usage state of the vehicle, and stores the vehicle state information.
In the state estimation step, when the in-vehicle device is in the confirmation required state and there is communication from the in-vehicle device, the in-vehicle device is in the normal operating state even during the period when the communication is interrupted. It is estimated that the vehicle was in a state of failure.
In the state information creation step, the vehicle state information corresponding to the usage state of the vehicle estimated in the state estimation step is created.
In the state information update step, the vehicle state information is stored in the storage unit.
An in-vehicle device deployment management method characterized by this. The in-vehicle device deployment management method according to claim 6 .
In the state estimation step, when the state of the in-vehicle device is after the repair is completed and the period of communication from the in-vehicle device exceeds a predetermined period, the in-vehicle device is in the storage state. presume,
An in-vehicle device deployment management method characterized by this. The in-vehicle device deployment management method according to claim 6 .
The storage unit further stores vehicle state information that specifies the usage state of the vehicle, and stores the vehicle state information.
In the state estimation step, when the on-board unit is in the removed state from the vehicle and communication is continued, the on-board unit is in the normal operating state in the removed state. , It is estimated that the vehicle was in a state of failure,
In the state information creation step, the vehicle state information corresponding to the usage state of the vehicle estimated in the state estimation step is created.
In the state information update step, the vehicle state information is stored in the storage unit.
An in-vehicle device deployment management method characterized by this. The in-vehicle device deployment management method according to claim 6.
The server device is
Corresponding to each of the usage states of the in-vehicle device, at least when there is communication from the in-vehicle device, when the period of non-communication from the in-vehicle device exceeds a predetermined period, and when the vehicle Depending on whether there is a change in the identification information of the in-vehicle device associated with the identification information, or the usage state to be transitioned to next, the normal operation state and the confirmation required state, respectively. A state transition table that defines the removed state and the above-mentioned removed state is further provided.
In the state estimation step, the usage state to be transitioned next is estimated as the usage state of the in-vehicle device by referring to the state transition table.
An in-vehicle device deployment management method characterized by this.

Images