Congestion rate prediction device and program

Abstract

To provide a congestion rate predictor and a program for the same which can predict a congestion state in a vehicle by a novel method.SOLUTION: A congestion rate predictor in this embodiment has a processing unit. The processing unit utilizes statistic data of a congestion state of a vehicle in a first section constituted of one or plural sections and a first measured value of a congestion state of the vehicle in the first section and predicts a congestion state of a vehicle that is a predicted object in the first section. The processing unit utilizes a difference between the statistic data and the first measured value to find a function to predict a time variation of a congestion state of the specific vehicle in the first section, and can use the function to predict a congestion state in the specific vehicle in the first section.SELECTED DRAWING: Figure 3

Description

[Technical Field]

[0001] The present invention relates to a congestion rate prediction device and a program. [Background technology]

[0002] Conventionally, operators of transportation such as railways have been working on improving transportation facilities and operations by knowing the congestion state of the transportation in order to maintain and improve service levels such as comfort on the transportation. To know the congestion state of the transportation, operators use indicators such as congestion rate (occupancy rate). Furthermore, operators have determined the congestion state of the transportation as a general trend, such as congested sections and congested time periods, by measuring the congestion rate and performing statistical analysis thereof. While advances in measurement technology have made it possible to measure the congestion rate for some sections or some transportation in real time, it is believed that a new, different method is useful for estimating the congestion rate of an entire large-scale line in real time, estimating the congestion rate in detail, such as for each train car, and for efficiently and sequentially predicting changes in congestion rate at future times. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Application Publication No. 2019-99068 Summary of the Invention [Problem to be solved by the invention]

[0004] The problem to be solved by the embodiments of the present invention is to provide a congestion rate prediction device and program that can predict the congestion state of a vehicle using a novel method. [Means for solving the problem]

[0005] According to an embodiment, a congestion rate prediction device includes a processing unit that predicts a target vehicle congestion state in a first section, the first section being composed of one or more sections, by using statistical data on the vehicle congestion state in the first section and a first measurement value of the vehicle congestion state in the first section. [Effects of the Invention]

[0006] The present invention provides a novel method for predicting vehicle congestion conditions. [Brief explanation of the drawings]

[0007] [Figure 1] 1 is a block diagram showing an example of the main configuration of a congestion prediction system according to a first embodiment and components included in the congestion prediction system; [Figure 2] 4 is a flowchart showing an example of processing according to the first embodiment by a processor of the congestion prediction server in FIG. 1; [Figure 3] 4 is a flowchart showing an example of processing according to the first and second embodiments by a processor of the congestion prediction server in FIG. 1; [Figure 4] A graph showing the distribution of congestion by car. [Figure 5] A graph of the table of fluctuations. [Figure 6] A diagram showing the congestion rate of multiple trains at each station section from Station A to Station G. [Figure 7] 10 is a graph showing an example of a change in congestion rate over time. [Figure 8] 10 is a graph showing an example of a change in difference over time. [Figure 9] FIG. 1 is a block diagram showing an example of the main configuration of a congestion prediction system according to second to fourth embodiments and components included in the congestion prediction system. [Figure 10] 10 is a flowchart showing an example of processing according to the second to fourth embodiments by a processor of the congestion prediction server in FIG. [Figure 11]10 is a flowchart showing an example of processing according to the third and fourth embodiments by a processor of the congestion prediction server in FIG. [Figure 12] 10 is a flowchart showing an example of processing according to the fourth embodiment by a processor of the congestion prediction server in FIG. [Figure 13] 10 is a graph showing an example of a change in congestion rate over time. [Figure 14] 10 is a graph showing an example of a change over time in a differential congestion rate. DETAILED DESCRIPTION OF THE INVENTION

[0008] Hereinafter, congestion prediction systems according to several embodiments will be described with reference to the drawings. Note that the scale of each part in each drawing used in the following description of the embodiments may be changed as appropriate. Also, for the sake of explanation, each drawing used in the following description of the embodiments may omit configurations. Also, in each drawing and in this specification, the same reference numerals indicate similar elements.

[0009] [First embodiment] FIG. 1 is a block diagram showing an example of the main configuration of a congestion prediction system 1 according to the first embodiment and the components included in the congestion prediction system 1. The congestion prediction system 1 is a system that calculates the congestion rate of each train on a railway. The congestion rate is, for example, the ratio of the number of passengers to the capacity of the train or vehicle. However, the congestion rate may be defined in other ways. The congestion prediction system 1 includes, as an example, a congestion prediction server 100, an operation management system 200, a measurement device 300, and a congestion rate management system 400.

[0010] The congestion prediction server 100, the operation control system 200, the measurement device 300, and the congestion rate management system 400 are connected to a network NW. The network NW is typically a communication network including the Internet. The network NW is typically a communication network including a WAN (wide area network). The network NW may be a communication network including a private network such as an intranet. The network NW may be a communication network including a LAN (local area network). Furthermore, the network NW may be a wireless line or a wired line, or may be a mixture of wireless and wired lines. Furthermore, the network NW may be a communication network including a dedicated line or a public mobile phone network.

[0011] The congestion prediction server 100 is a device that calculates the congestion rate of each train on a railway. The congestion prediction server 100 may be a single device or may be a device consisting of multiple devices. The congestion prediction server 100 includes, as an example, a processor 110, a ROM (read-only memory) 120, a RAM (random-access memory) 130, an auxiliary storage device 140, and a communication I / F (interface) 150. A bus 160 and the like connect these components. The congestion prediction server 100 is an example of a congestion rate prediction device.

[0012] The processor 110 is the central part of the computer that performs various calculations and processes, such as calculations and controls, necessary for the operation of the congestion prediction server 100. The processor 110 may be, for example, a central processing unit (CPU), a microprocessing unit (MPU), a system on a chip (SoC), a digital signal processor (DSP), a graphics processing unit (GPU), an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a field-programmable gate array (FPGA). Alternatively, the processor 110 may be a combination of these. The processor 110 may also be a combination of these with a hardware accelerator. The processor 110 controls each component to realize various functions of the congestion prediction server 100 based on programs such as firmware, system software, and application software stored in the ROM 120 or the auxiliary storage device 140. The processor 110 also executes the processes described below based on the programs. Note that some or all of the programs may be incorporated into the circuitry of the processor 110. Moreover, the processor 110 is an example of a processing unit.

[0013] The ROM 120 and RAM 130 are the main memory devices of the computer with the processor 110 at its core. The ROM 120 is a non-volatile memory used exclusively for reading data. The ROM 120 stores, for example, firmware among the above programs. The ROM 120 also stores data used by the processor 110 when it performs various processes. The RAM 130 is a memory used for reading and writing data. The RAM 130 is used as a work area for storing data that is temporarily used when the processor 110 performs various processes. The RAM 130 is typically a volatile memory.

[0014] The auxiliary storage device 140 is an auxiliary storage device of a computer centered around the processor 110. The auxiliary storage device 140 is, for example, an EEPROM (electric erasable programmable read-only memory), an HDD (hard disk drive), or a flash memory. The auxiliary storage device 140 stores, for example, system software and application software among the above programs. The auxiliary storage device 140 also stores data used by the processor 110 when performing various processes, data generated by the processes in the processor 110, various setting values, and the like.

[0015] The auxiliary storage device 140 also stores a congestion database 141. The congestion database 141 is a database that manages and stores data such as congestion rates determined by analysis processing, which will be described later. The congestion prediction server 100 refers to the congestion database 141 when predicting congestion rates.

[0016] The communication I / F 150 is an interface for the congestion prediction server 100 to communicate via a network NW or the like.

[0017] The bus 160 includes a control bus, an address bus, a data bus, etc., and transmits signals exchanged among the various parts of the congestion prediction server 100 .

