Data management for cloud supported cooperative driving

Abstract

The increasing number of technologies inserted into vehicles, allowed the common user to have access to a broad number of utilities that allows driving to be easier, safer and more economical. ABS, GPS, Bluetooth and onboard computer are some of the technologies associated with a recent vehicle. On more experimental ones there is obstacle detection, automatic braking and self-driving technologies, which can be supported by a wireless network connection to further improve their capabilities. That connection allows the transformation of each independent vehicle into nodes in an ad-hoc network. The current challenge is to connect all those vehicles and be able to provide the data needed for their correct functioning in a timely manner. That is the challenge this dissertation will seek to analyse: the possibility to create a reliable vehicular information system for cooperative driving based on the cloud. Cloud-based storage can support an ever changing number of vehicles while still satisfying scalability requirements and maintaining ease of access without the need to maintain a physical infrastructure, as that responsibility is laid upon the provider. To understand which service is the best to host the vehicular information system it was analyzed three services from Amazon Web Services (AWS): S3, EC2 and DynamoDB. Ease of utility, latency, scalability and cost were the main requirements tested as they are the most important aspects for a real-time vehicular information system for autonomous vehicles. After deciding which cloud service would be the most appropriate to implement the vehicular information system, two client models were created that fulfilled a set of requirements. They were based in an already existing algorithm named Two-Step Full Replication which utilizes a group of Key-Value Stores services from various clouds to simulate a shared-memory based on multi-writer, multi-reader (MWMR) registers. This algorithm tolerates Byzantine faults by using Byzantine quorum techniques and integrity and authenticity checks. It was defined and implemented the necessary changes on the algorithm to create usable a client for a vehicular information system. The first model called ”Atomic Snapshot Client”, uses the modified Two-Step Full Replication interface with the Atomic Snapshot algorithm. This model guarantees that the read of the system (snapshot) is done atomically without being adulterated by concurrent writes, sacrificing execution latency. The second model is a faster version of the first one with the objective of obtaining faster responses from the system without overly sacrificing data consistency, which is called ”Fast Snapshot Client”. The main change from the first one is the reduction of the guarantees of the atomic registers to regular ones making the reads (scan) and writes (update) simpler and faster, although removing the atomic snapshot feature. With the analysis of the data collected from experiments performed with this model it was possible to observe a relation between the increase of the scan latency time and the total time spent on the execution of the read and write operations on an application with various clients. To solve this problem a simple garbage collector was implemented, which cleans each register when the number of outdated writes that it contains goes over a specified threshold. This solution, although simple, proved to be effective to reduce each scan time. Finally, a vehicular information system based on the AWS S3 service was implemented. It is composed by two types of clients based on the Fast Snapshot Client, named vehicular client and calculator client. The two types of client work together, where the vehicular clients trade information with the calculator. The calculator client scans the registers of the vehicle clients and writes on its registers the processed data for each vehicular client. The vehicle clients need to write all the relevant data they gather and read the register of their respective calculator client and act according to the data read. Each of the clients was tested separately and analysed in order to discuss the viability of this system in a real-world application as well as possible changes to further improve it.