Information processing device, information processing method, and computer program

Abstract

To provide an information processing device, method, and program for updating constraint information including a constraint condition with a simple procedure.SOLUTION: In a plan system, a plan creation device 1 creates a candidate plan for work to be performed by an operator on the basis of constraint information including at least one constraint condition about the work to be assigned to an operator, and provides a plan management device 2 with the generated candidate plan. The plan management device 2 determines if the candidate plan has a constraint violation, and feeds back constraint violation information including contents of the constraint violation to the plan generation device 1 if the constraint violation exists. The plan generation device 1 converts the constraint violation information fed back from the plan management device 2 into a constraint condition interpretable by a plan system, and updates the constraint information on the basis of the converted constraint condition. The plan generation device 1 generates a final work plan by repeating the generation of a candidate plan and the update of constraint information.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] An embodiment of the present invention relates to an information processing device, an information processing method, and a computer program. [Background technology]

[0002] A plan to assign tasks to each worker so as to satisfy the wide variety of constraints at the work site is called a work plan or shift scheduling. With the increase in non-regular employees, there is a growing need to automate work plans (shift scheduling) for human resources in various fields such as transportation, manufacturing, medical care, nursing care, stores, and education. For example, crew planning is an example in the transportation field, such as railways and public transportation. Crew planning is the process of converting an anonymous basic plan, known as a shift plan, into a specific work plan (shift scheduling) that satisfies the individual conditions of each crew member (annual leave, qualifications, etc.).

[0003] In work schedules for human resources, there are many constraints (hereafter referred to as soft constraints) that correspond to on-site know-how and that "should be observed as much as possible." With soft constraints, there are often cases where mutually contradictory soft constraints must be satisfied simultaneously, or where no solution exists that satisfies all soft constraints.

[0004] As a representative example of a general solution method for scheduling when such soft constraints are set, the method shown in Non-Patent Document 1 is known. First, for each soft constraint, a calculation formula for a penalty according to the degree of violation of the constraint and a weight according to the importance of each constraint are defined. Then, the planning problem is expressed in the form of a weighted constraint satisfaction problem that minimizes the weighted sum of the penalties. This planning problem is solved as a combinatorial optimization problem.

[0005] With these methods, it is extremely difficult to tune the priority and weight of each constraint condition to a well-balanced value in advance. Also, even within the same company, each workplace has its own unique constraint conditions, so it is difficult to find out all the conditions and reflect them as constraint conditions. Also, since work rules are often changed irregularly after the start of operation (i.e., constraint conditions are changed), it is also difficult to maintain the parameter setting data of the planning module that generates the plan. For this reason, tuning of priorities and weights has traditionally been done manually.

[0006] As one of the techniques to solve such problems, there is a classical artificial intelligence method called case-based. In this method, past case data similar to the input data is found, and the found case data is used to select the constraints to be used in the target and to generate a plan. As another technique, there is a method of accumulating past planning cases as teachers, and learning the constraints and the weights of the constraints so that the features of the automatically proposed plan are close to the features of the teacher data. However, the above-mentioned case-based method and the method of learning the constraints and weights from past planning cases require the preparation of a large amount of case data of correct plans created by experts, which is a high barrier to practical use. [Prior art documents] [Patent documents]

[0007] [Patent Document 1] JP 2018-120342 A [Patent Document 2] JP 2019-028576 A [Patent Document 3] Patent No. 6467264 [Patent Document 4] Patent No. 6502816 [Patent Document 5] Patent No. 6622592 [Non-patent literature]

[0008] [Non-Patent Document 1] Koji Nonobe: "Constructing a general-purpose solver using metaheuristics", Journal of the Operations Research Society of Japan, May 2011, pp. 257-262 [Non-Patent Document 2] Atsuko Ikegami et al.: "Nurse Scheduling Problems in Japan", Journal of the Operations Research Society of Japan, August 1996, p436-442 Summary of the Invention [Problem to be solved by the invention]

[0009] The embodiments of the present invention provide an information processing device, an information processing method, and a computer program capable of updating constraint information including constraint conditions in a simple procedure. [Means for solving the problem]

[0010] In order to solve the above problems, according to one embodiment of the present invention, a system includes: a user interface unit that allows a user to check for constraint violations of candidate plans for operations performed by a plurality of workers; An information processing device is provided, comprising: an update unit that updates constraint information including a first constraint condition related to the work, based on a constraint violation of the candidate plan. [Brief description of the drawings]

[0011] [Figure 1] FIG. 1 is a block diagram illustrating a planning system according to an embodiment of the present invention. [Diagram 2] FIG. 4 is a diagram showing an example of a crew work schedule. [Diagram 3] FIG. 4 is a diagram showing a specific example of route definition data. [Figure 4] FIG. 1 is a diagram showing daily work allocations among multiple workers. [Diagram 5] This figure shows an example in which there are two options for constraint types: sequence of work conditions and sequence of work, and sequence of work has been selected. [Figure 6]This figure shows an example in which there are three options for constraint types: driving qualification, work qualification, and driving experience, and driving qualification has been selected. [Figure 7] There are four types of constraints to choose from: total working hours (upper limit), total working hours (lower limit), number of public holidays (lower limit), and number of night shifts (upper limit). This figure shows an example in which total working hours (upper limit) has been selected. [Figure 8] 8 is a diagram showing an example of displaying, in a colored manner, operations that violate the three types of constraints shown in FIGS. 5 to 7 . FIG. [Figure 9] FIG. 13 is a diagram showing an example of replacing the colored task (route) with an unassigned task (route). [Figure 10] A diagram showing an example of swapping the tasks (route) of the colored areas. [Figure 11] FIG. 13 is a diagram showing an example of exchanging with an unassigned route. [Figure 12] FIG. 13 is a diagram showing an example of exchanging work of different workers. [Figure 13A] FIG. 13 is a diagram showing an example of setting initial values ​​of weights of new constraints when replacing a plurality of operations. [Figure 13B] FIG. 13 is a diagram showing an example of collectively correcting the weights of learned constraints when replacing multiple tasks. [Figure 14A] FIG. 2 is a diagram showing an example of a candidate plan provided from the plan generating device 1 to the plan management device 2. [Figure 14B] 13 is a diagram showing a portion detected by the plan evaluation unit 31 as violating a constraint of type A. [Figure 15] FIG. 13 is a diagram showing an example of updating the first constraint list. [Figure 16A] FIG. 2 is a diagram showing an example of a candidate plan provided from the plan generating device 1 to the plan management device 2. [Figure 16B] 16B is a diagram showing a portion detected by the plan evaluation unit 31 as violating the constraint of type B in the candidate plan of FIG. 16A. [Figure 17] FIG. 13 is a diagram showing an example of updating the first constraint list. [Figure 18A] FIG. 2 is a diagram showing an example of a candidate plan provided from the plan generating device 1 to the plan management device 2. [Figure 18B]18B is a diagram showing a portion detected by the plan evaluation unit 31 as violating the constraint of type C in the candidate plan of FIG. 18A. [Figure 19] FIG. 13 is a diagram showing an example of updating the first constraint list. [Figure 20A] FIG. 2 is a diagram showing an example of a candidate plan provided from the plan generating device 1 to the plan management device 2. [Figure 20B] 20B is a diagram showing a portion detected by the plan evaluation unit 31 as violating the constraint of type D in the candidate plan of FIG. 20A. [Figure 21] FIG. 13 is a diagram showing an example of updating the first constraint list. [Figure 22] 11 is a flowchart of an example of processing of the planning system according to the embodiment. [Figure 23] FIG. 2 is a diagram showing a hardware configuration of the plan generating device 1 or the plan managing device 2 in FIG. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0012] Hereinafter, an embodiment of an information processing device, an information processing method, and a program will be described with reference to the drawings. The following description will focus on the main components of the information processing device, but the information processing device may include components and functions that are not shown or described. The following description does not exclude components and functions that are not shown or described.