[0018] The traffic control system 200 is a system that performs railway traffic control and the like. The traffic control system 200 also stores various information related to railway operations. The traffic control system 200 includes, for example, a server.

[0019] The measuring device 300 is a device that measures the congestion rate of each car of a railway train using a sensor or the like. The sensor is, for example, a load-adjusting device or a camera. The load-adjusting device is mounted on, for example, each car. The load-adjusting device is a sensor that measures the live load of the car. The measuring device 300 calculates the congestion rate from the live load using a predetermined calculation formula or the like. The camera is, for example, installed on the outside of the rail and takes pictures of the car from the outside side. Alternatively, the camera is installed inside the car and takes pictures of the interior of the car. The measuring device 300 measures the congestion rate by image recognition of the number of passengers on board from the images captured by the camera. The congestion rate measured by the measuring device 300 is, for example, a real-time measurement value. The measuring device 300 transmits the measured congestion rate to the congestion rate management system 400 or the like. The congestion rate management system 400 stores the received congestion rates by train, car, and station section. The congestion rate management system 400 also associates and stores situation data indicating the status of the station or station section at the time of measuring the congestion rate. The situation includes, for example, operation information such as date and time, day of the week, weather, weather forecast, and schedule disruptions, as well as whether or not an event is being held nearby and the scale of the event. The congestion rate management system 400 also associates and stores the starting station and destination of the train for which the congestion rate is being measured, its type (such as local or express), the type and number of carriages, and other train information. The congestion rate management system 400 acquires operation information and train information from, for example, the traffic management system 200.

[0020] The congestion rate may be measured visually by a person. In this case, a person in charge inputs the congestion rate measured by a person into the congestion rate management system 400. The congestion rate management system 400 stores the congestion rate.

[0021] The congestion rate management system 400 stores and manages the measurement values of the congestion rate measured by the measuring device 300, etc., as described above. The congestion rate management system 400 includes, for example, a server.

[0022] The operation of the congestion prediction system 1 according to the first embodiment will be described below with reference to Figures 2 and 3. Note that the processing content in the operational description is an example, and various processing that can achieve similar results can be used as appropriate. Figures 2 and 3 are flowcharts showing an example of processing by the processor 110 of the congestion prediction server 100. The processor 110 executes the processing of Figures 2 and 3 based on a program stored in the ROM 120 or the auxiliary storage device 140, for example. The processor 110 starts the processing of FIGS. 2 and 3, for example, based on the activation of the congestion prediction server 100 or the activation of an application for congestion prediction.

[0023] The process shown in FIG. 2 is a process that includes a process (hereinafter referred to as "analysis process") of obtaining various data to be used for predicting the congestion rate using past congestion rate data such as the congestion rate. In step ST11 of FIG. 2, the processor 110 of the congestion prediction server 100 determines whether to start analysis processing. The analysis processing refers to the processing of steps ST12 to ST17. The processor 110 determines to perform analysis processing when, for example, a predetermined condition is met. The predetermined condition may be that a predetermined period of time has elapsed since the previous analysis processing, or that a state in which the difference between the predicted congestion rate and the measured congestion rate is large occurs frequently. Examples of a state in which a state in which the difference between the predicted congestion rate and the measured congestion rate is large frequently include a state in which the average value of the square or absolute value of the difference is larger than a predetermined value, a state in which the frequency at which the square or absolute value of the difference is larger than a predetermined value is greater than or equal to a predetermined value, or a state equivalent to these. The predetermined condition may be, for example, that an input instructing the analysis processing to be performed has been received. The input may be based on, for example, an operation input using a console of the congestion prediction server 100 or the like. Alternatively, the input may be based on a command transmitted from another device or the like and input to the communication I / F 150. The command indicates an instruction to perform analysis processing.

[0024] In step ST12, the processor 110 acquires data to be used for analysis processing (hereinafter referred to as "analysis data") from the traffic control system 200, the congestion rate management system 400, etc. The analysis data includes, for example, route data, timetables, and congestion rate data for each train and each vehicle at each station from a predetermined past date and time to the present. The processor 110 acquires, for example, data such as route data and timetables from the traffic control system 200, and congestion rate data from the congestion rate management system 400. The processor 110 instructs the communication I / F 150 to send a request to the traffic management system 200 and the congestion rate management system 400 to send analysis data. Upon receiving this transmission instruction, the communication I / F 150 sends the request to the traffic management system 200 and the congestion rate management system 400. The sent request is received by the traffic management system 200 and the congestion rate management system 400. Then, in response to receiving the request, the traffic management system 200 and the congestion rate management system 400 send analysis data to the congestion prediction server 100. The data is received by the communication I / F 150 of the congestion prediction server 100.

[0025] In step ST13, the processor 110 uses the analysis data to determine (calculate) the average train congestion rate for each station section. The average train congestion rate for a station section is the average train congestion rate from when the train departs from a station to when it arrives at the next station. For example, the average train congestion rate for the Station A-Station B section is the average train congestion rate from when the train departs from Station A to when it arrives at Station B. The congestion rate for the Station A-Station B section may be, for example, the congestion rate when the train departs from or passes through Station A, the congestion rate when it arrives at or passes through Station B, or the congestion rate when it arrives at or passes through a position between Station A and Station B. Note that Station B is assumed to be the station next to Station A. The average train congestion rate is also the average train congestion rate for a predetermined period. Therefore, the average train congestion rate for a train consisting of multiple cars is the same as the average congestion rate of each car of the train. The processor 110 determines the average train congestion rate, for example, for each departure time. The departure time may be a time listed on the timetable or an actually measured time. For example, the processor 110 separately calculates the average train congestion rate for the train departing at 8:10 and the average train congestion rate for the train departing at 8:14. Alternatively, the processor 110 may calculate the average train congestion rate for each time slot of the departure time. For example, the processor 110 calculates the average train congestion rate for trains departing between 8:00 and 8:15 and the average train congestion rate for trains departing between 8:15 and 8:30. The processor 110 also calculates the average train congestion rate for various conditions other than the departure time. The conditions used to classify the average train congestion rate and other conditions are hereinafter referred to as "congestion conditions." The processor 110 may use some or all of the conditions listed below as congestion conditions, or may use conditions not listed below. Examples of such conditions include the following. The processor 110 may also calculate the average train congestion rate without classifying the conditions based on congestion conditions. ·day of week ·Whether it is a weekday, Saturday, Sunday or public holiday, etc. ·Train information ·Train information ·weather ·weather forecast · Whether it is a long weekend or not. Season or time of year ·Calendar such as month and day -Whether or not there is an event taking place near the station, and the scale of the event.

[0026] As one example, processor 110 separately calculates the average train congestion rate for trains departing at 8:14 on weekdays and the average train congestion rate for trains departing on Sundays at 8:14. As another example, processor 110 separately calculates the average train congestion rate for trains departing at 8:14 on sunny spring weekdays, the average train congestion rate for trains departing at 8:14 on rainy spring weekdays, and the average train congestion rate for trains departing at 8:14 on sunny summer weekdays.

[0027] The processor 110 also stores the calculated average train congestion rate in the congestion database 141 in association with information indicating the congestion conditions used to classify the average train congestion rate.

[0028] In step ST14, processor 110 uses the analysis data to determine the congestion distribution by car. The congestion distribution by car indicates the congestion rate for each car (car number) of the train. Processor 110 may determine the congestion distribution by car by dividing the conditions, as with the average train congestion rate determined in step ST13, or may determine the distribution by car without dividing the conditions. Processor 110 may also determine the distribution by car under congestion conditions different from those in step ST13. The congestion distribution by car indicates, for example, how many times the average congestion rate of the car is compared to the average train congestion rate for each car. Therefore, the congestion rate of a car for which the value of the congestion distribution by car is 1 will be the same as the average train congestion rate for the same congestion conditions.

