JP7470539B2 - Construction history information management system - Google Patents

Description

The present invention relates to a construction history information management system that accumulates and manages data collected by each work machine.

In recent years, in the field of information-based construction using work machines, construction history information management systems have been used to accumulate construction history information for multiple work machines under the management of construction managers such as manufacturers and users. These systems accumulate and manage data collected by sensors mounted on each work machine (such as work machine position data, work machine attitude data, and data on the amount of soil transported by the work machine) on a server. By utilizing the construction history information management system, construction managers can efficiently accumulate collected data on construction history information for each worker, work site, and work machine.

Regarding a system that manages data on a server, such as the above-mentioned construction history information management system, Patent Document 1 discloses that a server that receives probe data (data acquired by sensors mounted on the vehicles, etc.) transmitted from multiple vehicles detects the total number of transmitted vehicles and the upload time of the probe data for each vehicle based on the received probe data, calculates a correction value for the upload time for each vehicle according to the total number of vehicles based on the detected upload time, and transmits the calculated correction value to each vehicle.

International Publication No. 2017/037784

In a construction history information management system, the server may generate new data to be sent to each work machine based on data collected from each work machine, and transmit the generated data (generated data) to be used by each work machine. For example, the server may generate and transmit control command data (generated data) for each work machine based on collected data received from each work machine to remotely control each work machine. The server may also generate data related to the status and construction history of each work machine based on the collected data and present the data to the construction manager via a monitor or the like. In such cases, if it is assumed that collected data acquired by a sensor or the like of each work machine is promptly received by the server, it is preferable that the time when the server receives the collected data, the time when the server generates new data based on the collected data, and the time when the server transmits the generated data to each work machine are as close as possible from the viewpoint of the control accuracy and work efficiency of each work machine, and real-time performance is required.

However, when multiple work machines are under the management of a server, the timing of data acquisition (data acquisition cycle) at each work machine and the timing of data transmission (upload cycle) from each work machine to the server are independent for each work machine, and are usually not set with consideration given to the acquisition and transmission timings of the other work machines. Therefore, if too much collected data from each work machine is concentrated on the server at a certain time, the server load (e.g., the load on the processing unit) may increase. An increase in server load means an increase in the time from the time the collected data is received to the time the generated data is transmitted, which leads to a delay in the transmission of the generated data transmitted from the server to each work machine, and can easily reduce the control accuracy and work efficiency of the work machine to which the generated data is transmitted.

The technology of Patent Document 1 prevents probe data uploads from concentrating on the server by performing one of the following corrections: transmission interval extension correction, transmission data number reduction correction, and data transmission vehicle reduction correction according to the total number of vehicles for the probe data upload time from each vehicle. However, the transmission interval extension correction increases the difference between the data acquisition timing at the work machine and the transmission timing to the server, so that if there is a work machine that is remotely controlled based on the control command data of the server, for example, the control accuracy and work efficiency of the work machine will decrease. In addition, the transmission data number reduction correction and data transmission vehicle reduction correction may make it impossible to collect the collection data that is actually necessary, so they are inappropriate as corrections to apply when remotely controlling a work machine with a server. In this way, the technology of Patent Document 1 is not based on the premise that the collected data obtained by the work machine will be used for real-time processing such as remote control.

The object of the present invention is to provide a construction history information management system that includes a server that performs predetermined calculation processing using collected data transmitted from multiple work machines to generate generated data, and that can complete the calculation processing without delay in accordance with the characteristics of the generated data from the time the server receives the collected data.

The present application includes multiple means for solving the above-mentioned problems. One example is a construction history information management system including a communication device that communicates with multiple vehicle-mounted controllers mounted on multiple work machines and receives collected data, which is data transmitted from the multiple vehicle-mounted controllers, a database into which the collected data received by the communication device is imported, and a server that generates new data based on the collected data imported into the database and transmits the generated data to the multiple vehicle-mounted controllers via the communication device. The server classifies the collected data imported into the database into one of multiple categories including a first category based on its data characteristics, and when a load index value indicating the load of the server exceeds a predetermined load threshold, outputs a command to change the upload interval of the collected data classified into the first category to a longer time , to the vehicle-mounted controller among the multiple vehicle-mounted controllers that transmitted the collected data classified into the first category.

According to the present invention, the server can complete calculation processing without delay from the moment it receives collected data, in accordance with the characteristics of the generated data.

1 is an overall view of a construction history information management system according to an embodiment of the present invention. FIG. 1 is a side view of a hydraulic excavator 100 used as a work machine in an embodiment of the present invention. FIG. 2 is a schematic configuration diagram of a server 201 according to the embodiment of the present invention. FIG. 4 is a flowchart showing an example of processing executed by the server 201 according to the embodiment of the present invention. 4 shows data characteristics of data collected in this embodiment. FIG. 2 is a diagram showing an example of a management method for collected data in a database 202. FIG. 13 is a diagram showing an example of a flowchart of a category classification process performed by a collected data classification unit 240 in step S104. 11A to 11C are diagrams illustrating effects according to an embodiment of the present invention. 6 is a flowchart of a process in which the server 201 calculates a travel prohibition command (generated data) when the hydraulic excavator 100 approaches an obstacle. FIG. 5 is a diagram showing another example of a flowchart of the category classification process performed by the collected data classification unit 240 in step S104 of FIG. 4. FIG. 5 is a diagram showing another example of a flowchart of the category classification process performed by the collected data classification unit 240 in step S104 of FIG. 4. FIG. 5 is a diagram showing another example of a flowchart of the category classification process performed by the collected data classification unit 240 in step S104 of FIG. 4. FIG. 11 is a flowchart showing another example of the process executed by the server 201 according to the embodiment of the present invention. 11A to 11C are diagrams illustrating effects according to an embodiment of the present invention. 4 is a timing chart for receiving collected data from a plurality of hydraulic excavators 100 (work machines).

