No, it will not. The application focuses on intersection crosswalks only.
SPaT/MAP messages are part of our V2I and impaired pedestrian application. It is there.
It is up to 12 devices per intersections. Depending on the intersection width, you may need 3 or 4 devices per crosswalk. We anticipate 10 intersections so that is up to 120 devices.
The LTE based is to help impaired pedestrians navigate through the intersection/crossing. The Flare [ed. FLIR] detection is able to detect a pedestrian in the crosswalk and send the message to vehicles approaching or turning to the crosswalk by activating bits in the SPaT message.
It is the same safety device that we are using on our light vehicles. The physical ASD may differ between vehicles, but the functionality is the same.
We have adopted IEEE 1609.2 for DSRC messages. DTLS for the TMC connections are being used. All the communications are point-to-point and are authenticated from inside the device to inside the device. The networks are carefully firewalled and only allow traffic to designated IP addresses and port numbers.
Yes. For the pedestrian application. The impaired pedestrian application is pushing the SPaT information to both the RSU and the TMC.
SPaT/MAP messages will be pushed to the pedestrian through the Amazon Cloud and to the approaching vehicles using DSRC. The location accuracy is a subject for testing that we are going to be doing this week. We are just getting the RSUs and we will be working on it in the next week.
A location augmentation device is being added to the cellphones for impaired pedestrians to improve their location accuracy.
It is all based on the sample. Vehicles in motion in NYC is over a million at a given time. It is hard to predict but the sample will be sufficient. It is based on location, user, etc. We are addressing fleets that mostly use the middle of Manhattan – thus we hope for significant interaction.
The backhaul is all IP/v4. Right now, it is not clear if we will go to any IP/v6 to transmit data.
Our communications are specific to the connected vehicle projects. We are not interacting with any other project or systems. Our messages are directed only to/from the ASD and RSU in the designated DSRC 5.9 GHz band. Our ASDs only draw any significant current when the ignition switch is on and draw less than 25 microamps when the ignition switch is off after shutting down. This is within SAE standards for such devices; we don’t know the effect on vehicle distance for an all-electric vehicle.
The use cases of the PIDs are to provide the visually-impaired pedestrians information to know their orientation (cross walk they are facing), the status of the pedestrian signals (WALK, F-DON’T WALK, Steady DON’T WALK – and how much time is remaining to cross. We will be working with the visually impaired community to develop a user interface and experience which provides benefit. We will be collecting data from the use of the PID to assist in the evaluation and tuning.
The driver will receive audio alerts only. The data we are extracting from the in-vehicle device uses the speed, XY location, the braking, left turn signals, etc. and exchange all other information with other in-vehicle devices. This is the type of information connected vehicles will be exchanging, when they meet in a certain zone. Algorithms within the ASD will analyze information and identify potential conflicts and which vehicles pose a threat and will provide an alert if necessary to help the operator avoid a collision (if any).
Each vehicle is different.
Generally, the data is transferred back to the TMC. Remaining information will be kept for performance evaluation purposes. This is our way of protecting our participant drivers’ information.
The data is in the same format within the TMC and we have been working with our vendors to establish the protocol for uploading and format for all log and uploaded data.
We do not see the VIN. We do not have that personal information. The VIN is only used by the local device to determine if the ASD has been moved to a different vehicle. The VIN information is not transmitted to the TMC and is not available at the TMC.
We will have better feedback later. That also goes with the saturation issue as well.
Most of it has been completed by the vendors and we do not have any visibility into that. Everything has to come together to proof it all out.
Each vehicle is different. We have had better success with the F150s and F250s.
The vehicle dimension information (e.g. height) is stored internal to the ASD. When the vehicle is approaching an RSU indicating a height restriction, it can provide the driver an alert of the impending over height condition. Or, if there is a designated specific route for cars only, restricted vehicles can be alerted. It depends on the stored information on the OBU.
The pilot is in the prototype period. It is expected that by the end of August we will start the official prototype period. We are looking for production, procurement, and installation time in early November. By the end of the year, we will have had significant installation completed and operational. We will complete our goal of Phase 2 by mid next year or earlier.
The OBU is pushing to the secondary device. The ASD only listens.