JP7719645B2 - Congestion rate prediction device and program - Google Patents

Description

The present invention relates to a congestion rate prediction device and program.

Traditionally, operators of transportation such as railways have worked to improve transportation facilities and operations by knowing the congestion state of their vehicles in order to maintain and improve service levels, such as comfort on board. To understand the congestion state of their vehicles, these operators use indicators such as congestion rate (occupancy rate). Furthermore, these operators determine the congestion state of vehicles as general trends, such as congested sections and congested time periods, by measuring congestion rates and conducting statistical analysis of the measured values. While advances in measurement technology have made it possible to measure congestion rates in real time for some sections or some vehicles, it is believed that new, unconventional methods would be useful for estimating the congestion rate of entire large-scale routes in real time, estimating detailed congestion rates for individual train cars, and efficiently predicting changes in congestion rates at future times.

Japanese Patent Application Laid-Open No. 2019-99068

The problem that embodiments of the present invention aim to solve is to provide a congestion rate prediction device and program that can predict vehicle congestion conditions using a novel method.

The congestion rate prediction device of the embodiment includes a processing unit. The processing unit predicts the congestion state of a vehicle to be predicted in a first section, which is composed of one or more sections, using statistical data on the congestion state of vehicles in the first section and a first measurement value of the congestion state of vehicles in the first section.

The present invention provides a novel way to predict vehicle congestion.

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; 10 is a flowchart showing an example of processing according to the first embodiment by a processor of the congestion prediction server in FIG. 1 . 10 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 . A graph showing the distribution of congestion by car. A graph of the table of fluctuations. A diagram showing the congestion rates of multiple trains in each station section from Station A to Station G. 10 is a graph showing an example of a change in congestion rate over time. 10 is a graph showing an example of a change in difference over time. 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. 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. 1 . 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. 1 . 10 is a flowchart showing an example of processing according to the fourth embodiment by a processor of the congestion prediction server in FIG. 1 . 10 is a graph showing an example of a change in congestion rate over time. 10 is a graph showing an example of a change over time in a differential congestion rate.

The following describes congestion prediction systems according to several embodiments using drawings. Note that the scale of each part in the drawings used to explain the following embodiments may be changed as appropriate. Also, for the sake of explanation, each drawing used to explain the following embodiments may omit components. Also, in each drawing and throughout this specification, the same reference numerals indicate similar elements.

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.

The congestion prediction server 100, the traffic management 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 that includes the Internet. The network NW is typically a communication network that includes a WAN (wide area network). The network NW may be a communication network that includes a private network such as an intranet. The network NW may be a communication network that includes a LAN (local area network). The network NW may also be a wireless line or a wired line, or may be a combination of wireless and wired lines. The network NW may also be a communication network that includes a dedicated line or a public mobile phone network.

The congestion prediction server 100 is a device that calculates the congestion rate of each railway train. The congestion prediction server 100 may be a single device or a device consisting of multiple devices. As an example, the congestion prediction server 100 includes 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.

The processor 110 is the central part of the computer, performing calculations, control, and other processes necessary for the operation of the congestion prediction server 100, and performs various calculations and processes. 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 several of these. The processor 110 may also be a combination of these with a hardware accelerator. The processor 110 controls each component to realize the 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 these programs. Note that some or all of these programs may be incorporated into the circuitry of the processor 110. Additionally, the processor 110 is an example of a processing unit.

The ROM 120 and RAM 130 are 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.

The auxiliary storage device 140 is an auxiliary storage device for a computer with the processor 110 at its core. The auxiliary storage device 140 is, for example, an EEPROM (electric erasable programmable read-only memory), a HDD (hard disk drive), or flash memory. The auxiliary storage device 140 stores the above programs, such as system software and application software. 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, etc.

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 the analysis process described below. The congestion prediction server 100 references the congestion database 141 when predicting congestion rates.

The communication I/F 150 is an interface that allows the congestion prediction server 100 to communicate via a network NW, etc.

