DELIVERABLE D6.3 Proof-of-Concept “Smart Electric Car...

DELIVERABLE

ThisprojecthasreceivedfinancialsupportfromtheEuropeanUnionHorizon2020Programmeundergrantagreementno.688203.

D6.3Proof-of-Concept“SmartElectricCar”

Implementationv1

ProjectAcronym: bIoTopeProjecttitle: BuildinganIoTOpenInnovationEcosystemforConnectedSmartObjectsGrantAgreementNo. 688203Website: www.bIoTope-project.orgVersion: 1.0Date: 30June2017ResponsiblePartner: BMWAGContributingPartners: Eccenca,UniLuxemburgDisseminationLevel: Public X

Confidential–onlyconsortiummembersandEuropeanCommissionServices

Ref. Ares(2017)3317358 - 03/07/2017

D6.3Proof-of-Concept‘SmartElectricCar’–Implementationv1

©688203bIoTopeProjectPartners 2 30.06.2017

RevisionHistory

Revision Date Author Organization Description

0.1 16/05/2016 TobiasKraus BMWAG Initialdraft

0.2 19/06/2017 TobiasKrausSebastianNuck

AnnetteWeilandtNiklasKolbe

BMWAGeccencaeccencaUni.Lu

incorporationofcontributions

0.3 26/06/2016 TobiasKraus BMWAG Incorporatedreviews

1.0 28/06/2017 TobiasKraus BMWAG FinalVersion

Everyefforthasbeenmadetoensurethatallstatementsandinformationcontainedhereinareaccurate,howeverthebIoTopeProjectPartnersacceptnoliabilityforanyerrororomissioninthesame.



TableofContents

1. Introduction...........................................................................................................................51.1. Structureofthedocument..........................................................................................................5

2. SmartMobilityUseCase.........................................................................................................52.1. Services.......................................................................................................................................5

2.1.1. ChargingStationSelection...........................................................................................................52.1.2. RoutePlanning............................................................................................................................62.1.3. Pre-Conditioning..........................................................................................................................7

2.2. SmartMobilityPOCs...................................................................................................................82.2.1. RealTimeParkingInformation....................................................................................................82.2.2. RealTimeTrafficInformation......................................................................................................82.2.3. RealTimeChargingStationInformationandBooking.................................................................92.2.4. Pre-Conditioning........................................................................................................................102.2.5. Driveridentificationanddatausage.........................................................................................10

2.3. Architecture..............................................................................................................................112.3.1. Servicediscoveryandinvocation..............................................................................................112.3.2. Architectureontheend-userside.............................................................................................14

3. MobiVoc...............................................................................................................................15

4. ParkingandChargingStationDataPreparationandMapping...............................................174.1. Mappingarchitecture................................................................................................................184.2. Mappingexample......................................................................................................................184.3. RDFtoO-DF...............................................................................................................................22

5. Conclusion............................................................................................................................23

ListofTables

Table1:RealTimeParkingInformationPoCOutline..........................................................................................8Table2:RealTimeTrafficInformationPoCOutline............................................................................................9Table3:RealTimeChargingStationInformationandBookingPoCOutline.......................................................9Table4:Pre-ConditioningPoCOutline..............................................................................................................10Table5:DriverIdentificationanddatausagePoCoutline................................................................................10

ListofFigures

Figure1:BMWConnectedDrivePortalshowingrangeof i3andchargingstationsinLyon(left)andHelsinki(right)...........................................................................................................................................................6

Figure2:Comparisonoffastroute(left)andecological(“ECO-PRO”,right)......................................................6Figure3:RemoteAccesstoi3frombrowser(left),RemoteAccesstoSmartHomefromin-cari3(right).........7Figure4:Sequence-chartoffindingavailableparkingservicesanddata.........................................................11Figure5:ProcedureofavehiclelookingforparkingspacesinLyon.................................................................12Figure6:O-MInodewithreal-timedatafromparkingfacilitiesinLyon..........................................................13



Figure7:O-MInodeofferinglocationofvehicle..............................................................................................14Figure8:Architectureoverviewfromtheecosystemtothevehicle................................................................15Figure9:In-carappforshowingchargingstations...........................................................................................15Figure10:MobiVoc-Classesandpropertiesforparking..................................................................................17Figure11Themappingarchitecture.................................................................................................................18Figure12ThemappingUI.................................................................................................................................19Figure13ThecomplexmappingUI...................................................................................................................20



1. IntroductionMobility isalwaysbound infrastructuretosomeextent.AsMetropolitanareasgrowlargerandpopulationdensityincreasesintheseareas,therearealsomorepeoplewiththeneedfortransportationintheirdailylife.Thisleadstonewchallengesfortrafficauthoritiestooptimizeallmodalitiesinvolved.

Foranefficientlyrunningandfail-safetransportationsystem,all involvedpartiesneedtobeconnectedtoexchange data about supply and demand of transportation. Getting the systems that are involved in thisdataexchangetounderstandeachotherisanongoingeffort,moredatasourcesarecreatedeverydayandan increase in processing power and data analysis implies that the available sources should be used toleveragethevalueofthecontainedinformation.

TheSmartMobilityUseCase inbIoTopeaddresses the issues thatare involvedwhenconnectingdifferentsystemsofdifferentdomainsandages.Theimplementationinvolvesnearlythewholeecosystemandthushasthehigher-ordergoalsof

• Buildingasustainablewaytomakeuseofcrossdomaininformationandservices,

• Reducingorhandlinguncertaintyfordata-usageand

• Extendingtheexisting(de-facto)standardsandformatswithopen,scalablesolutions.

1.1. Structureofthedocument

Thestructureofthedocumentisasfollows:

• Chapter2motivates theSmartMobilityUseCase,describestheProof-of-Concepts (POCs)andtheaccordingarchitecturalaspects

• Chapter 3 describes the implementation of themobility vocabularyMobiVoc,which is the key tobringascalable,domain-specificstructuretothedata

• Chapter 4 describes how data is transformed into Linked Data and how it is embedded into theecosystem’sprotocols

