JP7163105B2 - Demand forecasting system and method - Google Patents

Description

The present invention relates to a system and method for accurately predicting future travel demand by combining data owned by transportation companies and external information for transportation facilities.

It is important for railway companies and other transportation operators to predict future passenger movement demand in order to improve the quality of transportation services and achieve highly efficient operations. In particular, in planning operations for train operation schedules and transportation facilities, we forecast passenger travel demand over a time span of several months to a year or even several years in advance, and based on that, we determine the number of trains on each route and each time period. We will decide the operation interval of

In the process of making the schedule plan concrete, it is necessary to coordinate and negotiate with the relevant departments that manage the trains and crews, so explain the necessity and effects of changing the timetable to those related departments and get their consent. This is very important. Also, when making a decision to reduce the number of services, etc., you may be asked to explain to commercial facilities and local governments in the area around the route. Therefore, the person in charge of timetable planning needs to predict the demand for each line and each station as accurately as possible in a highly convincing manner.

At present, the method of analyzing passenger travel demand using the results of observation surveys conducted once a year (or once every few years) is used, but the frequency of information update is low, and the analysis results are highly convincing. There is a problem that we have not been able to obtain it.

On the other hand, in recent years, efforts have been made to accumulate and utilize data owned by railway operators. discloses a technique for predicting power demand with high accuracy. Further, Patent Document 2 discloses a passenger demand prediction technique that extracts only data that satisfies input conditions from accumulated data and outputs predicted values at high speed using a statistical method.

JP 2018-23227 A JP-A-9-230910

In order to predict travel demand for each route and each station necessary for railway timetable planning using the technologies of Patent Documents 1 and 2, travel history data for the past several years is accumulated for each route and each station. It is necessary that However, at present, there are very few railway operators who have collected and sufficiently accumulated such data, and the applicable targets are limited.

It is also possible to install new measurement devices and systems to collect data, but this requires development costs and requires a long period of time until sufficient data is accumulated. On the other hand, the techniques disclosed in Patent Literature 1 and Patent Literature 2 basically create a typical pattern from accumulated past data and output it as a predicted value. We cannot respond to demand forecasts for the distant future that do not show signs.

SUMMARY OF THE INVENTION It is an object of the present invention to predict future passenger movement demand using the results of prediction using existing data without adding a new system.

According to a preferred aspect of the present invention, performance data, which is past time-series numerical data, is aggregated with a first temporal granularity, and a first prediction model having the first temporal granularity is created. a model creation unit of, a second model creation unit that aggregates performance data with a second temporal granularity smaller than the first temporal granularity and creates a second prediction model having the second temporal granularity; a prediction unit that predicts future numerical data based on a first predicted value obtained using the first prediction model and a second predicted value obtained using the second prediction model It is a demand forecast system.

Another preferred aspect of the present invention is a demand forecasting method in which a computer processes collected data to perform demand forecasting. In this method, a first step of aggregating actual data, which is past time-series numerical data, at a first temporal granularity and creating a first prediction model having the first temporal granularity; a second step of aggregating the data at a second temporal granularity smaller than the first temporal granularity and creating a second predictive model having the second temporal granularity, using the first predictive model a third step of predicting future numerical data based on the obtained first predicted value and the second predicted value obtained using the second prediction model;

Future passenger movement demand can be predicted using the results of predictions using existing data without adding a new system.

It is a figure which shows the system of a present Example, and the business flow of a timetable planner of a transportation means. It is a figure which shows the system configuration|structure of a present Example. 3 is a diagram showing a data structure of performance data 31. FIG. 3 is a diagram showing a data structure of station/route information 32. FIG. 3 is a diagram showing the data structure of external information 33. FIG. 4 is a diagram showing the data structure of passenger demand data 34. FIG. 4 is a flowchart of an annual trend model creation program 21; 4 is a flowchart of a seasonality model creation program 22; It is a figure which shows an example of the model by year. It is a figure which shows an example of a seasonality model. It is a figure which shows an example of the model according to time zone. 4 is a flow chart of a time zone model creation program 23. FIG. 3 is a diagram showing the data structure of model data 35. FIG. 3 is a diagram showing the data structure of model data 35. FIG. It is a figure which shows an example of the condition input screen of passenger demand forecast. 4 is a flow chart of a passenger demand prediction program 24; 4 is a diagram showing the data structure of scenario data 36. FIG. It is a figure which shows an example of the confirmation screen of passenger demand data.

Embodiments will be described in detail with reference to the drawings. However, the present invention should not be construed as being limited to the description of the embodiments shown below. Those skilled in the art will easily understand that the specific configuration can be changed without departing from the idea or gist of the present invention.

In the configuration of the invention described below, the same reference numerals may be used in common for the same parts or parts having similar functions between different drawings, and redundant description may be omitted.

When there are a plurality of elements having the same or similar functions, they may be described with the same reference numerals and different suffixes. However, if there is no need to distinguish between multiple elements, the subscripts may be omitted.

Notations such as “first”, “second”, “third” in this specification etc. are attached to identify the constituent elements, and do not necessarily limit the number, order, or content thereof is not. Also, numbers for identifying components are used for each context, and numbers used in one context do not necessarily indicate the same configuration in other contexts. Also, it does not preclude a component identified by a certain number from having the function of a component identified by another number.

The position, size, shape, range, etc. of each configuration shown in the drawings, etc. may not represent the actual position, size, shape, range, etc., in order to facilitate understanding of the invention. Therefore, the present invention is not necessarily limited to the positions, sizes, shapes, ranges, etc. disclosed in the drawings and the like.