Bus 160 includes a control bus, address bus, and data bus, and transmits signals exchanged between each part of the congestion prediction server 100.

The traffic management system 200 is a system that manages train operations. The traffic management system 200 also stores various information related to train operations. The traffic management system 200 includes, for example, a server.

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, for example, on each car. The load-adjusting device is a sensor that measures the load on the car. The measuring device 300 calculates the congestion rate from the 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 of the 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 the congestion rate is measured. This status includes, for example, operation information such as the date, 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 that 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 obtains operation information and train information from, for example, the traffic management system 200.

The congestion rate may also be measured visually by a person. In this case, a person in charge or the like inputs the manually measured congestion rate into the congestion rate management system 400. The congestion rate management system 400 stores the congestion rate.

The congestion rate management system 400 stores and manages the congestion rate measurements taken by the measuring device 300, etc., as described above. The congestion rate management system 400 includes, for example, a server.

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, for example, the ROM 120 or the auxiliary storage device 140.
The processor 110 starts the processing of Figures 2 and 3, for example, based on the activation of the congestion prediction server 100 or the activation of an application for congestion prediction.

The process shown in FIG. 2 includes a process (hereinafter referred to as "analysis process") for 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. A state in which a state in which the difference between the predicted congestion rate and the measured congestion rate is large frequently may be, for example, a state in which the average value of the square or absolute value of the difference is greater than a predetermined value, a state in which the frequency at which the square or absolute value of the difference is greater 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 has been made to instruct analysis processing to be performed. The input may be based, for example, on an operation input using a console of the congestion prediction server 100. Alternatively, the input may be based on a command transmitted from another device and input to the communication I/F 150. The command indicates an instruction to perform analysis processing.