[0029] The processor 110 also stores the calculated congestion distribution by car in the congestion database 141 in association with information indicating the congestion conditions used to classify the congestion distribution by car.

[0030] The processor 110 may use the previously calculated average train congestion rate or the previously calculated congestion distribution by car instead of calculating it in the current process. In this case, the processor 110 obtains the previously calculated average train congestion rate or the previously calculated congestion distribution by car from the congestion database 141.

[0031] In step ST15, processor 110 calculates the congestion rate by car. The congestion rate by car is the congestion rate of each car. Processor 110, for example, multiplies the average train congestion rate by the congestion distribution by car of each car. This allows processor 110 to calculate the congestion rate of each car for each congestion condition. The congestion rate by car is calculated by multiplying the average train congestion rate by the congestion distribution by car of each car, and is therefore categorized by conditions in the same way as the average train congestion rate.

[0032] FIG. 4 is a graph of the congestion distribution by car. FIG. 4 shows an example of the congestion rate by car for a train under specific congestion conditions. The train includes eight cars, from car 1 to car 8. FIG. 4 shows the congestion rate by car for each of cars 1 to 8 of the train in a bar graph. The broken line La shows the bar graph as a line graph. FIG. 4 also shows the congestion rate Ca, which indicates the average congestion rate of the train. In the congestion rate by car shown in FIG. 4, cars 1, 2, 4, and 5 have lower congestion rates than the train average congestion rate. In other words, the congestion distribution values by car for these cars are less than 1. Furthermore, cars 3, 6, 7, and 8 have higher congestion rates than the train average congestion rate. In other words, the congestion distribution values by car for these cars are greater than 1.

[0033] In step ST16, processor 110 creates a variation table. The variation table is, for example, a table showing the variation in the congestion rate by car for each station section for each car of a train. Processor 110 creates the variation table, for example, using the congestion rate by car. The variation table may be categorized by conditions, as with the congestion rate by car, or may not be categorized by conditions. When creating a variation table for a certain condition, processor 110 creates the variation table using the congestion rate by car that meets the certain condition. As an example, processor 110 creates the variation table using data clustering. The congestion rate of a specific car in a specific station section in a variation table for a certain condition is the average of the congestion rates by car for the same condition, station section, and car. For example, in a variation table where the condition is a sunny day, the congestion rate of car 3 in the section between stations B and C at 9:00 is the average of the congestion rates by car for car 3 in the section between stations B and C at 9:00 on a sunny day. The congestion rate for each car may be 9:00 on a sunny day, and may be any condition not included in the conditions of the fluctuation table, such as season. Alternatively, the processor 110 may use the congestion rate stored in the congestion rate management system 400 instead of the congestion rate for each car. When the fluctuation table is categorized by conditions, for example, the average congestion rate for each station section of the train departing from Station A at 7:50 on a holiday can be determined from the fluctuation table. The fluctuation table is an example of fluctuation information that shows changes in the train congestion state for each station section. The fluctuation table is also an example of data that shows the correlation between the first section and the second section.

[0034] FIG. 5 is a graph of the fluctuation table. FIG. 5 shows an example of a fluctuation table for a specific car of a train under specific congestion conditions. Assume that the train in question travels through stations A, B, C, D, E, F, and G in this order. FIG. 5 shows the congestion rate by car for each station section of the specific car in a bar graph. The broken line Lb is a line graph of the bar graph.

[0035] In step ST17, processor 110 creates a time series model for each congestion condition for each station section. The time series model is, for example, a function of time that indicates the change in train congestion rate for each car in the station section over time. When processor 110 creates a time series model for a specific station section under specific congestion conditions, it uses the congestion rate for each car under the congestion conditions in the station section. Processor 110 obtains the time series model from the congestion rate for each car using the least squares method, an autoregressive model (AR), an autoregressive moving average model (ARMA), an autoregressive integrated moving average model (ARIMA), a state space model, or the like. Alternatively, processor 110 may use a straight line connecting the congestion rates for each car in chronological order as the time series model. The time series model is an example of statistical data on the train congestion state in the station section.

[0036] In step ST18, processor 110 stores each data such as the congestion rate by car, the fluctuation table, and the time series model obtained by the analysis process in congestion database 141. After processing step ST18, processor 110 returns to step ST11.

[0037] The process shown in Fig. 3 includes a process for predicting the congestion rate by car using a congestion rate by car number, a fluctuation table, etc. The process shown in Fig. 3 will be described with reference to Fig. 6. FIG. 6 is a diagram showing the congestion rates of multiple trains in each station section from Station A to Station G. The congestion rates are measured, for example, by a measurement device 300. The level of each point, from congestion rate A1 to congestion rate F6, indicates the congestion rate. However, because showing all the symbols for congestion rates A1 to F6 in FIG. 6 would make the diagram difficult to read, some symbols have been omitted. Note that the symbols for each point indicating the congestion rate consist of two parts: an alphabet on the left and a number on the right. For example, "A1" includes two parts: the alphabet "A" on the left and the number "1" on the right. The alphabet on the left indicates the station in the station section where the train arrives first. For example, A indicates the Station A-Station B section, B indicates the Station B-Station C section, and C indicates the Station C-Station D section. The number on the right indicates the order in which the train passes through the station section. Note that the time when a train passes through a station section indicates, for example, the time when the train passes a specific position within the station section. The location may be, for example, a station at the end of the station section or a location in between. For example, the time when a train passes through the station A-station B section refers to the time when the train departs from or passes through station A, the time when the train arrives at or passes through station B, or the time when the train arrives at or passes through a specific location between stations A and B. The time when a train passes through a station section is not limited to an actually measured time, but may also be a time on a timetable. For example, congestion rate A1 indicates the congestion rate of the first train passing through the station A-station B section. In this case, congestion rate A2 indicates the congestion rate of the second train passing through the station A-station B section. That is, after the train corresponding to congestion rate A1 passes through the station A-station B section, the train passing through the station A-station B section next is the train corresponding to congestion rate A2. For example, congestion rate C3 indicates the congestion rate of the third train passing through the station C-station D section. Note that a train corresponding to a code with a digit 1 on the right may pass through the station section before the train corresponding to the code passes through the station section. Furthermore, the same digits on the right indicate the same train. Therefore, congestion rates A1 to F1 all indicate the congestion rates of the same train. The congestion rate of a specific train between station A and station B is congestion rate A1, the congestion rate of that specific train between station B and station C is congestion rate B1, the congestion rate of that specific train between station C and station D is congestion rate C1, and so on. The congestion rates shown in Figure 6 are representative examples of the congestion rates of specific cars.The specific car number can be any car number, but as an example, if congestion rate A1 indicates the congestion rate of car 3, congestion rates A1 to F6 all indicate the congestion rates of car 3.

[0038] Here, the processing of FIG. 3 will be explained using an example in which other congestion rates are predicted using congestion rates C1 to C4. In this case, the station C-D section is an example of a first section. The first section may consist of one station section or may consist of multiple station sections. Also, there may be another station between stations in one station section. Also, a station section is not limited to a section between stations. For example, a marshalling yard, a signal box, or a station may be used instead of a station.

[0039] In step ST21 of FIG. 3, the processor 110 determines whether to start predicting a congestion rate. For example, when the congestion rate management system 400 acquires a new, latest congestion rate of a train from the measurement device 300, the processor 110 determines to start predicting a congestion rate using the actual congestion rate measurement value of the train. If the processor 110 does not determine to start predicting a congestion rate, it determines No in step ST21 and repeats the processing of step ST21. On the other hand, if the processor 110 determines to start predicting a congestion rate, it determines Yes in step ST21 and proceeds to step ST22. Here, it is assumed that the latest congestion rate newly acquired by the congestion rate management system 400 is congestion rate C4.