Hereinafter, an embodiment of the present invention will be described with reference to the drawings.
(System configuration)
1 is an overall view of a construction history information management system according to an embodiment of the present invention. The construction history information management system 200 of this embodiment includes a plurality of work machines 100, an on-board controller 110 mounted on each work machine 100, a communication device 211 that receives various data (collected data) transmitted from the plurality of on-board controllers 110, a database 202 into which the collected data received by the communication device 211 is incorporated, a server 201 that generates new data based on the collected data incorporated in the database 202 and transmits the generated data (generated data) to the plurality of on-board controllers 110 via the communication device 211, and a monitor 203 on which the generated data by the server 201 is displayed. Here, a case where a hydraulic excavator is used as the work machine 100 will be described, but other work machines such as a wheel loader, a dump truck, and a dozer may also be used.

(Work machine (hydraulic excavator))
Fig. 2 is a side view of a hydraulic excavator 100 used as a work machine in the construction history information management system of this embodiment. The hydraulic excavator 100 in Fig. 2 is equipped with a crawler-type running body (lower running body) 2, a rotating body (upper rotating body) 3 rotatably attached to the upper part of the running body 2, and a front working device (sometimes simply referred to as a "working device") 6 consisting of a multi-joint type link mechanism one end (base end) of which is attached to the front of the rotating body 3.

The front working mechanism 6 has a boom 6A, one end of which is connected to the rotating body 3, an arm 6B, one end of which is connected to the other end of the boom 6A, and a bucket 6C, one end of which is connected to the other end of the arm 6B. Each of these front members 6A, 6B, and 6C is configured to rotate in the vertical direction.

In addition, a boom cylinder 11A, an arm cylinder 11B, and a bucket cylinder 11C are provided as drive actuators for rotating the front members 6A, 6B, and 6C. The rotating body 3 is driven to rotate around the central axis O of rotation by a rotation motor (not shown).

The hydraulic excavator 1 is equipped with a number of attitude sensors 75A, 75B, 75C, 23 for detecting the attitude of the front working device 6 and the revolving body 3. In this embodiment, an inertial measurement unit (IMU) capable of detecting angles (or angular velocity) and acceleration is used for each attitude sensor. Of these attitude sensors, the boom attitude sensor 75A is attached to the boom 6A, the arm attitude sensor 75B is attached to the arm 6B, and the bucket attitude sensor 75C is attached to the bucket 6C (see FIG. 2). In addition, the revolving body attitude sensor 23 is attached to the revolving body 3 (see FIG. 2), which measures the tilt angle (pitch angle and roll angle), revolving speed, and revolving angle of the revolving body 3. The outputs (detection signals) of the attitude sensors 75A, 75B, 75C, 23 are input to the on-board controller 40. Note that angle sensors that detect the rotation angles of each front member may be used as the attitude sensors of the front working device 6.

The rotating body 3 is provided with an operating device (not shown) operated by an operator, a driver's seat 4 provided with a monitor 60 that displays the positional relationship between the bucket 6C and the construction target surface, two GNSS antennas 50A, 50B for receiving satellite signals from multiple positioning satellites (GNSS satellites), a wireless communication device 7 for transmitting and receiving data to and from a server 201 via wireless communication NT1, and a GNSS receiver (position sensor) that calculates the position coordinates in a geographic coordinate system (global coordinate system) of at least one of the two GNSS antennas 50A, 50B and the direction between the two GNSS antennas 50A, 50B (i.e., the direction of the rotating body 3). 51, a camera 62 that detects obstacles around the hydraulic excavator 100 based on captured camera image data, a laser radar (LIDAR) 61 that functions as a distance sensor and a current topography acquisition device by measuring the distance to objects around the hydraulic excavator 100, a boom rod pressure sensor 63a and a boom bottom pressure sensor 63b that are used to calculate the load of the work object (e.g., soil) in the bucket 6C, and an on-board controller 110 that transmits data acquired by various sensors mounted on the hydraulic excavator 100 to a server 201 and controls the hydraulic excavator 100 based on control commands transmitted from the server 201.

The vehicle-mounted controller 110 acquires the position data and orientation data of the upper rotating body 3 (hydraulic excavator 100) calculated by the GNSS receiver 51, the attitude data of the hydraulic excavator 100 calculated from the detection signals of the multiple attitude sensors 75A, 75B, 75C, 23, the camera image data photographed by the camera 62, the distance sensor data acquired by the laser radar 61, the soil volume data transported by the hydraulic excavator 100 calculated from the detection signals of the pressure sensors 63a, 63b, and the current topography data (topography data defined by point cloud) around the hydraulic excavator 1 acquired by the laser radar 61 at each sampling period (sampling interval), and transmits them to the server 201 via the wireless communication device 7 at each upload period (upload interval). In this paper, the data transmitted from the vehicle-mounted controller 110 to the server 201 may be referred to as collected data. In addition, the on-board controller 110 can receive control commands (generated data) generated by the server 201 based on data (collected data) received from each hydraulic excavator 100, and execute control based on the received control commands (generated data).

The vehicle controller 110 is equipped with a processing unit (e.g., a CPU (not shown)), a storage device (e.g., semiconductor memory such as ROM and RAM), and an interface (input/output device (not shown)). The processing unit executes a program (software) that is pre-stored in the storage device, and the processing unit performs calculations based on data specified in the program and data input from the interface, and outputs a signal (calculation result) from the interface to the outside.

The vehicle controller 110 is connected to the GNSS receiver 51, the attitude sensors 75A, 75B, 75C, 23, the monitor 60, and the wireless communication device 7 via interfaces, allowing data to be exchanged between them.

The storage device of the on-board controller 110 stores, for example, construction target surface data that defines the position of the construction target surface that is the target of construction by the hydraulic excavator 100, vehicle body shape and dimension data, and various programs executed by the arithmetic processing device.

Satellite communication networks, mobile phone communication networks, the Internet, etc. can be used as wireless communication NT1.