[0013] Hereinafter, an embodiment of the present invention will be described with reference to the drawings.

[0014] 1 is a block diagram showing a planning system according to an embodiment of the present invention, which includes a plan generating device 1, which is an example of an information processing device according to the present embodiment, and a plan managing device 2.

[0015] The outline of the planning system in FIG. 1 will be described. The plan generation device 1 generates a candidate plan for work to be performed by a worker based on constraint information including at least one constraint condition (first constraint condition) related to the work to be assigned to the worker. The generated candidate plan is provided to the plan management device 2. The plan management device 2 determines whether there is a constraint violation in the candidate plan, and if there is a constraint violation, feeds back constraint violation information including the contents of the constraint violation to the plan generation device 1. The plan generation device 1 converts the constraint violation information fed back from the plan management device 2 into constraint conditions that can be interpreted by the planning system, and updates the above-mentioned constraint information (learns constraint conditions) based on the converted constraint conditions. The plan generation device 1 generates a final work plan by repeating the generation of the candidate plan and the update of the constraint information (learns constraint conditions). As a result, even if there are changes, additions, deletions, etc. of constraints in the field, or even if there are a wide variety of constraints in the field, a general-purpose system that easily generates a plan that satisfies the constraints in the field as much as possible can be realized. The planning system in FIG. 1 will be described in detail below.

[0016] The plan generating device 1 includes an input unit 10, a work data storage unit 11, a reservation data storage unit 12, an initial plan storage unit 13, an initial constraint condition storage unit 14, a constraint condition storage unit (first storage unit) 15, a plan storage unit 16, a plan generating unit 17, a constraint condition acquisition unit 25, a constraint condition comparison unit 21, and an update unit 26. The constraint condition acquisition unit 25 includes a violation information primary storage unit 18, a violation information conversion unit 19, a second constraint condition primary storage unit (second storage unit) 20, and a third constraint condition primary storage unit (third storage unit) 27. The update unit 26 includes a constraint condition addition unit 22 and a weight change unit 23.

[0017] The plan generation unit 17 generates candidate plans by allocating work for one or more days (time periods) to at least one worker (staff member) based on the data stored in the work data storage unit 11, the reservation data storage unit 12, the initial plan storage unit 13, the initial constraint condition storage unit 14, and the constraint condition storage unit 15. An example of a plan to be generated is the work plan of the train crew mentioned above.

[0018] Figure 2 shows an example of a crew work plan. In the work plan, work is assigned to each crew member for each day (time period). Here, "route" indicates one shift of work on the relevant day, and corresponds to the work to be assigned to the worker. "Annual leave" indicates paid leave, and "holiday" indicates a regular day off. There may be other types of holidays, such as "public holiday" and "special holiday."

[0019] The definition data for each task stored in the task data storage unit 11 includes attribute information, including ID information that can uniquely identify the task. FIG. 3 shows a specific example of route definition data. Items indicating values ​​of multiple attributes are included, such as day off, work type, working hours, work start time, work end time, rest time, type of train to be boarded, and train route. "Day off: NO" indicates that it is not a day off for the crew. The illustrated attribute set is an example, and other attribute information may be included, or some of the attribute information shown in FIG. 3 may not exist. Among the multiple routes shown in FIG. 2, routes with the same number (ID) mean that the values ​​of each item in FIG. 3 are the same.

[0020] In the present embodiment, the plan to be generated is not limited to a crew member's work schedule, but may be a plan that is generated by so-called shift scheduling, in which a set of tasks to be completed each day (each time period) is given and tasks are assigned to each worker. For example, in the fields of manufacturing planning and construction work, the plan may be a plan to assign workers to tasks to be completed in each time period. In the fields of medical care and nursing care, the plan may be a plan in which tasks to be performed in each time period (checks, treatment of patients, etc.) are determined in advance and each task is assigned to each worker according to the qualifications and attendance schedule of each worker. In addition, the plan may be a plan in which there are multiple types of tasks in a store and workers are assigned to each task. In the field of education, the plan may be a plan in which available teachers are assigned to each time period (timetable). The type of attribute information varies depending on the type of task to be generated.

[0021] The input unit 10 is an input device that inputs data to be stored in at least one of the storage units 11 to 15. As an example, the input unit 10 may be a device operated by a user of the present system, such as a mouse, a keyboard, or a touch panel. Alternatively, the input unit 10 may be a device into which the user inputs information by voice, gesture, or the like. Alternatively, the input unit 10 may be a communication device that receives data from an external device (such as a server, a terminal, or a storage) via a wired or wireless communication network (not shown) and inputs the received data into at least one of the storage units 11 to 15.

[0022] The work data storage unit 11 stores work data including the work to be completed on each day (each time period). The work data storage unit 11 is configured, for example, as a database (DB) or a list. The work data storage unit 11 stores a set of multiple works that must be completed for each day (each time period) of the period for which the plan is generated. The work data storage unit 11 also stores definition data for each work. For each time period of the period for which the plan is generated, a worker (a crew member in the case of a railway) must be assigned to each of the works that must be completed.

[0023] The reservation data storage unit 12 stores reservation data including work and rest days previously assigned to each worker. The reservation data storage unit 12 is, for example, configured with a database (DB) or a list. When generating a plan, it is necessary to observe the allocation indicated in the reservation data. It is also possible to generate a plan without using the reservation data. In this case, the reservation data storage unit 12 is not necessary.

[0024] The initial plan storage unit 13 stores an initial plan in which workers are assigned to all tasks that must be performed for each time period during the period for which the plan is to be generated. The initial plan storage unit 13 is, for example, configured with a database (DB) or a list. The initial plan may be a plan manually generated by a user, a plan in which tasks are randomly assigned to each worker, or a plan generated in some other way. It is also possible to generate a plan from scratch without using an initial plan.

[0025] The initial constraint condition storage unit 14 stores predetermined constraint conditions (initial constraint conditions) related to work to be assigned to workers (crew members, etc.). The initial constraint condition storage unit 14 is, for example, configured with a database (DB) or a list. A weight is set for each constraint condition. A simple example of a constraint condition is a constraint condition that prohibits the assignment of a route to a crew member on holiday days such as "annual leave" and "holiday". There are various types of constraint conditions. Details of the constraint conditions will be described later.

