WO2022245277A1

WO2022245277A1 - Method and apparatus for personnel assignment

Info

Publication number: WO2022245277A1
Application number: PCT/SG2021/050267
Authority: WO
Inventors: Rishabh RANJAN; Tejdeep Reddy Hunabad
Original assignee: Hitachi, Ltd.
Priority date: 2021-05-17
Filing date: 2021-05-17
Publication date: 2022-11-24

Abstract

A method of personnel assignment using at least one processor may include: receiving an input data comprising event data on a plurality of events and personnel data on a plurality of personnel; splitting the plurality of events into a plurality of disjoint event subsets; splitting the plurality of personnel into a plurality of disjoint personnel subsets, each personnel subset associated with a respective event subset of the plurality of disjoint event subsets; grouping the input data into a plurality of data groups, wherein each data group of the plurality of data groups comprises event data of a respective event subset and personnel data of a corresponding associated personnel subset; and computing a solution for each data group of the plurality of data groups, wherein the solution comprises an assignment to each event of the respective event subset, of at least one personnel from the corresponding associated personnel subset.

Description

METHOD AND APPARATUS FOR PERSONNEL ASSIGNMENT

TECHNICAL FIELD

[0001] Various aspects of this disclosure generally relate to methods of personnel assignment and apparatuses for personnel assignment, and more particularly, in relation to assigning personnel to respond to both scheduled and unscheduled events.

BACKGROUND

[0002] Cities are characterized by their high population density and their large variety of facilities and infrastructure that serve the population. These facilities may include residences, schools, hospitals, commercial buildings while the infrastructure may include roads, railways, airports, parks, and various public outdoor areas. These facilities and infrastructure require regular maintenance. In addition to these scheduled maintenance incidents, there may be unscheduled, in other words, dynamic incidents, such as car accidents, fires or medical emergencies, that need to be responded to promptly. For a city to be safe and livable, there is a need for a system that is capable of allocating the appropriate responders to handle the wide variety of incidents. It is challenging to solve the complex optimization problem where the scenarios include a mixture of scheduled and dynamic incidents. As on-ground situations may change dynamically, the system would need to re-optimize the allocation of responders to the incidents in real-time. Moreover, responders with specific skill sets may be required, depending on the type of incident tasks to be handled, and the availability of these skilled responders may be limited, therefore adding to the constraints of the optimization problem. One method of solving the optimization problem is to apply mixed integer linear programming and constraint programming to seek a globally optimal solution. While this method may provide a globally optimal solution, it is computationally intensive and therefore takes a long time to compute the solution when the problem size is large. As such, this method is unable to handle scenarios involving dynamic events that require immediate assistance, when the problem size is large. Another method of solving the optimization problem is to select the best possible responder per incident at any one time irrespective of the presence of other events. While this approach may provide a solution in real-time, or near real-time, the solution that it arrives at is not globally optimal. SUMMARY

[0003] According to a first aspect of the disclosure, there may be provided a method of personnel assignment using at least one processor. The method may include: receiving an input data comprising event data on a plurality of events and personnel data on a plurality of personnel; splitting the plurality of events into a plurality of disjoint event subsets; splitting the plurality of personnel into a plurality of disjoint personnel subsets, each personnel subset associated with a respective event subset of the plurality of disjoint event subsets; grouping the input data into a plurality of data groups, wherein each data group of the plurality of data groups comprises event data of a respective event subset and personnel data of a corresponding associated personnel subset; and computing a solution for each data group of the plurality of data groups, wherein the solution comprises an assignment to each event of the respective event subset, of at least one personnel from the corresponding associated personnel subset.

[0004] According to a second aspect of the disclosure, there may be provided an apparatus for personnel assignment. The apparatus may include a memory; and at least one processor communicatively coupled to the memory. The at least one processor may be configured to: split the plurality of events into a plurality of disjoint event subsets; split the plurality of personnel into a plurality of disjoint personnel subsets, each personnel subset associated with a respective event subset of the plurality of disjoint event subsets; group the input data into a plurality of data groups, wherein each data group of the plurality of data groups comprises event data of a respective event subset and personnel data of a corresponding associated personnel subset; and compute a solution for each data group of the plurality of data groups, wherein the solution comprises an assignment to each event of the respective event subset, of at least one personnel from the corresponding associated personnel subset.

[0005] According to a third aspect of the disclosure, there may be provided a non- transitory computer-readable storage medium that includes instructions executable by at least one processor, to perform a method of personnel assignment including: splitting the plurality of events into a plurality of disjoint event subsets; splitting the plurality of personnel into a plurality of disjoint personnel subsets, each personnel subset associated with a respective event subset of the plurality of disjoint event subsets; grouping the input data into a plurality of data groups, wherein each data group of the plurality of data groups comprises event data of a respective event subset and personnel data of a corresponding associated personnel subset; and computing a solution for each data group of the plurality of data groups, wherein the solution comprises an assignment to each event of the respective event subset, of at least one personnel from the corresponding associated personnel subset.

[0006] Additional features for advantageous embodiments are provided in the dependent claims.

BRIEF DESCRIPTION OF THE DRAWINGS

[0007] In the drawings, like reference characters generally refer to the same parts throughout the different views. The drawings are not necessarily to scale, emphasis instead generally being placed upon illustrating the principles of the invention. In the following description, various embodiments are described with reference to the following drawings, in which:

[0008] FIG. 1A shows a schematic block diagram of an environment framework of a system for responding to events.

[0009] FIG. IB shows a block diagram of the Control and Command Centre (CCC) according to various embodiments.

[0010] FIG. 2 shows a schematic diagram depicting operations of the CCC according to various embodiments.

[0011] FIG. 3 depicts a flow diagram that shows the operations of the dispatch optimizer 116 according to various embodiments.

[0012] FIG. 4A shows a detailed flow diagram of the process according to various embodiments.

[0013] FIG. 4B shows an example of the data grouping output.

[0014] FIG. 5 shows a flow diagram of a method of splitting the input data 310 into a plurality of data groups, according to various embodiments.

[0015] FIG. 6 shows a flow diagram of a method of splitting the input data 310 into a plurality of data groups, according to various embodiments.

[0016] FIG. 7 shows an illustration of an example of the method shown in FIG. 6.

[0017] FIG. 8 shows a flow diagram of a method of splitting the input data 310 into a plurality of data groups, according to various embodiments. [0018] FIG. 9 shows a flow diagram of a method of sorting events in a data group into a plurality of event batches, according to various embodiments.

[0019] FIG. 10 shows a flow diagram of a method of sorting events in a data group into a plurality of event batches, according to various embodiments.

[0020] FIG. 11 shows an example of an event batch distribution for scheduled events. [0021] FIG. 12A shows a flow diagram of a method of sorting events in a data group into a plurality of event batches, according to various embodiments.

[0022] FIG. 12B shows an example of an event batch distribution based on temporal proximity. FIG. 13 shows a flow diagram of a method of processing a single data group, according to various embodiments.

[0023] FIG. 14 shows a flow diagram of a method for computing the dispatch schedule according to various embodiments.

[0024] FIG. 15 shows an example of event information according to various embodiments. [0025] FIG. 16 shows an example of personnel information according to various embodiments.

[0026] FIG. 17 shows an example of task suitability score according to various embodiments.

[0027] FIG. 18 shows an example of travel time data according to various embodiments. [0028] FIG. 19A shows an example of personnel target workload data according to various embodiments.

[0029] FIG. 19B shows an example of personnel remaining workload data according to various embodiments.

[0030] FIG. 20 shows a flow diagram of a method of personnel assignment using at least one processor, according to various embodiments.

[0031] FIG. 21 shows a conceptual diagram of an apparatus for personnel assignment according to various embodiments.

DESCRIPTION

[0032] Embodiments described below in context of the apparatuses are analogously valid for the respective methods, and vice versa. Furthermore, it will be understood that the embodiments described below may be combined, for example, a part of one embodiment may be combined with a part of another embodiment. [0033] It will be understood that any property described herein for a specific apparatus may also hold for any apparatus described herein. It will be understood that any property described herein for a specific method may also hold for any method described herein. Furthermore, it will be understood that for any apparatus or method described herein, not necessarily all the components or steps described must be enclosed in the device or method, but only some (but not all) components or steps may be enclosed.

[0034] In this context, the apparatus as described in this description may include a memory which is for example used in the processing carried out in the apparatus. A memory used in the embodiments may be a volatile memory, for example a DRAM (Dynamic Random Access Memory) or a non-volatile memory, for example a PROM (Programmable Read Only Memory), an EPROM (Erasable PROM), EEPROM (Electrically Erasable PROM), or a flash memory, e.g., a floating gate memory, a charge trapping memory, an MRAM (Magnetoresistive Random Access Memory) or a PCRAM (Phase Change Random Access Memory).