• Chapter5wrapsupthedocumentwithashortsummaryandconclusions

2. SmartMobilityUseCase

DuetothenatureofmobilitymentionedintheIntroduction,theSmartMobilityUseCasehasbeendesignedtoparticularlymakeuseofthedatafromtheSmartcitypilots.ThethreeservicesrelatedtotheUseCaseasdescribedinD2.1aresubjecttocharging,routeplanningandsmarthomeintegration.Eachoftheseservicescanbeseenasasubstantialpartofawholemobilitysolutionoroffering.Usersofelectricvehiclesbenefitfromaseamlessintegrationoftheservicesintoanend-to-endjourney.

InteroperabilityanddataexchangeisachievedbyusingtheinfrastructureofthebIoTopeecosystem,aswellasextendedbyusingservices fromtheecosystemlikeContext-as-a-ServiceandBilling-as-a-Service. Inthisway,theSmartMobilityUseCasehasbothverticalandhorizontalaspects.Loweringtheefforttointegratethese and any upcoming services is extremely beneficial for cost-effective generation of new data-drivenmobilitysolutions.

2.1. Services

2.1.1. ChargingStationSelectionOneofthemainimpedingfactorsofelectricmobilityistheavailabilityofchargingstations.Rangeanxietyisstillanissueamongstthedriversofelectricvehicles.Buttakingintoaccountthat–inurbanareas-vehicles



areusuallyparkedmorethanlongenough,thistimecouldbeusedtochargethebatteryforthenexttriporevenmultipletrips.Therangeofelectricvehiclesiseasilylargeenoughforurbanandsuburbandestinations.InFigure1,therangeofa20%chargedBMWi3(BEV60Ah)isshowninLyonandHelsinkitogetherwiththeavailable charging stations in the BMW charging station directory. It is obvious that (apart from beingclustered),therearestillspotswithoutknownchargingstations.Forexample,thereiscurrentlynochargingstationlistedintheBMWchargingdirectorynearbytheAaaltoUniversityinEspoo.

Figure1:BMWConnectedDrivePortalshowingrangeofi3andchargingstationsinLyon(left)andHelsinki(right)

Toselectasuitablechargingstation,theafewfactorshavetomatch:thetechnicalcapabilitiesofthevehicle(typeof plug, power of outlet) but probably evenmore importantly thepossibility to pay for the electricenergyandlastbutnotleasttheavailabilityandreliabilityofthechargingstation.

In bIoTope, these challengeswill be addressed by extending the information about parking and chargingstations to give the driver more and reliable options to recharge her or his vehicle. Using the Ad-Hoc-ChargingstationservicefromtheSmartBuilding&Equipmentusecase,evennumberofavailablechargingstationscanbeincreased.CreatingandfindingthisnewchargingoptionshelpsDriversofBEVsimmediately.

2.1.2. RoutePlanningMobilityusuallyboilsdowntogettingfromAtoBandtheneedforanytypeofrouteIn-betweenoriginanddestination.Usinganelectricvehicle,thismeansyouneedaroutecalculatedonaroad-networkthattakesinto account the specificities of a Battery-Electric-Vehicle (BEV) such as a range and a consumption thatdiffersfromthatofanInternalCombustionEngine(ICE)vehicle.Figure2showstwodifferentroutesintheLyonarea.One isbasedonoptimizingthetimetogettothedestination(left), theother isoptimizingtheenergyconsumption(right).

Figure2:Comparisonoffastroute(left)andecological(“ECO-PRO”,right)



Thisisaverybasicexampleoftwodimensionsinwhichtheroutecanbeoptimized.Buttraffic-especiallyincities-isusuallymuchmorecomplicatedthanthis.Therearetraffic-jams,road-blockings,no-drive-zonesforcertainvehicle-types, tolls,etc.– this list isbasicallyendlessaseverycityhas itsownecosystem.Andthisonlycoversroad-basedtraffic,nottakingmultimodalapproachesintoaccount.

Inaddition,thedefinitionofabest route isoftenbasedontheprerequisitesofthedriverandthecurrentsituation.Thismeansthereisusuallynotasinglebestsolutionforthetaskofrouteplanning,butalwaysacompromisenecessary.Theroutingsystemhastotakethat intoaccountandhastodealwithuncertaintyandcontradictionsindata.

Toaddressthis,theavailabledatafromthecitiesshallbeusedforthecalculations,offeringboththedriversandtheauthoritiesabenefit: thedriverhasapainless journeyandthecitycandisseminate itsdatamoreeffectivelytoreliablycontrol–andavoid–unnecessarytraffic.Reliabledatathatreducesuncertaintyisthekeyforachievingthis.

InbIoTope, thedata fromthecitywillbeused toadjust the routecalculations:The Information fromtheBrusselsschoolpilotcanbeusedtoavoidtheschoolareasifthereisahigherdensityofchildrenonornearthe streets. This helps to avoid potential unsafe situations when passing vehicles have to look out forcrossingpedestrians–butthisalsomeansthatdriversofvehiclescanuseanalternativeroutethatisfasterand safer that the usual one. Having mechanism like this in place is inevitable for living together intomorrow’surbanareas.

2.1.3. Pre-ConditioningAchievingSmartMobilityalsomeanshavingaSmartVehiclethatisenabledtoexchangedatawiththe–forexample–SmartHome,ormoregeneral,SmartThings.Asof today, therearesolutionsthatallowyoutoremote control certain functions of your vehicle through the internet, or even access your smart homethroughthe in-carcomputersystem(Figure3).Basically, thismeansthatyoumakeuseofacross-domaincommunicationbetweenSmartThings,whichweareexperiencingalsoasaconvergingdigitalworldandtheredefinitionoftherolethatmobilityplaysinourtoday’sdailylife.

Figure3:RemoteAccesstoi3frombrowser(left),RemoteAccesstoSmartHomefromin-cari3(right)