[0026] The constraint condition storage unit (first storage unit) 15 stores the constraint conditions (first constraint conditions) learned by this system. The constraint condition storage unit 15 is configured, for example, with a database (DB) or a list. In the initial state, the constraint condition storage unit 15 may not yet store any constraint conditions. A weight is set to each constraint condition. The list that stores the constraint conditions stored in the constraint condition storage unit 15 is called a first constraint condition list.

[0027] The set of constraint conditions stored in the constraint condition storage unit 15 corresponds to the first constraint conditions. The constraint information may be defined so as to include the initial constraint conditions stored in the initial constraint condition storage unit 14.

[0028] The plan generation unit 17 generates a candidate plan in which work (routes, etc.) to be performed on each day (each time period) is assigned to multiple workers based on the data stored in the work data storage unit 11, the reservation data storage unit 12, and the initial plan storage unit 13, and the constraint conditions stored in the initial constraint condition storage unit 14 and the constraint condition storage unit 15. The plan generation unit 17 stores the generated candidate plan in the plan storage unit 16. In addition, the plan generation unit 17 provides the generated candidate plan to the plan management device 2.

[0029] The algorithm by which the plan generating unit 17 generates a plan utilizes a known method capable of handling the soft constraint conditions described above. An example of the definition as an optimization problem will be described below. Depending on the type of each constraint condition stored in the storage units 14 and 15, a penalty according to the degree of violation of the constraint condition and a weight according to the importance of the constraint condition are defined. The problem is defined as a weighted constraint satisfaction problem that minimizes the weighted sum of the penalties, and this problem is solved as a combinatorial optimization problem. Methods for solving combinatorial optimization problems include a construction method and a sequential improvement method. The construction method is a method of sequentially allocating tasks (paths) that satisfy the constraints. The sequential method is a method (such as steepest descent method, tabu search, genetic algorithm, and simulated annealing) in which the plan is repeatedly modified and internally evaluated. There are various other solution methods, but they are not limited here.

[0030] A specific example of the solution method in this embodiment will be described below. Symbols are defined as follows. Ck: Constraints p k (x): Penalty according to the degree of violation of the kth constraint (0 when the constraint is satisfied) W k : Weight according to the importance of the constraint (>=0) x: variable, x=(x 1,m1,j1 ,…, x d,m,j,…, x D,M,J )(∀d∈D, ∀j∈J(d)),x d,m,j ∈{0,1} D: Set of days (time slots) M: Gathering of workers J: A set of tasks (route, etc.) to be assigned J(d): A set of tasks to be assigned on a day (time period) d∈D (⊆J). The task j(d) to be assigned is different for each d. p(x): weighted sum of penalties, P(x)=Σw k p k (x)

[0031] Variable x d,m,jtakes the value of 0 or 1. When task j ∈ J(d) on day (time period) d ∈ D is assigned to worker m ∈ M, variable x d,m,j = 1, otherwise variable x d,m,j =0.

[0032] Let P(x) be the objective function, and the problem of minimizing the objective function is defined as follows:

number

[0033] The basic constraints for solving the problem of minimizing the objective function P(x) are given below.

number

number

number

[0034] Formula (2) is a constraint that requires that each task to be assigned on each day (each time period) must be assigned to exactly one worker.

[0035] Equation (3) is a constraint that each worker is assigned either one task per day (time slot), or none (there may be days (time slots) when there is no work).

[0036] Formula (4) defines a set C1 ⊆ D×M×J that represents the tasks that must be assigned to a worker on a certain day (time period), and a set C2 ⊆ D×M×J that represents the tasks that must not be assigned to a worker on a certain day (time period), and sets C1 and C2 are constraints. Only one of sets C1 and C2 may be defined.

[0037] The objective function P(x) is minimized or quasi-minimized under the basic constraints of equations (1) to (4) to minimize the variable x d,m,jis calculated. This allows tasks for each day (each time period) to be assigned to multiple workers. When solving the objective function, an efficient search is possible by starting from an initial plan and then processing to modify the initial plan. However, it is also possible that no initial plan exists and a plan is created from scratch. In this case, the initial plan storage unit 13 is not necessary. If there is a time limit for the search, starting from the initial plan can increase the possibility of minimizing or quasi-minimizing within the time limit.

[0038] The initial constraints and the constraints included in the first constraint list (learned constraints) are reflected in the objective function P(x). Each time a constraint is added to the first constraint list, optimization is performed to minimize or quasi-minimize the objective function P(x) reflecting the added constraints. The penalty (also called a penalty function) p k Details of (x) will be described later.

[0039] The plan management device 2 includes a plan evaluation unit 31, a plan update unit 32, and an input / output unit (user interface unit) 33. The input / output unit 33 includes an input device (operation device) operated by a user of the present system, and an output device that presents information to the user of the present system. An example of the input device is the same as the input unit 10 of the plan generation device 1. An example of the output device is a display device such as a liquid crystal display device, an organic EL display device, a plasma display device, or a CRT display device. Alternatively, the output device may be a VR (Virtual Reality) head mount or AR (Augumented Reality) glasses. The input / output unit 33 allows a user to check for constraint violations of the candidate plan. The input / output unit 33 outputs constraint violation information including at least one of the worker and date and time when a constraint violation of the candidate plan occurred and the type of the violated constraint.

[0040] The plan evaluation unit 31 checks whether or not there is a constraint violation in the candidate plan provided from the plan generation unit 17 (constraint violation check). The plan update unit 32 has a user interface function that allows the user to partially correct the given candidate plan by an operation such as exchanging tasks between workers.

[0041] A first method of checking for constraint violation is to check whether various constraints given in advance are satisfied by executing a computer program. That is, the plan evaluation unit 31 has a function of checking whether the constraints are satisfied. In this case, the plan evaluation unit 31 may execute a program that judges whether each constraint rule is satisfied based on a plurality of rules (constraint rules) including the contents of the constraints. The constraint rules may be set in a storage device by a user using the input / output unit 33, and the set constraint rules may be read out. The plan evaluation unit 31 identifies constraints that are violated (not satisfied) by the candidate plan as constraint violation information, and provides (feeds back) it to the plan generation device 1.

[0042] As a second method of checking for constraint violations, a user may check a candidate plan on a display device or the like, detect whether there is a part that does not satisfy a constraint, and input the constraint that is not satisfied by the detected part as constraint violation information using the input / output unit 33. In this case, the plan evaluation unit 31 provides (feeds back) the constraint violation information input by the user to the plan generation device 1.

[0043] The second method of constraint violation checking will be described in detail below using a specific example. Figs. 4 to 11 are diagrams showing examples of screen displays on a display device provided in the input / output unit 33. Figs. 4 to 11 are diagrams showing the allocation of tasks to workers A to L on a daily basis. The tasks in Figs. 4 to 11 are, for example, the routes of trains on which each worker (specifically, each crew member) rides. The numerical values ​​in Figs. 4 to 11 are identification information for the tasks (routes).

