A Smart Mobility Platform for Electric Vehicleswith Event Processing

Muge Kural, Fatih Kaan Tuncer, Deniz Memis, M.Naci DaiEteration

Istanbul, Turkey{muge.kural, fatih.tuncer, deniz.memis, naci.dai }@eteration.com

Abstract—Electric Vehicles (EV) are increasingly becoming themainstream for the automotive industry. EV drives researchin many diverse areas such as charging, battery performance,and autonomous driving. The volume, velocity and variety ofdata and events generated by a typical EV is very large. Inthis paper, we describe a hybrid architecture that consists ofembedded and cloud-based modules to monitor and process EVevent in near real-time, which is developed as a part of ITEA2Smart M2M Grids Project [1]. The platform has a customdesigned event processing hardware with network connectivityand module adapters to receive/transmit real time data such asthose coming from the automotive Control Area Network (CAN)Bus. The platform includes software to apply rules and policieson real-time events. In this paper, we demonstrate its use with asimulation that includes a risk assessment scenario to check thereachabilities of nearest charging stations based on the currentstate of EV and observe the performance results.

Index Terms—smart mobility unit, complex event processing,internet of things, electric car, cloud

I. INTRODUCTION

In 2017, global sales of electric cars crossed the thresholdof 1 million units (1.1 million) and as of 2017, there are over 3million electric and plug-in hybrid cars in use around the world[2]. The EV30@30 campaign which is announced by TheClean Energy Ministerial (CEM), targets the global stock ofEVs as 228 million by 2030 [2]. According to KPMG’s GlobalAutomotive Executive Survey “Data is the fuel for the futurebusiness model of automotive companies” and executivesabsolutely or partly agree with this statement.”[3] The numbersshow that the world has a future with EVs and there willbe a lot of data to give meaning. In this paper we describea hybrid architecture that consists of embedded and cloud-based modules to monitor and to process EV events in real-time. The platform has a custom designed event processinghardware with network connectivity and modal adapters totransmit/receive real time data from data sources in an EVsuch as those coming from the automotive Control Area Net-work (CAN) Bus. The embedded platform includes softwaresolutions to apply rules and policies on real-time events.The platform makes use of a lightweight Complex EventProcessing (CEP) engine and an OSGi based IoT gateway.The EV data is received from the CAN then processed andif needed published to the cloud. The cloud integration of theplatform expands the features of Smart Mobility Unit with big-

data analytics by processing data coming from other(external)sources,services and sensors. In this paper, Smart MobilityUnit is tested using a simulation that detects anomalies andtakes preset actions accordingly.

II. BACKGROUND

Complex Event Processing is a method to provide contin-uous and real time analysis of events via refined interpretersin large chunks of data. Its most important functionality is thedetection of risks and anomalies in almost real-time. [4] Thisminimal latency helps us to react immediately for minimizingthe risks or maximizing the benefits of the possible occuringevents. [4] Many applications based on CEP are done to beused in different fields such as RFID processing[5], productmanufacturing[6]. Fig. 1 describes the architecture; incomingevents are directed to complex event processor, which can han-dle very high thruput with async consumption and processing.These events are received by input event adapter (IEA) andnormalized into a form that can be processed by the CEP.IEA provides of a variety of adapter implementation out-of-the-box. CEP is independent of any data source and type.Event builders (EB) makes a conversion of events received byIEA to event stream and also deals with input mapping linkedassignments in the CEP. Event Processor (EP) is the heartof CEP. It is responsible of handling the different executionplans and processing events. Event Formatter (EF) transformsresulting events of EP into various formats (XML,Map, JSONetc). These formatted events are published by Output EventAdapter (OEA) to appropriate servers via distinct carrieradapters. In terms of structure OEA is similar to IEA. EventStream Manager (ESM) is an critical component that supervisethe stream definitions. EB, EP and EF components interactwith ESM to fetch the information related the streams.

III. MODEL

The embedded platform includes:• IoT board, which handles data transmission/reception via

CAN interface of EV.• IoT adapter, provides the convertion between raw CAN

data and events,• IoT engine, which is wrapped around Siddhi library,

includes processing logic, takes the events coming fromIoT adapter as an input and sends back the derived outputbased on processing logic to the CEP adapters.978-1-5386-4980-0/19/$31.00 ©2019 IEEE

