A Machine to Machine framework for the charging of Electric Autonomous Vehicles
Ziyad Elbanna, Ilya Afanasyev, Luiz J.P. Araujo, Rasheed Hussain, Mansur Khazeev, Joseph Lamptey, Manuel Mazzara, Swati Megha, Diksha Moolchandani, Dragos Strugar
AA Machine to Machine framework for thecharging of Electric Autonomous Vehicles
Ziyad Elbanna, Ilya Afanasyev, Luiz J.P. Ara´ujo, Rasheed Hussain, MansurKhazeev, Joseph Lamptey, Manuel Mazzara, Swati Megha, DikshaMoolchandani, and Dragos Strugar
Innopolis University, Innopolis 420500, Russia
Abstract.
Electric Autonomous Vehicles (EAVs) have gained increas-ing attention of industry, governments and scientific communities con-cerned about issues related to classic transportation including accidentsand casualties, gas emissions and air pollution, intensive traffic and cityviability. One of the aspects, however, that prevent a broader adoption ofthis technology is the need for human interference to charge EAVs, whichis still mostly manual and time-consuming. This study approaches sucha problem by introducing the Inno-EAV, an open-source charging frame-work for EAVs that employs machine-to-machine (M2M) distributedcommunication. The idea behind M2M is to have networked devicesthat can interact, exchange information and perform actions without anymanual assistance of humans. The advantages of the Inno-EAV includethe automation of charging processes and the collection of relevant datathat can support better decision making in the spheres of energy distri-bution. In this paper, we present the software design of the framework,the development process, the emphasis on the distributed architectureand the networked communication, and we discuss the back-end databasethat is used to store information about car owners, cars, and chargingstations.
Keywords:
Networking; Machine-to-machine economy; Electric AutonomousVehicles; Charging station; Software process and design
Electric Autonomous Vehicles (EAV) have been ubiquitously replacing standardvehicles since their invention in the 20 th century [1]. EAV technology is madepossible by the synergy of Vehicular Communication [19], Intelligent Transporta-tion Systems (ITS) and Big Data Analytics [20]. Vehicular Communication sys-tems are computer networks in which both vehicles and roadside units representcommunicating nodes exchanging information about safety and traffic. ITSs areapplications providing innovative services for traffic management and informeddecisions. Research has shown that these technologies represent a practical ap-proach to solving such transportation issues as accidents [2], traffic congestion,and harmful gas emissions [14,16]. a r X i v : . [ c s . C Y ] N ov Ziyad Elbanna et al.
Autonomous cars are already pervading our roads in the form of pilot ex-ecution from different stakeholders and are speculated to be on the verge ofcommercialisation [11]. It is also worth mentioning that autonomous cars arepoised to have profound social and economic impacts on our lives, as well asa positive impact on the environment [10]. The EAV technology is now emerg-ing as an enabler to establish the foundation for the Machine-to-Machine (M2M)economy, i.e. networked devices that can interact, exchange information and per-form actions without any manual assistance of humans. For this to happen, themarket should be able to offer appropriate charging services without involvinghumans [17,18,9,3].In this paper, we investigate the area of Intelligent Vehicle and Transporta-tion Systems and present the design of a versatile open-source framework devel-oped for improving and automating the charging process of electric vehicles andestablishing the foundation of M2M economy using WiFi networks. Inno-EAVis available as a set of open-source modules which can be used independently orconcomitantly by DevOps teams. It offers a repository that can be cloned intoa project for continuous integration and development [8].
The Inno-EAV framework is constituted of three layers (Fig. 1): – Physical layer . It encapsulates all the hardware components embedded inthe charging station (CS) used for sensing and gathering information aboutthe charging process, as well as communicating with external entities. – Network Layer . Since our scenario is composed of autonomous, dynamicdecision-making CSs and vehicles, we suggest the communication betweenthe entities in the system be entirely peer-to-peer (P2P) with distributedledger technologies (DLTs) as a possible solution to store both data andvalue transactions [4,5]. We also consider Message Queuing Telemetry Trans-port (MQTT) connectivity protocol to be the most appropriate choice forinter-device communication. In this way, the network layer would be able totransfer sensor data from the Physical Layer to the Services Layer rapidlyand securely [17,18]. – Services Layer . On top of the architecture sits the Services Layer, whichmakes use of the two layers described above to deliver services to both con-sumers and service providers. Such services include: • Charging services for EAVs; • Data Analysis for Service Providers.The Inno-EAV framework is proposed to solve problems common to mul-tiple application scenarios, and it is compatible with a multitude of environ-mental goals and application protocols. Moreover, its architectural and designdecisions does not only manifest but also promote qualities such as modular-ity, re-usability, modifiability, install-ability, adaptability, authenticity, integrity,interoperability as specified in the ISO/IEC 25010 [13]. nno-EAV 3
Fig. 1. Inno-EAV Architecture.
Currently Inno-EAV consists of 3 layers dedi-cated to high performance as explained and depicted in [17], with labels refering to:a)Main Controller b)IOTA’s tangle, c)Local database, d)Bidirectional Communication,e)EAV’s app, f)SP application, g) Component connection in one layer and h) Securedconnection between two layers respectively.
Traditional Electric charging billing systems requires humans interaction whichmay be time consuming and exhausting. The Inno-EAV framework will use wire-less networks to employ secure machine to machine interaction and performcharging and billing process seamlessly without any manual assistance of hu-mans.
The normal flow of Inno-EAV user use case is as follows: – The car owner connects to the same network of the charging station, andsend the JSON file to it. In Inno-EAV, we used JSON files as its a light, easyto read way of transmitting data over networks as well as being a native tojavascript which makes it easier to extract data. – The charging station verifies the car details by sending the file to the databasesystem in compliance with authenticity and integrity qualities [13].
Ziyad Elbanna et al.
Fig. 2. UML Use case diagram explanation for Inno-EAV Framework.
Inno-EAV enables the automatic charging of the electric car. The use case begins when anEAV owner connects to the same network as the charging station which it is registeredto, and to send the JSON file to the charging station. The system sends the JSON fileto the database system for verification. If the database system approves the car details,the server asks for the amount of electric charge and issues a receipt. The transactionsare recorded in the database. – The charging station then asks for the electricity amount needed. – The car enters the amount. – The bill is sent to the car. – The car pays the bill to the charging station.
In M2M communication between server and client, a file is required to be sentto the server at which is often unique for every car. This file has the followingattributes: (Name, Email, Phone and Personal-ID) of the car owner and (Model-name, Model-year, and Date purchased) of the car. Each ID is unique, and the nno-EAV 5 combination of the car owner ID and his car is also unique, likewise the IDof charging stations. However, after the file is sent to the server, it checks thecombination of the car ID and owner ID against the database for authorization.Charging station registration is therefore essential for assigning the car of eachowner to a specific charging station at which it can be charged from in the future.Our team created a web application aiming to ease the registration processfor car owners to register their car to a particular station, and thus be ableto charge from this station in the future. Therefore, Inno-EAV-Core Chargingstation registration offers a unique tool to perform this registration quickly androbustly on a wide variety of datasets.The owner will be asked to enter his personal information through formfilling, along with his car information, the information about the charging stationwhere the car is to be registered. In order to complete the authorization stepsuccessfully, it is necessary to enter the same details of the vehicle which willcharge from the station.The sequence diagram begins after the EAV connects to the same WIFInetwork as the charging station. It has the same steps as refered in section 2,but the additional step happens when the car details are invalid/ car is notregistered in the network. In that case, the car is not allowed to charge from thisstation and the session is closed as shown in Fig 3.
Inno-EAV-Core performs the charging station registration by creating a new tu-ple representing each relation entry, where the attributes values for each relationentry corresponds to the value from which the user entered at the registrationform. For cases in which these entries violate the key constraints, an error mes-sage is used to warn the user, and the registration is not completed successfully.Because the violation of key constraints can happen with different keys in thesame entry, the query execution is done after obtaining all the attribute valuesfrom the user for each of the car, the owner and the charging station relations,so the violation can also quickly checked and the user asked to correct his entryand enter a valid/unique key.To generate these key constraints, Inno-EAV-Core first executes ’Owner’ re-lation query, (Fig. 4). This is achieved by storing the owner’s information asa new tuple in the ’Owner’ relation, the ID attribute is considered a primarykey for the ’Owner’ table, as shown in Fig. 4. Then the next step is to executethe ’Car’ relation query, which also has a primary key ’ID’ representing the car’sunique ID (Fig. 4b). For the given schema, each car entry has a foreign key repre-senting the car’s owner. Finally, Inno-EAV-Core can then execute the ’Chargingstation’ query to enter the tuple representing the charging station informationthat the user can charge from in the future (See Fig. 4).Furthermore, the entries should contain non-repeated key entries uniquelyrepresenting each owner, car or charging station. A typical entry for this frame-work is three tuples with valid key constraints. Following the tuples creation of
Ziyad Elbanna et al.
Fig. 3. Inno-EAV sequence diagram explanation.
Allows any electric car ownerto charge their electric car automatically. This sequence begins when an EAV ownerconnects to the same network as the charging station which it is registered to, it sendsthe JSON file to the charging station. The system sends the JSON file to the databasesystem for verification. If the database system approves the car details, the server asksfor the amount of electric charge and issues a receipt, afterwards, the user pays thebill, and the transaction is stored in the database. Otherwise, the session is closed, andthe server waits for another client on the same port. this entry, Inno-EAV-Core will create another tuple for ’charging station-has-car’ relation which represents a many-to-many relationship as described in thefollowing section, This can be used to assign each car to a charging stationdepending on its unique (Owner-ID, Car-ID) combination. Given that all theentries are valid, therefore, four new tuples will be added to each relation. Therelations are: Owner, Car, Charging station, and Charging station-has-car, Inno-EAV-Core can then search the database for the car asking to charge from thestation, which is known as authorization step, the car will be accepted or refuseddepending on whether its registered in the charging station or not (Fig. 4).
As part of the Inno-EAV framework, we include our database entity-relationshipdiagram (ERD) designed to match our system’s needs, which is required to nno-EAV 7
Fig. 4. Registration Database System Entity Relationship Diagram withInno-EAV-Core. a)
Owner of Electric-car table representation consisting of fourmain attributes which are: ID, name, Email and Phone b) Car table representationwith four main attributes: ID, Model name, Model year, and Date-purchased and oneinherited attribute: Owner-ID c) Charging station table representation with three mainattributes: ID, Name, and Address d) Charging station-has-car table representationwith three attributes: Charging-station-id, Car-id, Car-owner-ID explain the relationships between different relations in the schema. As shown inFigure 4, the database has been constructed to keep track of the car owners, cars
Ziyad Elbanna et al. and charging station of a city. A charging station has several cars. It is desiredto keep track of the owners owning each vehicle for each charging station, theirname, ID, email, and phone the game. Each owner can have more than one car,so the relationship between car and owner relation is one-to-many as can beseen in the diagram. A charging station has more than one car, and a car canbe registered in more than one charging station, which yields a many-to-manyrelationship.
Inno-EAV is installed as a standard set of modules, and it is fully Java-basedopen-source. Each of its modules possesses its separate manual and documen-tation. To date, it encompasses two additional Java Archive (JAR) packages(Apache, JSON) alongside with the existing original packages in the Java JDK.The modular nature of Inno-EAV allows its components to be updated inde-pendently and the framework to be easily extended by appending new packageshence promoting the maintainability qualities: modularity, re-usability, analys-bility, modifiability and test-ability [13].
M2M communication commonly occurs during the acquisition of the same net-work to the server and the client, often as a result of the client connecting tothe same network where the server is connected. We assume that the networkIP address of the charging station is the server with a static IP address. Whiledifferent clients trying to charge from this server will have a different IP addresseach time they connect to the wifi network, the charging stations will still beprone to have different IP address each time they connect to the network (Fig.5). However, in our case where the charging station is considered to be the server,we assume that it uses the same IP address each time it connects to the networkand sets up a fixed static IP address for it.Inno-EAV breaks the task of network communication into two distinct parts:Server socket creation from the server, followed by socket creation from theclient.
Server -
As a first step, Inno-EAV-Core charging station creates the serversocket which represents it and waits for a connection from the client on a specificport number, which is the listening port number (Fig. 5b). The number of theport is previously agreed on by both stakeholders in the connection that is laterachieved as the server socket accepts the socket trying to connect to the listeningport using socket programming in Java. Once the connection is established, thedata of the client can be directly retrieved by getting the input stream using aninstance of the ObjectInputStream class shown in (Fig. 5b). The data retrievingprocess will, however, change the current input stream of the listening port,which can have an influence on further stream writing required to exchangeinformation between the client and the server. nno-EAV 9
Fig. 5. UML class diagram for Server package. a)
Image of Server class diagramwith two main functions: Main, and Server. The latter class is used to specify the portnumber of connection. b) TCP thread class which extends the Thread class and is runinside Server routine shown in a). c) Byte Stream class used to send and get outputstreams to and from the client
For the specific case of our project with Object output stream, there willonly be a few writes to the stream of the listening port, as there is only a fewinformation to be exchanged between stakeholders. The first input stream to theserver will be the file name of the client, such as ’test.json’ for instance. As anoption Inno-EAV-Core can store the incoming input lines in the stream withina new file in the sent documents, thus converting the input stream to a new filecontaining the client’s information.
Client -
Client package in Inno-EAV differs slightly from the server package,as it creates the socket with the specific port number and the fixed IP address ofthe server that we have set in previous steps. This allows the connection to besystematic once the client enters the region of the network to which the server is
Fig. 6. UML class diagram for Client package. a)
Image of MyClient class dia-gram with two main functions: Main, and MyClient. The latter class is used to specifythe port number of connection. b) Byte Stream class used to output and get outputstreams to and from the client connected. Furthermore, Inno-EAV-Server (as described in the previous section)can accept the socket creation (Fig.6a) created by Inno-EAV-Client and use thisconnection directly to retrieve the data from the client.As we discussed later, The sequence of Inno-EAV begins when the car con-nects to the same network that the charging station is connected to, as explainedin and (Fig.6) shows the sequence diagram of Inno-EAV. nno-EAV 11
In this paper, we investigated the area of Intelligent Vehicle and TransportationSystems proposing a versatile open-source framework developed for improvingand automating the charging process of electric vehicles and establishing thefoundation of M2M economy using WiFi networks. The networked communica-tion is done without the interference of human, wirelessly through WIFI network.In our proposed scheme, the cars are considered clients and the charging stationsare servers. Clients are authenticated with the charging station after they sendthe file containing the car information to the charging station through a secureTCP connection. Car registration is done using our web application, at whichthe owners fill in their information and then be assigned to a specific chargingstation meanwhile, the electric power service provider bills the vehicles on percharging palate basis. Our proposed scheme provides a secure and privacy-awarebidirectional audit, where the billing process is valid by both parties [12]. More-over, we also present the game-theoretic approach to validate the bidirectionalaudit.In the future, we aim to implement the system to have a more in-depth in-sight into the performance and security issues that can emerge when computinghas an high level of pervasiveness [6]. Moreover, we also aim to develop the Inno-EAV system to work on a larger scale. To this end, we intend to deploy DevOpspractices for faster feature delivery, high quality assurance and product owner-ship [15]. We will also focus on a more robust mechanism where the vehicles willhave a choice to buy the charge according to their convenience. We will addressthe complexity involved in such robust charging and its billing mechanism andcan thus be used to optimise acquisition workflows [12]. Furthermore, the currentframework is fundamentally monolithic-based. To cope with scalability issues, wemay in future refine it into a microservice-based one [7] and demonstrate how itcan be adopted for projects by DevOps teams.
References
1. Sit back, relax, and enjoy a ride through the history of self-driving cars. ,accessed: 2019-23-82. Critical reasons for crashes investigated in the national motor vehicle crash causa-tion survey. Tech. rep., U.S. Department of Transportation, 1200 New Jersey Ave,SE, Washington, DC 20590, USA (February 2015), https://crashstats.nhtsa.dot.gov/Api/Public/ViewPublication/812115
3. Afanasyev, I., Kolotov, A., Rezin, R., Danilov, K., Mazzara, M., Chakraborty,S., Kashevnik, A., Chechulin, A., Kapitonov, A., Jotsov, V., et al.: Towardsblockchain-based multi-agent robotic systems: Analysis, classification and appli-cations. arXiv preprint arXiv:1907.07433 (2019)4. Benˇci´c, F.M., ˇZarko, I.P.: Distributed ledger technology: Blockchain compared todirected acyclic graph. In: 2018 IEEE 38th International Conference on DistributedComputing Systems (ICDCS). pp. 1569–1570. IEEE (2018)2 Ziyad Elbanna et al.5. Burkhardt, D., Werling, M., Lasi, H.: Distributed ledger. In: 2018 IEEE Interna-tional Conference on Engineering, Technology and Innovation (ICE/ITMC). pp. 1–9 (June 2018)6. Dragoni, N., Giaretta, A., Mazzara, M.: The internet of hackable things. In: Pro-ceedings of 5th International Conference in Software Engineering for Defence Ap-plications - SEDA 2016, Rome, Italy, May 10th, 2016. pp. 129–140 (2016)7. Dragoni, N., Lanese, I., Larsen, S.T., Mazzara, M., Mustafin, R., Safina, L.: Mi-croservices: How to make your application scale. In: Perspectives of System Infor-matics - 11th International Andrei P. Ershov Informatics Conference, PSI 2017,Moscow, Russia, June 27-29, 2017, Revised Selected Papers. pp. 95–104 (2017)8. Elbanna, Z.: Innopolis electric autonomous vehicle - inno eav (2019)9. Hua, S., Zhou, E., Pi, B., Sun, J., Nomura, Y., Kurihara, H.: Apply blockchaintechnology to electric vehicle battery refueling. In: Proceedings of the 51st Inter-national Conference on System Sciences (2018)10. Hussain, R., Lee, J., Zeadally, S.: Autonomous cars: Social and economic implica-tions. IT Professional (6), 70–77 (Nov 2018)11. Hussain, R., Zeadally, S.: Autonomous cars: Research results, issues, and fu-ture challenges. IEEE Communications Surveys Tutorials (2), 1275–1313 (Sec-ondquarter 2019)12. Hussain, R., Son, J., Kim, D., Nogueira, M., Oh, H., Tokuta, A.O., Seo6, J.: Pbf: Anew privacy-aware billing framework for online electric vehicles with bidirectionalauditability (2017)13. ISO/IEC: Software product quality. https://iso25000.com/index.php/en/iso-25000-standards/iso-25010 (2019)14. Kyriakidis, M., Happee, R., de Winter, J.: Public opinion on automated driving:Results of an international questionnaire among 5000 respondents. TransportationResearch Part F: Traffic Psychology and Behaviour , 127 – 140 (2015)15. Lwakatare, L.E., Kilamo, T., Karvonen, T., Sauvola, T., Heikkil¨a, V., Itkonen, J.,Kuvaja, P., Mikkonen, T., Oivo, M., Lassenius, C.: Devops in practice: A multiplecase study of five companies. Information and Software Technology (2019)16. Rouse, M.: What is machine to machine. https://internetofthingsagenda.techtarget.com(2018)17. Strugar, D., Hussain, R., Mazzara, M., Rivera, V., Afanasyev, I., Lee, J.: An archi-tecture for distributed ledger-based M2M auditing for electric autonomous vehi-cles. In: Web, Artificial Intelligence and Network Applications - Proceedings of theWorkshops of the 33rd International Conference on Advanced Information Net-working and Applications, AINA Workshops 2019, Matsue, Japan, March 27-29,2019. pp. 116–128 (2019)18. Strugar, D., Hussain, R., Mazzara, M., Rivera, V., Lee, J.Y., Mustafin, R.: Onm2m micropayments: a case study of electric autonomous vehicles. In: 2018 IEEEInternational Conference on Internet of Things (iThings) and IEEE Green Com-puting and Communications (GreenCom) and IEEE Cyber, Physical and SocialComputing (CPSCom) and IEEE Smart Data (SmartData). pp. 1697–1700. IEEE(2018)19. Ting, Z., Jianjun, H., Li, S., Jianfeng, L., Yan, M.: Study on mobility mod-els in vehicular communication system. In: 2009 2nd IEEE International Con-ference on Broadband Network Multimedia Technology. pp. 57–61 (Oct 2009).https://doi.org/10.1109/ICBNMT.2009.534782420. Zhu, L., Yu, F.R., Wang, Y., Ning, B., Tang, T.: Big data analytics in intelligenttransportation systems: A survey. IEEE Transactions on Intelligent TransportationSystems20