Applying software-mathematical models of onboard equipment to develop onboard software

Introduction. Currently, spacecraft have a crucial role in providing consumers with communications, television broadcasting and navigation services. Depending on the purpose, spacecraft contain a specific set of onboard equipment. The problems solved by individual instruments determine the functioning and logic of the operation of individual systems and a spacecraft as a whole. To ensure a reliable uninterrupted operation [1] and automated management of emergency situations arising from the operation of onboard equipment, it is necessary to adjust the interaction with the software of the onboard integrated computing system of spacecraft [2; 3].

The development of onboard software. A spacecraft includes a number of target and auxiliary equipment (spacecraft systems), which is determined according to the purpose of a spacecraft. For all onboard equipment, specialists develop software as part of the onboard software, as well as software as a part of equipment ensuring the interaction of this equipment with the onboard control complex of a spacecraft.

Onboard software is a combination of the software of onboard systems operating in single hardware and software environment of the onboard integrated computing system of a spacecraft [4]. Each component of the onboard software is a functional part of its onboard system and, together with its hardware, solves the problems assigned to this onboard system.

There are many approaches to software development related to its design. The development, autonomous and system testing of onboard software are key stages of the lifecycle of a spacecraft [5], which provide the interaction and logic of functioning data and instruments within its systems.

Let us consider the standard cycle of the development of onboard software:

• 1)    defining the requirements to system software;

• 2)    developing the architectural design of system software;

• 3)    developing and autonomous testing of system software;

• 4)    system testing of system software in system modes;

• 5)    testing system software in spacecraft modes;

• 6)    fit testing of software and onboard equipment as part of a spacecraft at the stage of electrical and radio tests and flight tests;

• 7)    maintaining system software at the stage of normal operation.

If necessary, we return to the previous stages in the standard cycle of developing onboard software. In case of the successful completion of these stages we use the developed onboard software for work with spacecraft equipment and maintain the onboard software operation with the equipment in the spacecraft until the end of its active life. The onboard software architecture has the following form in general terms (fig. 1).

While developing the onboard software, it is necessary to conduct detailed testing of the interaction of software that is part of a spacecraft system and onboard equipment in order to detect errors before conducting integration tests of software and equipment as part of a spacecraft. Frequently, when errors are detected, changing the software of onboard equipment is no longer possible, since it may contain one-time programmable memories, or error correction may take much time, which leads to an increase in the duration of spacecraft testing. In this case, when abnormal situations occur, there is a possibility of correcting software failures of the onboard equipment from an onboard control complex by modifying its software.

The use of a mathematical software model. One of the ways to test software in the development of onboard software is to simulate the logic of the equipment by creating its software and mathematical model.

Software and mathematical model is a complex of the implemented logic of equipment operation in the form of a program code, through which we receive and transmit information when interacting with the onboard software.

When creating a software model of equipment, it is not necessary to have a high specification of the description of its internal structure and logic of functioning, but only to imitate those features of the equipment that are important from the point of view of its interaction with the external environment.

Fig. 2 shows the scheme of testing onboard software and software-mathematical model.

In the onboard software the logic of the interaction of equipment and the onboard control complex is implemented. The input information is the initial data, which contain the requirements for the development of onboard software.

The output information comprises the results of the stand-alone testing of the onboard software through debugging packages. The debug package is a pseudo-code for checking whether it is possible to achieve the execution of a certain branch of the logic of onboard software.

As a result of package debugging, we determine the execution time, the size of the stack used, the coverage of the logic of the executable program code.

The essence of the debugging of information interaction between the software-mathematical model and the onboard control complex is to check the reception and transmission of various types of information messages, such as control commands, telemetry information, onboard time, software arrays, receipts, etc. Information exchange between the equipment and the BUD is performed via a multiplex exchange channel according to GOST R 52070–2003 (ГОСТ Р 52070–2003) [6] in accordance with the protocol of information and logic interaction with this equipment, developed by the equipment manufacturer and agreed with the developer of the onboard software.

In case of the successful normal operation of the interaction between the onboard control complex and the software-mathematical model, we check the occurrence of abnormal situations in information exchange: hardware malfunctions, failures of the multiplex exchange channel, errors in information messages, temperature failures, failures in signal power, current strength, voltage and other malfunctions.

System testing on the ground debugging complex. The result of the procedures described above is the integration of the onboard software and the software-mathematical model with the aim of conducting system testing on the ground debugging complex [7; 8]. A ground testing complex is the integrated environment for testing the onboard software and the software-mathematical model instruments within a spacecraft. The testing of the interaction occurs by checking the execution of the program logic using sequence diagrams [9].

Fig. 1. Onboard software architecture

Рис. 1. Архитектура бортового программного обеспечения

Fig. 2. Testing of onboard software and of a software-mathematical model