In step ST12, the processor 110 acquires data to be used for the analysis process (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.

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 the time a train departs from a station until 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 the time a train departs from Station A until it arrives at Station B. The congestion rate for the Station A-Station B section may be, for example, the congestion rate at the time a train departs from or passes through Station A, the congestion rate at the time it arrives at or passes through Station B, or the congestion rate at the time it arrives at or passes a location between Station A and Station B. It is assumed that Station B is the station next to Station A. The average train congestion rate is also the average train congestion rate for a specified 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. As an 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. As an 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 the week - whether it is a weekday, Saturday, Sunday or public holiday, etc.
-Train information, operation information, weather, weather forecast, whether it is a holiday or not.
- Season or time of year, date, etc. - Whether or not an event is being held near the station, and the scale of the event.

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 at 8:14 on Sundays. 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.

In addition, the processor 110 associates the calculated average train congestion rate with information indicating the congestion conditions used to classify the average train congestion rate, and stores it in the congestion database 141.

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 each car, for example, how many times the average congestion rate of the car is compared to the average train congestion rate. 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.

The processor 110 also associates the calculated congestion distribution by car with information indicating the congestion conditions used to classify the congestion distribution by car, and stores it in the congestion database 141.

In addition, the processor 110 may use the previously calculated average train congestion rate or the previously calculated congestion distribution by car, rather than calculating it in the current process. In this case, the processor 110 obtains the previously calculated average train congestion rate or previously calculated congestion distribution by car from the congestion database 141.

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.

Figure 4 is a graph of the congestion distribution by car. Figure 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. Figure 4 shows the congestion rate by car for each of cars 1 to 8 of the train as a bar graph. Line La shows the bar graph as a line graph. Figure 4 also shows the congestion rate Ca, which indicates the average congestion rate of the train. In the congestion rate by car shown in Figure 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.

In step ST16, processor 110 creates a fluctuation table. The fluctuation table is, for example, a table showing fluctuations in congestion rates by car for each station section for each car of a train. Processor 110 creates the fluctuation table, for example, using congestion rates by car. The fluctuation table may be categorized by conditions, as with congestion rates by car, or may not be categorized by conditions. When creating a fluctuation table for a certain condition, processor 110 creates the fluctuation table using congestion rates by car that meet the certain condition. As an example, processor 110 creates the fluctuation table using data clustering. The congestion rate of a specific car in a specific station section in a fluctuation table for a certain condition is the average congestion rate by car for the same condition, station section, and car. For example, in a fluctuation 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 congestion rate 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 for the first 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.

Figure 5 is a graph of the fluctuation table. Figure 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 that order. Figure 5 uses a bar graph to show the congestion rate by car for that specific car in each station section. Furthermore, line Lb is a line graph that shows the bar graph.

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 that station section. From the congestion rate for each car, processor 110 obtains the time series model using least squares, AR (autoregressive model), ARMA (autoregressive moving average model), ARIMA (autoregressive integrated moving average model), or a state space model. 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.

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

The process shown in Fig. 3 includes a process for predicting the congestion rate by car number using a congestion rate table, etc. The process shown in Fig. 3 will be described with reference to Fig. 6 .
Figure 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 height 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 Figure 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 numbers on the right indicate the order in which trains pass through the station section. Note that the time at which a train passes through a station section indicates, for example, the time at which the train passes a specific location within the station section. The location may be, for example, a station at the end of the station section or a location in between. As an 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 Station A and Station 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. In other words, 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 there may be a train passing through the station section before the train corresponding to a code with a number 1 on the right side passes through the specific station section. Furthermore, the same numbers on the right side 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 in the section between station A and station B is congestion rate A1, the congestion rate of that specific train in the section between station B and station C is congestion rate B1, the congestion rate of that specific train in the section between station C and station D is congestion rate C1, and so on. The congestion rates shown in Figure 6 representatively indicate the congestion rate of a specific car. The specific car 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 rate of car 3.

Here, the processing in Figure 3 will be explained using congestion rates C1 to C4 as an example to predict other congestion rates. In this case, the Station C-D section is an example of a first section. Note that the first section may consist of a single station section, or multiple station sections. There may also be another station between stations in a single station section. Also, station sections are not limited to sections between stations. For example, instead of stations, they may be marshalling yards, signal stations, or train stations.

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

In step ST22, 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, processor 110 can acquire real-time congestion rates, etc. As an example, processor 110 acquires congestion rates C1 to C4 as the congestion rate data. Processor 110 also acquires situation data stored in association with each congestion rate data. Multiple congestion rate data for the same station section acquired in step ST22, such as congestion rates C1 to C4, are an example of a first measurement value of the train congestion state in the station section.

In step ST23, the processor 110 acquires from the congestion database 141 a time series model and a fluctuation table to be used to predict the congestion rate. The time series model used to predict 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 to predict 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 to predict 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 to predict the congestion rate is a fluctuation table for the train for which the congestion rate is to be predicted.

In step ST24, the 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 represents an example of a time series model acquired in step ST23. Furthermore, difference Da represents the difference in congestion rate between point Pa and curve Lc. Note that difference Da represents an example of the difference between statistical data and a measured value.

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 a time beyond the latest point Pb.

In step ST26, processor 110 uses a differential function to predict the congestion rate for a time beyond the latest point Pa in Figure 7. Curve Le is a function of time (hereinafter referred to as the "time series prediction function") that indicates the 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). Processor 110 can calculate the congestion rate Fc(t) at any time by using the time series prediction function. Processor 110, for example, calculates the congestion rate at the time a train passes through the station section from the time series prediction function. As an example, processor 110 calculates congestion rates C5 and 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-Station D section, processor 110 uses a time series prediction function to calculate the congestion rate at the time the train departs from Station C. Alternatively, processor 110 may use a 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 a station section.