[0035] The term “coupled” (or “connected”) herein may be understood as electrically coupled or as mechanically coupled, for example attached or fixed, or just in contact without any fixation, and it will be understood that both direct coupling or indirect coupling (in other words: coupling without direct contact) may be provided.

[0036] In order that the invention may be readily understood and put into practical effect, various embodiments will now be described by way of examples and not limitations, and with reference to the figures.

[0037] According to various embodiments, a method of personnel assignment may be provided. The method may include analyzing a set of input data that includes a list of a plurality of events, a list of personnel, and assigning the appropriate personnel to each event of the plurality of events. The plurality of events may include a diverse set of events, including both schedule events and dynamic events, whose occurrence cannot be predicted. The plurality of events may need to be attended to, by different types of personnel.

[0038] The method may consider joint optimization of multi-task incidents coupled with a rule engine to handle real-life dynamic scenarios with many uncertainties and may obtain globally optimal solutions, or nearly globally optimal solution, in assigning the personnel to the events. The globally optimal solution may be a solution in which personnel assignments are jointly optimized using a solver considering relative proximity between events as well as between events and personnel and other relevant factors. For example, a globally optimally solution may minimize the cumulative event response times considering all pending and new events for a given optimization problem, instead of computing the solution based on only considering a single event.

[0039] The method may include dividing a medium to large set of input data including information on events and personnel, into multiple smaller data groups. The input data may be divided into the smaller data groups based on event information such as locations, type, time of occurrence and personnel information such as locations, status, schedule, and workload etc. The method may include computing the respective solutions for each data group in parallel. These data groups may be processed at least substantially concurrently, as they are non-overlapping subsets of the input data. In other words, these data groups do not include any common events or personnel.

[0040] The method may further include sub-dividing data in the data groups into a plurality of batches to be processed sequentially. Batches that include higher priority events, such as emergency events, may be processed ahead of the other batches.

[0041] The method may include selecting a type of solver most suitable for processing the data within the data group or batch, based on information of the data group or batch. The solvers may be selected before computation of the personnel assignment for each data group or batch. The selected solver may determine the optimal personnel assignments for the data group or batch. The method may include running the solvers in parallel for each data group, so as to reduce the computation time required to find a solution for each data group. As a result, personnel may be dispatched to respond to the events efficiently. The solvers may be subjected to objective functions such as, minimizing time to complete all the incidents in a group or batch, prioritizing emergency events, minimizing personnel cost, even distribution of personnel workload etc.

[0042] According to various embodiments, a system for personnel assignment may be provided. The system may be part of an incident response and dispatch system that dispatches responders to various spaces within a smart city, to resolve incidents. Examples of the various spaces may include buildings, shopping malls, schools, hospitals, commercial facilities, road, railways airports, parks, outdoor areas etc. The incidents may vary in nature, for example, may be scheduled, non-emergency and emergency events.

[0043] In the context of various embodiments, the term “personnel” may be but is not limited to being interchangeably referred to as a “responder”, “staff’ or “officer”. [0044] In the context of various embodiments, the term “event” may be but is not limited to being interchangeably referred to as an “incident”.

[0045] FIG. 1A shows a schematic block diagram of an environment framework 100 of a system for responding to events. The environment framework 100 may include a Command and Control Center (CCC) 110, a plurality of personnel 120, a plurality of mobile devices 140, and a communication network 130. The CCC 110 may include a system for personnel assignment.

[0046] The CCC 110 may include a computing system that includes an operating system, a database system, a file system, a processing unit, a graphical user interface, and a graphics processing unit. The graphics processing unit may be configured to handle various operations relating to incident management, for example, receiving incident alerts, preparing action plans for incident workflow, computing optimal task assignments, dispatch alerts to assigned responders and continuous monitoring of incident response.

[0047] The personnel 120 may be deployed across the city to handle different types of incidents happening in the city. The locations of these incidents may be indoors or outdoors. The plurality of personnel 120 may include a mix of different types of personnel. These personnel 120 may be knowledgeable and skilled in different fields, such as maintaining law and order, extinguishing fires, first aid, evacuation, water safety, aircon repair, and more. For example, the personnel 120 may be a policeman who is trained to handle criminal events such like hit-and-run, gunshot, and robbery etc. In another example, the personnel 120 may be a fireman who is trained to deploy fire trucks, carry out evacuation, and extinguish fires etc. In another example, the personnel 120 may be a paramedic who is trained in dispensing first aid, carrying out emergency medical procedures, driving ambulances, etc. Each personnel 120 may be equipped with a respective mobile device 140. The mobile device 140 may be a portable electronic device, for example, a mobile phone, a tablet, a head mounted device, or a wearable device.

[0048] The communication network 130 may include a telecommunications network such as 3G, 4G or 5G. The communication network 130 may include an internet connection. The CCC 110 and the personnel 120, through their respective mobile devices 140, may communicate bi-directionally via the communication network 130. The personnel 120 may receive dispatch instructions from the CCC 110 via their mobile devices 140. Their mobile devices 140 may transmit updates on the personnel’s statuses, such as their locations, or the progress on their assigned tasks, to the CCC 110. [0049] FIG. IB shows a block diagram of the CCC 110 according to various embodiments. The CCC 110 may include an event detector 112, a response planning unit 114, a dispatch optimizer 116 and a dispatching unit 118. These components of the CCC 110 will be described in further details with respect to FIG. 2.

[0050] FIG. 2 shows a schematic diagram depicting operations of the CCC 110 according to various embodiments. The CCC 110 may receive information about the city 210, through a sensor management system 220.

[0051] A plurality of personnel 120 and events 212 may be distributed geographically across the city 210. The events 212 and the personnel 120 may be dynamic in nature. Real time information about the events 212 and the personnel 120, such as their locations and statuses, may be provided to the CCC 110. For example, the sensor management system 220 may provide real-time information about the events, for example, the mobile devices 140 may provide real-time information about the personnel 120. The events 212 may occur indoors or outdoors. The CCC 110 may assign a priority to each event 212, depending on whether the event was scheduled or unscheduled as determined from information received about the event. The CCC 110 may further assign the priority to the event, based on whether the event is an emergency or a non-emergency. Examples of indoor events may include detecting any indoor equipment/infrastructure failure (elevator, aircon, escalators etc.), repair/maintenance events, suspicious activity, intrusion alert, fire detection inside any premises of facility etc. Examples of outdoor events may include detecting any traffic violations, traffic accidents, riots, streetlights failure detection, drainage leak, garbage capacity fill detection, fire detection, medical emergency, gunshots etc.

[0052] The sensor management system 220 may include various sensors such as cameras, microphones, environmental monitoring devices etc. These sensors may be deployed indoors or outdoors. Some of these sensors may be part of a building management system (BMS) or a video management system (VMS). These sensors may include internet-of-things (IoT) sensors that are connected to the internet and may be capable of communicating to other sensors. The sensor management system 220 may transmit data collected from the sensors, to the CCC 110.

[0053] Still referring to FIG. 2, the CCC 110 may be configured to carry out a process 230. The process 230 may include detecting events based on information received from the sensors management system 220, in 232. For example, the event detector 112 may perform video analytics on video streams recorded by cameras. For example, the event detector 112 may perform data analysis, run prediction algorithms, apply machine learning (ML), or deep learning (DL) models to automatically identify various situations/incidents happening indoor or outdoor across the city 210. Alternatively, the events may be reported manually by a reporter, in 234. The reporter may be, for example, residents, personnel 120 or clients. The reporter may make reports of the events using various communication means like phone calls, messaging services, live chat feature via web/mobile or submitting an incident report via a mobile app. In 236, the CCC 110 may receive event details, such as geographical location, occurrence time, priority, and type. The event details may further include information like comments from the reporter, associated sensors data, and evidence captured by analytics platform. In 236, the response planning unit 114 of the CCC 110 may generate a response plan or appropriate workflow based the received event details. The response planning unit 114 may generate the response plan, further based on pre-defined settings. The response plan may include key requirements for the events to be resolved, for example, number of tasks, personnel type and quantity per task, target task completion time, and task complexity. In 238, events data may be provided to the dispatch optimizer 116 of the CCC 110, for further processing. The events data may include information about the events, including the response plan, the events requirements and the events details. In 238, the dispatch optimizer 116 may receive the events data, as well as other real-time information. The real-time information may include real-time updates about the events 212 and the personnel 120. The real-time information may further include information about the weather, traffic etc. The dispatch optimizer 116 may also receive stored data from a database. The stored data may include known information about the personnel 120, historical data about the personnel 120, for example, the tasks that they had completed before, information about the locations of the events or personnel. In 238, the dispatch optimizer 116 may compute a globally optimal dispatch schedule in real-time using dynamic batch-wise scheduling. The computed optimal dispatch schedule may include a sequence of tasks assigned to each personnel with other information like travel time, expected task start time etc. Real-time response from the dispatch optimizer 116 may be important for situations concerning emergency events where even a slight delay in dispatching a personnel 116 may result in loss of life or other collateral damage. Operations of the dispatch optimizer 116, including details of the batch-wise scheduling, will be described with respect to FIG. 3. In 240, the dispatching unit 118 of the CCC 110 may prepare a detailed task action plan for each personnel according to the generated dispatch schedule. The dispatching unit 118 may send an automatic dispatch alert with task details to the personnel 120 via their respective mobile devices 140.

