A bit of everything: car, cloud, Raspberry Pi and CAN

The entertainment center (in-vehicle infotainment, IVI) has become an integral part of a modern car. If earlier it was just a radio, then a cassette recorder, then you could listen to music just from a flash drive, and now there are barely enough two 10.25-inch displays for the dashboard and entertainment center in the new Mercedes A-class. By the way, IVI is not only music, but also navigation, Internet access and many other features inside the vehicle, which are slowly giving a start to the implementation of the “Connected Car” concept. Perhaps vehicles are also very close to implementing the concept of the Internet of Things (IoT). And all this is achieved thanks to the "assimilation" of the computer and the car.

In continuation of the previous article “ Automobile, Internet of things and other technologies»I would like to consider ideas for implementing an automobile computer at the level of open projects and slightly touch on current trends in this vein.


Image: Bringing its A game: new 2018 Mercedes A-class hatch revealed - CAR Magazine The

Internet of things is not a ghost of the distant future, but a fully implemented concept of the present. Starting from light bulbs and ending with home voice assistants - all these devices already have Internet access and can communicate with each other. Yes, now for this you need to configure a little, for example, the IFTTT serviceetc., but progress can no longer be stopped. As a result, the computer begins to penetrate the car, as a basic component of the entertainment center. For the automotive industry, there are well-founded restrictions that directly affect the speed of development of IVI - this is the observance of all security measures. In any case, you cannot neglect the safety of both yourself and other road users. Car and road - not a place for experimentation. Therefore, the projects of enthusiasts that I want to consider in this article are just ideas that may develop into future prototypes, but already for commercial offers. Of course, if it comes to security, then trust should be certified products, which are behind the hours of development and testing.

Since we talked about Connected Car and IVI, it becomes apparent that the use of cloud resources with IoT functions is implemented to implement the corresponding software and hardware architecture at the “top level”. For example, most universal cloud platforms, such as Amazon AWS, Microsoft Azure, IBM Watson, etc., contain almost universal services for building the Internet of things. Compared to take off, open solutions in this area will also be interesting. The Kaa project is one such example.


Picture: Kaa Platform Web Interface

Developers position Kaa as a multi-purpose middle-tier platform for IoT solutions aimed at creating applications for connected devices and smart systems. The Kaa platform is an open, multi-functional toolkit for developing embedded systems and solutions for the cloud. The platform is released under the Apache Software License 2.0. To quickly familiarize yourself with the platform, you can download an image for VirtualBox or deploy the system in the AWS cloud.

Kaa’s idea is that developers are provided with an SDK for creating applications using the API of the platform in question, and related services in the cloud, including compilation of low-level programs. The current version supports languages: C, C ++, Java, Objective-C, and Linux, Windows, Android, and iOS operating systems, as well as support for many embedded hardware platforms, for example, Raspberry Pi, Intel Edison.

Here I want to get distracted and notice that, approximately, as once upon a time in the early 2000s, Intel left the microcontroller market with its most interesting solution - the MCS-51, and now, in fact, we are witnessing such - the completion of the development of Galileo systems, Joule and Edison, this did not go unnoticed by the community of developers and enthusiasts. Many ideas from previous systems will be the beginning for new devices and solutions. Of course, if Intel continued to license its architecture for the i8051 (MCS-51) chip, even after it left the microcontroller market, now, perhaps, the positions of Raspberry Pi and Arduino (on the classic Atmel microcontroller platform) as the main tools will be significantly strengthened. prototyping embedded devices. But do not forget


Returning to the Kaa project, it should be noted that there are a number of architectural features that make the development of IoT on this platform extremely quick and easy. Decisions on Kaa should not depend on a specific hardware platform and, thus, the project is compatible with almost any connected devices, sensors and gateways. Of course, this is achieved through the use of universal communication protocols and standardized interfaces between system components. Kaa also provides a clear structure of IoT features and extensions for various types of applications. They can be used, almost by analogy to the plug-and-play technology, with minimal code, which the developer should nevertheless finalize for his systems and devices. These features, combined with analytics in the cloud,

The Kaa project is successfully developing and improving, but there is another, we can say, the inverse problem for building Connected Car solutions. Its essence lies in fulfilling the tasks of testing the software part of the cloud system and directly emulating the behavior of many cars connected to the cloud. For this task, open source projects are interesting, for example, Automatski AutoSIM, which is developed with the support of two licenses: GPLv3 and commercial. This system uses the basic data transfer protocols, including MQTT, AMQP, CoAP, etc. The user uses the Rest / Json API to control the operation of the server to simulate the required processes. AutoSIM theoretically allows you to simulate the flow of data from more than 100 million devices.