Using data from different domains mostly also means different histories/roots of the data and differentapproaches in how communication is realized. By introducing Linked data and common vocabularies, allinvolved domains can use a common approach to employ these, and data can be understood by allcommunicatingentities.Tofacilitatethis,vocabulariesneedtobedefinedtogetherwithdomainexperts,seealsochapter3.

In bIoTope, the vehiclewill add a service offering to the ecosystemenabling a trigger of remote-servicesinsidethevehicle.Obviously,theserviceshouldonlybeusedbyauthorizedpersonssuchasthedriverofthevehicle.Foranautomatedserviceoffering,thisauthorizationalsoneedstobedelegatedtootherentities,suchasasmarthome.Inthisway,theecosystemmustofferasecureframeworktoinvokeservicesandtodescribeandmakeuseofdatacomingfromdifferentdomains.



2.2. SmartMobilityPOCs

Theoveralluse-casesaresub-dividedintosmallerentities,eachwithitsowngoalsandrequirements.EachoftheseentitiesrepresentsaProof-of-Concept(PoC),thatfocusesonadifferentaspectoftheecosystem.TheyactastestsofthebuildingblocksandtogethertheyformtheMobilityUse-Case.

ThefollowingchaptersdescribethedifferentPoCsbylistingthemsystematicallyinatable,wheretheLinkedRequirementsarethesameasdefinedinD2.1.ThegoalofthePoCdescribesthefocusoftheparticularPoCand can be seen as both the design goal and test subject. For the PoC to be fully functional, thePreconditionshavetobemet–whensomeoftherequirementsarenotmet,onlypartsofthegoalsofthePoCcanbeachieved.Mandatoryandoptional requirementsaremarkedas such.The interfacingwith theecosystem, the PoC itself can offer data or services,which are described in the table rowwith the samename.Thelastrowofthetablegivesanshortoverviewofmostpopular/knownstateoftheartsystemsandstandards,ifthereareany.

2.2.1. RealTimeParkingInformation

Findingaparkingspotisoneofthemainchallengesadriverisfacedwitheverydayandeachtimethecarisleft.Usually, a fewaspects are relevant tooffer aparking information service and tomakeuseof it. Themost important ones are the availability and pricing of the parking space, but also the distance of theavailableparkingspottotheactualdestinationoftheusercanbeveryimportant(e.g.whenitisrainingortheuserisonatightschedule).

Table1:RealTimeParkingInformationPoCOutline

LinkedRequirements ParkingSpotSituation(Req_SmartM_1)

RealTimeSystem(Req_SmartM_1_1)

UniformPaymentSystem(Req_SmartM_4)

GoalofPOC Discoveravailableservicesanddatasources(IoTBnB,CoaaS)

UseGeoreferenced(linked)data

Preconditions/Necessarydata Possibility to discover and identify relevant, existing parking services(incl.restrictions,residentsparkingarea,BEVonly,valet)(mandatory)

Availability(incl.capacityand/orprobability/prediction)

BookingandPaymentsystem,wherepossibleand/ornecessary

Services/dataoffered Position, Destination, estimated time of arrival (ETA), (currentroute/guidance)

Existinginformationaboutorpreferencesofdriver

Stateof theartof systemsanddataformats

Off- and On-Street-Parking-Information Systems and Providers(proprietary)

Publicdata:DATEXII

2.2.2. RealTimeTrafficInformation

The data that is used for or derived by traffic information usually involves traffic flow and incidents(accidents,hazards,constructionsites,…),butalsostrategieslikeprioritizingsomeroadswithhighercapacityoversmalleronescanbebeneficialforboththecityandthedrivers.Thesystemsthatmakeuseofthedataare usually built around routing algorithms that are operating on a representation of the realworld: thedigitalmap- This digitalmap is a discrete graphwhich contains all necessary information for the routingalgorithmtofindtheoptimumroute.Thisisalsothemainchallengewhendealingwiththistypeofsystems:Thereceiveddatamustbematchedtothisdiscretedatastructurestobeusable.



Table2:RealTimeTrafficInformationPoCOutline

LinkedRequirements PredictTrafficSituation(Req_SmartM_2)

RealTimeSystem(Req_SmartM_2_1)

GoalofPOC MappinganduseofcomplexGeoreferenced(linked)data

Discoveravailabledatasources

Preconditions/Necessarydata KnownLocationReferencingFormat/Layer(mandatory)

Incidents,flow,roadclosures,otherimpacts,etc.(mandatory)

Specialregulations(e.g.HOVlanes,BEVlanes,green-zones,…)

Services/dataoffered Position,Destination,RouteandETA

Typeofvehicleandoccupancy(forregulationsregardingBEV,HOV)


Trafficdatatransport(flow,incidents):TMC,TPEGTEC+TFP

Referencing:TMC,OpenLR,Agora-C(DLR-1),[ULR]

Publicdata:DATEXII,OCIT

2.2.3. RealTimeChargingStationInformationandBooking

Findingasuitablechargingstationcanbeseenasanextensionoffindingaparkingspot(havinganadditionalpower outlet for charging the vehicle). The Additional requirements are mainly the matching of the(electrical)typeandpaymentsystemofthechargingpole.Chargingstationsforelectricvehiclesareofteninthecitycentresandotherprimary locationswherefindingaparkingspot.Althoughthiswillchange inthefuture,whenmorechargingstationsarewidelyavailable, thereliabilityofthe informationofthechargingstationcrucialforthequalityoftheservice.

ExtensionofParkingPoC,additionalrequirementsduetoinvolvedchargingpole

Table3:RealTimeChargingStationInformationandBookingPoCOutline

LinkedRequirements ChargingStationDataBase(Req_SmartM_3)

ChargingStation(Req_SmartM_3_1)

UniformPaymentSystem(Req_SmartM_4)GoalofPOC Ad-hoc service generation and discovery (Charging station through

IoTBnB)

Preconditions/Necessarydata Locationandtypeofeachchargingstation(mandatory)

Accesstolivedataaboutchargingstations:-Availability-Reservation/bookingsystem-Priceandbillingoptions

