Inglês (pdf)
Artigo em XML
Referências do artigo
Tradução automática
Enviar este artigo por email
Citado por SciELO 
Citado por Google 
Similares em
SciELO 
Similares em Google 
Permalink
I. INTRODUCTION
Currently, space missions face the challenge of releasing solutions with high-quality standards in short periods of time [1]. As a result, most space companies seek to improve their processes by developing devices with high-end hardware running a Software Development Kit (SDK) that contains the main common features across different satellites. It allow them to use the same products and software to reduce the development time and limits the development of the control software to meet the specific requirements of the mission [2]. GomSpace S/A is a manufacturer of nanosatellites with customers in sectors such as defense, academic, government and commercial markets. They manufacture devices like On-Board Computer (OBC) understood as the brain of the satellite [3], radio links, Attitude Determination And Control System (ADCS), “based on implementing the controller and sensor subsystems to monitor attitude determination” [4], and software integrations into the customer’s space mission requirements [1].
GomSpace products include software and hardware based on a CubeSat Space Protocol (CSP) that enables distributed embedded systems to deploy a service-oriented network topology. It is designed for embedded systems such as the 8-bit and 32-bit ARM/AVR microcontrollers from Atmel, designed for space segments in On-Board Computers and different subsystems with low power consumption. The implementation is written in C programing language and is ported to run on FreeRTOS, POSIX, and threads-based operating systems such as Linux for ground segments [1].
The Colombian Air Force (FAC by its Spanish acronym) developed an on-job training program based on a transfer of knowledge with the company GomSpace A/S. Their software/hardware environment were used to integrate an Inertial Measurement Unit as an external hardware device operated by the internal On-Board Computer. Thus, it was possible to share IMU’s features as measurement of acceleration and velocities rates across the CSP network in space to ground as a service from the OBC. This development is designed as a part of the FACSAT-2 program future space missions [2].
The software development to integrate a third-party hardware on a nanosatellite using GomSpace utilities is based on the A3200 command & management SDK designed for the NanoMind A3200 / AVR32 platform [5]. The ground segment uses the MS100 Command & Management SDK [6] running on a Linux server. These 2 segments communicate with a RF link through UHF AX100 radios on both, as any satellite in space will perform, thus allowing us to use different functionalities as telemetry from space to ground, performing IMU control, “remote monitoring and control of spacecraft subsystems and payloads” [7] as a regular satellite will operate.
II. METHODOLOGY
The development is given by a deductive methodology, organized in a step-by-step process, as described in Fig. 1.
A. Hardware Analysis
The development is based in two segments: space and ground. Each segment plays a crucial role in the overall functioning of the satellite system, and they must all work together seamlessly to ensure a successful operation of the satellites and the services they provide.
Space segment is composed by seven subsystems designed as normal nanosatellite with standard features, including one NanoCAM C1U as payload and one NanoMind A3200 as the main On-Board Computer, the subsystems are:
A3200 - OBC
A3200 - ADCS
P60 - EPS (2 extra nodes)
ACU - Solar panel control unit
PDU - Power distribution control unit
AX100 - UHF radio link Communication
NanoCAM - Payload
The NanoMind A3200 is the main computer on board. It is composed of a high performance AVR microcontroller equipped with flash devices and sensors. Fig. 2 shows a top view of the OBC A3200 and highlights its compact size and its two lateral connection ports for the AVR programmer, which can be used for GOSH or for KISS serial connection [5]. Its main function is to control and coordinate all subsystems on board the satellite, including the payload, communication and power systems [5]. In this research, the OBC controls and operates the IMU sensor to include their features to the satellite system.
1) IMU M-G364PDCA Hardware. The M-G364PDCA is a small form factor Inertial Measurement Unit (IMU) with 6 degrees of freedom, angular velocities, and triaxial linear accelerations. Additionally, it provides high stability and high precision measurement capabilities using high-accuracy offset technology. A variety of calibration parameters are stored in the IMU's memory and are automatically reflected in the measurement data sent to the application after the IMU is powered on. Fig. 3 shows the functional block diagram of the IMU M-G364PDCA [8].
2) Ground Segment. “A ground system supports the space segment … and relays to users mission data generated by onboard instruments and received from the space” [9]. The ground segment is composed of 01 UHF radio link AX100 subsystem controlled by a Linux server running the mission control software [6]. This tool is critical for managing and controlling satellites, some of the key functionalities of this software include:
Telemetry Data Processing: The software can collect, process, and analyze telemetry data transmitted by the satellite, thus providing important information about its health and status, and store it in a MongoDB for future access.
Commanding and Control: Mission control software can send commands to the satellite and adjust its functionalities or operating parameters as needed.
Payload Management: Satellite mission control software can manage the operation and performance of the satellite's payload, such as cameras, sensors, and scientific instruments.
Fault Detection and Diagnosis: The software can detect and diagnose faults in the satellite's systems and provide recommendations for corrective actions.
Communication Management: The software must manage the communication links between the satellite and the ground station, ensuring that data is transmitted and received correctly.
B. Software Analysis
Satellite systems require various types of software to perform different functions and support different subsystems, oriented by the ECSS standards, “ESA Council adopted a resolution that confirmed the Agency’s commitment to transferring the existing system of ESA space standards to a new set of standards that were to be prepared by the European Cooperation for Space Standardization (ECSS)” [10] [11]. This research aims to develop two key software components required for the satellite system:
Flight software: This software controls the behavior of the satellite in orbit and executes the various subsystem commands, including the IMU control and operation. “The FSW is responsible for the calculation of satellite position/orbit, operation of scientific instrument payload, and communication with ground antenna” [12]
Ground software: This software manages the communication between the satellite and the ground station, including data transmission, reception, and processing.
The flight software running in the OBC in this research focuses on controlling and operating the IMU features on the satellite system. Regarding software requirements, the IMU demands using SPI serial interface to access the control, data, and measurement parameters information; the read/write operations must be programed on the OBC for the satellite system to have full access.
The IMU starts immediately after a hardware restart or power-up, the hardware begins internal initialization; at that moment, all the values of the registers and states of the external pins are not defined. Once it is completed, the device goes into configuration mode; then, it is possible to adjust the operating values of the IMU. When the configuration is completed, it switches to sampling mode to read the temperature, angular velocity, and acceleration data in all three axes.
The ground software runs on a Linux desktop with Ubuntu distro. It needs to communicate with the satellite by accessing the user to request information from the satellite, sending commands, receiving, and managing the telemetry the satellite sends periodically, and storing the information in a MongoDB data base [13], both flight and ground software are oriented by the ECSS-E-ST-40C [14].
C. CSP Services
This section presents information related to the CubeSat Space Protocol (CSP) network services and the implementation in the NanoMind and the Linux Server to include the IMU features on the system. The protocol is intended to provide a standard way for CubeSats to communicate with each other and with ground stations on Earth [1].
The CSP network defines a set of packet formats, data structures, and transmission procedures optimized for the small size and limited power and computing resources of CubeSats. The protocol supports both point-to-point and broadcast communications and can be used for a range of data types, including telemetry, images, and command and control messages. The application in this research is limited to [15]:
Allow communication between the mission subsystems in space and ground segments, routing tables in every subsystem for intercommunication, and hops between segments using the RF AX100 radios as a gateway in both satellite segments.
Implementations for space and ground segments software with the A3200-SDK and MS100-SDK libraries and structure. This is basic to include the software development for implementation of new service for the IMU features into the CSP network.
Services information is required to request data from the IMU, store in a parameter table accessible through the CSP network, parameters are sampled (updated) periodically and others are updated if the user samples the sensor manually with a CSP command.
Services related to telemetry information are sent periodically from the space to ground segment and then included in a local database.
The implementation of a new CSP service protocol requires the programming of the server and the client, respectively. Additionally, a relationship must be maintained between the sent packets and those that are expected to be received through CSP to ensure correct communication [16]. The implementation of a CSP command has the following characteristics:
CSP-Term Client Commands Register: Commands and subcommands must be registered within the CSP-Term console by the user, so that when the user requests either the help, autocomplete or the use of the command option, the help text appears on the screen of the command in a friendly way. Highlighting the operation of the help command would display the corresponding options and messages.
Once the invoked command completes its execution, the software handler is in charge of packaging the return data in the format defined by the command to ensure that both the client and the server handle the same data sizes and format. For example, reading the IMU will invoke the SPI function to obtain the sample, later, the handler must pack this data in the required format to send it back by CSP to the client that requested it; likewise, it will obtain the information in the same format for its interpretation.
D. Development
The development is based on the hardware, software, and CSP network research to include the IMU service in the software image for space segment in the On-Board Computer NanoMind A3200 [13]. Also, it aims at including the new IMU service and the configuration of the telemetry beacon from space to ground into the CSP terminal in the Linux server, also solving the next issues:
CSP network configuration for each subsystem.
Include the IMU service in the NanoMind A3200 image for space.
Include the IMU parameter tables in the space segment on the OBC.
Include the IMU service in the CSP-Terminal in the Linux server.
Setup the telemetry beacons from space to ground IMU data.
The network segmentation is carried out following the recommendations of the CSP protocol, leaving the addresses of the space segment in the range of (0-23), and those of the ground segment in the range of (24-31). The CAN interface is taken as the main bus in the space segment (since all its nodes support this interface). The routing of the network packets is designed to connect all nodes to each other, and it seeks to restrict the routing of packets outside this network segment through the AX100, and vice-versa, as a connection gateway between ground and space segments.
Moreover, the ground station runs a ZMQ interface defined as a communication interface between tasks to be executed on the Linux Server (CSP-Term, Beacon parser). In the same way, the USART interface (via KISS protocol) is selected as the main interface for the connection between the Linux server PC and the AX100 communication module, since it supports network hopping at level 0, thus allowing to route the packets from the ZMQ proxy to the satellite through the AX100 node. Fig. 4 shows the assigned addressing for each node on the proposed CSP network for space and ground segments.
For the adequate communication and functioning of the system, the FAC team had to develop a telemetry beacon parser. It’s an application part of the CSP network with the purpose of receiving the packets from space to ground, which correspond to the CSP telemetry - housekeeping packets.
The telemetry beacon parser oversees identifying the beacon received, decompression and entry of the data (parameters) in the MongoDB database, as can be seen in. In this way, the proposed configuration for the ground segment is fulfilled as described in Fig. 5, which shows the main log from beacon parser, receiving some beacons, decoding, parsed and added into the MongoDB with timestamp, type, version, sat_id to complete the information.
Table 1 Telemetry data stored in the MongoDB database.
| Item | Parameter |
|---|---|
| 1 | init_status |
| 2 | auto_status |
| 3 | x_gyro |
| 4 | y_gyro |
| 5 | z_gyro |
| 6 | x_accl |
| 7 | y_accl |
| 8 | z_accl |
| 9 | temp |
Likewise, some scripts are developed to ensure that all the processes requested on the server are setup prior to the correct execution and configuration. The final mission control software running in the Linux server is shown in Fig. 0, and presents the main four running applications: ZMQ Bridge, ZMQ Proxy, Beacon parser, and a CSP terminal. The four are executed in parallel to send commands from the server by the user. The application tmux is used as a terminal multiplexer; it lets the user switch easily between several programs in one terminal, detach them (they keep running in the background), and reattach them to a different terminal without the risk of losing information during the switch, keeping the terminal in the background.
E. Integration and Testing
The integration phase development, the component assembly, and interconnection run in a cooperative way, to check that there are no adverse emergent behaviors. At the same time, they check the response of a complete system and how each component and subsystem “affect” the other ones. As described by the NASA “Product integration is the engineering of the subsystem interactions and their interactions with the system environments (both natural and induced). Also in this process, lower-level products are assembled into higher-level products and checked to make sure that the integrated product functions properly and that there are no adverse emergent behaviors” [17].
The testing stage can be divided into two: the first one defines the procedures to check that the new functionalities work properly; the second tests all functionalities developed to integrate the IMU into software and hardware in the nanosatellite from the CSP Terminal, verifying that the result complies with the requirements.
The Integration of the elements and their performance were validated with the technological partner: GomSpace. The next tests to perform on the system were defined, and the results after their execution were the following:
Check power up scenario, setup, and communication between space and ground segment: PASS.
Check power up scenario for the IMU, setup, set single sampling and auto sampling to retrieve data from the IMU to the CSP-Terminal, then power off the IMU and check power consumption: PASS.
Check telemetry beacon from space to ground segment and the consequent analysis and store in the MongoDB, allowing to read the IMU data log in the Linux Server: PASS.
The execution of the test obtained an overall pass result, thus concluding that the resultant system meets the requirements. During the test execution, the next terminal output on the Linux server side looks as shown in Fig. 6.
The Figure 6 shows an error produced by trying to retrieve data from the IMU when the state is powered off, so the actual error is a correct result to the user. Later, the user powered on the IMU and tried to get a sample, resulting in correct data information retrieved from the satellite.
III. RESULTS
Using software analysis to include the A3200 SDK into the space segment and MS100 SDK, the IMU services and new features, into the ground segment, it is possible to establish and execute the IMU commands from the CSP-terminal. It allows the user to initialize the device, obtaining the serial, starting the auto-sampling task, or requesting an individual sample of the sensor successfully. An example of the IMU service is shown in Fig. 7 with all the commands available in the terminal.
The complete setup for the space segment is shown in Fig. 8, and the communication RF link for the ground segment is shown in Fig. 9.
Using the satellite with the software developed allows the user to control the IMU from the ground segment, accessing all the measurement features, updating the values in a parameter table that other devices can access from CSP services, and a beacon sending information from the space and receiving the data on the ground segment and storing in a MongoDB data base. The complete terminal application is shown in Fig. 10 with a split screen running the four applications at the same time, i.e, CSP-Terminal, ZMQ Bridge, ZMQ Client, and Beacon parser.
IV. DISCUSSION AND CONCLUSIONS
Once the EPSON IMU M-G364PDCA sensor integration has been completed at the software level with the OBC NanoMind A3200 and the CSP-Term command terminal using the different tools provided by GomSpace, it is possible to conclude:
This is the first registered integration of an IMU with a space platform developed by a Colombian team, so the main achievement is the acquired capability to carry out these software engineering activities and the transfer of knowledge for space developments.
The Colombian Air Force personnel involved in the development of the integration faced the challenge of understanding the CSP protocol. It enabled to integrate the IMU with other hardware components correctly into the satellite, and the creation of new CSP commands to control the IMU according to defined functionalities by the manufacturer. The CSP protocol is mandatory to any development under GomSpace product lines.
The implementation of CSP commands requires a specific hardware with a unique structure of the protocol and packets to be sent and received by the subsystem at both ends of the communication, which requires prior planning to define these requirements and guarantee its correct operation and communication once implementation is complete.
The satisfactory results of this process open the possibility of developing new applications on other types of integration and new projects for space platforms in the Colombian space industry lead by the FAC personnel in the near future, as well as new satellites or space systems.
Specifically, for the FACSAT-2 mission, the knowledge acquired by developing these activities allows us to approach the integration and develop test procedures for the different subsystems that are part of the satellite, thus making the mission successful.