All publications, patents and patent applications cited herein are hereby incorporated by reference into this description.

Elements presented herein in the singular shall include the plural unless the context clearly dictates otherwise.

An example of the system of the embodiments described in detail below is a demand forecasting system that includes a processor that executes a program and a storage device that stores the program. A boarding/alighting facility for using the transport means and a part of the vehicle are provided with measuring means for detecting the number of passengers, and a storage device stores the number of passengers partially measured by the measuring means. The processor preliminarily calculates trends for each year, seasonality, and time period, and combines the input correction values to calculate future forecast values for passenger data.

Furthermore, by manually inputting future urban development plan information into the forecast results using existing data without adding a new system as described above, it is possible to obtain highly convincing future passenger travel demand. Predict.

According to one example of the system of the embodiment, by using accumulated data on the number of passengers collected fragmentarily from boarding and alighting facilities and vehicles, a trend model of passenger demand for transportation facilities can be modeled into three types: annual, seasonal, and time zone. By creating it from a perspective and making corrections by transportation planners, more accurate future passenger demand can be predicted. In addition, by accumulating the demand forecasting process and results and sharing them among transportation planners, it facilitates mutual understanding and handover of work between related parties. Problems, configurations and effects other than these will be clarified by the following description of the embodiments.

An embodiment of the present invention will be described with reference to FIGS. 1 to 15. FIG. Although the embodiments of the present invention are intended for railway transportation services, the present invention can be applied to means of transportation used by a large number of people (for example, airplanes and buses) and to the field of physical distribution (delivery).

FIG. 1 is a diagram showing an overview of the business flow of a railway diagram planner in the system of the embodiment of the present invention.

The demand forecasting device 1 of this embodiment uses sensors attached to trains and partial performance data 31 that can be acquired from existing equipment in the station premises to predict trends in passenger demand by year, season, and time zone. Based on the analysis and external information 33 such as future urban development plans, passenger demand on the railway network to be calculated is predicted in consideration of correction values input by the timetable planner 1000 .

For example, the output passenger demand data 34 is input to the operation diagram planning system 10, and combined with the data of the operation diagram plan formulated by the diagram planner 1000, a simulation regarding the movement of each passenger is performed. It can predict the congestion of all trains and all stations on the railway network.

As the above simulation method, for example, utilization of agent simulation technology can be considered. The congestion prediction results obtained from the simulations are compared and analyzed, and the timetable planners use them as quantitative judgment materials in formulating better operation timetable plans.

FIG. 2 is a diagram showing the system configuration of the demand prediction device 1 of this embodiment. The demand prediction device 1 is a general computer (server etc.). In this embodiment, one physical computer will be explained, but it can also be configured as a computer system configured on a plurality of logically or physically configured computers. It may operate on a virtual computer constructed on multiple physical computer resources.

The demand prediction device 1 has a central control device 11 , an input device 12 such as a keyboard and a mouse, an output device 13 such as a display, a communication device 14 , a main storage device 15 and an auxiliary storage device 16 . These are interconnected by buses.

The annual trend model creating unit 21, the seasonal model creating unit 22, the hourly model creating unit 23, and the passenger demand forecasting unit 24 in the main storage device 15 are programs. Hereinafter, when the subject is described as "○○ part", the central control unit 11 reads each program from the auxiliary storage device 16, loads it into the main storage device 15, and then performs the function of each program (details will be described later) shall be realized. These programs may be automatically executed according to predetermined time intervals (for example, every other day, every other week, every month, etc.), or may be executed at the timing instructed by the system operator. . Details of these programs will be described later.

The auxiliary storage device 16 stores performance data 31 , master data 32 , external information 33 , passenger demand data 34 , model data 35 and scenario data 36 . The demand forecasting device 1 is equipped with a keyboard, a mouse, etc., and is connected to an input interface for receiving input from the planner, a display device, a printer, etc., and outputs program execution results in a format that can be viewed by the planner. It has an output interface.

The demand prediction device 1 can communicate with an external system 2 and an external server 3 via a network 4 . Here, the external system 2 is, for example, a bus schedule planning system 10, which transmits the prediction result of passenger demand output by the demand prediction device 1, and utilizes it for creating a better schedule plan. Further, the master data 32 of station and route information and calendar information used in the train schedule planning system may be received by the demand prediction device 1 and utilized.

The external server 3 is, for example, a server that counts and manages the number of passengers passing through the ticket gate read by the automatic ticket gate, and a train information management server that collects and manages the number of passengers on the train. The history data collected by these external servers 3 are received by the demand forecasting device 1 via the network, accumulated as performance data 31, and utilized.

The demand forecasting device 1 may be owned by a railway operator as part of a business system, or may be owned by a service operator different from the railway operator and is a business that distributes congestion prediction results to the railway operator. may be in the form

FIG. 3 shows the data structure of performance data 31 stored in the auxiliary storage device 16. As shown in FIG. The performance data 31 accumulates various data held by railway operators. Here, the fare income data 311, the number of passengers data 312, and the number of people passing through the ticket gate data 313 will be described as representative examples.

First, fare revenue data 311 is a representative example of data that can be collected and accumulated on a yearly basis. The fare income data 311 includes, for example, year and amount information. If monthly aggregated results remain, the monthly aggregated results may be used as they are. Such fare revenue results are information disclosed in financial statements and the like, and generally it is easy to obtain information going back several years or even ten years or so. Therefore, it is considered that the data is suitable for grasping trends in macro passenger demand on a yearly basis.