Services/dataoffered Carpreferences(plugtype,amountofelectricenergyneeded,max/minpreferredelectricpower)

-Available(min/max)timeofparking&charging-Position,Destination,ETA


Severalproprietaryplatforms(hubject,goingelectric,etc.)

Opendirectoryservices(e.g.openchargemap)

Standardizedplugsandchargesystems(Europe:CCS)



2.2.4. Pre-ConditioningThis is a service offering of the vehicle to the ecosystem,whereonly theuser (or any authorizeddevice)should be able to activate. Main goal is the connections of different domains to enable and test cross-domainservicesintheecosystem.

Table4:Pre-ConditioningPoCOutline

LinkedRequirements Pre-ConditioningSystem(Req_SmartM_5)

CarsandBuildings(Req_SmartM_5_1)

GoalofPOC UsingaServicewithauthenticationandauthorization

Preconditions/Necessarydata Context/Information/Knowledgeasaservice (Weather,Driverschedule,etc.)

Securityasaservice:Authorizingtheservice(mandatory)

Preferencesoftheuser/driverforclimatesettings

Environmentalinformation

Services/dataoffered Status information about the car and environment (e.g. temperature,chargingconnection,etc.)

-Preconditioningserviceforauthorizedusers


BMWConnectedDriveRemoteServices(proprietary)

2.2.5. DriveridentificationanddatausageHavingdataavailableinalinkeddatarepresentation,thisdatacanbeusedtohelpandautomateallkindsoftasksintheuser’sdailylife.Averycomplexsetofinformationarethepreferencesofthedriver,raisingbothtechnicalandsecurity-relatedchallenges.

Table5:DriverIdentificationanddatausagePoCoutline

LinkedRequirements Driveridentification(Req_SmartM_6)

Driverdata(Req_SmartM_6_1)

GoalofPOC Distributedpersonalisation

Usedatafromdriver’scontext

Preconditions/Necessarydata Information/Knowledge/Contextasaservice(mandatory)

Security(privacy)asaservice

Driveridentification(logon,keys,mobiledevice,etc.)(mandatory)

Paymentmethodsbothofferedbyenvironmentandacceptedbydriver

Calendar, current destination, (additional miscellaneous information:preferred restaurant types, car sharing registrations, POIs – Points ofInterest,PDS-PersonalDataStore).

Services/dataoffered Identificationofcurrentdriver

Preferencesofdriverfromvehicledomain

Eventsandstatusupdates(e.g.majorincreaseinETA)




Calendar:iCal

Contacts:vCard

Vocabularyforlinkeddata:schema.org

2.3. Architecture

2.3.1. ServicediscoveryandinvocationServices, like the find parking service, can be dynamically discovered and requested through the ServiceDescription(SD)repository.

The findparking service is realised as an individual implementationwith anO-MI/O-DF interface.Upon amethodcall,thefindparkingservicerequeststheservicedescriptionsfromtheSDrepositorybyusingtermsfrom semantic vocabularies, as for exampleMobiVoc, andotherparameters (e.g. a geo-filter) todiscoverrelevantserviceanddatapublishers.Theservicedescriptionsareusedtoestablishpeer-to-peerconnectionstothesenodes.

Figure4:Sequence-chartoffindingavailableparkingservicesanddata

Thecollecteddataisusedtocalculatetheresultsoftheserviceimplementationtobesentastheresponsetotheconsumer.Incaseofthe“findparkingservice”,theMobiVoctermParkingFacilityisusedtodiscoverpublishers with parking information. The service algorithm takes the numberOfVacantParkingSpaces, thelocationandprofileofthevehicle,aswellasthe locationoftheparkingfacilities intoaccounttosendthedataofthebestparkingfacilityastheresponsetotheinitialrequestofthevehiclegateway.

Vehicle GatewayVehicle Gateway Find ParkingFind Parking SD RepositorySD Repository

getServiceDescriptions( "mobivoc:ParkingFacility", carLocation)

return(ParkingDataSD)

selectService("FindParking")

Parking DataParking Data

getServiceDescriptions(carLocation)

return(FindParkingSD, ...)

O-MI:READ(mobivoc:ParkingFacility)return(realtimeParkingData)

bestParking( realTimeParkingData, carLocation, carProfile)

return( bestParkingFacilityData)

routeCalculation( bestParkingFacilityData)

O-MI:METHOD( "FindParking", carLocation, carProfile)

Consumer Service Publisher Description Data Publisher



Figure5:ProcedureofavehiclelookingforparkingspacesinLyon

Allpublishersare indexed intheservicedescriptionrepositorywiththeirrespectiveURLsandothermeta-datatakenfromtheO-DFtree.Furthermore,servicepublishersareassignedwithageographicserviceareainwhich the service is valid. Upon receiving service description requestswith a location parameter, onlyservicedescriptionsforservicesthatareassignedtothatlocationarereturned.



Figure6:O-MInodewithreal-timedatafromparkingfacilitiesinLyon

Awebinterfaceisusedtomonitortheexecutionflowandvisualisetheserviceresults.ThelocationsofthevehiclesaresimulatedbyanagentthatupdatesthevalueseverysecondviaanO-MInode.Theexecutionflow is initiated by the vehicle gateway by reading the car location and initiating the service discovery,selectionandexecutionprocess.



Figure7:O-MInodeofferinglocationofvehicle

Theeventual resultof the findparkingservice contains the semanticannotateddata for thebestparkingfacility.Inthedescribedscenario,thisdataisusedbythevehiclegatewaytocalculatearoutetothelocationof this parking facility. The route is sent to the vehicle and displayed to the driver via the vehicle’s userinterface.

2.3.2. Architectureontheend-usersideAsdescribedinChapter2.1,thereareusuallyalreadysolutionsavailableinthemobilitydomain,whichalsoincludes end-user components and interfaces. In case of the BMW i3, this includes an integrated routingsystemaswellasparkingandchargingapps inthevehiclethatareavailablethroughthe in-carnavigationsystemandarefullyintegratedintothevehicle’sinfotainmentandcommunicationinfrastructure.