[0040] In step ST22, the processor 110 acquires congestion rate data to be used for predicting the congestion rate from the congestion rate management system 400 or the like. Here, the processor 110 can acquire real-time congestion rates, etc. As an example, the processor 110 acquires congestion rates C1 to C4 as the congestion rate data. The processor 110 also acquires situation data stored in association with each congestion rate data. The multiple congestion rate data for the same station section acquired in step ST22, such as the congestion rates C1 to C4, are an example of a first measurement value of the train congestion state in the station section.

[0041] In step ST23, the processor 110 acquires a time series model and a fluctuation table, etc., to be used for predicting the congestion rate from the congestion database 141. The time series model used for predicting the congestion rate is a time series model of congestion conditions that match the situation indicated by the situation data acquired in step ST22. The time series model used for predicting the congestion rate is a time series model of the same station section as the station section of the congestion rate data acquired in step ST22. The fluctuation table used for predicting the congestion rate is a fluctuation table of congestion conditions that match the situation indicated by the situation data acquired in step ST22. The fluctuation table used for predicting the congestion rate is a fluctuation table for the train whose congestion rate is to be predicted.

[0042] In step ST24, processor 110 calculates the difference between the congestion rate data acquired in step ST22 and the time series model acquired in step ST23. The relationship between the measured congestion rate data, the time series model, and the difference will be described with reference to Fig. 7. FIG. 7 is a graph showing an example of a change in congestion rate over time. In the graph of FIG. 7, the horizontal axis represents time (hour) and the vertical axis represents congestion rate. In FIG. 7, point Pa is plotted as an example of congestion rate data acquired in step ST22. However, point Pa shown in FIG. 7 is a different example from congestion rates C1 to C4. Curve Lc shows an example of a time series model acquired in step ST23. Furthermore, difference Da shows the difference in congestion rate between point Pa and curve Lc. Furthermore, difference Da shows an example of the difference between statistical data and a measured value.

[0043] In step ST25, the processor 110 calculates a predicted value of the difference from the difference calculated in step ST24. For example, the processor 110 expresses the difference as a function of time (hereinafter referred to as a "difference function") using the least squares method, AR, ARMA, ARIMA, a state space model, or the like. The relationship between the difference and the difference function will be explained using FIG. 8. FIG. 8 is a graph showing an example of how the difference changes over time. In the graph of FIG. 8, the vertical axis represents the difference in congestion rate, and the horizontal axis represents time. Point Pb is the difference Da plotted on the graph. Curve Ld shows an example of a difference function calculated from the difference Da. By using the difference function, it is possible to predict the difference for times beyond the latest point Pb.

[0044] In step ST26, the processor 110 uses a differential function to predict the congestion rate for a time beyond the latest point Pa in FIG. 7. The curve Le is a function of time (hereinafter referred to as the "time series prediction function") that indicates a predicted value of the change in congestion rate over time, and is a function obtained by adding a time series model and a differential function. For example, if the time series model is function Fa(t), the differential function is function Fb(t), and the time series prediction function is function Fc(t), then Fc(t) = Fa(t) + Fb(t). The processor 110 can calculate the congestion rate Fc(t) at any time by using the time series prediction function. For example, the processor 110 calculates the congestion rate at the time a train passes through the station section from the time series prediction function. As an example, the processor 110 calculates the congestion rate C5 and the congestion rate C6 using the time series prediction function. When calculating the congestion rate for a station section, processor 110 uses a time series prediction function to calculate the congestion rate at the time the train departs from the station that the train will arrive at first in the station section. As an example, when calculating the congestion rate for the station C-D section, processor 110 uses the time series prediction function to calculate the congestion rate at the time the train departs from station C. Alternatively, processor 110 may use the time series prediction function to calculate the congestion rate at the time the train passes through or arrives at a specific position in the station section. The time series prediction function is an example of a function that predicts changes over time in the train congestion state in the station section.

[0045] In step ST27, processor 110 estimates the congestion rate of a station section different from the target congestion rate using the target congestion rate and the fluctuation table acquired in step ST23. The target congestion rate is a known congestion rate used to estimate the congestion rate in step ST27. The target congestion rate is, for example, the congestion rate acquired in step ST22 and the congestion rate calculated in step ST26. Processor 110 estimates the congestion rate of a station section different from the target congestion rate for the same train and car as the target congestion rate using one target congestion rate (hereinafter referred to as "congestion rate Xa") and a fluctuation table (hereinafter referred to as "target fluctuation table") that has the same train and car as the congestion rate Xa. In the target fluctuation table, the congestion rate of the station section that is the same as the congestion rate Xa is set to congestion rate Ya. Processor 110 calculates the difference between congestion rate Xa and congestion rate Ya. As an example, the processor 110 calculates the difference α between the congestion rates Xa and Ya as a value indicating how much the congestion rates Xa and Ya differ from each other. For example, the difference α can be calculated using the following formula (1). α = Xa - Ya (1) Here, the congestion rate to be estimated is assumed to be congestion rate Xb. Also, in the target variation table, the congestion rate of the same station section as the congestion rate Xb is assumed to be congestion rate Yb. In this case, the processor 110 calculates the congestion rate Xb using, for example, the following formula (2). Xb=Yb+α (2) Furthermore, processor 110 calculates a ratio β between congestion rate Xa and congestion rate Ya as a value indicating how much the congestion rate Xa and congestion rate Ya differ from each other. For example, ratio β can be calculated using the following equation (3). β=Xa÷Ya (3) In this case, the processor 110 calculates the congestion rate Xb using, for example, the following equation (4). Xb=Yb×β (4)

[0046] As an example, processor 110 calculates congestion rates A5, B5, and D5 to F6 using the congestion rate C5 calculated in step ST26 and a fluctuation table that has the same train and car number as congestion rate C5. In this case, congestion rate C5 is congestion rate Xa, and congestion rates A5, B5, and D5 to F6 are congestion rate Xb. In this case, the Station C-D section is an example of a first section, and the Station A-B section, the Station B-C section, the Station D-E section, the Station E-F section, and the Station F-G section are each an example of a second section.

[0047] In step ST28, the processor 110 stores the congestion rates predicted in steps ST27 and ST28 in the congestion database 141.

[0048] In step ST29, the processor 110 instructs the communication I / F 150 to transmit the congestion rate predicted in step ST27 and step ST28 to various devices. The various devices are devices that perform some kind of processing using the estimated congestion rate. The various devices are, for example, computers installed in stations or on trains. The computers, for example, notify station staff or train crew members of the received congestion rate. The computers notify the congestion rate by displaying it on a display such as an LCD display. Alternatively, the various devices are devices such as servers that provide a service that provides users with estimated congestion rates. The servers transmit the received congestion rate to terminals such as personal computers (PCs) or smartphones used by users. After processing step ST29, processor 110 returns to step ST21.

[0049] According to the congestion prediction system 1 of the first embodiment, the congestion prediction server 100 predicts the congestion rate using a time series model and congestion rate data. In this way, the congestion prediction server 100 can predict the congestion rate using a novel method. Furthermore, by using such a method, it is believed that the congestion prediction server 100 can predict the congestion rate more accurately and quickly than conventional methods. Therefore, the congestion prediction server 100 can estimate the congestion rate of an entire large-scale route in real time. Furthermore, the congestion prediction server 100 can estimate detailed congestion rates, such as for each train car. Changes in the congestion rate at future times can be efficiently and sequentially predicted. Furthermore, the congestion prediction server 100 can efficiently obtain real-time congestion predictions for each train car in a large-scale route network.

[0050] Furthermore, according to the congestion prediction system 1 of the first embodiment, the congestion prediction server 100 obtains a time series prediction function and predicts the congestion rate using the time series prediction function. In this way, the congestion prediction server 100 can predict the congestion rate using a novel method. Furthermore, by using such a method, it is believed that the congestion prediction server 100 can predict the congestion rate more accurately and quickly than conventional methods.

