A class-structured software development platform for on-board computers of small satellites

Transcription

1 A class-structured software development platform for on-board computers of small satellites Takaichi Kamijo*, Yuhei Aoki*, Sotaro Kobayashi*, Shinichi Kimura* *Department of Electrical Engineering, Tokyo University of Science, Japan { kamijo@, aoki@, kobayashi@ } kimura-lab.net, [email protected] ABSTRACT With the increasing complexity of missions involving small satellites, high performance and high reliability are more important for the on-board computers. To meet these requirements, both hardware and software are required to have high reliability, high complexity, and high productivity. Generally, recursive operation and verification are efficient ways to increase software reliability and productivity. Because missions are highly specialized for individual spacecraft, software for on-orbit computers was developed for individual missions. Even though whole sequences may be specialized for each mission if they are divided into basic functional units, common units can be identified. Therefore we propose to develop a software recursive use of software for the on-orbit computers. In this paper, we introduce the outline of a software development and verification framework. 1. Introduction With the increasing complexity of missions involving small satellites, high performance and high reliability are more important for the on-board computers [1]~[3]. To meet these requirements, high reliability, high complexity and high productivity are required for both the hardware and software systems. Generally, recursive operation and verification are efficient ways of increasing software reliability and productivity. Because missions are highly specialized for individual spacecraft, software for on-orbit computers was developed for individual missions. Even though whole sequences may be specialized for each mission, common units can be identified if they are divided into basic functional units, such as the equipment interface, ground communication, and attitude estimation. An effective verification process is also important to realize increased software reliability. In particular, for software used on spacecraft, verification using hardware models of the on-orbit computer is important to identify errors due to implementation and delicate hardwarespecific performance parameters such as timing. While it is difficult to simulate whole on-orbit environments using whole spacecraft hardware models, software on OBCs should be able to verify the performance prior to launch. Therefore we propose to develop a software recursive use of software for the on-orbit computers. A simultaneous reduction of the development cost and software overhead increases its importance because of the wide variety of small-satellite applications. With this framework, the software can be constructed using classstructured software modules without special knowledge of the hardware or detailed specifications of the operating system. Telemetry command and auto sequence software can be automatically developed from design documents. The same software development kit dynamically links with hardware in the loop simulator that performs space environment simulation and automatically generates sensor read outs, which are due to actuator commands in the given situation [4]~[5]. In addition to these features, the classified structure enables us top-down development of the on-board software. In this paper, we introduce the outline of a software recursive use of software for the on-orbit computers. 2. Hardware platform For the first hardware platform used in the software development and verification system, we selected smallsized SOI-SOC OBC (SOBC) for the small satellites of the Funding Program for World-Leading Innovative R&D on Science and Technology (FIRST Program). SOBC consists of three segments. There are the CPU board, IF board, and power board, as shown in Fig. 1. Fig. 2 shows a schematic structure of SOBC; the CPU board is the main processing unit, consisting of **M bytes RAM, **M bytes program flash memory, and an FPGA for the chipset and SOI-SOC processor. The SOI-SOC processor was developed for dual use in space and consumer applications, and has high radiation tolerance. The IF board consists of FPGAs and various types of line drivers. It functions as a translator between Space Wire and various types of interfaces. In contrast, the CPU board dedicated Space Wire as the interface, while the IF board is suitable for various interfaces depending on the applications, and acts as a translator for Space Wire. Because the CPU board obtains four Space Wire ports, it can utilize a maximum of four IF boards, and can easily expand its interface capability. The power board generates power from several CPU