(server)
The server 201 can be, for example, a computer equipped with an arithmetic processing unit such as a CPU (not shown), a storage device (not shown) consisting of a semiconductor storage device such as a RAM or ROM or a magnetic storage device such as a HDD, and an input/output interface (not shown) for exchanging information with an externally connected device, and can be composed of a single computer or multiple computers.

Figure 3 is a schematic diagram of the server 201, with multiple blocks showing the processes executed by the server 201.

Connected to the server 201 are an input device 204 such as a mouse and keyboard, a communication device 211 for communicating with multiple vehicle controllers 110, a database (DB) 202 in which collected data is stored, and a monitor 203.

By having the processor execute the programs stored in the storage device, the server 201 can function as a communication control unit 210, a data input unit 220, a data output unit 222, a storage unit 230, a server load management unit 232, a data generation unit 234, a collected data classification unit 240, and an upload time change command calculation unit 242. The following describes in detail the processing performed by each unit of the server 201.

The communication control unit 210 is a part that performs the control necessary to transmit and receive data to and from external terminals such as the in-vehicle controller 110, and is connected to a communication device 211 for wireless communication with each in-vehicle controller 110.

The data input unit 220 is a part for inputting data input from the communication control unit 210, the input device 204, the DB 202, etc. into the server 201, and the data output unit 222 is a part for outputting data generated or stored in the server 201 to the monitor 203, the DB 202, etc.

The storage unit 230 is a part for temporarily storing data imported into the server 201, data output outside the server 201, data used in ongoing calculations, etc., and the hardware may be a semiconductor memory. The data temporarily stored in the storage unit 230 includes collected data imported into DB 202, collected data received by the communication device 211 and before being stored in DB 202, generated data calculated based on the collected data imported into DB 202, etc.

(Data Generation Unit 234)
The data generation unit 234 is a part that generates generated data, which is new data, based on the collected data that has been taken into the DB 202. The generated data includes control commands for controlling the work machines 100 by the on-board controller 110, and control commands for displaying on the monitor 203 information relating to each work machine 100 and the construction status that is provided to the construction manager.

The former control command is a travel stop command that is output when the work machine 100 approaches an obstacle. From the time series of position data transmitted from each on-board controller 110, it is determined whether the hydraulic excavator 100 on which the on-board controller 110 is mounted is traveling or not. If it is determined that the excavator is traveling, posture data of the front working implement 6 and camera data capturing an obstacle located in the traveling direction of the hydraulic excavator 100 are acquired to calculate the distance between the front working implement 6 and the obstacle. If the calculated distance falls below a predetermined distance threshold, output of the travel command by the operating lever is stopped or prohibited, and the hydraulic excavator 100 is promptly stopped.

(Collected Data Classification Unit 240)
The collected data classification unit 240 is a part that performs a process (category classification process) of classifying the collected data imported into the DB 202 into one of a plurality of predetermined categories based on the data characteristics of the collected data. The plurality of categories include a first category and a second category. Note that in this embodiment, there are two categories, the first category and the second category. The category classification process may be performed when the server load management unit 232 determines that the server load (described later) is high, or may be performed when or after the server 201 receives each collected data, regardless of the server load.

The first category is a category to which collected data belongs, for which the upload interval (upload interval can be set for each collected data) of certain collected data from the in-vehicle controller 110 to the server 201 can be changed to an interval longer than the interval currently set. Note that in this embodiment, the first category is sometimes referred to as a thinning request category.

The second category is a category for collected data that can change the upload interval of certain collected data from the in-vehicle controller 110 to the server 201 to an interval that is the same as or shorter than the interval currently set. In this embodiment, the second category is sometimes referred to as an immediate request category.

Details will be described later, but the data characteristics used for category classification include the length of the sampling period (collection frequency) of the collected data, whether the collected data is used for real-time processing, whether there is other collected data used simultaneously with the collected data, and the priority of use of the collected data by server 201. Note that real-time processing refers to generation processing performed by server 201 promptly and without delay after receiving the corresponding collected data, among the generation processing performed by server 201 for generated data. Furthermore, the priority of collected data can be set arbitrarily according to the actual usage of the collected data by server 201.

The data characteristics may be added to the collected data sent from the in-vehicle controller 110 (i.e., may be added by the in-vehicle controller 110), but may also be added by the server 201 by analyzing the characteristics of the data when or after the server 201 receives the collected data.

(Server load management unit 232)
The server load management unit 232 is a part that executes a process (server load management process) for managing the load (server load) of the server 201. In this embodiment, the level of the server load is grasped by a load index value indicating the server load, and when the load index value exceeds a predetermined load threshold, the server load management unit 232 determines that the server load is relatively high and outputs a high load flag. Examples of the load index value include the usage rate of a processor (e.g., a CPU) mounted on the server 201, the temperature of the processor, and the memory usage amount mounted on the server 201, and the load threshold can be set for each load index value.

(Upload time change command calculation unit 242)
The upload time change command calculation unit 242 is a part that performs processing to generate a command (control command) to change the upload time of each collected data based on the category into which each collected data was classified by the collected data classification unit 240, when the server load management unit 232 determines that the load index value of the server 201 has exceeded a predetermined load threshold (i.e., when a high load flag is output from the server load management unit 232), and outputs the generated command to the corresponding in-vehicle controller 110.

Methods for lengthening the upload interval of collected data classified into the first category include (1) changing the upload interval of the target collected data from the first upload interval (first time) currently set to a second upload interval (second time) longer than the first upload interval (i.e., outputting an instruction to rewrite the numerical value that defines the upload interval of the target collected data to a new value (correction value)), and (2) specifying the upload time of the target collected data as the next upload time to a time that is an arbitrary time later than the next upload time determined based on the currently set upload interval, and similarly specifying any upload time that is longer than the initial interval for subsequent upload timings. In the case of (2), a method for specifying the next upload time is to output an instruction (upload time specification instruction) to the corresponding in-vehicle controller 110 before the next upload time to instruct the corresponding collected data to upload to the server 201 at a specified time (upload time).