At the server-side, there are endpoints available for these apps including an underlying infrastructure toensure secure communication, vehicle provisioning, etc. Figure 8 gives an overview over the involvedcomponents and how they are related. The implementation of the POCs of the SmartMobility Use-Casefocusesontheparts inblueandwillbuildormodify them,whereas thegreypartsarealreadyexistingorhavewelldefinedinterfaces.



Figure8:Architectureoverviewfromtheecosystemtothevehicle

The implementation currently covers all mentioned components, concentrating the main efforts on thedefinitionofthecommunicationwiththeecosystem.However,afirstapptostudythefeasibilityhasbeencreated that can be used to display, choose and navigate to charging stations and parking lots. Figure 9showsafirstversionfilledwithstaticdata(retrievedfromtheexistingchargingstationinformationsystem).

Figure9:In-carappforshowingchargingstations

3. MobiVoc

Theusageofdifferentdataformats,datamodelsanddatacontentisamajorproblemthathastobesolvedfor enabling data exchange between IoT services. In the bIoTope project, parking data from threecities/regions is available. However, the data of each of the three sources is described by different datamodelsusingdifferentnaturallanguages.Therearealsodifferencesinwhichkindofinformationisprovidedandatwhatlevelofgranularity.Forexample,oneoftheLyonparkingdatasetsprovidesinformationaboutthe localisation of parking facilities. The static data is provided in French and includes e.g. coordinates,operator,ownertotalcapacity,streetnamesforentrancesandexits,openinghoursaswellasaspecification



whetherthefacilityisfreeofchargeornot.Lyonprovidestwomoreparkingdatasetsthatprovidereal-timecapacitiesofparkingfacilities.Brusselspublishesseveraldatasetsindicatingstaticparkingcapacities.Inonedataset, the information given is restricted to company, address and number of places,whereas anotherdatasetincludescoordinates,addressinformationinDutchandFrench(noinformationaboutentrancesandexits) and the number of places for disabled people. The examples of Brussels and Lyon show that dataintegrationandexchangeisachallengeforIoTservices.

In order to achieve interoperability of data sources and to enable IoT services requesting parkinginformation touseallparking informationavailableacommon language isneededtomapthecommon–butdifferentlymodelled–elementsofthedatasources.

FortheSmartMobilityUseCase,wedevelopanduseanopenRDFvocabularycalledMobiVoctodescribethedomainofparkingfacilitiesandchargingstations.AtthebeginningoftheprojectafirstdraftofMobiVocwasavailable.Ithassincebeenfurtherrefinedandextendedtodescribeparkingandchargingstationdataprovidedbythecities.

ThemainrationaleforusinganRDFvocabulary,orRDFandLinkedDataingeneralinthisUseCase,is,thatthereistherequirementtohaveaflexiblewaytodescribethe“things”inthe“InternetofThings”.WithRDFwe can describe topics such as Parking Facilities or Charging Stations, their locations or other abstractconcepts.Notonlythethingsthemselvesbutalsotheirrelationstoeachothercanbeexpressed,by,inthiscaselinks.

As a standard datamodel, RDF preserves the semantics of what it describes. The vocabularies used anddeveloped in the bIoTope context can also be reused and shared among other projects. This enablesextensibilitybyotherprojectsorapproacheswhocanuseMobiVocasabasevocabularyandthenextendittofittheirneeds.

SinceconceptssuchasParkingFacilitiesdescribedinRDFarereferenceablebytheirownURI,eachresourceisuniquelyidentifiableandcanthereforebelinkedwithotherresources,e.g.fromotherusecases.Theonlyrequirement is that the data has to be expressed via RDF. This enables interoperability since everybodyspeaksthesamevocabulary.

AfterbeingexpressedinRDF,thedatacanbequeriedviaSPARQL,ansemanticquerylanguagefordatabasesthat storeRDFdata. SPARQLprovideswell-knownSQL-like syntaxbutworkson topofRDFand thereforeuses triples (subject,predicate,object).GiventhenatureofRDFand itscapabilitiesofdescribingnotonlythingsbutalsotheirrelationstoeachother,SPARQLprovidesmeanstoquerythoserelations.Thisenablesusersofthisquerylanguagetoquerydatarelatedtoconcepts,suchas“friend-of-a-friend”relations.

Relationships between resources don’t always have to be explicitlymodelled.When usedwith a suitablereasoningengine,RDFdataallowimplicitrelationshipstobeinferredforthedata.Thisisespeciallyhelpfulifthesourcedataisincomplete.Anexampleforthatwouldbeasfollows:IfaParkingFacilityislocatedintheLyonandaParkingSpotislocatedinthisparticularParkingFacility,thenwecaninferthattheParkingSpotmustalsobelocatedinLyon.