[0044] First, as shown in the example screen of Fig. 4, the tasks (e.g., routes) in the candidate plan that violate the constraints that have already been learned (constraints that have been added to the constraint storage unit 15) are colored to draw the user's attention. In Fig. 4, the parts (tasks) to be colored are displayed in gray for convenience.

[0045] Next, the system narrows down and displays the options for the types (classifications) of applicable constraints according to the type and number of tasks selected by the user, as shown in the example screens in Figures 5 to 7. By the user selecting one of the constraint types from these options, a constraint violation check can be performed with a minimum of operations.

[0046] Figure 5 shows an example where there are two options for constraint types, sequence of work conditions and sequence of work, and the sequence of work is selected. In the example of Figure 5, the sequence of work is prohibited, so the part selected by the user as a constraint violation is displayed in color.

[0047] Figure 6 shows an example where there are three options for constraint types: driving qualification, work qualification, and driving experience, and driving qualification is selected. In the example in Figure 6, driving qualification is prohibited, so the part selected by the user as a constraint violation is displayed in color.

[0048] Figure 7 shows an example in which the user has selected the sum of working hours (upper limit) from the four constraint types: sum of working hours (lower limit), number of public holidays (lower limit), and number of night shifts (upper limit). In the example in Figure 7, the user has selected all candidate plans for workers whose sum of working hours exceeds the upper limit as constraint violations, and the selected areas are displayed in color.

[0049] Figure 8 shows an example in which operations that violate the three types of constraints shown in Figures 5 to 7 are displayed together in color. As shown in Figure 8, operations that violate multiple types of constraints may be displayed together on the same screen, or, as shown in Figures 5 to 7, operations that violate each type of constraint may be displayed on a separate screen.

[0050] In addition to the process of checking for constraint violations, the user may also perform an operation to replace the task at the constraint violation location shown in FIGS. 5 to 8 with another task, thereby revising the candidate plan and eliminating the constraint violation.

[0051] Figure 9 shows an example of exchanging an operation (journey) in a constraint violation location with an unassigned operation (journey). In Figure 9, a list of unassigned operations (journeys) on the relevant day (11 / 5) that can be exchanged with journey 30 is displayed, and one of the operations (journeys) is selected from this list. Specifically, Figure 9 shows an example of exchanging journey 30 with journey 47 in the list.

[0052] Fig. 10 is a diagram showing an example of resolving constraint violations by exchanging the tasks (paths) shown in the colored areas. Fig. 10 shows an example of exchanging path 15 of worker B with path 30 of worker L.

[0053] The plan generating device 1 according to this embodiment performs a constraint violation check using the above-mentioned first method and second method, or performs a constraint violation check using only the second method.

[0054] The types of constraints checked in the constraint violation check include some or all of the following four types. The plan management device 2 provides (feeds back) to the plan generation device 1 information on the type of constraint that has been violated and the location of the violation (the combination of the violated day (time frame) and worker) as constraint violation information. Also, after the user updates a candidate plan by exchanging the allocation of multiple tasks, a constraint violation check is performed on the updated plan in addition to the constraint violation information before the update, and if a new constraint violation has occurred, information on the type of constraint that has been violated and the location of the violation (the combination of the violated day (time frame) and worker) is provided (feedback) to the plan generation device 1 as constraint violation information.

[0055] (A) A constraint that prohibits a particular ordering of tasks assigned to the same worker. (B) Constraints that prohibit the combination of a worker's qualifications and experience with certain attributes of a task. (C) A constraint that specifies at least one of an upper limit and a lower limit of the sum of specific attribute values ​​of operations assigned to the same worker during a period. (D) A constraint that prohibits a specific ordering of the attributes of tasks assigned to the same worker.

[0056] Type A constraints are constraints on the arrangement of multiple tasks (including holidays, etc.) assigned to the same worker. The plan evaluation unit 31 or the user checks for violations in the arrangement of tasks in the candidate plan using a judgment logic that takes into account various connection conditions between multiple tasks, such as the need to take a certain amount of time to rest at home, restrictions on the combination of work start times and work end times before and after holidays, and the prohibition of consecutive long work hours. The connection conditions between multiple tasks are not themselves fed back to the plan generation device 1.

[0057] The constraints of type B are explained using an example of a crew plan. For example, the types of vehicles that a crew member can drive may be limited by their qualifications. In addition, there are cases where the crew member must have the qualifications necessary for tasks such as ticket checking during the ride, and there are also cases where the crew member must have driving experience on the route included in the journey.

[0058] Specific examples of type C constraints include, for example, a constraint that the total work hours within a certain period do not exceed a specified upper limit, a constraint that the total work hours within a certain period are equal to or greater than a specified lower limit, and a constraint that the legally specified number of days off are taken within a certain period. The upper limit and lower limit correspond to boundary values ​​that define the constraint. In the case of type C constraints, the plan evaluation unit 31 also provides (feeds back) to the plan generation device 1 information identifying whether the constraint is restricting an upper limit or a lower limit as information on the type of constraint that has been violated.

[0059] Specific examples of type D constraints include a constraint that the work type "late night" must not occur a certain number of times consecutively, and a constraint that "late night" and "early morning" must not occur consecutively.

[0060] The constraint condition acquisition unit 25 acquires constraint violation information that is determined not to be satisfied by the candidate plan from the plan management device 2. The violation information primary storage unit 18 stores the acquired constraint violation information. The violation information conversion unit 19 reads out the constraint violation information stored in the violation information primary storage unit 18, converts it into a format that can be interpreted by the present plan system, and stores the converted information in the second constraint condition primary storage unit 20 as a second constraint condition. The constraint violation information stored in the violation information conversion unit 19 may be erased or overwritten the next time it is written to the violation information primary storage unit 18. A list including a set of second constraint conditions stored in the second constraint condition primary storage unit 20 is called a second constraint condition list. Furthermore, the violation information conversion unit 19 generates a third constraint condition related to the work based on a new constraint violation generated by the exchange of the allocation of multiple works.

[0061] The constraint condition comparison unit 21 reads out the second constraint condition list from the second constraint condition primary storage unit 20. After reading out the second constraint condition list, the constraint condition comparison unit 21 may erase the second constraint condition list stored in the second constraint condition primary storage unit 20. Alternatively, the second constraint condition list may be overwritten the next time data is written to the second constraint condition primary storage unit 20.

[0062] The constraint condition comparison unit 21 compares the constraint conditions in the second constraint condition list with each constraint condition included in the first constraint condition list in the constraint condition storage unit 15. If the same constraint condition as the constraint condition in the second constraint condition list is not included in the first constraint condition list, the constraint condition addition unit 22 adds the constraint condition to the first constraint condition list as a new constraint condition. The constraint condition addition unit 22 sets an initial weight for the constraint condition, associates the set weight with the constraint condition, and adds the constraint condition to the first constraint condition list. The weight may be a predetermined value, or the plan management device 2 may feed back the weight together with constraint violation information and use the fed back weight. The weight may be determined by other methods. The weight is a type of learning parameter, and may be tuned in advance through actual cases.

