Welcome to the AES-I wiki!

In this part of the project, our main goal was to implement ways of using SmartData as our communication protocol. In the following sessions, we will describe what we were able to achieve, limitations, and next steps.

Based on our colleague's code, We were able to start exploring how we can employ SmartData on our project. We started our implementation by exploring how SmartData works. The executed steps were the following:

1. Execute the code with an initial version of SmartData on Linux: Even though the latest version provided by the other group seems to work, we faced some compiling errors regarding htonl. To compile the application we added the ifdef instruction regarding htons.

2. Start a UDP Server on port 5001: To achieve this task we used nc with the following command: nc -u -l 5001 -v

3. To test interact with our server we also used netcat with the following command: nc -u localhost 5001 -v

4. Spawn nodes and sink: After running the UDP server, we were able to spawn nodes and one sink. The following image presents an execution of two nodes:

During our experiments, we noticed that the sink and node weren't working as expected, even though it seems like the sink was defined in the correct region and unit. After some debugging, we found out that the UDPNIC class wasn't working as expected. So we started exploring how we can fix the send and receive functions. In the next section, we detailed how we altered these two functions.

We start our tests by creating a simple multicast group in the 224.0.0.1 address and port 5001. The udp multicast server can be found in the file named mc_server.py. The main goal of this server is to receive connections from differents nodes and sink and route the messages to others that are connected to the group. We used netcat to test whether the multicast server works as expected. The following image shows the server receiving and sending messages properly:

In this part of the experiment, we started by changing the way the SmartData binds with a socket. In previous versions, each time a node or sink was about to send a message, it would bind to a new socket and port. We changed this behavior by adding the server address configuration as a class attribute, which enabled us to define that an object from the UDPNIC class only binds to a socket in its creation.

As we progress in our experiments, we noticed that the receiving and sending functions must be changed too. In the previous version, the function receive_thread spawned during object creation, never actually executes the virtual function receive, that processes the received packet. Our changes consist in removing the condition that used the select function and employs the function recvfrom with the flag WAITALL. In the sending part, we changed the data sent to other peers, since it seemed to be incorrect. We start sending the frame, not the link.

Both the sending and receiving weren't working as expected, the node and the sink couldn't process the received packets, in which the interpretation of the received packets was always a REVOKE message. To fix these functions we tried using the previously implemented version of the function receive. However, the interpretation was still wrong. After our colleagues helped us, we were able to interpret the messages inside of the receiving thread.

After finding a way of creating the received buffer, we noticed the timestamp inside of the messages wasn't correct. To fix this problem we used the following:

instruction std::chrono::duration_caststd::chrono::milliseconds(std::chrono::system_clock::now().time_since_epoch()).count();

We aren't certain of the impact or whether this is the right choice, but it seems to fix the problem of different timestamps. We extracted the instruction from https://currentmillis.com/. After this addition, we are in the current situation:

1. We are receiving and interpreting the messages;
2. The timestamps seem to be right;
3. We are trying to figure out whether adding the instruction 'buf->destined_to_me = true;' is the right way to fix this problem;
4. After adding this instruction, the application seems to be working. We noticed that the node receive an interest message from the sink, thefore, it adds to its interests list. The node receives the updates and updates its value.

Following we list some problems and the decisions we made during the integration between the roadside agent and the SmarData on Linux:

1. Couldn't import some relavant libraries, such as sstream, string, and so on: we had some problems related to overloading the new operator. To solve this problem we commented the lines 38 and 39 from the file called types.h. We also added the instruction "#include ";
2. To exchange information between the Roadside agent we alter the transducer, in which the SmartData on Linux application reads from a socket the decision generated by the roadside agent;

1. Communicate Python API with SmartData on Linux;
2. Roadside agent sends the decision about the lane congestion via UDP sockets on port 5050;
3. Roadside agent creates decisions that should be encapsulated with SmartData;
4. Nodes will work as the roadside agent's actuator;
5. Create sinks that will receive the congestion status message from the roadside agent;
6. Car agent's sensors will receive SmartData and reason about it;
7. Car agent's reasoning output will control CARLA via Python API.

Mapping the AES for vulnerable points to the application safety, that is when the communication between distinct components happens. As represented in the image below, the communication between the Carla engine, the Roadside Agent, and the Car Agent is running with raw data and it can be intercepted and manipulated by malicious users.

To handle this problem encryption of the data sent through the APIs, using the RSA method with a Python library named rsa (https://github.com/sybrenstuvel/python-rsa/). This library provides functions to easily generate private and public keys and encrypt and decrypt the information in the data. All the data is encrypted before being sent through the API and decrypted after be received in each component. This method was selected because each component will have access just to his keys to decrypt decode, keeping part of the security system even when one of the components has the access compromised.

The SmartData application reads the data accessing straight in the flat memory, therefore no data is interceptable through the networking. The processing of data sharing between the Agents and the SmartData follows the steps below:

1. Agent writes the answer in the flat memory.
2. Node and Sink are created and keep "waiting" and processing messages.
3. Node reads from flat memory the decision of the Agent and converts it too long int with hexadecimal.
4. Sink keeps obtaining the long int and interprets the answer.

The following diagram includes the representation of the SmartData in the process.

To avoid cyber attacks of impostors trying to pretend to be an object near to the autonomous vehicle sending information, a security system will be implemented applying geohash to verify if the localization of the object is really close to the autonomous vehicle.

Geohash has the property to generate a hash code that preserves the distance relation between two differents localizations values without revealing the true position of the object.

To implement the Geohash function was applied the Python library pygeohash that provides a a function to encode the latitude and longitude data of the location and the degree of precision.