System software design based on DeltaOS

The system software of this system is built on the DeltaCORE kernel and is written in C language to improve the execution efficiency and readability of the software; the graphical interface is designed based on DeltaGUI and written in C++ to shorten the development cycle. The focus of the system software design is on stability and reliability, and the key and difficulty lies in the guarantee of real-time performance. As a complete system, the scalability of software functions is also indispensable. Starting from the overall design, this paper solves the above problems in a targeted manner.

1 System Function

The dual-star user terminal is a positioning and communication terminal. In addition to completing positioning and communication functions, it also needs to have a friendly human-computer interaction interface and a test equipment interface. The relationship between the embedded system and peripherals is shown in Figure 1.

The hardware platform of the embedded system is a universal platform, and the algorithm implementation and coordinated control of each part of the equipment are all implemented by embedded software. The specific functions that need to be completed by the software part are: interface input and output control, inbound data segment packaging, inbound information encryption, inbound frame packaging, outbound frame unpacking, outbound information decryption and providing a test interface.

2. Improve the real-time performance of the system

2.1 Optimization of task division

When designing a complex multi-tasking application, the reasonable division of tasks has a great impact on the system's operating efficiency, real-time performance, and throughput. Too detailed a task division will increase the overhead of frequent task switching, while insufficient task division will cause operations that could have been done in parallel to be completed sequentially, thereby reducing the system's throughput.

When decomposing a software system into parallel tasks, the main consideration is the asynchronous nature of the system's functions. By analyzing the transformations in the data flow graph, we can determine which transformations can be run in parallel and which transformations are sequential in nature. In this way, we can divide the tasks into tasks: one transformation corresponds to one task, or one task includes several transformations. Should a transformation be an independent task or should it be combined with other transformations to form a task? This software follows the H-Gomma principle [1], which is:

①I/O dependency principle

②Time criticality principle

③ Principle of large amount of calculation

④ Functional cohesion

⑤ Time cohesion

⑥ Periodicity principle

The software of this system is divided into two parts: application software and system software. The application software part is located on the upper layer of the system software, and it completes the input and display functions of the graphical interface. The application software part has the characteristics of long processing time, low real-time requirements and no parallelism, so it is treated as a GUI task and given the lowest priority. The system software needs to complete all inbound and outbound information processing. The processing process is complex and the real-time requirements are high. Sequential processing obviously cannot meet the requirements, so task division optimization must be carried out.

FIG. 2 is a data flow diagram for inbound information processing, and FIG. 3 is a data flow diagram for outbound information processing.

According to the I/O dependency principle, functions that directly interact with I/O devices should become independent tasks, because their running speed is subject to the speed of the I/O devices that interact with them. In the inbound process, sending instructions to the IC card, receiving IC card response information, and sending inbound data frames to the baseband all involve I/O operations, which should be divided into independent tasks. Similarly, the main channel data reading, secondary channel data reading, sending instructions to the IC card, and receiving IC card response information in the outbound information processing process are divided into independent tasks.

Figure 2 Inbound information processing data flow diagram

Figure 3 Outbound information processing data flow diagram

According to the principle of functional cohesion, transformations with closely related functions form a task, and they share resources or are driven by the same events. Positioning data segment packaging and communication data segment packaging have similar functions. They are both triggered by valid input instructions and can be combined into a data segment packaging task. Different functional modules are used to process different types of requests. In this way, when the system needs to add new functions, it only needs to add the corresponding processing module to the task, and scalability is guaranteed.

According to the principle of temporal cohesion, functions completed at the same time can form a task even if they are unrelated. The data segment packaging is processed immediately after the input instruction is interpreted, and has temporal continuity. Combining them into one task can reduce the communication overhead between tasks, which is conducive to improving the real-time performance of the system.

The computational complexity of primary channel data frame unpacking, secondary channel data frame unpacking and inbound data frame packing is large, so they are suitable as independent tasks. However, the outbound data frame formats of primary channel and secondary channel are the same, so they can share one task: outbound frame data unpacking.

Although the encryption instruction packaging and decryption instruction packaging are in the inbound information processing flow and the outbound information processing flow respectively, they belong to the same IC card instruction packaging, have strong functional cohesion, and are merged into one task to share the IC card driver.

The task redivision is shown in Figure 4. After optimization, not only the real-time performance and scalability of the system software are enhanced, but also the code size is reduced due to sufficient code reuse, saving storage space.

Figure 4 Optimized inbound and outbound task division and data flow diagram

2.2 Interrupt Optimization