MobiVoc(0.4.0)isavailableinaGithubrepository(https://github.com/vocol/mobivoc)andaccessibleviaaHTMLrepresentation(http://schema.mobivoc.org/).Itcoversthefollowingtopics:

• Parkingfacilities

• Accessconditions

• Pricespecification

• Timespecification

• Vehicles

• Chargingstations

Figure10showsanextractofMobiVocrepresentingclassesandpropertiesforparkinginformation.



Figure10:MobiVoc-Classesandpropertiesforparking

In the Smart Mobility Use Case, the parking data sources available will be mapped to the MobiVocvocabularywhich serves as a “lingua franca” for thedomain. Thus, it is possible toprovide an integratedparkingdatasetthatincludesallparkingdataavailablefromthethreecitiesandthatwillbepublishedinoneO-MI node. As RDF vocabularies are easily extendable, requirements of future data sources that are notknownyetcanbeincludedbyextendingtheMobiVocclassesandpropertieswhennecessary.

4. ParkingandChargingStationDataPreparationandMapping

ParkingandChargingStationdatacomesinavarietyofformatsandqualitylevels.Inordertohomogenizedata fromdifferent sources, theMobiVoc vocabulary is used tomap commonelements from thedata towell-known properties of the vocabulary. This makes the data not only consistent across the differentsourcesbutalsoenablesmachinereadabilityandinterpretability.

The data is often provided through open data portals from cities and therefore satisfies the cities’requirements.Fortheproject’scontexthowever,thedatadoesneedanadditionalstepofprocessing.

Civic structure (s:)

vehicle width limit : decimal

additional information : string

vehicle length limit : decimal

vechicle height limit : decimal

ID : string

picture : string

name : string

A public structure, such as a town

hall or concert hall, parking facility

or charging point.

Place (s:)

latitude (geo:) : string

longitude (geo:) : string

Entities that have a somewhat

fixed, physical extension.

Price specification (s:)

free of charge : boolean

unspecified charge : boolean

A structured value representing

a price or price range for an

item.

price

Opening hours specification (s:)

A structured value providing

information about the opening

hours of a place or a certain

service inside a place.

opening hours specification (s:)

Payment method (s:)

A payment method is a standardized

procedure for transferring

the monetary amount for a

purchase. Payment methods

are characterized by the

legal and technical structures

used, and by the organization

or group carrying out the

transaction.

accepted payment method (s:)

Civic structure status

Status information of a civic

structure.

civic structure status

Access condition

A condition that has to be

fullfilled to get access

to a civic structure.

access

http://purl.org/goodrelations/v1#BusinessEntity

operated by

owned by

Postal address (s:)

The mailing address.

address (s:)

Entrance

Entrance of a parking facility

where vehicles can enter

the parking facility.

Capacity

maximum value : integer

Capacity of a parking facility

or a parking space.

Parking usage type

A type of special purpose

a parking space is designated

for, like women's parking

spaces.

parking usage type

Vehicle (s:)

A vehicle is a device that

is designed or used to transport

people or cargo over land,

water, air, or through space.

intended for vehicle

Exit

Exit of a parking facility

where vehicles can leave

the parking facility.

Automated parking garage

Parking garage with an automated

parking system that automatically

moves cars to the available

parking space somewhere in

the garage.

Parking facility

number of carsharing spaces : integer

fill rate : string

total capacity : integer

exit rate : string

number of parking spaces for disabled persons : integer

number of vacant parking spaces : integer

number of parking spaces for motorbikes : integer

number of women's parking spaces : integer

queuing time : string

rate of occupancy : string

number of occupied parking spaces : integer

number of parking spaces for bicycles : integer

Any facility or area assigned for parking vehicles. A parking

facility can provide one or more parking spaces.

valid for vehicle

User group

A group of users having a

common characteristic.

valid for user group

Time specification

time unit : string

time end value : float

time start value : float

overnight : boolean

Specific time a price specification

is due for.

due for time

Charging point

energy source : string

Defines charging points for

electric vehicles.

Charger

brand : string

model : string

voltage in V : decimal

current type : string

current in A : decimal

three-phased current available : boolean

power in kW : decimal

Describes characteristics of the charger.

charger

Plug

voltage in V : decimal

cable available : boolean

current type : string

current in A : decimal

three-phased current available : boolean

power in kW : decimal

Describes plug characteristics.

Plug type

Describes the type of available

plug.

plug type

Underground parking garage

Parking facility with one

or more levels below the

surface and none above ground.

Parking garage

A single level or multilevel

parking building to park

at.

customer of

employee of

Action

Action that is done.

entrance

has capacity

exit

has charging point

Parking facility connections

Transport connections available

at the parking facility (e.g.

Park & Ride).

connected to

Parking space

A parking space is a location

that is designated for parking

a vehicle. A parking space

has a certain size, is sometimes

marked and can be located

at roadside or inside a parking

facility. Depending on the

location of the parking space,

there can be regulations

regarding the time allowed

to park and a fee paid to

use the parking space.

parking space

Parking facility feature

Features of the parking facility

(e.g. parking for disabled

people).

feature

Arrangement pattern

Pattern how parking spaces

are arranged in a parking

facility or at roadside.

arrangement pattern

Real time capacity

date (dct:) : datetime

current value : integer

Real-time capacity of a parking

facility or parking space.

has capacityhas charging point arrangement pattern

Bicycle parking station

Building or structure designed

for use as a bicycle parking

facility.

plug

Parking lot

Parking area on a single

groundfloor level that is

usually located outdoor.

restricted to vehicle typerestricted to user group action



Common challenges to overcome when working with heterogeneous data sources from cities acrossmultiplecountriesareforexampleinconsistentpropertyandidentifierlanguages.Thismeansthatnotonlyare theactualdatavalues in thecountries’ language,butalso theproperties themselves. Inorder tomapthese properties to our vocabulary, they have to be translated and interpreted. Another observation arevaluesdisplayedinanon-interpretableform.Thiscoversforexamplelatitudeandlongitudevaluesforgeopositioningthataremodelledinsimplearraysinthesourcedatabutneedtobesplitinordertobemappedto theappropriatepropertiesof thevocabulary.Due to the fact thatpartsof thedatacomes fromcities’crawlingtheirownwebsites,therearevaluesthatsimplycontaindatastringsfromwebsites.Oneexamplewould be theopening hours of a parking lot in Lyon that aremodelled as “Ouvert 24h/24h”. In order totransformthisvalueintosomethingmachinereadableandinterpretable,wefirstneedtoidentifythatthislabelcontainsinformationaboutwhentheparkinglotisopen.Thentheinformationabout“24h”needstobetransformedintoatimerangefrom00:00to23:59.

4.1. Mappingarchitecture

In order to map the data to the MobiVoc vocabulary, eccenca Corporate Memory is used. Figure 11illustratesthearchitecture:

Figure11Themappingarchitecture

The process begins with identifying the data sources. In our examples later on we use the Grand Lyonparking facilities dataset that is supplied in a JSON format.Once identified,multiple data sources can beusedbyeccencaCorporateMemorytocreateamappingwiththeuserinterface.Afterexecution,thedataismappedtoMobiVocandstoredinatriplestoreasRDFdata.ThemappingalsocoversidentifyingcertainasRDFresourcesandlinkingthetotheappropriateDBpediaorGeoNamesresources.OncetheRDFdatasetisavailableitcanbetransformedintoO-DFandputintoanO-MImessageinordertobepushedtoanO-MInodevia thewrite call.Now themappeddata is availableon thenodeand canbeoffered in the IoTBnBmarketplaceorascontextproviderintheCoaaScomponent.

4.2. Mappingexample

The example data originates from the Grand Lyon’s Parking Facilities data which is updated daily. Itcompriseslocalisationanddataaboutapproximately30parkingfacilities.

TheexampleinListing1showsthesourcedataofoneinstanceofaParkingFacility.

Data sources

Lyonfrench data

CSV

JSON

XML

Brusselsfrench/dutch/english data

CSV

Helsinkifinnish data

CSV

Processing

eccenca

RDF

DBpedia

GeoNames

RDF

RDF

O-DF O-MI Node

O-MIwrite

O-MI read

O-MI read

O-MI read

JSON



{ "features": [ { "geometry": { "coordinates": [ 4.750940328299037, 45.81385676152648 ], "type": "Point" }, "properties": { "annee": "2008", "avancement": "Existant", "capacite": "5", "capacite2rm": "0", "capaciteautopartage": "0", "capacitepmr": "1", "capacitevelo": "3", "codetype": "5", "commune": "DARDILLY", "fermeture": "Ouvert 24h/24h", "gabarit": "", "gestionnaire": "GRAND LYON", "gid": "1", "idfournisseur": "", "idparking": "P578", "idparkingcriter": "", "nom": "Gendarmerie", "observation": "", "parkingtempsreel": "Non", "proprietaire": "GRAND LYON", "reglementation": "Gratuit", "situation": "En surface", "typeparking": "Poche de stationnement", "usage": "Libre", "vocation": "", "voieentree": "Avenue de Verdun", "voiesortie": "Avenue de Verdun" }, "type": "Feature" } ]} }