Similar to the first category, methods for shortening the upload interval of collected data classified as the second category include (1) changing the upload interval of the target collected data from the currently set third upload interval (third hour) to a fourth upload interval (fourth hour) that is shorter than the third upload interval (a command to rewrite the upload interval to a new value (correction value)), or (2) specifying the upload time of the target collected data as the next upload time to a time that is an arbitrary time earlier than the next upload time determined based on the currently set upload interval, and similarly specifying arbitrary upload times for subsequent upload timings that will result in upload intervals shorter than the initial interval (a command to specify the upload time).

(Flowchart 1 of Server 201 (FIG. 4))
Next, the details of the process performed by the server 201 will be described with a specific example. Fig. 4 is a flowchart showing an example of the process executed by the server 201 of this embodiment. In the flowchart in this figure, when the server is under high load, a correction process is performed to increase the upload interval for collected data in the first category, but the upload interval is not changed for collected data in the second category.

When the server 201 starts the flow of FIG. 4, it judges whether or not the hydraulic excavator (work machine) 100 under its management is operating (S101). This judgment can be made, for example, based on whether or not there is data transmitted from each on-board controller 110. Each on-board controller 110 may transmit the ON/OFF status of the power supply of each hydraulic excavator. If it is determined in step S101 that there is no working machine in operation, the process ends. On the other hand, if there is a working machine in operation, the process proceeds to step S102.

In step S102, the server 201 appropriately receives the collected data transmitted from each vehicle controller 110 (each hydraulic excavator 100) via the communication device 211 and stores it in the DB 202. The upload timing of the collected data from each vehicle controller 110 depends on the settings of each vehicle controller 110, but usually coincides with the sampling period of the collected data in each work machine 100 (i.e., the sampling period and the upload period coincide).

(Characteristics of collected data)
Data characteristics of the data collected in this embodiment are shown in Fig. 5. As shown in this figure, the data collected in this embodiment includes attitude data of the front working implement 6 and the upper rotating body 3, position data of the hydraulic excavator 100, camera image data of the surroundings of the hydraulic excavator 100 captured by the camera 62, point cloud data of obstacles around the hydraulic excavator 100 acquired by the laser radar 61, data on the volume of soil excavated by the front working implement 6, and current topography data acquired by the laser radar 61.

Of the data shown in Figure 5, the data acquisition request categories of attitude data, position data, camera image data, and point cloud data are classified into the second category, while the same categories of soil volume data and current topography data are classified into the first category. In the case of Figure 5, the category classification matches the presence or absence of use for real-time processing. In other words, attitude data, position data, camera image data, and point cloud data are used for real-time processing, while soil volume data and current topography data are not used for real-time processing.

In the example of FIG. 5, data characteristic groups are classified into five groups, A to E, according to the collection frequency of each collected data (which can also be expressed as the upload interval or upload cycle to the server 201, the sampling cycle in the hydraulic excavator 100, etc.). Specifically, attitude data and position data with a collection frequency of 10 ms or less are classified into group A, camera image data with a collection frequency of more than 10 ms and less than 50 ms are classified into group B, point cloud data with a collection frequency of more than 50 ms and less than 100 ms are classified into group C, current topography data with a collection frequency exceeding 100 ms are classified into group D, and soil volume data for which a collection frequency is not set (for example, soil volume data can be measured each time the swing boom is raised) are classified into group E. The group classification may be performed on the vehicle controller 110 side or on the server 201 side.

Figure 6 is a diagram showing an example of a method for managing collected data in DB202. In this example, tables are classified by data characteristic group (Grp), and data can be identified from a combination of the group (Grp) to which the data belongs and an ID. When collected data is classified by category by the collected data classification unit 240, a category is assigned to the corresponding collected data. Each collected data is linked to the position data of the hydraulic excavator 100 when the data was acquired and the collection time (sampling time). In addition, the collected data stored in DB202 is a data store type with a simple structure that combines Key and Value. Therefore, for example, access performance can be improved by using it as a distributed data store that distributes and stores data in multiple databases.

Returning to the explanation of FIG. 4, in step S103, a check is made as to whether or not the control period for the category classification process of the collected data by the collected data classification unit 240 and the server load management process by the server load management unit 232 has arrived. If the control period has arrived, the process proceeds to step S104, and if not, the process returns to step S101. Note that in this flow, the category classification process and the server load management process are performed in the same period, but they may be performed in different periods.

In step S104, the server 201 (server load management unit 232) determines whether the utilization rate of the arithmetic processing unit (e.g., CPU) mounted on the server 201 exceeds a predetermined load threshold. If it is determined that the utilization rate exceeds the load threshold, it determines that the server is in a high-load state, outputs a high-load flag, and proceeds to step S105. Conversely, if it is determined that the utilization rate is equal to or lower than the load threshold, it determines that the server 201 is in a normal load state (i.e., not in a high-load state), and returns to step S101.

(Category Classification Process 1 (FIG. 7))
In step S105, the server 201 (collected data classification unit 240) classifies the collected data received when the server 201 is in a high load state into either the first category or the second category based on the data characteristics of the collected data. Details of the category classification process by the collected data classification unit 240 will now be described with reference to Fig. 7. Fig. 7 is a diagram showing an example of a flowchart of the category classification process performed by the collected data classification unit 240 in step S104.

When the server 201 (collected data classification unit 240) reaches step S104 (i.e., when a high load flag is output from the server load management unit 232), it starts the process of FIG. 7. First, in step S201, one piece of collected data is selected from the multiple pieces of collected data in DB 202 received when the server 201 is in a high load state, and it is determined whether the collection frequency (sampling period) of the selected collected data is 100 ms or less. If the collection frequency of the selected collected data is 100 ms or less, the process proceeds to step S203, where the collected data is classified into the second category. On the other hand, if the collection frequency exceeds 100 ms, the process proceeds to step S205, where the collected data is classified into the first category.