Task switching is scheduled by the operating system, and the intervention of the operating system will waste CPU time. Especially for time-critical tasks, such as reading baseband main channel data, reading secondary channel data, sending instructions to IC cards, and receiving corresponding information from IC cards, frequent task scheduling will make the system inefficient. Therefore, these processes are directly completed by the interrupt service subroutine.

Although the interrupt service response speed is fast, when an interrupt service is executed, other interrupts of the same priority or lower priority and tasks of any priority cannot be executed. Therefore, if the interrupt service takes too long, it will also reduce the real-time performance of the system.

In order to improve the real-time performance of the system, this system software has mainly made the following two optimizations in interrupt processing:

① Optimize the interrupt priority setting, set the interrupts with high trigger frequency and important interrupts to high priority to ensure their timely response.

② The interrupt shutdown time should be as short as possible. ISRs only complete some necessary operations, such as inputting data, outputting data, or passing control information to the task. Further processing of the interrupt is completed by the task [2].

3. Reliability guarantee and scalability improvement

Reliability is crucial for any software. Software reliability is easy to achieve within a task, and problems usually arise at the interface between tasks. Interface design is also related to software scalability. In a multitasking operating system, the interface between tasks is implemented through synchronization and communication mechanisms, so the synchronization and communication mechanisms must be carefully selected.

DeltaCORE provides four communication and synchronization mechanisms: message queue, semaphore, asynchronous signal, and event. Among them, the message queue and event mechanisms can achieve communication and synchronization at the same time, the semaphore mechanism can achieve synchronization and mutual exclusion, and the asynchronous signal (also called soft interrupt mechanism) can achieve synchronization.

In order to meet the needs of system communication and synchronization, two solutions can be adopted: the first solution is to achieve synchronization through synchronization mechanisms such as semaphores, and use global arrays or other shared data structures to achieve communication between tasks, as shown in Figure 5; the other solution is to use message queues to achieve communication and synchronization at the same time, as shown in Figure 6.

Comparing the two solutions, each has its own advantages and disadvantages: Solution 1 has strong real-time performance, but there is a reentrancy problem; Solution 2 is simple and reliable to implement, but the real-time performance of the message queue mechanism communication is relatively weak. The outbound information in this system is highly bursty. If Solution 1 is adopted, the data of the second channel may become invalid or the data of the first channel may be overwritten; if Solution 2 is adopted, although the data processing delay is slightly larger, the data can be completely stored in the message queue without being damaged. In addition, using the message queue to provide a unique entry for the task can simplify the interface design and facilitate function expansion. Therefore, this article adopts the message queue solution, and its implementation method is as follows:

Each task corresponds to a message queue, and the task only processes the messages in the corresponding message queue. For the sender (task1), when it needs to hand over the data in the send buffer to task2 for processing, it only needs to send the data in the buffer to the message queue Q2 corresponding to task2.

ret = delta_message_queue_send ( Queue_id[ 2 ], buffer, size );

Queue_id[2] is the ID of message queue Q2, and size is the message size (in bytes).

For the receiver (task2), set the waiting time parameter of the message receiving function to wait forever, so as to block the task when the message queue is empty. The code of task2 is as follows:

delta_task task1()

{

delta_status_code ret;

... // Define other local variables

while(1)

{

ret = delta_message_queue_receive(

Queue_id[ 2 ], /*Message queue ID*/

RecBuff, /*Pointer to the receive buffer*/

&size,/*Size of received message (in bytes)*/

DELTA_DEFAULT_OPTIONS, /*property set*/

DELTA_NO_TIMEOUT /*Wait time*/

);

…… //Complete the code for task1 function

}

}

In this way, communication and synchronization between tasks and between tasks and interrupts can be achieved. The state transition of tasks is shown in Figure 7:

4. Prevention and resolution of fatal errors

Exceptions are usually caused by two situations: one is array out of bounds or improper use of pointers; the other is task stack overflow. To avoid the above situations, the size of the array and task stack must be set appropriately, and when modifying array elements, the subscript must be within the legal range, and pointers must be used with special care. However, DeltaOS provides an exception handling mechanism, and users can write their own extension routines to implement certain rescue measures when fatal errors occur, such as resetting the entire system software or restarting a specified task.

DeltaOS is a strong real-time operating system that meets the strong real-time requirements of the system by optimizing task division and effectively using the interrupt mechanism. Using the communication and synchronization scheme proposed in this paper, the standardized interface of the task is realized, multiple functional expansions are conveniently carried out, and its strong reliability is demonstrated.