usdot-fhwa-stol / carma-cloud Goto Github PK

Types of Issue

• Anomaly report (something appears to not work correctly)
• Enhancement request (describe the enhancement being requested)
• Other (please ensure the description clarifies why the issue doesn’t fall into either of the above categories)

Descriptive summary

During Freight Work Zone Management testing, the team discovered large latencies during the process of V2XHub receiving a TrafficControlRequest (TCR) and broadcasting corresponding TrafficControlMessages (TCMs). The test set up for these evaluation runs sometimes included one vehicle transmitting TCRs at 1 Hz, and sometimes included three vehicles simultaneously transmitting TCRs at 1 Hz. CARMA Cloud was setup to provide 9 TCMs for each of these TCRs.

From these test runs, the RSU pcap logs, V2XHub docker logs, and CARMA Cloud tomcat logs were analyzed.

After conducting data analysis on the CARMA Cloud tomcat logs, some instances of a large delay between CARMA Cloud receiving a TCR from V2XHub and sending all corresponding TCMs to V2XHub were found. The average CARMA Cloud processing time (Time between receiving a TCR and sending all of the corresponding TCMs) was ~1.68 seconds for all April 22nd data (with 50% occurring under 1 second), but it was found that occasionally CARMA Cloud received a TCR and took 10-20 seconds to send a corresponding TCM to V2XHub. Some instances of delays over 100 seconds were found as well. It is currently unclear what caused these delays.

V2XHUB version where this issue was discovered

CARMA Cloud version from April 22nd-April 25th, 2022

Expected behavior

The following metric was developed in order to evaluate the performance of the system, and does not indicate pass/fail of the system; however, the round trip times for TCR/TCM processing are expected to be much lower than the actual behavior found during testing:

• Freight Workzone Metric 4: Once CC receives a TCR from the vehicle (via CS), it sends a TCM to CS within 0.1 seconds.

Actual behavior

• Freight Workzone Metric 4: Average of 1-2 seconds, but can occasionally spike to 100+ seconds.

Steps to reproduce the actual behavior

Conduct Freight Work Zone Management evaluation runs (1-vehicle or 3-vehicle versions) per the verification test plan for the use case.

Related work

Related V2XHub Issue: Click Here

Summary

As CARMA Cloud, I’ll be able to identify the downstream RSU’s along the ERV’s route, so that I can relay an approaching ERV's BSM messages to v2xhubs.
Given the registered RSU locations and the received ERV BSM, the RSUDetectingService shall calculate the list of downstream RSUs to identify which v2xhub server ports to forward the BSM hex to.

Detailed design refer to:
https://usdot-carma.atlassian.net/browse/CF-416

Reasoning for new functionality

Emergency Response Use Case

Summary

Analysis script to generate ERV use case verification metrics.
https://user-images.githubusercontent.com/62157949/231208075-8b10902d-b8a3-4988-8c44-12e2cfe96ac0.png

Commit

NA

Expected Behavior

Script is uploaded to github
Report generated by the script provide sufficient information for the verification testing

Actual Behavior

No script

Steps to Reproduce the Actual Behavior

NA

Related Work

No response

