- Email: [email protected]
Model-based Environment for Verification and Integration of Micro-satellites
19th IFAC Symposium on Automatic Control in Aerospace September 2-6, 2013. Würzburg, Germany
Model-based Environment for Verification and Integration of Micro-satellites T. Kuwahara, Y. Tomioka, K. Fukuda, N. Sugimura, Y. Sakamoto, K. Yoshida
Department of Aerospace Engineering, Tohoku University, Sendai, 980-8579 Japan (e-mail: {kuwahara, fukuda, tomioka, sakamoto, yoshida}@astro.mech.tohoku.ac.jp) Abstract: The Space Robotics Laboratory of Tohoku University has been developing multiples of microsatellites for years and has gathered experiences in their development, verification, integration, and operation. SRL has recently started development of model-based simulation, verification and integration environment to realize rapid and cost-effective development of reliable micro-satellites. The conceptual design and its functionality have been verified through the real-life micro-satellite project RISESAT, which is a 50kg class international scientific micro-satellite. The developed environment can be utilized in different configurations depending on requirements in each satellite development phase. This environment is designed to be modular and very flexible and can be utilized for other micro-satellites and possibly even much smaller space system projects in the future. Keywords: Micro-satellite, Assembly Integration and Test, Mission Control and Operation
recent miniaturization of satellite on-board equipment and performance improvement of payload instruments, as well as their unknown detailed operational conditions at the initial design phase – due to the fact that micro-satellites are usually launched in piggy-back launch opportunities – makes the development troublesome and time-consuming. Indeed, SRL has experienced that development and verification of 50kgclass micro-satellites at academic institution takes well more than three years, which cannot really be regarded as rapid. Also, longer development time means higher development cost. Therefore SRL has started investigations on possible improvements of design, development, and verification activities if micro-satellites. The main troubles usually one faces are followings:
1. INTRODUCTION The Space Robotics Laboratory (SRL) of Tohoku University has been very active in the field of small satellite development for years. Tohoku University has successfully developed, launched, and operated its first scientific microsatellite SPRITE-SAT (renamed as RISING-1 after the launch), CubeSat RAIKO, and is completing the second and third micro-satellites RISING-2 (Takahashi 2010, Fukuda 2011, Kuwahara 2011a, Yoshida 2011) and RISESAT (Kuwahara 2011b). Especially, the RISESAT (Rapid International Scientific Experiment Satellite) is a 50kg class international scientific micro-satellite and aims to demonstrate rapid and cost-effective access to space for scientific instruments. According to this background, SRL has recently started an investigation on software-assisted development, verification, and integration environment for micro-satellites to realize rapid and cost-effective development of reliable micro-satellite systems. This environment is named as MEVIμS: Model-based Environment for Verification and Integration of μ-Satellites. This project shall contribute to enhance the activities of world’s small satellite research societies and industries, and to build the basis of new paradigm for the future, where costeffective and reliable small satellites are widely utilized for both research and business purposes. This paper summarizes the design concept of this environment, results of initial functional verification, and future plan of extensions.
2. Concept of Rapid and Cost-effective Development
2.1 Time and Effort Consuming Problems It is often the case that micro-satellites are regarded as small and simple space systems which are easier to design, develop and test relative to traditional larger space systems. However, 978-3-902823-46-5/2013 © IFAC
230
The development of on-board flight software can only be started when the engineering model of the computer is available. This is usually almost in the middle of the project phase. The remaining time before launch is not enough for full verification, which consequently reduces the reliability of the system. If the development of flight software can be started just after the project initiation, the development time can be reduced and higher system reliability can be achieved. It is difficult to evaluate functionalities of attitude control system on ground. This sometimes leads to faulty performance of the system in orbit and even to false programming of polarities of attitude control sensors and actuators. If ground verification is possible, useless risks can be avoided beforehand. It is often very difficult to run long-term running test with the power control equipment integrated to the satellite system. Failures inside power supply system can directly trigger mission loss. For meaningful verification of this subject, one requires to simulate orbital environment in different operational conditions, including temperature variances. 10.3182/20130902-5-DE-2040.00142
2013 IFAC ACA September 2-6, 2013. Würzburg, Germany
Fig. 1. Conceptual Architecture Design of Model-based Simulation, Verification, and Integration Environment computer inside the simulator can execute the software codes which shall be portable to real hardware equipment. Software models of attitude control sensors and actuators are also implemented in the environment, so that the correct functionality of the attitude control algorithms can be evaluated. These attitude component models can be also replaced with real hardware in the later development phase. As illustrated in the figure, this environment starts from fullsoftware configuration and grows up to flat-sat configuration. Also it has the capability to be integrated with dynamic closed loop simulator at the final stage, which is also under development at SRL. Model-based development approach also has a merit that the developed models can be re-utilized for other projects just like one uses the same flight hardware for different satellite applications. The detail of each configuration is described in following chapter.
2.2 Model-based Simulation, Verification, and Integration In order to solve above mentioned problems, SRL started conceptual design of a model-based simulation, verification, and integration environment for micro-satellites. This environment shall support development activities all the way from the very beginning of the project even down to the real operation. The system diagram is illustrated in Fig. 1. This architecture is based on model-based object-oriented software simulation environment. The satellite system is simulated as a sum of individual component models, which can be replaced with the real hardware model without major changes in program codes in the later phases. Software simulated models (components) and real hardware models shall be able to be treated in the same level. The software simulated on-board 231
2013 IFAC ACA September 2-6, 2013. Würzburg, Germany
3.4 Dynamic Closed Loop Simulation Environment
3. Configuration of the Environment
In this configuration, a dynamic motion table is introduced and attitude control system sensors and actuators are mounted on this table. The commanding and telemetry monitoring are done via wireless communication, and the attitude of the table is determined observing motion sensors. Using this environment, the polarities of the sensors and actuators, as well as correct functionality of attitude control algorithms can be evaluated. A dynamic motion table is now under construction at the time of writing. It will be operational in the late spring 2013 and the progress will be included to the final paper.
3.1 Full-software Environment This is the initial configuration of the environment. The satellite model and orbital environment is simulated in the Satellite and Space Environment Simulator (SSES) application. Within the SSES, all individual satellite components including on-board computers are implemented in an object oriented manner so that they can be replace with real hardware equipment in later phase. The main On-board Computer (OBC) of the satellite is connected with the QuickLook (QL) application via socket connection. This QL is capable sending commands to and receiving telemetry from the OBC, and becomes the operation software after the launch of the satellite. These QL, SSES, and OBCs (more than one, if any) can be executed either on a single PC (configuration 1) or on multiple PCs (configuration 2,3) without any changes in source code. In this environment, the development of application level on-board software of OBCs can be started well ahead the development of the real hardware.
4. Implementation Results 4.1 Model-based Satellite and Space Environment Simulator The architecture of this environment shall be as simple and flexible as possible so that it can be utilized by a wide range of satellite projects in the future. As an example, the satellite system architecture of the SRL’s third micro-satellite RISESAT is illustrated in Fig. 2. In the figure, each sub system is classified with difference colours. RISESAT has three processor-based on-board computers: the Satellite Central Unit, the Attitude Control Unit, and the Science Handling Unit. (Power Control Unit does not have processor.) The configuration of the implemented software models of the RISESAT is illustrated in Fig. 3. The configuration of the software models, as well as the connections between them are simulated identical to the real hardware configuration. The connections between the models are represented by exchanging the pointers each other. For example, SCU possesses the pointer of ACU so that SCU can call methods defined inside the ACU model class. The QL is connected only with the SCU, which reflects the reality, and controls and monitors the satellite based on the real interface protocol defined in the specification. Besides the Satellite Class, there is also a Space Environment Class which holds all possible space environment classes, such as orbit propagation, attitude integration, geomagnetic field models, planet models etc. The satellite component models inherit Component Class as the base class, where the pointer of the Space Environment Class is implemented as static member. All component classes can have access to the environmental variables through this pointer.
3.2 OBC-in-the-loop Simulation Environment In this configuration, basic functionalities of the OBC are verified with the satellite component models in the SSES. The pre-developed software is integrated to real flight software which can be executed on the real machine. If there are more than one OBC, arbitral unit can be either simulated inside the SSES, or their hardware can be attached to SSES. At the initial phase, the communication between OBCs and SSES can be implemented by using debug ports, or by real interface hardware. For dealing with the real hardware interface, a modular front-end will be introduced. 3.3 Static Closed Loop Simulation Environment In this configuration, OBCs are connected with SSES via their real hardware interface. Data handling performance, functionality of ACS algorithms, and test and operating procedures can be developed and verified. In this configuration, the software on OBCs becomes identical to the flight software. The additional options of this configuration are the Power Supply System (PSS) in the loop simulation (III’), and Communication system in the loop simulation (III’’). The real Power Control Unit (PCU) is connected with the separation switches, real battery, and the simulated solar power source. The output of this solar simulator is controlled according to the calculation result of SSES depending on the orbital position, satellite attitude, and temperature of solar cells, etc.
4.2 Implementation of OBC Model The OBC model of the SSES is designed in the way that the socket interface of QL remains the same to all three configurations illustrated in Fig. 4. In the real operation, the QL is connected with the CMD/TLM server via socket interface. This can be replaced with socket interface directly with the OBC model. OBC model can be executed either inside the SSES or outside as stand-alone configuration. This helps to distribute the computational load to multiple PCs to ensure real-time performance.
If the communication system is also in the loop, the QL is connected with the CMD/TLM server, which forward commands and telemetry data to and from the main OBC via real RF equipment.
232
2013 IFAC ACA September 2-6, 2013. Würzburg, Germany
Fig. 2. Satellite System Architecture of RISESAT
Fig. 3. Software Model of RISESAT inside SSES
Fig. 4. OBC Model Implementation
This implementation is based on the assumption that the communication speed between the SSES and the modular front-end can be fast enough to ensure real-time simulation capability. This is however a very realistic assumption because the computational frequency of the on-board computer is, at least in the case of SRL’s micro-satellites, 10Hz at the maximum. Also, the PXI system is running on real-time OS with a controllable time steps of 1μs. This approach using commercially available electrical equipment makes the system quite simple and highly available.
4.3 Interface between SSES and Hardware Components In the configuration III and IV in Fig. 1, the OBCs shall be connected with the SSES. This interface between SSES and real hardware components are established by means of modular front-end based on PXI system of National Instruments. Modular front-end communicates with the SSES through socket to imitate the hardware interfaces of peripheral equipment of OBCs. This data transfer mechanism is implemented in an individual manner for all satellite components, as illustrated in Fig. 5. 233
2013 IFAC ACA September 2-6, 2013. Würzburg, Germany
Fig. 6. RISESAT Engineering Model and Development Environment
Fig. 5. OBC Model Implementation
4.4 Simulator Engine The simulator engine is designed to be executed with a frequency of 20Hz for simulated 1 second. This is to ensure the stable simulation and to reduce the latency of data delivered to hardware components. In each execution loop, the simulator updates the space environment at first, then updates the output variables of sensor models, and finally executes commands delivered to each component models. The common functionalities of component models such as variable update or command execution are implemented as virtual method of the Component Class, and each derived class implements its own custom functionalities on it. In this way, the simulator engine can access these common methods by identical function call.
Fig. 7. User Interfaces of MEVIμS
4.5 User Interfaces
It is also worth mentioning that the component model’s parameters are initialized based on the information summarized in a database. Component mass, consumption power, temperature range, etc. can be configured just by modifying information in the database. Moreover, the exact component model can be selected among several possible candidates in the same way. Provided that there are several different types of reaction wheels with different physical and performance characteristics, one can select a reaction wheel among them which shall be actually implemented inside the satellite, by configuring the parameter inside the database. This feature is very useful in the sense that the simulation environment can be easily re-configured for each specific target satellite system.
The scenery of satellite development and verification (RISESAT project) is shown in Fig. 6 and the user interfaces of MEVIμS are illustrated in Fig. 7. The QL, SSES, SSESQL (SSES control software), and 3D viewer are all in-house development at SRL. The contents of the QL are inheriting the experience gathered by the first micro-satellite project RISING-1. Actually there were several pieces of satellite verification setups developed for former satellites at SRL, and MEVIμS integrates all these instruments and facilities into single powerful environment. The engineering model illustrated in Fig. 6 is connected with solar simulator in PSS in the loop configuration (III’) for power cycling verification, and the main OBC is connected with the QL through real communication equipment in Communication system in the loop configuration (III’’).
The simulator engine is also capable of running accelerated and decelerated simulations depending on the simulation requirements. Therefore, one can use this simulation environment for operational planning by taking all possible operational conditions into account. This feature is very helpful when QL is used as real operational software.
The functionality and design concept of the MEVIμS is now under verification by being applied to RISESAT project, and will be further improved for future applications.
234
2013 IFAC ACA September 2-6, 2013. Würzburg, Germany
4.6 DCLS Environment
REFERENCES Fukuda, K., Nakano, T., Sakamoto, Y., Kuwahara, T., Yoshida, K., and Takahashi, Y. (2011). Attitude control system of micro satellite RISING-2, Proceedings of 8th Symposium on Small Satellites for Earth Observation, Berlin, pp.206-213. Kuwahara, T., Sakamoto, Y., Yoshida K., Takahashi, Y., Fukuhara, T., and Kurihara J. (2011a). Mission and system of the Earth observation microsatellite RISING-2, Proceedings of 8th Symposium on Small Satellites for Earth Observation, Berlin, pp.512-519. Kuwahara, T., Yoshida, K., Sakamoto, Y., Tomioka, Y., and Fukuda, K. (2011b). Satellite system integration based on space plug and play avionics, Proceedings of International Symposium on System Integration, Sendai, pp.896-901
SRL is now also developing a dynamic closed loop simulation environment for the verification of fine attitude control system of RISESAT. RISESAT is equipped with an 5m GSD high-precision telescope and a laser communication transmitter. For this reason, the requirement of the attitude control system of the RISESAT is quite high relative to former micro-satellites developed at SRL. The attitude control system of the RISESAT will be tested using this DCLS verification environment before the launch. In the final paper, an update on this topic will be also provided. 6. CONCLUSIONS AND OUTLOOK This paper summarized results of conceptual design and functional verification of the model-based simulation, verification, and integration environment of micro-satellites, named MEVIμS, developed at Space Robotics Laboratory of Tohoku University. The different possible configuration of the environment were summarized at the beginning, followed by implementation method of model-based satellite and space environment simulator, as well as exemplary real-life application to RISESAT project. Through the development activity of the RISESAT project, the functionality of the MEVIμS has been evaluated. The environment will be extended with dynamic closed simulation capability in the future. MEVIμS will realize rapid and cost-effective development and verification scheme for achieving reliable space systems and their safe operations.
Kuwahara, T., Yoshida, K., Sakamoto, Y., Tomioka, Y., and Fukuda, K. (2011b). Satellite system integration based on space plug and play avionics, Proceedings of International Symposium on System Integration, Sendai, pp.896-901 Takahashi, Y., Yoshida, K., Sakamoto, Y., and Sakanoi, T. (2010). SPRITE-SAT: A university small satellite for observation of high-altitude luminous events, Small Satellite Missions for Earth Observation: New Developments and Trends, Springer, pp.197-206. Wie, B. (2008). Space Vehicle Dynamics and Control, AIAA, Inc., Reston. Yoshida, K., Sakamoto, Y., Kuwahara,T., and Takahashi, Y. (2011) A series of 50kg-class micro-satellites for advanced science missions, Proceedings of 8th Symposium on Small Satellites for Earth Observation, Berlin, pp.99-106.
ACKNOWLEDGEMENT This research was supported by Grant-in-Aid for Scientific Research on Innovative Areas KAKENHI:24760658 from the Ministry of Education, Culture, Sports, Science and Technology of Japan and 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)," initiated by the Council for Science and Technology Policy (CSTP).
235
Model-based Environment for Verification and Integration of Micro-satellites T. Kuwahara, Y. Tomioka, K. Fukuda, N. Sugimura, Y. Sakamoto, K. Yoshida
Department of Aerospace Engineering, Tohoku University, Sendai, 980-8579 Japan (e-mail: {kuwahara, fukuda, tomioka, sakamoto, yoshida}@astro.mech.tohoku.ac.jp) Abstract: The Space Robotics Laboratory of Tohoku University has been developing multiples of microsatellites for years and has gathered experiences in their development, verification, integration, and operation. SRL has recently started development of model-based simulation, verification and integration environment to realize rapid and cost-effective development of reliable micro-satellites. The conceptual design and its functionality have been verified through the real-life micro-satellite project RISESAT, which is a 50kg class international scientific micro-satellite. The developed environment can be utilized in different configurations depending on requirements in each satellite development phase. This environment is designed to be modular and very flexible and can be utilized for other micro-satellites and possibly even much smaller space system projects in the future. Keywords: Micro-satellite, Assembly Integration and Test, Mission Control and Operation
recent miniaturization of satellite on-board equipment and performance improvement of payload instruments, as well as their unknown detailed operational conditions at the initial design phase – due to the fact that micro-satellites are usually launched in piggy-back launch opportunities – makes the development troublesome and time-consuming. Indeed, SRL has experienced that development and verification of 50kgclass micro-satellites at academic institution takes well more than three years, which cannot really be regarded as rapid. Also, longer development time means higher development cost. Therefore SRL has started investigations on possible improvements of design, development, and verification activities if micro-satellites. The main troubles usually one faces are followings:
1. INTRODUCTION The Space Robotics Laboratory (SRL) of Tohoku University has been very active in the field of small satellite development for years. Tohoku University has successfully developed, launched, and operated its first scientific microsatellite SPRITE-SAT (renamed as RISING-1 after the launch), CubeSat RAIKO, and is completing the second and third micro-satellites RISING-2 (Takahashi 2010, Fukuda 2011, Kuwahara 2011a, Yoshida 2011) and RISESAT (Kuwahara 2011b). Especially, the RISESAT (Rapid International Scientific Experiment Satellite) is a 50kg class international scientific micro-satellite and aims to demonstrate rapid and cost-effective access to space for scientific instruments. According to this background, SRL has recently started an investigation on software-assisted development, verification, and integration environment for micro-satellites to realize rapid and cost-effective development of reliable micro-satellite systems. This environment is named as MEVIμS: Model-based Environment for Verification and Integration of μ-Satellites. This project shall contribute to enhance the activities of world’s small satellite research societies and industries, and to build the basis of new paradigm for the future, where costeffective and reliable small satellites are widely utilized for both research and business purposes. This paper summarizes the design concept of this environment, results of initial functional verification, and future plan of extensions.
2. Concept of Rapid and Cost-effective Development
2.1 Time and Effort Consuming Problems It is often the case that micro-satellites are regarded as small and simple space systems which are easier to design, develop and test relative to traditional larger space systems. However, 978-3-902823-46-5/2013 © IFAC
230
The development of on-board flight software can only be started when the engineering model of the computer is available. This is usually almost in the middle of the project phase. The remaining time before launch is not enough for full verification, which consequently reduces the reliability of the system. If the development of flight software can be started just after the project initiation, the development time can be reduced and higher system reliability can be achieved. It is difficult to evaluate functionalities of attitude control system on ground. This sometimes leads to faulty performance of the system in orbit and even to false programming of polarities of attitude control sensors and actuators. If ground verification is possible, useless risks can be avoided beforehand. It is often very difficult to run long-term running test with the power control equipment integrated to the satellite system. Failures inside power supply system can directly trigger mission loss. For meaningful verification of this subject, one requires to simulate orbital environment in different operational conditions, including temperature variances. 10.3182/20130902-5-DE-2040.00142
2013 IFAC ACA September 2-6, 2013. Würzburg, Germany
Fig. 1. Conceptual Architecture Design of Model-based Simulation, Verification, and Integration Environment computer inside the simulator can execute the software codes which shall be portable to real hardware equipment. Software models of attitude control sensors and actuators are also implemented in the environment, so that the correct functionality of the attitude control algorithms can be evaluated. These attitude component models can be also replaced with real hardware in the later development phase. As illustrated in the figure, this environment starts from fullsoftware configuration and grows up to flat-sat configuration. Also it has the capability to be integrated with dynamic closed loop simulator at the final stage, which is also under development at SRL. Model-based development approach also has a merit that the developed models can be re-utilized for other projects just like one uses the same flight hardware for different satellite applications. The detail of each configuration is described in following chapter.
2.2 Model-based Simulation, Verification, and Integration In order to solve above mentioned problems, SRL started conceptual design of a model-based simulation, verification, and integration environment for micro-satellites. This environment shall support development activities all the way from the very beginning of the project even down to the real operation. The system diagram is illustrated in Fig. 1. This architecture is based on model-based object-oriented software simulation environment. The satellite system is simulated as a sum of individual component models, which can be replaced with the real hardware model without major changes in program codes in the later phases. Software simulated models (components) and real hardware models shall be able to be treated in the same level. The software simulated on-board 231
2013 IFAC ACA September 2-6, 2013. Würzburg, Germany
3.4 Dynamic Closed Loop Simulation Environment
3. Configuration of the Environment
In this configuration, a dynamic motion table is introduced and attitude control system sensors and actuators are mounted on this table. The commanding and telemetry monitoring are done via wireless communication, and the attitude of the table is determined observing motion sensors. Using this environment, the polarities of the sensors and actuators, as well as correct functionality of attitude control algorithms can be evaluated. A dynamic motion table is now under construction at the time of writing. It will be operational in the late spring 2013 and the progress will be included to the final paper.
3.1 Full-software Environment This is the initial configuration of the environment. The satellite model and orbital environment is simulated in the Satellite and Space Environment Simulator (SSES) application. Within the SSES, all individual satellite components including on-board computers are implemented in an object oriented manner so that they can be replace with real hardware equipment in later phase. The main On-board Computer (OBC) of the satellite is connected with the QuickLook (QL) application via socket connection. This QL is capable sending commands to and receiving telemetry from the OBC, and becomes the operation software after the launch of the satellite. These QL, SSES, and OBCs (more than one, if any) can be executed either on a single PC (configuration 1) or on multiple PCs (configuration 2,3) without any changes in source code. In this environment, the development of application level on-board software of OBCs can be started well ahead the development of the real hardware.
4. Implementation Results 4.1 Model-based Satellite and Space Environment Simulator The architecture of this environment shall be as simple and flexible as possible so that it can be utilized by a wide range of satellite projects in the future. As an example, the satellite system architecture of the SRL’s third micro-satellite RISESAT is illustrated in Fig. 2. In the figure, each sub system is classified with difference colours. RISESAT has three processor-based on-board computers: the Satellite Central Unit, the Attitude Control Unit, and the Science Handling Unit. (Power Control Unit does not have processor.) The configuration of the implemented software models of the RISESAT is illustrated in Fig. 3. The configuration of the software models, as well as the connections between them are simulated identical to the real hardware configuration. The connections between the models are represented by exchanging the pointers each other. For example, SCU possesses the pointer of ACU so that SCU can call methods defined inside the ACU model class. The QL is connected only with the SCU, which reflects the reality, and controls and monitors the satellite based on the real interface protocol defined in the specification. Besides the Satellite Class, there is also a Space Environment Class which holds all possible space environment classes, such as orbit propagation, attitude integration, geomagnetic field models, planet models etc. The satellite component models inherit Component Class as the base class, where the pointer of the Space Environment Class is implemented as static member. All component classes can have access to the environmental variables through this pointer.
3.2 OBC-in-the-loop Simulation Environment In this configuration, basic functionalities of the OBC are verified with the satellite component models in the SSES. The pre-developed software is integrated to real flight software which can be executed on the real machine. If there are more than one OBC, arbitral unit can be either simulated inside the SSES, or their hardware can be attached to SSES. At the initial phase, the communication between OBCs and SSES can be implemented by using debug ports, or by real interface hardware. For dealing with the real hardware interface, a modular front-end will be introduced. 3.3 Static Closed Loop Simulation Environment In this configuration, OBCs are connected with SSES via their real hardware interface. Data handling performance, functionality of ACS algorithms, and test and operating procedures can be developed and verified. In this configuration, the software on OBCs becomes identical to the flight software. The additional options of this configuration are the Power Supply System (PSS) in the loop simulation (III’), and Communication system in the loop simulation (III’’). The real Power Control Unit (PCU) is connected with the separation switches, real battery, and the simulated solar power source. The output of this solar simulator is controlled according to the calculation result of SSES depending on the orbital position, satellite attitude, and temperature of solar cells, etc.
4.2 Implementation of OBC Model The OBC model of the SSES is designed in the way that the socket interface of QL remains the same to all three configurations illustrated in Fig. 4. In the real operation, the QL is connected with the CMD/TLM server via socket interface. This can be replaced with socket interface directly with the OBC model. OBC model can be executed either inside the SSES or outside as stand-alone configuration. This helps to distribute the computational load to multiple PCs to ensure real-time performance.
If the communication system is also in the loop, the QL is connected with the CMD/TLM server, which forward commands and telemetry data to and from the main OBC via real RF equipment.
232
2013 IFAC ACA September 2-6, 2013. Würzburg, Germany
Fig. 2. Satellite System Architecture of RISESAT
Fig. 3. Software Model of RISESAT inside SSES
Fig. 4. OBC Model Implementation
This implementation is based on the assumption that the communication speed between the SSES and the modular front-end can be fast enough to ensure real-time simulation capability. This is however a very realistic assumption because the computational frequency of the on-board computer is, at least in the case of SRL’s micro-satellites, 10Hz at the maximum. Also, the PXI system is running on real-time OS with a controllable time steps of 1μs. This approach using commercially available electrical equipment makes the system quite simple and highly available.
4.3 Interface between SSES and Hardware Components In the configuration III and IV in Fig. 1, the OBCs shall be connected with the SSES. This interface between SSES and real hardware components are established by means of modular front-end based on PXI system of National Instruments. Modular front-end communicates with the SSES through socket to imitate the hardware interfaces of peripheral equipment of OBCs. This data transfer mechanism is implemented in an individual manner for all satellite components, as illustrated in Fig. 5. 233
2013 IFAC ACA September 2-6, 2013. Würzburg, Germany
Fig. 6. RISESAT Engineering Model and Development Environment
Fig. 5. OBC Model Implementation
4.4 Simulator Engine The simulator engine is designed to be executed with a frequency of 20Hz for simulated 1 second. This is to ensure the stable simulation and to reduce the latency of data delivered to hardware components. In each execution loop, the simulator updates the space environment at first, then updates the output variables of sensor models, and finally executes commands delivered to each component models. The common functionalities of component models such as variable update or command execution are implemented as virtual method of the Component Class, and each derived class implements its own custom functionalities on it. In this way, the simulator engine can access these common methods by identical function call.
Fig. 7. User Interfaces of MEVIμS
4.5 User Interfaces
It is also worth mentioning that the component model’s parameters are initialized based on the information summarized in a database. Component mass, consumption power, temperature range, etc. can be configured just by modifying information in the database. Moreover, the exact component model can be selected among several possible candidates in the same way. Provided that there are several different types of reaction wheels with different physical and performance characteristics, one can select a reaction wheel among them which shall be actually implemented inside the satellite, by configuring the parameter inside the database. This feature is very useful in the sense that the simulation environment can be easily re-configured for each specific target satellite system.
The scenery of satellite development and verification (RISESAT project) is shown in Fig. 6 and the user interfaces of MEVIμS are illustrated in Fig. 7. The QL, SSES, SSESQL (SSES control software), and 3D viewer are all in-house development at SRL. The contents of the QL are inheriting the experience gathered by the first micro-satellite project RISING-1. Actually there were several pieces of satellite verification setups developed for former satellites at SRL, and MEVIμS integrates all these instruments and facilities into single powerful environment. The engineering model illustrated in Fig. 6 is connected with solar simulator in PSS in the loop configuration (III’) for power cycling verification, and the main OBC is connected with the QL through real communication equipment in Communication system in the loop configuration (III’’).
The simulator engine is also capable of running accelerated and decelerated simulations depending on the simulation requirements. Therefore, one can use this simulation environment for operational planning by taking all possible operational conditions into account. This feature is very helpful when QL is used as real operational software.
The functionality and design concept of the MEVIμS is now under verification by being applied to RISESAT project, and will be further improved for future applications.
234
2013 IFAC ACA September 2-6, 2013. Würzburg, Germany
4.6 DCLS Environment
REFERENCES Fukuda, K., Nakano, T., Sakamoto, Y., Kuwahara, T., Yoshida, K., and Takahashi, Y. (2011). Attitude control system of micro satellite RISING-2, Proceedings of 8th Symposium on Small Satellites for Earth Observation, Berlin, pp.206-213. Kuwahara, T., Sakamoto, Y., Yoshida K., Takahashi, Y., Fukuhara, T., and Kurihara J. (2011a). Mission and system of the Earth observation microsatellite RISING-2, Proceedings of 8th Symposium on Small Satellites for Earth Observation, Berlin, pp.512-519. Kuwahara, T., Yoshida, K., Sakamoto, Y., Tomioka, Y., and Fukuda, K. (2011b). Satellite system integration based on space plug and play avionics, Proceedings of International Symposium on System Integration, Sendai, pp.896-901
SRL is now also developing a dynamic closed loop simulation environment for the verification of fine attitude control system of RISESAT. RISESAT is equipped with an 5m GSD high-precision telescope and a laser communication transmitter. For this reason, the requirement of the attitude control system of the RISESAT is quite high relative to former micro-satellites developed at SRL. The attitude control system of the RISESAT will be tested using this DCLS verification environment before the launch. In the final paper, an update on this topic will be also provided. 6. CONCLUSIONS AND OUTLOOK This paper summarized results of conceptual design and functional verification of the model-based simulation, verification, and integration environment of micro-satellites, named MEVIμS, developed at Space Robotics Laboratory of Tohoku University. The different possible configuration of the environment were summarized at the beginning, followed by implementation method of model-based satellite and space environment simulator, as well as exemplary real-life application to RISESAT project. Through the development activity of the RISESAT project, the functionality of the MEVIμS has been evaluated. The environment will be extended with dynamic closed simulation capability in the future. MEVIμS will realize rapid and cost-effective development and verification scheme for achieving reliable space systems and their safe operations.
Kuwahara, T., Yoshida, K., Sakamoto, Y., Tomioka, Y., and Fukuda, K. (2011b). Satellite system integration based on space plug and play avionics, Proceedings of International Symposium on System Integration, Sendai, pp.896-901 Takahashi, Y., Yoshida, K., Sakamoto, Y., and Sakanoi, T. (2010). SPRITE-SAT: A university small satellite for observation of high-altitude luminous events, Small Satellite Missions for Earth Observation: New Developments and Trends, Springer, pp.197-206. Wie, B. (2008). Space Vehicle Dynamics and Control, AIAA, Inc., Reston. Yoshida, K., Sakamoto, Y., Kuwahara,T., and Takahashi, Y. (2011) A series of 50kg-class micro-satellites for advanced science missions, Proceedings of 8th Symposium on Small Satellites for Earth Observation, Berlin, pp.99-106.
ACKNOWLEDGEMENT This research was supported by Grant-in-Aid for Scientific Research on Innovative Areas KAKENHI:24760658 from the Ministry of Education, Culture, Sports, Science and Technology of Japan and 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)," initiated by the Council for Science and Technology Policy (CSTP).
235