Figure 8.1 Measurement time of PikeOS Startup phases.
We inserted some code in the Init module of the PikeOS to dump the initialization times of the boot loader, PikeOS partitions and applications in the console display after switching on the hardware platform. The complete bootup time was approximately 2200 milliseconds (2.2 seconds) as shown in the above Figure 8.1.
8.3.1 Analysis of the Boot time results:
As shown in the above Figure 8.1, the startup of the PikeOS system consists of four phases. The first phase depends completely on the hardware platform. The next three phases depend on the hardware as well as the software configuration of the kernel, partitions and applications in the PikeOS system [29]. The time measurements for the initialization times of the boot loader, kernel, PikeOS partitions and applications were presented in Table 8.1.
Initialization Phases Time (milliseconds)
Boot loader ready since power on, T1 60 milliseconds
Initialization of PikeOS kernel since power on, T2
1050 milliseconds
Initialization of user partitions since power on, T3
1900 milliseconds
Startup of application since power on,
T4
Complete bootup time of PikeOS system
AUTOSAR and Linux – Single Chip solution 65
Table 8.1 Time measurements for PikeOS Initialization Phases.
In our proposed design, we have chosen the following design options and optimizations so that there is not much latency or delay while booting up the system.
a) In the resource partitioning mechanism, devices in the hardware platform were carefully considered according to their utilization by user partitions and most of the devices were included statically and given direct exclusive access in the user partitions. Only three I/O devices were dynamically shared between the user partitions and they were included directly in the system partition. Thus, we minimized the functionality of the system partition that acts as a partition manager in PikeOS system. This helped to minimize the latency in the second phase during loading of the PikeOS kernel since it takes less time to initialize the system partition as it has minimal I/O devices assigned to it.
b) PikeOS system carries out the memory mapping and management before the initialization of the user partitions [29]. It was important to ensure a minimal, as well as sufficient memory footprint for the AUTOSAR and Linux partitions. We analyzed the memory requirements of the AUTOSAR and Linux partitions and then allocated minimal and average-case memory space for kernel and RAM user memory regions of the AUTOSAR and Linux partition. As a result, the memory mapping for the partitions will be carried out quickly, that in turn reduced the startup time of the partitions during the third phase.
c) The AUTOSAR partition contains only a simple AUTOSAR application, and we optimized the StartOS functionality of the AUTOSAR application to immediately start up the AUTOSAR application. The Linux partition is a typical OS partition consisting of Linux kernel, root file system and libraries apart from the HMI application. We ported a lightweight Linux partition with minimal set of root file system, kernel modules, etc. so that the Linux partition and applications could be initialized quickly. Thus, we optimized the startup time of the applications during the fourth phase.
The measured boot time of our prototype model using PikeOS is compared other equivalent in-car systems as shown in the Figure 8.2 below.
Startup of application since PikeOS kernel startup = T4 - T2
1150 milliseconds
Startup of Application since initialization of partition = T4 - T3
AUTOSAR and Linux – Single Chip solution 66
Figure 8.2 Boot time for our prototype model, Optimized Linux and AllGO.
As it can be seen, our pilot implementation using PikeOS has better performance compared with the Optimized Linux and AllGO Android systems [45, 46]. Even though we do not have much information about the type of hardware and applications deployed in these systems, we can safely assume that our prototype model is more complicated since it executes two state of the art heterogeneous automotive applications on the same inexpensive, hardware platform.
PikeOS utilizes a thin, microkernel while other systems use a monolithic kernel. Apart from this factor, the fast bootup performance also depends on the hardware, software configuration of the kernel, partitions and applications in the PikeOS system [29]. There are certain other options to increase the bootup performance of our system. In our proposed design, after the PikeOS kernel is started up, the Linux and AUTOSAR partition were started up simultaneously by the kernel. PikeOS provides a mechanism known as modular boot and using this concept; it is possible first to load only part of the PikeOS image and thereby bootup the PikeOS kernel and the real-time AUTOSAR partition earlier [12, 29]. Then the rest of the image can be loaded later, and the Linux partition can be startup. This in turn will provide a faster startup time for the AUTOSAR application and slower startup time for Linux application compared to our approach. The designer can choose either of these approaches, and it purely depends on the fast boot requirements for the applications considered for the multipurpose ECU system. In automotive system, infotainment and automotive applications should be startup immediately after ignition on, and they require more or less equivalent bootup times.