In traditional embedded real-time operating systems, the kernel and applications run at the same privilege level, allowing applications unrestricted access to the entire system address space. Therefore, in certain situations, potentially dangerous actions by applications can affect the normal operation of other applications and the kernel, even leading to system crashes or malfunctions. To meet the high reliability, high availability, and high serviceability requirements of avionics, ARINC released ARINC 653 (Avionics Application Software Standard Interface) in January 1997, and ARINC 653 Supplement 1 in July 2003, providing supplementary specifications for inter-area management, inter-area communication, and health monitoring to standardize the development of avionics equipment and systems. Subsequently, major international embedded system developers launched operating systems supporting ARINC 653 with kernel and application protection mechanisms. However, such research still lags behind in the domestic embedded system field. Based on this, this paper proposes a design concept for an avionics embedded real-time operating system (A-RTOS, Avionics RTOS) and implements it on a target board with an MMU and support for advanced protection modes. ARINC 653, an avionics standard , primarily describes the baseline operating environment for application software used in Integrated Modular Avionics (IMAs). It defines the interface and data exchange patterns between avionics applications and the underlying operating environment, as well as the behavior of services, and describes the runtime environment of embedded avionics software. ARINC 653 Supplement 1 supplements ARINC 653 in several key aspects: In terms of system architecture, it introduces the concept of System Partition, clarifying that application scheduling within a partition should be partition-level, with these applications sharing partition resources; regarding partition management, it elucidates the principles for defining the master timeframe in partition scheduling and supplements the evolution process of partition modes; it provides a more detailed explanation of the principles of inter-partition communication; and it adds explanations regarding error levels and error handling for health monitoring. Software Composition The core module software in avionics includes two categories: application software and core software. The APEX (Application Executable) interface, located between the application software and the operating system (OS), defines a set of functions provided by the system for the application software. Using this set of functions, the application software can control system scheduling, communication, and internal status information. The APEX interface is essentially a high-level language provided for applications. For the OS, it defines parameters and entry mechanisms. [align=center] Figure 1 shows the relationships between the various parts of ARINC653[/align] Partitioning and Interval Management Partitioning is a core concept in ARINC653. In an IMA (Integrated Modular Avionics) system, a core module contains one or more avionics applications, and these applications must be able to run independently. Partitioning is a functional division within an avionics application. The unit of partitioning is called an interval, and each execution unit within an interval is called a process. Each interval has its own independent data, context, and runtime environment. This prevents errors in one interval from affecting other intervals. Furthermore, it makes the entire system easier to verify, confirm, and authenticate. Partitioning, as well as interval management and scheduling, are implemented by the OS. ARINC653 specifies a time-window-based cyclic scheduling algorithm for interval scheduling. The principle of this scheduling algorithm is shown in Figure 2. [align=center]Figure 2 Principle of Time-Window-Based Cyclic Scheduling Algorithm[/align] To complete the periodic scheduling of each interval, the OS maintains a main timeframe of fixed length, which repeats periodically during the module's runtime. Each timeframe can be divided into several time windows. The system uses a pre-determined configuration table to activate the corresponding interval's execution within the specified time window. This ensures that each application's access to public resources is not interrupted within its allocated time period. ARINC Supplement 1 supplemented the time definition principles of the main timeframe. It stipulates that the size of the main timeframe should be a positive integer multiple of the least common multiple of the interval periods in the core module, and should take into account the execution length and frequency of each interval. When ARINC653 Supplement 1 was released, system interval attributes and startup condition attributes were added. The interval's working modes include four types: idle, cold start, warm start, and normal, as shown in Figure 3. The resources required for each interval are specified during system construction, and the interval object is created when interval initialization is complete. The OS starts the application interval when entering the running mode, and then the interval enters the normal operating mode. The monitoring and management function will restart or stop the operation of the zone in response to a fatal error. [align=center]Figure 3 Zone State Transition Model[/align] A-RTOS System Design and Implementation The system architecture of A-RTOS is shown in Figure 4. In this system, each application works in its respective zone environment, and applications and the kernel, as well as the applications themselves, are isolated by protective walls, preventing mutual damage and thus ensuring the reliability of the core modules. [align=center]Figure 4 A-RTOS System Architecture[/align] Isolation and Protection Mechanisms Isolation and protection are the primary features emphasized by ARINC653 and one of the key issues that must be addressed. A-RTOS mainly uses two methods to achieve isolation and protection between applications and the kernel, as well as between applications. The first method is to use the Memory Management Unit (MMU). The MMU can realize the translation of logical addresses to physical addresses and control access permissions. This can protect the operating system kernel from intentional or unintentional damage by application software and effectively prevent mutual damage between application software. Figure 5 shows the address translation process of the MMU using the page directory/page table method. [align=center]Figure 5 Address Translation Flow of Page Directory/Page Table Method[/align] The second method is system calls. To protect the kernel and applications, A-RTOS provides two operating modes: user mode and system mode. The operating system kernel runs in system mode. Therefore, user-mode applications cannot directly call the functional interfaces provided by the system kernel; they must use the TRAP system call method. In this method, when a user-mode application needs to call a system call provided by the kernel, it first executes a set of special instructions to enter system mode to execute the required system call. After the call is completed, the kernel executes another set of characteristic instructions to return the system to user mode. Each system supporting protected mode provides a dedicated software interrupt command to complete the function of entering system mode from user mode. The system attaches a software interrupt handler function, and all system calls are entered through this software interrupt and distinguished by different parameter values ​​(i.e., system call numbers). Another form of system call is the call library mechanism called CALL-LIB. This mechanism is similar to the dynamic link library in Windows, which can meet the needs of dynamically loading and updating components and is also one of the characteristics of A-RTOS. The ARINC 653 interval scheduling mechanism specifies the following key characteristics: 1) the scheduling unit is the interval; 2) intervals have no priority; 3) the scheduling algorithm is predetermined, repeats at a fixed cycle, and can only be configured by the system integrator. At least one interval window must be allocated to each interval in each cycle. In A-RTOS, to facilitate system processing and better comply with the ARINC 653 specification, these provisions have been revised to some extent: the scheduling unit is the interval and system process; intervals have priorities. However, these revisions do not affect the operating system's interval layer POS or application users, so they do not violate the ARINC 653 specifications in terms of external characteristics. In addition, A-RTOS introduces two system intervals: Kernel intervals and Idle intervals. Kernel intervals have the highest priority and are used to support the operation of the entire system; some system-level processes also belong to the Kernel interval for easier scheduling. Idle intervals have the lowest priority and are used to fill system time. When no other intervals can run in the system, the Idle interval runs. The scheduling principle of A-RTOS intervals is primarily based on priority scheduling. For intervals of the same priority, time-slice round-robin scheduling or time-window-based cyclic scheduling strategies can be used. A-RTOS employs a two-level scheduling mechanism. The system has an interval priority bitmap and a ready list corresponding to each priority level. Each interval also contains a system process priority bitmap and a corresponding ready list. Using the priority bitmap and ready list, the scheduling of intervals and system processes can be easily implemented. Figure 6 illustrates this scheduling model. [align=center]Figure 6 A-RTOS Interval Scheduling Model[/align] The scheduling module first performs interval scheduling based on the interval priority bitmap and interval ready list in the system. The scheduled interval then performs system process scheduling based on the process priority bitmap and process ready list within the interval. Compared to a single-level scheduling method, this method ensures the determinism of scheduling time; the system scheduling time does not change due to the number of intervals or system processes, conforming to the definition of a real-time operating system. When performing time-window-based scheduling, both system intervals also participate in the scheduling. The runtime of the kernel interval is calculated in the interval scheduling configuration table for the current interval's runtime. Therefore, for a given application interval, its runtime actually includes the runtime of the system interval. Process Pool Mechanism In A-RTOS, a process pool refers to a group of processes maintained by the system that provide a set of services to applications. Applications submit application requests to the system through system-provided call interfaces. The system then hands the application's request over to the process pool, which automatically selects an idle process to serve it. After the service is completed, the system reclaims that process. Process pools are mainly used for clock timer services, interrupt services, and asynchronous I/O operations. Asynchronous Signals and Asynchronous I/O Mechanisms A-RTOS supports an asynchronous signal mechanism, allowing the COS to send signals to the upper-layer POS asynchronously under certain circumstances. A typical use of asynchronous signals is asynchronous I/O. This is because in ARINC653 applications, when a process in the POS generates a blocking I/O request through a system call, if the I/O is not asynchronous, the process will block, waiting for the system call to return. However, the COS is unaware of the existence of application processes in the POS; when one process blocks, the entire interval is blocked. Using asynchronous I/O avoids this situation. When an application requests a blocking I/O service, A-RTOS starts a system process to perform the requested I/O operation; this is the asynchronous I/O mechanism. A-RTOS calls this system process created to implement asynchronous I/O operations a worker process. As shown in Figure 7, in an ARINC653 application, when a process in the POS calls an asynchronous I/O system call, the system call checks if the I/O is in blocking mode. If so, it creates a worker process to complete the requested I/O work and returns an AIO_PENDING value to the POS. After receiving this return value, the POS removes the process currently making the asynchronous I/O call from the ready queue and places it in the waiting queue, then reschedules it. When the worker process completes the requested I/O operation, it sends an asynchronous signal to the POS, thereby waking up the original blocking process. [align=center] Figure 7: Asynchronous I/O Workflow Diagram[/align]