[0051] Furthermore, according to the congestion prediction system 1 of the first embodiment, the congestion prediction server 100 predicts the congestion rate using a fluctuation table. In this way, the congestion prediction server 100 can predict the congestion rate using a novel method. Furthermore, by using such a method, it is believed that the congestion prediction server 100 can predict the congestion rate more accurately and quickly than before.

[0052] Second Embodiment The congestion prediction system of the second embodiment estimates passenger flow and calculates the average train congestion rate. FIG. 9 is a block diagram showing an example of the main configuration of a congestion prediction system 1b according to the second embodiment and components included in the congestion prediction system 1b. The congestion prediction system 1b includes a ticket gate system 500 in addition to the congestion prediction system 1 of the first embodiment. The ticket gate system 500 is connected to a network NW.

[0053] The ticket gate system 500 includes an automatic ticket gate and a server. The ticket gate system 500 is a system that manages passengers' entry and exit through the ticket gates. The ticket gate system 500 records the entry and exit information of each passenger and transmits it to the congestion prediction server 100. The communication I / F 150 of the congestion prediction server 100 receives the entry and exit information. The processor 110 stores the entry and exit information in the congestion database 141. The entry and exit information includes information indicating the passenger's entry station, entry time, exit station and exit time, etc. The entry and exit information may also include information indicating intermediate stations. The entry and exit information is an example of boarding and alighting information that indicates where the passenger boarded the vehicle and where he or she disembarked. The passenger is also an example of a train user.

[0054] The operation of the congestion prediction system 1b according to the second embodiment will be described below with reference to Fig. 10, Fig. 3, etc. Fig. 10 is a flowchart showing an example of processing by the processor 110 of the congestion prediction server 100. The processor 110 executes the processing of Fig. 10 based on a program stored in the ROM 120 or the auxiliary storage device 140, for example. The processor 110 starts the process of FIG. 10, for example, based on the activation of the congestion prediction server 100 or the activation of an application for congestion prediction.

[0055] The processor 110 performs the processing of Fig. 10 instead of the processing of Fig. 2 in the first embodiment. The processor 110 also performs the processing of Fig. 3, as in the first embodiment. Regarding the operation of the congestion prediction system 1b in the second embodiment, differences from the first embodiment will be described.

[0056] After processing step ST12 in FIG. 10, processor 110 proceeds to step ST31. In step ST31, the processor 110 acquires entry / exit information for a predetermined period from the congestion database 141. Here, it is preferable that the processor 110 acquires the entry / exit information for the predetermined period for which operation is normal, excluding the portion for which operation is abnormal. The processor 110 acquires, for example, information indicating which period of operation is normal and which period of operation is abnormal from the operation management system 200. Then, the processor 110 uses this information to exclude the portion for which operation is abnormal from the entry / exit information.

[0057] In step ST32, processor 110 estimates the number of people passing through each station section by time period using the entrance / exit information acquired in step ST31. If the irregular service has been removed in step ST31, this entrance / exit information is the entrance / exit information for the normal service. For example, processor 110 can estimate that a passenger who entered at station STA1 and exited at another station STA2 passed through station section SS1. However, if there are multiple routes from station STA1 to station STA2, not all passengers who entered at station STA1 and exited at station STA2 may have passed through station section SS1. The proportions of passengers who take which routes from station STA1 to station STA2 are predetermined. For example, if there are three routes from station STA1 to station STA2, routes RO1 to RO3, the proportions are determined as follows: 50% of passengers take route RO1, 30% take route RO2, and 20% take route RO3. Processor 110 estimates the number of passengers who boarded at station STA1 and disembarked at station STA2 based on this ratio, i.e., how many of them passed through station section SS1. As an example, if only route RO1 includes station section SS1, processor 110 estimates that 50% of passengers who entered at station STA1 and exited at station STA2 passed through station section SS1. Processor 110 also estimates the time that passengers passed through station section SS1 based on the time that they entered station STA1. As an example, processor 110 estimates that passengers who entered between time t1 and time t2 will pass through station section SS1 at time t3. The relationship between time t1, time t2, and time t3 is predetermined based on, for example, a timetable. Alternatively, processor 110 may calculate time t3 from a timetable. Processor 110 similarly estimates the number of passengers who will pass through station section SS1 for each combination of entry station and exit station. Then, processor 110 estimates the number of people passing through station section SS1 for each time period by adding up the number of people passing through station section SS1 for each combination for each time period. Processor 110 also estimates the number of people passing through station sections other than station section SS1 for each time period in the same way.

[0058] In step ST33, processor 110 calculates the average train congestion rate for each time period using the number of passengers for each time period estimated in step ST32. For example, let NP1 be the number of passengers passing through station section SS1 during a certain time period. Let CA1 be the total number of passengers on trains passing through station section SS1 during that time period. In this case, the average train congestion rate for that time period can be calculated, for example, using the following formula (5): (Average train congestion rate) = NP1 ÷ CA1 (5) The processor 110 similarly calculates the average train congestion rate for each time period in each station section using equation (5) or the like. After processing step ST33, the processor 110 proceeds to step ST14. In the second embodiment, the processor 110 performs each process using the average train congestion rate calculated in step ST33 instead of the average train congestion rate calculated in step ST13 in the first embodiment.

[0059] The congestion prediction system 1b of the second embodiment can obtain the same effects as those of the first embodiment.

[0060] Furthermore, according to the congestion prediction system 1b of the second embodiment, the congestion prediction server 100 calculates the congestion rate using entry / exit information, which allows the congestion prediction server 100 to calculate the congestion rate with higher accuracy.

[0061] Third Embodiment The congestion prediction system of the third embodiment corrects the fluctuation table using the congestion rate of a running train. The configuration of the congestion prediction system 1b of the third embodiment is the same as that of the second embodiment, and therefore description thereof will be omitted. Note that the configuration of the congestion prediction system of the third embodiment may be the same as that of the first embodiment.

[0062] The operation of the congestion prediction system 1b according to the third embodiment will be described below with reference to Fig. 10 and Fig. 11. Fig. 11 is a flowchart showing an example of processing by the processor 110 of the congestion prediction server 100. The processor 110 executes the processing of Fig. 11 based on a program stored in the ROM 120 or the auxiliary storage device 140, for example. The processor 110 starts the process of FIG. 11, for example, based on the activation of the congestion prediction server 100 or the activation of an application for congestion prediction.

[0063] The processor 110 performs the processing of Fig. 11 instead of the processing of Fig. 3 of the second embodiment. Moreover, the processor 110 of the third embodiment performs the processing of Fig. 10 as in the second embodiment. Regarding the operation of the congestion prediction system 1b of the third embodiment, the parts that differ from the second embodiment will be described.

[0064] After processing step ST26 in FIG. 11, processor 110 proceeds to step ST41. In step ST41, the processor 110 acquires, from the congestion rate management system 400 or the like, the congestion rate measured by the measurement device 300 for the train whose congestion rate is to be predicted, from the starting station to the current running position. As an example, when predicting a congestion rate D5, the train corresponding to the congestion rate D5 is the train to be predicted. The congestion rate acquired in step ST41 will be referred to as the "measured congestion rate" hereinafter. The measured congestion rate is an example of a second measurement value of the congestion state of the vehicle to be predicted.

[0065] In step ST42, processor 110 corrects the target fluctuation table using the measured congestion rate. For example, processor 110 calculates the difference or ratio between the congestion rate of each station section in the target fluctuation table and the measured congestion rate. Then, processor 110 predicts the difference or ratio for each station section to which the train to be predicted has not yet arrived using the least squares method, AR, ARMA, ARIMA, or a state space model, etc., using the difference or ratio. Then, processor 110 corrects the fluctuation table using the predicted difference or ratio. After processing step ST42, processor 110 proceeds to step ST27. Processor 110 performs the processing of step ST27 using the corrected fluctuation table.

