Research on real-time technology of software reliability simulation test platform

Software reliability testing is a hot topic in the current software technology field. Software reliability has an increasingly greater impact on the reliability of the entire system, especially for aviation system software, where software failure is often one of the main causes of system failure. Using simulation to test the actual operating environment of the target software under test is currently one of the more ideal software testing methods recognized at home and abroad. Reasonable design of the operating environment of the target software reliability and more realistic simulation of the actual operating environment of the software under test can not only detect the faults in the target software during operation, but also ensure the authenticity and confidence of the test results.

Based on the introduction of the composition and functions of the software reliability simulation test platform, this paper takes the simulator subsystem as an example to study some implementation technologies of the platform in the real-time testing process.

1. Function and composition framework of simulation test platform system

The entire simulation test platform adopts a distributed structure, which consists of three subsystems: the main control subsystem (hereinafter referred to as the main control), the simulator subsystem (hereinafter referred to as the simulator) and the exciter subsystem (hereinafter referred to as the exciter). The cross-linking relationship between each subsystem and the target software under test is shown in Figure 1. Among them, the main control is the control center of the test platform. It is responsible for generating original test data, distributing test cases to the simulator and the exciter, coordinating the work of the two subsystems, and controlling the working mode of the simulator and the exciter according to the test conditions. The simulator and the exciter generate the test case data that the real target software can receive from the test case data transmitted by the main control and transmit it to the target system. At the same time, the simulator and the exciter are responsible for transmitting their own working status information and the test result data obtained from the target system back to the main control through the underlying network in real time or non-real time.

Figure 1 Cross-linking relationship diagram of the simulation test platform

Since the target software is written in assembly language and the internal processing is relatively complex, a black box test method is used. The processing cycle of the target software is 25 ms. Therefore, during the real-time test process, a set of test case data needs to be input to the target software by the emulator through the 1553B bus and the stimulator through the parallel port every 25 ms. The emulator and the stimulator not only need to generate input data of the target software every 25 ms and send data to the target software synchronously, but the emulator can also receive the output of the target software and perform corresponding real-time processing on the output data, such as collecting, saving and displaying the result data. Since the entire test platform is implemented on the non-real-time, multi-tasking Win98 operating system, how to use the multi-tasking concurrency characteristics of Win98, adopt a reasonable task scheduling strategy , complete various tasks on time within the task processing cycle, and coordinate multiple tasks are the main problems that should be solved in the entire design process.

In the subsystems of the platform shown in Figure 1, the main control machine and the target software form a real-time closed loop through the simulator. The simulator gives the commands and data issued by the cross-linking subsystem required for the closed-loop operation of the target software in real time through test cases, so that the target software can run in a more realistic simulation task profile and cross-linking environment. Therefore, the simulator is an important component of the simulation test platform, and the real-time implementation method of the simulator is the focus of the entire platform system design.

2 Functional Design and Real-time Implementation Technology of Simulator Subsystem

2.1 Simulator subsystem functional structure

The simulator subsystem is a real-time task system. In the running mode of the entire test process, different tasks need to be processed concurrently, such as real-time data storage, extraction, interactive display, and driving the 1553B bus every 25 ms. Task scheduling involves resources such as CPU , memory, network, hard disk, data structure, and I/O interface. Therefore, reasonable scheduling of each task and correct allocation of the system resources they occupy are one of the keys to the design of the simulator test platform.

In order to improve the reliability and fault recovery capability of the platform system, the simulator adopts a functional modular design method. The working modules corresponding to different tasks work relatively independently, and the software algorithms of the corresponding modules can be updated and expanded at any time according to new technologies. This design is easy to give full play to the multi-tasking characteristics of Win98 and improve the real-time working ability of the platform system. Among them, the task scheduling management module is the core of the simulator platform system, and the operation of other functional modules is completed under the unified management and control of the management scheduling module. The logical calling relationship between it and the functional modules of other tasks is shown in Figure 2.

Figure 2 Task scheduling management module call relationship

In the design of the emulator, except for the necessary hardware devices such as the network card (connected to the host computer) and the MBI card (connected to the target system), all the functions of the emulator are completed through software. Therefore, a reasonable scheduling strategy is adopted in the system software design to avoid the defects of the operating system in order to realize the functions of the emulator.

2.2 Real-time Implementation Technology of Simulator Subsystem

2.2.1 Task Scheduling Management Module

From the above discussion, we know that the real-time performance of the simulator is achieved through the simulator's task scheduling management module. The task scheduling management module is the main control module of the simulator subsystem and is the overall manager of the subsystem. This module manages and schedules concurrently executed real-time self-check/maintenance, network communication, cross-linked simulation data generation, data/status display, data recording, cross-linked data drive, test process analysis, and task queues corresponding to different functional modes of the simulator, coordinates the work of each module, connects each module, realizes the management of each thread, and completes the real-time cross-linked simulation task with the target system.