[0054] FIG. 3 depicts a flow diagram that shows the operations of the dispatch optimizer 116 according to various embodiments. The apparatus for personnel assignment may include the dispatch optimizer 116. The dispatch optimizer 116 may receive input data 310. The input data 310 may include events data 312, personnel data 314 and other data 316. The events data 312 may include geographical location of the event, the occurrence time of the event, the time of detecting the event, the number of tasks and time required to resolve the incident, and the staff type and quantity requirements. The events data 312 may be provided to the dispatch optimizer 116 by the response planning unit 114. The personnel data 314 may include geographical location of each personnel 120. The personnel data 314 may also include information about the mode of travel, the current schedule and work load, the skills, experience, and past performance of each personnel 120. The personnel data 314 may include at least part of the real-time information received in the process 238. The personnel data 314 may also include at least part of the stored data received from the database. For example, the personnel’s respective skill sets, experience and past performance may be retrieved from the database. The other data 316 may include weather information, traffic information, and historical dispatch data. The weather and traffic information may be part of the real-time information. The historical dispatch data may be part of the stored data. The historical dispatch data may be categorized according to the event type, personnel type, geographical area and time of occurrence, etc.

[0055] The dispatch optimizer 116 may generate dispatch schedules 320 based on the received input data 310 through a task assignment method 300. The generated dispatch schedule 320 may be globally optimal, and may be generated in real-time relative to the events’ occurrences. The task assignment method 300 may include a process 382. The process 382 may include dividing a given problem set of events and personnel into sub problems, referred herein as “data groups”, based on one or more criteria, and by applying grouping algorithms. The task assignment method 300 may include a process 384 which includes selecting a solver type from a pre-defined set of solvers based on information and parameters of the data groups. The task assignment method 300 may include a process 386 which includes concurrently generating the dispatch schedules 320 for each data group, by applying the respective selected solver on each data group based on a set of rules and objective functions subject to multiple constraints. The dispatch schedule 320 may assign at least one personnel to each event. The dispatch schedule 320 may further assign each personnel to a sequence of tasks associated with the assigned event.

[0056] FIG. 3 includes an example of the dispatch schedule 320. In the example, the dispatch schedule 320 is generated in the form of a table that includes a respective column for “personnel id”, “event id”, “task id”, “travel time”, “task duration” and “task start time”. The “personnel id” column may indicate the assigned personnel by their respective identifier codes. The “event id” column may indicate the event, by an event identifier code, that the personnel is assigned to. The “task id” column may indicate the task, by a task identifier code, associated to the event listed under the “event id” column, that the personnel is assigned to carry out. The “task duration” column may indicate the maximum time available for the assigned personnel to complete the task. The “task start time” column may indicate the time that the assigned personnel is expected to start working on the task. The dispatch schedule 320 may also include other information, such as, the estimated travelling time for the personnel to travel to the event location, and the time duration that the personnel needs to complete the task as estimated based on the personnel’s task suitability score. The task suitability score will be discussed with respect to FIG. 17.

[0057] According to various embodiments, the solver selected in the process 384 may be one of mixed integer linear programming (MILP), heuristics, and reinforced learning (RL). The MILP solver may solve a problem using exact mathematical modelling. The MILP solver may provide an optimal solution but may be computationally heavy and its run time may grow unbounded with problem size. The heuristics solver may provide an approximate solution rather than an optimal solution, but it may solve the problem faster than the MILP solver. The RL solver may solve problems using reward-based agent actions and its learning model is trained based on extensive past dispatch data about given set of events and responders. With a well-trained learning model, the RL solver may provide an optimal solution or a solution at least as good as that provided by the heuristics solver, and within a shorter computation time for a given problem size.

[0058] FIG. 4A shows a detailed flow diagram of the process 382 according to various embodiments. The process 382 may include determining whether the problem size, i.e. size of the input data 310, is larger than a threshold, P. When the problem size is larger than P, the problem may be too large to be solved in one single run. If the problem size is larger than P, the process 382 may proceed to a data grouping process 420, where the input data 310 is split into a plurality of data groups. If the problem size is smaller than P, the process 382 may proceed directly to generate a data grouping output 430 that includes a single, undivided set of input data 310.

[0059] The data grouping process 420, in other words, the process of splitting the input data into a plurality of data groups, may include determining one or more data grouping criteria, in 422. The data grouping criteria may include, for example, the event’s personnel type requirements, travel time considering the events and the personnel’s locations, the personnel’s schedule and workload etc. The data grouping process 420 may further include computing grouping features based on the determined data grouping criteria, in step 424. The grouping features may include, for example, correlation values between an event and a personnel, correlation values between events, travel time between the events and the personnel etc. The data grouping process 420 may further include applying at least one grouping algorithm on the input data 310 to find distinct groups of events and personnel, in 426. The grouping algorithm may group the input data 310 based on the computed features, into a plurality of data groups. The events and personnel in each data group do not overlap with the other data groups. The data grouping process 420 may further include checking whether each data group complies with a set of grouping rules. The set of grouping rules may include, for example, having enough personnel to keep the response time to the events in the data group sufficiently short, and ensuring that the personnel to event ratio in each data group is within an acceptable range.

[0060] The process 382 may include determining whether the input data 310 was split into data groups in the process 420, in 404. In some cases, the process 420 may not result in splitting the input data 310 into any data groups, for example, when the input data 310 could not be divided into data groups based on the computed features or the data grouping rules. If no data groups are formed, the process 382 may proceed to a sequential grouping process 410, where the input data 310 is split into a plurality of batches to be solved sequentially. Dividing the problem into smaller batches may avoid overwhelming the computational resources, and may provide solutions at a faster rate.

[0061] If a plurality of data groups were formed in the process 420, the process 382 may proceed to determine whether the size of each data group is less than the threshold P, in 406. If the data group is larger than P, i.e. its data size is still too large to be processed in a single run. As such, the data group may need to be further split into smaller groups, referred herein as “batches”, in the sequential grouping process 410. Otherwise, if the data groups are sufficiently small, and therefore need not be further divided into batches, the process 382 may proceed directly to generate the data grouping output 430 that includes the data groups formed in the data grouping process 420.

[0062] The sequential grouping process 410 may further reduce the size of each data group. The sequential grouping process 410 may include determining grouping criteria, such as but not limited to, events priority/severity, time horizon, temporal proximity of the events’ occurrence, in 412. The sequential grouping process 410 may further include computing grouping features such as a sorting of the events by priority, temporal clustering of events etc., in 414. The sequential grouping process 410 may further include dividing the data in the data group into a plurality of batches, based on the computed features, and using at least one grouping algorithm, in 416. Unlike the data groups formed in the data grouping process 420, the batches may be dependent on other batches as they share the same pool of personnel from the data group. The events in the batches will be non-overlapping, but the personnel in the batches may overlap. Therefore, the sequential grouping process 410 may divide the events into smaller batches while the number of personnel in the batches may be decided in run-time based on the dispatch schedule of the previous batch. Events in batches may be in close geographical proximity of events in other batches, and as such batches may be chosen to ensure globally optimal solutions. In addition, the number of batches in each data group may be kept to a minimum as much as possible, as a large number of sequential batches may affect the optimality of the solution in the global context. Each batch may be given a sequence number within each data group. Finally, all the data groups and their batches may be collected in the data grouping output 430. Each data group and each batch may include, for example, data group identifier codes, batch identifier codes, information of subsets of events and personnel extracted from the input data 310, and other information relevant to the data group or batch. The other information may include, for example, historical dispatch data pertaining only to the events and personnel types in the respective data group.

[0063] FIG. 4B shows an example of the data grouping output 430. In this example, the data grouping output 430 includes a plurality of data groups 432, 434, 436, and each of these data groups includes a plurality of batches. For example, the data group 432 includes a first batch 432A, followed by a second batch 432B etc. Each batch may include a sequence tag that indicates the order in which the batch will be processed. Each of the data groups 432, 434, 436 may be processed in parallel. Within each data group, the batches may be processed sequentially.