Next, the passenger number data 312 will be explained. A railway operator manages train position information and data on train interior conditions using an operation management system and a train information management system, and train information is sent from these external servers 3 to the demand prediction device 1 via a network 4. It is possible to collect and accumulate. For example, if a train information management system is used, train positions, train numbers, train failure information, etc. can be sent from each train and collected at the operation management center. In general, trains are equipped with sensors capable of measuring the weight of the train in order to adjust the intensity of braking. Train occupancy information can be inferred from the average weight per passenger by collecting train weight measurements. In addition, the estimated number of passengers can be accumulated as the number of passengers data 312 .

The number of passengers data 312 includes, for example, year, month, route name, time period (in units of one hour), and number of passengers. In addition to year and month, data may be saved by day, or by train number (set) instead of route name. The aggregation unit depends on the data source. The time period may also be stored in the minimum granularity that enables data measurement, for example, in units of seconds instead of in units of one hour, and aggregation processing may be performed at the time of subsequent analysis. The inclusion of yearly and monthly information makes it possible to analyze seasonal changes over at least one year. Other examples of data for which seasonal changes can be analyzed include the above-mentioned fare revenue data and the number of commuter pass sales. In both cases, it is necessary to be able to aggregate by month.

Next, the data 313 of the number of people passing through the ticket gate will be described as an example of performance data that can be utilized when analyzing usage trends by time zone. In recent years, automatic ticket gates have been installed in many railway stations, and passengers can use the ticket gates at stations by reading contactless IC cards (or mobile terminals with equivalent functions) or magnetic tickets. You can enter or leave. The information read by the automatic ticket gate is transmitted to the data management server group (external server 3) managed by the railway operator via the network and accumulated as ticket gate passage data. The ticket gate passage data includes information such as the station and time when each passenger entered the train to use the train, and the station and time when they got off. The data shown in the ticket gate passing number data 313 can be accumulated. The aggregation unit is not limited to one hour, and can be arbitrarily set according to the measurement granularity of the original data.

Examples of other data sources that may be included in performance data 31 include:

(1) Number of People Information Estimated from Surveillance Camera Images In recent years, surveillance cameras have been installed near ticket gates and platforms at stations for safety reasons. Technology has also been developed to detect people from images captured by surveillance cameras and count the number of people present in a given space. Therefore, data on the number of passengers obtained by analyzing surveillance camera images is collected and stored. Since the spatial range that can be filmed by a single surveillance camera is limited, it is common to install multiple surveillance cameras near ticket gates, on each platform, aisle, and stairs at a single station. By processing and aggregating data collected by multiple surveillance cameras, it is expected to expand the collection range and improve the accuracy of analysis.

(2) Public Wireless LAN Connection History With the spread of public wireless LANs that can be used in stations and trains, access points are being installed in various places. Note that the public wireless LAN may be provided by a company other than the railway company. A public wireless LAN is a service that provides connection to the Internet via a wireless LAN, and passengers connect to the Internet from mobile terminals such as notebook PCs, tablet PCs, and smartphones via access points. Since the reachable range of radio waves from one access point is generally about several tens of meters, a plurality of access points are installed in a wide space such as a station. In order to prevent interference when a mobile terminal can communicate with a plurality of access points, communication is performed using an SSID that identifies a network. Therefore, the access point side can acquire the connection start time and connection end time of each mobile terminal. By using this connection information, it is possible to collect and accumulate information on the number of people staying at a certain place.

FIG. 4 shows the data structure of the master data 32 stored in the auxiliary storage device 16. As shown in FIG. The master data 32 includes railway station and route information to which the system is applied. The station information 321 includes information such as station ID, station name, owner company, and location. In addition, latitude and longitude information and equipment information in the station premises (installation status of monitoring cameras, etc.) may be included. The route information 322 includes information such as route IDs, route names, and operating companies. Other information may be included, such as jurisdictional information. The station/route related information 323 includes information such as route IDs, station IDs, and running order. The stations that make up the route are basically stored according to the actual order of arrangement.

The master data 32 needs to be updated as new stations or routes are added or stations are abolished. The update work will be carried out by the system operator when the new station/line is actually opened. Also, if it is desired to forecast demand in anticipation of a new station development plan that is scheduled several years ahead, it is necessary to prepare fictitious master data with new stations added. In this case, the system operator or the user of the demand forecasting device 1 (timetable planning worker) carries out the fictitious master data creation work. As described above, the demand forecasting device 1 needs to manage a plurality of master data. The timetable planner designates and uses master data according to the purpose of analysis.

FIG. 5 shows the data structure of the external information 33 stored in the auxiliary storage device 16. As shown in FIG. The external information 33 stores past and future event information and urban development information that are thought to affect railroad passenger demand. Specifically, information of date 331, location 332, content 333, and source 334 is included.

The date 331 stores the approximate year and month of development in the case of urban development plans, and information on the scheduled dates of events in the case of event information. Places 332 store approximate areas, stations, and routes where changes in passenger demand are expected to occur. The content 333 includes specific information on urban development and events, and the source 334 includes information released by developers and event operators.

Such external information may be automatically collected from Web information according to predefined keywords, or may be manually collected or added by a system operator or timetable planning work. In addition, as the time approaches, future development plans and event information will be disclosed in more detail, so it is good to have a system for regular maintenance. At that time, if the update contents and update date/time of the external information are also saved, the flow of materialization of development plans and events can be known, and it is thought to be useful in determining the parameters of the demand forecast work.