2 board and IF board sources. Moreover, it performs the hardware function triggered by an external reset cue. Figure 1. SOBC Engineering Model Figure 2. Schematic Structure of SOBC 3. Software development system 3.1. Macroscopic structure The macroscopic structure of on-board software that is constructed using the software-development system is illustrated in Fig. 3. The software is constructed in four major levels, which are the (1) operating system level, (2) driver and middleware level, (3) SDK level, and (4) application level. The operating system performs basic functions such as memory access and task management. To meet those functions, we adopted the micro-itron-based real-time operating system. Micro-itron is a free and open source operating system that realizes millisecond-level realtime task management. The operating system level compensates for the difference in the CPU structure. The driver and middleware level functions as the physical level interface between the CPU and peripheral components. As mentioned in the previous section, the interface of SOBC can be customized using the IF board. Such a variation in the interface structure is compensated for by the FPGA that acts as a link between various kinds of interfaces and Space Wire. For the software, the driver and middleware level performs the setting and interface function of the FPGA. The SDK level realizes the interconnected applications and the driver and middleware level in an abstracted manner. The SDK level intermittently accesses the sensors, and the sensor data is converted into a generalized structured memory map. Applications can obtain sensor information by accessing a structured memory map, and the process is free from the hardware interface process of the peripheral equipment. When applications need to send commands to the peripheral equipment, there is an application request to call the generalized function. The SDK level translates the commands for transmission to the peripheral equipment with proper timing, and it compensates for hardware dependencies and timing issues. Other tasks performed at the SDK level include: 1) automatically dispatching commands and telemetries, 2) performing command frame extraction, error check, extraction of command codes and parameters, and transmission of user-defined command tables, which are generated from the operation document described below, 3) user-defined parameters in the operational document are packed into the telemetry frame by the SDK level and are automatically transmitted, and 4) it performs command and telemetry networking between on-board computers. Based on these three-level functions, at the application level, a user can create programs without considering the hardware structure and physical interface. The user program can obtain sensor information that accesses predefined parameters and can send a command to the actuator, which calls the predefined function. The sensor and actuator interfaces are abstracted into a generalized memory map and functions. Figure 3. Macroscopic Software Structure The software-development system is supplied as a software framework from the operating system level to the SDK level. The user can implement personalized software into the entry point of the software skeleton. This system supports three types of entry point time driven, command driven, and event driven. Time driven entry points are evoked at certain time intervals and are mainly utilized for real-time control, such as altitude control. Command driven entry points are triggered by commands from the ground or on-board computer networks. Event driven entry points are triggered by predefined conditions such as situations in which certain parameters are lower than a predefined threshold. Several entry points are predefined, such as a 50 ms interval time driven entry point and UVC event-driven

3 entry point, and users can also add their own entry points. Figure 6. GUI-based software development system Figure 4. Three Types of Entry Points 3.2. Class-structured software development Generally, the reliability of software increases when the software is recursively utilized and verified in various conditions. Even though OBC software is highly dependent on the specific satellite mission, it can be divided into functional modules. Common features are identified in the modules, which can then be categorized into common and individual parts. Therefore, OBC software is divided into functional modules and is categorized into class libraries. Using such class structures, the reliability is expected to increase by recursive utilization. These structures are also effective for the enhancement of software productivity, because software can easily be reconstructed by the combination of instances of classstructured modules depending on the differences in the satellite structure. Furthermore, we propose to develop a GUI-based software development system to increase software productivity. The GUI-based software development system is realized, and such class structures are combined with a GUI software-development environment. We have already achieved class-structured modules in SDK-level software tools, and plan to expand such structures for the application level part, and to establish class-structured libraries for satellite control Automatic Generation of software Command and telemetry signals are highly dependent on the satellite mission and on the users preferences. Moreover, command and telemetry codes will be added or modified during satellite development. When these additions or modifications are made, the onboard software needs to be updated to register these changes. These changes also have an effect on the ground operation systems, and have the potential to cause errors, such as human error. Therefore, a system that enables users to flexibly update command and telemetry codes for both the ground operation system and on-board software is desired. We developed a system database from operating documents, such as command definition tables. If a user writes the software entry point in a certain field of the command definition table, code generation software automatically extracts such information, and includes it in the on-board software. Similarly, a database generator can be used to build a ground operation system. By using such an automatic command generation system, we can reduce the software update load and the risks associated with human error, and increase the flexibility of the user in the development of the software. We hope to expand this automatic code-generation approach to other sections of the on-board software, such as fault detection, management functions, and autonomous sequences. Figure 5. Class Structure Concept of OBC Software Figure 7. Auto Code-Generation Process