[0064] There are various methods of distributing the problem data into clusters. [0065] FIG. 5 shows a flow diagram of a method 420A of splitting the input data 310 into a plurality of data groups, according to various embodiments. The method 420A may be an embodiment of the data grouping process 420, and may split the input data 310 into data groups based on personnel requirements of the events. The method 420A may include processes 421 A, 422A, 423A, 424A, 425A, 426A and 427A. The process 421 A may include obtaining a list of the events, the events’ requirements on the personnel type, and a list of the personnel, from the input data 310. The process 422 A may include computing, for each event, a correlation value between the event and all other events using their respective requirements for personnel type. For example, an event Ei may require personnel types F and H, while another event Ei may require personnel type H, and another event /?_.; may require personnel types S and W. In this example, the correlation value between Ei and Ei is 1 as both events have a common requirement for personnel type H, whereas the correlation value between Ei and

as well as the correlation value between Ei and

are 0, as they have no common personnel type requirement.

[0066] The process 423A may include obtaining a next event Ei from the list of events. The process 424 A may include, finding all other events that has a correlation value of 1 with the event Ei. The process 424A may further include grouping Ei and these events which are correlated with Ei, into an event subset. The process 424A may further include removing these grouped events from the list of events.

[0067] The process 425A may include identifying, for each event within the event subset, other events in the list of events, that are correlated to them. As a result, all events which have at least one common personnel type requirement may be grouped in one event subset. For example: E3 requires personnel types S and W, E4 requires personnel type S, and E5 requires personnel type W. In this example, since E3 is correlated to both E4 and Es, all three may be grouped into a single event subset. Although E4 and E5 are not directly correlated, they are indirectly correlated via E3. The process 425A may include adding these identified indirectly correlated events into the event subset, and removing these identified indirectly correlated events from the list of events.

[0068] The process 426A may include determining whether the event list is now empty. The processes 423A, 424A and 425A may be repeated until the event list is empty, i.e. when all of the events are allocated to a respective event subset. The plurality of events in the events list have been split into a plurality of disjoint, i.e. non-overlapping, events subsets. When the event list is empty, in process 427A, the plurality of personnel in the personnel list may be split into a plurality of disjoint personnel subsets that correspond to the plurality of event subsets. In the process 427A, each personnel subset may be allocated to a respective event subset based on the personnel type requirements of the respective event subset. Event data of the events in an event subset may be combined with the personnel data of the personnel in the allocated personnel subset, to form a data group. In other words, the process 427A may include determining for each event subset, its personnel requirement, and forming an associated personnel subset based on the personnel requirement. Consequently, the plurality of personnel in the personnel list may be split into the plurality of disjoint personnel subsets, and each of the personnel subsets may be grouped with a respective event subset to form a data group.

[0069] The process 420A is further described with respect to a specific example below. [0070] The process 421 A may include obtaining an event list and a personnel list. In this example, the event list may include 10 events and the personnel list may include 10 personnel as follows:

Event list = [El, E2, E3, . , E10];

Events’ personnel requirements (F, H, S, and W) = El: {F}; E2: {F, H}; E3: { S } ; E4: {S,W}; E5: {W}; E6: {H}; E7: {F, H}, E8: {W}; E9: {S}; E10: {S, W}

Personneljist = [FI, F2, HI, H2, H3, SI, S2, Wl, W2, W3]

[0071] The process 422 A may include computing the correlation values between all possible pairs of events, as shown in Table 1:

Table 1

[0072] The process 423A may include obtaining the next event, Ei, from the event list. For example, in a first iteration, Ei =Ei_.

[0073] In the process 424A: for El, the correlated events are E2 and E7 as their correlation values are 1. Therefore, E2, and E7 are placed into a first event subset Event_subsetl = [El, E2, E7] and these events are removed from the event list. The updated event_list =[E3, E4, E5, E6, E8, E9, E10]).

[0074] In the process 425A: For all the events in the first event subset, other events from event_list (=[E3, E4, E5, E6, E8, E9, E10]) that are correlated to events in the Event_subsetl = [El, E2, E7] are identified. E2 is correlated with E6 while E7 is also correlated with E6. Therefore, E6 is added into the first event subset, so that Event_subsetl= [El, E2, E6, E7]. E6 is then removed from the event list. Consequently, the updated event_list (=[E3, E4, E5, E8, E9, E10]). For newly added events to the first event_subset, the process 425A is repeated until there are no more correlated events to be added to the event subset. In this example, E6 is not correlated to any event beyond Event_subsetl. Hence, the method may proceed to the process 426A.

[0075] The process 426A may include determining if the event list is empty. In this example, the event list still has 6 events, and hence, the method may proceed to the process 423 A. In the process 423 A, the next event is identified as E3. Next, the processes 424A to 426A are carried out to obtain a second event subset, Event_subset2 = [E3, E4, E5, E8, E9, EIO]

[0076] In the process 427A: personnel FI, F2, HI, H2, H3 from the personnel list are associated with the first event subset, while personnel SI, S2, Wl, W2, W3 are associated with the second event subset. The personnel FI, F2, HI, H2, H3 may be grouped as a first personnel subset, personnel_subsetl = [FI, F2, HI, H2, H3]. The personnel SI, S2, Wl, W2, W3 may be grouped as a second personnel subset, personnel_subset2 = [SI, S2, Wl, W2, W3]. Personnel_subsetl may be combined with Event_subsetl to form a first data group, G1 = {events: [El, E2, E6, E7], personnel: [FI, F2, HI, H2, H3]}. Personnel_subset2 may be combined with Event_subset2 to form a second data group, G2 = {events: [E3, E4, E5, E8, E9, EIO], officers: [SI, S2, Wl, W2, W3]}.

[0077] FIG. 6 shows a flow diagram of a method 420B of splitting the input data 310 into a plurality of data groups, according to various embodiments. The method 420B may be an embodiment of the data grouping process 420, and may split the input data 310 into data groups based on geographical proximity. In the context of a city, the plurality of personnel may be distributed geographically over a large area, and as such, it may be advantageous to allocate the events and personnel into different data groups based on the time required for the personnel to travel from his/her location to an event and to travel between events.

[0078] The method 420B may include processes 421B, 422B, 423B, and 424B. The process 42 IB may include obtaining a list of the events and their respective locations, and a list of the personnel and their respective locations. The process 422B may include computing the travel time between all permutations of pairing between two events, and all permutations of pairing between an event and a personnel. The process 423B may include setting a travel time maximum threshold, T so that no personnel would need to travel too far to an event. One of the main objectives of an incident response system may be to minimize travel time so as to maximize time spent by personnel on working on the tasks assigned. The process 424B may include grouping the events and personnel based on their locations into a plurality of non overlapping clusters, using a clustering algorithm, such that the maximum travel time between any two events or between any responder location and any event, within a cluster is less than T. In clustering the events and personnel, the process 424B may split the events into a plurality of disjoint event subsets and may split the personnel into a plurality of disjoint personnel subsets. The clustering algorithm may include at least one of K-mean clustering, hierarchical clustering, or mean shift clustering. However, there may be outlying events and/or personnel that are left out of any cluster because of the travel time criterion and in such cases, these outlying events and personnel may be put into a cluster that is geographically closest. Each cluster may be a data group, and may include a respective event subset and a respective personnel subset.

[0079] FIG. 7 shows an illustration of an example of the method 420B. The solid lines 702 represent the distance, and hence, travel time for a personnel to reach an event. The dashed lines 704 represent the travel time, between two events. The events and personnel may be grouped into three distinct clusters 710A, 710B, and 7 IOC based on the geographical proximities of the events and the personnel. The data in the three clusters, i.e. three non overlapping data groups, may be processed concurrently to seek a solution within each data group.

[0080] While the methods 420A and 420B relate to methods of splitting the input data 310 into a plurality of data groups based on a single criterion, in other embodiments, the splitting the input data 310 into a plurality of data groups based on a plurality of criteria. The data groups may be sub-divided into smaller data groups. One such method is described with respect to FIG. 8.

