**5. Onboard software architecture**

If onboard system monitor is implemented on flight software, it is necessary to consider what software architecture should be employed. Most hardware control tasks must run in a fixed time interval or by triggered as a response to an event while satisfying strict timing requirements. In other words, such a control task must run as a real-time task. On the other hand, system monitoring shown in previous sections does not have such limitations. Since timing requirements for hardware control and system monitoring are different, corresponding software should be implemented in different level of tasks.

To implement flight software clearly structured as multiple tasks running in parallel without unexpected mutual interventions, layered programming approach is suitable. Although there are many researches on this topic, the three-layer structure programming is considered in this chapter as basic software architecture (Rabideau et al., 1999). because such structure is simple, popular, and has a variety of applications even in space systems (Balzano & Isaacs, 2006). The architecture consists of a deliberator layer, an executor layer, and a driver layer as shown in Fig. 16. The driver layer manages data interfaces with hardware in a real-time manner by performing tasks, such as serial data port handling and interruption signal handling. This layer should be implemented to perform real-time tasks

Fig. 15. Classification results by the SVM generated using OK and NG data sets. The result using one month statistics case successfully detects all the changes in FOG bias drifts, while the 10 days statistics case have one false positive detection (miss detection of change in FOG bias).

If onboard system monitor is implemented on flight software, it is necessary to consider what software architecture should be employed. Most hardware control tasks must run in a fixed time interval or by triggered as a response to an event while satisfying strict timing requirements. In other words, such a control task must run as a real-time task. On the other hand, system monitoring shown in previous sections does not have such limitations. Since timing requirements for hardware control and system monitoring are different,

To implement flight software clearly structured as multiple tasks running in parallel without unexpected mutual interventions, layered programming approach is suitable. Although there are many researches on this topic, the three-layer structure programming is considered in this chapter as basic software architecture (Rabideau et al., 1999). because such structure is simple, popular, and has a variety of applications even in space systems (Balzano & Isaacs, 2006). The architecture consists of a deliberator layer, an executor layer, and a driver layer as shown in Fig. 16. The driver layer manages data interfaces with hardware in a real-time manner by performing tasks, such as serial data port handling and interruption signal handling. This layer should be implemented to perform real-time tasks

corresponding software should be implemented in different level of tasks.

**5. Onboard software architecture** 

on a real-time OS. The deliberator layer processes all the input data such as environment measurement data, hardware status data, and operation commands and determines the next action to be taken. The executor layer connects input and output data between the executor and driver layers by interpreting the stream of abstract data such as operator commands (for examples GO or STOP) into the hardware data stream (ON or OFF) and vice versa. It also manages the issue of commands, i.e., when and where to send the data.

Fig. 16. The three-layer architecture for remote system software consisting of Deliberator, Executor, and Driver functions.

A human operator at a remote station communicates with a remote system by telecomands (CMD) and telemetry (TLM). The operator reads TLM data to determine the event that has occurred at the remote system and then sends CMDs so that the system can operate as planned to achieve its mission goals, resulting in a human-in-the-loop control system. To make the remote system autonomous, the deliberator layer should behave in the same way as the human operator. If this can be achieved, the lower layers will act in the same way under both a human operator and autonomous control. If this situation can be realized, the system can be considered to have the ability to make its own decisions.

Here is an example to show how to implement such architecture in Fig. 17. The driver and executor layers is implemented as real-time tasks running on a real-time OS and the deliberator is implemented as a script engine running on the same OS so that it is easy to communicate between the three layers by an intertask communication mechanism provided by the OS kernel. The reason why a script engine is used on the deliberator layer is that it is expected that algorithms for system monitoring such as SVM should change its target according to operation purposes and circumstances of the system: many algorithms should be loaded to detect many potential failures throughout its mission. FOG bias drift detection was explained in this chapter, but it is not only possible trouble on onboard hardware. Using usual tasks programmed in C/C++, it is hard to change onboard algorithm for system monitoring after starting up the system. However, script engines seem to be an only option to change algorithm frequently. By changing the script, the algorithms can be changed without affecting other running tasks such as hardware controls.

Telemetry Data Mining with SVM for Satellite Monitoring 113

FOG bias drift means and how it can be estimated from telemetry data of attitude motion. Then, an SVM was designed and tested to monitor the instability of the FOGs in the REIMEI satellite using 2 years of telemetry data. The result shows that the SVM can detect changes in bias with a simple linear kernel. Thus, the classification part of the SVM logic can be implemented on the flight software without difficulty. As a hint for actual implementation