In step 207, the server 201 (collected data classification unit 240) determines whether or not category classification has been completed for all collected data received when the server 201 was in a high-load state, and if there is unclassified collected data, the process returns to S201, and if classification of all collected data received when the server 201 was in a high-load state has been completed, the process of FIG. 7 (process of step S105 (category classification process)) is terminated and the process proceeds to step S106 in FIG. 4.

In step S106, the server 201 (upload time change command calculation unit 242) selects one piece of collected data from the multiple pieces of collected data categorized in step S105, and determines whether the category of the selected collected data is the first category (thinning request). If the category of the collected data is the first category, the process proceeds to step S107, and if the category is the second category (immediate request), the process proceeds to step S108.

In step S107, the server 201 (upload time change command calculation unit 242) calculates a command to change the upload interval (collection frequency) of the collected data belonging to the first category selected in step S106 from the first upload interval (first time) set at that time to a second upload interval (second time) that is longer than the first upload interval (i.e., a command to rewrite the upload interval of the selected collected data to a new value (correction value)), and outputs the command to the in-vehicle controller 110 that transmitted the selected collected data.

The upload interval after the change made by the upload time change command calculation unit 242 can be calculated by multiplying the pre-change (current) upload interval by a coefficient greater than 1. For example, if current topography data belonging to the first category is selected in step S106 and the upload interval of the current topography data is to be lengthened, the corrected upload interval t(I)' of the current topography data can be calculated by the following formula (1).

Corrected current terrain upload interval (collection cycle) t(I)'=pre-corrected current terrain upload interval t(I)×(1+(position data upload interval t(P))/(position data upload interval t(P)+pre-corrected current terrain upload interval t(I)) ...Equation (1)
Here, assuming that the upload interval of the current topography data before correction, t(I) = 1 [s] = 1000 [msec], and the upload interval of the position data = 10 [msec], then t(I)' = 1000 x (1 + 10/(10 + 1000)) = 1009.9 [msec]. In other words, the upload interval of the current topography after correction, t(I)', increases by 9.9 [msec] compared to before correction. The effect of this will be explained using FIG. 8.

The upper diagram in Figure 8 shows a case where attitude data, position data, camera image data, point cloud data, soil volume data, and current terrain data are concentrated at a certain time (shown as 10 [msec] for convenience) (i.e., the situation before the upload interval is corrected by the upload time change command calculation unit 242). In this case, if the upload interval of the current terrain data is corrected by the upload time change command calculation unit 242 as in the above example, the upload time of the current terrain data will be delayed by 9.9 [msec] from 10 [msec] as shown in the lower diagram in Figure 8, so that the data concentration at 10 [msec] can be alleviated and the server load can be reduced. The reduction in server load allows the server 201 to complete calculation processing without delay in accordance with the characteristics of the generated data from the time it receives the collected data.

When step S107 is completed, the server 201 (upload time change command calculation unit 242) determines whether or not the determination in step S106 has been performed for all collected data categorized in step S105. If the determination in step S106 has been performed for all collected data, the process returns to step S101; otherwise, the process returns to step S106.

(Example of calculation of generated data)
9 shows a flowchart of a process for calculating a travel prohibition command (generated data) when the hydraulic excavator 100 approaches an obstacle, as an example of the generated data calculation process executed by the server 201 of this embodiment. Note that here, it is assumed that collected data is received from a specific hydraulic excavator 100 (on-vehicle controller 110) among the multiple hydraulic excavators 100 under the management of the server 201, and the generated data (travel prohibition command) is transmitted to the specific hydraulic excavator 100.

In step S501, the server 201 receives (acquires) position data from the hydraulic excavator 100 (on-board controller 110) to be controlled.

In step S502, the server 201 compares the position data received in step S501 this time with the position data received previously (for example, in step S501 one cycle ago) to determine whether the hydraulic excavator 100 to be controlled (first work machine) has traveled. If there has been a change in the position data received here, it is determined that the hydraulic excavator 100 to be controlled has traveled, and the process proceeds to step S503. Conversely, if there has been no change in the position data, it is determined that the hydraulic excavator 100 to be controlled has stopped, and the process returns to step S501.

In step S503, the server 201 acquires posture data from the hydraulic excavator 100 to be controlled, and calculates the position of the front working implement 6 of the hydraulic excavator 100 to be controlled based on the acquired posture data and the position data acquired in step S501.

In step S504, the server 201 acquires camera image data from the hydraulic excavator 100 to be controlled, detects an obstacle captured in the camera image, and calculates the distance from the camera 62 to the obstacle. If the camera image is a stereo camera image (parallax image), the distance from the camera 62 to the obstacle can be easily calculated.

In step S505, the server 201 calculates the distance L from the front working implement 6 to the obstacle based on the position of the front working implement 6 calculated in step S503 and the distance to the obstacle (the position of the obstacle) calculated in step S504.

In step S506, the server 201 determines whether the distance L calculated in step S506 is less than a predetermined distance threshold L1. If the distance L is less than the threshold L1, it determines that there is a possibility of contact with the obstacle detected by the camera 62, and outputs a travel prohibition command to the hydraulic excavator 100 to be controlled, to stop travel or to disable the travel operation input by the operator. As a result, even if the hydraulic excavator 100 to be controlled is traveling, its travel operation is stopped, and contact with the obstacle can be prevented.

If the distance L is equal to or greater than the threshold L1 in step S506, the server 201 ends the process and waits until the next control cycle.