[0081] FIG. 8 shows a flow diagram of a method 420C of splitting the input data 310 into a plurality of data groups, according to various embodiments. The method 420C may be an embodiment of the data grouping process 420, and may split the input data 310 into data groups based on more than one criteria. The method 420C may include processes 421C, 422C, 423C, 424C and 425C. The process 421C may include selecting more than one criteria as the basis for dividing the input data 310. The process 422C may include dividing the input data 310 into a plurality of data groups based on a first criteria, for example, personnel requirements, like in the method 420A. The process 423C may include obtaining the next data group in a list of data groups formed from the process 422C. The process 424C may include dividing the obtained data group into smaller data groups based on a second criteria, for example, geographical proximity, like in the method 420B. The process 425C may include determining whether all the data groups formed from the process 422C have undergone the process 424C. If yes, the method 420C ends, and the output may be a plurality of smaller data groups. Each of these smaller data groups may be processed concurrently, to find a solution within each smaller data group. If there is at least one data group formed from the process 422C that has not undergone the process 424C, the processes 423C and 424C may be repeated until all of the data groups formed from the process 422C have undergone the process 424C. In some cases, it may not be possible to further divide the data groups into smaller data groups, and hence the output from the process 424C may be the same as the data group input into the process 424C.

[0082] FIG. 9 shows a flow diagram of a method 410A of sorting events in a data group into a plurality of event batches, according to various embodiments. The method 410A may be an embodiment of the sequential grouping process 410. The method 410A may sort the events in the data group into an ordered, i.e. sequenced, plurality of event batches based on the priority of the events. According to this method, personnel will be first sent to events with the highest priority, for example, critical, life-threatening events. The method 410A may include processes 411A, 412A, 413A, 414A, 415A, 416A, 417A, 418A and 419A. The process 411 A may include obtaining a list of events along with their priorities from a data group. The process 412A may include sorting the events according to their respective priorities. [0083] In an example, the priority of the event may depend on whether the event is a scheduled event, a non-emergency event, or an emergency event. A scheduled event is an event that is pre-planned and its occurrence time is known in advance. Examples of a scheduled event include regular maintenance and repair work. A non-emergency event is an unscheduled event that may need to be handled as soon as possible although it is not life- threatening. Examples of a non-emergency event include minor accidents, theft, etc. An emergency event is an unscheduled event that needs to be responded to immediately and may include life-threatening situations. Examples of emergency events may include fire incidents, medical emergencies, chemical leak in factory etc. Emergency events may be given the highest priority, followed by non-emergency events with medium priority, and lastly, scheduled events with the lowest priority. The priority of the scheduled events may further depend on their scheduled time. Events that are scheduled to begin shortly may be given a higher priority than events that are scheduled to begin at a later time.

[0084] The process 413 A may include grouping events of the highest priority into an event batch. The process 414A may determine whether the event batch formed in the process 413A has too any events, i.e. more events than a maximum threshold E. If the event batch has more events than the maximum threshold E, the method may proceed to the process 415A, where the event batch is further divided into smaller batches with less events than E. The event batch may be divided into smaller batches based on another criteria such as their geographical locations, or occurrence time. Alternatively, the event batch may be divided into smaller batches by grouping the events in the event batch based on their order within the event batch. [0085] If the number of events in the event batch from 414A is less than E, the method may proceed to the process 416A. The process 416A may group events of medium priority to form a second event batch. The events of medium priority may include non-emergency events and scheduled events that are due to begin shortly.

[0086] The process 417 A may determine if there are too many events in the second event batch, i.e. more than E. If yes, the second batch is further divided into more event batches, for example, an earlier event batch for the non-emergency events, and a later event batch for the scheduled events, in the process 418A. The process 419A may group all the remaining events in the data group to form a last event batch. The process 419A may optionally also check if the number of events within the event batch exceed E, and if the size of the last event batch is still more than E, the last event batch may be further divided into smaller batches. Following completion of the process 419A, all the event batches may be given a sequence identifier. When the data group is processed to compute a solution, the event batches in the data group may be processed sequentially according to their respective sequence identifiers.

[0087] FIG. 10 shows a flow diagram of a method 410B of sorting events in a data group into a plurality of event batches, according to various embodiments. The method 410B may be an embodiment of the sequential grouping process 410. The method 410B may sort the events in the data group into an ordered plurality of event batches based on the timing of the events. This method may be most suitable for scheduled events where the event occurrence time is known beforehand. In this method, events within a duration of T (for example, 30 mins, 1 hour etc.) may be grouped in an event batch. The method 410B may include processes 41 IB, 412B, 413B, 414B, 415B, 416B, 417B, 418B. The process 41 IB may include obtaining a list of the events in the data group and their respective occurrence times. The process 412B may include scheduling the events based on their occurrence times. The process 413B may include initializing the occurrence time U, for example, to set U=0. In the process 414B, events may be grouped for every time duration T. In other words, events having occurrence time U < t < ti₊t are grouped as an event batch. The process 415B may determine whether the size of the event batch formed in the process 414B is larger than a threshold P. If the process 415B determines that the event batch size does not exceed P, the method may proceed to the process 417B, to determine whether all events in the list are placed into respective event batches. If not all of the events have been placed into event batches, then the method may proceed to 418B, to add T to the occurrence time, and then return to the process 414B.

[0088] If the process 415B determines that the event batch size exceeds P, in the process 416B, the event batch may be divided into smaller batches that are smaller than P, based on a reduced time duration that is smaller than T, and/or other criteria such as temporal proximity. As compared to dynamic events, the response time to be scheduled events may be more flexible and therefore, larger event batch size may be allowed. In other words, P may be larger than E. Next, the method may proceed to the process 417B. If not all of the events have been placed into event batches, then the method may proceed to 418B, to add T to the occurrence time, and then return to the process 414B.

[0089] In relation to the method 410B, FIG. 11 shows an example of an event batch distribution for scheduled events with time duration, T of 1 hour.

[0090] FIG. 12A shows a flow diagram of a method 4 IOC of sorting events in a data group into a plurality of event batches, according to various embodiments. The method 4 IOC may be an embodiment of the sequential grouping process 410. The method 410C may sort the events in the data group into an ordered plurality of event batches based on temporal proximity of the events, in other words, their proximity at given occurrence times. This embodiment may be suitable for scheduled events as their occurrence times are known in advance. The method 410C may include processes 411C, 412C, 413C, 414C, 415C, 416C, 417C, 418C. The process 411C may include obtaining a list of the events along with their occurrence times. The process 412C may include applying time-series clustering algorithm to the list of events sorted by their occurrence time, to find unique clusters of events based on a similarity index defining similarity between two events with respect to temporal proximity with a time difference of T_d. The process 413C may include obtaining a next cluster. The process 414C may include determining if the obtained cluster can be merged with a subsequent cluster. A criterion for the determination in the process 414C may be based on a quantity of events in the successive clusters. The clusters may be merged if the cumulative quantity of events in the successive clusters is less than a minimum threshold. If yes, in the process 415C, the merged clusters may form a new event batch, otherwise in the process 416C, the single cluster may be an event batch. This process may be repeated until all the clusters have been grouped into an event batch.

[0091] In relation to the method 4 IOC, FIG. 12B shows an example of an event batch distribution based on temporal proximity. The horizontal axis 420 represents time, while the vertical axis 422 represents distance. The dots in FIG. 12A represent events within a data group, arranged according to their locations and occurrence times. Using a clustering algorithm, these events may be grouped into a plurality of clusters 432, 434, 436, 438, 440, and 442. The clusters 436 and 438 may be determined in the process 414C, to be suitable for combining to form an event batch. Similarly, the clusters 440 and 442 may be combined to form another event batch. On the other hands, each of the clusters 432 and 434 may be assessed to be suitable for forming a respective event batch.

[0092] FIG. 13 shows a flow diagram of a method 1300 of processing a single data group, according to various embodiments. The method 1300 may include a personnel selection process 460, a solver selection process 500 and a solution computing process 600. The personnel selection process 460 may include selecting personnel for each event batch in the data group. The personnel selection process 460 may be skipped if the events in the data group are not split into event batches. The solver selection process 500 may include selecting a solver for the data group or for each event batch in the data group. The solution computing process 600 may include computing the optimal dispatch schedule for the data group or each event in the data group, using the selected solver(s).

[0093] The personnel process 460 may include determining in 462, whether there is an event batch in the data group. If the data group does not include an event batch, the data within the data group may be directly fed to the solver selection process 500. Otherwise, the list of events in the next event batch may be obtained, in 464. 464 may also include obtaining a list of the personnel within the data group, as well as a current dispatch schedule of all the personnel officers in the data group. Next, a sub-set of the personnel may be selected for the event batch, in 466. The sub-set of personnel may be selected based on personnel information, such as the availability of personnel, their skill levels, and their past performance data. The sub-set of personnel may be selected further based on events information relating to events in the event batch. For example, the personnel may be first sorted based on availability and then based on skill. For a given range of occurrence times corresponding to events in the event batch, all available personnel may be shortlisted and then, a number (represented by O ) of most skilled and available personnel may be selected for this batch, wherever applicable. The value of O may be decided based on the number of events and to ensure global optimality of the solution and at the same time minimum run-time of the solver. As example, the number of personnel may be 2 to 3 times the number of events. Another criterion which may be used to select personnel for the events in the event batch is if there is historical dispatch data of some personnel being matched with the same event types in the event batch. After the personnel for the event batch are selected, the method may proceed to the solver selection process 500, to select a solver to process data on the events and the selected personnel for the event batch. If the data group does not include any event batches, the solver is selected for the data in the entire data group.

