Modular design has become increasingly prevalent in software design. Modular design leads to clear program structure, easier maintenance, and more efficient development. Large software programs typically consist of multiple functional modules, and the functionality of these modules is supported by multiple threads. Operating systems like Windows and Linux can manage inter-thread communication well without needing to worry too much about the underlying details. However, VxWorks is a multi-tasking system, where tasks are the most basic execution units. Communication between functional modules is essentially inter-task communication, and VxWorks' management of inter-task communication is far less sophisticated than Windows'. When there are many modules and a large volume of communication tasks, VxWorks' inter-task communication mechanism cannot adequately meet the requirements of real-time performance and resource utilization. This paper proposes an inter-task communication model that introduces UDP, a method used for network communication, into inter-task communication, making communication more flexible and easier to manage, and improving the overall system performance. Introduction to the Multi-Task Real-Time Operating System VxWorks: VxWorks is an embedded real-time operating system (RTOS) and a key component of embedded development environments, characterized by high reliability, strong real-time performance, and scalability. VxWorks provides programmers with efficient real-time task scheduling, interrupt management, real-time system resources, and inter-task communication. Application programmers can focus on the application itself without worrying about system resource management. VxWorks can support up to 256 tasks and supports resource sharing methods such as binary semaphores, mutex semaphores, and message mailboxes. Its efficient real-time multi-tasking kernel allows VxWorks to provide similar API interfaces to multiple series of MPUs, MCUs, and DSPs simultaneously. Its excellent portability requires only 1% to 5% code modification across processor platforms. Its strong continuous development capabilities, high-performance kernel, and user-friendly development environment have secured VxWorks a place in the embedded real-time operating system field. Its high reliability and excellent real-time performance have led to its widespread application in high-precision technologies and fields with extremely high real-time requirements, such as communications, military, aviation, and aerospace, including satellite communications, military exercises, ballistic guidance, and aircraft navigation. Problems with Traditional Inter-Module Communication Methods Embedded operating systems are mostly used in applications with high real-time requirements. Due to size and cost limitations, the resources and operating speed of embedded systems cannot be compared with those of PCs. Therefore, the efficiency and resource consumption reduction of applications developed on such systems are crucial. VxWorks is a multitasking operating system, and traditional inter-task communication models include shared memory, semaphores, and message queues. Each of these methods has its shortcomings. Shared memory uses global variables or caches; for large and complex programs, multiple tasks simultaneously reading and writing to the same variable can cause conflicts or cache overflows. While semaphores effectively prevent mutual exclusion, multiple tasks communicating with the same task simultaneously can lead to semaphore contention, causing queuing at the initiating end and reducing system efficiency. Message queues avoid queuing problems caused by semaphores through asynchronous message passing, but with a large number of tasks, the required number of queues becomes excessive, consuming significant system resources. A large number of modules and high communication volume can cause task queuing and resource consumption, impacting VxWorks' real-time performance and overall system performance. The communication model described below offers advantages in overcoming these problems. Communication Model Principles and Performance Analysis The entire communication model consists of four parts: business modules, UDP ports, virtual device controllers (DEVs), and a unified timer. Inter-module communication uses UDP-based communication for information exchange. A Virtual Device Controller (DEV) concept binds the UDP port to the business module, creating a loosely coupled relationship. Each module has its own DEV, responsible for managing the UDP port and interacting with other modules. A unified timer coordinates and controls the timing of message sending by the business modules. The unified timer and DEV work together to complete inter-module communication. UDP is inherently a connectionless network communication method; its reliability needs to be examined when introduced into a program for communication. Although UDP communication is connectionless and may experience packet loss in poor network conditions, the probability of UDP packet loss is very small because the program runs on a single host, and the interaction between modules within the program is limited to the local machine and does not involve the network. Therefore, communication reliability is fully guaranteed. The principle diagram of the communication model is as follows: 1. Concept of Virtual Device Controller (DEV) The Virtual Device Controller (DEV) is essentially a data structure. Each module obtains its own DEV by declaring such a data structure. The DEV records information about the UDP port, module number, or module name. The DEV also includes two circular buffers for data interaction with the module. The UDP socket is closely integrated with the DEV, but it is not directly connected to the module. That is to say, a UDP does not belong to a certain module. They are loosely coupled. The introduction of the DEV concept abstracts the UDP socket into a virtual device for the module to use. It separates the communication function from the business function of the module, making them more independent and improving efficiency. The module and the UDP socket can also be flexibly configured and released through the DEV. The structure of the DEV is as follows: Struct DEV { int Module_ID; //Records the module number; int SocketKind; //Records the socket type; int socket_ID; //Records the socket handle struct RINGBUF_t m_Buf[2]; //Two circular buffers: [0] for input and [1] for output} During software initialization, several idle DEV devices can be requested. When a certain business module starts, an idle DEV can be requested for its own use. Filling the Module_ID in the DEV structure variable with the number of the business module completes the binding between the module and the DEV. By requesting a new UDP socket and storing its handle in the `socket_ID` variable of the `DEV` structure, the UDP and `DEV` connections are established. This allows the business module to connect to UDP via `DEV`, and control and use UDP for communication through `DEV`. When the module no longer needs UDP, or if the UDP socket fails, the `Module_ID` and `socket_ID` in its `DEV` structure can be set to 0, canceling the connection and releasing the UDP connection. When the module needs to use UDP again, it can re-request `DEV` and UDP. This decoupling method ensures that the normal operation of the module is unaffected by UDP, improving program reliability. **2. The Role of the Unified Timer** The unified timer is responsible for coordinating all UDP transmissions. It starts after program initialization and executes a specific action when the timer expires. It polls all DevOps instances and sends the contents of their transmission buffers via UDP. 3. Communication Implementation Process ① UDP Message Sending: When a task in module A needs to communicate with other modules, it packages the information and sends it to the other modules via UDP. The task (thread) of module A puts the message packet to be sent into buffer #1 of DEV. A unified timer polls all DEVs at regular intervals. If there is information waiting to be sent, it sends the information to the destination through the UDP port controlled by that DEV. ② UDP Message Reception: As shown in Figure 2, each module has a monitoring task (thread) responsible for periodically monitoring the UDP port controlled by the corresponding DEV. Once a message is received via UDP, the thread is responsible for reading the received message from the UDP buffer and storing it in buffer #0 of DEV. Other tasks of the module can read and parse messages from buffer #0 when they need to obtain messages. 4. Performance Analysis of the Communication Model The above communication model adopts a quasi-asynchronous approach. Modules send messages synchronously and receive messages asynchronously. This avoids conflicts during multi-module communication and saves resources, making it more efficient than traditional communication models. The loosely coupled mapping relationship allows for flexible combination and release between modules and communication ports, providing greater freedom in software architecture design. ① Efficiency: A timer-based polling message sending method is used to avoid communication conflicts. When a module sends a UDP message to another module, it only needs to package the message and put it into the DEV's send buffer; the packet sending is handled by a unified timer. The module itself doesn't concern itself with packet sending; after putting the packet into DEV, it can perform other tasks. This method avoids the queuing phenomenon seen in semaphore models when multiple modules communicate with a particular module simultaneously, improving system efficiency and ensuring real-time performance. Since all module sending is handled by timers, the program code is simplified, enhancing code reusability. ② Resource Utilization: Due to the flexible UDP communication method, messages are sent only when communication is needed between modules, eliminating the need to establish multiple message queues between modules. This resource saving is even more pronounced when the number of modules is large. For example, with n modules, establishing a message queue between each pair would require (n-1)! queues, requiring the program to maintain a large number of message queues, resulting in significant resource consumption. The communication model presented in this paper will save limited system resources and is well-suited for embedded system development. ③ Solution to message backlog problem: In traditional communication models, modules send messages without restriction. The send function is called immediately whenever a message needs to be sent. If multiple modules send messages to a single module simultaneously within a certain period, and the receiving module cannot process them in time, the continuous backlog of messages will cause buffer overflow. Using a unified timer method, message sending is made more orderly and restricted to a certain extent. During the interval between two polls of a module by the timer, the module can process the previously received message and prepare for receiving new messages. As long as the timer's timing is set appropriately, buffer overflow can be avoided. [b]Implementation of the Communication Model[/b] VxWorks is a multi-tasking operating system. The various components of the model can be implemented through tasks. VxWorks' network programming interface and timers are very convenient to use, providing open APIs to users. Only functions such as socket, send, receive, CreateTimer, and SetTimer are needed to operate on sockets and timers. During program initialization, timer tasks can be started first, then a sufficient number of DEVs can be generated, and then the various modules can be started sequentially. During the startup of each module, an idle DEV is first requested, then a UDP socket is created, and a mapping relationship is established between the socket and the DEV. After the binding between the module and the DEV is completed, a monitoring task (Moniter_Task) is started to monitor the UDP port. At this point, the communication model is established. Finally, other tasks of the module are started to begin the normal business process. Conclusion This paper proposes an inter-module communication model that differs from traditional communication mechanisms. By introducing UDP, a method used for network communication, into inter-module communication within the program, it avoids the inefficiencies and excessive resource consumption that may arise from traditional methods. The loosely coupled connection method enhances the program's flexibility. In experiments, this UDP-based virtual device binding communication model achieved good results and has high value in the development of embedded systems with high real-time requirements. Editor: He Shiping