Architecture

From iaiaGi Wiki
Jump to: navigation, search

This document describes the D-ECU (Development - Electronic Control Unit) architecture and explains the reason for the specific technical choices.

Introduction

The iaiaGi Project is aimed to generate a universal development platform for the conversion of combustion engine vehicles into electric vehicles. Just from the platform's first development steps, it came into evidence that the integration of the standard vehicle electronics with the electric powertrain electronics was a critical point of the entire project. Thus, since the beginning of the project, we started to develop a mobile workbench used to deploy and test new ideas and new electronic integration functionalities.

Following our makers approach, the development workbench has been developed adding the best prototyping hardware in the market to common automotive devices. To that integrated staff, we added an open-source software compound to avoid patents and royalty payments and to maximize project’s spread. The result of this design process is the D-ECU (Development – Electronic Control Unit), a control unit that is versatile and scalable and that carries enough power to support future developments of the platform.

This document describes the D-ECU architecture and it details its integrated hardware devices.


Requirements

We summarize here some of the estimations that guided us to the actual D-ECU implementation.

What we developed to support the iaiaGi Project was a device capable of addressing the following requirements:

  • High computation power: the integration with pre-existent vehicle electronics requires that many functions are implemented inside the bridge device to the added electric powertrain. Those complex functions require a high computation power and cannot be managed exclusively by dedicated microcontrollers. Also, the same device should talk to and integrate the converted vehicle’s infotainment system and this for sure requires even more computation power.
  • Scalability: currently the iaiaGi Project covers subcompact or supermini or small cars (“Segmento B” in Italy), but in the future due to its universality we would like covering also other vehicle segments. In case during the project development, we should face electronic control units performance issues, scalability can address the increased power request.
  • Expandability: it is obvious that in the future many functionalities will be added to the system, thus we need to guarantee that the control unit can easily integrate new technologies. An Information Technology based platform is the best choice here.
  • Availability: all the hardware and software used to develop the control unit must be easily accessible and should be as much cheap as possible.
  • IoT integration: the project aims to align the converted vehicle with the state of the art of all automotive functionalities even when the car comes originally without those features. IoT is the must have function to introduce the vehicle into the future. Also, IoT will enable some interesting features like the remote vehicle management and support, data collection for debugging and troubleshooting activities, remote software updates, and more.
  • Affordability: the automotive world is extremely demanding when affordability is involved. The control unit should integrate hardware that can implement and satisfy all the demanding certifications of the automotive area. That should also improve the user experience and increase his satisfaction.
  • Flexibility: the development control unit hardware and software platform should be designed to accept a large number of project changes without affecting design and development time or resources. It should easily support changes when they are required.
  • Geo-localization: due to the many functionalities the control unit will implement, geo-localization is a must. The control unit should support geo-localization functionalities without the need to re-design all the platform when a change comes to the system.
  • Standardization: all the design of the control unit should be oriented to standardize the platform in order to make it available with a known behavior to the open-source / open-hardware community.
  • Usability: all the control unit design choices should be oriented to the whole device usability, that means in terms of development processes and applications, and in terms of user friendly interaction to control the vehicle.
  • Documentation and support: documentation of the many control unit components should be oriented to satisfy the open-source / open-hardware community needs. This has to start from a well-known and well documented set of components that possibly come from the same thought.
  • Acknowledgment: the control unit should be a compound of open-source / open-hardware acknowledged technologies, this mainly to facilitate contribution to and diffusion of the project development platform.
  • Security: the resulting development control unit should be arranged in adavance to manage and support security in its environmental and istitutional features. Due to all the IoT functions it will implement and the sensible data managed by this device, user and vehicle information should be kept secure from external attacks. A good security design is a basic requirement. It is essential that security topics are involved into the design of the control unit since the beginning of its project.


Resources

To write this document we referred to the following Internet shared resources:

  • Raspberry Pi – Raspberry Pi Hardware Guide requirements | Raspberry Pi Learning Resources [1].
  • Setting up Raspberry Pi as an access point in a standalone network – Raspberry Pi Documentation [2].
  • Kernel building – Raspberry Pi Documentation [3].
  • Configuring the kernel – Raspberry Pi Documentation [4].
  • Raspberry Pi Kernel Compilation – eLinux.org [5].
  • Raspberry Pi Raspbian and Raspberry Pi Desktop Linux distributions download page [6].
  • Change default users on Raspberry Pi – Gordon Lesti [7].
  • How to fix missing dirmngr - SLEEPLESSBESTIE’S NOTES [8].
  • GitHub – resin.io/etcher: Flash OS images to SD cards & USB drives, safely and easily [9].
  • How to backup your Raspberry Pi SD card, or copy it to another (larger?) Raspberry Pi SD card – Tech Sparx [10].
  • microSDTM Card EXCERIATM – M302EC – TOSHIBA Memory [11].
  • Carberry.it – Carberry – CANBUS, GMLAN, LIN BUS Raspberry Pi shield [12].
  • Carberry.it - Accessories - Box - Carberry 3 (Raspberry Pi 2/3) [13].
  • Carberry.it - Accessories - Carberry Free Wires Harness [14].
  • Carberry.it - Accessories - OBD2 Extender [15].
  • start [Carberry Wiki] [16].
  • PCAN-USB: PEAK-System [17].
  • PCAN-Cable OBD-2: PEAK-System [18].
  • PEAK-System LINUX Website [19].
  • Adafruit Ultimate GPS Breakout - 66 channel w/10 Hz updates - Version 3 [20].
  • GPS Antenna - External Active Antenna - 3-5V 28dB 5 Meter SMA [21].
  • SMA to uFL/u.FL/IPX/IPEX RF Adapter Cable [22].
  • USB to TTL Serial Cable - Debug / Console Cable for Raspberry Pi [23].
  • Adafruit Ultimate GPS on the Raspberry Pi [24].
  • E3372 | Dongles | HUAWEI Global [25].
  • Eightwood TS-9 connector 3,5dBi TS9 for 2G 3G 4G LTE GSM Wlan Bluetooth HSDPA UMTS DCS Wifi wireless networks with 3m 9,8ft connection cable [26].
  • OpenGarages [27].
  • Car Hacker's Handbook [28].
  • Official SocketCAN Linux Kernel Documentation [29].
  • Bosch Automotive Handbook - 9th Edition - Bentley Publishers - Repair Manuals and Automotive Books [30].
  • Build Your Own Electric Vehicle, Third Edition: Seth Leitman, Bob Brant [31].
  • OpenXC [32].
  • chipKIT-based OpenXC Vehicle Interface [33].
  • VI Firmware – OpenXC [34].
  • Advanced Firmware Development - OpenXC [35].
  • OpenXC Vehicle Interface Firmware - OpenXC Vehicle Interface Firmware 7.2.1-dev documentation [36].
  • Getting Started with Python – OpenXC [37].
  • OpenXC for Python — OpenXC for Python 0.13.0 documentation [38].



<This document is under construction>