[0094] Following the solver selection process 500, the process 600 may include computing the optimal dispatch schedule for the current event batch (or the data group, if there is no event batch), using the selected solver. The resulting dispatch schedule may be fed back to the process 460, for selection personnel for a subsequent event batch, as the personnel selection process 460 may consider the updated availability of the personnel. In 470, it may be determined whether all of the events batches have been processed, i.e. having their respective solutions computed. If yes, the method may come to an end, otherwise, the method may return to the personnel selection process 460. [0095] A solver may include a set of algorithms which seeks an optimization of a problem given various constraints. These algorithms may include but not may not be limited to mixed integer linear programming (MILP), heuristics, reinforcement learning (RL) etc.

[0096] For the scenario where the data group does not include event batches, the solver selection process 500 may consider at least one attribute of the data group, to select the solver. For the scenario where the data group includes a plurality of event batches, for each event batch, the solver selection process 500 may consider at least one attribute of the event batch and information on its selected personnel, to select the solver for the event batch. The at least one attribute of the event batch or data group may include information like data size, whether there are dynamic events in the event batch or data group, high correlation with historical dispatch data of personnel and events. For example, if in 510, it is determined that the data size is small enough, for example, less than a threshold B, the MILP solver 540 may be selected as it may provide an optimal solution within an acceptable computing time. Examples of MILP solvers 540 include Gurobi and PuLP. In addition, if in 520, it is determined that there is no dynamic event in the event batch, the MILP solver 540 may be selected even if the data size is slightly large. This is because scheduled events are generally not time-critical, and hence, more time may be afforded to the MILP solver 540. The heuristics solver 550 may search for feasible solutions based on rule-of-thumb based approach which shorten the run-time. However, the solution may not be as optimal as that of the MILP solver 540. If in 520, it is determined that there are dynamic events in the event batch, the heuristics solver 550 may be selected. The RL solver 560 may be an agent-based solver where rewards and penalties are given to the solver based on actions. The RL solver 560 usually learns a model from past dispatch data and may use this learning to predict new dispatch schedule. Therefore, if in 510, it is determined that the batch size is large, but there is high correlation of historical dispatch data with type of events and personnel, then the RL solver 560 may be selected. Otherwise, if there is none or very little historical data available, then the selection process may go to 520, to select either the MILP solver 540 or the heuristics solver 550.

[0097] In an alternative embodiment, the historical dispatch data may be directly used determine the optimal dispatch schedule using a prediction model.

[0098] FIG. 14 shows a flow diagram of a method 1400 for computing the dispatch schedule according to various embodiments. The method 1400 may be an embodiment of the solution computing process 600. The method may include extracting event data in the event batch and personnel data relating to the selected personnel for the event batch, in 610. In other embodiments where the data group does not include event batches, the method may extract event data and personnel data from the data group. In 620, a task suitability score (TSS) may be computed for each event-personnel pair, based on past dispatch data. The TSS is described further with respect to FIG. 17. In 630, the travel time between events and personnel’s location’s may be determined. The computation of travel time is described further with respect to FIG. 18. In 640, the remaining workload of each personnel may be computed, based on their current and target workload. In 650, the selected solver may determine a dispatch schedule 660 based on the TSS and travel time. The selected solver may determine the dispatch schedule 660 further based on event information and personnel information. The event information may include location identifier (indicating if the location is indoors or outdoors), GPS coordinates, floor number if applicable, identity of the building or geolocation area, type, priority, workload, number of tasks, personnel requirement, task IDs, and tasks statuses. The event information is described further with respect to FIG. 15.

The selected solver may seek to achieve minimize overall response time and a balanced workload for the personnel. The selected solver may determine the solution while being subject to constraints. The dispatch schedule 660 may include an assignment to each event of the event batch, of at least one personnel from the data group. The dispatch schedule 660 may further include the timings where each personnel is scheduled to turn up to each event.

[0099] FIG. 15 shows an example of event information according to various embodiments. Workload, for example, may be defined as different levels of task activities involved in an event: Strenuous(S) - requiring high load of physical activity; Moderate (M) - requiring moderate amount of physical activity; and Light (L) - requiring minimum physical activity. In other words, workload refers to task complexity involved which may be determined during events reporting or in some cases, may also be determined from sensor data pertaining to the event. Each event may have multiple tasks as generated by the response plan generated by the response planning unit 114 and each task may be assigned an ID. Officer type requirement, i.e. personnel requirement, may indicate which personnel type should be assigned to each task of an event. For example, task T1 requires 2 fire (F) officer and task T2 requires 3 health (F) officer. There may be additional resource requirements like ambulance, fire vehicle etc. which are not shown in the figure. The event information may include any other relevant information. Task information may also include target task duration as determined by the response plan, for example, task T1 needs to be completed within 10 minutes of task start time. Task status may indicate the progress of each task: un-assigned means that the task is not yet assigned and pending assignment by the dispatch optimizer 116; pending means that the task is assigned but has not commenced, in-progress means that the assigned personnel have started working on the task. Events where all the tasks are completed will not be sent to the dispatch optimizer 116.

[00100] FIG. 16 shows an example of personnel information according to various embodiments. Personnel information may include location identifier (either indoor or outdoor), GPS coordinates, floor number if applicable, ID of indoor building or geolocation area, floor number if applicable, officer type (security, medical, electrician etc.), personnel status, travel mode, target workload etc. Personnel status may indicate whether the personnel is busy or available. For example: doing task action (DTA) may indicate that the personnel is busy, returning to base station (RTB) may indicate that the personnel has completed his current tasks, and is currently going to a base station, At base-station (ATB) may indicate that the personnel is available and is at a base-station, navigating to incident (NTI) may indicate that the personnel is travelling to an event location. Travel mode information may be used to determine travel time for a personnel to reach an event location and may be used in dispatch optimization for accurate arrival time estimation. Additional personnel information may include skill, experience, past dispatching data, and associated logs, fitness and health related data, target and current workload. To assist the dispatch optimizer 116 in determining the best personnel for a particular task, the task suitability score (TSS) may be computed for each event task.

[00101] FIG. 17 shows an example of TSS according to various embodiments. The TSS may be computed using a weighted sum of several factors like task specific skill, personnel’s task familiarity, personnel’s familiarity with respect to event location and past performance data. In an example, the TSS between all personnel and tasks may be stored in the form of a two-dimensional (2D) array as shown in FIG. 17. The TSS for each officer, i.e. personnel, and task is a number between 0 to 1. A TSS of 1 may indicate that the personnel is most suited for the task while 0 indicates that the personnel is least suited for the task.

[00102] FIG. 18 shows an example of travel time data according to various embodiments. The travel time data may be stored in the form of a 2D array between each personnel and all events, as well as between all events per officer. In 630 shown in FIG. 14, travel time may be computed for each possible route that a personnel could take i.e., from each personnel’s initial location to all the event locations and from one event location to another event location. The travel time may be computed based on the most optimal route for the personnel considering both indoor and outdoor routes, as well as situations wherever applicable, and the personnel’s mode of travel like walking, personal mobility devices, car etc. For indoor events, the travel time may include time required to navigate inside the building. Other information such as blocked access, crowding, elevator failure, etc. may also be factored into the computation of travel time. For outdoor events, information such as the traffic and weather conditions etc. may also be factored into the computation of travel time.

[00103] FIG. 19A shows an example of personnel target workload data and FIG. 19B shows an example of personnel remaining workload data, according to various embodiments, in relation to 640 shown in FIG. 14. The personnel remaining workload data (like shown in FIG. 19B), may be computed based on target workload (like shown in FIG. 19A) and current workload data. The personnel remaining workload is taken into consideration while determining the dispatch schedule. Without this information, the dispatch optimizer 116 may assign higher skilled officer more tasks and may cause them to be overworked.

[00104] The personnel’s target workload may be defined in terms of required time units for three different levels of task activities: Strenuous (S), Moderate (M), Light (L). Since the task activities are directly/indirectly related to fitness level of a personnel as well as past activity data, each personnel may have different target workload for each level of activity. Examples of target workload times for personnel 01 and 02 are shown in FIG. 19. tsm_/L denotes the total time a personnel can work on strenuous/moderate/light level of task activity without needing any break. In addition, target workload may also be accompanied by a mandatory recovery period /«, i.e., once target workload for an officer is reached, he/she would rest for the mandatory recovery period. In this example, personnel 01 is young, fit, and has a healthy profile and thus, may work for a longer period for the same level task intensity as compared to personnel 02, who is less fit. In the example shown, personnel 01 can either do 60 units of strenuous level task or 90 minutes of moderate level task or 180 units of light level task or any combination of these as long total target workload in within the limit.