In step ST27, the processor 110 uses the target congestion rate and the fluctuation table acquired in step ST23 to estimate the congestion rate of a station section different from the target congestion rate. 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. The processor 110 uses one target congestion rate (hereinafter referred to as "congestion rate Xa") and a fluctuation table (hereinafter referred to as "target fluctuation table") with the same train and car as the congestion rate Xa to estimate the congestion rate of a station section different from the target congestion rate for the same train and car. 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. The processor 110 calculates the difference between the congestion rate Xa and the 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 defined as congestion rate Xb. Furthermore, the congestion rate in the target variation table for the same station section as congestion rate Xb is defined as congestion rate Yb. In this case, the processor 110 calculates congestion rate Xb using, for example, the following formula (2):
Xb=Yb+α (2)
The processor 110 also calculates the ratio β of the congestion rate Xa to the congestion rate Ya as a value indicating how much the congestion rate Xa and the congestion rate Ya differ from each other. For example, the 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)

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

In step ST28, the processor 110 stores the congestion rate predicted in steps ST27 and ST28 in the congestion database 141.

In step ST29, the processor 110 instructs the communication I/F 150 to transmit the congestion rate predicted in steps ST27 and ST28 to various devices. The various devices are devices that perform some kind of processing using the congestion rate estimate. 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 server transmits the received congestion rate to a terminal, such as a personal computer (PC) or smartphone, used by the user.
After processing step ST29, processor 110 returns to step ST21.

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. It can efficiently and sequentially predict changes in congestion rate at future times. Furthermore, the congestion prediction server 100 can efficiently obtain real-time congestion predictions for each train car in a large-scale route network.

Furthermore, according to the congestion prediction system 1 of the first embodiment, the congestion prediction server 100 calculates 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.

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 conventional methods.

Second Embodiment
The congestion prediction system of the second embodiment estimates passenger flow to determine 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.

The ticket gate system 500 includes an automatic ticket gate and a server. The ticket gate system 500 is a system that manages passenger entry and exit through 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. 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 an example of a train user.

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, for example, the ROM 120 or the auxiliary storage device 140.
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.

The processor 110 performs the processing shown in FIG. 10 instead of the processing shown in FIG. 2 in the first embodiment. The processor 110 also performs the processing shown in 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 explained below.

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 entry/exit information for the predetermined period for which operation is normal, excluding the portion of the entry/exit information for which operation is abnormal. Note that the processor 110 acquires, for example, information indicating which periods of operation are normal and which periods of operation are abnormal from the traffic management system 200. Then, the processor 110 uses this information to exclude the portion of the entry/exit information for which operation is abnormal.

In step ST32, processor 110 uses the entry/exit information acquired in step ST31 to estimate the number of people passing through each station section by time period. If the entry/exit information is for when operation is not normal in step ST31, it is the entry/exit information for when operation is normal. 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 proportion of passengers who take which route from station STA1 to station STA2 is predetermined. As an example, if there are three routes from station STA1 to station STA2, route RO1 to route RO3, the ratios are set such that 50% of passengers take route RO1, 30% take route RO2, and 20% take route RO3. Based on these ratios, processor 110 estimates the number of passengers who boarded at station STA1 and disembarked at station STA2 and 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 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 from the time 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 determined in advance based on, for example, a timetable. Alternatively, processor 110 may calculate time t3 from a timetable. Processor 110 similarly estimates the number of people passing through station section SS1 for each combination of entry station and exit station. Processor 110 then adds up the number of people passing through station section SS1 for each combination for each time period, thereby estimating the number of people passing through station section SS1 for each time period. Processor 110 also similarly estimates the number of people passing through station sections other than station section SS1 for each time period.

In step ST33, the 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, assume that the number of passengers passing through station section SS1 during a certain time period is NP1. Also, assume that the total number of passengers on trains passing through station section SS1 during that time period is CA1. 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. Note that 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 of the first embodiment.

The congestion prediction system 1b of the second embodiment achieves the same effects as the first embodiment.

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. This allows the congestion prediction server 100 to calculate the congestion rate with greater accuracy.

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.

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.

The processor 110 performs the processing shown in FIG. 11 instead of the processing shown in FIG. 3 in the second embodiment. Furthermore, the processor 110 in the third embodiment performs the processing shown in FIG. 10, similar to the second embodiment. Regarding the operation of the congestion prediction system 1b in the third embodiment, differences from the second embodiment will be explained below.

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 congestion rate D5, the train corresponding to 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.

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 uses the difference or ratio to predict the difference or ratio for each station section that the train to be predicted has not yet arrived, using least squares, AR, ARMA, ARIMA, or a state space model. 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.