[0063] On the other hand, if the first constraint condition list contains the same constraint condition as the second constraint condition in the second constraint condition list, the weight change unit 23 changes the weight of the constraint condition contained in the first constraint condition list. For example, the weight is changed by adding a certain value or multiplying it by a certain value. The weight value may be changed using the number of times the weight is updated. For example, the value to be added may be made smaller or larger as the number of times the weight is changed increases. The weight may be changed by other methods. If the type of constraint is C, and the constraint is about the sum of attribute values ​​in a period of the same length as the constraint condition in the second constraint condition list, and only the boundary value (upper or lower limit) is different, the boundary value of the constraint condition contained in the first constraint condition list is updated by the boundary value contained in the constraint condition in the second constraint condition list, and the weight of the constraint condition is also updated. There may be a case where only the boundary value is updated.

[0064] As shown in Figures 9 and 10 above, when a user performs an operation to eliminate a constraint violation by partially modifying a candidate plan by exchanging tasks, it is possible to learn the magnitude relationship of the "weights" of soft constraints based on the content of the user's operation.

[0065] For example, suppose that the user performs the exchange operation shown in Figure 9 to resolve a constraint violation (the sequence of route 30 → route 13). If a new constraint violation occurs due to the sequence "47 → 13" as shown in Figure 11 after this exchange operation, it is possible to interpret that the user recognizes that the weight of the constraint violation "30 → 13" is greater than the weight of the constraint violation "47 → 13", and use this information to modify the weight of "30 → 13" from the initial setting. For example, if "30 → 13" is a point that has been pointed out as a new constraint violation and "47 → 13" is an already learned constraint, the current weight of 47 → 13 can be increased by a certain amount to become the initial weight of the new constraint "30 → 13".

[0066] Furthermore, if both the constraint violations before and after the replacement (in the example of FIG. 11, "30→13" and "47→13") are learned constraints, the weights of both constraints before and after the replacement may be simultaneously corrected so as to satisfy the magnitude relationship. For example, possible methods include adding a fixed amount to the current weight of "47→13" to correct the weight of "30→13", or conversely, subtracting a fixed amount from the current weight of "30→13" to correct it to "47→13", but the present embodiment does not limit the specific calculation method.

[0067] Suppose the user performs the exchange operation shown in Fig. 10 to resolve a constraint violation (the sequence of route 30 → route 13). If after the exchange operation, a new constraint violation occurs due to the sequence "41 → 30" at the exchange destination as shown in Fig. 12, it is interpreted that the user recognizes that the weight of the constraint violation "30 → 13" is greater than the weight of the constraint violation "41 → 30", and it is possible to use this information to initially set or modify the weight of "30 → 13" as in the previous example. Also, if both "30 → 13" and "41 → 30" are already learned constraints, it is possible to simultaneously modify the weights of both so that they satisfy the magnitude relationship.

[0068] When a user resolves a constraint violation by exchanging tasks, if the user exchanges assigned routes, the user may exchange multiple locations (three or more locations) at the same time. In this case, the user can obtain information on the relationship between the weights of the constraints recognized by the user by comparing the relationship between the sums of the weights of the violated constraints before and after the exchange operation for the exchanged locations.

[0069] For example, in the example of Figure 13A, suppose that by swapping multiple tasks (routes), the number of constraint violations has increased from 2 before the swap to 3. In this case, if the weight of the new constraint "30 → 13" is set to x and the weights of the other four constraints are set to their current values, the user is likely to recognize that the sum of the weights of the constraint violations after the swap is smaller than the sum of the weights of the constraint violations before the swap, and in this example, it can be interpreted that X+2>2+2+3 holds, and an initial value of 5 or more can be set for x.

[0070] In the example of Figure 13B, if all constraint violations before and after the replacement are learned constraints, for example, a correction coefficient k is introduced and set so that the inequality holds, and the weights of the constraints of the constraint violations that appeared after the replacement operation are updated evenly by prorating them by multiplying them by a correction coefficient k whose value is less than or equal to (4 + 3) / (2 + 1 + 3). In this embodiment, the specific calculation method for updating these weights is not limited.

[0071] Below, some specific examples of updating the constraints in the first constraint list based on the constraint violation information fed back from the plan management device 2 will be described.

[0072] [First example] Fig. 14A is a diagram showing an example of a candidate plan provided from the plan generating device 1 to the plan management device 2. Fig. 14B is a diagram showing a portion detected by the plan evaluation unit 31 as violating the constraint of type A in the candidate plan of Fig. 14A. The detected portion is surrounded by a dashed frame.

[0073] The plan evaluation unit 31 judges whether there is a part (case) that violates the constraint in the candidate plan in Fig. 14A. In this example, two cases, "Journey 5 → Journey 3" and "Journey → Public Holiday → Journey 6" shown in Fig. 14B, are detected as violating the constraint.

[0074] The constraint condition acquisition unit 25 of the plan generation device 1 acquires constraint violation information regarding violations of the two constraints from the plan management device 2. The constraint condition acquisition unit 25 converts the constraint violation information into a format that can be interpreted by the plan generation device 1, and provides the constraint condition comparison unit 21 with a second constraint condition list including the two constraint conditions.

[0075] The constraint comparison unit 21 compares each constraint condition included in the second constraint condition list with the constraint condition included in the first constraint condition list to determine whether they are the same. If a constraint condition included in the second constraint condition list is different from a constraint condition included in the first constraint condition list, the constraint condition is added to the first constraint condition list. An initial weight is set for the constraint condition to be added. If a constraint condition included in the second constraint condition list is the same as a constraint condition included in the first constraint condition list, the weight of the constraint condition in the first constraint condition list is changed.

[0076] Fig. 15 is a diagram showing an example of updating the first constraint list. As shown on the right side of Fig. 15, the first constraint list before the update stores a constraint that prohibits "route 5 → route 3" and a constraint that prohibits "route 9 → route 5". The weights for both are 0.5. Other constraints are also stored, but are not shown in the figure.

[0077] As shown in the center of Figure 15, the constraint violation information fed back from the plan management device 2 shows a constraint that prohibits "Journey 5 → Journey 3" and a constraint that prohibits "Journey 4 → Public holiday → Journey 6".

[0078] The fed back "route 5 → route 3" is the same as "route 5 → route 3" included in the first constraint list. Therefore, as shown on the left side of Figure 15, 0.1 is added to the weight of "route 5 → route 3" in the first constraint list, making it 0.6.

[0079] The fed back "Route 4 → Public Holiday → Route 6" is not included in the first constraint list. Therefore, as shown on the left side of Figure 15, "Route 4 → Public Holiday → Route 6" is associated with an initial weight of 0.5 and added to the first constraint list as a new constraint.

[0080] [Second example] Fig. 16A is a diagram showing an example of a candidate plan provided from the plan generation device 1 to the plan management device 2. Fig. 16B is a diagram showing a portion detected by the plan evaluation unit 31 as violating the constraints of type B in the candidate plan of Fig. 16A. The detected portion is surrounded by a dashed frame. The vehicle type in Figs. 16A and 16B is assumed to be one of the attributes of the work (route).

