Diagnostics over Internet Protocol, commonly referred to as DoIP has opened avenues for remote vehicle diagnostics, ECU re-programming and more.
On the ground, it translates into safer vehicles on road, less hassle for customers who have to drive down to the service center for every issue, and better customer experience provided by the OEMs.
Traditionally, DoIP is integrated into the Vehicle ECU (Server) and external tester device (Client). Both server and client are based on Embedded systems where DoIP is integrated into the Transport Layer.
In the recent past, technology vendors have been exploring the idea of integrating DoIP on Linux platform instead of Embedded systems. This is obviously not possible inside the vehicle system as it is largely dominated by embedded systems. However, the external testing device where DoIP is integrated as the client, can be based on a Linux platform.
Integration of DoIP directly to a Linux platform where other applications also reside, can make for an interesting use-case. But there are several challenges too!
So, what are the challenges involved? Despite the challenges, is it still worth migrating to Linux platform? How do we mitigate these challenges? We will try to answer these questions in our blog.
But first let’s understand the basic architecture of the Linux platform.
Understanding the Linux Architecture for DoIP Integration
In a Linux environment, there are two realms where the different modules reside- User Space and Kernel Space. If you compare this with an embedded system, there are some visible differences.
In contrast to the Linux environment, which is divided into two layers, an embedded system will at least have 3 layers- Application Layer, Base Software Module and the Low-Level Drivers. In addition to these modules, there is a scheduler/RTOS that manages the scheduling of tasks performed by the applications.
Now let’s understand the User Space and Kernel Space of a Linux Platform:
- User Space: This is the set of locations where the user processes run. The User Space will have the applications, the DoIP and other automotive stacks and the sockets required for stacks to communicate with the physical medium. As a matter of fact, the applications residing in the User Space have limited access to the memory. It is the Kernel that manages the applications running in the User Space.
- Kernel Space: Kernel is the core of the Linux platform. It has access to all of the memory. In addition to providing the APIs to the applications in the User Space, it has a very important role to play in the context of scheduling the applications. It is the Kernel that decides which application will be given priority for execution and the ones that will be queued.
As already mentioned, DoIP and other stacks are part of the User Space. Why are stacks kept in the User Space and not in the Kernel Space, you may ask? Theoretically, it is feasible. However, one of the many reasons that it should be avoided is that any instance of a run-time error can destabilize the kernel and result in system crash.
While we are talking about integration of DoIP with Linux, an obvious question comes to mind- Why integrate DoIP with Linux when we already have a time-tested architecture based on Embedded system/RTOS. Let’s try to answer that!
Why Integrate DoIP with Linux?
In a classic off-board diagnostics scenario, a Tester device connects to the vehicle ECU and retrieves the Diagnostic Trouble Codes (DTC). Based on the DTCs, the service center professionals understand the issue and rectify it. When DoIP is involved, this diagnostic can also be remotely performed over Internet Protocols.
The tester device is limited to its role of retrieving the DTCs from the vehicle ECU. If you wish to perform other tasks related to the vehicle ECU, you would always require a gateway device that can connect to the ECU peripherals.
Having a LINUX based tester device with DoIP integrated into it, allows you to keep different applications within the tester device. Such a setup enhances the role of a tester device, allows it to re-program ECUs remotely, retrieves data other than the diagnostic details and opens avenues for many such use-cases. Obviously, the security aspect also has to be taken care of, but that will be the subject of another blog later on.
Embedded system and Linux platform are completely different in the way the applications and the underlying hardware interact. The scheduling part that takes care of how execution time is allocated to each application, is also quite distinct.
In the next section, we will look at the scheduling challenges that come to the fore when integrating DoIP over Linux.
Scheduling Challenges Involved in DoIP Integration with Linux Platform
When it comes to scheduling, the Kernel Space has complete control. As it is not a real-time scheduler, we cannot expect it to fulfill the timing constraints of a DoIP stack, which is usually 1 milli second ticks. In this 1 milli second stipulation, every task has to be called, failing which the entire operation would be stalled.
In a Linux environment, where the Kernel scheduler controls the scheduling of every application, the timing constraints of DoIP stack cannot be fulfilled. However, there are certain modifications that we can bring about in both the Kernel and the User Space to make them fulfill the timing constraints.
Option 1- Converting the Linux Kernel into a Non-Preemptive Real Time Scheduler:
A non-preemptive real time scheduler is one which does not interrupt a process till it is finished or the stipulated time has expired. Once the CPU allocates the resource to a process, the process can hold the resource till it terminates.
An RT patch is added to the Kernel Space to enable a non-preemptive real time scheduling mechanism in the Kernel Space. Although it looks simple, this is not a preferred choice among the automotive engineers as it has some downsides too. A non-preemptive scheduler is a rigid one, and automotive applications may require certain amount of flexibility at times.
Option 2- Using a High Resolution Timer and Scheduler:
This is a much cleaner process as we do not modify the Kernel Scheduler. Instead, we get our own Scheduler in the User Space and control it with a High Resolution Timer (HR Timer), which will be a part of the Kernel Space.
The HR timer is tuned for 1 milli second ticks which is transmitted to the scheduler (in the User Space) with the help of Sys FS (Pseudo File System) and SIGRT (Real Time Signal).
A scheduler especially fine-tuned for a Linux platform is required for the process. Any scheduler can be used with minimum modification. As seen in the diagram, SIGRT has a dedicated connection with the Scheduler through IOCTL protocol. It does not affect any other module of the User Space and is only meant to meet the timing constraints.
Additional Activities Involved in Integration of DoIP on Linux
DoIP uses TCP/UDP IP for communication; hence these protocols are integrated within the Linux Kernel Space. They interface with the Network physical layer in order to send the data packets.
Additionally, we need to integrate the socket that would interface between the DoIP stack and the TCP/IP and UDP stack in the Kernel Space. The role of the socket communication module is to process the data provided by DoIP stack before transmitting it over the TCP/IP protocol.
Conclusion
Diagnostics over IP has already solved several problems related to remote diagnosis of the vehicle ECU. When combined with a Linux Platform, its range of application will only widen. Hopefully, in the future, we might witness a whole lot of new use-cases for this set up. Watch this space!