[0066] The congestion prediction system 1b of the third embodiment can obtain the same effects as those of the second embodiment.

[0067] Furthermore, according to the congestion prediction system 1b of the third embodiment, the congestion prediction server 100 corrects the fluctuation table using the congestion rate of the train for which the congestion rate is to be predicted, measured by the measurement device 300. This allows the congestion prediction server 100 to calculate the congestion rate with higher accuracy.

[0068] [Fourth embodiment] The congestion prediction system of the fourth embodiment estimates the congestion rate when an abnormality occurs in railway operation using a method different from that used during normal times. The congestion prediction system of the fourth embodiment also estimates the expected time for the congestion rate during the abnormal time to return to the normal congestion rate. In many cases, transportation operations are significantly restricted on routes where an abnormality has occurred. Furthermore, there are a variety of causes of the abnormality and methods for dealing with the problem. Furthermore, passenger responses vary depending on the content of the information provided. For this reason, predicting congestion on routes where an abnormality has occurred is more difficult than predicting congestion on other routes. Therefore, for example, it is preferable to prioritize providing information on the expected resumption of service for routes where an abnormality has occurred. It is also possible to use the congestion prediction system of the fourth embodiment to estimate the impact of congestion on routes connected to the route where an abnormality has occurred or neighboring routes, predict the abnormal congestion state, and predict the time it will take to return to normal. However, it is also possible to use the congestion prediction system of the fourth embodiment for routes where an abnormality has occurred.

[0069] The configuration of the congestion prediction system 1b of the fourth embodiment is the same as that of the third embodiment, and therefore a description thereof will be omitted.

[0070] The operation of the congestion prediction system 1b according to the fourth embodiment will be described below with reference to Figs. 10 to 12. Fig. 12 is a flowchart showing an example of processing by the processor 110 of the congestion prediction server 100. The processor 110 executes the processing of Fig. 12 based on a program stored in the ROM 120 or the auxiliary storage device 140, for example. The processor 110 starts the process of FIG. 12, for example, based on the activation of the congestion prediction server 100 or the activation of an application for congestion prediction.

[0071] The processor 110 of the fourth embodiment performs the processes of Figures 10 and 11 in the same way as in the third embodiment. Furthermore, the processor 110 performs the process of Figure 12 in addition to the process of Figure 10 of the third embodiment. Regarding the operation of the congestion prediction system 1b of the fourth embodiment, the parts that differ from the third embodiment will be described.

[0072] In step ST51, the processor 110 determines whether an abnormality has occurred in the operation of a route different from the route to be predicted or in the route to be predicted. For example, when an abnormality occurs in the operation of each route, the operation control system 200 transmits information notifying the congestion prediction server 100 of the abnormality. The information is received by the communication I / F 150 of the congestion prediction server 100. In response to receiving the information, the processor 110 determines that an abnormality has occurred in the operation of the route. Alternatively, the processor 110 may determine that an abnormality has occurred from a change in the measured value of the congestion rate.

[0073] Fig. 13 is a graph showing an example of how the congestion rate changes over time. In the graph of Fig. 13, the vertical axis represents the congestion rate and the horizontal axis represents time. In Fig. 13, the measured values of the congestion rate are plotted as points Pc. The polygonal line Lf is a polygonal line connecting the points Pc. The curve Lg shows how the congestion rate changes over time under normal conditions.

[0074] Point Pc represents, for example, the congestion rate of a train or vehicle in a specific station section. In this case, polygonal line Lf represents, for example, the change in the congestion rate of a train or vehicle in a specific station section over time. In addition, curve Lg represents, for example, a time series model. Alternatively, point Pc represents the hourly congestion rate of a specific train or vehicle. In this case, the broken line Lf represents, for example, the change in the congestion rate of a specific train or vehicle over time. In addition, in this case, the curve Lg represents, for example, a graph of a fluctuation table. The curve Lg may be a graph of a congestion rate predicted using a fluctuation table for normal times.

[0075] Fig. 13 also shows the differential congestion rate CD. The differential congestion rate CD is the difference between point Pc and curve Lg at the same time, or the difference between curve Lf and curve Lg. Fig. 13 representatively shows the differential congestion rate CD for one point Pc.

[0076] FIG. 14 is a graph showing an example of the change over time in the differential congestion rate CD. Point Pd is a plot of the differential congestion rate CD, which is the difference between point Pc and curve Lg. Line Lh is a polygonal line connecting points Pd. Therefore, line Lh shows the change over time in the differential congestion rate CD. FIG. 14 also shows a threshold value CDa. Threshold value CDa is a threshold value that indicates the boundary between whether or not an abnormality has occurred. For example, if the differential congestion rate CD based on the latest congestion rate measurement value is equal to or greater than a threshold value CDa, the processor 110 determines that an abnormality has occurred in the operation of the route. Figures 13 and 14 show time Ta as the time when the differential congestion rate CD becomes equal to or greater than the threshold value CDa.

[0077] If processor 110 does not determine that an abnormality has occurred in the operation of the route, it determines No in step ST51 and repeats the processing of step ST51. On the other hand, if processor 110 determines that an abnormality has occurred in the operation of the route, it determines Yes in step ST51 and proceeds to step ST52.

[0078] In step ST52, the processor 110 changes the congestion rate prediction method used in step ST26 of FIG. 11 from the normal state to the abnormal state. When using the abnormal state congestion rate prediction method, the processor 110, for example, multiplies the predicted congestion rate calculated in the processing of step ST26 by n1. Alternatively, the processor 110 adds m1 points to the congestion rate calculated in the processing of step ST26. Here, n1 is a number equal to or greater than 1. Here, m1 is a number equal to or greater than 0. The congestion rate may also have an upper limit. When setting an upper limit for the congestion rate, if multiplying the congestion rate by n1 or adding m1 points to the congestion rate results in the congestion rate being equal to or greater than the upper limit, the processor 110 sets the congestion rate to the upper limit regardless of the calculation result. The upper limit for the congestion rate indicates, for example, a full-occupancy state. In other words, trains and cars with a congestion rate at the upper limit are expected to be full. Note that the values of n1 or m1 may differ for each station section. The value of n1 or m1 may also differ depending on the line and station section where the abnormality occurred. The value of n1 or m1 may also differ depending on the line and station section for which the congestion rate is to be predicted. Processor 110 may also multiply the differential congestion rate based on the congestion rate calculated in the processing of step ST26 by n1 or add m1 to it. Then, processor 110 calculates the congestion rate from the differential congestion rate. 13 is a portion where the congestion rate is flat, and is a portion where the congestion rate is at its upper limit. The portion where the congestion rate is flat is a range from time Tc to time Td.

[0079] In step ST53 of FIG. 12, processor 110 determines whether the congestion rate has started to return to normal. Although the congestion rate increases from normal due to an abnormality in operation, the increase in the congestion rate decreases as operation returns to normal. For example, processor 110 determines that the congestion rate has started to return to normal by detecting that the increase in the congestion rate has started to decrease based on the congestion rate measured by measuring device 300. Alternatively, processor 110 determines that the congestion rate has started to return to normal in response to receiving information indicating that the congestion rate has started to return to normal from traffic management system 200. One example of the information indicating that the congestion rate has started to return to normal is information indicating that train operation has resumed.

[0080] 14 shows the threshold CDb. The threshold CDb indicates the boundary between whether the congestion rate has started to return to normal. For example, if the differential congestion rate CD is equal to or less than the threshold CDb, the processor 110 determines that the congestion rate has started to return to normal.