FIG. 6 shows the data structure of the passenger demand data 34 stored in the auxiliary storage device 16. As shown in FIG. Passenger demand data 34 stores forecast data created and output by the demand forecasting device 1 according to the conditions input by the user (timetable planner). The passenger demand data 34 includes, for example, ID 340, year 341, month 342, weekdays and holidays 343, departure station ID 344, arrival station ID 345, departure time period 346, number of people 347, and other information. It represents information about where and when to start moving.

The values of year 341, month 342, weekday 343, departure station ID 344, and arrival station ID 345 are acquired from the conditions input by the user of the monthly demand prediction device 1 (timetable plan creator). An example of the input screen will be described later.

One combination of the departure station ID 344 and the arrival station ID 345 may be targeted in one request, or a plurality of combinations may be targeted. When a plurality of combinations are targeted, it is desirable to assign a unique ID to each passenger demand data creation unit and manage them as one unit. For example, the data of ID2 in FIG. 6 includes two combinations of data.
Also, although the time granularity of the departure time zone 346 is shown as an example for each time zone, it may be stored in units of seconds, or may be stored in arbitrary units such as 1 minute or 10 minutes.

FIG. 7 is a flow chart of the annual trend model creation program 21. As shown in FIG. The annual trend in the present embodiment is the fluctuation trend of demand for each year when viewed from a long-term perspective. For example, for performance data aggregated on a monthly basis, aggregation is performed on a yearly basis from a long-term perspective, and annual demand fluctuations are treated as trends.

In step S<b>201 , the annual trend model creating unit 21 acquires the master data 32 and the performance data 31 . In step S202, the annual trend model creating unit 21 aggregates the performance data 31 for each year. Then, in step S203, change points are extracted and the data is divided into periods.

The change point in step S203 is the time (total point) when the trend changes significantly. For example, if the aggregated results show that demand continues to increase by 10% each year for five years, and then continues to decrease by 10% each year for the next five years, up to the present, the change point will be the year five years ago. . In this case, the data is divided into the period from 10 years ago to 5 years ago and the period from 5 years ago to the present. Alternatively, curve approximation may be performed to set the point at which the slope changes as the point of change.

In step S204, an approximate straight line model or an approximate curve model is created for each divided period. Then, the model created in step S205 is used as a trend model, and the model ID is stored in the assigned model data 35. FIG. A specific image of the trend model will be described later.

FIG. 8 is a flow chart of the seasonality modeling program 22. As shown in FIG. The seasonality in the present embodiment is, for example, monthly demand fluctuations, and is demand fluctuations that are regularly repeated every year, such as an increase in demand in July and a decrease in demand in February.

In step S<b>301 , the seasonality model creating unit 22 acquires the master data 32 and the performance data 31 . In step S302, the seasonality model creation unit 22 aggregates the performance data 31 for each month. In step S303, the seasonality model creation unit 22 divides the performance data 31 by the yearly trend component.

The trend component in step S303 is a value calculated by the trend model created by the annual trend model creation unit 21. FIG. For example, in the case of a trend model in which demand increases at an annual rate of 10%, by dividing the increase rate from the performance data 31, the trend can be removed and data with stationarity can be created. The same is true for decreasing, ie removing the slope component removes the trend component. The slope component can also be said to be a sufficiently low frequency component compared to the frequency of the Fourier series model below.

Then, in step S304, the data obtained by dividing the trend component from the performance data 31 is divided in 12-month (one-year) cycles. In step S305, the data obtained by dividing the data with one year as one cycle is subjected to Fourier expansion to create a Fourier series model. Then, in step S306, the created Fourier series model is used as a seasonal model, and the model ID is stored in the assigned model data 35. FIG.

In the present embodiment, the use of Fourier expansion to create a seasonal model was described as an example, but the creation of a seasonal model is not limited to Fourier expansion. Also good. A specific image of the seasonality model will be described later.

9A to 9C are diagrams showing specific images of the annual trend model, the seasonal model, and the hourly model.

A specific image of the annual trend model will be described along FIG. 9A. In FIG. 9A , each dot on the screen is the yearly performance data aggregated in step S202 described above, and the solid line is the model value created by the yearly trend model creating unit 21 . The data is split into period 1 (901) and period 2 (902), creating two trend models y1 (903) and y2 (904). The reason why the data is divided into two is that the trend changes greatly at the change point (905). . Annual trend models can, for example, reflect the slow fluctuations associated with population growth and decline over years to decades.

A specific image of the seasonality model will be described along FIG. 9B. In FIG. 9B, each dot on the screen is the data obtained by dividing the trend component from the monthly performance data 31 in step S303 described above, and the solid line is the value of the model created by the seasonality model creation unit 22. The data is divided with one year (12 months) as one cycle (911), and a seasonality model y(t) (912) is created. Seasonality models can reflect month-to-month variations due to social factors, such as summer vacations and end-of-term busy periods.

A specific image of the hourly model will be described with reference to FIG. 9C. FIG. 9C is a bar graph showing the number of passengers per hour for a combination of a departure station (SA station) and an arrival station (SB station), using the performance data 31. As shown in FIG. In other words, it represents the change in tendency of passengers traveling from SA station to SB station in one day. The allocation rate for each time slot can be calculated by dividing the number of passengers in each time slot by the total number of passengers per day (total value from 5:00 to 23:00 in FIG. 9C). This allocation rate is one of the representative examples of the hourly model. The allocation rate is stored in the model data 35 as array information as follows.
1. 5:00: 5.2%
2. 6:00: 6.1%
・・・
19. 23:00: 1.3%
The hourly model can reflect daily fluctuations due to social factors, such as congestion during morning and evening commuting hours. Also, depending on the combination of the departure station (SA station) and the arrival station (SB station), which is a business district and which is a bedroom town, different models are often used.