Kaa and AutoSIM are great examples of open systems and, possibly, solutions that will become very popular for the automotive industry. But now, at the lower level of embedded systems for the car, there are many interesting open solutions that successfully interact with cloud services. For example, Google’s Android Auto platform . This solution is based on Android Automotive and is aimed at combining a smartphone and an automotive media center into a single platform that extends the functionality of IVI systems.


Since in a modern car there are many blocks that directly interact with the media center, for example, using the Controller Area Network (CAN), Local Interconnect Network (LIN), Media Oriented Systems Transport (MOST) networks, as well as the more familiar Ethernet and protocols TCP / IP, Android Automotive offers some abstraction - the hardware abstraction layer (HAL) between the physical networks of the car and the functionality of the Android operating system available to developers.


Figure: Vehicle HAL and Android automotive architecture

But, if Android is a completely predictable solution from Google, then the use of Linux as a platform for the car entertainment center, perhaps, has already become a classic of the genre. And as they say, someone definitely should have proposed a project, for example, Automotive Grade Linux . It is an open-source development that brings together automakers, suppliers and technology companies under the auspices of The Linux Foundation . Of course, AGL is available as source code, and for an initial acquaintance, you can download an image of a virtual machine, for example, to run it in VirtualBox or it is quite possible to run a distribution system on Raspberry Pi . To use the AGL SDK, you need a Docker.


Picture: Automotive Grade Linux - Getting Started

Application development for AGL is provided in HTML5, Qt OpenGL. Automotive Linux platform itself is focused on security. For example, the solution architecture involves a hypervisor and, of course, isolation of mission-critical applications, multimedia systems, and entertainment. AGL applications and components are built on a modular basis with interfaces in the form of signals / events, which allows you to hide the complex software implementation of low-level solutions, for example, the implementation of the CAN bus interface, and provide a simple API for applications.


Figure: Upgraded Security Blueprint 2017. AGL security overview - Automotive Grade Linux Documentation

It is interesting that the developers of Automotive Grade Linux are eyeing architecture-level implementations from other projects, however, which is typical for the entire movement of open systems. For example, an interesting solution in the OpenXC project is the principle of describing in JSON format all CAN signals that need to be processed. A software generator converts such a description into a C ++ file that can be compiled, etc.


Figure: OpenXC is an open source, data-focused API for your car

If we talk about the OpenXC project, then it uses a combination of hardware and software with open source code, which allows you to expand the functionality of the car using special applications and plug-ins. The project is focused on obtaining data about the car and uses the standard interface of the diagnostic connector OBD-II. In fact, the project allows you to develop your mobile application for Android, iOS or use it for Python development, and the Ford brand is chosen as the main automotive platform.

Returning to the Automotive Grade Linux project, it is worth noting that the Raspberry Pi is used for demonstration and prototyping purposes, but specialized solutions were chosen for the industrial platform, for example, systems based on ARM SoCs (system on a chip) from Renesas Electronics R-Car series Generation 3 and some others.


Figure: R-Car H3. System Block Diagram - Renesas Electronics

Since we can continue to consider various platforms for building IVI systems, I would like to draw a small conclusion about the examples already given. Everything suggests that the current year 2018 will be the year of delivering applications to the user and developer. Indeed, both in the Kaa cloud project and in the solutions for the AGL operating system, the principle of providing an almost ready-made application in the form of an SDK for the developer is used. Also widely used is the approach based on the description of the criteria of the developed system, for example, in the JSON format, and the generation of the application framework based on them. This is somewhat reminiscent of the ideas disclosed earlier in the publication: “ Rapid prototyping of IoT devices”, Where solutions were considered in which chip designers provide starter kits, etc. for quick reference to their components. Indeed, for a programmer developing a project for IoT, it will always be convenient to start development not with a detailed acquaintance with a “certain” API, but with a ready-made application framework.

Let's pay attention to a slightly different level of IVI, where multifunctional systems such as Renesas or others are not used. It is interesting to consider approaches based on the already traditional Raspberry Pi solution. It is clear that all these are rather prototypes, because The Raspberry Pi can hardly be compared to an industrial board specially designed for automotive applications, but the ideas and approaches of enthusiasts are always interesting. So, one of the curious solutions for the media center is the CarPC project, which is actually the development and improvement of the graphical interface and additional functionality for the famous Kodi cross-platform media player (previously the XBMC project).


Picture: CarPC-touch for Kodi

But Kodi or another media center will not allow you to receive and display data from the vehicle’s on-board network. For this, the easiest way is to connect to the diagnostic connector of the car, as was discussed in our previous publication: “ Diagnostic connector OBD-II, as an interface for IoT ”. And here the Carberry project is interesting, which is an expansion board for the Raspberry Pi.