[0081] In this example, the days when crew member 2 is assigned route 3, which involves working on a train, and the days when crew member 2 is assigned route 5, which involves working on a diesel locomotive (car D), are detected as constraint violations.

[0082] Fig. 17 is a diagram showing an example of an update of the first constraint list. As shown in the upper right of Fig. 17, the first constraint list before the update stores a constraint that prohibits "Crew 1 & train (Crew 2 working on a train)" and a constraint that prohibits "Crew 2 & car D (Crew 2 working on a diesel locomotive (car D))." The weights for both are 0.5. Other constraints are also stored, but are not shown in the figure.

[0083] As shown in the center of FIG. 17, the constraint violation information fed back from the plan management device 2 shows a constraint prohibiting "Crew 2 & train" and a constraint prohibiting "Crew 2 & D car".

[0084] The fed back "Crew 2 & D car" is the same as "Crew 2 & D car" included in the first constraint condition list. Therefore, as shown on the left side of Figure 17, the weight of "Crew 2 & D car" in the first constraint condition list is increased by 0.1 to 0.6.

[0085] The fed back "Crew 1 & Train" is not included in the first constraint list. Therefore, as shown on the left side of Figure 17, "Crew 1 & Train" is added to the first constraint list as a new constraint. The initial weight of "Crew 1 & Train" is set to 0.5.

[0086] [Third example] Fig. 18A is a diagram showing an example of a candidate plan provided from the plan generation device 1 to the plan management device 2. Fig. 18B is a diagram showing a portion detected by the plan evaluation unit 31 as violating the constraint of type C in the candidate plan of Fig. 18A. The detected portion is surrounded by a dashed frame. In Fig. 18, work (working hours) is assumed to be one of the attributes of a task (route).

[0087] The plan evaluation unit 31 detects a portion indicated by a dotted frame in FIG. 16B as not satisfying the constraints.

[0088] 19 is a diagram showing an example of updating the first constraint list. As shown in the upper right corner of FIG. 19, the first constraint list before the update includes “Σ 8 d=1 The constraint that requires working hours d<60 and Σ 8 d=1 The constraint that requires "public holiday > 1" is stored. 8 d=1 "Working hours d<60" requires that the total working hours over eight days be less than 60 hours. In other words, it prohibits the total working hours over eight days from exceeding 60 hours. "Σ 8 d=1 "Public Holiday > 1" requires that the number of public holidays be more than one in an eight-day period. In other words, it prohibits the number of public holidays from being less than one in an eight-day period. Other constraints are also stored, but are not shown in the figure.

[0089] As shown in the lower right of FIG. 19, the constraint violation information fed back from the plan management device 2 is “Σ 8 d=1 "Working hours d<56" is shown. The boundary value (56 in this example) is the sum of the target attribute values ​​of the parts in the candidate plan that are determined to violate the constraint of type C, and corresponds to the total working hours of crew member 2 over 8 days in FIG. 18(B), 56.

[0090] The feedback "Σ 8 d=1 Working hours d<56 is included in the first constraint list. 8 d=1Like "working hours d<60," this is a constraint that limits the upper limit of the total working hours over eight days, and only the boundary value (60 in this example) is different. Therefore, as shown on the left in Figure 19, "Σ 8 d=1 The boundary value of 60 for "Working hours d<60" is changed to 56. Also, 0.1 is added to the weight to make it 0.6. In this example, the boundary value of the constraint condition is changed, but it is also possible to add a constraint condition with a different boundary value as a new constraint condition. In this case, an initial weight (for example, 0.5) is set for the new constraint condition. Also, a method is possible in which only the boundary value is changed and the weight is not changed.

[0091] [Example 4] Fig. 20A is a diagram showing an example of a candidate plan provided from the plan generation device 1 to the plan management device 2. Fig. 20B is a diagram showing a portion detected by the plan evaluation unit 31 as violating the constraint of type D in the candidate plan of Fig. 20A. The detected portion is surrounded by a dashed frame. In Fig. 20, the work type, such as day shift, late night, or early morning, is considered to be one of the attributes of the work (route).

[0092] Fig. 21 is a diagram showing an example of updating the first constraint list. As shown in the upper right of Fig. 21, the first constraint list before the update stores a constraint that prohibits "late night → late night". The weight is 0.5. Other constraints are also stored, but are not shown in the figure.

[0093] As shown in the lower right of FIG. 21, the constraint conditions fed back from the plan management device 2 include a constraint condition that prohibits "late night to late night" and a constraint condition that prohibits "late night to early morning".

[0094] The fed back "late night → late night" is the same as "late night → late night" included in the first constraint condition list. Therefore, as shown on the left in Fig. 21, the weight of "late night → late night" in the first constraint condition list is increased by 0.1 to 0.6.

[0095] The fed back "late night → early morning" is not included in the first constraint list. Therefore, "late night → early morning" is added to the first constraint list as a new constraint, as shown on the left in Figure 21. The initial weight of "late night → early morning" is set to 0.5.

[0096] Here, a specific example will be given of formulating the penalty function of the above-mentioned equation (1) based on the constraints included in the first constraint list.

[0097] [Type A constraint]

number

[0098] The kth constraint (k∈K1) allows every worker to k +1) operations in a specific order (j k (0), j k (1), …, j k (T k )) to prohibit allocation. K1 is the number of constraints of the same type, k is the ID of the constraint, and T k denotes the number of permutations that constraint k prohibits.

[0099] [Type B constraint]

number

[0100] Let j be a set of jobs with a specific attribute M k Prohibits the assignment to workers included in the flag (α 1j , α 2j , …, α Kj ) indicates whether the task j corresponds to the attribute targeted by the constraint k. kj If =1, then α kj = 0 indicates non-applicability. K2 is the number of constraints of the same type, and k is the ID of the constraint.

[0101] [Type C constraint (limiting the upper limit)]

number