The congestion prediction system 1b of the third embodiment achieves the same effects as the second embodiment.

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 greater accuracy.

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 status, and predict the time it will take to return to normal. However, the congestion prediction system of the fourth embodiment can also be used for routes where an abnormality has occurred.

The configuration of the congestion prediction system 1b in the fourth embodiment is the same as that in the third embodiment, so a detailed description will be omitted.

The operation of the congestion prediction system 1b according to the fourth embodiment will be described below with reference to Figures 10 to 12. Figure 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 Figure 12 based on a program stored in, for example, the ROM 120 or the auxiliary storage device 140.
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.

The processor 110 of the fourth embodiment performs the processing shown in Figures 10 and 11, similar to that of the third embodiment. Furthermore, the processor 110 performs the processing shown in Figure 12 in addition to the processing shown in Figure 10 of the third embodiment. Regarding the operation of the congestion prediction system 1b of the fourth embodiment, differences from the third embodiment will be described below.

In step ST51, the processor 110 determines whether an abnormality has occurred in the operation of a route different from the route being predicted or the route being predicted. For example, when an abnormality occurs in the operation of each route, the operation management system 200 transmits information notifying the congestion prediction server 100 that an abnormality has occurred in the operation. 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.

Figure 13 is a graph showing an example of how congestion rates change over time. In the graph in Figure 13, the vertical axis represents congestion rates and the horizontal axis represents time. In Figure 13, measured values of congestion rates are plotted as points Pc. The broken line Lf connects the points Pc. The curve Lg shows how congestion rates change over time under normal conditions.

Point Pc represents, for example, the congestion rate of trains or vehicles in a specific station section. In this case, polygonal line Lf represents, for example, the change in the congestion rate of trains or vehicles in a specific station section over time. In this case, 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, polygonal line Lf represents, for example, the change in the congestion rate of a specific train or vehicle over time. In addition, curve Lg represents, for example, a graph of a fluctuation table.
The curve Lg may be a graph of the congestion rate predicted using a fluctuation table for normal times.

Figure 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. Figure 13 representatively shows the differential congestion rate CD for one point Pc.

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. 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.

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.

In step ST52, the processor 110 changes the congestion rate prediction method used in step ST26 of FIG. 11 from the normal congestion rate prediction method to the abnormal congestion rate prediction method. When using the abnormal congestion rate prediction method, the processor 110, for example, multiplies the congestion rate prediction value calculated in step ST26 by n1. Alternatively, the processor 110 adds m1 points to the congestion rate calculated in 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 maximum congestion rate are expected to be full. The values of n1 and 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. The 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. The processor 110 then calculates the congestion rate from the differential congestion rate.
13, the portion where the congestion rate is flat is the portion where the congestion rate is at its upper limit, and is the range from time Tc to time Td.

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 operational abnormality, the rate of increase in the congestion rate decreases as operation returns to normal. Processor 110 determines that the congestion rate has started to return to normal by detecting, for example, that the rate of 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 from traffic management system 200 indicating that the congestion rate has started to return to normal. One example of information indicating that the congestion rate has started to return to normal is information indicating that train operations have resumed.

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