4 4. Software verification system 4.1. Concept of software verification Software verification is essential to achieve software reliability. However, in some cases, fully software-based verification of basic logic may not be sufficient. In some types of software, it is expected that the software will be verified for sensitive performance parameters such as response timing. In future, we hope to verify the implementation process for actual on-board computers, and expect it to verify whether or not the implemented software should perform the same function as the logic-level simulation. To realize these requirements, the software should be verified under the actual condition in which it will be implemented in a real OBC. Even though such hardware-based verification can be realized using an assembled satellite model, the simulation condition is constrained by hardware limitations. Therefore, we developed hardware in a loop simulation as OBC software verification system. In this verification system, the performance and interface of the peripheral equipment are simulated by the PC simulator, the software can be verified in the realistic situation on the real OBC, and the user can verify the implementation process. Because the software runs in the real OBC, the sensitive timing performance and hardware performance are naturally included in the verification process. Since the PC simulator simulates external conditions, normal or non-normal simulating conditions can be easily set without hardware limitations. easy to modify the interface structure according to the satellite hardware structure. The interface software can be constructed by interlinking software blocks in a GUI manner, and the modules correspond to well-known sensors and actuators, including its interface and performance parameters. Users can easily construct their own simulation systems by dragging and dropping the component icons used in their own satellites. The hardware in the loop simulation is shown in Fig. 9. This simulation is able to verify various situations, such as some equipment errors. The attitude dynamics simulator and the orbital dynamics and environment simulator are constructed using C++ or MATLAB. Attitude dynamics are always simulated, whereas sensors and actuators are output according to the timing of the actual equipment. The front panel which served of the interface in LabVIEW is shown in Fig. 10. Users can extract the data and monitor the orbital and satellite status through this interface. The block diagram in LabVIEW is shown in Fig. 11. The graphical block set can be modified to change the function displayed in the front panel Software verification system architecture Figure 9. Hardware in the Loop Simulation Figure 8. Software verification system architecture Fig. 8 shows the software verification system architecture. NI-PXI is used to build the Software verification system and test the functions of the hardware and on-board software. In order to use the NI- PXI, we utilized LabVIEW [6]~[7], which is a GUIbased hardware interface control language that was developed by National Instruments. Because LabVIEW performs well in the modularization of functions, it is Figure 10. LabVIEW front panel

5 5. Conclusion Figure 11. LabVIEW block diagram This paper proposes a software development and verification framework that enhances the recursive use of software for on-orbit computers. This system is being utilized for the software development of the on-board computers in a series of small satellites, which were developed in the Funding Program for World-Leading Innovative R&D on Science and Technology (FIRST Program), and the first flight is scheduled for launch in The system effectively enhances the recursive utilization of software heritage in the satellite series. We hope to expand the system for the development of the series as well as other hardware platforms. Furthermore, we believe that many persons can easily develop satellite system using this framework. 3 Shinichi, K., Hitoshi, M., Hiroshi, Y., Yasufumi, N., Heihachiro, K., Satomi, K., Fuyuhiro, T., Shinichiro, N., Shinichi, N., Shinichi, U., Hidekazu, H., Nobuhiro, T. & Keisuke, Y. (2004). Preliminary Experiments ontechnologies for Satellite Orbital Maintenance Using Micro-LabSat 1, Advanced Robotics, Vol.18, No.2, pp Chong, C, Y., Yang, X, Z., Juang, J, C. & Miau, J, J. (2010). Development and verification of Microsatellite Attitude Control System by Processor-in-the-loop Method, 61th International Astronautical Congress, Prague. 5 Ambrosio, A, M., Guimaraes, D, C. & Barreto, J, P. (2007). Satellite Simulator Requirements Specification based on Standardized Space Services, Complex Systems Concurrent Engineering, part3, pp Ertugrul, N. (2000). Towards Virtual Laboratories: A Servey of LabVIEW-Based Teaching/Learning Tools and Future Trends, The Special Issue on Applications of LabVIEW in Engineering Education, International Journal of Engineering Education, No.16, Vol.3, pp Andreassen, O, O., Kudryavtsev, D., Raimondo, A., Rijllart, A., Shaipov, V. & Sorokoletov, R. (2011). THE LABVIEW RADE FRAMEWORK DISTRIBUTED ARCHITECTURE, ICALEPCS, Geneva, Switzerland. 6. Acknowledgments This research was supported by the Japan Society for the Promotion of Science (JSPS) through the Funding Program for World-Leading Innovative R&D on Science and Technology (FIRST Program), which was initiated by the Council for Science and Technology Policy (CSTP). Reference 1 Shinichi, K., Makoto, T., Koichi, H., Yutaro, F., Hitoshi, S., Tetsuji, Y., Akihiro, M., Hiroyuki, N., Kei, S. & Masanori, H. (2004). Visual Analysis in a Deployable Antenna Experiment using Sub-pixel Cross-correlation, IEEE Transactions on Aerospace and Electronic Systems. Vol.40, No.1, pp Shinichi, K., Yasufumi, N., Hiroshi, Y., Hiroshi, K., Sachiko, S., Shinobu, N., Kazumi, M. & Naohiko, A. (2006). Rendezvous Experiments on SmartSat-1, Space Mission Challenges for Information Technology (SMC-IT 2006), Pasadena, CA, USA, pp