Listing1

Figure12ThemappingUI



Thedatacontainsanumberoftheinconsistenciesdescribedabove.Firstofall,someoftheidentifiersareinFrench.Also,theopeninghoursexamplementionedbeforeisfoundinthisdataset.InordertomapthisdatatheeccencaDataIntegrationtoolisused.ThescreenshotinFigure12showshowthemappingcanbecreatebyusingtheappropriatemappingUIineccencaCorporateMemory.

Weherebydifferentiatebetweenthreedifferentkindsofmapping rule types.Directmappingsaremostlysimple1-to-1mappings for twoproperties thatcanbemappeddirectly toeachother. In theexamplewemap the property “nom” from the source dataset to both aMobiVoc name (mv:name) and a RDFS label(rdfs:label).Thesecondkindofmappingarecomplexmappings.Theycanbeusedwhenmappingrequiresfurtherprocessingstepslikesplittinganarrayorstringintomultipleparts.Intheexamplewemakeusofthisbysplittingthecoordinatesarrayintolatitudeandlongitude.ThescreenshotinFigure13showstheUIforthis exact processing step. The third and final kind ofmapping rule type are ObjectMappings. They arebasicallymappingswithinmappingsinordertomaphierarchicalstructures.Intheexampleweusethise.g.formappingthedifferentkindsofcapacities.

Theresultisafully-fledgedRDFdatasetrepresentedintheTurtleformatinListing2.

Figure13ThecomplexmappingUI



@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix schema: <http://schema.org/> . @prefix wgs84: <http://www.w3.org/2003/01/geo/wgs84_pos#> . @prefix mv: <http://schema.mobivoc.org/> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . @prefix ex: <http://example.org/parkingfacility/grandlyon/P578/> . @prefix xsd: <http://www.w3.org/2001/XMLSchema#> . ex:Gendarmerie a mv:ParkingFacility ; rdfs:label "Gendarmerie" ; mv:capacity ex:capacity, ex:bicycleCapacity, ex:carSharingCapacity, ex:disabledCapacity , ex:motorbikeCapacity ; mv:name "Gendarmerie" ; schema:address ex:address ; mv:price ex:price ; mv:entrance ex:entrance ; mv:exit ex:exit ; schema:openingHoursSpecification ex:openingHours ; wgs84:lat 45.81385676152648 ; wgs84:long 4.750940328299037 . ex:address a schema:PostalAddress ; schema:addressLocality "Dardilly" ; schema:adressRegion "Grand Lyon" ; schema:country <http://dbpedia.org/resource/France> ; rdfs:label "Dardilly, Grand Lyon" . #reglementation: Gratuit ex:price a schema:PriceSpecification ; mv:freeOfCharge "true"^^xsd:boolean ; . #entrance, exit ex:entrance a mv:Entrance ; rdfs:label "Avenue de Verdun"^^xsd:string ; schema:address ex:entranceAdress ; . ex:entranceAdress a schema:PostalAddress ; schema:streetAddress "Avenue de Verdun"^^xsd:string ; schema:addressLocality "Dardilly" ; schema:country <http://dbpedia.org/resource/France> ; rdfs:label "Avenue de Verdun, Dardilly"^^xsd:string ; . ex:exit a mv:Exit ; rdfs:label "Avenue de Verdun"^^xsd:string ; schema:address ex:exitAdress ; . ex:exitAdress a schema:PostalAddress ; schema:streetAddress "Avenue de Verdun"^^xsd:string ; schema:addressLocality "Dardilly" ; schema:country <http://dbpedia.org/resource/France> ; rdfs:label "Avenue de Verdun, Dardilly"^^xsd:string ; . #capacity ex:capacity mv:intendedForVehicle mv:Car ; mv:totalCapacity 5 ; a mv:Capacity . ex:bicycleCapacity mv:intendedForVehicle mv:Bicycle ; mv:totalCapacity 3 ; a mv:Capacity . ex:carSharingCapacity mv:intendedForVehicle mv:Car ; mv:parkingUsageType mv:CarsharingParkingSpace ; mv:totalCapacity 0 ; a mv:Capacity . ex:disabledCapacity mv:intendedForVehicle mv:Car ; mv:parkingUsageType mv:DisabledParkingSpace ; mv:totalCapacity 1 ; a mv:Capacity . ex:motorbikeCapacity mv:intendedForVehicle mv:Motorbike ; mv:totalCapacity 0 ; a mv:Capacity . #fermeture ex:openingHours schema:closes "23:59" ; schema:opens "00:00" ; a schema:OpeningHoursSpecification ; rdfs:label "Ouvert 24h/24h" .