If processor 110 does not determine that the congestion rate has begun to return to normal, 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 begun to return to normal, it determines Yes in step ST53 and proceeds to step ST54.

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, for example, a method to be used 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. Note that the function representing n2 is not limited to equation (6). Note that the function representing m2 is not limited to equation (7). The processor 110 may also multiply the differential congestion rate based on the congestion rate calculated in the processing of step ST26 by n2 or add m2 to it. The processor 110 then calculates the congestion rate from the differential congestion rate. Note that the attenuation curve Li in FIG. 14 shows the time change 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.
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.

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.

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 at the first point Pd after the congestion rate begins to normalize, R2 be the differential congestion rate CD at the second point Pd, R3 be the differential congestion rate CD at the third point Pd, and so on. Let R(i-1) be the differential congestion rate CD at the (i-1)th point Pd, and Ri be the differential congestion rate CD at 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 τ. The difference between the time of the i-th point Pd and the time of the (i-1)th point Pd is ΔTi. 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 τ, and ε is the estimation error.
(R(i-1)/Ri) ∝ τ+ε (10)
The processor 110 obtains the estimation error ε by compressing it through averaging in the range of i = 1 to N. Alternatively, the processor 110 may perform averaging to obtain a moving average in consideration of tracking state changes.

Ri can be expressed, for example, by the following formula (11).
Ri=(R(i-1))×e ^(-ΔTi/τ) (11)
Therefore, the processor 110 calculates the time constant τ using, for example, the following equation (12): 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 the 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 preceding the point Pd corresponding to R1. Note that R0 is not shown in FIG. 14. If the congestion rate of the point Pc corresponding to the point Pd corresponding to R0 is at the upper limit, the error will be large, so the 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, the processor 110 calculates the time constant τ using equation (12) for i = 2. Note that the point Pc corresponding to point Pd is the point Pc before the differential congestion rate CD is calculated by subtracting the value of the curve Lg. Therefore, the time between point Pd and the point Pc corresponding to point Pd is the same. 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.

The differential congestion rate calculated using the measured congestion rate value 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), may be ignored because it is close to 0. In other words, 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 τ.

In step ST55, processor 110 estimates the time ΔTb until operation returns to normal and the time Tb at which operation returns to normal. Time Tb is, for example, the time at which the differential congestion rate based on the congestion rate calculated in step ST54 by multiplying by n2 or adding m2 falls below threshold CDa. The time ΔTb until operation returns to normal is the time from the current time to time Tb.

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 straight 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, which 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, as follows:
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, by the following equation: 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:

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:

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.

In addition, the processor 110 transmits the time ΔTb and time Tb until operation returns to normal to various devices, for example, 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. Note that 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.

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 passed since the congestion rate began to return to normal. Alternatively, processor 110 determines that operation has returned to normal in response to receiving information from traffic management system 200 indicating that operation has returned to normal. 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.

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.

The congestion prediction system 1b of the fourth embodiment achieves the same effects as the third embodiment.

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.

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.

In the above embodiment, some or all of the processing performed by the congestion rate management system 400 may be performed by the congestion prediction server 100 or the traffic management system 200. In the above embodiment, some or all of the processing performed by the traffic management system 200 may be performed 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 performed by the traffic management system 200 or the congestion rate management system 400.

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

Instead of the congestion rate, the congestion prediction system 1 may use a value other than the congestion rate that indicates the state of vehicle congestion.

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

The congestion prediction system 1 of the above embodiment is a system that predicts the congestion rate of a railway. However, the congestion prediction system of the embodiment may also be a system that predicts 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, trolley bus, guideway bus, or other bus, a ship, an airplane, an elevator, or other vehicle.

The congestion prediction server 100 may be divided into multiple devices. These multiple devices may then share the processing responsibilities of the above embodiments.

The processor 110 may implement some or all of the processing implemented by a program in the above embodiments using a hardware circuit configuration.

The program that realizes the processing of the embodiment is 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. In this case, 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.

The above describes an embodiment of the present invention, but it is presented as an example and does not limit the scope of the present invention. The embodiment of the present invention can be implemented in various forms without departing from the spirit of the present invention.

1, 1b Congestion prediction system 100 Congestion prediction server 110 Processor 120 ROM
130 RAM
140 Auxiliary storage device 141 Congestion database 150 Communication I/F
160 Bus 200 Operation control system 300 Measuring device 400 Congestion rate control system 500 Ticket gate system

Claims (9)

a processing unit that predicts a state of vehicle congestion in a first section that is a prediction target, 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 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. 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 . 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. 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. 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. 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. 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. 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. 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 .