FIG. 10 is a flow chart of the hourly model creation program 23 . As described above, the time zone trend in the present embodiment represents demand fluctuations within a day by separating them into fixed time units for each combination of departure station and arrival station.

In step S<b>401 , the hourly model creating unit 23 acquires the master data 32 and the performance data 31 . In step S402, the hourly model creating unit 23 extracts only data that satisfies the specified conditions (type and time of actual data to be used, combination of departure station and arrival station).

For example, when the user (timetable plan creator) specifies the condition that "create a model for each time period that departs from SA station and arrives at SB station in units of one hour using actual data in July 2017". Furthermore, in step S402, from the performance data 31, the performance data for the period of July 2017 and the data indicating the movement from the SA station to the SB station are extracted. If there is no data, display an error message and terminate the program.

In step S403, the hourly model creation unit 23 uses the extracted data to total, for example, hourly, and in step S404, uses the totaled result to calculate the hourly usage ratio (allocation ratio). In step S405, the model ID is stored in the assigned model data 35, with the obtained usage ratio result as a time zone model.

In the present embodiment, the allocation rate is used to generate the hourly model. However, the present invention is not limited to this, and a regression model, Fourier expansion, or the like may be used.

11A and 11B are diagrams showing the data structure of the model data 35. FIG. The model data 35 stores annual trend model management data 351 , seasonal model management data 352 , hourly model management data 353 , and model data list 354 .

11A and 11B, for the sake of convenience, each table is described separately, but these may be integrated and stored as one table. The annual trend model management data 351 includes information such as a unique ID, departure station ID, arrival station ID, model ID, and data source used to create the model. You can also include the date and time the model was created, who created it, and the time period of the data source used to create the model.

If a station ID is written in each of the departure station ID and arrival station ID values, it indicates a specific combination of departure station and arrival station. If nothing is described, it represents a combination of all departure stations to all arrival stations (that is, the entire target area).

When using actual fare revenues as a data source, since data is generally not collected for a combination of specific departure and arrival stations, the trend model is for all departure stations and all arrival stations. Even when actual passenger data is used as a data source, data is generally not collected for a combination of specific departure and arrival stations, so the trend model is for all departure stations and all arrival stations. These models are effective, for example, in grasping macroscopic demand trends in a certain metropolitan area.

On the other hand, when using the data of the number of people passing through ticket gates or the actual number of commuter passes sold as data sources, it is possible to tabulate by any combination of departure station and arrival station. stores a specific station ID. The seasonal model management data 352 and the hourly model management data 353 are similar to the annual trend model management data 351 .

Since the model data stored in the model management data by time period 353 is data representing fluctuations by time period, actual data with the finest temporal granularity is required. A representative example is the data on the number of people passing through the ticket gate. When using the data on the number of people passing through the ticket gate, the date and time information is recorded in detail. However, data can be aggregated by month or day of the week, and models for different time periods can be created and stored.

Also, as supplementary information of the performance data, external data acquired from the external server 3 may be utilized to generate a model. Specifically, as external factors that affect demand, forecasted precipitation probability, forecasted temperature, etc. may be incorporated as explanatory variables in the forecast formula. In addition to weather/climate data, various data such as economic indicators, SNS/media information, and tourist statistics survey results may be incorporated as explanatory variables.

In FIG. 11B, the model data list 354 stores an ID for identifying a model and a prediction formula. Models created in the present embodiment, such as trend models, seasonal models, and hourly models, are stored as formulas in the prediction formula column. The formulas in the model data list 354 are prediction models such as simple regression models and multiple regression models. For example, by setting Y as the predicted value of the annual trend model M01 and X as the explanatory variable, the predicted value for the year is obtained by inputting the value of the target year for which X is to be predicted. In the seasonality model M11, Y is the predicted value, X is the explanatory variable, and X is the value of the target month to be predicted, thereby obtaining the predicted value of the month.

The demand forecast model is created based on the performance data 31 as input data, and the timing is arbitrary. If it is decided which model is to be created using which performance data, the model may be automatically updated at regular intervals such as when the corresponding performance data is added or several times a year. Alternatively, model data may be created under conditions individually specified by the user of the demand prediction device 1 or the system operator.

In the example above, the demand forecast model consists of three layers: a yearly trend model with a time granularity of one year, a seasonal model with a time granularity of January, and a time zone model with a time granularity of one hour. did. However, instead of or in addition to these, models with other temporal granularities (for example, one day, one week, or ten years) may be prepared. The hierarchy of the model may be two, or four or more. Further, as shown in FIG. 11A, the trend model for each layer may include a plurality of models depending on the combination of departure station-arrival station.

FIG. 12 is a diagram showing an example of a screen for inputting conditions when a user (timetable planner) of the demand forecasting device 1 performs passenger demand forecasting. Such a screen is created by the passenger demand prediction unit 24 and displayed on the output device 13 . The screen 1001 has several text input fields and option boxes, and the user can freely input text using the input device 12 or choose from fixed options according to his/her analysis purpose. , perform the operation of selecting conditions.

In the example of the screen 1001, for example, a title 1201 representing the purpose of the demand forecast and columns for entering special notes 1202 are provided at the top. It also has columns for designating a prediction target time 1203 and a prediction target area/station (a combination of a departure station and an arrival station) 1204 .