[0081] If processor 110 determines that the congestion rate has not started to normalize, it determines No in step ST53 and repeats the processing of step ST53. On the other hand, if processor 110 determines that the congestion rate has started to normalize, it determines Yes in step ST53 and proceeds to step ST54.

[0082] In step ST54, the processor 110 changes the congestion rate prediction method in step ST26 of FIG. 11 from that for abnormal times to that for normal times. The normal time prediction method is a method to be used, for example, in a transient state from an abnormal time to a normal time. When using the congestion rate prediction method for normal times, the processor 110 multiplies the predicted value of the congestion rate obtained in the processing of step ST26 by n2. Alternatively, the processor 110 adds m2 points to the congestion rate obtained in the processing of step ST26. Note that n2 is a number equal to or greater than 1. m2 is a number equal to or greater than 0. n2 and m2 are values that decrease as the elapsed time t11 from the start of normalization becomes longer. When t11 is 0, for example, n1=n2 and m1=m2. As an example, n2 and m2 are n2=1+(n1-1)×e (-t11 / τ1) (6) m2=m1×e (-t11 / τ2) (7) where e is Napier's constant. τ1 and τ2 are time constants. The function representing n2 is not limited to equation (6). The function representing m2 is not limited to equation (7). Processor 110 may multiply the differential congestion rate based on the congestion rate calculated in the processing of step ST26 by n2 or add m2 to it. Then, processor 110 calculates the congestion rate from the differential congestion rate. The attenuation curve Li in FIG. 14 shows the change over time of the differential congestion rate calculated by multiplying the differential congestion rate based on the congestion rate calculated in the processing of step ST26 by n2 or adding m2 to it. Moreover, a curve Li shown in FIG. 14 is a curve showing an example of a change over time in the differential congestion rate CD based on the congestion rate calculated using n2 or m2.

[0083] Alternatively, the processor 110 may set the elapsed time from the i-th point Pd to t12, and use n3 instead of n2 and m3 instead of m2. n3=1+(n1-1)×e (-t12 / τ3) (8) m3=m1×e (-t12 / τ4) (9) is.

[0084] The processor 110 calculates the time constant τ using two or more points Pd, such as those shown in FIG. 14. For example, let R1 be the differential congestion rate CD of the first point Pd after the congestion rate begins to normalize, R2 be the differential congestion rate CD of the second point Pd, R3 be the differential congestion rate CD of the third point Pd, and so on. Let R(i-1) be the differential congestion rate CD of the (i-1)th point Pd, and Ri be the differential congestion rate CD of the i-th point Pd. Note that i is an integer between 1 and N. N is the number of points Pd that can be used to calculate the time constant τ. Let ΔTi be the difference between the time of the i-th point Pd and the time of the (i-1)th point Pd. Note that ΔTi is collectively referred to as ΔT. The value of ΔTi is not constant but varies for each i. Alternatively, the processor 110 may correct ΔTi so that it is constant regardless of i. The time constant τ can be expressed, for example, by the following equation (10): The time constants τ1 to τ4 are collectively referred to as the time constant τ. Furthermore, ε is the estimation error. (R(i-1) / Ri) ∝ τ+ε (10) Processor 110 obtains the estimation error ε by compressing it through averaging in the range of i = 1 to N. Alternatively, processor 110 may perform averaging to obtain a moving average in consideration of tracking of state changes.

[0085] Ri can be expressed, for example, by the following equation (11). Ri = (R(i-1)) × e (-ΔTi / τ) (11) Therefore, the processor 110 calculates the time constant τ using, for example, the following equation (12): Here, the τ calculated here is, for example, the time constant τ3 or the time constant τ4. Furthermore, ln indicates the natural logarithm. τi=ΔTi×ln(Ri / (R(i-1))) (12) Note that time constant τi denotes the time constant τ calculated using Ri and R(i-1). Here, consider the case where i=1. When i=1, R(i-1) is R0. R0 indicates the differential congestion rate CD of the point Pd immediately before the point Pd corresponding to R1. Note that R0 is not shown in FIG. 14. If the congestion rate of point Pc corresponding to point Pd corresponding to R0 is at the upper limit, the error will be large, so processor 110 does not need to calculate the time constant τ until the value of R2 is known. Then, once the value of R2 is known, for example, processor 110 calculates the time constant τ using equation (12) for i=2. Note that point Pc corresponding to point Pd is the point Pc before the differential congestion rate CD is calculated by subtracting the value of curve Lg. Therefore, point Pd and point Pc corresponding to point Pd have the same time. The processor 110 does not need to change the congestion rate prediction method from that for abnormal times to that for normal times until the time constant τ is calculated.

[0086] The differential congestion rate calculated using the measured congestion rate contains various errors. The estimated value τe of the time constant τ is τe=E[τi+εi]=E[τi]+E[εi] (13) Here, E[x] represents the expected value of x. Note that τi and εi are independent. εi is the estimation error for the time constant τi. εi is a sum of the errors included in each measurement value, etc. The processor 110 may calculate τe using the following formula: τe≒(1 / N)·Σ(ΔTi·ln(Ri / R(i-1)))+(1 / N)·Σ(εi) (14) Here, the second term on the right-hand side, (1 / N) Σ(εi), can be ignored because it is close to 0. That is, when the second term is ignored, the processor 110 sets the average value of N τi as τe. The processor 110 may use the estimated value τe of the time constant as the time constant τ.

[0087] In step ST55, processor 110 estimates the time ΔTb until operation returns to normal and the time Tb when operation returns to normal. Time Tb is, for example, the time when the differential congestion rate based on the congestion rate calculated in step ST54 by multiplying by n2 or adding m2 becomes equal to or less than threshold CDa. The time ΔTb until operation returns to normal is the time from the current time to time Tb.

[0088] Alternatively, the processor 110 may estimate the time Tb from Ri and R(i-1). For example, the processor 110 calculates the slope m of the line SLi connecting the i-th point Pd and the (i-1)-th point Pd. The slope m can be calculated, for example, as follows: m=((Ri-R(i-1)) / ΔTi) (15) The processor 110 also calculates the time Txi that is the difference between the time Ti of the i-th point Pd and the time TQ of the point Q. The point Q is the point where the line SLi intersects with the line indicating the threshold CDa. In other words, the point Q is the point on the line SLi where the differential congestion rate CD is CDa. The time Txi can be calculated, for example, by Txi=ΔTi-Ri / m (16) The processor 110 calculates, for example, the time Tbi from the time Ti to the time Tb. The time Tbi can be calculated, for example, as follows: Tbi = Txi × γ1 (17) Here, the coefficient γ1 is a predetermined coefficient. The processor 110 also estimates the time Tb. The time Tb can be calculated, for example, as follows: Tb = Ti + Tbi (18) It can be found by:

[0089] Alternatively, the processor 110 may obtain time Tx(i-1) instead of time Txi, and time Tb(i-1) instead of time Tbi. Time Tx(i-1) is the difference between time Ti at the (i-1)th point Pd and time TQ at point Q. Time Tb(i-1) is the time from time T(i-1) to time Tb at the (i-1)th point Pd. Time Tx(i-1) is Tx(i-1)=ΔT(i-1)-(R(i-1)) / m (19) The time Tb(i-1) can be calculated by, for example, Tb(i-1)=Tx(i-1)×γ2 (20) Here, the coefficient γ2 is a predetermined coefficient. The processor 110 also estimates the time Tb. The time Tb can be calculated, for example, as follows: Tb=T(i-1)+Tb(i-1) (21) It can be found by:

[0090] Furthermore, the time ΔTb can be obtained by subtracting the current time from the time Tb. The equations for determining the time Tb and the time ΔTb are not limited to those shown above.