Listing2



4.3. RDFtoO-DFInorder topush theRDF to theO-MInode, the relevantpropertiesneed tobe transformedtoO-DF.TheexampleinListing3showshowafinisheddatasetlookslike.ThisdatahasbeenprovidedviatheO-MInodefromtheAaltoUniversity.<msg> <Objects xmlns="http://www.opengroup.org/xsd/odf/1.0/" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:odf="http://www.opengroup.org/xsd/odf/1.0/"> <Object prefix="schema: http://www.schema.org/ mv: http://www.schema.mobivoc.org/" type="ParkingService"> <id>ParkingService</id> <Object type="list"> <id>ParkingFacilities</id> <Object type="schema:ParkingFacility"> <id>DipoliParkingLot</id> <InfoItem name="MaxParkingHours"> <value unixTime="1496929058" dateTime="2017-06-08T16:37:38.941+03:00">20</value> </InfoItem> <InfoItem type="mv:isOwnedBy" name="Owner"> <value unixTime="1496929058" dateTime="2017-06-08T16:37:38.941+03:00">Aalto University</value> </InfoItem> <Object type="list"> <id>ParkingSpaceTypes</id> <Object type="mv:ParkingUsageType"> <id>CarParkingSpace</id> <InfoItem type="mv:PriceParking" name="HourlyPrice"> <value unixTime="1496929058" type="xs:int" dateTime="2017-06-08T16:37:38.941+03:00">2</value> </InfoItem> <Object type="list"> <id>Spaces</id> <Object type="mv:ParkingSpace"> <id>Space1</id> <InfoItem name="User"> <value unixTime="1496929058" dateTime="2017-06-08T16:37:38.941+03:00">NONE</value> </InfoItem> <InfoItem name="Available"> <value unixTime="1496929058" dateTime="2017-06-08T16:37:38.941+03:00">true</value> </InfoItem> </Object> <Object type="mv:ParkingSpace"> <id>Space3</id> <InfoItem name="Available"> <value unixTime="1496929058" dateTime="2017-06-08T16:37:38.941+03:00">true</value> </InfoItem> <InfoItem name="User"> <value unixTime="1496929058" dateTime="2017-06-08T16:37:38.941+03:00">NONE</value> </InfoItem> </Object> </Object> </Object> <Object type="schema:GeoCoordinates"> <id>geo</id> <InfoItem name="longitude"> <value unixTime="1496929058" type="xs:double" dateTime="2017-06-08T16:37:38.941+03:00">24.831899</value> </InfoItem> <InfoItem name="latitude"> <value unixTime="1496929058" type="xs:double" dateTime="2017-06-08T16:37:38.941+03:00">60.184274</value> </InfoItem> <Object type="schema:PostalAddress"> <id>address</id> <InfoItem name="addressCountry"> <value unixTime="1496929058" dateTime="2017-06-08T16:37:38.941+03:00">Finland</value> </InfoItem> <InfoItem name="addressRegion"> <value unixTime="1496929058" dateTime="2017-06-08T16:37:38.941+03:00">Espoo</value> </InfoItem> <InfoItem name="streetAddress"> <value unixTime="1496929058" dateTime="2017-06-08T16:37:38.941+03:00">Otakaari 15</value> </InfoItem> <InfoItem name="addressLocality"> <value unixTime="1496929058" dateTime="2017-06-08T16:37:38.941+03:00">Otaniemi</value> </InfoItem> <InfoItem name="postalCode"> <value unixTime="1496929058" type="xs:double" dateTime="2017-06-08T16:37:38.941+03:00">2150.0</value> </InfoItem> </Object> </Object> <Object type="schema:OpeningHoursSpecification"> <id>openingHoursSpecification</id> <InfoItem name="closes"> <value unixTime="1496929058" type="schema:Time" dateTime="2017-06-08T16:37:38.941+03:00">24:00</value> </InfoItem> <InfoItem name="opens"> <value unixTime="1496929058" type="schema:Time" dateTime="2017-06-08T16:37:38.941+03:00">00:00</value> </InfoItem> </Object> </Object> </Object> </Object> </Objects> </msg>

Listing3



5. ConclusionThePlanningandImplementationofthesmartMobilityUseCasestartwithdefiningasuitablevocabularytobeusedforthemobilitydomaininbIoTope.Tousethedifferentvocabulariesthroughouttheecosystem,apossibilityforembeddinglinkeddatainO-MI/O-DF.Bynow,wehaveachievedandagreedonasolutionthatwillbeusedforthis:TheO-MInodesfromthemobilitydomainwilluseMobivocandexistingvocabulariestogetherwithO-DF.

TheimplementationoftheSmartMobilityUseCaseisongoing;firstTestsforintegratingthesystemintothevehiclewere successful and the routing systems can be adjustedwith zones that should be avoided (forschoolsafety).

Astheconnectiontotheactualcities’datasourcesandservicescontinues,thevocabularywillbeextendedaccordingtothenewrequirements.Bycoveringadditionalandnewprerequisites,weensurethatMobiVocis ready tobe scalable andadaptiveevenafter theendof theproject, as extensibility is oneof themaingoalsoftheapproach.

End-to-EndDemonstratorsareplannedineachcitycoveringthethreemaingoalsoftheSmartMobilityUse-Case.

DELIVERABLE D6.3 Proof-of-Concept “Smart Electric Car...

Documents

Transcript of DELIVERABLE D6.3 Proof-of-Concept “Smart Electric Car...