If a similar demand forecast has been performed in the past for the same analysis purpose, there may be a function to call up past work results (condition input screen) from a button 1205 such as "call created scenario". . In this case, if the usage authority is managed for each user, the assigned user ID 1206 may be used to call up only the analysis results that the user has worked on. Alternatively, the analysis results of all users may be referred to.

The prediction target time 1203 may be specified separately for the year, month, and weekday/holiday, or may be selected collectively for the year, month, and day as in the example of FIG. 12 . Similarly, for the prediction target area/station 1204, in addition to the options of the specific departure station and arrival station "SA station - SB station", for example, a method of specifying "all stations - all stations") or the entire specific route ( For example, a designation method of "all LA lines") may be used. Also, there may be a plurality of combinations of departure stations and arrival stations, in which case a list of combinations of departure stations and arrival stations may be prepared in the form of a text file or the like, and an interface for uploading it may be provided. In addition to stations and routes, a method of designating in units of municipalities and a method of allowing users to freely define a combination list of stations are also conceivable.

In FIG. 12, "SA station-SB station" is selected in the prediction target area/station 1204 (ID of SA station is 10001, ID of SB station is 10002), and in this case, the prediction model targets the station interval is selected by default (trend model M03 here). In addition, the seasonal model and the hourly model (here, the seasonal model M13 and the hourly model M22) having the same conditions as the model selected in the trend model are selected by default. The conditions are, for example, a combination of a departure station ID and an arrival station ID, a route ID, a data source, and a numerical unit, and the same model is selected. If there are multiple models with the same conditions, the user can select one. If there is no model with the same conditions, the user should be able to select a similar one.

Also, the model selected by default may be changed by the user. For example, as a trend model, select data that targets "all stations - all stations" that shows a more macro trend (for example, trend model M01), and select a model between specific stations in the seasonal model and time zone model. You can In this case, a conversion table for converting the predicted value of “all stations-all stations” into the predicted value between specific stations is separately prepared and stored in the main storage device 15 . For example, the conversion table contains
"Data on the number of people in 'SA station - SB station' (persons) = Fare revenue data in 'all stations - all stations' (yen) * Share of 'SA station - SB station' (%)/100/average fare per person (Circle)"
A conversion formula such as is set in advance by the user and stored.

The lower portion of the screen 1001 is an example of a screen for selecting/editing an annual trend model, a seasonal model, and a time zone model. In the example of FIG. 12, the model is displayed graphically, but it may be displayed in a tabular format or the like. Although the screen 1001 has been described as having a tab screen configuration, it may be configured such that when a button or the like is pressed, each model is displayed on a pop-up screen. Each model may have a common screen configuration. For example, the annual trend model selection/editing screen has the following functions.
1. 2. Select a model from the list and load it. 3. Referencing, adding, and editing external information. 4. Display the trend of the selected model and the predicted value in graph format. Manually Edit Forecast Values and Save

A list of models is displayed based on the data stored in the model data 35 . Also, the external information is displayed based on the data stored in the external information 33 . At that time, the conditional input value of the "prediction target period" may be referred to, and only the external information of the period before and after that period may be extracted and displayed. Alternatively, only the information selected for the display may be displayed on the screen 1001 . The external information may be displayed as text data as shown in FIG. 12, or may be output as voice. Alternatively, it may be a moving image such as a news video.

A screen 1001 shows an example of the screen when M03 is selected as the annual trend model. Various variations are conceivable for the display method of the graph. For example, the period for which actual data has already been collected and accumulated and the forecast period can be displayed in different colors, or the actual data used to generate the model can be plotted. , the predicted value v of the “prediction target period” is highlighted and plotted.

This forecast value v is a value obtained by inputting the forecast target period (2020 in the example of the screen 1001) into the annual trend model M03, but this value is a value derived from the trend of past actual data. . Such trends are based, for example, on natural population growth, but do not include factors such as future urban development plans or increased passenger demand during major events. Therefore, the screen 1001 for inputting the prediction target time provides a function that allows the user to manually adjust the prediction value v while referring to external information.

Specifically, an edit button is prepared near the graph showing the trend of the model and the plot position of the predicted value v, and the user can click on it to enter a new predicted value v'. Prepare. As a result, for example, if you want to predict the passenger demand in a situation where a large-scale event is held in which about 500,000 people are expected to mobilize during the prediction target period, v + 500,000 people A new predicted value v' can be set for the position. It is desirable to be able to save the operation history of inputting a new predicted value v' for the original predicted value v.

Similarly, for seasonal models and hourly models, users can select models, check forecast values, and manually enter new forecast values. Since the seasonality model is a model that expresses monthly fluctuations, for example, on a screen that displays monthly bar graphs or line graphs, the user selects a specific month, refers to external information, Set a new forecast value by increasing or decreasing the demand forecast value for a specific month. For example, assuming that demand usually declines during the year-end and New Year holidays and in the summer due to holidays, the demand forecast for this summer will be further revised downward if the holidays are particularly long.

Similarly, for the hourly model, for example, if the model represents hourly fluctuations, the user can select a certain time period on the screen that displays hourly demand forecast values in bar graphs or line graphs. Adjust hourly models by selecting and manually entering new forecast values. For example, the number of passengers increases in the morning and evening for commuting to and from work, but if it is assumed that companies will work from home in a certain year or later, the number of passengers in the morning and evening will be revised downward.

The annual trend model, seasonal model, and hourly model may be edited for each combination of specific departure stations and arrival stations, or may be common to all stations. For example, in the case of predicting passenger demand at the time of holding a large-scale sporting event, it is often the case that the location and start date and time of the event are decided in advance. By manually adding models for each time zone for several hours before and after the event start time, it is possible to create passenger demand data for simulating congestion at the nearest station to the venue on the day of the event. After selecting and editing the annual trend model, the seasonal model, and the hourly model, the demand data generation process is executed by pressing the passenger demand data creation button.