[0091] Furthermore, the processor 110 transmits the time ΔTb and time Tb until operation returns to normal to various devices, for example, in the same manner as in step ST29. The various devices notify the time ΔTb and time Tb until operation returns to normal, for example, by displaying them on a display. The various devices transmit the time ΔTb and time Tb until operation returns to normal to, for example, a terminal used by a user. The processor 110 uses a common threshold CDa in steps ST51 and ST55. However, the processor 110 may use different thresholds in steps ST51 and ST55.

[0092] In step ST56, processor 110 determines whether operation has returned to normal. For example, processor 110 determines that operation has returned to normal if a predetermined time has elapsed since the congestion rate began to return to normal. Alternatively, processor 110 determines that operation has returned to normal in response to receiving information indicating that operation has returned to normal from traffic management system 200. Alternatively, processor 110 determines that operation has returned to normal in response to the congestion rate measured by measuring device 300 falling within a predetermined normal range. If processor 110 does not determine that operation has returned to normal, it determines No in step ST56 and proceeds to step ST57. On the other hand, if processor 110 determines that operation has returned to normal, it determines Yes in step ST56 and proceeds to step ST57.

[0093] In step ST57, processor 110 changes the time series model and fluctuation table from those for normalization to those for normal times. That is, processor 110 uses the congestion rate calculated in step ST26 of Fig. 11 as is. After processing step ST57 of Fig. 12, processor 110 returns to step ST51.

[0094] The congestion prediction system 1b of the fourth embodiment can obtain the same effects as those of the third embodiment.

[0095] Furthermore, according to the congestion prediction system 1b of the fourth embodiment, when an abnormality occurs in operation, the congestion prediction server 100 predicts the congestion rate using a congestion rate prediction method for abnormal situations. This allows the congestion prediction server 100 to more accurately determine the congestion rate when an abnormality occurs in operation. Furthermore, when the congestion state becomes transiently abnormal due to a train schedule disruption or the like, the congestion prediction server 100 can predict the time it will take for the abnormal congestion state to converge to a normal state.

[0096] The above embodiment can be modified as follows. In the above embodiment, the processor 110 predicts the congestion rate using the difference in steps ST24 to ST26. However, the processor 110 may predict the congestion rate using the ratio instead of the difference.

[0097] In the above embodiment, some or all of the processing performed by the congestion rate management system 400 may be executed by the congestion prediction server 100 or the traffic control system 200. In the above embodiment, some or all of the processing performed by the traffic control system 200 may be executed by the congestion prediction server 100 or the congestion rate management system 400. In the above embodiment, some or all of the processing performed by the congestion prediction server 100 may be executed by the traffic control system 200 or the congestion rate management system 400.

[0098] In the above embodiments, some or all of the information stored in the congestion rate management system 400 may be stored in the congestion prediction server 100 or the traffic management system 200. In the above embodiments, some or all of the information stored in the traffic management system 200 may be stored in the congestion prediction server 100 or the congestion rate management system 400. In the above embodiments, some or all of the information stored in the congestion prediction server 100 may be stored in the traffic management system 200 or the congestion rate management system 400.

[0099] The congestion prediction system 1 may use a value other than the congestion rate that indicates the state of congestion of a vehicle, instead of the congestion rate.

[0100] The congestion prediction system 1 may use a median value instead of the average value.

[0101] The congestion prediction system 1 of the above embodiment is a system for predicting the congestion rate of a railway. However, the congestion prediction system of the embodiment may be a system for predicting the congestion rate of a vehicle other than a railway. For example, the congestion prediction system of the embodiment predicts the congestion rate of a route bus, a trolley bus, a guideway bus, or other buses, a ship, an airplane, an elevator, or other vehicles.

[0102] The congestion prediction server 100 may be divided into multiple devices, and the multiple devices may share the processing in the above embodiment.

[0103] The processor 110 may implement some or all of the processes implemented by the programs in the above embodiments by a hardware circuit configuration.

[0104] The program for implementing the processes of the embodiments may be transferred, for example, in a state stored in the device. However, the device may also be transferred without the program stored therein. The program may then be transferred separately and written to the device. The program may be transferred, for example, by recording it on a removable storage medium or by downloading it via a network such as the Internet or a LAN.

[0105] Although the embodiments of the present invention have been described above, they are merely examples and are not intended to limit the scope of the present invention. The embodiments of the present invention can be implemented in various forms without departing from the spirit of the present invention. [Explanation of symbols]

[0106] 1,1b Congestion prediction system 100 Congestion Prediction Server 110 processors 120 ROM 130 RAM 140 Auxiliary storage 141 Congestion Database 150 communication interface 160 Bus 200 Traffic Management System 300 Measuring Equipment 400 Congestion Rate Management System 500 Ticket Gate System

Claims

1. a processing unit that predicts a state of vehicle congestion in a first section that is a prediction target, using statistical data on the state of vehicle congestion in a first section that is composed of one or more sections and a first measurement value of the state of vehicle congestion in the first section; The processing unit using a difference between the statistical data and the first measurement value to obtain a function for predicting a time change in the congestion state of the vehicle to be predicted in the first section, and predicting the congestion state of the vehicle to be predicted in the first section using the function; predicting a congestion state of the vehicle to be predicted in a second section different from the first section using the congestion state of the vehicle to be predicted in the first section and using fluctuation information indicating a change in the congestion state of the vehicle for each section as a correlation between the first section and the second section; The fluctuation information is a fluctuation table showing fluctuations in congestion rate by car for each station section for each car of the train as the vehicle to be predicted. Congestion rate prediction device.

2. The congestion rate prediction device described in claim 1, wherein the processing unit corrects the fluctuation table using a second measurement value of the congestion state of the vehicle to be predicted, and predicts the congestion state of the vehicle to be predicted using the corrected fluctuation table.

3. The processing unit, in correcting the table of variations, Calculating the difference or ratio between the congestion rate of each station section in the fluctuation table and the actually measured congestion rate, and predicting the difference or ratio for each station section that the train to be predicted has not yet arrived using the difference or ratio; The congestion rate prediction device according to claim 1 or 2, wherein the variation table is corrected using the predicted difference or ratio.

4. The congestion rate prediction device according to claim 1 , wherein the processing unit predicts a congestion state according to a situation at the time of measurement of the first measurement value.

5. The congestion rate prediction device according to any one of claims 1 to 4, wherein the processing unit generates the statistical data using boarding and disembarking information indicating where a user who used the vehicle boarded the vehicle and where the user disembarked the vehicle.

6. The congestion rate prediction device according to claim 1 , wherein the processing unit changes a congestion rate prediction method when an abnormality occurs in the operation of the vehicle.

7. The congestion rate prediction device according to claim 6 , wherein the processing unit determines that an abnormality has occurred in the operation of the vehicle using a change in the first measurement value.

8. 8. The congestion rate prediction device according to claim 6, wherein the processing unit predicts a time when the operation of the vehicle will return to normal from the congestion rate predicted by the prediction method when an abnormality occurs in the operation of the vehicle.

9. The processor in the congestion rate prediction device is A computer program that functions as a processing unit that predicts a state of vehicle congestion in a first section that is a target of prediction, using statistical data on a state of vehicle congestion in a first section that is composed of one or more sections and a first measurement value of the state of vehicle congestion in the first section, the computer program comprising: The processing unit using a difference between the statistical data and the first measurement value to obtain a function for predicting a time change in the congestion state of the vehicle to be predicted in the first section, and predicting the congestion state of the vehicle to be predicted in the first section using the function; predicting a congestion state of the vehicle to be predicted in a second section different from the first section using the congestion state of the vehicle to be predicted in the first section and using fluctuation information indicating a change in the congestion state of the vehicle for each section as a correlation between the first section and the second section; The fluctuation information is a fluctuation table showing fluctuations in congestion rate by car for each station section for each car of the train as the vehicle to be predicted. Computer program.

Images