Restricting access of certain vehicle types to locations

Use Case: Restricted Access for Specific Vehicle Types to Locations

In logistics operations, it's often necessary to restrict certain vehicle types from accessing particular locations. This feature is crucial for maintaining operational efficiency, adhering to safety regulations, and managing infrastructure limitations.

Consider a scenario where a distribution center has a dedicated loading dock designed exclusively for small vans and light-duty trucks due to space constraints and the type of goods handled there. Simultaneously, the same distribution center might have a separate, larger yard and loading bays for heavy-duty trucks and articulated lorries, which are unsuitable for the smaller dock.

SWAT allows you to define location restrictions by associating them with specific vehicle types. When optimizing routes, the system automatically ensures that only vehicles matching the allowed types are directed to these locations. This prevents operational bottlenecks and potential damage while also ensuring compliance with site-specific rules. This capability enables the seamless integration of diverse fleet types within a complex logistical network, all while maintaining strict control over access.

Implementation

To manage location access, SWAT introduces a structured VehicleType model.

The VehicleType Model: A Central Template

The core of this feature is the new VehicleType model. Think of it as a reusable template for creating vehicles. Each VehicleType you define within a project can specify a set of default properties, including:

• Vehicle type name (e.g., 'small_van')
• Routing profile and settings
• Capacity structure
• Cost profiles
• A set of associated labels

Creating Vehicles: Copy on Create

When you create a new Vehicle and associate it with a VehicleType, the system uses a "copy on create" approach.

• How it works: The vehicle's properties (like capacity and cost) are copied from the VehicleType at the moment of creation.
• Why it's useful: This gives you flexibility. You get a pre-configured vehicle based on the template, but you can still override or modify any of its specific properties later without changing the original VehicleType template.

How Vehicle Labels are Aggregated

A vehicle's final set of labels, which is crucial for matching it to jobs and locations, is automatically aggregated from three sources:

1. The VehicleType name itself (e.g., 'heavy_truck').
2. Any additional labels defined on the VehicleType (e.g., 'refrigerated', 'tail-lift').
3. Any labels you specify on the Vehicle instance itself during or after its creation.

For example, if you create a vehicle with the label 'urgent_delivery' and assign it to a VehicleType named 'large_van' that has the label 'high_capacity', the final vehicle will have all three labels: 'large_van', 'high_capacity', and 'urgent_delivery'.

Restricting Locations with OperationsLoCationVehicleType model

You can now directly control which types of vehicles can serve a specific OperationsLocation. This is done through a three-way link involving a simulation, a vehicle type, and the operations location itself. Only vehicle types explicitly connected to an operations location are permitted to visit it.

Because the simulation is part of this three-way connection, these restrictions are unique to each simulation. For even greater planning flexibility, these restrictions can also be temporarily adjusted within a simulation. This allows planners to experiment with different scenarios (e.g., allowing larger trucks at a location for a one-off event) without altering the location's master data. Furthermore, these constraints can be defined at the simulation template level. When set this way, the relationships will be automatically copied to all new simulations created from that template.

tip

Internally, the system automatically generates labels. These labels are created for operations locations and for vehicles, with the vehicles being determined based on their types.

The Logic of Combining Labels

When a booking needs to be routed to a restricted location, the system intelligently combines the booking's requirements with the location's restrictions. The final rule is created by joining the two sets of conditions with a logical AND.

This means a vehicle must satisfy both the booking's original label requirements and be an allowed type for the location.

Let's break it down:

1. Booking Requirements: A booking can have its own complex set of label requirements defined in booking.vehicle_labels.

   • Example: A booking requires a vehicle that has label '1', at least one of '2' or '3', and not both '5' and '6' at the same time. The logic would look like this:

     {"and": ["1", {"or": ["2", "3"]}, {"not": {"and": ["5", "6"]}}]}

2. Location Restrictions: The location's allowed_vehicle_types are converted into a logical OR condition.

   • Example: A location allows vehicles of type 'small_van' or 'light_truck'. The logic becomes:

     {"or": ["small_van", "light_truck"]}

3. Final Combined Logic: The system combines these two rules using AND. The resulting node.vehicle_labels requires a vehicle to meet all conditions.

   • Final Example:

     {
       "and": [
         {"and": ["1", {"or": ["2", "3"]}, {"not": {"and": ["5", "6"]}}]},
         {"or": ["small_van", "light_truck"]}
       ]
     }

This ensures that routing is precise: the assigned vehicle not only has the specific equipment or attributes needed for the job (Rule 1) but is also physically permitted to access the location (Rule 2).