Picture: Carberry for RPi 3 - Paser

The Carberry payment of the Italian company Paser costs 123.83 € (euro). It connects to the standard expansion port of the Raspberry Pi 3 and supports: CANBUS, GMLAN, infrared receiver and other functionality. The expansion board is an excellent complement to software solutions, such as the already mentioned CarPC. It should be noted that the hardware and software project is constantly evolving towards the expansion of functionality, etc.


Picture: What is AutoPi and What Does It Do? - AutoPi.io The

German startup AutoPi is also actively developing ., which is a project of an automotive IoT platform. Interesting in AutoPi is the hardware based on the Raspberry Pi Zero and the presence of the OBD-II interface, as well as: 3G / 4G, Bluetooth, WiFi, GPS-receiver and other components that fit in a fairly small device.

Against the background of all the systems reviewed, the question directly arises: how to connect the OBD-II interface to the Raspberry Pi? The obvious answer is to use a ready-made board, for example, the PiCAN2 CAN-Bus Board for Raspberry Pi 2/3 at a price of £ 26.90 (in pounds without European VAT) or something similar. But it is very tempting to use the widespread CAN Bus module based on the MCP2515 / TJA1050, which is available on AliExpress from USD $ 1.36 and a little more expensive. For example, such a module is much cheaper than expansion cards based on the MCP2515 for Arduino.

It is worth noting that the low price of the MCP2515 / TJA1050 module is due to its modest size and the number of elements on the board. It is great for working with Arduino boards, but in this case, when programming, you should not forget that mainly on the MCP2515 / TJA1050 module, developers install an 8 MHz quartz crystal rather than 16 MHz, which is usually present on most Arduino CAN-BUS Shield boards . Thus, the use of the MCP2515 / TJA1050 module for connecting to the Raspberry Pi and working with the CAN bus, for example, with the OBD-II emulator, discussed all in the same article “ OBD-II Diagnostic Connector as an Interface for IoT ”, suggests itself . or directly with the ELM327 module, etc.


Picture: CAN Bus module based on MCP2515 / TJA1050

But when working with electronic modules, you always need to be careful about the supply voltage and restrictions on data lines. Using the standard GPIO expansion interface of the Raspberry Pi, this is quite relevant. The fact is that there are 5V and 3.3V voltages on the Raspberry Pi connector, which can power external circuits, however, the board's I / O lines work only with levels up to 3.3V. Accordingly, the MCP2515 / TJA1050 module board, designed for 5V only, should not be immediately connected to the Raspberry Pi.


Schematic: CAN bus on raspberry pi with MCP2515 - Raspberry Pi Foundation Forum

The solution may be a simple two-way level converter 3.3V / 5.5V. There are plenty of such ready-made modules for the SPI bus, but the MCP2515 has an additional interrupt pin, indicating data readiness. This conclusion will allow the Raspberry Pi processor to do its job and respond to data from the MCP2515 only at the required times, without being constantly distracted by monitoring the SPI interface. Therefore, the finished interface module will not have additional contact and you just need to make your own circuit.


Picture: Minor refinement of the CAN Bus module based on the MCP2515 / TJA1050 to work with the Raspberry Pi

There is a completely simple solution, but of course, not the best. It is based on the fact that the MCP2515 chip is fully functional with voltage levels from 2.7V to 5.5V, which means it can be powered 3.3V with a Raspberry Pi, and the SPI interface lines and INT interrupts can be connected to the GPIO. The TJA1050 will need 5V power, which can be connected all from the same GPIO connector, but on the MCP2515 / TJA1050 module, you will need to carefully cut the general power track and solder to it.

As a proper improvement of such a circuit, it is very reasonable to use a voltage divider to match the 5V levels of the TJA1050 transceiver, by the way, you can use the analog MCP2551 from Microchip or others, and the MCP2515 CAN controller with 3.3V power (see. Fig.). Also interesting is the CAN Simulator project.based on the Raspberry Pi and, of course, the MCP2515. The simulator uses the TJA1049 chip, which although it requires 5V power, it works without additional components for matching levels with 3-volt systems. If you choose the most interesting solution, then perhaps the CAN-Bus Interface with galvanic isolation project is the most interesting, as it offers the use of the MCP2562 transceiver , which allows you to connect a controller with voltages in the range from 1.8V to 5V without additional elements.


Schematic: CAN + Raspberry Pi

Having decided on the hardware, you can proceed to work with the Raspberry Pi at the software level. As the operating system, we will choose a rather traditional Raspbian Stretch solution. And for working with CAN, support for the Linux kernel level MCP2515 driver.


Picture: Transferring data between the Raspberry Pi and Arduino via the CAN bus