489

Fig. 1: Complex Event Processing diagram

Fig. 2: Modeling Complex Event Processing on EV

The main architecture of the platform can be seen in Fig.3. A low cost ARM based on-board computer (OBC) withembedded linux is used as a host to run software parts of thesystem with respect to incoming EV data. To receive/transmitEV data, a custom hardware stack intragrable with OPC isdesigned and manufactured. Inside of OBC an OSGI basedgateway to settle the applications which are IoT adapters andengines (in this case for CEP) are used.

Fig. 3: Architecture

A. Ongoing Hardware Design

As the research has made progress for hardware stackdesign, it has been decided to produce a Hardware Attachedon Top (HAT, see Fig. 3). Hence it will be capable of servingthe required functionality and will, at the same time, preservethe attributes of a blackbox design mentality. This black-box

Fig. 4: Hardware Stack Front and Back

mentality will allow our hardware to be placed in any devicethat is considered to be a data source, as one single piece. Thetasks handled by HAT can be listed as:

• Receiving data from vehicle that is provided over Con-troller Area Network (CAN).

• Supplying wireless communication in order to processreceived data on cloud platform.

• Powering OBC and itself by regulating power fed fromthe supply of vehicle.

To perform aforementioned tasks, HAT consists of certainmodules. These modules and their respective components arelisted below:

• Power Supply Modules: These modules regulates in-coming vehicle voltage (around 12 Volts) and reduceit down to operating voltage levels of other on-boardmodules, e.g. 4,1 Volts for SIM module. They containbuck regulators and other complementary elements thathelp produce a stable DC voltage.

490

• Adapter Module: This module handles transmission, re-ception and control of CAN data that is present at vehicleCAN bus. It contains a high speed CAN transceiver anda CAN controller.

• Networking Module: This module allows HAT to havewireless communication. It contains SIMCom’s chip, amicro SIM card and an antenna.

B. Cloud Integration

The core CEP system has been embedded into the designedhardware stack which will be located in EV. Since, ourhardware is capable of providing GPRS connectivity it leadsto the cloud integration of CEP system.

Fig. 5: Cloud Integration of CEP for EV

The cloud integration has extended the capabilities of theplatform. Firstly, we have implemented Rest API for CEPEngine. The API layer enabled all the operations to be doneremotely such as configuration of sink and source channels andstart,update or stop operations of execution plans. Besides, thatmade the platform open for external data sources, services orapplications.

C. OSGI based Gateway

The OSGi (Open Services Gateway initiative) explains anarchitecture for developing modular applications and javalibraries. The term ’bundle’ represents an application in OSGienvironment. At life-cycle layer, the elements of bundle canbe installed, started, stopped, updated and uninstalled dynam-ically and independently. Our implementation of IoT adapters(IEAs) and IoT engines (EPs) have been developed in an opensource Java/OSGi IoT Edge Framework [7]. These advantagesof OSGi architecture provides flexibility and robustness forSmart Mobility Unit.

The gateway UI enables the configutarion:• Necessary information for IoT adapter such as Vehicle

ID, CAN Bus interface selection, publish rate and EVrelated data channels’ IDs through web UI of gateway.

• Easy plan management for IoT Engine (installation, unin-stallation, update, start/stop).

D. Event Processing

The flow of an event within the IoT engine goes as follows:Event processing runtime [8] directs events to various compo-nents within. For each query defined or listed in queries, anevent junction is created. Each junction uses a thread to handle

Fig. 6: Structure of OSGi

Fig. 7: CAN Bus and Plan Management through UI

incoming events from streams. The events can be configuredto use a different thread in order to run asynchronous andparallel.

By source/sink definitions and event adapters (mqtt, rest,storm, cage, etc.), the query execution can be done dy-namically with stream connection and schema definitions.Forparallel flows, event junction uses the disruptor event pattern.Disruptor subscribers (down stream junctions / sinks) enableeach event to be received in parallel.

The process logic, also called execution plan, is given tothe event processor as DSL queries in SQL syntax. The planincludes two main elements: patterns and streams.

• Pattern: An element which includes the query that cancreate an output event and direct it to the output streamby combining various events and tables that are streamedand applying logical structures. Each query combines N-pieces of the input stream and the events from 1 tableand produces the output of the logical function as another

491

