exchange: add the notifications

[tigroo31]

Trace each rud received: "traffic_orchestrator ru_description received_from v2x_gateway \ OBU10/OBU10/1559064682429 at 1559064682430" Trace each maneuver sent: "traffic_orchestrator maneuver sent_to v2x_gateway 123456 at 1556525122280" Trace each maneuver feedback received: "traffic_orchestrator maneuver_feedback received_from v2x_gateway \ 123456/accept/ at 1556525122670" "traffic_orchestrator maneuver_feedback received_from v2x_gateway \ 123456/abort/distance_front at 1556525122770" "traffic_orchestrator maneuver_feedback received_from v2x_gateway \ 654321/refuse/decelaration at 1556525122870"

Remove useless global variables.

Remove offuscing parameters on global variables.

Remove useless generateUuidTo method.

Use modern c++ nullptr instead of 0 or C NULL.

Use references to avoid useless copies.

HOw to test: use the real v2x gateway, and check one line appears into the standard output (standalone execution) or into the ELK (docker gelf driver used) for each: ->notification (done by myself) ->maneuver (done by myself) ->maneuver feedback (not done, the injector stub doesn't provide it)

[tigroo31]

@theomarzaki , could you test the new 3 outputs from your installation? TO be sure that no regression was introduced, and the log is correct? I'll check the ELK when it will be merged.

[tigroo31]

More elements :

Today, we’ve got a uuid for a maneuver recommendation to trace the route of a message: “uuid_maneuver”. Moreover, the “timestamp” field is never changed. So we can compute the communication delay. We don’t provide the “message_id” into the json message. The Traffic Orchestrator, the V2X Gateway and the vehicles must create a new log line each time it receives or sends a message. The information part is filled with the uuid_maneuver message field. For examples: • From the Traffic Orchestrator: traffic_orchestrator maneuver sent_to v2x_gateway 123456 at 1556525122280 • From the V2X Gateway: v2x_gateway maneuver received_from traffic_orchestrator 123456 at 1556525122300 v2x_gateway maneuver sent_to OBU4 123456 at 1556525122310 • From a vehicle: OBU4 maneuver received_from v2x_gateway 123456 at 1556525122450

[tigroo31]

More elements again:

Today, we’ve got a uuid for a maneuver recommendation to trace the route of a message: “uuid_maneuver”. Moreover, the “timestamp” field is never changed. So we can compute the communication delay. We don’t provide the “message_id” into the json message. The Traffic Orchestrator, the V2X Gateway and the vehicles must create a new log line each time it receives or sends a message. The information part is composed of other message fields like this: “//” (the concatenation of the 3 fields separated by slash ‘/’). • The < uuid_maneuver > part indicates the digital identifier of the maneuver recommendation, generated by traffic orchestrator, needed as reference for maneuver feedback. It’s mandatory. • The < feedback > part indicates the result of the process. It’s mandatory. It must be one of these three values: 1- “accept”, if the vehicle executes the recommended maneuver. 2- “abort”, if the vehicle does not execute the whole recommended maneuver. 3- “refuse”, if the vehicle does not execute parts of the recommended maneuver. • The < reason > part indicates why the maneuver was refused or aborted. It’s optional, it must only be present if feedback is “abort” of “refuse” in the message. Indicates a reason, among the following: 1- “refuse”: Do not want to be given instructions 2- “distance_front”: Distance to front vehicle too short 3- “distance_rear”: Distance to rear vehicle too short 4- “accelaration”: Acceleration too strong 5- “decelaration”: Deceleration too strong For examples: • From a vehicle: OBU4 maneuver_feedback sent_to v2x_gateway 123456/accept/ at 1556525122500 OBU4 maneuver_feedback sent_to v2x_gateway 123456/abort/distance_front at 1556525122600 OBU5 maneuver_feedback sent_to v2x_gateway 654321/refuse/decelaration at 1556525122700 • From the V2X Gateway: v2x_gateway maneuver_feedback received_from OBU4 123456/accept/ at 1556525122650 v2x_gateway maneuver_feedback received_from OBU4 123456/abort/distance_front at 1556525122750 v2x_gateway maneuver_feedback received_from OBU5 654321/refuse/decelaration at 1556525122850 v2x_gateway maneuver_feedback sent_to traffic_orchestrator 123456/accept/ at 1556525122660 v2x_gateway maneuver_feedback sent_to traffic_orchestrator 123456/abort/distance_front at 1556525122760 v2x_gateway maneuver_feedback sent_to traffic_orchestrator 654321/refuse/decelaration at 1556525122860 • From the Traffic Orchestrator: traffic_orchestrator maneuver_feedback received_from v2x_gateway 123456/accept/ at 1556525122670 traffic_orchestrator maneuver_feedback received_from v2x_gateway 123456/abort/distance_front at 1556525122770 traffic_orchestrator maneuver_feedback received_from v2x_gateway 654321/refuse/decelaration at 1556525122870

[theomarzaki]

@tigroo31 Works Perfectly, when I deployed on my machine. However, I cannot get the data sent (cloud), so I had to do it manually.

With the additional info. The TO should create a new message_id every time it receives/sends a message. And the message_id has the same format as before(with the addition of the explanation of feedback) but not sent as a message, but in standard out for the ELK stack. Is this right ?

[tigroo31]

Into the payload (recommendations sent to OBU's and their feedbacks), we could add a message_id to the json. But it may be useless : it would be just to "harmonize" with the ruds. Into the logs (traces into the output for the ELK), we could add too. But it would be useless again, no? If we do this, it will be important to keep the useful maneuver_uuid, feedback and reason fields. So something like:

traffic_orchestrator maneuver sent_to v2x_gateway traffic_orchestrator/traffic_orchestrator/1556525122280 123456 at 1556525122280

traffic_orchestrator maneuver_feedback received_from v2x_gateway OBU11/OBU11/1556525122740 123456/abort/distance_front at 1556525122770

Like you see, the message_id (source_uuid/uuid/timestamp) is trivial for the maneuvers.

[theomarzaki]

Ahhh, I understand now. Yes, I agree fully !

As you said, it would be more beneficial to tailor towards TO case, rather than just relaying the information.