Car Agent

When a car agent is forked by the simulation engine, it reads the road network specification file to build its own road network database. This database will be queried by the agent logic during simulation. Instead of accessing a common road network database built by the simulation engine, each car agent builds its own road network database even though the content of each car agent’s database is the same. This design is based on the performance consideration that the road network information query is very frequent and needs a fast response from the database.

Thus, we trade the memory space for the simulation speed. In addition, the car agent reads the obstacle specification file to construct visual obstacles. The obstacle

information is also stored in the road network database. Moreover, the car agent also reads the car profile mapping file to know which car profile is assigned to it and then reads the corresponding car profile file. As stated before, different car profiles define different moving characteristics with respect to maximum speed, maximum acceleration, and maximum deceleration. The difference and change on vehicular moving speed result in the changing of the vehicular ad hoc network topology during simulation. The topology changing affects the operations of network communication protocols and the performance of application programs. Generally speaking, the dynamics of topology is one of the considerable parameters when studying ad hoc network issues. A user can change this parameter by modifying the five car profiles and changing the car profile mapping ratio.

A car agent is an independent process that communicates with the command server located within the simulation engine through its car/signal information socket-interface API’s, which are TCP-based. Besides, a car agent exchanges messages with other car agents through its network packet socket-interface API’s, which are TCP-or UDP-based. The operations of packet exchange and the content carried in each packet are defined by a user to satisfy the requirements of an ITS application. NC-TUns provides users with the flexibility to add or modify any operation in a car agent.

In Section 3.5.5, we mentioned that a socket opened by a NCTUns process is a NCTUns socket that operates based on the virtual time. That means, by de-fault, both the car/signal information socket and the network packet socket operate based on the virtual time within a car agent. However, the former must operate based on the real time. This is because when a car agent starts a request-reply communication with the simulation engine through the TCP-based car/signal in-formation socket, the virtual time maintained in the simulation engine is frozen to avoid unexpected virtual time advance. Until the car agent finishes its request-reply communication and signals the simulation engine about the finish, the simulation engine continues advancing the virtual time. During the request-reply communica-tion, if the car/signal information socket is based on the virtual time, all the TCP

timers malfunction because no timer expiration can be expected. In other words, a dead lock situation may occur when the request-reply communication relies on the virtual time advancing to finish and the virtual time advancing depends on the com-pletion of the request-reply communication. In order to support the real time socket within a car agent, NCTUns provides a customized system call. When a car agent opens a socket, it calls the system call to clear (set to zero) the node identification number in the socket’s corresponding sock data structure in the kernel space. After that, the kernel does not recognize the socket as a NCTUns socket and the socket starts operating based on the real time.

Figure 4.5 shows the communication between the car agent and the simulation server, including the virtual time based network packet transmission path and the real time based request-reply communication. The operations over network packet transmission path are the same as those presented in Section 3.2.3. For example, if Car Agent 1 (belonging to Mobile Host 1) wants to send a TCP/UDP network packet to Car Agent 2 (belonging to Mobile Host 2), it first sends out the packet through its network packet socket. The packet is then sent to Tunnel 1, which is Mobile Host 1’s associated tunnel interface. After the simulation server moves the packet from Tunnel 1 to Mobile Host 1’s Interface module, the packet goes through the MAC- and PHY-layer protocol simulations. Then, the packet is moved from Mobile Host 2’s Interface module to Tunnel 2, which is Mobile Host 2’s associated tunnel interface. Finally, Car Agent 2 obtains the packet through its network packet socket.

Regarding the real time based request-reply communication, it is a normal TCP connection built between a car agent and the command server located within the simulation server. Because the car agent and the simulation server are run on a single machine, the TCP connection between them passes through the loop back interface provided by most Linux operating systems. The loop back interface’s IP address is usually 127.0.0.1. When a request packet is sent out by a car agent over the TCP connection, the kernel recognizes it as a normal TCP packet instead of a NCTUns TCP packet. Thus, the kernel does not translate this packet’s IP address to the

Tunnel 2

TCP/UDP TCP TCP TCP TCP TCP/UDP

Command Server

Figure 4.5: The communication between the car agent and the simulation server source-destination-pair IP format and operates its corresponding TCP operations based on the real time. Because the packet’s destination IP address is 127.0.0.1, at the IP layer the kernel routes it to the loop back interface and it is looped back immediately to the IP layer. When the command server obtains the request packet, it queries the car or signal information database for requested data and then sends a reply packet back to the car agent. The kernel treats the reply packet the same way as the request packet.