FIG. 13 is a flow chart of the passenger demand prediction program 24. As shown in FIG. The passenger demand prediction program 24 predicts the passenger demand for the required prediction target area according to the conditions input by the user on the condition input screen for passenger demand prediction, and stores it in the passenger demand data 34 .

The passenger demand forecasting program 24 is executed, for example, at the timing when the "create passenger demand data" button is pressed on the screen 1001 for inputting conditions for passenger demand forecasting. First, a set of conditions specified on the passenger demand forecast condition input screen 1001 is read (step S501). The specified conditions are the title of the prediction work, the time to be predicted, and the area and station to be predicted. If the value of the prediction target area/station consists of a plurality of combinations of departure stations and arrival stations, the latter processing is repeated for each combination of departure station-arrival station. For example, if the prediction target area/station value is “all stations-all stations”, the master data 32 is referenced, all station IDs included in the station information 321 are extracted, and possible departure station-arrival Enumerate all combinations of stations.

By referring to the designated yearly trend model data and the values of the prediction target area/station, the corresponding model is acquired from the model data 35, and the prediction value is calculated by substituting the value of the prediction target period. If there is no model corresponding to the target departure station-arrival station combination, it is preferable to refer to a model of another target station (for example, all stations-all stations). In the yearly trend model designation screen of the screen 1001 for inputting passenger demand forecast conditions, if the user manually inputs a new forecast value, it is replaced with the input value (step S502).

Similarly, by referring to the specified seasonal model data and the prediction target area/station values, the corresponding model is acquired from the model data 35, and the prediction target time value is substituted to calculate the prediction value. In the seasonal model designation screen of the screen 1001 for inputting passenger demand forecast conditions, if the user manually inputs a new forecast value, it is replaced with the input value (step S503).

For the hourly model, the corresponding model is acquired from the model data 35 according to the specified conditions. If the user manually inputs a new forecast value on the hourly model specification screen of the screen 1001 for inputting passenger demand forecast conditions, the input value is substituted (step S504).

Passenger demand data is generated by synthesizing the predicted values of the annual trend model, the seasonal model, and the hourly model (step S505), and the result of predicting the number of people for one hour is stored in the passenger demand data 34 (step S506). . If the conditions of each model are different, the prediction values are converted using the conversion table described above and synthesized.

In step S505, the first granularity (yearly) forecast value derived from the first forecast model (annual trend model) in process S502, and the second forecast model (seasonal model) in process S503. A predicted value for a specific month of a specific year (for example, July 2020) is obtained from the calculated second granularity (monthly) predicted value. At this time, the monthly forecast values derived from the seasonal model for one year (12 months) are normalized to be equal to the yearly forecast values derived from the yearly trend model for one year. Specifically, for example, if the month you want to forecast is July 2020, the forecast value for 2020 predicted by the annual trend model and the forecast from January 2020 to December 2020 predicted by the seasonal model Just make sure the sum of the values is equal.

Next, in step S505, the predicted value of the second granularity (monthly) is divided by the number of days in the month (for example, 31 in July) to obtain a daily predicted value. From the predicted values of the third granularity (hourly unit) derived from the third prediction model (hourly model), the predicted values for the specific month of the specific year and the specific time period are obtained. Since the example forecast values in FIG. 9C are given in percentages, in this case, the (daily forecast value/100) is multiplied by the hourly forecast value (%) to give an hourly value (e.g., the number of people and amount) can be obtained.

FIG. 14 shows the data structure of the scenario data 36. As shown in FIG. The scenario data 36 stores the history of conditions and work details specified on the condition input screen for passenger demand forecast. Specifically, for example, unique ID assigned to each work, creator information, work date and time (creation date and time of passenger demand data), title (content of work), prediction conditions, selected model information, and prediction values are edited. It includes information such as the history of passenger demand data created and the ID of the created passenger demand data. In addition, access authority information, etc., which can be set to be public/private to other users for each scenario, may be included. Here, the work refers to a series of steps from inputting various conditions on the screen 1001 for inputting passenger demand forecast conditions to finally pressing the passenger demand data creation button. A new ID is given.

By managing and accumulating such work histories as scenario data 36, for example, demand forecasting work assuming the same large-scale event can be shared among a plurality of users, and a few conditions can be set while referring to past work histories. It becomes easy to change and analyze differences. It is also possible to record the process of conducting detailed demand forecast analysis step by step in accordance with the update of external information. For example, scenario data having an ID of SC03 in FIG. 14 indicates that the conditions and model of the scenario data of SC01 were reused, but were not edited.

FIG. 15 is a diagram showing an example of a screen for confirming the created passenger demand data after the user (timetable plan creator) of the demand forecasting device 1 executes the passenger demand forecast. The screen 1101 contains functions (buttons, list boxes, etc.) that call up specific scenarios based on the information stored in the scenario data 36. Users can use the scenarios created by themselves and the tasks of other users. You can call the results, etc. It is desirable that the scenario data 36 also manage which scenario each user can access.

On the screen 1101, after a certain scenario is called up, passenger demand data 34, which is the final output of the scenario, is called up. This is an example that can be confirmed by In order to show changes, a reference value is necessary, but as a method of selecting the reference value, there are methods such as referring to the latest actual data or selecting the demand forecast results created in a different scenario. , it is desirable that there is a screen for selecting passenger demand data as a reference value. It would also be nice if there was a function that allows you to check changes in passenger demand by location and by time of day.