The flight software version of the SVM using a script engine has not yet been tested in the REIMEI satellite, and the author is waiting for an opportunity to carry out an in-flight experiment. It appears that SVMs can be used as a standard autonomous software component not only for onboard software even in small satellite systems but also for monitoring telemetry data. Thus, the author conducted an experiment to export this concept of system monitoring onto an autonomous underwater vehicle as concept verification activities and obtain sound results as it was expected. However, the most fruitful result

Balzano, V. & Zak, D. (2006). Event-drvien Jamses Space Webb Space Telescobe operations

Cristianini, R. & Shawe-Tylor, J. (2000). *An Introduction to Support Vector Machines,* Cambridge University Press, ISBN 978-052-870-19-3, Cambridge, UK Farrenkopf, R. L. (1978). Analytic steady-state accuracy solutions for two common spacecraft

Fukushima, Y. & Mita, M. (2011). A New Approach to Onboard Mission Replanning Using

Fukushima, Y. (2008). Onboard Sensor and Actuator Failure Detection using SVM for

Fukushima, Y.; Sakai, S. & Saito, K. (2006). Flight Performance of the REIMEI Microsatellite

Ninomiya, K.; Hasimoto, T.; Kii, T.; Muranaka, N.; Uo, M.; Maeda, K. & Saitoh, T. (1994). In-

Saito, H.; Mizuno, T.; Tanaka, K.; Sone, Y.; Fukuda, S.; Sakai, S.; Okuizumi, N.; Mita, M.;

*Annual AAS Rocky Mountain,* Keystone, CO, USA, February 2 – 6, 1994 Rabideau, G. ; Knight, R. ; Chien, S. ; Fukunaga, A. & Govindjee, A. (1999). Iterative Repair

*Advanced Intelligent Mechatronics*, Budapest, Hungary, July, 2011

ESA-SP-625, Sardignia, Italy, September, 2006

Noordwijk, The Netherlands, June, 1999

Fukuoka, Japan, 2005

using on-board JavaScripts, *Proceedings of SPIE,* 6274, 62740A, Orlando, FL, USA,

attitude estimators, *Journal of Guidance, Control, and Dynamics,* Vol.1, No.4, pp. 282-

Orthogonal Arrays, Proceedings of *2011 IEEE/ASME International Conference on* 

Autonomy of Small Satellite Systems. *Proceedings of the 9th International Symposium on Artificial Intelligence and Robotic Automation in Space,* Los Angels, CA, USA,

Attitude Determination System, *Proceedings of the Small Satellite Systems and Services*,

Orbit Performance of ASCA Satellite Attitude Control System, *Proceedings of 17th*

Planning for Spacecraft Operations in the ASPEN System, *Proceedings of 5th International Symposium on Artificial Intelligence, Robotics, and Automation in Space,*

Fukushima, Y.; Hirahara, M.; Asamura, K.; Sakanoi, T.; Miura, A.; Ikenaga, T. & Masumoto, Y. (2005). AN-OVERVIEW AND INITIAL IN-ORBIT STATUS OF "INDEX" SATELLITE, *56th International Astronautical Confernce*, IAC-05-B5.6.B.05,

onboard software, the three-layer architecture for onboard software was explained.

expected area seems to space systems and it is the final destination of this research.

**7. References** 

May 24, 2006

January, 2008

284, ISSN 0731-5090

The requirements of time and memory for a script engine to run with multiple real-time tasks have been too great for its realization on an actual onboard computer so far. However, owing to recent technical advances, such a script engine can be installed in a spacecraft project. The author recommends T-Kernel as the OS kernel, which is expected to become a standard real-time OS, and JavaScript as the script engine to run on T-Kernel (Fukushima & Mita, 2011). Figure 16 depicts the proposed software architecture.

Most space systems can accept such commands that a software internal variable should be substituted by some value like "a\_hardware\_switch = 1". With the proposed script engine, it is possible to send commands by another form: an expression of a logic such as "IF a variable = value THEN do something", i.e., a program fragment. If space systems can accept a logic-type command, the system will have the capability to self-update dynamically; a script code sent by a logic-type command can modify the prescribed behaviours of the system. So far, software updates have only been achieved by stopping and reloading the entire software or by applying memory data patches on the running software code, despite the concern that these methods of updating have some risk of corrupting the system. Thus, such logic-type commands are clearly advantageous for our proposed software architecture.

Fig. 17. A sample recommended implementation of the three-layer architecture for a remote system using a real-time OS with the deliberator that is realized by the help of a text-script engine, such as JavaScript, to provide onboard dynamic and self-update mechanism for users.
