# IoT OS Platform: Software Infrastructure for Next-Gen Industrial IoT
## 3 Theoretical Framework of the IoT OS Platform
### Core Design of the IoT Operating System Platform
#### 3.2.2 Real-Time  
In IIoT scenarios, there are issues with large volumes of data, high real-time requirements, and significant security risks. Various attempts have been made domestically and internationally to address these issues, mainly by introducing and adapting technologies from other fields with characteristics of the IIoT industry. To solve problems brought by massive data, the consensus is that single-machine systems are no longer sufficient, and the introduction of distributed systems is necessary [51]. Many studies have been conducted from the perspectives of communication and wireless networking, focusing on improving the underlying network for real-time data transmission, but lacking attention to business real-time requirements. Existing IIoT systems often integrate multiple terminal devices and systems. In their distributed network architecture, adopting decentralized data access and business execution strategies can enhance real-time performance in more business scenarios. To meet the real-time requirements in the context of massive data in IIoT, we have designed mechanisms for nearest data access and task scheduling in the IoT operating system platform. **Nearest Data Access. ** In operating systems, data are stored in high-speed caches, main memory, or auxiliary storage according to access frequency, in order to enhance data access speed and storage capacity. The data access model of the IoT operating system platform is as shown in Figure 4.  
Specifically, when storing data, we designed a mechanism that allows the IoT OS platform to schedule data across cloud, edge, and end sides based on the importance and access frequency of the data. This enables better support for data access speed and processing efficiency in scenarios with massive data, reducing data storage costs. We primarily consider the data volume and real-time requirements in evaluating data storage. High-frequency data and important alarm data, such as device attributes and device alarms, should be stored in the central platform for rapid access when needed. For data of lesser importance and weaker real-time requirements, they should be stored in edge nodes and  
Figure 4: Model of data access. Figure 3: Semantic standards. accessed when needed, such as audio and video data, which are usually transmitted to the platform when users stream. For low-frequency data, such as device authentication information and signaling logs, they are stored directly in devices and not uploaded to edge nodes or the central platform, reducing storage overhead and communication costs. **Task Scheduling. ** In complex IIoT scenarios, IoT systems need to execute a wide variety of tasks. Different tasks have different resource requirements. Some tasks have real-time requirements and need to be executed on edge devices or edge servers, while others require significant computational power and need to be handed over to central cloud nodes. To meet the resource demands of different tasks, we believe that IIoT systems need the ability to dynamically and reasonably allocate resources and schedule tasks. In operating systems, the execution of processes occupies CPU time, memory space, files, network ports, etc. Based on factors such as process priority and execution time, the operating system can schedule and manage resources. In our design for the IoT OS platform, computational resources and storage resources are unevenly distributed across the distributed IIoT system. Many services provided to the upper layer also require the coordinated scheduling of various resources, including network resource coordination during transmission, data resource coordination during data flow, and computational resource coordination during task execution. Referring to traditional operating system resource allocation strategies, we designed a unified resource allocation system in the IoT OS platform, as shown in Figure 5, to collect real-time information from each subsystem.