2.2.2 Simulator subsystem task division

Since the simulator subsystem is used for real-time simulation testing of the target software, each task must meet the timing constraints of the real-time cross-link simulation according to the needs of the target software operation. Therefore, in order to ensure the real-time performance of the simulator, different scheduling strategies are concentrated in the scheduling framework according to the different working modes of the tasks and platform systems. Task scheduling involves the scheduling of real-time tasks and ordinary time-sharing tasks. [page]

According to the running mode of the simulator, its tasks are divided into real-time tasks and non-real-time tasks .

Real-time tasks refer to tasks that the simulator needs to complete within a certain time during the simulation test, including:

． Command control (including test start, working mode switching, drive communication interface, test end, etc.);

．Real-time cross-linking data-driven tasks with the target software under test;

．Real-time network communication tasks with the main control subsystem;

． Real-time generation of cross-linking data;

．Record and display of test data and test result data;

．Preliminary accuracy analysis of test result data and state logic verification.

Non-real-time tasks refer to tasks that have no strict constraints on the time of task completion, including:

． Subsystem parameters and related configuration descriptions performed by the user through the interface;

． Subsystem initialization and user-specified subsystem self-check and maintenance;

． Post-test data playback;

．Database operations.

For the convenience of system task scheduling management, real-time tasks are divided into dynamic tasks and static tasks according to the attributes, levels and processing cycles of the tasks. Static tasks include long-cycle tasks and short-cycle tasks.

Dynamic tasks refer to tasks that are dynamically tracked by the system status and temporarily added based on the actual operating conditions, such as real-time self-check tasks and exception handling tasks that are dynamically added when a system failure occurs.

Long-term tasks are tasks that can be completed within multiple time tags. If necessary, such tasks can be terminated before the time limit is completed. They include display tasks, recording tasks, and tasks that read data from a database or data file into memory.

Short-cycle tasks are tasks that have strict time limits and must be completed within a time tag, that is, within a 25 ms period, complete a drive of the target software and receive the external output of the target software. They include periodic tasks such as the generation of crosslink data, the 1553B drive of crosslink data, the network communication tasks of receiving and sending test data packets from the host computer and the simulator response packets to the host computer.

The above-mentioned tasks generally include six states in their life cycle: creation, ready, suspension, running, cancellation and end. The state transition relationship is shown in Figure 3. The overall task scheduling controller brings each task into a different state.

Figure 3 Schematic diagram of task state transition relationship

2.2.3 Design of simulator scheduling module

The simulator uses a scheduling principle that combines time, event and data drive to control and manage various tasks. In order to improve the real-time and adaptability of the system, a scheduling method that combines dynamic and static scheduling strategies and the cycle and priority of task occurrence is adopted.

Different scheduling strategies are integrated in the scheduling framework. In the running mode: if the system test works normally, the statically generated scheduling strategy is used for periodic real-time tasks; when a system failure occurs, a temporary dynamic scheduling strategy is used, which adds dynamic tasks in real time according to the system's operating status, and decides whether the task is executed immediately or in sequence according to the level of the dynamic task. As the failure is eliminated, the task is canceled and the system returns to the previous scheduling strategy.

The simulator schedules different modules at different rates according to the different time taken by the task to meet the requirements of real-time driving. A combination of priority scheduling and time-sharing scheduling is adopted: the priority scheduling method is that the scheduling module assigns a strict priority to each task and executes it in order of priority from high to low; the time-sharing scheduling method uses a time slice rotation method to execute each task. This scheduling method is mostly used in the termination mode (or in the running mode, the system has completed the short-cycle task and there is still time left). For example, short-cycle tasks such as 1553B data driving and cross-linking data generation are serially executed every 25 ms, and are given a higher priority, while long-cycle tasks such as displaying and recording data are time-sharing or cross-executed, and are given a lower priority to ensure that the MBI card can be driven normally.

In the priority scheduling mode, the principle of floating priority is adopted: that is, according to the different real-time processing tasks of the system, the priority is changed dynamically as needed. When the system is operating normally, the priority remains unchanged; when a serious fault occurs in the system, the scheduling module dynamically triggers the exception handling task, and dynamically adjusts the module processing level according to the fault type and the condition of the fault being maintained. For important modules that affect the system test, the scheduling module starts the corresponding backup reserve module and sends the application of "pause test" to the main control machine through the network. In this way, the system has the ability to recover from faults, realizes redundant protection of key parts, and improves reliability.