[00105] The personnel’s current workload may be computed as sum of time units spent in different levels of activities. For example, consider 01 has done S level task for 20 units, M level task of 15 units, and L level task of 30 units since last recovery period or since beginning of current shift, whichever comes later. Then, current workload of personnel 01 is calculated as 20/60 + 15/90 + 30/180 = 0.67. In other words, the current workload of the personnel is 67% and his remaining workload is 33%. In other words, 01 can still do 20 units of S level or 30 units of M level or 60 units of L level or any other combination. This information may be used for computing task assignments for this personnel to utilize remaining 33% of his workload when distributing tasks and subsequently, accounting for a rest period also in the optimal dispatch schedule.

[00106] Joint optimization of multiple events and personnel may be performed using the task suitability scores, travel times, and remaining workload information to minimize objectives like overall incident response times and subject to rules and constraints for effective, feasible and globally optimal solution. In 650 of FIG. 14, joint optimization may be computed using one of the selected solvers and for every event batch or data group. Some of the common objectives or cost function, may include, for example, minimizing sum of response times (i.e., difference between completion time and occurrence time), prioritizing the dynamic events and more so for emergency events (i.e., higher penalty if an emergency event takes more time to complete), minimizing manpower cost (average footprint of manpower used in an event batch or data group to be kept minimum) etc.

[00107] In addition to objectives for optimization, rules and constraints may also be set so that dispatch optimizer 116 may use them to find only effective and feasible solutions. One example of the rules may be to allow other ongoing low priority events to be interrupted if the best possible officer for an emergency event is assigned to any other lower priority task. An example of a rule may be to minimize the number of interruptions. This factor may be included in objective function based on whether there is any emergency event in the batch. The following is a non-exhaustive list of examples of the rules and constraints:

• An event must start after its occurrence time.

• Precedence rule: In case of sequential tasks for an event, previous task must be completed before subsequent task can be started.

• Each task must be assigned to according to event’ s personnel type requirements.

• Each personnel must travel from their current location to event location before starting any task.

• Personnel schedule cannot be interrupted unless any new event of higher priority or any unexpected situation happens like delay in task, personnel stuck in traffic, etc.

• Personnel cannot work more than target workload times and must go for mandatory recovery period before resuming work. In other words, dispatch optimizer should assign tasks personnel according to remaining workload capacity and then account for recovery period in dispatch schedule. • Personnel travel time is determined based on traffic/weather data, indoor/outdoor route, indoor situations, mode of travel etc.

• Task completion time is computed based as a function of personnel’s TSS, i.e., if personnel’s TSS is very high (close to 1), he/she can finish the task much sooner as compared to any other personnel whole score is close 0. In general, task completion can be modelled as probability distribution function depending on TSS and task target duration.

[00108] FIG. 20 shows a flow diagram of a method of personnel assignment 2000 using at least one processor, according to various embodiments. The method may include part of the process 382 described with respect to FIGS. 3 and 4A. The method may include receiving an input data 310, in a process 2002. The input data 310 may include event data on a plurality of events, as well as personnel data on a plurality of personnel. The method may include splitting the plurality of events into a plurality of disjoint event subsets, in a process 2004. The method may include splitting the plurality of personnel into a plurality of disjoint personnel subsets, in a process 2006. Each personnel subset may be associated with a respective event subset of the plurality of disjoint event subsets. The method may include grouping the input data into a plurality of data groups. Each data group of the plurality of data groups may include event data of a respective event subset, and personnel data of a corresponding associated personnel subset, in a process 2008. The method may include concurrently computing a solution for each data group of the plurality of data groups, in a process 2010. The process 2010 may include the process 386 described with respect to FIG. 3 and the process 600 described with respect to FIG. 13. The solution may include an assignment to each event of the respective event subset, of at least one personnel from the corresponding associated personnel subset. The solution may be part of the dispatch schedule 320. Assigning the at least one personnel from the corresponding associated personnel subset, to each event of the respective event subset, may include subjecting the selected solver to an objective function. The objective function may include at least one of minimization of time to compute the solution, minimization of personnel cost, and even distribution of personnel workload.

[00109] The process 2010 may include determining at least one group attribute of the data group, and selecting a solver based on the determined at least one group attribute, like in the solver selection process 500 described with respect to FIG. 13. The at least one group attribute may be at least one of data size, event type and availability of historical assignment information. The process 2010 may further include assigning to each event of the respective event subset, the at least one personnel from the corresponding associated personnel subset, using the selected solver.

[00110] According to another embodiment, the process 2004 may include determining a personnel requirement of each event of the plurality of events, like in the method 420A described with respect to FIG. 5. The process 2004 may further include computing correlation values between the event and every other event of the plurality of events based on the determined personnel requirements, for each event of the plurality of events. The process 2004 may include grouping the plurality of events into the plurality of disjoint event subsets based on the computed correlation values. The process 2006 may include selecting at least one personnel from the plurality of personnel based on the determined personnel requirement of the events in the event subset, for each event subset of the plurality of disjoint event subsets, like in the process 427A.

[00111] The process 2004 may optionally further include applying a clustering algorithm on the event data in each event subset based on locations of the events in the event subset, to split each event subset into a further plurality of event subsets, like in the process 424C described with respect to FIG. 8.

[00112] According to an embodiment, the process 2004 may include applying a clustering algorithm on the event data in the input data based on locations of the plurality of events, like in the method 420B described with respect to FIG. 6. The process 2004 may further include determining a first travel time between the event and every other event of the plurality of events based on locations of the plurality of events, for each event of the plurality of events. The process 2004 may further include a second travel time required for each personnel of the plurality of personnel to travel to the event based on locations of the plurality of personnel, for each event of the plurality of events. The clustering algorithm may be applied on the event data, using the first travel time and the second travel time as constraints.

[00113] According to various embodiments, the method of personnel assignment 2000 may further include sorting the events in the respective event subset and their respective event data based on an event attribute of the events, into an ordered plurality of event batches, for each data group of the plurality of data groups. The process of sorting the events may include the sequential group process 410 described with respect to FIG. 4A. The event attribute may be one of priority level, occurrence time, and temporal proximity. [00114] In these embodiments, the process 2010 may include processing each event batch of the plurality of event batches sequentially in accordance with an order of the plurality of event batches. Processing each event batch may include selecting at least one personnel from the respective personnel subset based on personnel data of all personnel in the respective personnel subset, updating the event batch by adding personnel data of the selected at least one personnel to the event batch, determining at least one event batch attribute of the updated event batch, selecting a solver based on the determined at least one event batch attribute, and assigning to each event in the event batch, at least one personnel from the data batch using the solver. Assigning, to each event in the event batch, the at least one personnel from the data batch, using the selected solver, may include subjecting the selected solver to an objective function. The objective function may include at least one of minimization of time to compute the solution, minimization of personnel cost, and even distribution of personnel workload. Processing each event batch may further include generating a dispatch schedule using the selected solver, wherein the dispatch schedule indicates, for each event in the event batch, a time that the assigned at least one personnel is scheduled to respond to the event. Processing each event batch may further include selecting the at least one personnel further based on the dispatch schedule generated for a preceding event batch.

[00115] Sorting the events into the ordered plurality of event batches may include applying time-series clustering algorithm on the event data in the data group to group the events into clusters, like in the method 4 IOC. Sorting the events into the ordered plurality of event batches may further include determining a quantity of the events in each cluster, and merging two successive clusters based on the determined quantity of events in the successive clusters. [00116] FIG. 21 shows a conceptual diagram of an apparatus for personnel assignment 2100 according to various embodiments. The apparatus may include a memory 2102 and at least one processor 2104. The at least one processor 2104 may be communicatively coupled to the memory, like indicated by line 2106. The at least one processor 2104 may be configured to carry out the method of personnel assignment 2000 as described with respect to FIG. 20. [00117] According to various embodiments, a non-transitory computer-readable storage medium may be provided. The non-transitory computer-readable storage medium may be, for example, the memory 2102. The non-transitory computer-readable storage medium may include instructions executable by at least one processor, to perform the method of personnel assignment 2000. [00118] While the method is described with respect to assigning personnel to handle emergency and scheduled events, the method may also be applied to other applications that require automatic generation of a response plan that optimally dispatch personnel to the events.