A car agent is the mobility controller of its associated vehicle simulated in the simulation engine. The agent logic in a car agent is the decision maker that deter-mines when to make an action. After setting up the connection with the command server located within the simulation engine, the agent logic first retrieves the node identification number of the associated vehicle through the customized system call

that is mentioned in Section 4.2. With the node identification number, the agent logic informs the command server to activate its associated vehicle in the simulation engine. This validates that vehicle’s corresponding data within the car informa-tion database. Next, the agent logic queries for its initial/current posiinforma-tion from the command server. The command server retrieves the queried position from the car information database and then sends it back to the agent logic. Before moving a vehicle from its initial position, the agent logic sets the current speed and current acceleration of the vehicle to zero.

During simulation, the agent logic periodically updates/accesses the car and sig-nal information databases through the car/sigsig-nal information socket-interface API’s.

For example, the agent logic may store/retrieve the current moving direction, current speed, current acceleration, current position of its associated vehicle, or retrieve the state of a traffic light that is nearest in front of its associated vehicle. The command server provides not only update/access services but also data-analyzing services. In the case that an agent logic tries to retrieve the state of a traffic light through the command server, the command server first retrieves the current position of the ve-hicle controlled by the agent logic from the car information database and all traffic lights’ positions from the signal information database. Because the command server does not have the road network information, the nearest traffic light in front of the vehicle is obtained by doing some mathematical calculations based on the informa-tion provided by the agent logic. For example, the agent logic specifies the distance within which the nearest traffic light ahead of the vehicle should be returned by the command server. After the command server identifies the nearest traffic light, it sends the state of the traffic light to the agent logic. With this information, the agent logic can now control the vehicle to either drive across a crossroad if the traffic light is green or stop it at a crossroad if the traffic light is red.

Moreover, the agent logic can retrieve the positions of the vehicles that is located within a specified area to its associated vehicle’s position. Because the command server does the analysis considering only the vehicular positions, the agent logic has to analyze the retrieved positions again considering the view obstacles. If the

straight line between the associated vehicle’s position and one retrieved vehicle’s position crosses any obstacle’s rectangular area, then in the agent logic’s viewpoint the retrieved vehicle should not be seen. For example, in Figure 4.6, the agent logic on behave of vehicle A’s driver tries to find out the nearest vehicle that is located within a sector area in front of vehicle A. The agent logic has to specify the the angle of the sector (say, 60 degrees) and the radius of the sector (say, 50 meters) so that the command server can search those qualified vehicles and return them to the agent logic. Like that shown in Figure 4.6a, vehicle B and vehicle C are qualified vehicles.

After the agent logic obtains the returned vehicles’ positions, it checks if any obstacle locates between its associated vehicle (say, vehicle A) and those returned vehicles.

Like that showed in Figure 4.6b, because the obstacles around the crossroad blocks the viewpoint from vehicle A, the visual area from vehicle A does not include the whole sector area but only the gray part within the sector area. As a result, vehicle B should not be seen by vehicle A and the nearest vehicle in front of vehicle A is finally determined to be vehicle C instead of vehicle B.

Although the command server can obtained the obstacle information from the obstacle specification file that is read by the simulation engine, it does not use the information when dealing with the above-mentioned request. This is because the request is a general-purpose request. A car agent usually issues the request to obtain those vehicles located within a specified area. Then, the car agent may combine the retrieved result with additional information to do advanced analyses, such as finding the nearest vehicle located on the right or left lane in front of or in the back of itself.

The additional information may be the obstacle positions, the road block positions, and/or other information. Which kinds of information are required depend on what operation an agent logic wants to do. Thus, the command server does not do that for an agent logic but only provides general-purpose functions for an agent logic to call.

Other request commands are also provided for the agent logic to collect compre-hensive information to make driving decisions. For example, the agent logic obtains the direction of a road ahead of the vehicle so that the vehicle can move in the

C

B

A

(a) The simulation engine returns a driver’s viewpoint to the car agent only considering the relationship of vehicular position.

Obstacle Obstacle

Obstacle Obstacle

A B

C

(b) The car agent determines a driver’s viewpoint considering ad-ditionally the locations of all view obstacles based on the simulation engine’s return.

Figure 4.6: Two phases to simulate a driver’s viewpoint

correct direction on the road. Another example is that the agent logic obtains the information of neighboring lanes so that the vehicle can safely change lanes and/or overtake other vehicles. Yet another example is that the agent logic obtains the information of the crossroad ahead of the vehicle so that the vehicle can make a turn smoothly. On top of the default autopilot intelligence, a user can freely add more intelligence into the agent logic of a car agent. A user can also replace the default autopilot intelligence with more advanced autopilot intelligence.