According to the above design, during the real-time test, the real-time scheduling hierarchical model of the simulator is shown in FIG4 .

Figure 4 Schematic diagram of real-time task scheduling model in RUN() mode

Based on the above scheduling strategies, the task scheduling management module schedules each module in the following ways:

．Interrupt mode: When the overall task scheduler monitors the arrival of the highest message in the message queue, it immediately applies for a software interrupt, or when a hardware interrupt is applied, the system immediately stops the currently executed task and performs the corresponding interrupt processing.

． Timing mode: After the real-time test starts, the timer sends a timing message every 25 ms to send the test case data to the MBI card.

． Message mode: Based on Win98 message passing mechanism, implemented by thread scheduling.

．Semaphore and global variable method: After the overall task scheduler monitors the semaphore or state change of the task start, it runs the task according to the task level.

According to the system task scheduling management method, the processing level of task messages is divided into three priorities:

① Highest level message: This type of message requires the system to respond immediately. Modules with this type of priority are at the core of the system real-time simulation. This message is not queued in the Windows system message queue, but is directly sent to the corresponding application message queue for application processing. This can avoid uncontrolled message loops and ensure the timeliness of message processing.

[page]

② Clock-level message: The "timing time is up" message is generated by a precise timer. In normal testing, this message is the highest level. Clock-level messages are mainly allocated to data generation modules and driver modules in real-time testing.

③ Ordinary level messages: This type of message is mainly allocated to functional modules such as user interface modules and recording modules.

2.2.4 Real-time implementation technology of key functional modules of simulator

① Network communication module: The non-real-time part uses TCP/IP protocol for network transmission. The real-time part uses the method of setting up a network communication buffer area to partially achieve real-time communication of network transmission from the communication results. The key lies in the depth of the buffer. Or use VXD technology to directly perform transmission operations on the network card to avoid the defects of affecting the real-time performance of the system due to network delay.

②Display module: During the real-time test, the test data can be displayed through this module, and the user can control the test process. In real-time testing, the central task processing cycle is 25 ms, and other processing is required in the spare time of the task cycle. Therefore, in each 25 ms cycle, there is very little time left for the display task. In addition, since the human eye is less sensitive to data changes than 25 ms, displaying relevant data once every 50 ms or more can meet the needs of the system. In data display, text display takes up much less CPU processing time than graphic display. In graphic display, the use of high-performance graphics processing algorithms can ensure the real-time nature of graphics processing. In addition, with the improvement of graphics card hardware performance, under the condition that the performance of the graphics accelerator card is guaranteed, the system only needs to calculate the time that the graphics description statement occupies the CPU, and the time for graphics drawing can be ignored. The real-time display algorithm of graphics needs further research.

③ Cross-link data 1553B driver module: Since Win98 is in safe mode, the virtual memory address in Win98 is inconsistent with the actual physical address, and it is not easy for users to directly access the actual physical memory address and I/O port address of the hardware. In order to meet the needs of real-time driving of the MBI card, the WinDriver tool software is used to directly map the actual physical memory address and I/O address on the MBI card, and the hardware interrupt is virtualized. Using a series of functions generated by WinDriver to read and write memory and I/O port addresses, users can directly and quickly control the hardware. The experimental results show that when Win98 has a single application task, the speed at which users operate the MBI card is the same as that under DOS. The working principle of WinDriver is shown in Figure 5.

Figure 5 WinDriver working principle diagram

3 Conclusion

This paper takes the real-time test of the reliability of a certain aviation software as the background, and introduces the role of the simulator in the simulation test platform. According to the modular and expandable design ideas, the functional structure of the simulator is given; and the design idea of ​​the task scheduling management module of the simulator is introduced in detail. According to the specific tasks and system working modes, an integrated dynamic scheduling strategy is proposed; for the priority + level scheduling method, the principle of priority floating is adopted. In addition, the method of real-time network implementation is given, the feasibility of real-time graphic display is discussed, and WinDriver is used to realize the direct drive of the hardware MBI card under Win98. The experimental results show that the above scheduling ideas and related technologies are used in combination to meet the real-time nature of the simulator system.

* This project is supported by the National Defense Science and Technology "Ninth Five-Year" Key Pre-Research Project

References

[1] Cai Kaiyuan. Fundamentals of Software Reliability Engineering. Beijing: Tsinghua University Press, 1995

[2]Dunham JR Real-time Software Failure Characterization.IEEE AES Magazine,1990.11

[3]Kaneko H, Stankovic J A. A Multimedia Server on the Spring Real-time Systems Umass Computer Science Technical Report 96-11,1996.1

[4] Tang Rongxi. Computer Graphics Tutorial. Beijing: Science Press, 1994