A Simple Discrete-Event Simulation: Part 39

Today I continue thinking about the details of how entities interact with each other at intersections (and in general).

The upper two sections of the figure below describe various dimensions that must be considered. The top section describes a rectangular entity, which might represent a vehicle. The next section down describes a circular entity of the type we’ve been working with. We’ll begin by describing what all the dimensions represent.

  • location definition (T): This is the primary definition of where an entity is on a path (the T is for traversal). It is defined in terms of the distance traversed along a path. The x- and y-locations in space are derived from that. For a rectangular entity the location is defined from the front center of the rectangle. For a circular entity the location is defined from the center, though in theory it could be redefined to represent the forward edge of the circle. That might be better from a consistency standpoint. The location definition is the only definition that defines the location of the entity in space; all of the other values are relative to the location definition or other points within the entity.
  • extension definition (E): This defines a point at or near the back end of the entity. The back end of a rectangular entity would also have to move along the path, though calculating its x- and y-locations would be more complicated. The distance between the location definition and extension definition would not change, so placing it on a path would have to consider junctions and angles between two or more paths.
  • separation clearance (C): This is the distance that must separate entities in any direction.
  • forward clearance (F): If the location definition is not at the leading edge of the entity, this defines the distance to the leading edge.
  • backward clearance (B): This is defined as the distance to the back end of the entity from the location definition or the extension definition. For a circular entity this is equal to the radius of the circle (or it could be the diameter). For a rectangular entity this is the distance to the back end from the extension definition. This distance might be set to zero for a car, as an approximation, but it might have a meaningful value for a box truck where the rear end extends well beyond the rear axle which serves as its pivot point and extension definition.
  • side clearance (S): It is assumed for the time being that all entities will be symmetrical across the direction of travel. This distance is from the center line of the entity to either side of the entity. For a circular entity this distance is equal to the entity’s radius.

I’m also going to define a distance (N), which is the distance toward the intersection node, along one or more path segments (without branches). The length of the current path will be referred to as (L).

Looking at the lower section of the image we can analyze how the described measurements affect the movements of entities across node junctions.

  • Following an entity in general: No following entity’s forward-most location (defined by T+F) can move beyond a traverse distance defined by T-E-B-C.
  • Approaching an intersection at which a different entity will arrive first or is currently passing through: The approaching entity must stop (that is, the leading edge defined by L+F cannot go beyond this point) at a distance from the intersection defined by N-S-C if the angle between converging paths is greater than 45 degrees. If the angle is less than 45 degrees then this distance is defined by N-E-B-C. For circular entities N-S-C should be the same as N-E-B-C. Think of this like cars merging into traffic. A car turning in from a side road (angle > 45 degrees) needs clearance of a car width plus a buffer. A car merging in at a shallower angle ( < 45 degrees) would need an entire car length plus a buffer.

This line of thought suggests that it might be a good idea to have each node store the distance along all subsequent paths to the next intersection or activity node.

The implementation has to be worked out in detail, but it seems like we may be able to accomplish what we want using a fairly small set of generalized rules, which is always desirable.

This entry was posted in Simulation and tagged . Bookmark the permalink.

Leave a Reply