(Action and Effects)
The data used in the flow of Fig. 9 are the position data and attitude data belonging to group A (see Fig. 5) and the camera image data belonging to group B (see Fig. 5). Therefore, if the load on the server 201 is high at the timing when these three types of data are received by the server 201, the time required to generate a travel prohibition command will increase, and there is a risk of an increase in the gap between the time when the three types of data on which the travel prohibition command is based is sampled (collected) by the hydraulic excavator 100 to be controlled and the time when the travel prohibition command generated by the server 201 is received by the hydraulic excavator 100 to be controlled. An increase in the gap between the two times means a decrease in the control accuracy of the hydraulic excavator 100, and increases the risk of the hydraulic excavator 100 colliding with an obstacle.

In this embodiment, by using the flow shown in FIG. 4, when data transmission to the server is concentrated and the server becomes highly loaded, the reception of data used for real-time processing is prioritized, while the reception of data not used for real-time processing is delayed. This allows the server 201 to receive the above three types of data at approximately the same time and execute the flow shown in FIG. 9 without delay, preventing a large gap from occurring between the time the above three types of data are sampled by the hydraulic excavator 100 and the time the travel prohibition command is received by the hydraulic excavator 100, allowing the hydraulic excavator 100 to be controlled with high precision and preventing collisions with obstacles.

(supplement)
In the flow of Fig. 4, the collected data is classified into categories (step S105) when the server 201 is in a high-load state, but the category classification process may be performed when the server 201 is in a normal load state. That is, the category classification process may be performed, for example, between steps S102 and S103, or between steps S103 and S104. In addition, the process of step S105 is performed for all collected data received in a high-load state, and then the process proceeds to step S106. However, the processes of steps S105, S106, and even step S107 may be performed for each piece of collected data received in a high-load state. The same applies to the modified examples and other embodiments described below.

The category classification process of the collected data by the collected data classification unit 240 is not limited to the method shown in FIG. 7 above, and other methods can also be used. Next, other category classification processes will be described.

(Category Classification Process 2 (FIG. 10))
Fig. 10 is a diagram showing another example of a flowchart of the category classification process performed by the collected data classification unit 240 in step S104 in Fig. 4. Note that the same processes as those in Fig. 7 are denoted by the same reference numerals and descriptions thereof may be omitted (the same applies to the diagrams described below).

When the server 201 (collected data classification unit 240) reaches step S104 (i.e., when a high load flag is output from the server load management unit 232), it starts the process of FIG. 10.

First, in step S220, the high load count n, which is the number of times that the server load management unit 232 has determined that the server 201 is in a high load state, is counted up by 1. Note that the value (initial value) of the high load count n at the start of the flow in FIG. 4 is zero, and the high load count n is reset to zero at the end of the flow in FIG. 4. In other words, the high load count n is the number of times that the server load management unit 232 has determined that the server 201 is in a high load state since the flow in FIG. 4 started (i.e., the number of times the high load flag has been output).

In step S222, the server 201 (collected data classification unit 240) selects one piece of collected data from among the multiple pieces of collected data in the DB 202 received when the server 201 was in a high-load state, and determines whether the selected collected data is the data with the longest collection frequency (sampling interval) among the multiple pieces of collected data received when the server 201 was in a high-load state, up to the mth largest. Here, m=n+c1, where c1 is an integer equal to or greater than zero.

For simplicity, let c1 = 0 here. In this case, when n = 1, m = 1, and in step S222, the server 201 (collected data classification unit 240) determines whether the selected collected data is the most frequently collected data among the collected data received when the server was in a high load state. If the selected collected data is the most frequently collected data, it is classified into the first category (step S205), and if not, it is classified into the second category (step S203). That is, through these processes, the collected data up to the mth most frequently collected data are classified into the first category, and the remaining collected data (collected data with the most frequently collected data after m+1) are classified into the second category.

In this manner, in the flow of FIG. 10, the server 201 (collected data classification unit 240) classifies the collected data into the DB 202 so that, of the collected data, the collected data with a relatively long collection frequency (collection cycle) in the multiple vehicle controllers 110 is classified into a first category, and the collected data with a relatively short collection frequency (collection cycle) is classified into a second category. Even if the collected data categories are classified in this manner, the same effect as that described above can be achieved.

However, in the example of FIG. 10, the number of collected data items classified into the first category is automatically increased in accordance with an increase in the number of times that server 201 is determined to be in a high load state, so a distinctive advantage is that the system can be shifted in a direction that maintains the server load at a normal state without the construction manager having to actively set the number of collected data items to be classified into the first category.

(Category Classification Process 3 (FIG. 11))
FIG. 11 is a diagram showing another example of a flowchart of the category classification process performed by the collected data classification unit 240 in step S104 of FIG.

In step S210, the server 201 (collected data classification unit 240) selects one piece of collected data from the multiple pieces of collected data in the DB 202 received when the server 201 is in a high load state, and determines whether or not the selected collected data is used for real-time processing. If the selected collected data is used for real-time processing, the process proceeds to step S203, where the collected data is classified into the second category. On the other hand, if the collected data is not used for real-time processing, the process proceeds to step S205, where the collected data is classified into the first category. Whether or not each piece of collected data is used for real-time processing is indicated in the "Property" field in the table of FIG. 5. The real-time processing includes the obstacle collision prevention processing that calculates the travel prohibition command shown in FIG. 9. Note that the obstacle collision prevention processing may be performed using attitude data, position data, and point cloud data.

In this manner, in the flow of FIG. 11, the server 201 (collected data classification unit 240) classifies, among the collected data imported into the DB 202, collected data that is not used for real-time processing by the server 201 into a first category, and classifies collected data that is used for real-time processing by the server 201 into a second category. Even if the categories of collected data are classified in this manner, the same effect as when the processing of FIG. 7 is performed can be achieved.

(Category Classification Process 4 (FIG. 12))
FIG. 12 is a diagram showing another example of a flowchart of the category classification process performed by the collected data classification unit 240 in step S104 of FIG.

In step S212, the server 201 (collected data classification unit 240) selects one piece of collected data from among the multiple pieces of collected data in the DB 202 received when the server 201 is in a high load state, and determines whether there is collected data to be processed simultaneously by the server 201 with the selected collected data. If there is collected data to be processed simultaneously with the selected collected data, the process proceeds to step S214, where the selected collected data and the collected data to be processed simultaneously with the selected collected data are classified into a second category. On the other hand, if there is no collected data to be processed simultaneously, the process proceeds to step S205, where the selected collected data is classified into a first category. Examples of collected data to be processed simultaneously include the attitude data, position data, and camera image data shown in the example of FIG. 9. In addition, if obstacle collision prevention processing is performed using the attitude data, position data, and point cloud data, these are also collected data to be processed simultaneously.

In this manner, in the flow of FIG. 12, the server 201 (collected data classification unit 240) classifies collected data that is imported into the DB 202 and does not contain collected data that is used simultaneously when the server 201 generates generated data into a first category, and classifies collected data that does contain collected data that is used simultaneously when the server 201 generates generated data into a second category. Even when the categories of collected data are classified in this manner, the same effect as when the process of FIG. 7 is performed can be achieved.

(Flowchart 2 of Server 201 (FIG. 13))
In the above, the upload interval (collection frequency) of collected data classified into the first category is lengthened as shown in Fig. 4, but at the same time, the upload interval of collected data classified into the second category may be shortened. Next, the process performed by the server 201 in this case will be described with reference to Fig. 13.

Figure 13 is a flowchart showing another example of the processing executed by the server 201 of this embodiment. In this flowchart, when the server is heavily loaded, a correction process is performed to increase the upload interval for collected data in the first category, and a correction process is performed to decrease the upload interval for collected data in the second category. Note that the only difference from the flow in Figure 4 is step S109. Here, only the processing in step S109 will be explained, and the other processing will be omitted.

In step S109, the server 201 (upload time change command calculation unit 242) calculates a command to change the upload interval (collection frequency) of the collected data belonging to the second category selected in step S106 from the currently set third upload interval (third hour) to a fourth upload interval (fourth hour) that is shorter than the third upload interval (i.e., a command to rewrite the upload interval of the selected collected data to a new value (correction value)), and outputs the command to the in-vehicle controller 110 that transmitted the selected collected data.

The upload interval after the change made by the upload time change command calculation unit 242 can be calculated by multiplying the pre-change (current) upload interval by a coefficient smaller than 1. For example, if camera image data belonging to the second category is selected in step S106 and the upload interval of the camera image data is to be shortened, the corrected camera image data upload interval t(C)' can be calculated using the following formula (2).