Рис. 2. Отработка бортового программного обеспечения и программно-математической модели

A sequence diagram is a pseudo-code for system testing, based on a graphical formalized language describing the procedures and test options, allowing automating a testing process.

The result of this stage is the onboard software of the equipment, ready for testing in the spacecraft mode on the ground testing complex.

In addition, the ground testing complex has the ability to specify various initial data of the spacecraft operation, both in general and each spacecraft system in particular; that allows testing the onboard software for the whole set of its functionality. Fig. 3 shows the ground testing complex architecture.

Sample application for laboratory testing. Another way to test the onboard software is to use a laboratory testing sample [10; 11]. A laboratory testing sample is a special sample of equipment for testing, which is a prototype of standard equipment in terms of functionality and basic technical characteristics, on which we develop software and technical solutions. Such a product is cheaper than standard equipment and it is manufactured faster, therefore there is a possibility of the onboard software testing before the completion of the production of a standard sample. Fig. 4 shows the scheme for testing the interaction of onboard software with the laboratory testing sample.

Software environment

Fig. 3. Ground testing complex architecture

Рис. 3. Архитектура наземного отладочного комплекса

Fig. 4. Testing the interaction between onboard software and a laboratory testing sample unit

Рис. 4. Отработка взаимодействия бортового программного обеспечения с образцом для лабораторно-отработочных испытаний

Fig. 5. The general scheme of the development of onboard software with the application of a software-mathematical model, and laboratory testing sample unit

Рис. 5. Общая схема разработки БПО с использованием ПММ, образца ЛОИ

The input information is the logic of the functioning of the sample, which is governed by the requirements for the creation of an experimental product. The output information is the executable code of the onboard software for testing with the ground testing complex.

As part of the development of software interaction with the equipment, we conduct testing to check the standard and abnormal logic of the laboratory testing sample.

The result is a corrected logic of the equipment, which we take into account at further stages of the development of onboard software. Fig. 5 shows the proposed software development scheme for onboard spacecraft systems [12; 13].

The particularities of using a software-mathematical model and a laboratory testing sample. We develop the onboard software and the software-mathematical model in parallel, and we pair them with the help of software drivers.

The peculiarity of using the software-mathematical model is to simulate the logic of the equipment in both regular and abnormal situations in which there are predictable failures in information exchange between it and the onboard control complex [14; 15]. We perform testing of the docking of the onboard software and the software-mathematical model during the delivery of the software to the ground testing complex, which allows us to prevent errors in the logic of the functioning of the onboard software at subsequent stages.

The use of the laboratory testing sample contributes to the accurate reflection of the procedures for recording and reading information from the point of view of the logic of operation of the device.

Testing on the laboratory testing sample gives a complete picture of the logic of the equipment, the physical component of the equipment, the processor, the runtime and the number of operations for a given time, which allows us to work out the hardware software and onboard software. In this case, there is information about real-time execution of operations, making it possible to adjust the system resources in advance (allocated memory, execution time, pauses during operation, etc.).

The use of the laboratory testing sample allows to reduce the time for making changes to the code of the onboard software, since the introduction of changes at the system testing stage in spacecraft modes requires consistency in working with the developers of other systems. The laboratory testing sample serves as a prototype for design finishing test sample and preliminary test sample, we take into account the adjustments for the laboratory testing sample on the indicated samples.

The advantages of the described methods in the development of onboard software. The use of the proposed methodology for the development of system software, including direct interaction with the laboratory testing sample and the use of the software-mathematical model, contributes to the reduction of time and parity of errors in the development cycle, autonomous and system testing of software.

The benefits of using a software-mathematical model is to organize the development of regular and emergency situations in the flight control center, to provide training for operation personnel, which contributes to rapid response when such situations occur during the operation of products.

Conclusion. The need to develop and use a software-mathematical model to test the onboard software of spacecraft is determined by several factors. Firstly, with the help of the software-mathematical model at the NOC, we sreated and tested the sequence diagrams, which are later used in testing and final adjusting actual onboard equipment and spacecraft systems, which can significantly reduce the time required for software testing and final adjustment. Secondly, the development stages of software and hardware run in parallel, therefore the possi- bility of developing software with real hardware is not available. Consequently, there is a need for its software simulation. The use of a software-mathematical model when testing onboard software allows us to produce better and more complete development of the logic of the operation of the equipment and various emergency situations. Thirdly, it is necessary to envisage the possibility of making changes in the onboard software after launching the spacecraft, changes can be preliminarily worked out on software models of spacecraft systems before they are installed in the onboard integrated computing complex; that helps prevent emergency situations and increases the overall reliability of spacecraft.

The modified methodology for the development of onboard software is used in the development of software of systems in the process of the creation of the “Glonass-K” spacecraft.