Request Events

6 minute read

The following events handle ride requests within the simulation. A ride request represents a customer’s demand to be transported from a start intersection to a destination intersection. Requests are either generated by the simulation based on a predefined scenario or manually created via the visualization. Each request specifies the number of customers, the pick-up and drop-off locations, and an optional time window within which the service must be started.

When a ride request is received, the simulation creates the corresponding person entities and notifies all participants. The optimizer is then responsible for assigning a taxi to fulfil the request by planning an appropriate route. A request is considered served when all customers have arrived at the destination. If the request is not fulfiled before the latest service time, it expires and any remaining customers are marked as not served. The optimizer may also explicitly reject a request.

request:ride-request-received

Informs all participants that a new ride request has been received by the simulation. This event contains the full details of the request including the customer identifiers, locations, and time constraints. The corresponding person entities have already been created at the start intersection when this event is emitted.

Senders

  • SIMULATION

Receivers

  • OPTIMIZER
  • SIMULATION
  • VISUALIZATION

Data Fields

Field Type Required Description
id string Yes The unique identifier of the ride request.
label string Yes A human-readable label for the request.
start-intersection-id integer Yes The identifier of the intersection where customers are waiting for pick-up.
end-intersection-id integer Yes The identifier of the destination intersection.
number-of-customers integer Yes The number of customers to be transported.
customer-ids array Yes A list of person identifiers associated with this request.
latest-service-time number No The latest simulation time by which the request must be served before it expires.
earliest-service-time number No The earliest simulation time at which the request can be served. If omitted, the request can be served immediately.

Example

{
  "category": "request",
  "name": "ride-request-received",
  "data": {
    "id": "request-1",
    "label": "Request 1",
    "start-intersection-id": 243974386,
    "end-intersection-id": 243974397,
    "number-of-customers": 1,
    "customer-ids": ["person-request-1-0"],
    "latest-service-time": 100
  }
}

With an earliest service time:

{
  "category": "request",
  "name": "ride-request-received",
  "data": {
    "id": "request-2",
    "label": "Request 2",
    "start-intersection-id": 247422894,
    "end-intersection-id": 243974386,
    "number-of-customers": 1,
    "customer-ids": ["person-request-2-0"],
    "earliest-service-time": 20,
    "latest-service-time": 200
  }
}

Flow after Triggering

  1. The simulation creates person entities and sends person:added for each customer.
  2. The simulation sends request:ride-request-received to all participants.
  3. The optimizer should plan a route for a taxi to fulfil the request using taxi-fleet:plan-route.

request:ride

A command event that triggers the creation of a new ride request in the simulation. This event can originate from the simulation itself (based on a predefined scenario) or from the visualization (manual request creation). Upon processing, the simulation generates the corresponding person entities and emits request:ride-request-received.

Senders

  • SIMULATION
  • VISUALIZATION

Receivers

  • SIMULATION

Data Fields

Field Type Required Description
id string Yes The unique identifier of the ride request.
start-intersection-id integer Yes The identifier of the intersection where customers are waiting for pick-up.
end-intersection-id integer Yes The identifier of the destination intersection.
number-of-customers integer Yes The number of customers to be transported.
latest-service-time number Yes The latest simulation time by which the request must be served before it expires.
earliest-service-time number No The earliest simulation time at which the request can be served.

Example

{
  "category": "request",
  "name": "ride",
  "data": {
    "id": "request-1",
    "start-intersection-id": 243974386,
    "end-intersection-id": 243974397,
    "number-of-customers": 1,
    "latest-service-time": 100
  }
}

Flow after Triggering

  1. The simulation receives request:ride.
  2. The simulation creates person entities at the start intersection.
  3. The simulation sends person:added for each created person.
  4. The simulation sends request:ride-request-received to all participants.

request:reject

A command event sent by the optimizer to explicitly reject a ride request. This indicates that the optimizer has decided not to fulfil the request, for example because no taxi is available, or the request cannot be served within the time constraints.

Senders

  • OPTIMIZER

Receivers

  • SIMULATION

Data Fields

Field Type Required Description
id string Yes The unique identifier of the ride request to reject.
explanation object Yes Possible explanations for the rejection.

Example

{
  "category": "request",
  "name": "reject",
  "data": {
    "id": "request-1",
    "explanation": object
  }
}

Flow after Triggering

  1. The optimizer sends request:reject.
  2. The simulation processes the rejection and sends request:rejected.
  3. The associated persons are marked as not served and removed from the simulation.

request:rejected

Confirms that a ride request has been rejected. This event is sent by the simulation after processing a request:reject command from the optimizer.

Senders

  • SIMULATION

Receivers

  • OPTIMIZER
  • SIMULATION
  • VISUALIZATION

Data Fields

Field Type Required Description
id string Yes The unique identifier of the rejected ride request.
explanation object Yes Possible explanations for the rejection.

Example

{
  "category": "request",
  "name": "rejected",
  "data": {
    "id": "request-1",
    "explanation": object
  }
}

request:customer-arrived

Informs all participants that a customer associated with a ride request has arrived at the destination intersection. This event is emitted for each individual customer when they are dropped off. Once all customers of a request have arrived, the request:ride-request-served event is emitted.

Senders

  • SIMULATION

Receivers

  • OPTIMIZER
  • SIMULATION
  • VISUALIZATION

Data Fields

Field Type Required Description
request-id string Yes The identifier of the ride request.
customer-id string Yes The identifier of the person who arrived at the destination.

Example

{
  "category": "request",
  "name": "customer-arrived",
  "data": {
    "request-id": "request-1",
    "customer-id": "person-request-1-0"
  }
}

request:customer-not-served

Informs all participants that a customer associated with a ride request could not be served. This event is emitted when the request expires (i.e., the latest service time is reached) and the customer has not been transported to the destination.

Senders

  • SIMULATION

Receivers

  • OPTIMIZER,
  • SIMULATION,
  • VISUALIZATION

Data Fields

Field Type Required Description
request-id string Yes The identifier of the ride request.
customer-id string Yes The identifier of the person who was not served.

Example

{
  "category": "request",
  "name": "customer-not-served",
  "data": {
    "request-id": "request-2",
    "customer-id": "person-request-2-0"
  }
}

request:ride-request-served

Informs all participants that a ride request has been fully served. This event is emitted when all customers associated with the request have arrived at the destination intersection.

Senders

  • SIMULATION

Receivers

  • OPTIMIZER,
  • SIMULATION,
  • VISUALIZATION

Data Fields

Field Type Required Description
id string Yes The unique identifier of the served ride request.

Example

{
  "category": "request",
  "name": "ride-request-served",
  "data": {
    "id": "request-1"
  }
}

request:ride-request-expired

Informs all participants that a ride request has expired because the latest service time has been reached. When a request expires, any customers that have not yet arrived at the destination are marked as not served via request:customer-not-served events. Note that a request can be both partially served and expired — if some customers arrived before the deadline but others did not.

Senders

  • SIMULATION

Receivers

  • SIMULATION

Data Fields

Field Type Required Description
id string Yes The unique identifier of the expired ride request.

Example

{
  "category": "request",
  "name": "ride-request-expired",
  "data": {
    "id": "request-1"
  }
}

Updated: