Recently in the blog, we reviewed a border checkpoint customer service model. The overview demonstrated how to model and analyze a variety of queuing related business problems. In this post, we will look at the technical features of the model: what it consists of, how it works, and what methods were used in its development.
You can find the model in AnyLogic, versions 7.3.7 and higher, including the free Personal Learning Edition. Go to the ‘Example Models’ tab on the start page. It is also in the AnyLogic Cloud.
Connecting AnyLogic libraries
To represent the process of crossing the border, the model uses specialized libraries: the Road Traffic Library and the Pedestrian Library. The Process Modeling Library then connects the behavioral logic of the vehicles and pedestrians from these libraries. Focusing on car travelers for simplicity, we will investigate the connections between libraries in detail. Let's get started!
While the car is moving toward the checkpoint and waiting to enter the inspection area, only the behavior of the car is important. Cars are the only agents operating in the model. However, this situation changes when the driver and passengers leave the car to pass the border.
When a car arrives at an inspection area, it exits the CarMoveTo block (toCheckpoint). In real life, the passengers, including the driver, then get out of the car. This process is implemented using the Split block (dropoffPassengers). We use a Split block and not a Dropoff block because the cars are not filled with passengers before they arrive at the checkpoint. Using Split allows a car to create passengers, as needed, for the drop off.
The Tourist agents lack pedestrian behavior logic when they are created. It is provided by passing the agent through the PedEnter block (getOffCar). The main characteristics of the agent are specified, such as position and speed. In our case, tourists appear in the checkpoint arrival area, where their car has stopped. From here on, they are seen as pedestrians and proceed, in parallel to the car, through the processes.
While passengers have their documents checked, their vehicles are made to wait for them using the Delay block (delayOnPassportControl). If a vehicle is not sent for an in-depth inspection, it is given a general inspection by the inspector from the Service block (Inspection).
After passengers are checked, they leave the pedestrian space through the PedExit block (readyToGetOnCar) and wait in a virtual queue for their car. On completing its own check, a car goes to the PickUp block (pickupPassengers), where it takes its passengers from the queue. Once more, the model now only considers vehicle movement.
If a car or its passengers cause suspicion, the car is sent to the in-depth inspection area. Logically the car enters the PickUp block (pickupDriver) to collect its driver, these are not self-driving cars! A queue for the drivers must be attached to the PickUp block because they do not have queues by default. Cars are only allowed to proceed to the inspection area after they have collected their driver. It is important to consider how the Pickup unit behaves, to avoid vehicles leaving without drivers.
Determining the number of cars in the queue at the border crossing point
We have detailed the process for travelers crossing the border but how can we describe the traffic flow to the border crossing? This is important, due to the capacity of the checkpoints.
Typically, models with cars use the CarSource block. This block stops generating cars if all the places on the road are taken. However, for the border crossing it is important to understand the total number of cars in the queue, even if it goes beyond the limit of the road segment in the model. To do this, we replace the CarSource block with both a Source and a Queue block, these do not require a road binding. Cars then enter the model if there is free space on the road and are routed to the CarEnter block (carAppearOnRoad). Otherwise, the car is held in a virtual queue and waits for space on the road.
Cars appearing on the road network proceed with the rest of the cars towards the border crossing in the CarMoveTo block (toCarStopBeforeCheckPoint). The cars in the virtual queue and those on the road are combined to give statistics about the checkpoint queue.
Allocating cars to inspection areas
The CarCheckPointLanes Agent Type describes how vehicles proceed through the border crossing. Cars are held at the entrance by the Hold block (hold), and enter the inspection area territory one by one. Cars follow a single lane, CarMoveTo block (toBorder), to the stop line, represented by the borderStopLine parameter, where the road divides. Before proceeding, the cars select a lane and a checkpoint. Arrival at a checkpoint removes the car from the toCheckPoint and hold blocks, allowing the next car to enter the inspection area territory.
Choosing a checkpoint has its own peculiarities. Cars select the lane with the least cars, using the function getLaneWithLessCars(), and take a place, function captureFreeCheckPoint(). Cars cannot pass others in a lane, meaning they must wait for access to free points if their way is blocked. If access is clear, cars will proceed to the furthest free checkpoint in the lane. This approach distributes the traffic flow evenly and avoids congestion at the checkpoints.
When a car occupies a checkpoint, the next vehicle in the queue is prohibited from following it, function blockLaneAfterCheckpoint(). The following car can proceed after the first car has been checked and has passed the stop line.
When the inspection is over, and depending on the results, the cars are sent to one of the CarMoveTo blocks.
- Cars with no detected violations proceed on their journey, toNeutralZone.
- Driver document problems mean a car must return to its original country, backToInitialCountry.
- Illegal cars go to a special area, toDetentionCenter.
Hierarchy and scalability of the model
To simplify the development process and to more easily examine a model, it can be separated into several sections. In this example, we grouped processes linked by common logic into user blocks: carCrossCheckPoint and busCrossCheckPoint. They describe the process of crossing the border for individual travelers in cars, and for groups on buses. The isolation of these processes into separate blocks makes the model more flexible. For example, the procedure for processing bus groups can be modified without affecting the top-level model. To learn more about creating custom blocks, check out our tutorial video.
To increase the capacity of the border checkpoint model, you can add additional checkpoints and checkpoint lanes (CheckpointLane). Doing so, does not require changing the logic of the model.
Managing model parameters using interactive elements
In our example, you can change the arrival rate of vehicles and the number of inspectors without stopping the simulation. This allows the effect of changes to be witnessed visually, as well as output statistically. For example, the effect on queue length when the number of inspectors is increased or the arrival rate changes.
Normally, the arrival rate slider is connected to the Rate property of the Source block. However, to allow both automatic and manual management of the arrival rate schedule, a different approach is used.
To store the current value of the arrival rate, the carRate parameter was created and connected to the carRateSlider. If manually set, the carRate parameter is the same as the CarSource Arrival Rate property. When a schedule is used, resetTimeStatEvent updates the carRate parameter and the slider every hour. This means the slider shows the current arrival rate. When you switch to the schedule, it automatically updates the value.
Our exploration of the model comes to an end here. If want to continue, we have many more models to investigate. The chocolate factory or the gas station models are good examples to begin with.
Take a look at part one of this model overview to read more of the usage scenarios and let us know your questions or suggestions in the comments below!