Corrected camera image data upload interval (collection cycle) t(C)′=uncorrected camera image data upload interval t(C)×(1−(position data upload interval t(P)/uncorrected camera image data upload interval t(C)) …Equation (2)
Here, assuming that the upload interval of camera image data before correction, t(C)=33 [msec] and the upload interval of location data=10 [msec], then t(C)'=33×(1+(10/33))=23 [msec]. In other words, the upload interval of camera image data after correction, t(C)', is reduced by 10 [msec] compared to before correction. The effect of this is shown in FIG. 14.

The upper diagram of FIG. 14 shows a case where attitude data, position data, camera image data, point cloud data, soil volume data, and current topography data are concentrated at a certain time (shown as 10 [msec] for convenience) (i.e., the situation before the upload interval is corrected by the upload time change command calculation unit 242). In this case, the upload time change command calculation unit 242 corrects the upload interval of the camera image data as in the above example, and outputs a command (upload command (data request)) to the corresponding in-vehicle controller 110 to upload the camera image data acquired at a time according to the corrected upload interval to the server 201. This upload command makes the upload time of the camera image data 10 [msec] earlier than before the correction, as shown in the lower diagram of FIG. 14, and the time at which the attitude data and position data of group A can be used simultaneously is also 10 [msec] earlier, so that, for example, the number of times that obstacle collision prevention processing can be performed within a specified time can be improved compared to before the correction. In Figure 14, the timing at which the three types of data required for obstacle collision prevention processing (attitude data and position data of group A, and camera image data of group B) can be acquired simultaneously is shown by encircling the group name; before correction, this was twice every 60 msec, but after correction, this has increased to three times.

As shown in FIG. 13, by shortening the upload interval of collected data classified into the second category in this way, multiple pieces of collected data that should be processed simultaneously can be received at the same time, thereby improving the control accuracy of the hydraulic excavator 100 through real-time processing by the server 201.

In the example of FIG. 14, the upload interval of the group with the longer upload interval (group B) among the multiple collected data processed simultaneously is corrected to match the group with the shorter upload interval (group A), but the upload interval of the group with the shorter upload interval (group A) may also be corrected to match the group with the longer upload interval (group B). Also, in the example of FIG. 14, a mechanism is adopted in which the server 201 outputs an upload command to receive desired collected data from the in-vehicle controller 110 at a desired timing, but as in the example described above, a mechanism may also be adopted in which the server 201 outputs a command to the target in-vehicle controller 110 to change the upload interval of the target collected data to a corrected value.

(Receiving collected data from multiple work machines)
Fig. 15 is a timing chart for receiving collected data from a plurality of hydraulic excavators 100 (work machines). In the above, in order to simplify the explanation, an example has been given of a case in which collected data from one hydraulic excavator 100 (work machine) is received, but in an actual work site, a large amount of data is transmitted from a plurality of hydraulic excavators 100 under the control of the server 201, as shown in Fig. 15. Therefore, it can be said that it is a very useful measure to prevent an increase in the server load due to data concentration by carrying out a process of changing the reception time (upload interval from the on-board controller 110) in accordance with the data characteristics of each collected data, as in this embodiment.

In addition, in order to determine the status of work efficiency, work progress, and the like, it is desirable for the server 201 to receive the collected data at the exact time it was collected from multiple work machines. However, when collecting data from multiple work machines, an increase in server load can cause a time lag in receiving the collected data. If the reception time lag continues, the collected data will lose consistency, causing problems in the time management of the collected data when integratedly managing the data collected from multiple work machines. However, if the reception time (upload interval from the on-board controller 110) is changed according to the data characteristics of each collected data, as in this embodiment, an increase in server load due to data concentration can be prevented, and reception time lags can also be prevented.

(others)
The present invention is not limited to the above-described embodiments, and includes various modifications within the scope of the gist of the present invention. For example, the present invention is not limited to those having all the configurations described in the above-described embodiments, and includes those in which some of the configurations are deleted. Also, it is possible to add or replace some of the configurations of one embodiment with the configurations of another embodiment.

The configurations of the controller 110 and server 201 and the functions and execution processes of the configurations may be realized in part or in whole by hardware (e.g., by designing the logic for executing each function in an integrated circuit). The configurations of the controller 110 and server 201 may be realized as a program (software) that is read and executed by an arithmetic processing device (e.g., a CPU) to realize each function of the configurations of the controller 110 and server 201. Information related to the program may be stored in, for example, a semiconductor memory (flash memory, SSD, etc.), a magnetic storage device (hard disk drive, etc.), and a recording medium (magnetic disk, optical disk, etc.).

In addition, in the above explanation of each embodiment, the control lines and information lines are those that are considered necessary for the explanation of the embodiment, but they do not necessarily show all the control lines and information lines related to the product. In reality, it can be considered that almost all components are connected to each other.

2...Traveling body (lower traveling body), 3...Rotating body (upper rotating body), 6...Front working device, 6A...Boom, 6B...Arm, 6C...Bucket, 7...Wireless communication device, 11A...Boom cylinder, 11B...Arm cylinder, 11C...Bucket cylinder, 23...Rotating body attitude sensor, 40...On-board controller, 50A...GNSS antenna, 50B...GNSS antenna, 51...GNSS receiver (position sensor), 61...Laser radar (LIDAR), 62...Camera, 63a...Boom rod pressure sensor, 63b...Boom bottom pressure sensor, 75A ...Boom position sensor, 75B...Arm position sensor, 75C...Bucket position sensor, 100...Hydraulic excavator (work machine), 110...On-board controller, 110...Controller, 200...Construction history information management system, 201...Server, 202...Database (DB), 203...Monitor, 204...Input device, 211...Communication device, 220...Data input unit, 222...Data output unit, 230...Storage unit, 232...Server load management unit, 234...Data generation unit, 240...Collected data classification unit, 242...Upload time change command calculation unit

Claims (7)

A construction history information management system including a server having a communication device that communicates with a plurality of on-board controllers mounted on a plurality of work machines and receives collected data transmitted from the plurality of on-board controllers, and a database into which the collected data received by the communication device is input ,
The server,
classifying the collected data inputted into the database into any one of a plurality of categories including a first category and a second category having a higher priority for use in the server than the first category based on the data characteristics;
When a load index value indicating a load on the server exceeds a predetermined load threshold, a command to change an upload interval to a longer time only for the collected data classified into the first category among the collected data classified into the first category and the collected data classified into the second category is output to an in-vehicle controller, among the multiple in-vehicle controllers , that has transmitted the collected data classified into the first category, and the collected data classified into the first category and the collected data classified into the second category are collected.
A construction history information management system characterized by the above. A construction history information management system including a communication device that communicates with a plurality of on-board controllers mounted on a plurality of work machines and receives collected data that is data transmitted from the plurality of on-board controllers, a database into which the collected data received by the communication device is input, and a server that generates new data based on the collected data input into the database and transmits the generated data as generated data to the plurality of on-board controllers via the communication device,
The server,
Classifying the collected data entered into the database into any one of a plurality of categories including a first category and a second category based on the data characteristics;
when a load index value indicating a load on the server exceeds a predetermined load threshold, a command to change an upload interval of the collected data classified into the first category to a longer time is output to an in-vehicle controller, among the plurality of in-vehicle controllers, that has transmitted the collected data classified into the first category;
a command to change the upload interval of the collected data classified into the second category to a shorter time when the load index value exceeds the predetermined load threshold is output to an on-board controller among the plurality of on-board controllers that transmitted the collected data classified into the second category. In the construction history information management system according to claim 2,
the server classifies collected data, among the collected data imported into the database, whose collection period in the multiple on-board controllers is longer than a predetermined period threshold, into the first category, and classifies collected data, among the collected data imported into the database, whose collection period is shorter than the period threshold, into the second category. In the construction history information management system according to claim 2,
The construction history information management system is characterized in that the server classifies collected data that is not used for real-time processing by the server into the first category, and classifies collected data that is used for real-time processing by the server into the second category, among the collected data imported into the database. In the construction history information management system according to claim 2,
The construction history information management system is characterized in that the server classifies collected data imported into the database into the first category for which no collected data exists that is used simultaneously when the server generates the generated data, and classifies collected data into the second category for which collected data exists that is used simultaneously when the server generates the generated data. In the construction history information management system according to claim 2,
the collected data classified into the second category by the server includes at least one of attitude data of the plurality of work machines, position data of the plurality of work machines, camera image data captured by a camera mounted on the plurality of work machines, and distance sensor data acquired by a distance sensor mounted on the plurality of work machines;
a construction history information management system, characterized in that the collected data classified into the first category by the server includes at least one of data on the volume of soil transported by the plurality of work machines and data on current topography around the plurality of work machines. In the construction history information management system according to claim 1 or 2 ,
The server,
camera image data captured by a camera mounted on a first work machine, position data of the first work machine detected by a position sensor mounted on the first work machine, and attitude data of the first work machine detected by an attitude sensor mounted on the first work machine are received as the collected data and classified into the second category;
a control unit for controlling a vehicle that is running a construction history information management system, the control unit for controlling a vehicle that is running a construction history information management system, the control unit for controlling a vehicle that is running a construction history information management system, and the control unit for controlling a vehicle that is running a construction history information management system.

Images