Abstract : To provide an open, independent, and practical automotive electronics software development platform, this paper introduces the OSEK/VDX specification, which is increasingly dominating the international automotive industry. It focuses on analyzing the definition of the operating system kernel and, based on the free embedded real-time operating system μC/OS-II, analyzes the differences in technical characteristics between the two. By modifying some functions of the μC/OS-II kernel to conform to the OSEK/VDX specification, a design concept for an automotive real-time operating system is proposed. Keywords : OSEK/VDX; μC/OS-II; embedded real-time operating system; kernel Introduction With the rapid development of the automotive industry, the application of electronic technology in automobiles is constantly increasing. To meet the development needs of increasingly complex automotive electronic control software and achieve the portability of application software and compatibility between control modules from different manufacturers, the German automotive industry jointly launched the "Open System and the Corresponding Interfaces for Automotive Electronics" specification in 1993. In 1994, the similar VDX ​​(vehicle distributed executive) and OSEK specifications from the French automotive industry were merged to form the OSEK/VDX specification system. This specification mainly consists of four parts: Operating System Specification (OSEKOS), Communication Specification (OSEKCOM), Network Management Specification (OSEKNM), and OSEK Implementation Language (OSEKOIL). OSEKOS is a small RTOS specification specifically designed for automotive applications, emphasizing the following aspects: ① Portability: all APIs are standardized and have clearly defined functions; ② Scalability: OSEKOS aims to be universally applicable to any type of ECU, therefore, the system must be highly modular and flexible in configuration; ③ Specific requirements of automotive applications, such as reliability, usability, and cost sensitivity. Correspondingly, OSEKOS static configuration can be implemented using the OS2EKOIL language, allowing users to statically specify the number of tasks, required resources, and system services during system generation. OSEKCOM provides standard interfaces and protocols for data exchange in communication networks. OSEKNM provides a standard set of functions for monitoring network traffic to ensure network security and reliability. μC/OS-II is a well-known open-source real-time kernel designed specifically for embedded applications. Its main performance characteristics are as follows: ① Open source code. This makes it easy to port the operating system to various hardware platforms; ② Portability. Most of the μC/OS-II source code is written in C, while the parts related to microprocessor hardware are written in assembly language, making μC/OS-II easy to port to other microprocessors; ③ Embeddable. As long as the developer has the embedding method, μC/OS-II can be embedded into the developer's system; ④ Scalable. Developers can selectively use the system services required by the application in μC/OS-II, reducing the storage space required by μC/OS-II; ⑤ Preemptive. μC/OS-II is a completely preemptive real-time kernel; ⑥ Multi-Tasking. μC/OS-II can manage 64 tasks, but currently applications have a maximum of 56 tasks; ⑦ Affirmable. The execution time of μC/OS-Ⅱ system services does not depend on the number of application tasks; ⑧ Practicality and reliability. Many industries have successfully applied this real-time kernel, and these applications are the best evidence of the kernel's practicality and reliability. OSEKOS Structural Features and Operating Mechanism OSEKOS Structural Features (1) High real-time performance. In the field of automotive control, even the slightest error can lead to serious consequences that endanger life safety, so a high degree of real-time performance is required. All system objects in OSEKOS are statically created by the user during the creation process, avoiding the time consumption of dynamic creation and enhancing its real-time performance. Moreover, the preemptive scheduling strategy and alarm mechanism can also meet the real-time requirements; (2) Standardized application interface. It has formulated a standard application programming interface, which can shield the different underlying hardware structures and provide a consistent development environment. Furthermore, users only need to modify the hardware-related parts in the OIL configuration file, which can be easily ported to different ECUs; (3) Customizability. It has highly modular and flexibly configurable characteristics. It can be customized using the OIL language and can run in an environment with very few hardware resources. OSEK OS Operating Mechanism Analysis The OSEK specification divides tasks into basic tasks and extended tasks. Basic tasks have three states: running, ready, and suspended. Extended tasks have an additional waiting state. Furthermore, basic tasks only have synchronization points at the beginning and end, so they require fewer resources, while extended tasks can correspond to different times and may have multiple synchronization points during operation, thus requiring a more robust environment. Synchronization between tasks in the operating system is achieved through a scheduler. The OSEK specification supports three scheduling methods: ① Fully preemptive scheduling. This strategy incurs significant memory overhead for saving the current state. Theoretically, tasks can be rescheduled at any point, therefore tasks must synchronously access shared resources, increasing system complexity; ② Non-preemptive scheduling. This strategy achieves task switching by calling certain service routines, i.e., the user sets the rescheduling point. By defining task groups, multiple tasks can simultaneously exhibit preemptive or non-preemptive scheduling characteristics; ③ Hybrid preemptive scheduling. When preemptive and non-preemptive tasks coexist in a system, a "hybrid preemptive" scheduling strategy is used. In this context, the scheduling strategy relies on the preemptive nature of running tasks. Developers define the task execution order by configuring task priorities and preemption attributes. For more flexible configuration of operating system scheduling, the OSEK specification defines four consistency classes: BCC1, BCC2, ECC1, and ECC2. These are based on the number of tasks that may exist at each priority level and whether basic or extended tasks are required. If there is only one task at each priority level, and it is a basic task, the consistency class is defined as BCC1; if it is an extended task, it is defined as BCC2. If there can be multiple tasks at each priority level, and they are basic tasks, the consistency class is defined as ECC1; if they are extended tasks, it is defined as ECC2. The OSEK specification defines two types of interrupt service routines: ① ISR1. These interrupt routines do not use operating system resources. After the interrupt ends, the handler continues execution from where the interrupt originated. They have no impact on task management and do not require calls to operating system APIs. ② ISR2. These interrupt routines are generated by the system and configured through user subroutines. They can call operating system APIs. Interrupts have higher priority than tasks, therefore they can preempt any task. The event mechanism ensures synchronization between different extended tasks. This means that an extended process in a waiting state can only enter the ready state when at least one of the events it is waiting for has occurred, and the occurrence of an event is signaled to the process. Only extended tasks have events. Resource management requires coordination between multiple tasks with different priorities accessing shared resources. These resources can be critical sections of code, schedulers, shared memory, data structures, or shared hardware devices. When handling mutual exclusion access to shared resources by multiple processes, the system uses semaphores to lock critical section data or resources, but this can lead to priority inversion. To avoid this, OSEK uses the Priority Maximum Protocol (PCP), where when a process acquires a resource, its priority is temporarily raised to the priority of that resource. When the task releases the resource, its priority returns to the priority before it requested access. This protocol also solves the deadlock problem. Alarms are a service mechanism provided by OSEK for handling cyclic events. Alarms are based either on the system clock or some other counter. When the counter reaches the alarm setting value, it is triggered. This can activate a process, set an event for a process, or execute an alarm callback. Message processing tasks communicate through messages. A message is a container for application data, with only one sender but multiple receivers. The OSEK specification classifies messages into queued and non-queuable messages. Queued messages are statically long, with internal data organized into a FIFO queue, and can be removed by the receiving service routine; non-queuable messages are constantly refreshed and cannot be removed by service routines. Error handling: OSEK provides system-specific hooks to execute user-defined functions during internal operating system operations. Hooks can be used for: system startup (executed after operating system startup but before entering the scheduler); system shutdown (executed when an application or operating system (in which case a serious error occurs) requests system shutdown); calling user-defined extensions during application tracing, debugging, and context switching; and error handling. The OSEKOS design, based on μC/OS-II, follows the OSEK specification and μC/OS-II kernel requirements. The CC1 and ECC1 priority levels allow only one process per priority. Therefore, priorities from 0 to N-1 can be assigned to N processes, ensuring each process has a different priority. N is the number of processes in the system. This allows the modified μC/OS-II kernel to meet the ECC1 class mode. Since the BCC2 and ECC2 priority levels allow multiple processes per priority, a complex scheduling strategy is needed to track each process. The designed OSEKOS adopts the μC/OS-II scheduling structure—the ready table—using a simple preemptive scheduling strategy. Each process's ready flag is placed in the ready table, and the highest-priority ready process is selected for execution, implementing a priority-based preemptive real-time kernel. This not only improves system real-time performance but also reduces the CPU load on the operating system. For the BCC2 and ECC2 priority levels, a time-slice round-robin scheduling algorithm can be added to the priority-based preemptive scheduling strategy to handle the scheduling of two tasks with the same priority. Alternatively, a FIFO queue can be added for each priority level, first searching by task priority and then selecting the process at the head of the queue to run. However, this sacrifices some real-time performance and increases CPU load and RAM consumption. To improve the portability and configuration of OSEKOS, it is divided into three parts according to the μC/OS-II kernel structure: hardware-independent, hardware-dependent, and application-dependent. This makes it easier to port to different hardware. The application-dependent part is placed in the configuration file for user convenience. When handling mutual exclusion access to shared resources by multiple processes, μC/OS-II mainly uses interrupt switching and semaphores to lock critical section data or resources, uses mutex semaphore management to avoid priority inversion, and allows users to define wait timeouts when requesting semaphores to resolve deadlock issues. OSEKOS avoids priority inversion and deadlock issues by employing the Highest Priority Protocol (PCP). By statically allocating the highest priority of each resource during system creation, the designed OS2EKOS executes the PCP protocol, achieving compatibility with the OSEK specification. Based on the two types of interrupts specified by OSEK, standard interrupt management APIs are implemented for specific processor platforms, and non-OSEK standard APIs (enabling/disabling interrupts) are provided according to μC/OS-II. Since OSEKOS is implemented based on ECC1 mode, it supports the event mechanism defined in the OSEK specification, which can be used for synchronization and coordination between tasks. According to μC/OS-II, supported event types include semaphores, mutex semaphores, mailboxes, and message queues. Time management and timer interrupt functions provided by μC/OS-II implement the alarm management required in OSEKOS, further improving the real-time performance and security of the operating system. In μC/OS-II, a series of hook programs similar to those required by the OSEKOS specification are defined for implementing user-defined functions. Composition of the Basic Structure of OSEKOS Since the standard application programming interfaces (APIs) in OSEKOS are defined in the kernel space of the operating system, based on the above design concept, the operating system can be functionally divided into process management and scheduling, resource management, alarm and counter management, event management, and interrupt management, as shown in Figure 1. Process management and scheduling are the core of the entire operating system, with other management mechanisms providing different service support. Figure 1 shows the structure of OSEKOS. Each process is managed through a Process Control Block (TCB). In the process management module, the OSEK standard APIs are implemented: activating a process, terminating a process, connecting processes, scheduling, capturing the currently running process ID, and obtaining the process status. The resource management module implements the OSEK standard APIs: acquiring resources and releasing resources. Counter management has no standard API. The alarm management structure consists of alarms and alarm behaviors. Its standard APIs include: obtaining alarm information, obtaining the time required for an alarm to expire, setting relative alarms, setting absolute alarms, and clearing alarms. The event management module implements the OSEK standard APIs: waiting for events, setting events, clearing events, and obtaining the time status of processes. The interrupt management standard APIs are implemented: enabling/disabling all interrupts and enabling/disabling Type II interrupts. Conclusion Based on the different technical characteristics of the OSEKOS specification and the μC/OS-II kernel implementation, this paper proposes some design ideas for OSEKOS and designs its basic structural components. The establishment of the OSEK/VDX architecture has had a profound impact on the international automotive industry. Developing an RTOS based on the OSEK/VDX specification can save development time, reduce costs, improve software quality and module portability, and requires fewer resources. Therefore, researching operating systems based on the OSEK/VDX specification is of great significance.