Utilities have become very good at determining where an outage is, what equipment is likely involved and which crew should be sent. AMI last-gasp messages, SCADA events, customer calls, GIS network models and outage management systems can reduce a large field of possibilities to a probable device or section of conductor before a truck leaves the service center.
There is still a blind spot in that process. An outage management system can know that a job requires an overhead line crew and optimize the dispatch accordingly, while knowing very little about whether the physical equipment that makes the job executable is actually available.
That distinction matters when the required resource is not simply "a truck." Replacing a transformer, accessing an energized structure or setting a pole can require a particular combination of aerial reach, material-handling capacity, dielectric rating, payload, towing capability, digger derrick configuration and onboard equipment. A nominally available crew paired with the wrong vehicle is not an available restoration resource.
The resulting systems problem is straightforward to describe but harder to solve: utilities have built increasingly sophisticated models of the electrical network without always building an equally useful real-time model of the resources that can physically work on it.
Closing that gap means extending outage dispatch beyond crew availability. The workflow needs to move from outage detection to job classification, translate the job into crew and vehicle requirements, resolve those requirements against real-time field availability and only then commit the dispatch.
Step 1: The OMS Determines What Happened
Consider a simplified distribution outage. AMI reports multiple meters offline, the OMS groups the events against the network model, and SCADA indicates that a protective device has operated. Using connectivity from GIS, the system determines the probable outage area and identifies the device or network segment associated with the interruption.
At this stage, the OMS has several pieces of information that matter operationally:
Outage: INC-48217
Circuit: FDR-12
Probable location: Structure 12-447
Customers affected: 386
Network type: Overhead distribution
Device state: Open
Priority: High
Depending on the utility's architecture, additional analytics may provide a probable cause based on weather, previous incidents, fault indicators or vegetation information. The OMS may also know which crews are logged in, their current locations and which assignments they are already carrying.
That is enough to start optimizing a dispatch. It is not necessarily enough to determine whether the dispatch can be executed.
The missing step is converting the electrical event into a physical work requirement.
Step 2: Translate the Outage Into a Job Class
"Overhead outage" is too broad a classification for resource optimization. A crew investigating a fuse operation has different equipment requirements from a crew replacing a pole or changing a distribution transformer.
The first useful integration point is therefore a job classification layer. The incident attributes coming from the OMS can be mapped to a defined set of restoration job types. For example:
OMS event
↓
Probable equipment / damage
↓
Job classification
↓
Resource requirements
A suspected transformer failure might initially be classified as OH_TRANSFORMER_RESPONSE. A confirmed broken pole could become POLE_REPLACEMENT. A conductor-down event might require a different response depending on conductor type, voltage class, accessibility and whether tree damage is involved.
The classification does not have to be perfect before dispatch. Field assessment will always change some jobs. The objective is to provide enough information to prevent obviously incompatible resource assignments.
This is similar to the way utilities already encode skills and qualifications for personnel. An OMS or workforce management platform should not assign specialized electrical work solely because a crew happens to be geographically close. The same principle can be applied to vehicles and equipment.
Step 3: Define Vehicles by Capability, Not Just Asset Class
This is where the data model becomes important.
A vehicle record that says BUCKET TRUCK is useful for accounting and broad fleet reporting, but it is not sufficiently descriptive for restoration dispatch. Two aerial devices can belong to the same fleet class while having materially different operating envelopes.
A capability-oriented vehicle record might include attributes such as:
Vehicle: BT-217
Class: Aerial device
Working height: 60 ft
Side reach: 40 ft
Material handler: Yes
Material capacity: 2,000 lb
Insulated boom: Yes
Voltage rating: Utility-defined class
Payload available: 1,450 lb
Tow capability: Yes
Assigned depot: North Service Center
A digger derrick record would expose a different capability set: sheave height, digging radius, lifting capacity at specified radii, auger configuration, pole-handling equipment and trailer requirements.
The important change is conceptual. The dispatch system should not ask only, "Is a bucket truck available?" It should be able to ask, "Which currently available assets satisfy the capability envelope for this job?"
That turns the fleet inventory into a dispatchable resource model.
Step 4: Separate Asset Existence From Asset Availability
Knowing that BT-217 has the required capabilities still does not mean it can roll.
Vehicle availability is dynamic. A unit may be in preventive maintenance, waiting for a hydraulic repair, restricted following an inspection finding, assigned to another crew, missing required onboard equipment or physically located too far away to satisfy the restoration objective.
This is where a static fleet master becomes insufficient. Dispatch needs an operational availability state.
A useful state model might distinguish among:
AVAILABLE
ASSIGNED
IN_TRANSIT
ON_JOB
PM_SCHEDULED
OUT_OF_SERVICE
RESTRICTED
AWAITING_PARTS
INSPECTION_REQUIRED
Some of those states come from maintenance. Others come from AVL, telematics, workforce management or dispatch itself. The operational view has to reconcile them.
If the EAM system reports that BT-217 is active but the telematics platform shows it 90 miles away on another assignment, the vehicle is not meaningfully available for a nearby outage. If AVL places BT-304 in the service center but the maintenance system has an open safety-critical defect, proximity must not make it eligible for dispatch.
The question is therefore not whether the vehicle exists or even whether its engine is running. The question is whether it is dispatchable for this job at this time.
Step 5: Resolve Availability Across OMS, GIS, AVL and Maintenance
This is the integration point that determines whether the architecture actually works.
No single system necessarily owns every attribute required for the decision. GIS owns network location and connectivity. OMS owns the outage and restoration state. AVL or telematics provides vehicle location and, potentially, operating status. Workforce management provides crew status and qualifications. EAM or the fleet maintenance system provides maintenance restrictions, inspection state and asset availability. Other systems may own inventory, specialty equipment or depot assignments.
The dispatch layer therefore needs to resolve multiple sources into a common resource view:
┌─ GIS: network/location
│
Outage → Job class ──────┼─ WFM: crew/skills
│
├─ AVL: vehicle/location
│
├─ EAM: maintenance status
│
└─ Fleet master: capabilities
↓
Dispatchable resource set
The integration does not necessarily require every system to copy its data into the OMS. In many architectures, that would create synchronization and ownership problems. What matters is that the dispatch decision can query or consume authoritative state quickly enough to avoid assigning a resource that has become unavailable.
Latency matters here. A nightly interface may be perfectly adequate for cost reporting and completely inadequate for storm dispatch. If a vehicle is placed out of service at 14:03 and the OMS continues treating it as available until the next batch update, the integration is technically functioning but operationally useless.
Utilities should therefore define freshness requirements by data type. Vehicle capability may change rarely. Maintenance restrictions need to propagate quickly. AVL position may require updates measured in seconds or minutes. Crew assignment status may need near-real-time synchronization.
"Integrated" is not a binary property. The interface has to be fast enough for the decision it supports.
Step 6: Apply Hard Constraints Before Optimization
Once the OMS has a job classification and a current resource view, the dispatch problem can be separated into constraints and optimization.
Hard constraints determine whether an assignment is permissible:
required_working_height <= vehicle_working_height
required_material_handler = vehicle_material_handler
required_crew_skill ⊆ crew_qualifications
vehicle_status = AVAILABLE
maintenance_restriction = FALSE
Any crew-vehicle combination that fails a hard constraint should be removed from the candidate set before optimization begins.
Soft constraints determine which valid assignment is preferable. These can include travel time, crew continuity, overtime exposure, vehicle utilization, expected job duration, staging strategy and the probability that a resource will be needed for a more critical incident later.
This distinction is important because nearest-resource dispatch is not always optimal. The closest bucket truck might be the only unit in the district with the reach required for another known job. Sending it to a routine incident could force a much longer response when the second outage is classified.
During major events, resource preservation becomes part of dispatch strategy.
Step 7: Build a Dispatchable Crew-Vehicle Pair
Utilities often model crews and vehicles separately because they are managed in different systems. Restoration execution joins them.
Suppose the system has three candidate line crews and four nominally available aerial devices. The useful dispatch unit is not either list independently. It is the set of valid crew-vehicle-job combinations.
Conceptually:
Job J requires:
skill = overhead_distribution
aerial_height >= 55 ft
material_handler = true
Crew C1:
qualified = yes
status = available
Vehicle V1:
height = 60 ft
material_handler = true
status = available
(C1, V1, J) = VALID
Now add geography. Crew C1 may already be paired with V3, while V1 is at another depot. Re-pairing them adds mobilization time that a simplistic optimization model may not capture.
This is why resource state needs relationships as well as attributes. The system should know which crew has custody of which vehicle, what equipment is onboard, where each resource is located and whether changing the pairing is operationally reasonable.
A truck and a crew can each be "available" while the combination is not.
Step 8: Recalculate When Reality Changes
Dispatch optimization is not a one-time calculation. Storm operations are particularly hostile to static plans.
A crew arrives and discovers a broken pole rather than a blown fuse. The original bucket truck is no longer sufficient, and a digger derrick, pole trailer and additional material are required. Elsewhere, a vehicle develops a hydraulic fault. Another crew completes work 40 minutes earlier than expected. A road closure changes travel times between districts.
Each event changes the feasible resource set.
The architecture therefore needs event-driven recalculation. A change in job classification should trigger a new capability check. A maintenance status change should remove the vehicle from future assignments. A completed work order should release the crew and vehicle back into the candidate pool. Significant changes in location or estimated completion time should affect subsequent optimization.
The operating model begins to look less like traditional dispatch and more like continuous constraint solving.
That is particularly important during restoration peaks because the cost of a poor assignment compounds. Sending an under-capable vehicle to an incident does not merely delay that job. It consumes travel time, crew hours and vehicle capacity before the error is discovered, then requires another resource to be dispatched.
Step 9: Measure Dispatch Feasibility, Not Just Fleet Uptime
The integration also changes what utilities should measure.
Fleet availability is commonly expressed as a percentage:
available vehicles / total vehicles
That number can be healthy while restoration capability is constrained. A utility could have 95% fleet availability and still be unable to execute several high-priority jobs if the unavailable 5% consists of critical digger derricks or high-reach aerial devices.
A more operational metric would measure capability against expected work:
Dispatch feasibility = (jobs with a valid crew-vehicle-resource combination) / (jobs requiring dispatch)
The same concept can be calculated by district, vehicle capability, job class or storm scenario.
This produces information that both fleet and grid operations can use. Fleet managers can identify which vehicle classes create the greatest operational bottlenecks. Reliability and storm-planning teams can determine where mutual assistance or pre-staging is required. Capital planners can see whether an apparently adequate fleet contains capability gaps that only become visible during high-load restoration periods.
The result is a better connection between fleet investment and reliability performance.
Step 10: Feed the Results Back Into Planning
Once job, vehicle and restoration data are connected, utilities can analyze more than individual dispatches.
Which vehicle capabilities are most frequently constrained during major events? Which districts repeatedly borrow specialty equipment? How often does maintenance unavailability force a second-choice dispatch? How much restoration time is added when the preferred resource is unavailable? Are particular asset classes generating disproportionate operational risk as they age?
Those questions can inform preventive maintenance windows, vehicle replacement plans, depot assignments and storm staging.
They can also expose an important difference between nominal capacity and effective capacity. A utility may own 100 aerial devices, but if only 72 satisfy the capabilities, location and availability constraints associated with the modeled storm workload, 72 is much closer to the operational number that matters.
Over time, historical outage patterns can be combined with fleet availability to model that capacity before an event occurs. Weather forecasts and expected damage profiles can estimate likely job classes. Those job classes can be translated into equipment demand and compared with the current dispatchable resource set.
At that point, fleet readiness becomes an input to storm planning rather than something operations discovers after the first shift begins.
The OMS Should Know More Than Where to Send the Crew
Utilities have invested heavily in improving situational awareness of the distribution system. OMS, GIS, AMI, SCADA and increasingly ADMS platforms can provide operators with a detailed understanding of network state and help identify where field intervention is required.
The next integration problem is making the resource model equally credible.
An optimized dispatch is only optimal if it can be executed. That requires knowing not simply that a crew is available, but that the crew has the appropriate qualifications, that the required vehicle has the necessary capabilities, that the vehicle is mechanically and operationally available, and that the combined resource can reach the job within the restoration objective.
None of those requirements diminish the role of the OMS. They make its optimization problem more complete.
The outage tells the utility where work is required. The job classification determines what kind of work it is. Capability data defines what equipment can perform it. AVL and maintenance state determine what can actually roll. Only after those questions have been resolved does the dispatch become physically meaningful.
For utility operations, that is the distinction worth paying attention to. Knowing where the outage is has become increasingly sophisticated. Knowing whether the right resources can get there should be just as rigorous.