Fig. 8: IoT Engine Runtime

event via 1-output stream• Stream: Includes an information of sink/source channels

to create a schema that is labeled with a single name, asequence of events that is sequentially placed over time,and the attributes that define each event in that array andthe data types of these properties.

E. Monitoring

Cloud integration provides the monitoring of event channelsthrough web. As seen in figure above, real time data ismonitored from various channels with instantaneous variousgraphics. Line graph helps monitoring instantaneous rise andfalls of events. Center dot, change its size according to eventfrequency, simply if event frequency is intensifies it grows,becomes smaller if reduced. Graphic includes event counteron top right, and its count related to channel’s events sincethe beginning.

Fig. 9: A sample execution plan

Fig. 10: Monitoring event channels on web

IV. RESULTS AND DISCUSSION

In order to measure performance results of the unit, a samplescenario is created around battery range parameter of EV. Theunit keeps track of ETA of closest charging stations by a thirdparty traffic API. It also computes the decrease rate of stateof charge (SOC) by processing the following parameters: packcapacity (kWh), economy (Wh/km) and trip meter (km). Giventhe decrease rate in SOC remaining battery life is estimated.Ultimately, given ETAs by traffic API are compared withthe estimated remaining life and the unit creates a warningwhether there is a risk that a charging station is unreachable.

While calculating economy (Wh/km), all data points withinthe last one hour range are processed and this results in a moreaccurate value since it considers the consumption trend of thedriver. Until the warning event is triggered, it can be seen thatover 2000 events are processed per data stream (there are 3streams,see Fig. 10) justifying the functionality of CEP.

In the first case, the unit alerts that none of the chargingstations are within the reachable range.

In the second case, the unit notifies that all of the chargingstations are within the reachable range.

492

Fig. 11: Risk detection case 1

Fig. 12: Notification case 2

In the third case, the unit alerts that only one of the chargingstations is within the reachable range.

V. CONCLUSION

In conclusion, the smart mobility platform has a hybridarchitecture that is capable of running both as an embeddedsystem and as a cloud platform. This fact provides flexibilityand robustness and it is enabled by the ability of designedhardware stack which provides both network connectivity anddata transmitting/receiving abilities to/from EV. Data withmonumental size and variety that is extracted from EV is pro-cessed in real time. In this paper a simple scenario that concern”battery range vs EV economy”, considering also ETAs of thenearest charging stations, is demonstrated. In this simulationuser is also notified and promoted to take action accordinglywhich underlines the action recommendation functionality ofthe platform, given the computed risk analysis.

Fig. 13: Risk detection case 3

Fig. 14: Execution plan diagram for risk detections

REFERENCES

[1] J. van der Heide, “13011 M2MGrids,” itea3.org. [Online]. Available:https://itea3.org/project/m2mgrids.html. [Accessed: 01-Nov-2018].

[2] Global EV Outlook 2018, May-2017. [Online]. Available:https://www.connaissancedesenergies.org/sites/default/files/pdfactualites/globalevoutlook2018.pdf. [Accessed: 01-Nov-2018].

[3] Global Automotive Executive Survey2017, Jan-2017. [Online]. Available:https://assets.kpmg.com/content/dam/kpmg/xx/pdf/2017/01/globalautomotive-executive-survey-2017.pdf.[Accessed: 01-Nov-2018].

[4] B. Hoßbach and B. Seeger, “Anomaly management using complexevent processing,” Proceedings of the 16th International Conference onExtending Database Technology - EDBT 13, 2013.

[5] Y. Liu and D. Wang, “Complex Event Processing Engine for Large Vol-ume of RFID Data,” 2010 Second International Workshop on EducationTechnology and Computer Science, 2010.

[6] N. Mao and J. Tan, “Complex Event Processing on uncertain datastreams in product manufacturing process,” 2015 International Confer-ence on Advanced Mechatronic Systems (ICAMechS), 2015.

[7] D. Woodard, Eclipse Kura™ Documentation. [Online]. Available:http://eclipse.github.io/kura/. [Accessed: 01-Nov-2018].

[8] “WSO2 Documentation,” Architecture - Complex EventProcessor 3.0.0 - WSO2 Documentation. [Online]. Available:https://docs.wso2.com/display/CEP300/Architecture. [Accessed: 01-Nov-2018].

493