The Device Chronicle interviews Stephan Kaufmann, CEO, Ridelink GMBH, on how IoT, and an embedded solution based on Beaglebone and Yocto for the Canbus is helping get great apps on automobiles starting with motorcycles.
Ridelink is an aftermarket solution for motorcycles on an OTP platform for the Canbus. It is retrofitted so the riders put it on their motorcycles. The application is free but the user needs to purchase the hardware. 2,500 hardware units and 5,000 apps have been downloaded. There is an emergency e-call as soon as the hardware detects an accident with the motorcycle. There is a theft alerting system as soon as the motorcycle is shook.There is a live tracking to track a tour so others could follow. There is also a route planning and navigation system. These are the 4 use cases, and a can bus communication to show the performance of the motorcycle through analytics. In the end, this is a full IoT platform.
Ridelink uses a Beaglebone and Linux-based custom hardware which is quite complex used for simple tasks such as tracking, and also more complex tasks such as vehicle communication with the Canbus and telematics control unit. We can read and repair cars, motorcycles and trucks. The hardware is based on Yocto 2.5, started by developing the hardware in house but then needed help from outside to look at the antenna technology and design, and needed help getting 4 communication channels supported in a small device – wifi, LTE, bluetooth and Canbus. Three of them are wireless so complex to get them all running on a small device enclosed in a small shell. They managed after 12 months to get a working platform up and running.
The goal is to have an open telematic platform, something like an app store for mobility solutions. This would be a “translator” for the transport industry. Stephan describes Ridelink’s platform and technology as a “Esperanto for cars”. There are so many different car and motorcycle manufacturers and they all seem to speak different languages. Ridelink offers a basic language for use with the Canbus, this is real time. It is not as robust a protocol as TCP/IP so if you lose a package during transit with Canbus, you will be kicked out, and doesn’t support latency as TCP/IP does. There is a clash of cultures of development too. On the one hand you have embedded system developers who are accustomed to low memory, low CPU and real time on the devices, and then the app developers who are accustomed to SDKs, robust protocols and interfaces which are human readable. Ridelink with its hardware translates between these two worlds. They have a canbus interface and a JSON web service and translate between the two. The first use case is with motorcycles to show how this would work.
There are three different levels of OTA software updates. First, the Ridelink software is completely configurable, JSON formats are exchanged on the hardware. Every communication pattern is written in these JSON files and the Ridelink hardware parses these JSON files, and then understands how to communicate with the different vehicles. There are also configuration files that define how each of the Ridelink apps work – so an emergency call works differently than a maintenance application. A maintenance app needs a constant stream of data whereas. It is a way to define how the hardware should react, it is all defined in the configuration files and there is an update process for pr. Second, OTP Core (open telematics core) is how Ridelink updates its own software. Updates can be performed via LTE or via Wi-Fi, in a routine it checks for a new software update. If it is correct after a checksum is performed, it downloads it and updates. It restarts and runs the new software. The third level is the firmware update with the Yocto image and Mender performs the update.
Stephan believes that in the automotive, motorcycle and truck industry, there is a tendency towards “too much thinking in silos where every industry player is baking their own solution and tries to convince the customer to build that solution. Being always closed and not open is a serious challenge for the industry especially in Germany. Openness and versatility is needed to be applied to IoT software and hardware development.” Stephan concludes by saying that the strategic value of getting the hardware installed by the users is often overlooked by analysts. “Hardware is the lock in, if you user installs it then it is not easy to switch out. Hardware is a strong accelerator for software use cases and if the hardware is connected many use cases will flow from this point. Most investors underestimate the hardware but then why do Apple, Google and Nvidia do it? If all you are offering is software then you are much more exchangeable (in the context of the auto, motorcycle and truck sector).