[0102] Use either formula (7) or formula (7'). k T assigned from k +1 operation, their attribute α kj The sum of b is k This is a constraint that prohibits the value of α from exceeding α. kj is the value of the attribute targeted by constraint k in task j. K3 is the number of constraints of the same type, and k is the ID of the constraint.

[0103] [Example 4] [Type C constraint (when restricting the lower limit)]

number

[0104] Use either equation (8) or equation (8'). k T assigned from k +1 job, their attribute α kj The sum of b is k It is prohibited to go below α kj is the value of the attribute targeted by constraint k in job j. K4 is the number of constraints of the same type, and k is the ID of the constraint.

[0105] [Type D Constraint]

number

[0106] For every worker, k +1 task is flagged as α kj(t) The attribute flags (α 1j (0), α 1j (1),…,α 1j (T1),…,α Kj (0), α Kj (1),…,αKj (T K )) indicates whether the task j corresponds to the t-th attribute in the list of attributes prohibited by the constraint k. kj(t) If =1, then α Kj(t) If =0, it is not applicable. K5 is the number of constraints of the same type, k is the constraint ID, and T k denotes the number of permutations that constraint k prohibits.

[0107] Fig. 22 is a flowchart of an example of processing of the planning system according to this embodiment. The plan generation unit 17 reads out a list of tasks to be assigned to each day (task data) from the task data storage unit 11, and reads out reservation information for holidays such as annual leave and tasks for which assignment has already been decided from the reservation data storage unit 12 (step S1). It also reads out an initial plan from the initial plan storage unit 13, and reads out pre-set constraint conditions (initial constraint conditions) from the initial constraint condition storage unit 14. The data read out in step S1 is collectively called initial data.

[0108] Next, the plan generating unit 17 reads out a first constraint list including the learned constraints (first constraints) from the constraint storage unit 15 (step S2).

[0109] Next, the plan generating unit 17 generates a candidate plan based on the initial constraint conditions, the constraint conditions in the first constraint condition list, and the data read in step S1 (step S3). The plan generating unit 17 sends the candidate plan data and a check request to check whether or not there is a constraint violation in the candidate plan data to the plan management device 2.

[0110] Based on the check request, the plan management device 2 performs a constraint violation check on the candidate plan (step S4). As an example, the user checks the candidate plan displayed on the input / output unit 33 using the method described above, checks the violation points that do not satisfy the constraints, and inputs the type of constraint that the violation points violate. In this case, the plan evaluation unit 31 feeds back constraint violation information including the new constraint input by the user to the plan generation device 1. Furthermore, if the user partially corrects the work by the above-mentioned replacement operation, constraint violation information that appears after the correction operation is also fed back to the plan generation device 1.

[0111] The violation information conversion unit 19 converts the constraint violation information for the candidate plan fed back from the plan management device 2 into second constraint conditions in a format that can be interpreted by the plan generation device 1, and generates a second constraint condition list including the second constraint conditions (step S5).

[0112] It is determined whether the user has partially modified the work by the above-mentioned replacement operation (step S6). If the user has partially modified the work (YES in step S6), the constraint violation information that appears after the modification operation is converted into a third constraint condition in a format that can be interpreted by the plan generating device 1, and a third constraint condition list including the third constraint condition is generated (step S7).

[0113] Next, the constraint comparison unit 21 sequentially compares the second constraints in the second constraint list with the first constraints in the first constraint list (step S8). It is determined whether the second constraint in the second constraint list is the same as the first constraint in the first constraint list, that is, whether it is a constraint that has already been detected in a constraint violation check or a new constraint (step S9).

[0114] If the second constraint condition in the second constraint condition list is not the same as the first constraint condition included in the first constraint condition list, that is, if it is a new constraint condition, an initial weight is set for the new constraint condition (step S10). In this case, the new contract condition with the initial weight set is added to the first constraint condition list. When setting the initial weight, if a third constraint condition list exists, it is added with the initial weight calculated by a comparison operation between the second constraint condition list and the third constraint condition list.

[0115] If the constraint condition in the second constraint condition list is the same as the constraint condition included in the first constraint condition list, the weight of the constraint condition included in the first constraint condition list is increased. This allows the constraint condition to be more strongly reflected when the plan generation unit 17 generates a candidate plan next time. If a third constraint condition list exists, the weight is corrected to the weight obtained by a comparison operation between the second constraint condition list and the third constraint condition list (step S11). If the constraint condition in the second constraint condition list is type C, is a constraint on the sum of the same attribute value for the same period as the constraint condition included in the first constraint condition list, and only the boundary value is different between the two, the boundary value is updated and the weight is also updated. Specifically, if a violation occurs that exceeds the upper limit value (boundary value) of the sum, the upper limit value of the constraint condition is made smaller than the current state (the constraint is made stricter). Conversely, if a violation occurs that falls below the lower limit value (boundary value) of the sum, the lower limit value of the constraint condition is corrected to be larger than the current state (the constraint is made stricter).

[0116] It is determined whether or not the processing of steps S8 to S11 has been performed for all the second constraint conditions in the second constraint condition list (step S12). If there are any second constraint conditions that have not yet been processed, the processing of steps S8 to S11 is repeated. If the processing of all the second constraint conditions has been performed, it is determined whether or not the termination condition has been satisfied (step S13). If the termination condition has not been satisfied, the process returns to step S3. In step S3 after returning, a new candidate plan is generated using the updated first constraint condition list, and a constraint violation check is performed (steps S3 to S12). Steps S3 to S12 are repeated until the termination condition is satisfied.

[0117] When the termination condition is satisfied, the last generated candidate plan is output as the final plan to the plan management device 2 (step S14). Alternatively, the candidate plan having the smallest objective function value among the candidate plans stored in the plan storage unit 16, or the candidate plan having an objective function value smaller than a threshold value, may be output as the final plan.

[0118] The input / output unit 33 of the plan management device 2 displays the final plan on a display device. The final plan may be stored in a storage device within the plan management device 2 or an external storage device.

[0119] Here, an example of a method for determining the termination condition is shown. When the plan evaluation unit 31 checks for constraint violations by program operation, it may determine that the termination condition is satisfied after steps S3 to S12 are repeated a predetermined number of times. Alternatively, steps S3 to S12 may be repeated until a predetermined time limit is reached, and when the time limit is reached, it may determine that the termination condition is satisfied. Alternatively, steps S3 to S12 may be repeated in a loop until there is no constraint violation, or until the value of the objective function (penalty sum) is equal to or less than a threshold. The success or failure of the termination condition may be determined by other methods. When the user checks for constraint violations using the input / output unit 33 (GUI), the user himself may determine the timing to end the repetition of steps S3 to S12. The user may input instruction data to end the repetition, and the repetition may be ended based on the instruction data.

[0120] As described above, according to this embodiment, the plan management device or the user detects constraints that are violated by the candidate plan generated by the plan generation device 1 as constraint violation information and feeds back the information. The plan generation device accumulates constraint conditions based on the constraint violation information in a first constraint condition list. Specifically, if a constraint condition identical to a constraint condition does not exist in the first constraint condition list, a weight is set for the constraint condition and the constraint condition is added to the first constraint condition list. If a constraint condition identical to a constraint condition exists in the first constraint condition list, the weight of the constraint condition existing in the first constraint condition list is updated. In this way, by repeating the generation of candidate plans, the accumulation of constraint conditions, and the change of the weight of the constraint conditions, a general-purpose planning system that can easily handle changes and additions of constraints on site can be realized.

[0121] For example, when the system is initially introduced or when work regulations are changed, new or changed constraint conditions can be reflected in a format that can be handled by the plan generation device by rewriting the evaluation algorithm or rules of the plan management device 2, improving maintainability. Also, feedback from users at each site makes it possible to gradually adapt to the small differences in constraints at each site.

[0122] (Hardware configuration) Fig. 23 is a diagram showing a hardware configuration of the plan generation device 1 or the plan management device 2 in Fig. 1. The plan generation device 1 or the plan management device 2 in Fig. 1 is configured by a computer device 600. The computer device 600 includes a CPU 601, an input interface 602, a display device 603, a communication device 604, a main storage device 605, and an external storage device 606, which are connected to each other by a bus 607.

[0123] A CPU (Central Processing Unit) 601 executes an information processing program, which is a computer program, on a main memory device 605. The information processing program is a program that realizes each of the above-mentioned functional configurations of the present device. The information processing program may be realized not as a single program, but as a combination of multiple programs and scripts. Each functional configuration is realized by the CPU 601 executing the information processing program.

[0124] The input interface 602 is a circuit for inputting operation signals from input devices such as a keyboard, a mouse, a touch panel, etc. The input interface 602 corresponds to an input unit or an input / output unit.

[0125] The display device 603 displays data output from this device. The display device 603 is, for example, but not limited to, an LCD (liquid crystal display), an organic electroluminescence display, a CRT (cathode ray tube), or a PDP (plasma display). Data output from the computer device 600 can be displayed on this display device 603. The display device 603 corresponds to an input / output unit.

[0126] The communication device 604 is a circuit for the device to communicate with an external device wirelessly or via wire. Data can be input from the external device via the communication device 604. The data input from the external device can be stored in the main memory device 605 or the external memory device 606.

[0127] The main memory device 605 stores an information processing program, data required for executing the information processing program, data generated by executing the information processing program, etc. The information processing program is deployed and executed on the main memory device 605. The main memory device 605 is, for example, a RAM, a DRAM, or an SRAM, but is not limited to these. Each storage unit or database in FIG. 1 may be constructed on the main memory device 605.

[0128] The external storage device 606 stores an information processing program, data required for executing the information processing program, data generated by executing the information processing program, etc. These information processing programs and data are read into the main storage device 605 when the information processing program is executed. The external storage device 606 is, for example, but is not limited to, a hard disk, an optical disk, a flash memory, and a magnetic tape. Each storage unit or database in FIG. 1 may be constructed on the external storage device 606.

[0129] The information processing program may be pre-installed in the computer device 600, or may be stored in a storage medium such as a CD-ROM. The information processing program may also be uploaded onto the Internet.

[0130] Furthermore, this apparatus may be configured as a single computer apparatus 600, or may be configured as a system made up of a plurality of computer apparatuses 600 connected to each other.

[0131] The present invention is not limited to the above-described embodiments as they are, and the components can be modified and embodied in the implementation stage without departing from the gist of the invention. Various inventions can be formed by appropriately combining multiple components disclosed in the above-described embodiments. For example, a configuration in which some components are deleted from all the components shown in each embodiment can also be considered. Furthermore, the components described in different embodiments can be appropriately combined. [Explanation of symbols]

[0132] 1 plan generation device, 2 plan management device, 10 input unit, 11 work data storage unit, 12 reservation data storage unit, 13 initial plan storage unit, 14 initial constraint condition storage unit, 15 constraint condition storage unit, 16 plan storage unit, 17 plan generation unit, 18 violation information primary storage unit, 19 violation information conversion unit, 20 second constraint condition primary storage unit, 21 constraint condition comparison unit, 22 constraint condition addition unit, 23 change unit, 25 constraint condition acquisition unit, 26 update unit, 27 third constraint condition primary storage unit, 31 plan evaluation unit, 32 plan update unit, 33 input / output unit, 600 computer device, 602 input interface, 603 display device, 604 communication device, 605 main memory device, 606 external memory device, 607 bus

Claims

1. a first storage unit configured to store constraint information including a first constraint condition for a candidate plan in which operations to be performed are assigned to a plurality of workers; a user interface unit that allows a user to check for constraint violations for a plurality of workers and allows the user to input constraint violation information including the worker and date and time when a constraint violation of the candidate plan occurred, and the type of the constraint that was violated; a violation information conversion unit that converts the constraint violation information into a second constraint condition related to the work that is in an information processable format; an update unit that updates the constraint information by using the second constraint condition.

2. the update unit compares the second constraint condition with the constraint information and updates the constraint information. The information processing device according to claim 1 .

3. the update unit compares the second constraint condition with the constraint information and adds the second constraint condition not included in the constraint information to the constraint information. The information processing device according to claim 2 .

4. a second storage unit that stores a plurality of the second constraint conditions; 4. The information processing device according to claim 1, further comprising: a condition addition unit that compares the plurality of first constraint conditions stored in the first storage unit with the plurality of second constraint conditions stored in the second storage unit, and causes the second constraint conditions not stored in the first storage unit to be stored in the first storage unit as new first constraint conditions.

5. A determination unit that determines whether or not a constraint violation of the candidate plan satisfies a preset condition, 5. The information processing device according to claim 1, wherein the generation of the second constraint condition by the violation information conversion unit, the updating of the constraint information by the update unit, and the storage of new the first constraint condition in the first storage unit are repeated until a constraint violation of the candidate plan satisfies the condition.

6. the user interface unit allows a user to exchange allocations of the plurality of tasks to be performed by the plurality of workers and check for new constraint violations of the candidate plan due to the exchange; The information processing device according to claim 1 , wherein the violation information conversion unit converts the new constraint violation information generated by exchanging the allocation of the plurality of tasks into a third constraint condition related to the tasks in an information processable format.

7. The information processing apparatus according to claim 6 , wherein the exchange includes an exchange of an unassigned task with an assigned task.

8. The information processing apparatus according to claim 6 , wherein the exchange includes an exchange of assigned tasks.

9. The information processing apparatus according to claim 6 , wherein the exchange includes an exchange of three or more operations.

10. The information processing apparatus according to claim 6 , wherein the constraint information before the exchange includes a new constraint condition that is not included in the first constraint condition.

11. The information processing apparatus according to claim 6 , wherein all of the constraint information before the exchange is performed is included in the first constraint condition.

12. The information processing apparatus according to claim 1 , wherein the user interface unit displays the constraint violation information, including an operation within a specific date and time range selected by a user and a type of constraint, in an emphasized manner.

13. The information processing apparatus according to claim 12 , wherein the types of constraints include at least one of a sequence of work conditions and a sequence of work.

14. The information processing apparatus according to claim 12 , wherein the type of the constraint includes at least one of a driving qualification, a work qualification, and a work experience of the worker.

15. The information processing device according to claim 12 , wherein the type of the constraint includes at least one of a total of working hours, a number of public holidays, and a number of night shifts.

16. The information processing apparatus according to claim 12 , wherein the user interface unit is capable of selecting one of a plurality of candidates for the type of the constraint.

17. The computer storing constraint information including a first constraint condition for a candidate plan in which tasks to be performed are assigned to a plurality of workers in a first storage unit; having a user check for constraint violations for a plurality of workers, and having the user input, via a user interface unit, constraint violation information including the worker and date and time when the constraint violation of the candidate plan occurred, and the type of the constraint that was violated; converting the constraint violation information into a second constraint condition related to the task in an information processable format; updating the constraint information using the second constraint condition.

18. On the computer, storing constraint information including a first constraint condition for a candidate plan in which tasks to be performed are assigned to a plurality of workers in a first storage unit; a step of having a user check for constraint violations for a plurality of workers, and having the user input, via a user interface unit, constraint violation information including the worker and date and time when the constraint violation of the candidate plan occurred, and the type of the constraint that was violated; converting the constraint violation information into a second constraint condition related to the activity that is in an information processable format; a step of updating the constraint information by using the second constraint condition.

Images