[00119] While embodiments of the invention have been particularly shown and described with reference to specific embodiments, it should be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the invention as defined by the appended claims. The scope of the invention is thus indicated by the appended claims and all changes which come within the meaning and range of equivalency of the claims are therefore intended to be embraced. It will be appreciated that common numerals, used in the relevant drawings, refer to components that serve a similar or the same purpose.

[00120] It will be appreciated to a person skilled in the art that the terminology used herein is for the purpose of describing various embodiments only and is not intended to be limiting of the present invention. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises" and/or "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

[00121] It is understood that the specific order or hierarchy of blocks in the processes / flowcharts disclosed is an illustration of exemplary approaches. Based upon design preferences, it is understood that the specific order or hierarchy of blocks in the processes / flowcharts may be rearranged. Further, some blocks may be combined or omitted. The accompanying method claims present elements of the various blocks in a sample order, and are not meant to be limited to the specific order or hierarchy presented.

[00122] The previous description is provided to enable any person skilled in the art to practice the various aspects described herein. Various modifications to these aspects will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other aspects. Thus, the claims are not intended to be limited to the aspects shown herein, but is to be accorded the full scope consistent with the language claims, wherein reference to an element in the singular is not intended to mean “one and only one” unless specifically so stated, but rather “one or more.” The word “exemplary” is used herein to mean “serving as an example, instance, or illustration.” Any aspect described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects. Unless specifically stated otherwise, the term “some” refers to one or more. Combinations such as “at least one of A, B, or C,” “one or more of A, B, or C,” “at least one of A, B, and C,” “one or more of A, B, and C,” and “A, B, C, or any combination thereof’ include any combination of A, B, and/or C, and may include multiples of A, multiples of B, or multiples of C. Specifically, combinations such as “at least one of A, B, or C,” “one or more of A, B, or C,” “at least one of A, B, and C,” “one or more of A, B, and C,” and “A, B, C, or any combination thereof’ may be A only, B only, C only, A and B, A and C, B and C, or A and B and C, where any such combinations may contain one or more member or members of A, B, or C. All structural and functional equivalents to the elements of the various aspects described throughout this disclosure that are known or later come to be known to those of ordinary skill in the art are expressly incorporated herein by reference and are intended to be encompassed by the claims. Moreover, nothing disclosed herein is intended to be dedicated to the public regardless of whether such disclosure is explicitly recited in the claims. The words “module,” “mechanism,” “element,” “device,” and the like may not be a substitute for the word “means.” As such, no claim element is to be construed as a means plus function unless the element is expressly recited using the phrase “means for.”

Claims

1. A method of personnel assignment using at least one processor, the method comprising: receiving an input data comprising event data on a plurality of events and personnel data on a plurality of personnel; splitting the plurality of events into a plurality of disjoint event subsets; splitting the plurality of personnel into a plurality of disjoint personnel subsets, each personnel subset associated with a respective event subset of the plurality of disjoint event subsets; grouping the input data into a plurality of data groups, wherein each data group of the plurality of data groups comprises event data of a respective event subset and personnel data of a corresponding associated personnel subset; and computing a solution for each data group of the plurality of data groups, wherein the solution comprises an assignment to each event of the respective event subset, of at least one personnel from the corresponding associated personnel subset.

2. The method of claim 1, wherein computing the solution for each data group comprises: determining at least one group attribute of the data group; selecting a solver based on the determined at least one group attribute; and assigning, to each event of the respective event subset, the at least one personnel from the corresponding associated personnel subset, using the selected solver.

3. The method of claim 2, wherein the at least one group attribute is at least one of data size, event type and availability of historical assignment information.

4. The method of any one of claims 2 to 3, wherein assigning, to each event of the respective event subset, the at least one personnel from the corresponding associated personnel subset, using the selected solver, comprises: subjecting the selected solver to an objective function.

5. The method of claim 4, wherein the objective function comprises at least one of minimization of time to compute the solution, minimization of personnel cost, and even distribution of personnel workload.

6. The method of claim 1, further comprising: computing the solution for each data group of the plurality of data groups at least substantially concurrently.

7. The method of any one of claims 1 to 6, wherein splitting the plurality of events into the plurality of disjoint event subsets comprises: applying a clustering algorithm on the event data in the input data based on locations of the plurality of events.

8. The method of claim 7, wherein splitting the plurality of events into the plurality of disjoint event subsets further comprises: for each event of the plurality of events, determining a first travel time between the event and every other event of the plurality of events, based on locations of the plurality of events; for each event of the plurality of events, determining a second travel time required for each personnel of the plurality of personnel to travel to the event, based on locations of the plurality of personnel; and applying the clustering algorithm using the first travel time and the second travel time as constraints.

9. The method of any one of claims 1 to 6, wherein splitting the plurality of events into the plurality of disjoint event subsets comprises: determining a personnel requirement of each event of the plurality of events; for each event of the plurality of events, compute correlation values between the event and every other event of the plurality of events, based on the determined personnel requirements; and grouping the plurality of events into the plurality of disjoint event subsets based on the computed correlation values.

10. The method of claim 9, wherein splitting the plurality of personnel into the plurality of disjoint personnel subsets comprises: for each event subset of the plurality of disjoint event subsets, selecting at least one personnel from the plurality of personnel based on the determined personnel requirement of the events in the event subset.

11. The method of any one of claims 9 to 10, wherein splitting the plurality of events into the plurality of disjoint event subsets further comprises: applying a clustering algorithm on the event data in each event subset, based on locations of the events in the event subset, to split each event subset into a further plurality of event subsets.

12. The method of any one of claims 1 to 11, further comprising: for each data group of the plurality of data groups, sorting the events in the respective event subset and their respective event data based on an event attribute of the events, into an ordered plurality of event batches.

13. The method of claim 12, wherein the event attribute is one of priority level, occurrence time, and temporal proximity.

14. The method of any one of claims 12 to 13, wherein sorting the events and their respective event data into the ordered plurality of event batches comprises: applying time-series clustering algorithm on the event data in the data group to group the events into clusters.

15. The method of claim 14, wherein sorting the events and their respective event data into the ordered plurality of event batches further comprises: determining a quantity of the events in each cluster, and merging two successive clusters based on the determined quantity of events in the successive clusters.

16. The method of any one of claims 12 to 15, wherein computing the solution for each data group comprises: sequentially in accordance with an order of the plurality of event batches, processing each event batch of the plurality of event batches, wherein processing each event batch comprises: selecting at least one personnel from the respective personnel subset based on personnel data of all personnel in the respective personnel subset; updating the event batch by adding personnel data of the selected at least one personnel to the event batch; determining at least one batch attribute of the updated event batch; selecting a solver based on the determined at least one batch attribute; and assigning, to each event in the event batch, at least one personnel from the data batch, using the selected solver.

17. The method of claim 16, wherein assigning, to each event in the event batch, the at least one personnel from the data batch, using the selected solver, comprises subjecting the selected solver to an objective function comprising at least one of minimization of time to compute the solution, minimization of personnel cost, and even distribution of personnel workload.

18. The method of any one of claims 16 to 17, wherein processing each event batch further comprises: generating a dispatch schedule using the selected solver, wherein the dispatch schedule indicates, for each event in the event batch, a time that the assigned at least one personnel is scheduled to respond to the event.

19. The method of claim 18, wherein processing each event batch further comprises: selecting the at least one personnel further based on the dispatch schedule generated for a preceding event batch.

20. A system for personnel assignment, the system comprising: a memory; and at least one processor communicatively coupled to the memory and configured to: split the plurality of events into a plurality of disjoint event subsets; split the plurality of personnel into a plurality of disjoint personnel subsets, each personnel subset associated with a respective event subset of the plurality of disjoint event subsets; group the input data into a plurality of data groups, wherein each data group of the plurality of data groups comprises event data of a respective event subset and personnel data of a corresponding associated personnel subset; and compute a solution for each data group of the plurality of data groups, wherein the solution comprises an assignment to each event of the respective event subset, of at least one personnel from the corresponding associated personnel subset.

21. A non-transitory computer-readable storage medium, comprising instructions executable by at least one processor, to perform a method of personnel assignment comprising: splitting the plurality of events into a plurality of disjoint event subsets; splitting the plurality of personnel into a plurality of disjoint personnel subsets, each personnel subset associated with a respective event subset of the plurality of disjoint event subsets; grouping the input data into a plurality of data groups, wherein each data group of the plurality of data groups comprises event data of a respective event subset and personnel data of a corresponding associated personnel subset; and computing a solution for each data group of the plurality of data groups, wherein the solution comprises an assignment to each event of the respective event subset, of at least one personnel from the corresponding associated personnel subset.