WO2024116865A1 - 交通リソース貸借管理装置、交通リソース貸借管理システム及び交通リソース貸借管理方法 - Google Patents

交通リソース貸借管理装置、交通リソース貸借管理システム及び交通リソース貸借管理方法 Download PDF

Info

Publication number
WO2024116865A1
WO2024116865A1 PCT/JP2023/041208 JP2023041208W WO2024116865A1 WO 2024116865 A1 WO2024116865 A1 WO 2024116865A1 JP 2023041208 W JP2023041208 W JP 2023041208W WO 2024116865 A1 WO2024116865 A1 WO 2024116865A1
Authority
WO
WIPO (PCT)
Prior art keywords
resource
transportation
location
lending
management device
Prior art date
Application number
PCT/JP2023/041208
Other languages
English (en)
French (fr)
Inventor
弥生 小野
進吾 足立
陽子 平島
陽平 長谷川
Original Assignee
株式会社日立製作所
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社日立製作所 filed Critical 株式会社日立製作所
Publication of WO2024116865A1 publication Critical patent/WO2024116865A1/ja

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0645—Rental transactions; Leasing transactions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/40—Business processes related to the transportation industry

Definitions

  • the present invention relates to a transportation resource rental and management device, a transportation resource rental and management system, and a transportation resource rental and management method.
  • Public transportation such as trains, route buses, express buses, passenger planes, and passenger ships operate according to pre-planned timetables.
  • transportation resources such as vehicles and crew members due to vehicle breakdowns, vehicles not returning to the depot due to accidents, or crew members being absent due to sudden illness.
  • the number of services may be increased due to events or congestion.
  • new resources must be arranged to make up for the shortage or increase in services, but if new transportation resources cannot be arranged, services may have to be suspended.
  • MaaS Mobility as a Service
  • MaaS Mobility as a Service
  • Patent Document 1 discloses a rental system technology that centrally manages information on all rental items in a construction vehicle rental company that has multiple branches in different locations, each of which independently owns, maintains, and operates multiple construction vehicles, and has a means for creating a schedule for moving rental items between rental locations and a means for managing the operating status during the rental period.
  • Patent Document 1 Public transportation that operates according to a timetable has different departure and destination locations for different trips even when they are operating on the same route.
  • the technology described in Patent Document 1 does not anticipate returning resources from a location other than the rental location, or the existence of multiple candidate departure and destination locations.
  • the object of the present invention is to enable transportation resource lending and management devices to easily lend and borrow transportation resources between operators, thereby enabling optimal operation of routes.
  • a transportation resource rental management device is a transportation resource rental management device having a processor that searches for candidates for resources to be rented out when resources are rented out between a plurality of public transportation operators, and has a rental plan creation unit that creates a rental plan based on a rental plan creation request received from an operation management device of a requester, the public transportation operator, that wishes to borrow the resource, and the rental plan creation unit, using the processor, extracts the resources that are candidates for rental from the rental conditions and the rental plan creation request received from the operation management device of the resource owner, the public transportation operator, that owns the resource that can be rented out, as candidate resources, and calculates the compatibility between the candidate resources and the route to be allocated based on route characteristics, and a schedule start/end control unit that stores constraint information on the places and times when crew members can work or vehicles can operate, using the processor,
  • the device has a constraint condition creation unit that creates resource constraint conditions that define the priorities of the contract conditions and constraint conditions that are not related to the schedule start
  • a transportation resource rental and management device can make it possible for transportation resources to be easily rented and lent between operators, thereby enabling route operations to be optimally carried out.
  • FIG. 1 is a diagram showing an example of a network configuration of a transportation resource lending and borrowing management device 1 and related devices.
  • 1 is a diagram illustrating an example of the hardware configuration of a transportation resource lending and borrowing management device 1 and related devices.
  • 13 is a diagram showing an example of the data structure of a loan proposal creation request 61.
  • FIG. 13 is a diagram showing an example of the data structure of a formal request 63.
  • 13 is a diagram showing an example of the data structure of lending conditions 71.
  • FIG. FIG. 13 is a diagram showing an example of the data configuration of a lending/borrowing proposal 315.
  • 13 is a flowchart of the process of the lending proposal creation unit 203.
  • FIG. 2 is a diagram showing an example of the data configuration of route characteristics 301.
  • 13 is a flowchart of a process of a constraint condition creating unit 207.
  • 13 is a flowchart of a process of a constraint condition creating unit 207. This is a diagram to explain where work or operation can start and end. This is a diagram to explain where work or operation can start and end.
  • 3 is a diagram showing an example of the data configuration of the roll call inspection master 303.
  • FIG. FIG. 3 is a diagram showing an example of a data configuration of forwarding information 305.
  • FIG. 13 is a diagram showing an example of the data structure of a constraint 313.
  • FIG. 13 is a diagram showing an example of the data structure of a constraint 313.
  • FIG. 13 is a flowchart of the processing of the crew scheduling unit 209 and the vehicle scheduling unit 2011.
  • FIG. 13 is a diagram showing an example of a route characteristic setting screen displayed to the manager of the resource borrowing requester.
  • FIG. 13 is a diagram showing an example of a screen displaying a diagram of borrowed resources that is displayed to an administrator who has requested resource borrowing;
  • FIG. 13 is a diagram showing an example of a map display screen of borrowed resources displayed to an administrator who has requested resource borrowing;
  • FIG. 13 is a diagram showing an example of a borrowed resource cost display screen displayed to an administrator who has requested resource borrowing;
  • FIG. 13 is a diagram showing an example of a time zone display screen for borrowed resources that is displayed to an administrator who has requested resource borrowing;
  • FIG. 13 is a diagram showing a display screen of the operation schedule or driving schedule of the resource to be lent or borrowed, which is displayed to the manager of the resource owner.
  • FIG. 1 shows a block diagram of the transportation resource lending and borrowing management device 1 and related devices in this embodiment, as well as an example of the network configuration.
  • the transportation resource rental and borrowing management device 1 is connected to the operation and operations management device 6 of bus company A via communication network 46, to the operation and operations management device 7 of bus company B via communication network 47, to the operation and operations management device 8 of railway company C via communication network 48, and to the operation and operations management device 49 of taxi company D via communication network 49.
  • communication networks 46, 47, 48, and 49 may be a common communication network, or may be networks that use different protocols. Furthermore, communication networks 46, 47, 48, and 49 may be either wired networks or wireless networks. Data is transmitted and received between the respective systems and terminals via these networks.
  • Bus operator A's operation and operations management device 6, bus operator B's operation and operations management device 7, railway operator C's operation and operations management device 8, and taxi operator D's operation and operations management device 9 are owned by each public transportation operator and are used to monitor and control vehicles running in each transportation mode, as well as to issue instructions and allocate vehicles and crew members, manage schedules, and manage work hours.
  • Bus operator A, bus operator B, railway operator C, and taxi operator D are examples of public transportation operators, and other public transportation operators such as trams, passenger airplanes, and passenger ships may also be used.
  • the number of operation and operations management devices connected to the transportation resource lending management device 1 is not limited to four, and may be more or less than that.
  • the operation and operations management device may implement functions related to operation management and functions related to operation management of vehicles and crew in separate devices, or may be implemented in a single device. One operator may have multiple operation and operations management devices for each sales office or branch office.
  • Each operation and management device 6, 7, 8, 9 holds the following data: a rental proposal creation request 61, a formal request 63, and rental conditions 71, 81, 91. Details of this data will be described later.
  • the transportation resource lending and borrowing management device 1 holds the following data in the memory unit 30: route characteristics 301, roll call inspection master 303, out-of-service information 305, timetable 307, crew operation information 309, vehicle operation information 311, constraint conditions 313 (consisting of schedule start and end constraint conditions 3131 and resource constraint conditions 3133), and lending and borrowing plan 315.
  • the timetable 307 is data that stores the arrival and departure times for each station and stop for each operating service.
  • crew operation information 309 and vehicle operation information 311 are data that respectively store the allocation of crew and vehicles to each service.
  • Timetable 307, crew operation information 309, and vehicle operation information 311 are all assumed to be equivalent to data used by general public transportation facilities, but transportation resource lending and borrowing management device 1 receives this information periodically or whenever there is a change from each of the connected operation and management devices 6, 7, 8, and 9, and data from multiple entities is managed in an integrated manner. Details of the other data will be described later.
  • the transportation resource lending and borrowing management device 1 has, as functional modules, a transmission/reception unit 201, a lending and borrowing proposal creation unit 203 (comprised of a resource search unit 205, a constraint condition creation unit 207, a crew operation reorganization unit 209, a vehicle operation reorganization unit 2011, a traffic reorganization unit 2013, and a response creation unit 2015).
  • a transmission/reception unit 201 a transmission/reception unit 201
  • a lending and borrowing proposal creation unit 203 (comprised of a resource search unit 205, a constraint condition creation unit 207, a crew operation reorganization unit 209, a vehicle operation reorganization unit 2011, a traffic reorganization unit 2013, and a response creation unit 2015).
  • the transmitting/receiving unit 201 transmits or receives data and processing requests between the operation and management devices 6-9 of each transportation operating entity.
  • the timing of transmitting and receiving data and processing requests between each system will be described later using FIG. 3, but it may be a pull type starting from the operation and management devices 6-9 of each entity, or a push type starting from the transportation resource lending management device 1.
  • the data is converted into a specified format so that there is no need to be aware of differences in data format or items in subsequent processing.
  • the lending proposal creation unit 203 and each sub-function module will be described later in detail.
  • FIG. 2 shows an example of the hardware configuration of the transportation resource lending and borrowing management device 1.
  • the transportation resource lending and borrowing management device 1 is realized using a computer device (information processing device) in which a storage device 51, a memory 52, a microprocessor (CPU: Central Processing Unit) 53, a user interface device (UI device) 54, and a communication device 55 are communicatively connected via a bus 56.
  • a computer device information processing device
  • a storage device 51 a memory 52
  • a microprocessor CPU: Central Processing Unit
  • UI device user interface device
  • communication device 55 may be designed as a virtual machine and realized as a cloud system, for example.
  • the storage device 51 is a non-volatile storage device such as an SSD (Solid State Drive) or a hard disk drive, and stores computer programs 57 that implement the functional modules 201-2015 (see FIG. 1) executed by the transportation resource lending and borrowing management device 1, as well as data 58 such as data necessary for executing the functional modules or data 301-315 (see FIG. 1) generated by the functional modules.
  • the memory 52 is a volatile memory such as a RAM (Random Access Memory).
  • the CPU 53 reads out the program 57 and data 58 stored in the storage device 51 into the memory 52 and executes them.
  • the UI device 54 is connected to input devices such as a keyboard and mouse (not shown) and output devices such as a display, and realizes a GUI (Graphical User Interface).
  • the communication device 55 performs communication processing with external systems (operation and operation management devices 6, 7, 8, 9) via networks 46, 47, 48, 49.
  • operation and management devices 6, 7, 8, and 9 shown in FIG. 1 as related devices also have the same hardware configuration as the transportation resource lending and borrowing management device 1.
  • the function " ⁇ unit" shown in FIG. 1 is realized, for example, by the processor (CPU 53) executing program 57 stored in storage device 51.
  • the resource search unit 205 realizes a resource search function by executing a program using a processor (CPU 953).
  • the constraint condition creating unit 207 realizes a constraint condition creating function by executing a program by the processor (CPU 953).
  • the crew rescheduling unit 209 realizes a crew rescheduling function by executing a program by the processor (CPU 953).
  • the vehicle operation rescheduling unit 2011 realizes a vehicle operation rescheduling function by executing a program using a processor (CPU 953).
  • the timetable replanning unit 2013 realizes a timetable replanning function by executing a program by the processor (CPU 953).
  • the answer creating unit 2015 realizes a answer creating function by executing a program by the processor (CPU 953).
  • FIG. 3 shows a sequence diagram for explaining the flow of communication between the transportation resource rental management device 1 and related devices.
  • the operator renting resources is bus operator A
  • the operator lending resources is bus operator B.
  • Business operator A has a manager 60 who manages bus operations and the operations of drivers and crew members, and this manager 60 performs operation and management tasks by operating a terminal of operation and management device 6.
  • a manager 70 performs operation and management tasks by operating a terminal of operation and management device 7.
  • the manager 60 of bus company A inputs the desired conditions for borrowing resources into the terminal of the operation and management device 6, and creates a request for creating a rental and borrowing plan 61 (step s101).
  • a detailed example of the data configuration of the rental and borrowing plan creation request 61 will be described later with reference to FIG. 4A.
  • this process is started when operation arrangements (changes to timetables) and operational arrangements (changes to operational information for crew and vehicles) within the manager 60's jurisdiction, such as within the company or sales office, have already been implemented at this point, and the manager 60 is in a situation where it is necessary to borrow resources from an entity outside its jurisdiction to operate the bus.
  • the rental and borrowing plan request 61 is created in step s101
  • the operation and management device 6 of bus company A sends the data to the transportation resource rental and borrowing management device 1 (step S103).
  • the transportation resource rental management device 1 When the transportation resource rental management device 1 receives the rental plan creation request 61 from the operation and management device 6 of bus company A, it creates a rental plan 315 based on the information (step s105) and transmits it to the operation and management device 6 of bus company A (step s107). Details of the rental plan 315 will be described later using FIG. 6. Details of the processing of step s107 will be described later using FIG. 7.
  • the bus operator A's operation and management device 6 When the bus operator A's operation and management device 6 receives the rental proposal 315 from the transportation resource rental management device 1, it displays the information on the display screen of the terminal operated by the manager 60 (step s109). Examples of the screens displayed in step s109 will be described later with reference to Figures 15 to 18.
  • the administrator 60 selects the resource he wishes to borrow from the displayed lending proposals 315 (step s111), enters the desired conditions, and creates a formal request 63 (step s113).
  • a formal request 63 is sent via the transportation resource lending management device 1 to the owner of the resource that bus operator A wishes to borrow (bus operator B in this case).
  • the operation and management device 6 of bus operator A sends the data to the transportation resource lending management device 1 (step s115).
  • the transportation resource lending and borrowing management device 1 When the transportation resource lending and borrowing management device 1 receives the formal request 63 from the operation and management device 6 of bus operator A, it transmits the formal request 63 to the operation and management device 7 of bus operator B based on that information (step s117).
  • bus operator B's operation and management device 7 When bus operator B's operation and management device 7 receives the formal request 63 from the transportation resource lending management device 1, it displays the information on the display screen of the terminal operated by the manager 70 (step s119). An example of the screen displayed in step s119 will be described later with reference to FIG. 19.
  • the manager 70 checks the contents of the displayed formal request 63 and inputs a response of acceptance or rejection (step s121). When the operation and management device 7 accepts the input in step s121, it sends the response entered by the manager 70 to the transportation resource lending management device 1 (step s123).
  • the transportation resource rental and borrowing management device 1 When the transportation resource rental and borrowing management device 1 receives the response from the operation and management device 7 of bus operator B, it transmits the response to the operation and management device 6 of bus operator A (step s125).
  • the operation and management device 6 of bus company A When the operation and management device 6 of bus company A receives the response from the transportation resource lending and borrowing management device 1, it displays that information on the display screen of the terminal operated by the manager 60 (step s127).
  • the information displayed here is expected to include responses of acceptance or rejection, as well as requests from bus company B, the resource owner.
  • the manager 60 checks the contents of the display and carries out the subsequent operation and management tasks.
  • Figure 4A shows an example of the data structure of a request for creating a rental proposal 61
  • Figure 4B shows an example of the data structure of a formal request 63.
  • the loan proposal creation request 61 shown in FIG. 4A includes fields for storing the values of the requester 6101, resource type 6103, transportation type 6105, route 6107, start date and time 6109, end date and time 6111, and desired quantity 6113.
  • the requester 6101 is a name or identification code that identifies a business operator or an office within the business operator, and a value indicating the operating entity that wishes to borrow the resources is stored.
  • the resource type 6103 is a name or identification code that specifies the type of resource, and the type of resource that the requester wishes to borrow is stored as a value indicating either a crew member or a vehicle.
  • the transportation type 6105 is a name or identification code that specifies the means of transportation to which the borrowed resource will be assigned, and is stored as a value indicating the means of transportation, such as a route bus, tourist bus, shuttle bus, demand bus, train, or taxi.
  • Route 6107 is a name or identification code that specifies a railroad or bus route, and a value indicating the route that the requester will have the resource rented operate is stored.
  • Start date and time 6109 and end date and time 6111 are both values indicating a date and time, and values indicating the start time and end time of the schedule for which the requester wishes to rent the resource are stored.
  • the desired number 6113 stores a value indicating the number of resources the requester wishes to borrow under the same conditions. If the conditions of the resources to be borrowed are different, a different record is created for each. Alternatively, if it is desired to borrow a crew member and vehicle as a set, one record is created for each of the same conditions but with a different resource type 6103.
  • the formal request 63 shown in FIG. 4B includes fields for storing the values of the requester 6301, resource owner 6303, resource 6305, lending location 6307, return location 6309, lending date and time 6311, and return date and time 6313.
  • the requester 6301 and resource owner 6303 are names or identification codes that identify a business operator or an office within the business operator, and a value indicating the operating entity that wishes to borrow the resource and a value indicating the operating entity that owns the desired resource are stored, respectively.
  • the resource 6305 is a name or identification code for identifying a resource, and a value indicating the resource to be lent or borrowed is stored.
  • the lending location 6307 and the return location 6309 are names or identification codes for identifying a location, and a value indicating the location where the resource is lent from the resource owner to the requester and a value indicating the location where the requester returns the resource to the resource owner are stored, respectively.
  • the lending date and time 6311 and the return date and time 6313 are values indicating a date and time, and a value indicating the date and time where the resource is lent from the resource owner to the requester and a value indicating the date and time where the requester returns the resource to the resource owner are stored, respectively.
  • FIG. 5 shows an example of the data configuration of rental conditions 71 created by the operation and management device 7 of the owner of the rentable resource (here, bus operator B).
  • the rental conditions 71 are data that store the resources that bus operator B can rent out and the conditions that the party renting those resources must comply with, and are created according to the situation on the day.
  • lending conditions 81, 91 may be created in the operation and operations management device 8 of railway operator C or the operation and operations management device 9 of taxi operator D (see FIG. 1).
  • lending conditions may be created in the operation and operations management device 6 of bus operator A.
  • the lending conditions 71, 81, 91 are transmitted from the operation and operations management devices 7, 8, 9 of each entity to the transportation resource lending management device at any timing. They may be transmitted when each lending condition 71, 81, 91 is created or updated, or may be transmitted automatically on a regular basis, or may be transmitted in response to a request from the transportation resource lending management device.
  • the rental conditions 71 shown in FIG. 5 include fields for storing the values of resource type 7100, resource 7101, transportation type 7102, condition item 7103, caution condition 7105, and warning condition 7107.
  • the resource type 7100 is a name or identification code that identifies the type of resource, and is stored as a value indicating whether the resource identified by resource 7101 is a crew member or a vehicle.
  • Resource 7101 is a name or identification code that identifies a resource, and a value that uniquely identifies a resource that can be rented is stored.
  • Transportation type 7102 is a name or identification code that identifies a means of transportation, and a value that indicates the means of transportation that the resource identified by resource 7101 normally drives or operates is stored.
  • the condition item 7103 stores a name or identification code that specifies the condition item that the party lending the resource specified in the resource 7101 is expected to observe.
  • the caution condition 7105 and warning condition 7017 store the value of the condition that must be satisfied for the condition item specified in the condition item 7103.
  • the caution condition 7105 stores a condition that should be satisfied if possible, and the warning condition 7017 stores a condition that must be satisfied with certainty.
  • the caution condition 7105 does not necessarily have to store a value. For example, if “Crew member” is stored in resource type 7100, “Crew member B1" in resource 7101, “Route bus” in transportation type 7102, “Return date and time” in condition item 7103, "Until October 1st 15:00” in caution condition 7105, and "Until October 1st 16:00” in warning condition 7017, the record will indicate that "When lending out crew member B1, who normally drives a route bus, it is desirable for the return date and time to be by October 1st 15:00, but in the worst case scenario, it is acceptable until 16:00.” When defining multiple lending conditions for one resource, create multiple records for each condition item.
  • FIG. 6 shows an example of the data structure of a rental proposal 315 that is created by the transportation resource rental management device 1 and sent to a requester (here, bus operator A) who wishes to rent.
  • a requester here, bus operator A
  • the loan proposal 315 includes fields for storing the values of a loan possibility flag 3151, resources 3153, plan change information 3155, and cost information 3157, or further data such as tables within those fields.
  • the loan possibility flag 3151 is a name or identification code indicating whether a loan can be made, and a value indicating whether a loan can be made or not is stored. The data described below is stored only if a loan can be made.
  • Resource 3153 is a name or identification code that uniquely identifies a resource that can be lent or borrowed.
  • Plan change information 3153 is information about plan changes that take into account the resources to be lent or borrowed, and is composed of timetable 307', crew operation information 309', and vehicle operation information 311'. These are respectively an excerpt of only the information related to the resource identified by resource 3153 from timetable 307, crew operation information 309, and vehicle operation information 311 stored in memory unit 30 of transportation resource lending management device 1.
  • the cost information 3157 is information relating to the labor and expenses incurred by lending and borrowing resources, and is composed of forwarding information 305', suitability 31571, number of operation changes 31573, and borrowing fee 31575.
  • the forwarding information 305' stores information relating to the forwarding required from the time the resource is borrowed to its return.
  • the suitability 3157 is an index calculated by the resource search unit 205, and stores the degree to which the resource is suitable for the route in question as a numerical value.
  • the number of operation changes 31573 stores the number of service operations that have been changed from the plan calculated by the crew operation planning unit 209 or the vehicle operation planning unit 2011.
  • the forwarding information 305', the compatibility 31571, and the number of operation changes 31573 are forwarding information 305 stored in the memory unit 30 of the transportation resource lending management device 1, or are information extracted from the information created by each functional module that is related only to the resource specified by the resource 3153.
  • the borrowing fee 31575 is information such as the fee per unit time multiplied by the time to be borrowed. Details of each data and functional module will be described later.
  • the resource search unit 205 extracts candidate resources and calculates their suitability (s20301).
  • Suitability is an index that indicates the degree to which the loanable resources presented by each resource owner are suitable for the route. From the loanable resources, resources that can be allocated to the route are extracted, and the resource that will be given priority for subsequent processing is determined based on the suitability. Details of the resource search unit 205 and the data that is input and output will be described later.
  • step s20303 the process branches depending on the result of step s20301. If no resources are extracted in step s20301, the response creation unit 2015 creates a response to the requester explaining that the resources cannot be borrowed (step s20319). Here, a value indicating "not borrowable" is stored in the lending/borrowing feasibility flag 3151 of the lending/borrowing proposal 315 described using FIG. 6. If any resources are extracted in step s20301, the process proceeds to step s20305.
  • step s20305 the processes from step s20307 to step s20315 are repeated the number of times equal to the number of candidate resources extracted in s20301 (step s20305).
  • the constraint condition creation unit 207 creates the constraint condition 313 to be used for the subsequent operational arrangement (step s20307).
  • the process of the constraint condition creation unit 207 and the details of the constraint condition 313 will be described later with reference to Figures 9A, 9B, 12A, and 12B.
  • the crew rescheduling unit 209 and the vehicle rescheduling unit 2011 reschedule crew and vehicle operations based on the timetable 307 and the constraints 313 created in step s20307, and create proposed changes to the crew operation information 309 and the vehicle operation information 311 (step s20309).
  • Crew rescheduling and vehicle rescheduling are carried out first according to the type of resource to be borrowed. If both are borrowed, either one may be carried out first.
  • the processing of the crew rescheduling unit 209 and the vehicle rescheduling unit 2011 will be described later with reference to FIG. 13.
  • step s20311 the process branches depending on the result of step s20309. If operational reorganization is implemented in step s20309 and there are proposals for changes to crew operation information 309 and vehicle operation information 311, the process proceeds to step s20313. If operational reorganization is not implemented in step s20309, the process proceeds to step s20319, where the response creation unit 2015 creates a lending/borrowing proposal 315 as a response to the requester explaining that the resources cannot be borrowed (step s20319).
  • the traffic rescheduling unit 2013 implements traffic rescheduling based on the crew operation information 309 and vehicle operation information 311 for which changes were proposed in step s20311, and creates a proposed change to the timetable 307 (step s20313).
  • the traffic rescheduling method and algorithm may be the general one currently used by transportation operators.
  • step s20315 when the timetable 307 is changed in step s20313, the operation time is changed, so the latest crew operation information 309 and vehicle operation information 311 are compared again with the constraints on operations 313 to determine whether the constraints are met (step s20315). If the constraints are not met, the process returns to step s20309 and starts over based on the updated timetable 307. If the constraints are met, the process returns to step s20305 and repeats the process.
  • step s20305 may not be performed if the number of candidate resources is limited to one, or the subsequent processes may be performed by selecting several resources with the highest compatibility values obtained in step 20301, or the subsequent processes may be performed in descending order of compatibility, and the repetition may be terminated when a resource that satisfies the constraints is found in step s20315.
  • the response creation unit 2015 creates a loan proposal 315 as a response to the requester, and the processing of the loan proposal creation unit 203 ends (step s20317).
  • Route characteristics 301 are data that define the conditions of resources that cannot be allocated for each route of the borrower, and define conditions (mandatory exclusion conditions) that directly affect whether or not driving/operating can be allocated, such as the type of driver's license and the type of vehicle, and conditions (optional exclusion conditions) that do not directly affect the allocation of driving/operating, such as driving history, work experience, and health condition, and are used to always exclude resources that satisfy the mandatory exclusion conditions and to preferentially extract resources that satisfy the optional exclusion conditions as much as possible.
  • conditions such as the type of driver's license and the type of vehicle
  • optional exclusion conditions that do not directly affect the allocation of driving/operating
  • Route characteristics 301 include fields for storing the values of operator 30101, route 30103, resource type 30105, condition classification 30107, exclusion condition 30109, date and time restriction 30111, and compatibility coefficient 30113.
  • Operator 30101 is a name or identification code that identifies an operator or an office within an operator, and stores the value of the operator to which the target route belongs.
  • Route 30103 is a name or identification code that identifies a rail or bus route, and stores the value of the route that is the target of each record.
  • the resource type 30105 is a name or identification code that identifies the type of resource, and is stored as a value indicating which type of resource the condition identified by the exclusion condition 30109 relates to, either crew or vehicle.
  • the condition classification 30107 stores a value indicating whether the condition identified by the exclusion condition 30109 is mandatory or optional, either a mandatory exclusion condition or an optional exclusion condition.
  • the exclusion condition 30109 stores the contents of the condition to be excluded when allocating the resource specified by the resource type 30105 to the route specified by the route 30103.
  • the date and time restriction 30111 stores the value of the restricted date and time, etc., when the condition specified by the exclusion condition 30109 is that allocation should be made only on a certain day, day of the week, or time period.
  • the compatibility coefficient 30113 is a value between 0 and 1 that indicates the degree to which the resource candidate being searched for matches the route specified in the route 30103, and the smaller the value stored is, the more of a condition specified in the exclusion condition 30109 that must be excluded. If a required exclusion condition is stored in the condition classification 30107, the compatibility coefficient 30113 for that record stores 0.
  • the resource search unit 205 extracts resources based on the rental proposal creation request 61 received from the operation and management device of the operator wishing to borrow resources (here, the operation and management device 6 of bus company A) and the rental conditions 71, 81, 91 received from the operation and management devices 7, 8, 9 of the owners of the rentable resources (here, the bus company B, the railway company C, and the taxi company D), and prioritizes the resources according to their suitability by calculating the suitability of each of the rentable resource candidates presented by each resource owner based on the above-mentioned route characteristics 301, which indicates the degree to which the candidates suit the route.
  • the specific procedure is as follows: first, from among the loanable resources presented by each resource owner, resources are extracted where the resource type 6103 in the loan proposal creation request 61 matches the resource type 7100 in the loan conditions 71, 81, 91, and the start date and time 6109 and end date and time 6111 in the loan proposal creation request 61 fall within the caution condition 7105 or warning condition 7107 in the condition items 7103 "loan date and time” and "return date and time” in the loan conditions 71, 81, 91.
  • the loanable resources presented by each resource owner are listed by listing the resources stored in the resource 7101 of the loan conditions 71, 81, 91 received from the operation and management devices 7, 8, 9 of each resource owner and deleting duplicates. Also, the start date and time 6109 and the caution condition 7105 or warning condition 7107 of the condition item 7103 "loan date and time" do not necessarily have to match, as long as the start date and time 6109 is the later date and time.
  • the degree of suitability is calculated.
  • the method of calculating the degree of suitability has already been described in the explanation of the configuration example of the line characteristics 301. The larger the value of this degree of suitability, the more suitable the resource is for the line, and therefore it is given priority when processing resource candidates in subsequent processes.
  • the constraint creation unit 207 first creates a schedule start/end constraint 3131 (s2070), and then creates a resource constraint 3132 (s2077).
  • step s2070 The detailed process flow of step s2070 is shown in FIG. 9B.
  • steps s2073 and s2075 are repeatedly executed the number of times corresponding to the number of locations where the driver's duty or the vehicle's operation can start and end (step s2071). The locations where the driver's duty or the vehicle's operation can start and end will be described later with reference to FIG. 10A and FIG. 10B.
  • route information 305 is created (s2073), which stores information about the route from the rental location to the location where the driving (operation) starts, and from the location where the driving (operation) ends to the location where the return is made, with respect to the movement from rental to the start of the driving (operation) and from the end of the driving (operation) to the return.
  • s2073 An example of the data configuration of the roll call inspection master 303, which is the input of step s2073, and the route information 305, which is the output, will be described later using Figures 11A and 11B.
  • step s2073 a schedule start/end constraint 3131 is created (s2075).
  • step s2075 the process returns to step s2071, and the process is repeated as long as the repetition condition is satisfied.
  • the rental location B1 (1001) for the resource owner (here, bus company B) and the duty (operation) start location A1 (1005) for the borrower (here, bus company A) do not necessarily match. This is because in many cases, the rental location B1 is within the jurisdiction of the resource owner (bus company B), and the duty (operation) start location A1 is within the jurisdiction of the borrower (bus company A). The same can be said for the return location B2 (1003) and the duty (operation) end location A2 (1007).
  • the entire process from rental to return is as follows: After rental at rental location B1 (1001), the vehicle travels to duty (operation) start location A1 (1005), from where the driver drives the vehicle or operates it to duty (operation) end location A2 (1007), and then the vehicle is returned to return location B2 (1003). Before and after the driver drives the vehicle or before and after the vehicle is operated, roll calls and inspections are required.
  • the roll call for the crew includes alcohol detection, checking clothing, checking belongings, and checking operational instructions
  • the vehicle inspection includes checking the engine, checking destination signs, cleaning, and checking for lost property.
  • the roll call and inspection may take place at the start or end location of the driving (operation), or at another location. For this reason, from the rental location B1 (1001) to the driving (operation) start location A1 (1005), the vehicle is sent (1021) to the roll call inspection location A1' (1013), the roll call inspection (1023) at the roll call inspection location A1' (1013), and sent (1025) from there to the driving (operation) start location A1 (1005). From the driving (operation) start location A1 (1005) to the driving (operation) end location A2 (1007), the vehicle is sent (1027).
  • the vehicle From the end of the driving (operation) location A2 (1007) to the return location B2 (1003), the vehicle is sent to the inspection and roll call location A2' (1015) (1029), and then the vehicle is inspected by roll call (1031) at the inspection and roll call location A2' (1015), and then sent from there to the return location B2 (1003) (1033), just like when the vehicle was rented out.
  • step s2071 of FIG. 9 may be defined in advance as the locations for start and end of driving (operation) for each route, or all stops may be set as the locations for start and end of driving (operation).
  • the roll call inspection location is likely to be different compared to when the driving (operation) section is from the driving (operation) start location A1 (1005) to the driving (operation) end location A2 (1007), and the time required for the return trip, roll call inspection, and driving (operation) will also be different.
  • bus services are shown as timetable lines (1041a, b, c, d) on a graph called a timetable, which has the arrangement of stops on the target route on the vertical axis 1041 and time on the horizontal axis 1043, and further shows the possible working (operating) range 1045 by filling it in.
  • the stops A1, A2, A3, A4, and A5 on the vertical axis 1041 are the working (operating) start and end locations shown in Fig. 10(a), and the working (operating) start times at each location are shown as 1047a, b, c, d, e, and the working (operating) end times are shown as 1049a, b, c, d, e.
  • timetable lines 1041a, b, c, and d are illustrated from the information of timetable 307. If a bus is operated at each stop between the duty (operation) start time 1047 and the duty (operation) end time 1049, the bus can be operated. For example, at bus stop A1, the timetable line 1041a passes earlier than the duty (operation) start time 1047a, so resources cannot be allocated to 1041a, but the timetable line 1041b passes later than the duty (operation) start time 1047a and earlier than 1049a, so resources can be allocated to timetable 1041b.
  • the area enclosed by the lines connecting the duty (operation) start times 1047a, b, c, d, and e and the duty (operation) end times 1049a, b, c, d, and e at each stop is the possible duty (operation) range 1045.
  • the constraint condition creation unit 207 creates constraint conditions (timetable start/end constraint conditions 3131 described later, which store information on possible locations and times of operation (operation) on the route described in FIG. 10B) for the borrower's target route from the rental conditions 71 received from the resource owner, taking into account the time required for the transfer and roll call inspection described in FIG. 10A (stored in transfer information 305 described later using FIG. 11B), and by comparing the constraint conditions with the route, it becomes possible to extract an assignable timetable line, i.e., a service.
  • constraint conditions timetable start/end constraint conditions 3131 described later, which store information on possible locations and times of operation (operation) on the route described in FIG. 10B
  • the roll call inspection master 303 is a master of the time required for roll calls and inspections performed before and after a crew member's shift and before and after a vehicle is operated, and stores information on the required time, which differs depending on the past performance and skills of the crew member and vehicle, and information on the required time for transportation between the location where the roll call inspection is performed and the start and end locations of the shift (operation) when they are far apart.
  • the roll call inspection master 303 includes fields for storing the values of resource type 30301, route 30303, stop 30305, start end type 30307, roll call inspection point 30309, performance level 30311, roll call inspection time required 22113, and delivery time required 33115.
  • Resource type 30301 is a name or identification code that identifies the type of resource, and is stored as a value indicating whether the target resource in each record is a crew member or a vehicle.
  • Route 30303 is a name or identification code that specifies a railway or bus route, and the value of the target route is stored in each record.
  • Bus stop 30305 is a name or identification code that specifies a location where buses and other vehicles stop to allow passengers to get on and off, and a value indicating a location where a shift (operation) can start or end is stored.
  • Start/end type 30307 is a name or identification code that specifies whether the location stored in bus stop 30305 is the location where a shift (operation) starts or ends, and a value indicating the start or end is stored.
  • the roll call and inspection location 30309 is a name or identification code that identifies the location where roll calls and inspections are conducted before and after the driver's shift or before and after the vehicle is in operation, and a value indicating the location where roll calls and inspections are conducted is stored for the shift (operation) start location or shift (operation) end location identified by the bus stop 30305 and start/end type 30307.
  • the performance level 30311 is a value that defines the performance of the crew or vehicle specified by the resource type 30301, such as work experience and driving experience on the route specified by the route 30303.
  • Crew members and vehicles are each divided into several levels, and are expressed in three stages, for example, a crew member having "work experience,” “substitute experience,” and “no experience.”
  • the time required for roll call inspection and the time required for delivery are defined according to the value of the performance level stored here.
  • the roll call inspection time required 33113 stores the value of the time required for a crew member or vehicle with the performance specified by the performance level 30311 to conduct a roll call or inspection at the location specified by the roll call inspection location 30309.
  • the required time for moving between them is stored as the required time for forwarding 33115. If the bus stop 30305 and the location specified by the roll call inspection location 30309 match, no forwarding work occurs, so the required time can be left blank.
  • the list of stops 30305 for each route 30303 in the roll call inspection master 303 with duplicates removed will match the list of locations where crew members can start and end their shifts or vehicle operations, as shown in step s2071 of FIG. 9B.
  • the roll call inspection time 33113 and the return trip time 33115 are values that vary depending on the individual circumstances of the crew and vehicle, the operation of the day, weather, traffic congestion, and other conditions, but it is possible to treat them as masters and store average values or maximum values, or to set detailed values for each condition.
  • the forwarding information 305 stores the results of calculating the rental location and rental time defined in the rental conditions 71, the means of travel and travel time to the duty (operation) start location defined in the roll call inspection master 303, and the means of travel and travel time from the duty (operation) start and end location defined in the roll call inspection master 303 to the rental location defined in the rental conditions 71.
  • the route information 305 includes fields for storing the values of resource type 3051, departure location 3053, arrival location 3055, transportation means 3057, and travel time 3059.
  • Resource type 30501 is a name or identification code that specifies the type of resource, and is stored as a value indicating whether the resource type targeted by the target record is a crew member or a vehicle.
  • the departure location 3053 and arrival location 3055 are names or identification codes that specify locations, and store values indicating the departure and arrival locations for the out-of-service movement.
  • the means of transportation 3057 is a name or identification code that specifies the means of transportation used for the out-of-service movement, and stores a value indicating, for example, a train, taxi, etc., as the means of transportation from the location specified by the departure location 3053 to the location specified by the arrival location 3055.
  • Travel time 3059 stores the value of the time it takes to travel from the location specified by departure location 3053 to the location specified by arrival location 3055. For example, if “crew member” is stored in resource type 3051, "office X” in departure location 3053, “stop X” in arrival location 3055, "railroad” in transportation means 3057, and "10 minutes” is stored in travel time 3059, the content indicated by that record will be "It takes 30 minutes for the crew member to travel by train from office X to stop X.”
  • the departure location 3053 and arrival location 3055 are obtained from the rental conditions 71 and roll call inspection master 303.
  • the means of transportation 3057 and travel time 3059 may be searched using a general route search app, etc., and are assumed to take into account the current day's conditions such as traffic congestion and congestion. Alternatively, although it is difficult to take into account the current day's conditions, they may be defined in advance as master data.
  • schedule start/end constraints 3131 store information and numerical values related to the possible work (operation) range 1045 described in FIG. 10B.
  • the schedule start/end constraints 3131 include fields for storing the values of the resource 31311, the route 31313, the stop 31315, the start/end type 31317, the condition classification 31318, and the time 31319.
  • Resource 31311 is a name or identification code that identifies a resource, and a value that uniquely identifies a resource that is a candidate for leasing is stored.
  • Route 31313 is a name or identification code that identifies a railway or bus route, and a value of the route to which the resource identified by route 31311 is to be allocated is stored.
  • Stop 31315 is a name or identification code that identifies a location where buses, etc. stop to allow passengers to board and disembark, and a value indicating a location where a shift (operation) can begin or end is stored.
  • the start/end type 31317 is a name or identification code that specifies whether the location stored in the bus stop 31315 is the start location of a shift (operation) or the end location of a shift (operation), and a value indicating the start or end is stored.
  • the condition classification 31318 is a name or identification code that specifies whether the value of the condition referenced when calculating the time 31319 is the value stored in the caution condition 7105 of the rental condition 71, or the value stored in the warning condition 7107.
  • the time 31319 is the earliest time that a trip (operation) can start or the latest time that a trip (operation) should end at the trip (operation) start location or end location specified by the bus stop 31315 and start/end type 31317, and is created and stored based on the rental conditions 71, the inspection call master 303, and the forwarding information 305.
  • Resource constraint conditions 3133 store constraint conditions that define priorities so that resources to be lent or borrowed can be allocated preferentially, after consolidating constraint conditions related to resource operation that are defined in advance according to the rules of each entity for the resource type (crew or vehicle) of the resource that was to be lent or borrowed in the processing flow from step s2071, and constraint conditions that are defined on the day as lending conditions 71 and do not relate to schedule start and end constraint conditions 3131.
  • the resource constraint condition 3133 includes fields for storing the values of the subject 31331, condition item 31333, caution condition 31335, warning condition 31337, and priority order 31339.
  • the subject 31331 is a name or identification code that identifies an operating entity or resource, and stores a value that indicates the business entity to which the resource belongs, or the resource itself, for which the conditions described in the target record should be satisfied.
  • the condition item 31333 stores a name or identification code that identifies an item of the condition that should be satisfied by the target resource or group of resources identified by the subject 31331.
  • Caution conditions 31335 and warning conditions 31337 store values of conditions that should be met for the exam items specified by condition items 31333.
  • Caution conditions 31335 store conditions that should be met as much as possible, while warning conditions 31337 store conditions that should be met with certainty.
  • Caution conditions 31335 do not necessarily need to store values.
  • the priority value 31339 stores the prioritized value of each condition stored in the resource constraint condition 3133. If the value stored in the subject 31331 is the resource that was the subject of lending or borrowing in the processing flow from step s2071, then the record will have the highest priority.
  • the value stored in subject 31331 is the sales office or business to which the resource to be lent or borrowed belongs, in other words, the resource owner, then it takes the next priority.
  • the next priority is when the value stored in subject 31331 is the requester of the borrowing. If the value stored in subject 31331 is an entity not involved in the lending or borrowing, or is common to all companies, then it will have a lower priority.
  • candidates for allocatable service routes are extracted from the schedule start/end constraints 3131 (s20901).
  • the method for extracting the allocatable service routes is as described above with reference to FIG. 10B.
  • flight schedules that satisfy the attention conditions 31335 of the resource constraint conditions 3133 are searched for, and the candidates for flight schedules that can be allocated are narrowed down (s20903).
  • step s20903 it is determined whether there are any candidate flights (hereafter referred to as candidate flights) that can be assigned that were narrowed down in step s20903 (s20905). If there are candidate flights, the process proceeds to step s20913. If there are no candidate flights, the process proceeds to step s20907.
  • candidate flights hereafter referred to as candidate flights
  • step s20907 the processes of steps s20909 and s20911 are repeatedly executed in the order of lowest priority 31339 of resource constraint conditions 3133 (s20907).
  • step s20909 the caution condition 31225 of resource constraint conditions 3133 used to narrow down the candidate flights in step s20903 is switched to a warning condition 31337, and flights that satisfy the resource constraint conditions 3133 are searched for again from among the flights extracted in step s20901, and these flights are set as candidate flights (s20909).
  • step s20911 it is determined whether or not there are any candidate flights found in step s20909 (s20911). If there are candidate flights, the process proceeds to step s20913. If there are no candidate flights, the process returns to s20907 and executes the process again from step s20909 for the condition with the next lowest priority.
  • step s20913 steps s20915 and s20917 are repeated for the number of flights narrowed down as candidate flights in the previous process (s20913).
  • step s20915 operational adjustments are made for flights other than the candidate flights, i.e. flights that can be managed using the company's own resources, and a proposal for changing the operational information (in this example, crew operational information 309) is created (s20915).
  • step s20915 the number of resources whose allocation to service routes has been changed from the original operational information (referred to as the number of operational changes) is counted (s20917).
  • step s20913 the operational reorganization plan with the fewest number of operational changes counted in the processing of step 20917 in each repetition is adopted to create a change proposal for crew operational information 309, and the processing of crew operational reorganization 209 is terminated (s20919).
  • step s20913 the constraint conditions of the resources borrowed from the resource owner are set as the highest priority, while in the process after step s20913, the operation reorganization plan that has the fewest operational changes for the borrower is adopted, thereby creating crew operation information 309 and vehicle operation information 311 that are convenient for both the resource owner and the borrower. Note that if it is not possible to narrow down the candidate flights at all by using the priority order 31339 of the resource constraint conditions 3133, it is not necessarily necessary to use the priority order 31339.
  • FIG. 14 shows an example of a route characteristics setting screen 1500 displayed to the administrator 60 of the operation and management device 6 of bus company A, which is the requester of the resource borrowing.
  • the administrator 60 operates this screen to create and update information to be stored in route characteristics 301 in advance or on the day of the route to which the administrator 60 wishes to allocate borrowed resources.
  • the route characteristic setting screen 1500 is composed of a route storage section 1501, a resource type storage section 1503, a required exclusion condition storage section 1505, and an optional exclusion condition storage section 1507.
  • the required exclusion condition 1505 is composed of an exclusion condition storage section 15051 and a date and time restriction storage section 15053, and a condition can be deleted by pressing the delete row button 1505, or added by pressing the add row button 1507.
  • the optional exclusion conditions are composed of an exclusion condition storage section 15701, a date and time restriction storage section 15073, and a compatibility coefficient storage section 15075, and a condition can be deleted by pressing the delete row button 15077, or added by pressing the add row button 15079.
  • the values entered by the administrator 60 on this screen are reflected in the route characteristics 301.
  • the screen shown in FIG. 14 allows the administrator 60 of the operation and management device 6 of bus company A, which is the requester of the resource borrowing, to flexibly create and update route characteristics 301, thereby enabling detailed settings of the requirements for the target route on which the borrowed resource will be operated and operated, and enabling a search for more optimal resources.
  • FIG. 15 shows an example of a bus schedule diagram display screen 1400 displayed to the administrator 60 of the operation and management device 6 of bus company A, which is the requester of the resource borrowing.
  • FIG. 15 is a screen displayed in step s109 (display of lending/borrowing plan 315) in the flowchart of FIG. 3, and is intended to depict the lines of a timetable so that borrowed resources and resources whose operation has been changed can be easily distinguished, and further depict the working range of crew members or the operating range of vehicles.
  • the manager 60 refers to the display on this screen when selecting the resources to borrow.
  • the bus schedule display screen 1400 shows bus service as schedule lines (1405a, 1405b, 1405c, 1405d, 1405e) on a graph called a schedule, which has the sequence of stops from the start to the end of the target route on the vertical axis 1041 and time on the horizontal axis 1043. It also shows the possible work (operation) range area 1401 that is filled in based on records for which a caution condition is stored in the condition classification 31318 of the schedule start/end constraint condition 3131, and the possible work (operation) range area 1403 that is further filled in based on records for which a warning condition is stored in the condition classification 31318.
  • timetable lines 1405a to 1405e can be easily understood by changing the color or thickness depending on whether they are lines to which borrowed resources have been assigned, or lines to which resources whose operations have been changed have been assigned.
  • the display can be switched by setting tabs 1401 at the top of the screen for each operation reorganization and operation reorganization proposal, and by pressing selection button 1049, it is possible to select the resource to be borrowed, the operation reorganization proposal, or the operation reorganization proposal.
  • the administrator 60 of the operation and management device 6 of bus company A which is the requester of the resource rental, can use this information to narrow down the candidates for the borrowed resource.
  • FIG. 16 shows an example of a map display screen 1600 displayed to the administrator 60 of the operation and management device 6 of bus company A, which is the requester of the resource borrowing.
  • FIG. 16 shows the screen displayed in step s109 (display of rental proposal 315) in the flowchart of FIG. 3, and is intended to show a typical map on which the locations of the rental location, roll call inspection location, bus stops, and return location, as well as the route to travel between them, and travel time and stay time.
  • the administrator 60 refers to the display on this screen when selecting the resources to borrow.
  • the map screen 1600 is a general map with a line drawn around the area that corresponds to the company's jurisdiction (1603), markings at locations that correspond to the company's bus stops and roll call inspection locations (1605a, b, c, d), markings at locations that correspond to other companies' resource lending locations and return locations (1607a, b), lines drawn on roads that correspond to the travel routes for commercial operations (1609), and lines drawn on roads that correspond to the travel routes for out-of-service vehicles (1611a, b, c, d). Information such as the name of the location, travel time, and transportation method can be written near the markings and lines to make it easier to understand.
  • the display can be switched by setting tabs 1601 at the top of the screen for each resource to be borrowed, for each proposed reorganization of operations within the resource, and for each proposed reorganization of operations. Selection buttons may be placed as in FIG. 15.
  • the administrator 60 of the operation and management device 6 of bus company A which is the requester of the resource borrowing, can use this information to narrow down the candidates for the borrowed resource.
  • FIG. 17 shows an example of a cost display screen 1700 displayed to the administrator 60 of the operation and management device 6 of bus company A, which is the requester of the resource borrowing.
  • FIG. 17 shows the screen displayed in step s109 (display of borrowing proposal 315) in the flowchart of FIG. 3, and is intended to be a screen drawn to make it easy to compare the costs involved in borrowing each proposed resource for borrowing.
  • the administrator 60 refers to the display on this screen when selecting the resources to borrow.
  • the cost display screen 1700 plots the time required for forwarding and roll call inspections for both lending and returning in a bar graph along the horizontal axis of a graph 1703 with time on the horizontal axis, and arranges borrowed resources and proposals for operational reorganization and operation reorganization within the resources along the vertical axis as 1705a, b.
  • the display can be switched by setting tabs 1701 for each type of cost at the top of the screen. Selection buttons may be arranged as in FIG. 15.
  • FIG. 18 shows an example of a time zone display screen 1800 displayed to the administrator 60 of the operation and management device 6 of bus company A, which is the requester of the resource borrowing.
  • FIG. 18 shows the screen displayed in step s109 (display of loan proposal 315) in the flowchart of FIG. 3, and is intended to show a screen that plots the time periods available for borrowing and suitability on a schedule.
  • the administrator 60 refers to the display on this screen to select the resources to borrow.
  • the time zone display screen 1800 displays values for resource 1801 and resource owner 1803, and displays a value indicating whether borrowing is possible at each time in time zone 1805.
  • the time zone 1805 displays the time zone during which borrowing is possible at each time using a mark. For example, it is easy to understand if the marks are displayed in descending order of suitability with the route, such as ⁇ , O, ⁇ . Clicking on this mark may result in a selection being made in the same way as the selection button in Figure 15.
  • Figs. 15 to 18 examples of screen displays of borrowed resource proposals are shown in Figs. 15 to 18 above, the information stored in the borrowing proposal 315 may also be displayed using tables or other methods.
  • the screens in Figs. 15 to 18 may also be displayed individually, or multiple screens may be displayed side-by-side or switched between.
  • FIG. 19 shows an example of a work (operation) schedule display screen 1900 displayed to the manager 70 of the operation and management device 7 of the resource owner, bus company B.
  • FIG. 19 is a screen displayed in step s119 (display of formal request 63) in the flowchart of FIG. 3, and is intended to show a screen illustrating the driving and operation schedules for the resource to be borrowed and rented, including both the company's own and other companies'.
  • the manager 70 refers to the display on this screen and selects whether to accept or reject the resource rental request from bus company A, the party requesting the resource rental.
  • the work (operation) schedule display screen 1900 displays values indicating the work (operation) details for each time period in time zones 1901, and allows the user to choose whether to accept or reject the resource lending request by pressing the accept button 1903 or reject button 1905.
  • the work (operation) details for each time period are displayed, for example, in different colors, such as company work (19017), out-of-service (19011a, b), other company work (19015), and breaks (1903a, b).
  • the screen display of the resources to be lent or borrowed does not have to be a graphical display as in Figure 15; information such as the target resource, lending time, and lending destination may be displayed in a table or the like. Also, while it has been explained that the resources to be lent or borrowed and the schedule from lending to returning are uniquely determined, multiple proposals may be presented and the resource owner may select the one they prefer. Also, requests from the resource owner may be added to the response of acceptance or rejection.
  • the subject of rental is described as a crew member, but the subject of rental may be a vehicle, or a set of crew member and vehicle. There may be multiple subjects of rental. Also, in this embodiment, the subject of rental is described as one service to which rental resources are allocated by the rental recipient, but there may be multiple services or multiple routes.
  • information on the borrowing fee 31575 is stored as cost information 3157 in the borrowing plan 315, but rather than simply settling the costs between the operating entities in monetary terms, the settlement may be made so that no monetary transfer occurs by, for example, matching the number of times each resource is borrowed or lent or the duration of the loan.
  • the operation and management systems 6, 7, 8, and 9 of each operator may have a function such as distributing information to passengers.
  • the crew operation reorganization unit 209, vehicle operation reorganization unit 2011, and train operation reorganization unit 2013 of the transportation resource lending and management device 1 do not necessarily have to be provided in the transportation resource lending and management device 1, and the data created by the constraint condition creation unit 207 may be sent to the operation and management systems 6, 7, 8, and 9 of each operator, where operation reorganization and train operation reorganization are performed.
  • transportation resources can be easily lent and borrowed between offices and businesses, and if the number of vehicles and crew members on standby managed by each party can be reduced, vehicle maintenance costs, replacement costs due to equipment aging, labor costs, etc. can be reduced. Furthermore, in the event of an unforeseen event such as an operational disruption, alternative means can be prepared, preventing a decline in service quality.
  • Transportation resource lending and borrowing management device 30: Memory unit, 301: Route characteristics, 303: Roll call inspection master, 305: Delivery information, 307: Timetable, 308: Crew operation information, 311: Vehicle operation information, 313: Constraint conditions, 3131: Timetable start and end constraint conditions, 3133: Resource constraint conditions, 315: Lending and borrowing plan, 201: Transmitting and receiving unit, 203: Lending and borrowing plan creation unit, 205 Resource search unit, 207: constraint condition creation unit, 209: crew rescheduling unit, 2011: vehicle rescheduling unit, 2013: train rescheduling unit, 2015: response creation unit

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • General Physics & Mathematics (AREA)
  • Finance (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Theoretical Computer Science (AREA)
  • Strategic Management (AREA)
  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Human Resources & Organizations (AREA)
  • Tourism & Hospitality (AREA)
  • Primary Health Care (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Development Economics (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

リソースの借用を希望する公共交通運営主体である依頼主の運行運用管理装置から受信した貸借案作成依頼に基づき貸借案を作成する。

Description

交通リソース貸借管理装置、交通リソース貸借管理システム及び交通リソース貸借管理方法
　本発明は、交通リソース貸借管理装置、交通リソース貸借管理システム及び交通リソース貸借管理方法に関する。
　鉄道、路線バス、高速バス、旅客機、旅客船などの公共交通は、予め計画された時刻表に従って運行する。しかし、車両に故障が生じたり、事故などで車両が車庫に戻らなかったり、乗務員が急な体調不良で休んだりすることで、車両や乗務員といった交通リソースが不足する場合がある。また、イベントや混雑により運行本数を増便する場合がある。このような場合には、不足分や増便分のリソースを新たに手配する必要があるが、新たな交通リソースを手配できないと、運行の中止を余儀なくされることもある。
　一方、持続可能なモビリティの実現に向けて近年注目を集めるＭａａＳ（Ｍｏｂｉｌｉｔｙ　ａｓ　ａ　Ｓｅｒｖｉｃｅ）では、全ての交通手段によるモビリティを１つのサービスと捉えてユーザの移動を支援することが期待されており、交通手段や交通リソースが必ずしも予め決められている必要はない。したがってＭａａＳの考え方に則れば、交通リソースを新たに手配する際に、必ずしも路線内や営業所内だけでリソースを再配置する必要はなく、他の路線、他の営業所、他の事業者からリソースを借用しても構わない。交通リソースを、その所有者に関わらずに柔軟に運用できることが求められる。
　複数の公共交通運営主体の間でリソースを貸借する場合、リソース所有主も運行業務を行っており、その運行と運行の隙間時間に貸借することが想定されるため、貸借可能なリソースの候補数が少ない。したがって、リソースの割当のない運行便に対して割当可能なリソースを選択するのではなく、貸借可能なリソースが割当可能な運行便を選択したうえで、残りの運行便への影響が少ないように運用を変更することが有用である。
　特許文献１には、異なる場所に複数の支店を配し各支店がそれぞれ独自に複数台の建設車両を保有・整備・運用する建設車両のレンタル会社において、全てのレンタル品の情報を一元管理し、レンタル品のレンタル場所間の移動スケジュールの作成手段や、レンタル期間の稼働状態の管理手段を有するレンタルシステムの技術が開示されている。
ＷＯ０２／０１１００７号公報（特願２００２－５１５６５５号）
　時刻表に従って運行する公共交通においては、同一路線上で運行されていても運行便によって出発場所や終着場所が異なるが、特許文献１に記載の技術では、貸出場所と異なる場所からリソースを返却することや、出発場所と終着場所の候補が複数存在することが想定されていない。
　また、天候や混雑や事故などにより運行に乱れが生じると、停車・出発時刻が変更されたり、出発、終着、停車、経由の地点そのものが変更されたり、新たな便が追加されたりするため、全てのケースを想定してレンタル品の移動スケジュールを作成できない。
　本発明の目的は、交通リソース貸借管理装置において、事業者間で交通リソースを容易に貸借し合えるようにして路線としての運行を最適に実行可能にすることにある。
　本発明の一態様の交通リソース貸借管理装置は、プロセッサを有し複数の公共交通運営主体の間でリソースを貸借する場合に貸借する前記リソースの候補を探索する交通リソース貸借管理装置であって、前記リソースの借用を希望する前記公共交通運営主体である依頼主の運行運用管理装置から受信した貸借案作成依頼に基づき貸借案を作成する貸借案作成部を有し、前記貸借案作成部は、前記プロセッサにより、貸出可能な前記リソースを所有する前記公共交通運営主体であるリソース所有主の前記運行運用管理装置から受信した貸出条件と前記貸借案作成依頼から貸借対象の候補となる前記リソースを候補リソースとして抽出し、路線特性に基づき前記候補リソースと割当予定路線との適合度を算出するリソース探索部と、前記プロセッサにより、乗務員の乗務又は車両の運行が可能な場所と時間の制約情報を格納するダイヤ開始終了制約条件と、前記ダイヤ開始終了制約条件に関与しない制約条件に優先順位付けを定義したリソース制約条件を作成する制約条件作成部と、前記プロセッサにより、前記依頼主に対する回答として前記貸借案を作成する回答作成部と、を有し、前記制約条件作成部は、前記プロセッサにより、前記リソース所有主から受信した前記貸出条件に格納される貸出場所又は返却場所と、乗務及び運行の開始場所又は終了場所の間の移動手段又は移動時間を格納する回送情報を作成し、前記貸出条件に格納される前記貸出場所と貸出時間及び前記返却場所と返却時間と、前記回送情報に格納される前記貸出場所又は前記返却場所と乗務及び運行の前記開始場所又は前記終了場所の間の前記移動手段又は前記移動時間に基づき、前記乗務又は前記車両の運行が可能な場所と時間の制約情報を格納する前記ダイヤ開始終了制約条件を作成することを特徴とする。
　本発明の一態様によれば、交通リソース貸借管理装置において、事業者間で交通リソースを容易に貸借し合えるようにして路線としての運行を最適に実行可能にすることができる。
交通リソース貸借管理装置１及び関連装置のネットワーク構成例を示す図である。 交通リソース貸借管理装置１及び関連装置のハードウェア構成例を示す図である。 交通リソース貸借管理装置１と関連装置のやり取りの流れを説明するためのシーケンス図である。 貸借案作成依頼６１のデータ構成例を示す図である。 正式依頼６３のデータ構成例を示す図である。 貸出条件７１のデータ構成例を示す図である。 貸借案３１５のデータ構成例を示す図である。 貸借案作成部２０３の処理のフローチャートである。 路線特性３０１のデータ構成例を示す図である。 制約条件作成部２０７の処理のフローチャートである。 制約条件作成部２０７の処理のフローチャートである。 乗務あるいは運行の開始終了が可能な場所の説明するための図である。 乗務あるいは運行の開始終了が可能な場所の説明するための図である。 点呼点検マスタ３０３のデータ構成例を示す図である。 回送情報３０５のデータ構成例を示す図である。 制約条件３１３のデータ構成例を示す図である。 制約条件３１３のデータ構成例を示す図である。 乗務員運用整理部２０９および車両運用整理部２０１１の処理のフローチャートである。 リソース借用依頼主の管理者に表示する路線特性設定画面の例を示す図である。 リソース借用依頼主の管理者に表示する借用リソースのダイヤ図表示画面の例を示す図である。 リソース借用依頼主の管理者に表示する借用リソースの地図表示画面の例を示す図である。 リソース借用依頼主の管理者に表示する借用リソースのコスト表示画面の例を示す図である。 リソース借用依頼主の管理者に表示する借用リソースの時間帯表示画面の例を示す図である。 リソース所有主の管理者に表示する貸借対象リソースの乗務あるいは運行スケジュール表示画面を示す図である。
　以下、図面を用いて実施例を説明する。
　本実施例では、路線バスを運営するバス事業者Ａにおいて、増便したいのに乗務員が足りないことが発覚したときに、貸出可能な乗務員を所有するバス事業者Ｂにとって不利益が発生しない範囲内で、バス事業者Ａがバス事業者Ｂの乗務員を借用できるように、貸借対象リソースのスケジュールを調整する交通リソース貸借管理装置を例に説明する。
　図１には、本実施例の交通リソース貸借管理装置１及び関連する装置のブロック図とネットワーク構成例を示している。
　交通リソース貸借管理装置１は、通信ネットワーク４６を介してバス事業者Ａの運行・運用管理装置６と接続され、通信ネットワーク４７を介してバス事業者Ｂの運行・運用管理装置７と接続され、通信ネットワーク４８を介して鉄道事業者Ｃの運行・運用管理装置８と接続され、通信ネットワーク４９を介してタクシー事業者Ｄの運行・運用管理装置４９と接続される。
　なお、通信ネットワーク４６、４７、４８、４９は、共通の通信ネットワークであってもよいし、それぞれ異なるプロトコルを用いるネットワークであってもよい。また、通信ネットワーク４６、４７、４８、４９は、有線ネットワークまたは無線ネットワークのいずれであってもよい。これらのネットワークを介して、それぞれのシステム、端末間でデータを送受信する。
　バス事業者Ａの運行・運用管理装置６、バス事業者Ｂの運行・運用管理装置７、鉄道事業者Ｃの運行・運用管理装置８、タクシー事業者Ｄの運行・運用管理装置９は、各公共交通事業者がそれぞれ保有し、各交通手段において走行する車両を監視して制御や指示出しを行ったり、車両や乗務員の配置、スケジュール、勤務管理などを行ったりするための装置である。
　バス事業者Ａ、バス事業者Ｂ、鉄道事業者Ｃ、タクシー事業者Ｄは公共交通運営主体の一例であり、その他の例えば路面電車、旅客機、旅客船といった公共交通運営主体であってもよい。また、交通リソース貸借管理装置１に接続する運行・運用管理装置の台数は４台に限らず、それより多くても少なくてもよい。また、運行・運用管理装置は、運行管理に関する機能と車両や乗務員の運用管理に関する機能がそれぞれ別の装置に実装されてもよいし、ひとつの装置に実装されてもよい。ひとつの事業者が、営業所や支社ごとに複数の運行・運用管理装置を保有してもよい。
　各運行・運用管理装置６、７、８、９は、それぞれデータとして、貸借案作成依頼６１、正式依頼６３、貸出条件７１、８１、９１を保有する。これらのデータの詳細は後述する。
　交通リソース貸借管理装置１は、記憶部３０に、データとして、路線特性３０１、点呼点検マスタ３０３、回送情報３０５、時刻表３０７、乗務員運用情報３０９、車両運用情報３１１、制約条件３１３（ダイヤ開始終了制約条件３１３１およびリソース制約条件３１３３で構成）、貸借案３１５を保有する。時刻表３０７は、各運行便における駅や停留所ごとの着発時刻を格納するデータである。
　また、乗務員運用情報３０９、車両運用情報３１１は、それぞれ、各運行便に対する乗務員、車両の割当を格納するデータである。時刻表３０７、乗務員運用情報３０９、車両運用情報３１１は、いずれも一般的な公共交通機関で用いられるデータと同等のものを想定しているが、交通リソース貸借管理装置１においては接続される各運行・運用管理装置６、７、８、９から定期的あるいは変更があれば随時受信するものであり、複数主体のデータが統合して管理される。その他の各データの詳細は後述する。
　また、交通リソース貸借管理装置１は、機能モジュールとして、送受信部２０１、貸借案作成部２０３（リソース探索部２０５、制約条件作成部２０７、乗務員運用整理部２０９、車両運用整理部２０１１、運転整理部２０１３、回答作成部２０１５で構成）を保有する。
　送受信部２０１は、各交通運営主体の運行・運用管理装置６～９との間でデータや処理要求を送信あるいは受信する。各システム間におけるデータや処理要求の送受信のタイミングは、図３を用いて後述するが、各主体の運行・運用管理装置６～９が起点となるＰＵＬＬ型でもよいし、交通リソース貸借管理装置１が起点となるＰＵＳＨ型でもよい。なお、データの受信の際には、受信したデータをチェックし、重複や誤記があれば、クレンジングを行うことが望ましい。また、異なる事業者や路線のデータを取得する場合には、以降の処理でデータのフォーマットや項目の違いを意識する必要のないように、所定のフォーマットにデータを変換する。貸借案作成部２０３および各サブ機能モジュールの詳細は後述する。
　図２に、交通リソース貸借管理装置１のハードウェア構成例を示す。
　交通リソース貸借管理装置１は、記憶装置５１、メモリ５２、マイクロプロセッサ（ＣＰＵ：Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）５３、ユーザインタフェース装置（ＵＩ装置）５４、通信装置５５をバス５６で通信可能に接続したコンピュータ装置（情報処理装置）を用いて実現される。なお、例えば仮想マシンで設計し、クラウドシステムで実現してもよい。
　記憶装置５１は、ＳＳＤ（Ｓｏｌｉｄ　Ｓｔａｔｅ　Ｄｒｉｖｅ）やハードディスクドライブなどの不揮発性記憶装置であり、交通リソース貸借管理装置１が実行する機能モジュール２０１～２０１５（図１参照）を実装するコンピュータプログラム５７のほかに、機能モジュールの実行に必要なデータあるいは機能モジュールによって生成されるデータ３０１～３１５（図１参照）などをデータ５８として保持する。メモリ５２は、ＲＡＭ（Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｍｅｍｏｒｙ）などの揮発性メモリである。
　ＣＰＵ５３は、記憶装置５１に保持されるプログラム５７とデータ５８をメモリ５２に読み出して実行する。ＵＩ装置５４は、図示しないキーボードやマウス等の入力装置やディスプレイ等の出力装置に接続され、ＧＵＩ（Ｇｒａｐｈｉｃａｌ　Ｕｓｅｒ　Ｉｎｔｅｒｆａｃｅ）を実現する。通信装置５５は、ネットワーク４６、４７、４８、４９を介して外部システム（運行・運用管理装置６、７、８、９）との通信処理を行う。
　なお、関連装置として図１に示した運行・運用管理装置６、７、８、９も、交通リソース貸借管理装置１と同様のハードウェア構成を有する。
　また、図１に示す機能である「～部」は、例えば、プロセッサ（ＣＰＵ５３）により記憶装置５１に保持されるプログラム５７を実行することによりその「機能」が実現される。
　例えば、リソース探索部２０５は、プロセッサ（ＣＰＵ９５３）によりプログラムを実行することによりリソース探索機能が実現される。
制約条件作成部２０７は、プロセッサ（ＣＰＵ９５３）によりプログラムを実行することにより制約条件作成機能が実現される。乗務員運用整理部２０９は、プロセッサ（ＣＰＵ９５３）によりプログラムを実行することにより乗務員運用整理機能が実現される。
　車両運用整理部２０１１は、プロセッサ（ＣＰＵ９５３）によりプログラムを実行することにより車両運用整理機能が実現される。
運転整理部２０１３部２０１３は、プロセッサ（ＣＰＵ９５３）によりプログラムを実行することにより運転整理機能が実現される。回答作成部２０１５は、プロセッサ（ＣＰＵ９５３）によりプログラムを実行することにより回答作成機能が実現される。
　図３に、交通リソース貸借管理装置１と関連装置のやり取りの流れを説明するためのシーケンス図を示す。先述の通り、本例ではリソースを借用する事業者がバス事業者Ａ、貸出する事業者がバス事業者Ｂであることを想定している。
　事業者Ａには、バスの運行や乗務員・乗務員の運用を管理する管理者６０が存在し、その管理者６０が運行・運用管理装置６の端末を操作することで運行・運用業務を行うものとする。事業者Ｂでも同様に、管理者７０が運行・運用管理装置７の端末を操作することで、運行・運用業務を行うものとする。
　まず、バス事業者Ａの管理者６０が運行・運用管理装置６の端末にリソース借用の希望条件を入力し、貸借案作成依頼６１を作成する（ステップｓ１０１）。貸借案作成依頼６１のデータ構成例の詳細は、図４Ａを用いて後述する。なお、増便や運行乱れの場合、自社内や営業所内といった管理者６０の管轄内の運転整理（時刻表の変更）、運用整理（乗務員や車両の運用情報の変更）はこの時点で実施済みであり、管轄外の主体からリソースを借用しなければ運行ができない状況に陥った場合にこの処理を開始する。バス事業者Ａの運行・運用管理装置６は、ステップｓ１０１にて貸借案依頼６１が作成されると、そのデータを交通リソース貸借管理装置１に送信する（ステップＳ１０３）。
　交通リソース貸借管理装置１は、バス事業者Ａの運行・運用管理装置６から貸借案作成依頼６１を受信すると、その情報に基づき貸借案３１５を作成し（ステップｓ１０５）、バス事業者Ａの運行・運用管理装置６に送信する（ステップｓ１０７）。貸借案３１５の詳細は図６を用いて後述する。また、ステップｓ１０７の処理の詳細は、図７を用いて後述する。
　バス事業者Ａの運行・運用管理装置６は、交通リソース貸借管理装置１から貸借案３１５を受信すると、その情報を管理者６０が操作する端末の表示画面に表示する（ステップｓ１０９）。ステップｓ１０９にて表示される画面の例は、図１５から図１８を用いて後述する。
　管理者６０は、表示された貸借案３１５の中から、借用を希望するリソースを選択し（ステップｓ１１１）、希望条件を入力して正式依頼６３を作成する（ステップｓ１１３）。正式依頼６３のデータ構成例の詳細は、図４Ｂを用いて後述する。正式依頼６３は、交通リソース貸借管理装置１を経由して、バス事業者Ａが借用を希望するリソースの所有主（ここではバス事業者Ｂ）まで送信されるものである。バス事業者Ａの運行・運用管理装置６は、ステップｓ１１３にて正式依頼６３が作成されると、そのデータを交通リソース貸借管理装置１に送信する（ステップｓ１１５）。
　交通リソース貸借管理装置１は、バス事業者Ａの運行・運用管理装置６から正式依頼６３を受信すると、その情報に基づき、バス事業者Ｂの運行・運用管理装置７に正式依頼６３を送信する（ステップｓ１１７）。
　バス事業者Ｂの運行・運用管理装置７は、交通リソース貸借管理装置１から正式依頼６３を受信すると、その情報を管理者７０が操作する端末の表示画面に表示する（ステップｓ１１９）。ステップｓ１１９にて表示される画面の例は、図１９を用いて後述する。管理者７０は、表示された正式依頼６３の内容を確認し、承諾あるいは拒否の回答を入力する（ステップｓ１２１）。運行・運用管理装置７は、ステップｓ１２１の入力を受け付けると、管理者７０が入力した回答を交通リソース貸借管理装置１に送信する（ステップｓ１２３）。
　交通リソース貸借管理装置１は、バス事業者Ｂの運行・運用管理装置７から回答を受信すると、バス事業者Ａの運行・運用管理装置６に回答を送信する（ステップｓ１２５）。
　バス事業者Ａの運行・運用管理装置６は、交通リソース貸借管理装置１から回答を受信すると、その情報を管理者６０が操作する端末の表示画面に表示する（ステップｓ１２７）。ここで表示される情報は、承諾あるいは拒否の回答およびリソース所有主であるバス事業者Ｂからの要求などを想定している。管理者６０は、表示の内容を確認し、その後の運用・運行業務を遂行する。
　リソースの借用を希望する運営主体（ここではバス事業者Ａ）の運行・運用管理装置６で作成されるデータの詳細を説明する。図４Ａに貸借案作成依頼６１のデータ構成例を、図４Ｂに正式依頼６３のデータ構成例を示す。
　図４Ａに示す貸借案作成依頼６１は、依頼主６１０１、リソース種別６１０３、交通種別６１０５、路線６１０７、開始日時６１０９、終了日時６１１１、希望数６１１３の各値を格納するフィールドを含む。依頼主６１０１は、事業者あるいは事業者内の営業所を特定する名称あるいは識別コードであり、リソースの借用を希望する運営主体を示す値が格納される。
　リソース種別６１０３は、リソースの種別を特定する名称あるいは識別コードであり、依頼主が借用を希望するリソースの種別を、乗務員あるいは車両のいずれかを示す値として格納される。交通種別６１０５は、交通手段を特定する名称あるいは識別コードであり、借用したリソースを割当する交通手段を、路線バス、観光バス、送迎バス、デマンドバス、鉄道、タクシー、といった交通手段を示す値として格納される。
　路線６１０７は、鉄道やバスにおける路線を特定する名称あるいは識別コードであり、依頼主が借用するリソースに運行させる経路を示す値が格納される。開始日時６１０９、終了日時６１１１は、ともに、日および時刻を示す値であり、依頼主がリソースの借用を希望する日程の開始時刻と終了時刻を示す値がそれぞれ格納される。
　希望数６１１３は、同じ条件下で依頼主が借用を希望するリソースの数を示す値が格納される。借用を希望するリソースの条件が異なる場合は、それぞれ異なるレコードを作成する。あるいは乗務員と車両をセットで借用を希望する場合は、同じ条件でリソース種別６１０３のみ異なるレコードをそれぞれ１レコードずつ作成する。
　例えば、依頼主６１０１に「バス事業者Ａ」、リソース種別６１０３に「乗務員」、交通種別６１０５に「路線バス」、路線６００７に「路線１」、開始日時６１０９に「１０月１日１１時００分」、終了日時６１１１に「１０月１日１３時００分」、希望数６１１３に「１」が格納される場合、そのレコードの示す内容は「バス事業者Ａの借用を希望するリソースは、路線バスの路線１に乗務する乗務員を、１０月１日１１時００分から１０月１日１３時００分の間に１台」となる。
　図４Ｂに示す正式依頼６３は、依頼主６３０１、リソース所有主６３０３、リソース６３０５、貸出場所６３０７、返却場所６３０９、貸出日時６３１１、返却日時６３１３の各値を格納するフィールドを含む。依頼主６３０１、リソース所有主６３０３は、事業者あるいは事業者内の営業所を特定する名称あるいは識別コードであり、リソースの借用を希望する運営主体を示す値と、その希望されるリソースを所有する運営主体を示す値が、それぞれ格納される。
　リソース６３０５は、リソースを特定する名称あるいは識別コードであり、貸借の対象となるリソースを示す値が格納される。貸出場所６３０７、返却場所６３０９は、場所を特定する名称あるいは識別コードであり、リソース所有主から依頼主にリソースの貸出が行われる場所を示す値と、依頼主からリソース所有主に返却が行われる場所を示す値が、それぞれ格納される。貸出日時６３１１、返却日時６３１３は、日および時刻を示す値であり、リソース所有主から依頼主にリソースの貸出が行われる日時を示す値と、依頼主からリソース所有主に返却が行われる日時を示す値が、それぞれ格納される。　
例えば、依頼主６３０１に「バス事業者Ａ」、リソース所有主６３０３に「バス事業者Ｂ」、リソース６３０５に「乗務員Ｂ１」、貸出場所６３０７に「営業所Ｂ１」、返却場所６３０９に「営業所Ｂ２」、貸出日時６３１１に「１０月１日１０時００分」、返却日時６３１３に「１０月１日１４時００」が格納される場合、そのレコードの示す内容は「バス事業者Ａは、バス事業者Ｂが所有する乗務員Ｂ１を、１０月１日１０時００分に営業所Ｂ１から貸出してもらい、１０月１日１４時００分に営業所Ｂ２に返却する」となる。
　図５に、貸出可能なリソースの所有主（ここではバス事業者Ｂ）の運行・運用管理装置７で作成される貸出条件７１のデータ構成例を示す。
　貸出条件７１は、バス事業者Ｂにとって貸出可能なリソースと、そのリソースを貸出する相手に順守してほしい条件が格納されるデータであり、当日の状況に応じて作成される。
　なお、貸出可能なリソースがあれば、鉄道事業者Ｃの運行・運用管理装置８やタクシー事業者Ｄの運行・運用管理装置９（図１参照）にて同様に貸出条件８１、９１が作成されてもよく、また、図１に記載は無いが、バス事業者Ａに貸出可能なリソースがあれば、バス事業者Ａの運行・運用管理装置６にて同様に貸出条件が作成されてもよい。貸出条件７１、８１、９１は、各主体の運行・運用管理装置７、８、９から任意のタイミングで交通リソース貸借管理装置に送信される。各貸出条件７１、８１、９１が作成・更新されるタイミングで送信されてもよいし、定期的に自動送信されてもよいし、交通リソース貸借管理装置の要求に応じて送信されてもよい。
　図５に示す貸出条件７１は、リソース種別７１００、リソース７１０１、交通種別７１０２、条件項目７１０３、注意条件７１０５、警告条件７１０７の各値を格納するフィールドを含む。リソース種別７１００は、リソースの種別を特定する名称あるいは識別コードであり、リソース７１０１で特定されるリソースが、乗務員あるいは車両のいずれかであるかを示す値として格納される。
　リソース７１０１は、リソースを特定する名称あるいは識別コードであり、貸出可能なリソースを一意に特定する値が格納される。交通種別７１０２は、交通手段を特定する名称あるいは識別コードであり、リソース７１０１で特定されるリソースが通常時に乗務あるいは運行している交通手段を示す値が格納される。
　条件項目７１０３は、リソース７１０１で特定されるリソースを貸出する相手に順守してほしい条件の項目を特定する名称あるいは識別コードを格納する。注意条件７１０５、警告条件７０１７は、条件項目７１０３で特定される条件の項目に関して満たすべき条件の値が格納される。注意条件７１０５にはなるべく満たすべき条件を、警告条件７０１７には確実に満たすべき条件が格納される。
　注意条件７１０５は必ずしも値が格納されなくてもよい。例えば、リソース種別７１００に「乗務員」、リソース７１０１に「乗務員Ｂ１」、交通種別７１０２に「路線バス」、条件項目７１０３に「返却日時」、注意条件７１０５に「１０月１日１５時まで」、警告条件７０１７に「１０月１日１６時まで」が格納される場合、そのレコードの示す内容は「普段路線バスを乗務する乗務員Ｂ１を貸出する場合、返却日時が１０月１日１５時までであることが望ましいが、最悪の場合１６時まで許容される」となる。ひとつのリソースに対して複数の貸出条件を定義する場合には、条件の項目ごとに複数のレコードに分けて作成する。
　図６に、交通リソース貸借管理装置１が作成し、借用を希望する依頼主（ここではバス事業者Ａ）に送信する貸借案３１５のデータ構成例を示す。
　貸借案３１５は、貸借可否フラグ３１５１、リソース３１５３、計画変更情報３１５５、コスト情報３１５７の各値あるいはその中に更にテーブル等のデータを格納する各フィールドを含む。貸借可否フラグ３１５１は、貸借の可否を表す名称あるいは識別コードであり、貸借可能あるいは貸借不可能を示す値が格納される。貸借可能である場合のみ、以降で説明するデータが格納される。
　リソース３１５３は、貸借可能なリソースを一意に特定する名称あるいは識別コードである。計画変更情報３１５３は、貸借するリソースを考慮した計画変更に関する情報であり、時刻表３０７'、乗務員運用情報３０９'、車両運用情報３１１'から構成される。これらはそれぞれ、交通リソース貸借管理装置１の記憶部３０に格納される時刻表３０７、乗務員運用情報３０９、車両運用情報３１１から、リソース３１５３にて特定されるリソースに関する情報のみ抜粋したものである。
　コスト情報３１５７は、リソースの貸借によって発生する労力や費用のコストに関する情報であり、回送情報３０５'、適合度３１５７１、運用変更数３１５７３、借用料金３１５７５から構成される。回送情報３０５'はリソースの借用から返却までにかかる回送に関する情報が格納される。適合度３１５７は、リソース探索部２０５が算出する指標であり、リソースが当該路線に適合する度合いが数値にて格納される。運用変更数３１５７３は、乗務員運用整理部２０９あるいは車両運用整理部２０１１が算出する計画から変更された運行便の数が格納される。
　回送情報３０５'、適合度３１５７１、運用変更数３１５７３は、交通リソース貸借管理装置１の記憶部３０に格納される回送情報３０５であったり、各機能モジュールが作成する情報から、リソース３１５３にて特定されるリソースに関する情報のみ抜粋したものである。借用料金３１５７５は、例えば単位時間あたりの料金に借用する時間を掛けた料金といった情報である。各データや機能モジュールの詳細は後述する。
　ここからは、図１に記載の貸借案作成部２０３について、処理のフローチャートを図７を用いて説明する。
　まず、リソース探索部２０５は候補リソースを抽出し、適合度を算出する（ｓ２０３０１）。適合度とは、各リソース所有主が提示する貸出可能なリソースが当該路線に適合する度合いを表す指標である。貸出可能なリソースの中から、当該路線に割当できるリソースを抽出し、その後の処理を優先的に行うリソースを適合度によって決める。リソース探索部２０５および入出力となるデータの詳細は、後述する。
　ステップｓ２０３０３では、ステップｓ２０３０１の結果に応じて処理を分岐する。ステップｓ２０３０１で抽出されたリソースが無ければ、回答作成部２０１５は、依頼主に対してリソースの借用は不可能であることを説明する回答を作成する（ステップｓ２０３１９）。ここでは、図６を用いて説明した貸借案３１５の貸借可否フラグ３１５１に「貸借不可能」を示す値を格納する。ステップｓ２０３０１で抽出されたリソースがあれば、ステップｓ２０３０５に進む。
　ステップｓ２０３０５では、ステップｓ２０３０７からステップｓ２０３１５の処理を、ｓ２０３０１にて抽出された候補リソースの数だけ繰り返し実行する（ステップｓ２０３０５）。
　繰り返し処理として、まず、制約条件作成部２０７が、その後の運用整理に用いる制約条件３１３を作成する（ステップｓ２０３０７）。制約条件作成部２０７の処理、および制約条件３１３の詳細は、図９Ａ、図９Ｂ、図１２Ａ、図１２Ｂを用いて後述する。
　次に、乗務員運用整理部２０９および車両運用整理部２０１１が、時刻表３０７とステップｓ２０３０７で作成した制約条件３１３に基づき、乗務員および車両の運用整理を実施し、乗務員運用情報３０９と車両運用情報３１１の変更案を作成する（ステップｓ２０３０９）。乗務員の運用整理と車両の運用整理は、借用するリソースの種別に該当する方を先に実施する。両方借りる場合は、どちらから実施してもよい。乗務員運用整理部２０９および車両運用整理部２０１１の処理は図１３を用いて後述する。
　ステップｓ２０３１１では、ステップｓ２０３０９の結果に応じて処理を分岐する。ステップｓ２０３０９で運用整理が実施され、乗務員運用情報３０９および車両運用情報３１１の変更案があれば、ステップｓ２０３１３に進む。ステップｓ２０３０９で運用整理が実施されなければ、ステップｓ２０３１９に進み、依頼主に対してリソースの借用は不可能であることを説明する回答として回答作成部２０１５が貸借案３１５を作成する（ステップｓ２０３１９）。
　ステップｓ２０３１３では、運転整理部２０１３が、ステップｓ２０３１１で変更案が作成された乗務員運用情報３０９および車両運用情報３１１に基づき運転整理を実施し、時刻表３０７の変更案を作成する（ステップｓ２０３１３）。運転整理の手法やアルゴリズムは、現行の交通事業者が実施する一般的なものでよい。
　次に、ステップｓ２０３１３にて時刻表３０７が変更されると、運行の時刻が変更されるため、改めて最新の乗務員運用情報３０９および車両運用情報３１１を運用に関する制約条件３１３と比較し、制約を満たすか否かを判定する（ステップｓ２０３１５）。制約を満たさなければ、更新された時刻表３０７に基づき、ステップｓ２０３０９に戻りやり直す。制約を満たしていれば、ステップｓ２０３０５に戻り、繰り返し処理を実行する。
　なお、ステップｓ２０３０５の繰り返しは、候補リソースをひとつに限定すればそもそも実施しなくてもよいし、ステップ２０３０１で求めた適合度の値が大きいリソースをいくつか抜粋して以降の処理を実施してもよいし、適合度が大きい順に以降の処理を実施したうえでステップｓ２０３１５にて制約を満たすリソースが見つかったタイミングで繰り返しから抜けてもよい。
　最後に、回答作成部２０１５が、依頼主への回答として貸借案３１５を作成して、貸借案作成部２０３の処理は終了となる（ステップｓ２０３１７）。
　ここからは、貸借案作成部２０３に関わる処理およびデータの詳細を説明する。
　まず、図８を用いて、リソース探索部２０５の入力となる路線特性３０１のデータ構成例を説明する。路線特性３０１とは、借用の依頼主における路線ごとに割当不可能なリソースの条件を定めるデータであり、例えば乗務員の免許の種類、車両の車種など、乗務・運行の割当可否に直接関与する条件（必須除外条件）と、走行実績、勤労経験、健康状態など、乗務・運行の割当に直接的には関与しない条件（任意除外条件）とを定義し、必須除外条件を満たすリソースを必ず除外し、かつなるべく任意除外条件を満たすリソースを優先的に抽出するために活用する。
　路線特性３０１は、運営主体３０１０１、路線３０１０３、リソース種別３０１０５、条件分類３０１０７、除外条件３０１０９、日時限定３０１１１、適合係数３０１１３の各値を格納するフィールドを含む。運営主体３０１０１は、事業者あるいは事業者内の営業所を特定する名称あるいは識別コードであり、対象路線の所属する運営主体の値が格納される。路線３０１０３は、鉄道やバスにおける路線を特定する名称あるいは識別コードであり、各レコードの対象となる路線の値が格納される。
　リソース種別３０１０５は、リソースの種別を特定する名称あるいは識別コードであり、除外条件３０１０９で特定される条件がどのリソースの種別に関する条件なのか、乗務員あるいは車両のいずれかを示す値として格納される。条件分類３０１０７は、除外条件３０１０９で特定される条件が必須であるか任意であるかを、必須除外条件あるいは任意除外条件のいずれかを示す値として格納される。
　除外条件３０１０９は、路線３０１０３で特定される路線にリソース種別３０１０５で特定されるリソースを割当する際に除外すべき条件の内容が格納される。日時限定３０１１１は、除外条件３０１０９で特定される条件がある特定の日、曜日、時間帯においてのみ割当すべものである場合に、その限定される日時等の値が格納される。
　適合係数３０１１３は、探索の対象となるリソースの候補が、路線３０１０３で特定される路線に適合する度合いを０以上１以下の数値で表す値であり、除外条件３０１０９で特定される条件が必ず排除したい条件であるほど、小さい値を格納する。条件分類３０１０７に必須除外条件が格納されている場合は、そのレコードにおける適合係数３０１１３は０を格納する。
　ひとつの路線３０１０３の値に対して複数の除外条件３０１０９が定義され、複数のレコードが存在する場合には、それぞれの除外条件３０１０９との比較を行い、該当する除外条件３０１０９の適合係数同士を掛け合わせることで、適合度を算出する。適合度が１であれば、該当する除外すべき条件はなく、適合度が０であれば対象のリソースは割当不可能であると言える。
　例えば、運営主体３０１０１に「バス事業者Ａ」、路線３０１０３に「路線１」、リソース種別３０１０５に「乗務員」、条件分類３０１０７「任意除外条件」、除外条件３０１０９に「通常の業務内容が路線バス乗務ではない」、日時限定３０１１１「なし」、適合係数「０．８」が格納される場合、そのレコードの示す内容は「バス事業者Ａの路線１において、乗務員の通常の業務内容が路線バス乗務ではない場合には、適合係数は０．８」となる。
　また、追加のレコードとして、運営主体３０１０１に「バス事業者Ａ」、路線３０１０３に「路線１」、リソース種別３０１０５に「乗務員」、条件分類３０１０７「任意除外条件」、除外条件３０１０９に「当該路線での勤務経験がない」、日時限定３０１１１「なし」、適合係数「０．９」が格納され、前述のレコードと両方の条件を満たすリソースが存在した場合、そのリソースの当該路線への適合度は、適合係数「０．８」と「０．９」を掛け合わせて「０．７２」となる。いずれのレコードの条件も満たさない場合には、そのリソースの当該路線への適合度は「１」となり、除外する理由は無いと言える。
　リソース探索部２０５は、リソースの借用を希望する運営主体の運行・運用管理装置（ここではバス事業者Ａの運行・運用管理装置６）から受信した貸借案作成依頼６１と、貸出可能なリソースの所有主（ここではバス事業者Ｂ、鉄道事業者Ｃ、タクシー事業者Ｄ）の運行・運用管理装置７、８、９から受信した貸出条件７１、８１、９１に基づきリソースを抽出し、上述の路線特性３０１に基づき各リソース所有主が提示する貸出可能なリソースの候補が当該路線に適合する度合いを表す適合度をそれぞれ算出することで、適合度によるリソースの優先度づけを行う。
　具体的な手順としては、まず、各リソース所有主が提示する貸出可能なリソースの中から、貸借案作成依頼６１のリソース種別６１０３と貸出条件７１、８１、９１のリソース種別７１００が一致し、貸借案作成依頼６１の開始日時６１０９と終了日時６１１１が貸出条件７１、８１、９１の条件項目７１０３「貸出日時」および「返却日時」の注意条件７１０５あるいは警告条件７１０７の条件内に収まっているリソースを抽出する。
　なお、各リソース所有主が提示する貸出可能なリソースは、各リソース所有主の運行・運用管理装置７，８，９から受信した貸出条件７１、８１、９１のリソース７１０１に格納されたリソースを一覧にして重複を削除することで、一覧化される。また、開始日時６１０９と条件項目７１０３「貸出日時」の注意条件７１０５あるいは警告条件７１０７は必ずしも一致しなくても良く、開始日時６１０９の方が遅い日時であればよい。
　なぜなら、リソース所有主にとっての貸出の時刻と、借用の依頼主にとっての運行あるいは乗務開始の時刻は必ずしも一致せず、貸出の後に運行あるいは乗務開始、という順番で実施されるためである。終了日時６１１１と条件項目７１０３「返却日時」注意条件７１０５あるいは警告条件７１０７についても同様のことが言え、終了・返却の場合には終了日時６１０９の方が早い日時であればよい。
　次に、抽出されたリソースそれぞれにおいて、該当する貸出条件７１、８１、９１のリソース種別７１００と路線特性３０１のリソース種別３０１０５が一致し、路線特性３０１の運営主体３０１０１と路線３０１０３がそれぞれ貸借案作成依頼６１の依頼主６１０１、リソース種別６１０３とが一致する場合に、適合度を計算する。適合度の計算方法は、路線特性３０１の構成例の説明箇所に記載済みである。この適合度の値が大きいほどリソースが当該路線に適合していると言えるため、以降の処理でリソース候補に関する処理を行う際に優先される。
　次に、図９Ａ、図９Ｂを用いて、制約条件作成部２０７の処理フローを説明する。
　図９Ａに示す通り、制約条件作成部２０７は、まずダイヤ開始終了制約条件３１３１を作成し（ｓ２０７０）、次にリソース制約条件３１３２を作成する（ｓ２０７７）。
　ステップｓ２０７０の詳細の処理フローが、図９Ｂである。ステップｓ２０７０では、ステップｓ２０７３、ｓ２０７５を乗務員の乗務あるいは車両の運行の開始・終了が可能な場所の数だけ繰り返し実行する（ステップｓ２０７１）。乗務あるいは運行の開始・終了が可能な場所について、図１０Ａ、図１０Ｂを用いて後述する。
　ステップｓ２０７１の繰り返しのループ内では、まず、貸出から乗務（運行）開始まで、乗務（運行）終了から返却までの移動に関して、貸出場所から乗務（運行）開始場所まで、および乗務（運行）終了場所から返却場所までの回送に関する情報が格納される回送情報３０５を作成する（ｓ２０７３）。ステップｓ２０７３の入力となる点呼点検マスタ３０３、および出力となる回送情報３０５のデータ構成例は、図１１Ａ、図１１Ｂを用いて後述する。
　次に、ステップｓ２０７３に続く処理として、ダイヤ開始終了制約条件３１３１を作成する（ｓ２０７５）。ステップｓ２０７５が終了すると、ステップｓ２０７１に戻り、繰り返しの条件を満たすうちは処理を繰り返す。
　ここからは、制約条件作成部２０７に関わる処理およびデータの詳細を説明する。
　ステップｓ２０７１に記載の、乗務員の乗務あるいは車両の運行の開始終了が可能な場所について、図１０Ａ、図１０Ｂを用いて説明する。図１０Ａに示す通り、リソース所有主（ここではバス事業者Ｂとする）にとっての貸出場所Ｂ１（１００１）、借用の依頼主（ここではバス事業者Ａとする）にとっての乗務（運行）開始場所Ａ１（１００５）は必ずしも一致しない。なぜなら、多くの場合、貸出場所Ｂ１はリソース所有主（バス事業者Ｂ）の管轄内で合って、乗務（運行）開始場所Ａ１は借用依頼主（バス事業者Ａ）の管轄内であるためである。返却場所Ｂ２（１００３）と乗務（運行）終了場所Ａ２（１００７）についても同様のことがいえる。
　貸出から返却までの一連の流れは、貸出場所Ｂ１（１００１）で貸出ののち乗務（運行）開始場所Ａ１（１００５）へ行き、そこから乗務（運行）終了場所Ａ２（１００７）まで乗務員が乗務、あるいは車両を運行し、その後に返却場所Ｂ２（１００３）へ行って返却する、となる。乗務員の乗務前後、あるいは車両の運行前後には、点呼・点検の業務が必要である。
　乗務員の点呼とは、アルコール検知、服装確認、携行品確認、運行上の指示確認などであり、車両の点検とは、エンジンの確認、行先表示の確認、清掃、遺失物確認などである。点呼や点検は、乗務（運行）開始場所や終了場所で行われることもあるし、別の場所で行われることもある。このことから、貸出場所Ｂ１（１００１）から乗務（運行）開始場所Ａ１（１００５）に至るまでに、点呼点検場所Ａ１'（１０１３）までの回送（１０２１）、点呼点検場所Ａ１'（１０１３）での点呼点検（１０２３）、そこから乗務（運行）開始場所Ａ１（１００５）までの回送（１０２５）を実行する。乗務（運行）開始場所Ａ１（１００５）から乗務（運行）終了場所Ａ２（１００７）に至るまでには、乗務（運行）（１０２７）を実行する。
　乗務（運行）終了場所Ａ２（１００７）から返却場所Ｂ２（１００３）に至るまでには、貸出時と同様に、点検点呼場所Ａ２'（１０１５）までの回送（１０２９）、点呼点検場所Ａ２'（１０１５）での点呼点検（１０３１）、そこから返却場所Ｂ２（１００３）までの回送（１０３３）を実行する。
　なお、乗務（運行）開始・終了場所は、それぞれ路線ごとにひとつとは限らない。特に増便を行うような場合には、路線の始発から終着まで運行するだけでなく、必要な区間のみを運行することも考えられる。図９のステップｓ２０７１で示した乗務員の乗務あるいは車両の運行の開始・終了が可能な場所は、路線ごとに事前に乗務（運行）開始・終了場所を定義してもよいし、全ての停留所を乗務（運行）開始・終了場所として設定してもよい。
　なお、乗務（運行）開始場所Ａ３（１００９）から乗務（運行）終了場所Ａ４（１０１１）が乗務（運行）区間である場合には、前記の乗務（運行）開始場所Ａ１（１００５）から乗務（運行）終了場所Ａ２（１００７）が乗務（運行）区間である場合と比べて、点呼点検場所も異なる可能性が高く、回送、点呼点検、乗務（運行）にかかる時間も異なってくる。
　図１０Ｂは、縦軸１０４１に対象路線における停留所の並び、横軸１０４３に時間をとったダイヤ図と呼ばれるグラフ上にバスの運行便をダイヤスジ（１０４１ａ、ｂ、ｃ、ｄ）として表記したうえで、更に乗務（運行）可能範囲１０４５を塗りつぶしで表現したものである。縦軸１０４１に存在するＡ１、Ａ２、Ａ３、Ａ４、Ａ５の停留所が図１０（ａ）で示した乗務（運行）開始・終了場所であり、それぞれの場所における乗務（運行）開始時刻が１０４７ａ、ｂ、ｃ、ｄ、ｅ、乗務（運行）終了時刻が１０４９ａ、ｂ、ｃ、ｄ、ｅにて示される。
　なお、ダイヤスジ１０４１ａ、ｂ、ｃ、ｄはダイヤ３０７の情報から図示される。各停留所において、乗務（運行）開始時刻１０４７と乗務（運行）終了時刻１０４９の間の時間にバスが運行される場合に、そのバスに乗務（運行）することができる。例えば、停留所Ａ１において、ダイヤスジ１０４１ａの通過時刻は乗務（運行）開始時刻１０４７ａよりも早い時刻なので、１０４１ａにリソースを割当できないが、ダイヤスジ１０４１ｂの通過時刻は乗務（運行）開始時刻１０４７ａよりも遅く１０４９ａより早いため、ダイヤ１０４１ｂにはリソースを割当できることがわかる。各停留所の乗務（運行）開始時刻１０４７ａ、ｂ、ｃ、ｄ、ｅと乗務（運行）終了時刻１０４９ａ、ｂ、ｃ、ｄ、ｅの線で結んで囲われた範囲が、乗務（運行）可能範囲１０４５となる。
　制約条件作成部２０７は、リソース所有主から受信した貸出条件７１から、図１０Ａで説明した回送や点呼点検にかかる時間（図１１Ｂを用いて後述する回送情報３０５に格納される）を考慮して、借用依頼主の対象路線における制約条件（後述するダイヤ開始終了制約条件３１３１であり、図１０Ｂで説明した路線上の乗務（運行）可能場所や時刻の情報を格納）を作成し、その制約条件とダイヤを比較することで、割当可能なダイヤスジ、つまり運行便を抽出することが可能になる。
　ここからは、図１１Ａ、図１１Ｂを用いて、ステップｓ２０７３の入力となる点呼点検マスタ３０３、および出力となる回送情報３０５のデータ構成例を説明する。
　まず、図１１Ａを用いて、ステップｓ２０７３の入力である点呼点検マスタ３０３のデータ構成例を説明する。点呼点検マスタ３０３は、乗務員の乗務前後や車両の運行前後に行う点呼や点検にかかる所要時間のマスタであり、乗務員や車両の過去の実績やスキルに応じて異なる所要時間の情報や、点呼点検を行う場所と乗務（運行）開始場所、終了場所が離れている場合のその間の回送にかかる所要時間の情報が格納される。
　点呼点検マスタ３０３は、リソース種別３０３０１、路線３０３０３、停留所３０３０５、開始終了種別３０３０７、点呼点検地点３０３０９、実績レベル３０３１１、点呼点検所要時間２２１１３、回送所要時間３３１１５の各値を格納するフィールドを含む。リソース種別３０３０１は、リソースの種別を特定する名称あるいは識別コードであり、各レコードで対象となるリソースが乗務員あるいは車両のいずれであるかを示す値として格納される。
　路線３０３０３は、鉄道やバスにおける路線を特定する名称あるいは識別コードであり、各レコードで対象となる路線の値が格納される。停留所３０３０５は、乗客の乗り降りのためにバスなどが停まる場所を特定する名称あるいは識別コードであり、乗務（運行）開始あるいは終了が可能な場所を示す値が格納される。開始終了種別３０３０７は、停留所３０３０５に格納された場所が乗務（運行）開始場所のものか、乗務（運行）終了場所のものかを特定する名称あるいは識別コードであり、開始あるいは終了を示す値が格納される。
　点呼点検場所３０３０９は、乗務員の乗務前後あるいは車両の運行前後に行う点呼や点検を実施する場所を特定する名称あるいは識別コードであり、停留所３０３０５および開始終了種別３０３０７にて特定される乗務（運行）開始場所あるいは乗務（運行）終了場所に対して、点呼や点検を行う場所を示す値が格納される。
　実績レベル３０３１１は、リソース種別３０３０１で特定される乗務員あるいは車両の、路線３０３０３で特定される路線における勤務経験、走行経験などの実績を定義する値であり、乗務員と車両それぞれでいくつかのレベル分けをし、例えば乗務員の「勤務経験あり」「代行経験あり」「経験なし」といった３段階で表される。ここに格納された実績レベルの値に応じて、点呼点検にかかる時間や回送にかかる時間がそれぞれ定義される。点呼点検所要時間３３１１３は、点呼点検場所３０３０９で特定される場所において実績レベル３０３１１で特定される実績をもつ乗務員あるいは車両が、点呼あるいは点検をするのにかかる所要時間の値が格納される。
　回送所要時間３３１１５は、停留所３０３０５と点呼点検場所３０３０９で特定される場所が一致しない場合に、その間を移動するのにかかる所要時間の値が格納される。停留所３０３０５と点呼点検場所３０３０９で特定される場所が一致する場合には、回送業務が発生しないので、所要時間も空でよい。
　例えば、リソース種別３０３０１に「乗務員」、路線３０３０３に「路線１」、停留所３０３０５に「停留所X」、開始終了種別３０３０７に「開始」、点呼点検場所３０３０９に「営業所X」、実績レベル３０３１１に「勤務経験あり」、点呼点検所要時間３３１１３に「１０分」、回送所要時間３３１１５に「１０分」が格納される場合、そのレコードの示す内容は「乗務員を路線１に割当するにあたり、乗務開始場所が停留所Xの場合には、点呼点検場所は営業所Xとなり、その乗務員が路線１での勤務経験がある場合には、点呼点検にかかる時間が１０分、営業所Xから停留所Xまで回送にかかる時間が１０分」となる。
　なお、点呼点検マスタ３０３における路線３０３０３ごとの停留所３０３０５について重複を削除した一覧が、図９Ｂのステップｓ２０７１で示した乗務員の乗務あるいは車両の運行の開始・終了が可能な場所の一覧と一致することになる。
　なお、点呼点検所要時間３３１１３や回送所要時間３３１１５は、乗務員や車両の個別の都合や当日の運行、天候、渋滞などの状況によって変動する値であるが、マスタと割り切って平均値や最大値を格納してもよいし、条件ごとに細かく値を設定してもよい。
　次に、図１１Ｂを用いて、ステップｓ２０７３の出力である回送情報３０５のデータ構成例を説明する。回送情報３０５は、貸出条件７１にて定義される貸出場所および貸出時刻と、点呼点検マスタ３０３にて定義される乗務（運行）開始場所への移動手段と移動時間、および点呼点検マスタ３０３にて定義される乗務（運行）開始終了場所から貸出条件７１にて定義される貸出場所への移動手段、移動時間の情報を計算した結果が格納される。
　回送情報３０５は、リソース種別３０５１、出発場所３０５３、到着場所３０５５、移動手段３０５７、移動時間３０５９の各値を格納するフィールドを含む。リソース種別３０５０１は、リソースの種別を特定する名称あるいは識別コードであり、対象のレコードの対象となるリソース種別が乗務員あるいは車両のいずれかであるかを示す値として格納される。
　出発場所３０５３、到着場所３０５５はそれぞれ、場所を特定する名称あるいは識別コードであり、回送の移動において出発する場所、および到着する場所を示す値を格納する。移動手段３０５７は、回送の移動に用いる手段を特定する名称あるいは識別コードであり、出発場所３０５３で特定される場所から到着場所３０５５で特定される場所までの移動手段として、例えば鉄道、タクシーなどを示す値が格納される。
　なお、リソース種別３０５１が車両の場合には、移動手段３０５７は空となる。移動時間３０５９は、出発場所３０５３で特定される場所から到着場所３０５５で特定される場所までの移動にかかる時間の値が格納される。例えば、リソース種別３０５１に「乗務員」、出発場所３０５３に「営業所X」、到着場所３０５５に「停留所X」、移動手段３０５７に「鉄道」、移動時間３０５９に「１０分」が格納される場合、そのレコードの示す内容は「乗務員が営業所Xから停留所Xまで鉄道で移動するのに３０分かかる」となる。
　出発場所３０５３や到着場所３０５５は、貸出条件７１や点呼点検マスタ３０３から取得する。移動手段３０５７や移動時間３０５９は一般的な経路検索アプリなどを用いて検索してもよく、渋滞や混雑の当日の状況も考慮されているものとする。あるいは、当日の状況を考慮することは難しいが、マスタとして事前に定義してもよい。
　なお、車両の回送の場合は、その車両を運転する乗務員の情報も必要である。回送情報３０５が作成されるタイミングでは、厳密な時刻を推定するものではなく、割当する運行便も決められないため、このタイミングで乗務員の特定までする必要は無いが、割当する運行便が決まり出発時刻や到着時刻が決まる場合には、考慮されるべきである。また、乗務員と車両をセットで借用する場合もある。
　ここからは、図１２Ａを用いて、ステップｓ２０７５にて作成されるダイヤ開始終了制約条件３１３１のデータ構成例を説明する。ダイヤ開始終了制約条件３１３１は、図１０Ｂにて説明した乗務（運行）可能範囲１０４５に関する情報および数値が格納される。
　ダイヤ開始終了制約条件３１３１は、リソース３１３１１、路線３１３１３、停留所３１３１５、開始終了種別３１３１７、条件分類３１３１８、時刻３１３１９の各値を格納するフィールドを含む。
　リソース３１３１１は、リソースを特定する名称あるいは識別コードであり、貸借の候補となるリソースを一意に特定する値が格納される。路線３１３１３は、鉄道やバスにおける路線を特定する名称あるいは識別コードであり、路線３１３１１で特定されるリソースを割当する予定の路線の値が格納される。停留所３１３１５は、乗客の乗り降りのためにバスなどが停まる場所を特定する名称あるいは識別コードであり、乗務（運行）開始あるいは終了が可能な場所を示す値が格納される。
　開始終了種別３１３１７は、停留所３１３１５に格納された場所が乗務（運行）開始場所のものか、乗務（運行）終了場所のものかを特定する名称あるいは識別コードであり、開始あるいは終了を示す値が格納される。条件分類３１３１８は、時刻３１３１９の時刻を算出するにあたり、参照する条件の値が、貸出条件７１の注意条件７１０５に格納される値であるか、警告条件７１０７に格納される値であるかを特定する名称あるいは識別コードである。
　時刻３１３１９は、停留所３１３１５と開始終了種別３１３１７で特定される乗務（運行）開始場所あるいは終了場所にて乗務（運行）開始可能な最も早い時間、あるいは終了すべき最も遅い時間の値が、貸出条件７１、点検点呼マスタ３０３、回送情報３０５に基づき作成し、格納される。
　例えば、リソース３１３１１に「乗務員Ｂ１」、路線３１３１３に「路線１」、停留所３１３１５に「停留所Ｘ」、開始終了種別３１３１７に「開始」、時刻３１３１９に「Ｘ１時Ｘ１分」が格納される場合、そのレコードの示す内容は「乗務員Ｂ１を路線１に割当する場合、停留所Ｘの乗務開始時間はＸ１時Ｘ１分以降」となる。
　次に、図１２Ｂを用いて、ステップｓ２０７７にて作成されるリソース制約条件３１３３のデータ構成例を説明する。リソース制約条件３１３３は、ステップｓ２０７１からの処理の流れにおいて貸借対象とされていたリソースの該当するリソース種別（乗務員か車両か）に関して、各主体のルールに従って事前に定義されるリソース運用に関する制約条件や、貸出条件７１として当日に定義され、ダイヤ開始終了制約条件３１３１に関与しない制約条件を集約したうえで、貸借の対象リソースを優先して割当できるように優先順位付けを定義した制約条件が格納される。
　リソース制約条件３１３３は、主体３１３３１、条件項目３１３３３、注意条件３１３３５、警告条件３１３３７、優先順位３１３３９の各値を格納するフィールドを含む。主体３１３３１は、運営主体やリソースを特定する名称あるいは識別コードであり、対象レコードに記載の条件が満たされるべきリソースの所属する事業者や、リソースそのものを示す値が格納される。条件項目３１３３３は、主体３１３３１で特定される対象のリソースあるいはリソース群が、満たすべき条件の項目を特定する名称あるいは識別コードを格納する。
　注意条件３１３３５は、警告条件３１３３７は、条件項目３１３３３で特定されるお受験の項目に関して満たすべき条件の値が格納される。注意条件３１３３５にはなるべく満たすべき条件を、警告条件３１３３７には確実に満たすべき条件が格納される。注意条件３１３３５には必ずしも値が格納されなくてもよい。
　優先順位３１３３９は、リソース制約条件３１３３に格納される各条件を優先順位付けした値が格納される。主体３１３３１に格納される値が、ステップｓ２０７１からの処理の流れにおいて貸借対象とされていたリソースそのものであれば、そのレコードは優先順位が最優先になる。
　また主体３１３３１に格納される値が、貸借対象のリソースの所属する営業所や事業所、つまりリソース所有主であれば、その次に優先される。その次に優先されるのは、主体３１３３１に格納される値が、借用の依頼主である場合である。主体３１３３１に格納される値が、貸借に関与しない主体であったり、各社共通である場合には、優先順位は下位になる。例えば、主体３１３３１に「各社共通」、条件項目３１３３３に「一日の拘束時間」、注意条件３１３３５に「１３時間以下」、警告条件３１３３７に「１６時間以下」、優先順位３１３３９に「４」が格納される場合、そのレコードの示す内容は「一日の拘束時間は１３時間以下であることが望ましいが、最悪の場合１６時間以内まで許容される、という各社共通の条件は、優先順位第４位である」となる。
　次に、図１３を用いて、乗務員運用整理部２０９および車両運用整理部２０１１の処理フローを説明する。ここでは乗務員運用整理部２０９を例に説明するが、車両運用整理部も同様の処理フローである。
　まず、ダイヤ開始終了制約条件３１３１から、割当可能な運行便の候補を抽出する（ｓ２０９０１）。割り当て可能な運行便の抽出方法は図１０Ｂを用いて先述した通りである。
　次に、ステップｓ２０９０１が抽出した運行便の中から、リソース制約条件３１３３の注意条件３１３３５を満たす運行便を探索して、割当可能な運行便の候補を絞り込む（ｓ２０９０３）。
　次に、ステップｓ２０９０３にて絞りこまれた割当可能な運行便の候補（以降では候補便と呼ぶ）の有無を判定する（ｓ２０９０５）。候補便「有り」の場合には、ステップｓ２０９１３に進む。候補便「無し」の場合には、ステップｓ２０９０７に進む。
　ステップｓ２０９０７では、リソース制約条件３１３３の優先順位３１３３９が低い条件の順に、ステップｓ２０９０９、ｓ２０９１１の処理を繰り返し実行する（ｓ２０９０７）。ステップｓ２０９０９では、ステップｓ２０９０３にて候補便の絞り込みに用いたリソース制約条件３１３３の注意条件３１２２５を、警告条件３１３３７に切り替えて、改めてステップｓ２０９０１が抽出した運行便の中から、リソース制約条件３１３３を満たす運行便を探索し、候補便とする（ｓ２０９０９）。
　次のステップｓ２０９１１では、ステップｓ２０９０９にて見つかった候補便の有無を判定する（ｓ２０９１１）。候補便「有り」の場合には、ステップｓ２０９１３に進む。候補便「無し」の場合には、ｓ２０９０７に戻り、次に優先順位が低い条件について、ステップｓ２０９０９から改めて処理を実行する。
　ステップｓ２０９１３に進んだ場合には、それまでの処理にて候補便として絞り込まれた運行便の数の分だけ、ステップｓ２０９１５、ｓ２０９１７の処理を繰り返し実行する（ｓ２０９１３）。ステップｓ２０９１５では、候補便以外の運行便、つまり自社のリソースで賄われる運行便について、運用整理を実施し、運用情報（本例では乗務員運用情報３０９）の変更案を作成する（ｓ２０９１５）。
　運用整理の手法やアルゴリズムは、現行の交通事業者が実施する一般的なものでよい。ステップｓ２０９１５において、元の運用情報から運行便の割当が変更となったリソースの数（運用変更数と呼ぶ）をカウントする（ｓ２０９１７）。ステップｓ２０９１３からの繰り返し処理が終了したら、各繰り返しのステップ２０９１７の処理でカウントされた運用変更数の数が最も少ない運用整理案を採用して乗務員運用情報３０９の変更案を作成し、乗務員運用整理２０９の処理を終了する（ｓ２０９１９）。
　ステップｓ２０９１３より前の処理において、リソース所有主から借用したリソースの制約条件を最優先に設定しつつも、ステップｓ２０９１３以降の処理に置いて、借用依頼主の運用変更数が最も少ない運用整理案を採用することで、リソース所有主、借用依頼主の双方にとって都合が良い乗務員運用情報３０９および車両運用情報３１１を作成する。なお、リソース制約条件３１３３の優先順位３１３３９を用いることで候補便の絞り込みが全くできないような場合には、優先順位３１３３９を必ずしも使わなくてよい。
　図１４に、リソース借用の依頼主であるバス事業者Ａの運行・運用管理装置６の管理者６０に表示する路線特性設定画面１５００の例を示す。
　管理者６０は、借用したリソースを割当したい路線に関して、事前にあるいは当日に、路線特性３０１に格納される情報を作成・更新するために、本画面を操作するものとする。
　路線特性設定画面１５００は、路線格納部１５０１、リソース種別格納部１５０３、必須除外条件格納部１５０５、任意除外条件格納部１５０７から構成される。必須除外条件１５０５は、除外条件格納部１５０５１、日時限定格納１５０５３から構成され、行削除ボタン１５０５を押下することで条件を削除したり、行追加ボタン１５０７を押下することで条件を追加したりすることができる。
　任意除外条件は、除外条件格納部１５７０１、日時限定格納部１５０７３、適合係数格納部１５０７５から構成され、行削除ボタン１５０７７を押下することで条件を削除したり、行追加ボタン１５０７９を押下することで条件を追加したりすることができる。管理者６０が本画面から入力した各値が、路線特性３０１に反映される。
　図１４に例示する画面により、リソース借用の依頼主であるバス事業者Ａの運行・運用管理装置６の管理者６０が路線特性３０１を柔軟に作成、更新できることで、借用したリソースを乗務・運行させる対象路線の要件を細かく設定でき、より最適なリソースを探索することができる。
　図１５に、リソース借用の依頼主であるバス事業者Ａの運行・運用管理装置６の管理者６０に表示するダイヤ図表示画面１４００の例を示す。
　図１５は、図３のフローチャートにおけるステップｓ１０９（貸借案３１５の表示）において表示される画面であり、ダイヤ図のスジを借用リソース、運用変更されたリソースなどを区別しやすいように描画し、更に乗務員の乗務可能範囲あるいは車両の運行可能範囲を描画した画面を想定している。管理者６０は、本画面の表示を参考にして、借用するリソースを選択する。
　ダイヤ図表示画面１４００は、縦軸１０４１に対象路線における始発から終点までの停留所の並び、横軸１０４３に時間をとったダイヤ図と呼ばれるグラフ上にバスの運行便をダイヤスジ（１４０５ａ、１４０５ｂ、１４０５ｃ、１４０５ｄ、１４０５ｅ）として表記したうえで、ダイヤ開始終了制約条件３１３１の条件分類３１３１８に注意条件が格納されるレコードに基づき塗りつぶされる乗務（運行）可能範囲エリア１４０１と、更に条件分類３１３１８に警告条件が格納されるレコードに基づき塗りつぶされる乗務（運行）可能範囲エリア１４０３を図示する。
　乗務（運行）可能範囲エリアである１４０１と１４０３は、塗りつぶしのエリアが重複するため、配色を変えると理解しやすい。また、ダイヤスジ１４０５ａから１４０５ｅは、借用リソースが割当されたスジであるか、あるいは運用変更されたリソースが割当されたスジであるか、などによって色や太さを変えると理解しやすい。画面上部には運転整理、運用整理の案ごとにタブ１４０１を設定することで表示の切替が可能になり、選択ボタン１０４９を押下することで、借用するリソースや運転整理案、運用整理案の選択が可能になる。
　図１５に例示する画面により、ダイヤ図を用いて乗務（運行）可能範囲を図示することで、リソース借用の依頼主であるバス事業者Ａの運行・運用管理装置６の管理者６０は、借用リソースの候補を絞り込むための判断材料とすることができる。
　図１６に、リソース借用の依頼主であるバス事業者Ａの運行・運用管理装置６の管理者６０に表示する地図表示画面１６００の例を示す。
　図１６は、図３のフローチャートにおけるステップｓ１０９（貸借案３１５の表示）において表示される画面であり、一般的な地図の上に、借用場所、点呼点検場所、停留所、返却場所の位置や、その間を移動するための経路、および移動時間や滞在時間を描画した画面を想定している。管理者６０は、本画面の表示を参考にして、借用するリソースを選択する。
　地図画面１６００は、一般的な地図に対して、自社管轄エリアに該当する範囲を線で囲ったり（１６０３）、自社の停留所や点呼点検場所に該当する位置にマーキングしたり（１６０５ａ、ｂ、ｃ、ｄ）、他社のリソース貸出場所や返却場所に該当する位置にマーキングしたり（１６０７ａ、ｂ）、営業運行の移動経路に該当する道路に線を引いたり（１６０９）、回送の移動経路に該当する道路に線を引いたり（１６１１ａ、ｂ、ｃ、ｄ）される。マーキングや線の近くに、場所の名称、移動にかかる時間、交通手段などの情報を記載すると理解しやすい。画面上部には、借用するリソースごとやリソース内の運転整理、運用整理の案ごとにタブ１６０１を設定することで表示の切替が可能になる。図１５と同様に選択ボタンを配置してもよい。
　図１６に例示する画面により、地図を用いて借用するリソースに関する移動経路や所要時間を図示することで、リソース借用の依頼主であるバス事業者Ａの運行・運用管理装置６の管理者６０は、借用リソースの候補を絞り込むための判断材料とすることができる。
　図１７に、リソース借用の依頼主であるバス事業者Ａの運行・運用管理装置６の管理者６０に表示するコスト表示画面１７００の例を示す。
　図１７は、図３のフローチャートにおけるステップｓ１０９（貸借案３１５の表示）において表示される画面であり、借用リソース案ごとに借用にかかるコストを比較しやすいように描画した画面を想定している。管理者６０は、本画面の表示を参考にして、借用するリソースを選択する。
　コスト表示画面１７００は、横軸時間のグラフ１７０３に、貸出と返却それぞれにおいて回送と点呼点検にかかる所要時間を棒グラフで横軸方向に描画し、借用するリソースごとやリソース内の運転整理、運用整理の案ごとに１７０５ａ、ｂとして縦軸方向に並べたものである。画面上部には、コストの種類ごとにタブ１７０１を設定することで表示の切替が可能になる。図１５と同様に選択ボタンを配置してもよい。
　図１８に、リソース借用の依頼主であるバス事業者Ａの運行・運用管理装置６の管理者６０に表示する時間帯表示画面１８００の例を示す。
　図１８は、図３のフローチャートにおけるステップｓ１０９（貸借案３１５の表示）において表示される画面であり、借用可能な時間帯や適合度をスケジュール表に描画した画面を想定している。管理者６０は、本画面の表示を参考にして、借用するリソースを選択する。
　時間帯表示画面１８００は、リソース１８０１、リソース所有主１８０３に各値が表示され、時間帯１８０５に各時間における借用可否を表す値を表示する。リソース所有主１８０３が所有するリソース１８０１に関して、時間帯１８０５に各時間における借用可能な時間帯をマークで表示する。例えば路線との適合度に応じて、適合度が高い順に、◎、〇、△といったようにマークを変えて表示すると、理解しやすい。このマークをクリックすることで図１５の選択ボタンと同様に選択決定されてもよい。
　以上、図１５から図１８までに、借用リソース案の画面表示例を示したが、この他にも貸借案３１５に格納される情報を表などを用いて表示してもよい。また、図１５から図１８の画面は、個別に表示してもよいし、複数の画面を並べたり切り替えたりして表示してもよい。
　図１９に、リソース所有主であるバス事業者Ｂの運行・運用管理装置７の管理者７０に表示する乗務（運行）スケジュール表示画面１９００の例を示す。
　図１９は、図３のフローチャートにおけるステップｓ１１９（正式依頼６３の表示）において表示される画面であり、貸借の対象とするリソースに関して乗務や運行のスケジュールを自社他社合わせて図示した画面を想定している。管理者７０は、本画面の表示を参考にして、リソース借用依頼主であるバス事業者Ａからのリソース貸借の依頼を承諾するか拒否するかを選択する。
　乗務（運行）スケジュール表示画面１９００は、時間帯１９０１に各時間帯における乗務（運行）内容を表す値を表示し、承諾ボタン１９０３あるいは拒否ボタン１９０５を押下することで、リソース貸出の依頼を承諾するか拒否するかの選択が可能になる。時間帯１９０１には、各時間における乗務（運行）内容を、自社乗務（１９０１７）、回送（１９０１１ａ、ｂ）、他社乗務（１９０１５）、休憩（１９０３ａ、ｂ）といったように例えば色分けして表示する。
　貸借対象リソースの画面表示は、図１５のように図を用いた表示でなくても、対象となるリソースや貸出時間、貸出先などの情報を、表などを用いて表示してもよい。また、貸借の対象となるリソースや貸出から返却の間のスケジュールは一意に決まるものとして説明したが、複数案を提示することでリソース所有主が望ましい案を選択させてもよい。また、承諾あるいは拒否の回答に対してリソース所有主からの要求を追加してもよい。
　以上、本発明を実施例に沿って説明した。本発明は上記実施例に限定されるものではなく、様々な変形例が含まれる。上記実施例は本発明を分かりやすく説明するために詳細に記載したものであり、説明した全ての構成を備えるものに限定されるものではない。
　例えば、本実施例においては貸借の対象は乗務員として説明したが、貸借の対象は車両であってもよいし、乗務員と車両がセットであってもよい。貸借の対象は複数であってもよい。また、本実施例においては貸借リソースを貸出先で割当する運行便は一つとして説明したが、複数の運行便であってもよいし、複数の路線であってもよい。
　また例えば、貸借案３１５にはコスト情報３１５７として借用料金３１５７５の情報を格納したが、金銭によって運営主体間のコストを精算するだけでなく、互いのリソースの貸借回数や貸借時間を揃えるなどして金銭の授受が発生しないように精算を行ってもよい。
　また例えば、各運営主体の運行・運用管理システム６、７、８、９は、乗客に対する案内配信などの機能を備えてもよい。あるいは、交通リソース貸借管理装置１の乗務員運用整理部２０９、車両運用整理部２０１１、運転整理部２０１３は必ずしも交通リソース貸借管理装置１に備えられていなくてもよく、制約条件作成部２０７で作成されたデータを各運営主体の運行・運用管理システム６、７、８、９に送信して、そこで運用整理や運転整理が実行されてもよい。
　本実施例によれば、リソース割当のない運行便に対して貸借したリソースを割当できない場合でも、貸借するリソースの割当可能範囲を作成し、割当先の他の便の運行や運用を柔軟に変更しながら割当を行うことで、路線として運行を最適に実行できるようになる。
　また、本実施例によれば、営業所間や事業者間で交通リソースを容易に貸借し合えるようになり、それぞれが管理する車両や乗務員の待機数を削減できれば、車両の維持コストや設備の老朽化に伴う取り換えコスト、人件費などを抑制することができる。また、運行障害など不測の事態があった場合に、代替手段を用意できるため、サービス品質の低下を防ぐことができる。
１：交通リソース貸借管理装置、３０：記憶部、３０１：路線特性、３０３：点呼点検マスタ、３０５：回送情報、３０７：時刻表、３０８：乗務員運用情報、３１１：車両運用情報、３１３：制約条件、３１３１：ダイヤ開始終了制約条件、３１３３：リソース制約条件、３１５：貸借案、２０１：送受信部、２０３：貸借案作成部、２０５
リソース探索部、２０７：制約条件作成部、２０９：乗務員運用整理部、２０１１：車両運用整理部、２０１３：運転整理部、２０１５：回答作成部

Claims (14)

  1. プロセッサを有し複数の公共交通運営主体の間でリソースを貸借する場合に貸借する前記リソースの候補を探索する交通リソース貸借管理装置であって、
    前記リソースの借用を希望する前記公共交通運営主体である依頼主の運行運用管理装置から受信した貸借案作成依頼に基づき貸借案を作成する貸借案作成部を有し、
    前記貸借案作成部は、
    前記プロセッサにより、貸出可能な前記リソースを所有する前記公共交通運営主体であるリソース所有主の前記運行運用管理装置から受信した貸出条件と前記貸借案作成依頼から貸借対象の候補となる前記リソースを候補リソースとして抽出し、路線特性に基づき前記候補リソースと割当予定路線との適合度を算出するリソース探索部と、
    前記プロセッサにより、乗務員の乗務又は車両の運行が可能な場所と時間の制約情報を格納するダイヤ開始終了制約条件と、前記ダイヤ開始終了制約条件に関与しない制約条件に優先順位付けを定義したリソース制約条件を作成する制約条件作成部と、
    前記プロセッサにより、前記依頼主に対する回答として前記貸借案を作成する回答作成部と、を有し、
    前記制約条件作成部は、
    前記プロセッサにより、前記リソース所有主から受信した前記貸出条件に格納される貸出場所又は返却場所と、乗務及び運行の開始場所又は終了場所の間の移動手段又は移動時間を格納する回送情報を作成し、
    前記貸出条件に格納される前記貸出場所と貸出時間及び前記返却場所と返却時間と、前記回送情報に格納される前記貸出場所又は前記返却場所と乗務及び運行の前記開始場所又は前記終了場所の間の前記移動手段又は前記移動時間に基づき、前記乗務又は前記車両の運行が可能な場所と時間の制約情報を格納する前記ダイヤ開始終了制約条件を作成することを特徴とする交通リソース貸借管理装置。
  2. 前記プロセッサにより、前記ダイヤ開始終了制約条件と前記リソース制約条件に基づき乗務員運用情報及び車両運用情報の変更案を作成する乗務員運用整理部及び車両運用整理部と、
    前記プロセッサにより、前記変更された前記乗務員運用情報及び前記車両運用情報に基づき時刻表の変更案を作成する運転整理部と、
    を更に有することを特徴とする請求項１に記載の交通リソース貸借管理装置。
  3. 前記路線特性は、
    前記依頼主が管理する路線ごとに割当不可能な前記リソースの条件を定めるデータであり、割当可否に直接関与する必須除外条件と、割当から除外すべき任意除外条件と、前記必須除外条件及び前記任意除外条件ごとに適合係数が定義され、
    前記リソース探索部は、
    前記プロセッサにより、前記候補リソースが満たす前記必須除外条件と前記任意除外条件の前記適合係数を掛け合わせることにより前記適合度を算出し、
    前記適合度の低い前記候補リソースを割当の候補から除外あるいは前記優先順位を下げることを特徴とする請求項１に記載の交通リソース貸借管理装置。
  4. 前記乗務員運用整理部及び前記車両運用整理部は、
    前記プロセッサにより、前記ダイヤ開始終了制約条件に基づき貸借対象リソースを割当可能な運行便の候補を抽出し、
    前記優先順位、警告条件及び注意条件に基づき、前記優先順位に応じて前記警告条件と前記注意条件を切り替えて前記貸借対象リソースを割当可能な前記運行便の候補を絞り込み、
    前記貸借対象リソースを割当てる前記運行便を定めた後に、前記依頼主における他の運行便の運用情報の変更案を作成することを特徴とする請求項２に記載の交通リソース貸借管理装置。
  5. 前記乗務員運用整理部及び前記車両運用整理部は、
    前記プロセッサにより、前記運転整理部が前記時刻表の変更案を作成した後に前記ダイヤ開始終了制約条件と前記リソース制約条件を満たさない場合には、変更された時刻表を用いて再度前記貸借対象リソースの割当候補の絞り込みと前記他の運行便の運用情報の変更案を作成することを特徴とする請求項４に記載の交通リソース貸借管理装置。
  6. 前記回答作成部が作成する前記貸借案は、
    貸借の可否を表すフラグと、貸借可能な前記リソースと、計画変更情報と、前記貸借によって発生するコストの情報を格納することを特徴とする請求項１に記載の交通リソース貸借管理装置。
  7. プロセッサを有し複数の公共交通運営主体の間でリソースを貸借する場合に貸借する前記リソースの候補を探索する交通リソース貸借管理装置と、
    前記交通リソース貸借管理装置に接続され、前記リソースの借用を希望する前記公共交通運営主体である依頼主の運行運用管理装置と、
    を有する交通リソース貸借管理システムであって、
    前記交通リソース貸借管理装置は、
    前記運行運用管理装置から受信した貸借案作成依頼に基づき貸借案を作成する貸借案作成部を有し、
    前記貸借案作成部は、
    前記プロセッサにより、貸出可能な前記リソースを所有する前記公共交通運営主体であるリソース所有主の前記運行運用管理装置から受信した貸出条件と前記貸借案作成依頼から貸借対象の候補となる前記リソースを候補リソースとして抽出し、路線特性に基づき前記候補リソースと割当予定路線との適合度を算出するリソース探索部と、
    前記プロセッサにより、乗務員の乗務又は車両の運行が可能な場所と時間の制約情報を格納するダイヤ開始終了制約条件と、前記ダイヤ開始終了制約条件に関与しない制約条件に優先順位付けを定義したリソース制約条件を作成する制約条件作成部と、
    前記プロセッサにより、前記依頼主に対する回答として前記貸借案を作成する回答作成部と、を有し、
    前記制約条件作成部は、
    前記プロセッサにより、前記リソース所有主から受信した前記貸出条件に格納される貸出場所又は返却場所と、乗務及び運行の開始場所又は終了場所の間の移動手段又は移動時間を格納する回送情報を作成し、
    前記貸出条件に格納される前記貸出場所と貸出時間及び前記返却場所と返却時間と、前記回送情報に格納される前記貸出場所又は前記返却場所と乗務及び運行の前記開始場所又は前記終了場所の間の前記移動手段又は前記移動時間に基づき、前記乗務又は前記車両の運行が可能な場所と時間の制約情報を格納する前記ダイヤ開始終了制約条件を作成することを特徴とする交通リソース貸借管理システム。
  8. 前記運行運用管理装置は、
    前記路線特性を設定するための路線特性設定画面を表示することを特徴とする請求項７に記載の交通リソース貸借管理システム。
  9. 前記運行運用管理装置は、
    前記交通リソース貸借管理装置から送信される前記借用案に格納されるダイヤに関する情報をダイヤ図表示画面として表示することを特徴とする請求項７に記載の交通リソース貸借管理システム。
  10. 前記運行運用管理装置は、
    前記交通リソース貸借管理装置から送信される前記借用案に格納される地図に関する情報を地図表示画面として表示することを特徴とする請求項７に記載の交通リソース貸借管理システム。
  11. 前記運行運用管理装置は、
    前記交通リソース貸借管理装置から送信される前記借用案に格納されるコストに関する情報をコスト表示画面として表示することを特徴とする請求項７に記載の交通リソース貸借管理システム。
  12. 前記運行運用管理装置は、
    前記交通リソース貸借管理装置から送信される前記借用案に格納される時間帯に関する情報を時間帯表示画面として表示することを特徴とする請求項７に記載の交通リソース貸借管理システム。
  13. プロセッサを有し複数の公共交通運営主体の間でリソースを貸借する場合に貸借するリソースの候補を探索する交通リソース貸借管理方法であって、
    前記リソースの借用を希望する前記公共交通運営主体である依頼主の運行運用管理装置から受信した貸借案作成依頼に基づき貸借案を作成する貸借案作成ステップを有し、
    前記貸借案作成ステップは、
    前記プロセッサにより、貸出可能な前記リソースを所有する前記公共交通運営主体であるリソース所有主の前記運行運用管理装置から受信した貸出条件と前記貸借案作成依頼から貸借対象の候補となる前記リソースを候補リソースとして抽出し、路線特性に基づき前記候補リソースと割当予定路線との適合度を算出するリソース探索ステップと、
    前記プロセッサにより、乗務員の乗務又は車両の運行が可能な場所と時間の制約情報を格納するダイヤ開始終了制約条件と、前記ダイヤ開始終了制約条件に関与しない制約条件に優先順位付けを定義したリソース制約条件を作成する制約条件作成ステップと、
    前記プロセッサにより、前記依頼主に対する回答として前記貸借案を作成する回答作成ステップと、を有し、
    前記制約条件作成ステップは、
    前記プロセッサにより、前記リソース所有主から受信した前記貸出条件に格納される貸出場所又は返却場所と、乗務及び運行の開始場所又は終了場所の間の移動手段又は移動時間を格納する回送情報を作成し、
    前記貸出条件に格納される前記貸出場所と貸出時間及び前記返却場所と返却時間と、前記回送情報に格納される前記貸出場所又は前記返却場所と乗務及び運行の前記開始場所又は前記終了場所の間の前記移動手段又は前記移動時間に基づき、前記乗務又は前記車両の運行が可能な場所と時間の制約情報を格納する前記ダイヤ開始終了制約条件を作成することを特徴とする交通リソース貸借管理方法。
  14. 前記プロセッサにより、前記ダイヤ開始終了制約条件と前記リソース制約条件に基づき乗務員運用情報及び車両運用情報の変更案を作成する乗務員運用整理ステップ及び車両運用整理ステップと、
    前記プロセッサにより、前記変更された前記乗務員運用情報及び前記車両運用情報に基づき時刻表の変更案を作成する運転整理ステップと、
    を更に有することを特徴とする請求項１３に記載の交通リソース貸借管理方法。
PCT/JP2023/041208 2022-12-01 2023-11-16 交通リソース貸借管理装置、交通リソース貸借管理システム及び交通リソース貸借管理方法 WO2024116865A1 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2022192576A JP2024079898A (ja) 2022-12-01 2022-12-01 交通リソース貸借管理装置、交通リソース貸借管理システム及び交通リソース貸借管理方法
JP2022-192576 2022-12-01

Publications (1)

Publication Number Publication Date
WO2024116865A1 true WO2024116865A1 (ja) 2024-06-06

Family

ID=91323560

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2023/041208 WO2024116865A1 (ja) 2022-12-01 2023-11-16 交通リソース貸借管理装置、交通リソース貸借管理システム及び交通リソース貸借管理方法

Country Status (2)

Country Link
JP (1) JP2024079898A (ja)
WO (1) WO2024116865A1 (ja)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012017172A (ja) * 2010-07-07 2012-01-26 Nippon Steel Corp 配船計画作成装置、方法及びプログラム
WO2013084268A1 (ja) * 2011-12-09 2013-06-13 株式会社日立製作所 異主体間連携による資源融通方式
JP2021196838A (ja) * 2020-06-12 2021-12-27 株式会社Ｙｋｂシステムズ 人員マッチングシステム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012017172A (ja) * 2010-07-07 2012-01-26 Nippon Steel Corp 配船計画作成装置、方法及びプログラム
WO2013084268A1 (ja) * 2011-12-09 2013-06-13 株式会社日立製作所 異主体間連携による資源融通方式
JP2021196838A (ja) * 2020-06-12 2021-12-27 株式会社Ｙｋｂシステムズ 人員マッチングシステム

Also Published As

Publication number Publication date
JP2024079898A (ja) 2024-06-13

Similar Documents

Publication Publication Date Title
Ashkrof et al. Understanding ride-sourcing drivers' behaviour and preferences: Insights from focus groups analysis
Wang Routing and scheduling for a last-mile transportation system
Kuo et al. Public transport for smart cities: Recent innovations and future challenges
JP6655939B2 (ja) 輸送サービス予約方法、輸送サービス予約装置、及び輸送サービス予約プログラム
JP3959245B2 (ja) 乗合車両運行スケジューリングシステム
US7813846B2 (en) System and method for railyard planning
JP4056076B2 (ja) 空席経路探索システム、空席経路探索装置および端末装置
Vaidyanathan et al. Multicommodity network flow approach to the railroad crew-scheduling problem
JP7022039B2 (ja) 車両割当支援システム、方法、およびプログラム
WO2022130705A1 (ja) 運行支援システムおよび運行支援方法
US20200005235A1 (en) Port management system,reservation management server, ship manager terminal and port manager terminal
König et al. Railway delay management with passenger rerouting considering train capacity constraints
JP6656899B2 (ja) 輸送計画システム、および輸送計画変更支援方法
JP2003141219A (ja) サービススケジューリング方法及びプログラム
JP6902481B2 (ja) リソース調停システムおよびリソース調停装置
Yu et al. Time window optimization for attended home service delivery under multiple sources of uncertainties
WO2024116865A1 (ja) 交通リソース貸借管理装置、交通リソース貸借管理システム及び交通リソース貸借管理方法
JP4054018B2 (ja) 空席経路探索システム、空席経路探索装置および端末装置
Freemark et al. Multimodal Relationships: Shared and Autonomous Vehicles and High-Capacity Public Transit
Thorlacius Integrated Rolling Stock Planning for Suburban Passenger Railways
JP4519223B2 (ja) 配車自動作成装置
JP7268719B1 (ja) 出向計画システム、制御方法およびプログラム
WO2024134897A1 (ja) 配車管理装置及び配車管理方法
WO2023175853A1 (ja) オペレーションプラン作成システム、交通サービス連携システム、オペレーションプラン作成方法、及びオペレーションプラン作成プログラム
WO2019093255A1 (ja) リソース調停システムおよびリソース調停装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23897516

Country of ref document: EP

Kind code of ref document: A1