As described above, according to the embodiment of the present invention, a transportation planner refers to external information and corrects a trend model of passenger demand for a transportation facility created from accumulated data. Predict, store and share accurate future passenger demand. As a result, railway operators can use future passenger demand data as basic data when planning measures to alleviate congestion (for example, timetable revisions). In addition, a large amount of capital investment will be required to create a passenger demand trend model using any or a combination of available data sources such as fare revenue data, ticket gate passage data, surveillance camera images, and public wireless LAN connection information. It is possible to know future passenger demand without

It should be noted that the present invention is not limited to the embodiments described above, but includes various modifications and equivalent configurations within the scope of the appended claims. For example, the above-described embodiments have been described in detail for easy understanding of the present invention, and the present invention is not necessarily limited to those having all the described configurations. Also, part of the configuration of one embodiment may be replaced with the configuration of another embodiment. Moreover, the configuration of another embodiment may be added to the configuration of one embodiment. Further, additions, deletions, and replacements of other configurations may be made for a part of the configuration of each embodiment.

In addition, each configuration, function, processing unit, processing means, etc. described above may be realized by hardware, for example, by designing a part or all of them with an integrated circuit, and the processor realizes each function. It may be realized by software by interpreting and executing a program to execute. Information such as programs, tables, and files that implement each function can be stored in storage devices such as memories, hard disks, SSDs (Solid State Drives), or recording media such as IC cards, SD cards, and DVDs.

In addition, the control lines and information lines indicate those considered necessary for explanation, and do not necessarily indicate all the control lines and information lines necessary for mounting. In practice, it can be considered that almost all configurations are interconnected.

Claims (15)

Performance data that is past time-series numerical data is aggregated at a first time granularity, and a first time granularity that has the first time granularity and indicates fluctuations in the performance data at the first time granularity A first model creation unit that creates a prediction model of
The actual data is aggregated with a second temporal granularity smaller than the first temporal granularity, and the aggregated actual data is divided by the fluctuation component of the actual data of the first prediction model to correct the slope. a second model creation unit that removes components and creates a second prediction model having the second temporal granularity from the corrected performance data;
a prediction unit that predicts future numerical data based on a first predicted value obtained using the first prediction model and a second predicted value obtained using the second prediction model;
A demand forecasting system with Further, the performance data is narrowed down under a predetermined condition, the performance data thus narrowed down is aggregated with a third temporal granularity smaller than the second temporal granularity, and a third prediction having the third temporal granularity is performed. A third model creation unit that creates a model,
The prediction unit, based on the first prediction value, the second prediction value, and a third prediction value obtained using the third prediction model, predicts future predictions having a third temporal granularity. predict numerical data,
The demand forecasting system according to claim 1. said first temporal granularity is one year, said second temporal granularity is one month, and said third temporal granularity is one hour;
The demand forecasting system according to claim 2. The prediction unit
normalizing the first predicted value and the second predicted value;
The demand forecasting system according to claim 1. The prediction unit
normalizing the sum of the first predicted value corresponding to the predetermined period and the plurality of second predicted values corresponding to the same predetermined period to be equal;
The demand forecasting system according to claim 4. The first model creation unit
aggregating the actual data with a first temporal granularity, dividing the aggregated actual data into a plurality of periods, and generating the first prediction model for each divided period;
The demand forecasting system according to claim 1. The first model creation unit
generating the first prediction model by creating an approximate straight line model or an approximate curve model for each of the divided periods;
The demand forecasting system according to claim 6. The second model creation unit
Generate the second prediction model using a Fourier series model from the corrected actual data, and remove the frequency component sufficiently low compared to the frequency of the Fourier series model in the removal of the slope component.
The demand forecasting system according to claim 1. The second model creation unit
generating the second prediction model using at least one of a Fourier series model, an autoregressive model, and a moving average model from the corrected performance data;
The demand forecasting system according to claim 1. The third model creation unit
Extraction is performed from the performance data under a predetermined condition, the extracted performance data is aggregated by a certain time unit that is a third temporal granularity, and the ratio of each of the certain time units in one day is calculated, generating an array of ratios as the third predictive model;
The demand forecasting system according to claim 2. The performance data is transportation usage performance data, and includes at least one of the number of users associated with the departure point and the destination and the number of users corresponding to the route,
The demand forecasting system according to claim 1. The prediction unit
displaying at least one of the first predicted value and the second predicted value on a display device and presenting external information; correcting at least one of the predicted value of and the second predicted value of
The demand forecasting system according to claim 1. The prediction unit
Presenting the external information by displaying text information on the display device;
The demand forecasting system according to claim 12. the external information includes time information;
The prediction unit
Presenting the external information including time information related to a prediction target time at which at least one of the first prediction value and the second prediction value is displayed on the display device;
The demand forecasting system according to claim 12. A demand forecasting method in which a computer processes collected data and forecasts demand,
Performance data that is past time-series numerical data is aggregated at a first time granularity, and a first time granularity that has the first time granularity and indicates fluctuations in the performance data at the first time granularity A first step of creating a predictive model of
The actual data is aggregated with a second temporal granularity smaller than the first temporal granularity, and the aggregated actual data is divided by the fluctuation component of the actual data of the first prediction model to correct the slope. a second step of removing components and creating a second predictive model having said second temporal granularity from the corrected historical data;
A third step of predicting future numerical data based on the first predicted value obtained using the first prediction model and the second predicted value obtained using the second prediction model ,
A demand forecasting method comprising:

Images