Assessment of the Technical Feasibility of ICT and Charging Solutions

Total Page:16

File Type:pdf, Size:1020Kb

Assessment of the Technical Feasibility of ICT and Charging Solutions Assessment of the technical feasibility of ICT and charging solutions Deliverable No. D4.2.1 Workpackage No. WP4.2 Workpackage Title Technical feasibility of ICT and charging solutions Authors ENIDE, ICCS, CEA, CIRCE, CRF, TECNO, UNIGE, VEDE Status (Final; Draft) Final Dissemination level (Public; Public Restricted; Confidential) Project start date and duration 01 January 2014, 48 Months Revision date 2014 – 10 – 31 Submission date 2014 – 10 – 31 This project has received funding from the European Union’s Seventh Framework Programme for research, technological development and demonstration under grant agreement no 605405 Copyright FABRIC <D4.2.1> Public Contract N. 605405 TABLE OF CONTENTS EXECUTIVE SUMMARY ............................................................................................................................ 12 1. INTRODUCTION ............................................................................................................................... 17 1.1 GENERAL .................................................................................................................................... 17 1.2 CONTRIBUTION TO FABRIC OBJECTIVES ...................................................................................... 17 1.3 DELIVERABLE STRUCTURE ........................................................................................................... 17 2. METHODOLOGY .............................................................................................................................. 19 2.1 GENERAL ANALYSIS ..................................................................................................................... 19 2.2 FABRIC-ORIENTED ANALYSIS ...................................................................................................... 19 2.3 GAPS AND CHALLENGE ANALYSIS .................................................................................................. 20 2.4 ASSESSMENT .............................................................................................................................. 20 2.4.1 ASSESSMENT CRITERIA FOR CHARGING SOLUTIONS: ...................................................................... 21 2.4.2 ASSESSMENT CRITERIA FOR ICT SOLUTIONS ................................................................................. 21 3. ASSESSMENT OF CHARGING SOLUTIONS ................................................................................. 22 3.1 INTRODUCTION ............................................................................................................................ 22 3.2 POLITO CWD WPT SOLUTION ................................................................................................... 22 3.3 SAET SPA - INDUCTION POWERED VEHICLE (IPV).......................................................................... 23 3.4 KAIST - ONLINE ELECTRIC VEHICLE (OLEV) ................................................................................ 24 3.5 CONDUCTIX WAMPFLER IPT ........................................................................................................ 24 3.6 PLUGLESS POWER ...................................................................................................................... 25 3.7 WITRICITY ................................................................................................................................... 26 3.8 SIEMENS E HIGHWAY .................................................................................................................... 27 4. ASSESSMENT FOR ICT SOLUTIONS............................................................................................. 28 4.1 PRELIMINARY FUNCTIONAL ARCHITECTURE ................................................................................... 28 4.2 FABRIC ELECTRIC MOBILITY PLATFORM ....................................................................................... 30 4.2.1 BASELINE TECHNOLOGIES ............................................................................................................ 30 4.2.1.1 SERVICE BUS .......................................................................................................................... 31 4.2.1.1.1 WSO2 ESB ....................................................................................................................... 31 4.2.1.1.2 OPEN ESB ......................................................................................................................... 34 4.2.1.1.3 SERVICE MIX ....................................................................................................................... 35 4.2.1.2 PROCESS MANAGEMENT & SERVICE ORCHESTRATION ............................................................. 38 4.2.1.2.1 APACHE ODE ..................................................................................................................... 38 4.2.1.2.2 WSO2 BUSINESS PROCESS SERVER .................................................................................. 40 4.2.1.3 COMPLEX EVENT PROCESSING ................................................................................................ 42 4.2.1.3.1 WSO2 COMPLEX EVENT PROCESSING ................................................................................ 42 4.2.1.3.2 ESPER ............................................................................................................................... 45 4.2.2 IBM PLATFORM : IOC – INTELLIGENT OPERATIONS CENTER ........................................................... 46 4.2.3 SUMMARY ASSESSMENT FOR FABRIC ELECTRIC MOBILITY PLATFORM ......................................... 50 4.2.3.1 BASELINE TECHNOLOGIES ....................................................................................................... 50 4.2.3.2 IBM PLATFORM ....................................................................................................................... 51 4.3 IDENTIFICATION ........................................................................................................................... 52 4.3.1 OPTICAL TECHNOLOGY ................................................................................................................ 52 4.3.1.1 BARCODE READERS ................................................................................................................ 52 4.3.1.2 AUTOMATIC NUMBER PLATE RECOGNITION – ANPR ................................................................. 54 4.3.1.2.1 ANPR PROCESSES ............................................................................................................. 55 4.3.1.2.2 ANPR APPLICATIONS ......................................................................................................... 56 4.3.2 RADIO FREQUENCY IDENTIFICATION – RFID ................................................................................. 59 4.3.2.1 TAGS ...................................................................................................................................... 59 4.3.2.2 READERS ................................................................................................................................ 60 4.3.3 DEDICATED SHORT -RANGE COMMUNICATIONS ............................................................................. 63 4.3.4 SUMMARY ASSESSMENT FOR AVI TECHNOLOGIES ........................................................................ 67 Page 2 Copyright FABRIC <D4.2.1> Public Contract N. 605405 4.4 ROUTING ..................................................................................................................................... 69 4.4.1 GOOGLE MAPS WEB SERVICES .................................................................................................... 69 4.4.2 BING MAPS ................................................................................................................................. 71 4.4.3 ARCGIS..................................................................................................................................... 72 4.4.4 HERE MAPS ............................................................................................................................... 73 4.4.5 MAP QUEST ................................................................................................................................. 75 4.4.6 OPEN STREET MAP ....................................................................................................................... 76 4.4.7 SUMMARY ASSESSMENT FOR ROUTING ........................................................................................ 77 4.5 CONNECTED CAR AND HMI .......................................................................................................... 79 4.5.1 MIRROR LINK ............................................................................................................................... 79 4.5.2 CAR PLAY .................................................................................................................................... 82 4.5.3 OPEN AUTOMOTIVE ALLIANCE ...................................................................................................... 84 4.5.4 SUMMARY ASSESSMENT FOR CAR CONNECTED AND HMI TECHNOLOGIES ..................................... 86 4.6 CHARGING INFRASTRUCTURE OPERATOR : LOAD BALANCING CONTROL .......................................... 87 4.6.1 INTRODUCTION TO ELECTRIC VEHICLE LOAD BALANCING ................................................................ 87 4.6.2 TECHNICAL
Recommended publications
  • Industrial Control Via Application Containers: Migrating from Bare-Metal to IAAS
    Industrial Control via Application Containers: Migrating from Bare-Metal to IAAS Florian Hofer, Student Member, IEEE Martin A. Sehr Antonio Iannopollo, Member, IEEE Faculty of Computer Science Corporate Technology EECS Department Free University of Bolzano-Bozen Siemens Corporation University of California Bolzano, Italy Berkeley, CA 94704, USA Berkeley, CA 94720, USA fl[email protected] [email protected] [email protected] Ines Ugalde Alberto Sangiovanni-Vincentelli, Fellow, IEEE Barbara Russo Corporate Technology EECS Department Faculty of Computer Science Siemens Corporation University of California Free University of Bolzano-Bozen Berkeley, CA 94704, USA Berkeley, CA 94720, USA Bolzano, Italy [email protected] [email protected] [email protected] Abstract—We explore the challenges and opportunities of control design full authority over the environment in which shifting industrial control software from dedicated hardware to its software will run, it is not straightforward to determine bare-metal servers or cloud computing platforms using off the under what conditions the software can be executed on cloud shelf technologies. In particular, we demonstrate that executing time-critical applications on cloud platforms is viable based on computing platforms due to resource virtualization. Yet, we a series of dedicated latency tests targeting relevant real-time believe that the principles of Industry 4.0 present a unique configurations. opportunity to explore complementing traditional automation Index Terms—Industrial Control Systems, Real-Time, IAAS, components with a novel control architecture [3]. Containers, Determinism We believe that modern virtualization techniques such as application containerization [3]–[5] are essential for adequate I. INTRODUCTION utilization of cloud computing resources in industrial con- Emerging technologies such as the Internet of Things and trol systems.
    [Show full text]
  • 2018 Enabling Technology Leadership Award
    2018 Global In-Vehicle Infotainment Enabling Technology Leadership Award 2018 BEST PRACTICES RESEARCH Contents Background and Company Performance ........................................................................ 3 Industry Challenges .............................................................................................. 3 Technology Leverage and Customer Impact ............................................................. 4 Significance of Enabling Technology Leadership ............................................................. 8 Understanding Enabling Technology Leadership ............................................................. 8 Key Benchmarking Criteria .................................................................................... 9 Best Practices Award Analysis for Automotive Grade Linux .............................................. 9 Decision Support Scorecard ................................................................................... 9 Technology Leverage .......................................................................................... 10 Customer Impact ............................................................................................... 10 Decision Support Matrix ...................................................................................... 11 Best Practices Recognition: 10 Steps to Researching, Identifying, and Recognizing Best Practices ................................................................................................................. 12 The Intersection
    [Show full text]
  • RTAI-Lab Tutorial: Scicoslab, Comedi, and Real-Time Control
    RTAI-Lab tutorial: Scicoslab, Comedi, and real-time control Roberto Bucher 1 Simone Mannori Thomas Netter 2 May 24, 2010 Summary RTAI-Lab is a tool chain for real-time software and control system development. This tutorial shows how to install the various components: the RTAI real-time Linux kernel, the Comedi interface for control and measurement hardware, the Scicoslab GUI-based CACSD modeling software and associated RTAI-Lab blocks, and the xrtailab interactive oscilloscope. RTAI-Lab’s Scicos blocks are detailed and examples show how to develop elementary block diagrams, automatically generate real-time executables, and add custom elements. 1Main RTAI-Lab developer, person to contact for technical questions: roberto.bucher at supsi.ch, see page 46 Contents 1 Introduction 4 1.1 RTAI-Lab tool chain . .4 1.2 Commercial software . .4 2 Installation 5 2.1 Requirements . .5 2.1.1 Hardware requirements . .5 2.1.2 Software requirements . .6 2.2 Mesa library . .7 2.3 EFLTK library . .7 2.4 Linux kernel and RTAI patch . .7 2.5 Comedilib . .8 2.6 RTAI (1st pass) . .8 2.7 RTAI tests . .9 2.8 Comedi . .9 2.9 RTAI (2nd pass) . 10 2.10 ScicosLab . 11 2.11 RTAI-Lab add-ons to Scicoslab-4.4 . 11 2.12 User configuration for scicoslab-4.4 . 11 2.13 Load the modules . 11 3 Development with RTAI-Lab 13 3.1 Boot Linux-RTAI . 13 3.2 Start Scicos . 13 3.3 RTAI-Lib palette . 14 3.4 Real-time sinewave: step by step . 16 3.4.1 Create block diagram .
    [Show full text]
  • Android Before Ios in The
    Vol. 27, No. 1 u hansenreport.com u February 2014 Microsoft Windows Android before iOS in the Car As technology giants Google and Apple baked” and Apple’s approach to the indus- Not Part of Sync 3 focus on extending their reach into the car, try as arrogant. In contrast Google is said Google has made far more progress than its to be more accommodating, indicating it is rival. Both companies have efforts under- willing to adapt Android to make it more Ford Goes with Panasonic and QNX way to make devices based on their respec- useful to carmakers. The software devel- Sync 3, Ford’s third-generation Sync tive operating systems more compatible oped by the OAA is expected to debut in a infotainment system, will be based on with vehicle head units. Google has gone a production vehicle as early as the end of QNX from Blackberry, not Windows Em- step further by showing a willingness to 2014. Nobody is saying if and when iOS in bedded Automotive from Microsoft as adapt its Android operating system to run the Car will find production. with Sync 1 and Sync 2. According to Ford, the vehicle’s head unit, potentially replac- the QNX operating system makes more ing QNX, Linux or Windows. Open Automotive Alliance efficient use of memory and computing At the January 2014 Consumer Elec- Drivers would love to be able to safely power. When an infotainment design goes tronics Show, Google, along with Audi, and easily use smartphones in their cars, to production, carmakers like to have no GM, Honda, Hyundai and Nvidia, and carmakers are keen to offer cars that more than 60% utilization of microproces- announced the founding of the Open let them do that.
    [Show full text]
  • Author Guidelines for 8
    Proceedings of the 52nd Hawaii International Conference on System Sciences | 2019 A New Approach to the Evolution of Collaboration Platforms: The Case of South Korea’s Convergence Alliances Heeyoung Jang Minsun Kim Sungmin Cho Korea Institute of Industrial Technology Korea Institute of Industrial Technology Korea Institute of Industrial Technology [email protected] [email protected] [email protected] Jongho Lee Hongbum Kim* Korea Institute of Industrial Technology Korea Institute of Industrial Technology [email protected] [email protected] * Corresponding author Abstract since 2000, there have been no new industries that can generate economy leverage in Korea. While organizations and alliances for collaboration Many studies have demonstrated that among the have been promoted by governments for many years, various factors affecting Korea’s rapid economic their performance has not been very meaningful in growth in the twentieth century, government-led terms of activation or outcome, particularly in South industrial policies were the main cause of the economic Korea. Thus, as a tool for creating new industries and development (e.g., [1]). However, in the current growth engines, a new form of collaboration complex economic environment, arguments for platform—convergence alliances—is being promoted maintaining government-led industrial policies are now in South Korea. In order to explore the distinct not appropriate and this is why a new type of economic characteristics and advantages of convergence growth paradigm is necessary. alliances, this research compares this new type of The government, media, scholars, and practitioners platform with existing collaboration platforms. By now emphasize that new strategies for economic using a case analysis framework with in-depth growth must be developed that will help Korea adapt to interviews, this research suggests several implications the era of the Fourth Industrial Revolution.
    [Show full text]
  • Enabling Mobile Service Continuity Across Orchestrated Edge Networks
    This is a postprint version of the following published document: Abdullaziz, O. I., Wang, L. C., Chundrigar, S. B. y Huang, K. L. (2019). Enabling Mobile Service Continuity across Orchestrated Edge Networks. IEEE Transactions on Network Science and Engineering, 7(3), pp. 1774-1787. DOI: https://doi.org/10.1109/TNSE.2019.2953129 © 2019 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes, creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works. Enabling Mobile Service Continuity across Orchestrated Edge Networks Osamah Ibrahiem Abdullaziz, Student Member, IEEE, Li-Chun Wang, Fellow, IEEE, Shahzoob Bilal Chundrigar and Kuei-Li Huang Abstract—Edge networking has become an important technology for providing low-latency services to end users. However, deploying an edge network does not guarantee continuous service for mobile users. Mobility can cause frequent interruptions and network delays as users leave the initial serving edge. In this paper, we propose a solution to provide transparent service continuity for mobile users in large-scale WiFi networks. The contribution of this work has three parts. First, we propose ARNAB architecture to achieve mobile service continuity. The term ARNAB means rabbit in Arabic, which represents an Architecture for Transparent Service Continuity via Double-tier Migration. The first tier migrates user connectivity, while the second tier migrates user containerized applications. ARNAB provides mobile services just like rabbits hop through the WiFi infrastructure.
    [Show full text]
  • Automotive Data Sharing
    Automotive Data Sharing 16.10.2020 Executive summary Data sharing in the automotive industry Data initiatives from National Road Authorities The usage of data in the global automotive industry has been increasingly important National Road Authorities (NRAs) are looking to utilize vehicle generated data. They the last couple of years. Even though Original Equipment Manufacturers (OEMs) are, under the ITS Delegated Act 2010/40/EU, required to share data through have been collecting data from their connected vehicles for several years, they have National Access Points. Some have chosen to comply only with the regulations, just recently started to investigate opportunities for sharing the data. OEMs have while others have taken a more proactive approach to improve road operations and traditionally been reluctant to this, because of the uncertain value potential of their traffic safety in their country. Later this year (2020), the EU Member States will data. However, during 2019 and 2020, the OEMs have gradually been accelerating provide a new update on their progress with the National Access Points. We have sharing of vehicle generated data with third parties and penning deals with both data seen a number of data initiatives from the NRAs, and some are even starting to pilot aggregators and data marketplaces. These deals are creating new revenue streams Vehicle to Infrastructure (V2I) use cases. Some notable mentions of V2I applications for the OEMs. are: - Ingolstadt in Germany – also known as Audi City – are working with TTS and Safety Related Traffic Information Audi to enable traffic lights to communicate with Audi vehicles. Throughout our interviews, utilizing Safety Related Traffic Information (SRTI) have - Barcelona in Spain are collaborating with SEAT, DGT, Barcelona City Council been a persistent topic.
    [Show full text]
  • Devices, the Weak Link in Achieving an Open Internet
    Smartphones, tablets, voice assistants... DEVICES, THE WEAK LINK IN ACHIEVING AN OPEN INTERNET Report on their limitations and proposals for corrective measures French République February 2018 Devices, the weak link in achieving an open internet Content 1 Introduction ..................................................................................................................................... 5 2 End-user devices’ possible or probable evolution .......................................................................... 7 2.1 Different development models for the main internet access devices .................................... 7 2.1.1 Increasingly mobile internet access in France, and in Europe, controlled by two main players 7 2.1.2 In China, mobile internet access from the onset, with a larger selection of smartphones .................................................................................................................................. 12 2.2 Features that could prove decisive in users’ choice of an internet access device ................ 14 2.2.1 Artificial intelligence, an additional level of intelligence in devices .............................. 14 2.2.2 Voice assistance, a feature designed to simplify commands ........................................ 15 2.2.3 Mobile payment: an indispensable feature for smartphones? ..................................... 15 2.2.4 Virtual reality and augmented reality, mere goodies or future must-haves for devices? 17 2.2.5 Advent of thin client devices: giving the cloud a bigger role?
    [Show full text]
  • ADA+-+Iot+Automotive FINAL.Pdf
    The market for automobiles enhanced with IoT "When Henry Ford made cheap, reliable cars is staggering. A 2013 forecast by GSMA, a global people said, 'Nah, what's wrong with a horse?' association of wireless carriers, found every car That was a huge bet he made, and it worked." will have some type of connection by 2025. The ~ Elon Musk, inventor, entrepreneur and CEO market for technology to connect cars and the of Tesla Motors Internet was an estimated $18 billion in 2012 and is expected to increase three times that number in the next four years. EXECUTIVE SUMMARY “Not only that, but this remarkable technology Since Henry Ford helped automate their can seamlessly sync a wireless smartphone or manufacture, cars have become central to our tablet to a vehicle’s audio and display system lives. This makes the automobile a central hub for communication with pedestrians, other for not only transportation, but as a vehicles and even road infrastructure,” communications center: The ideal ecosystem according to Rajiv Kapur of Broadcom India. for the Internet of Things (IoT). In 2014, the Application Developers Alliance The connected vehicle is truly a microcosm of and its Emerging Technology Working Group IoT. Not only can a networked car, truck or bus began identifying five areas influenced by IoT so include internal sensors that determine such that developers have insight into creating a things as speed, location and temperature of robust IoT ecosystem. This whitepaper serves as the vehicle, but it also may interact with an exploration of IoT by looking at its current surrounding roads, buildings and other vehicles state in automotive; best practices for creating to provide up-to-the-minute information to apps; and new opportunities to explore.
    [Show full text]
  • Hugo Gonzálezgonzález
    This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc-sa/3.0/ HugoHugo GonzálezGonzález @hugo_glez http://atit.upslp.edu.mx/~hugo/ Linux en sistemas de tiempo realLinux en sistemas de tiempo real Hugo Francisco González Robledo [email protected] presenta: Sistema Operativo de Tiempo Real ● Un sistema operativo de tiempo real (SOTR o RTOS ­Real Time Operating System en inglés), ha sido desarrollado para aplicaciones de tiempo real. Se le exige corrección en sus respuestas bajo ciertas restricciones de tiempo. Para garantizar el comportamiento correcto en el tiempo requerido se necesita que el sistema sea predecible (determinista). 1 [1] Fuente: Wikipedia. http://es.wikipedia.org/wiki/Sistemas_operativos_de_tiempo_real ¿Qué es tiempo real ? ● Tiempo real en los sistemas operativos: ● La habilidad del sistema operativo para proveer un determinado nivel de servicio bajo un tiempo de respuesta definido.2 [2] ­ POSIX Standard 1003.1 Catacterísticas ● Usado típicamente para aplicaciones integradas, normalmente tiene las siguientes características: – No utiliza mucha memoria – Cualquier evento en el soporte físico puede hacer que se ejecute una tarea – Multi­arquitectura (puertos de código para otro tipo de CPU) – Muchos tienen tiempos de respuesta predecibles para eventos electrónicos Características deseables 3 ● Multi­threaded y pre­emptible ● Thread priority has to exist because no deadline driven
    [Show full text]
  • DIAPM-RTAI a Hard Real Time Support for LINUX
    DIAPM-RTAI Dipartimento di Ingegneria Aerospaziale, Politecnico di Milano Real Time Application Interface (for Linux) A Hard Real Time support for LINUX This document explains how to call the functions available in DIAPM-RTAI The RTAI distribution (www.aero.polimi.it/projects/rtai/) contains a wealth of examples showing how to use services and APIs described herein. Document written by: E. Bianchi, L. Dozio, P. Mantegazza. Dipartimento di Ingegneria Aerospaziale Politecnico di Milano e-mail: [email protected] e-mail: [email protected] e-mail: [email protected] Appendices contributed also by Pierre Cloutier and Steve Papacharalabous: e-mail: [email protected] e-mail: [email protected] Send comments and fixes to the manual coordinator Giuseppe Renoldi: e-mail: [email protected] Help by Gábor Kiss, Computer and Automation Institute of Hungarian Academy of Sciences, in updating and revising this doc is acknowledged. SUMMARY RTAI_SCHED MODULE .......................................................................................... 7 Task functions ................................................................................................................................ 8 rt_task_init ....................................................... 9 rt_task_init_cpuid ................................................. 9 rt_task_delete .................................................... 11 rt_task_make_periodic ............................................. 12 rt_task_make_periodic_relative_ns ................................
    [Show full text]
  • Real-Time in Embedded Linux Systems
    Linux and real-time Thomas Petazzoni Free Electrons 1 Free Electrons. Kernel, drivers and embedded Linux development, consulting, training and support. http://free-electrons.com Who am I ? Thomas Petazzoni Work for Free Electrons, an embedded Linux consulting and training company Development services (bootloader, kernel, drivers, system integration, boot time optimizations, power management, etc.) Training (documents freely available under CC-BY-SA) http://www.free-electrons.com And also Buildroot developer (embedded Linux build system) MapOSMatic developer (OpenStreetMap city map generator) Co-founder of Toulibre http://thomas.enix.org 2 Free Electrons. Kernel, drivers and embedded Linux development, consulting, training and support. http://free-electrons.com Real Time in Embedded Linux Systems Introduction 3 Free Electrons. Kernel, drivers and embedded Linux development, consulting, training and support. http://free-electrons.com Embedded Linux and real time Due to its advantages, Linux and the open-source softwares are more and more commonly used in embedded applications However, some applications also have real-time constraints They, at the same time, want to Get all the nice advantages of Linux: hardware support, components re-use, low cost, etc. Get their real-time constraints met ? 4 Free Electrons. Kernel, drivers and embedded Linux development, consulting, training and support. http://free-electrons.com Embedded Linux and real time Linux is an operating system part of the large Unix family It was originally designed as a time-sharing system The main goal is to get the best throughput from the available hardware, by making the best possible usage of resources (CPU, memory, I/O) Time determinism is not taken into account On the opposite, real-time constraints imply time determinism, even at the expense of lower global throughput Best throughput and time determinism are contradictory requirements 5 Free Electrons.
    [Show full text]