A security vulnerability was identified with log4j 2 version that is currently being used (https://logging.apache.org/log4j/2.x/security.html) that requires an update to address it.

Summary

During the integration testing, the RSU GPS is sending geolocation in 100th micro degree. The cloud parser logic needs to update the conversion from 100th micro degree to degree by dividing geolocation by 100000000. Update the map center location and zoom to the testing facility at Suntrax

Version

Develop (Commit 10baa9f)

Expected Behavior

RSU GPS can be plotted on the map correctly.

Actual Behavior

RSU GPS cannot be plotted on the map correctly.

Steps to Reproduce the Actual Behavior

Run carma-cloud
Run v2xhub and enable ERVCloudForwardingPlugin

Related Work

No response

Most of the request/response XML tags usage are described in the ASN definition, refer to https://github.com/usdot-fhwa-stol/carma-cloud/blob/develop/cc_traffic_control_messages_asn1.txt. Some tags that add additional information about the web API are not in the ASN definition, such as list=true, port etc... To help users to understand the service functionalities with different tag options, more details docs need to be added for those tags.

Create Issue and Pull Request templates to guide team to fill out required information.
Making all those fields on the template mandatory.

Types of Issue

• Anomaly report (something appears to not work correctly)
• Enhancement request (describe the enhancement being requested)
• Other (please ensure the description clarifies why the issue doesn’t fall into either of the above categories)

Descriptive summary

For Integrated Highway Prototype II (IHP2) project, one of the objectives is to reduce traffic congestion. Speed harmonization algorithm is proposed, and aims to adjust traffic speed upstream of a traffic bottleneck to allow vehicles slow down and pass the bottleneck at a reasonable speed, and avoid sudden stop at the downstream queue. This algorithm will be developed as a new feature in the carma-cloud application. The carma-cloud application listens to incoming traffic control requests (TCRs) from vehicles, and responds with traffic control messages (TCMs) that has the calculated advisory speed using speed harmonization algorithm. In addition, a new user interface will be added for the end users to adjust any input parameters, and upload any necessary detector data used by this algorithm.

CARMA Cloudversion where this issue was discovered

CARMA Cloud version 3.8.0

Expected behavior

NA

Actual behavior

NA

Steps to reproduce the actual behavior

NA

Related work

#26

Summary

Carma-cloud needs the new web API to accept an HTTP post request from v2xhub client. The request payload includes a plain ERV BSM in XML format and ERV BSM hex string. Carma-cloud stores this ERV BSM hex and UTC timestamp in an instance variable to keep track of the received ERV BSM hex, and the UTC timestamp indicate when the BSM is received. If the ERV BSM hex is already stored in the variable and the stored duration is less than configurable fixed duration, it shall ignore it. If ERV BSM is not stored in the variable, it will store the ERV BSM hex string and UTC timestamp in the variable, then process the ERV BSM. Upon every store operation, it will clear any ERV BSMs from the variable if the stored durations for the BSMs are greater than the configurable duration.

Stored duration = current timestamp – timestamp when storing the BSM hex in the variable

Reasoning for new functionality

Emergency Response Use Case

Created 4 notopen geofence on carma-cloud test website.

1. Clicking on edit icon, then selecting the 1st, 3rd, and 4th geofences on the map, it pops up an edit control dialog. After updating the vehicle types, and label, click on save. It displays edit successful. But when we double check the edit control, the data was never updated. Below is a snippet pf the tomcat logs:

67.205.181.210 - - [05/Apr/2022:14:06:09 +0000] "POST /api/ctrl/delete HTTP/1.1" 200 -
67.205.181.210 - - [05/Apr/2022:14:06:09 +0000] "GET /api/ctrl/18/74893/100228 HTTP/1.1" 200 208135
67.205.181.210 - - [05/Apr/2022:14:06:10 +0000] "GET /api/ctrl/18/74895/100228 HTTP/1.1" 200 98631
67.205.181.210 - - [05/Apr/2022:14:06:10 +0000] "GET /api/ctrl/18/74893/100227 HTTP/1.1" 200 79435
67.205.181.210 - - [05/Apr/2022:14:06:10 +0000] "GET /api/ctrl/18/74894/100227 HTTP/1.1" 200 132454
67.205.181.210 - - [05/Apr/2022:14:06:10 +0000] "GET /api/ctrl/18/74895/100227 HTTP/1.1" 200 109465
67.205.181.210 - - [05/Apr/2022:14:06:10 +0000] "GET /api/ctrl/18/74894/100228 HTTP/1.1" 200 223845
161.69.123.10 - - [05/Apr/2022:14:06:13 +0000] "POST /api/ctrl/saveEdit HTTP/1.1" 400 762
161.69.123.10 - - [05/Apr/2022:14:06:23 +0000] "POST /api/ctrl/saveEdit HTTP/1.1" 200 474

2. Clicking on the edit icon, then selecting the 2nd geofence on the map, the control dialog does not show at all.

Types of Issue

• Anomaly report (something appears to not work correctly)
• Enhancement request (describe the enhancement being requested)
• Other (please ensure the description clarifies why the issue doesn’t fall into either of the above categories)

Descriptive summary

The TCR servlet is processing the TCR requests with one thread. If the stream of TCRs requests are received faster than the process to generate the TCMs as response. The TCRs requests are not process in time for a real-time client application.

carma-cloud version where this issue was discovered

CARMA Cloud version from April 22nd-April 25th, 2022

Expected behavior

TCR servlet will handle the TCR requests in an asynchronous manner and will not wait for any further response.

Actual behavior

TCR servlet accepts upcoming TCR requests and will not generated the TCMs until the TCRs are processed.

Steps to reproduce the actual behavior

NA

Related work

#27
#30

当我做CARMACloud的环境部署的时候，出现这个问题该如何解决呢？
environment：Ubuntu 20.04.2