For the Raspberry Pi to work correctly with the CAN interface card based on the MCP2515, you need to know the kernel version of the installed operating system. To do this, run the command:
$ uname -a

In our case, this is Linux raspberrypi 4.9.59+. You can find out more detailed information about the distribution and the board itself using the commands:
$ cat /etc/debian_version- version of the basic Debian distribution;
$ cat /etc/os-release- release features;
$ cat /proc/cpuinfo- version of the hardware platform (details can be found in the article: “How to Check the Software and Hardware Version of a Raspberry Pi ").

For SPI to work with the MCP2515 chip, you need to add parameters to the configuration file /boot/config.txt of the operating system: It is clear that if quartz is on a 16 MHz board, then you need to specify the number "16000000". The bcm2835 driver will need to be explicitly specified in the config only for old Linux kernels up to kernel 4.4.x + The next parameter should be uncommented for modern systems: Well, after a long search, we found the actual line that allowed the desired module to work on the Linux kernel raspberrypi 4.9.59+ in current system: After rebooting, you can simply “raise” the network interface:
# Uncomment some or all of these to enable the optional hardware interfaces
dtparam=spi=on
dtoverlay=mcp2515-can0, oscillator=8000000, interrupt=25


# dtoverlay=spi-bcm2835-overlay



# dtoverlay=spi1-1cs


dtoverlay=spi0-hw-cs


$ sudo ip link set can0 up type can bitrate 500000

Indeed, it turns out very convenient that CAN becomes a kind of network interface in the Raspberry Pi and, for example, send or receive a dump of received data, as well as find out the operation statistics: In order not to “raise” the interface each time the system starts, you can add a couple of standard lines to the configuration file / etc / network / interfaces , etc. Screenshot: Data transfer between the Raspberry Pi and the OBD-II emulator based on the Arduino board. Then it remains to write new code or use ready-made libraries. Since the MCP2515 driver actually gives the system a new network interface, development can be done in almost any language. And immediately I want to say a little about Go
$ cansend can0 127#DEADBEEF
$ candump can0
$ ip -details -statistics link show can0




, a cross-platform, compiled, multi-threaded programming language developed by Google. This language is definitely very interesting in terms of developing embedded systems and, of course, it will not be difficult at all to find a ready-made library for it suitable for a project, for example, CAN bus in Go . And if you go further, then you should consider the Gobot project - a framework aimed at creating robots, solutions for IoT, etc. But perhaps this will be too much for this publication.

You should definitely return to programming issues on Go, but already in the following publications. It will also be necessary not to forget about the Tizen operating system, on which Automotive Grade Linux was previously based, and also to consider the trend of this year - voice assistants in the car interior and much more. And at the end of the auto topic of the current publication, we just recall the digital cab platform presented Samsung and HARMAN at CES 2018 and will be a little inspired by the ideas of designers and engineers who developed this concept.



Interesting resources and links:
- Mercedes-Benz's new MBUX in-car assistant and smart UI rocks - TechCrunch
- Interface from Mercedes-Benz announced as a friend of the driver - Drive
- Getting started. Kaa Sandbox - KaaIoT Technologies
- Intel discontinues Galileo, Joule and Edison - Computer Review
- OK Google, what is Android Auto? Here's everything you need to know about it - Digital Trends
- Android Auto system has become available in any car - 3DNews
- Android on wheels: Google will “implant” Audi and Volvo cars - News
- Toyota Camry will be the first car equipped with Automotive Grade platform Linux - OpenNET
- Raspberry PI 2 CarPC - Engineering (DIY)
- Arduino CAN Bus Module Pin Outs and Schematics - Henry's Bench
- MCP2515: CAN bus controller with SPI - microsin.net - ham radio notes
- Matching 5V and 3.3V logic levels of devices - EasyElectronics community .ru
- Hacking CAN bus for voice control - Geektimes
- Pin Numbering - Raspberry Pi Model B (Revision 2.0) - The Pi4J Project
- CAN-Bus with Raspberry Pi: HowTo / Quickstart MCP2515 Kernel 4.4.x + - vimtut0r's blog
- CAN On the Raspberry Pi - Harrison's Sandbox
- MyPi CAN-BUS Card Configuration - Embedded Micro Technology
-CAN BUS Shield for Raspberry CanBerryDual V2.1 - Industrialberry
- Libre Solar CAN interface for Raspberry Pi (Zero W) - GitHub
- OBD-Pi - Instructables
- SocketCAN userspace utilities and tools - GitHub
- CAN Bus - Embedded Linux Wiki
- Go on Raspberry Pi - @NET
- Need to Create Synergy Korean Connected Car Developers Alleged to Need More Collaboration - Korea's Premier Business Portal
- CES 2018: who is the main exhibit? - Geektimes