SINGLE MODULAR ON-BOARD COMPUTER FOR SPACE APPLICATIONS

Transcription

1 APPLICATIONS Jonathan William de Holanda, Benjamin Gilles Nicolas Boglietti, Sidney L. A. Carrara, Equatorial Sistemas SA, São José dos Campos São Paulo - Brasil, Abstract: This paper describes the MuSat - Mock-Up Satellite - platform, an innovative IMA for space architecture demonstrator, which aims to validate the expected benefits of applying IMA to a space avionics platform: a single on-board computer running several real-time applications with different criticality levels, each securely contained in its own space and time partition. The MuSat platform results from a key technology transfer cooperation between Equatorial Sistemas, the Instituto Tecnológico de Aeronáutica (ITA) and GMV. Keywords: IMA for Space, On-Board Computer, Mock-Up Satellite 1 Introduction The aviation industry has over the last decade performed significant modifications in avionics architectures. The Integrated Modular Avionics (IMA) technology was the solution that allowed the aeronautic industry to manage increased software functionality and efficiency. The IMA architecture makes use of a high-integrity partitioned environment that may host multiple avionics functions of different criticalities on a shared computing platform. In this realm, the ARINC 653 specification is a very important block of the IMA definition and the partitioning concept emerges for protection and functional separation between applications, usually for fault containment and ease of validation, verification, and certification. Figure 1 An IMA Module The IMA concept has evolved since late 80 s and has been adapted across the aviation industry from large aircraft like the Airbus A380 and the Boeing 787 to regional and business jets as the Dassault-Falcon. In the near future, the dissemination of the IMA technology to other market areas, like space, automotive, and control of critical infrastructures, will become a reality, and is already under study by several technology providers. In particular, this technology has reached outstanding relevance for the space market. The European Space Agency (ESA), as well as NASA, is analyzing the benefits of IMA for the space industry. 1

2 The need to share hardware among several avionic functions is even more urgent in the space domain than in the aeronautic sector. On a modern civil aircraft, there are dozens of digital devices, running hundreds of software components. In a satellite, due to several restrictions, the number of computers is much more limited. And, with today s technology, there is no other alternatives, with comparable reliability and performance levels, to share the available hardware among components of the avionics platform like Attitude & Orbit Control System (AOCS), Fault Detection, Isolation and Recovery (FDIR), control procedures or payload controllers. 2 Scope of Project This paper describes the MuSat (Mock-up Satellite) platform, an innovative IMA-for-space architecture demonstrator, which aims at validating the expected benefits of applying IMA technology to a space avionics platform. The MuSat platform results from a key technology transfer cooperation between Equatorial Sistemas, the Instituto Tecnológico de Aeronáutica (ITA) and GMV [1]. The objective of this already successful cooperation is twofold: to place these Brazilian institutions on the forefront of space avionics development and to demonstrate the IMA concept as a key technology in enabling the future growth of the space domain. The technology transfer project is named IMA4Brazil. MuSat comprises a sphere floating on a compressed air bearing (a hemispheric convex surface with the same diameter). Inside this sphere, an IMU (inertial measurement unit), reaction wheels, communications circuitry and antenna, batteries and a CCD camera (as a payload) are the basic satellite subsystems of this demonstrator. Due to size limitation, the Modular Mission Computer (MMC) is installed outside of sphere and connected with the MuSat through a wireless bus. The MMC is built with a Leon-3 processor, and shall actuate on the reaction wheels to control attitude according to mission commands and IMU information received, and control the CCD camera to perform the required mission, transmitting the image data back to the ground console via the downlink communications channel. To support the IMA concept validation and technology transfer, the software was designed following a loose adaptation of the European on-board software reference architecture [2] to the IMA-SP (IMA for Space) partitioned architecture. This resulted in the segregation of two functional chains: data handling (OBDH) and attitude control (ACS). Additionally, the payload (CCD camera) control software and the fault monitoring function (FDIR) were also partitioned. This software architecture was supported by the AIR time and space partitioned real-time operating system from GMV [3], running on a Leon-3 based on-board computer. 3 Operational Scenarios and Requirements Specifications for MuSat The MuSat system simulates a complete the satellite's life cycle. Since the stage in which the satellite is at the launch platform, until the imaging operation phase, each and every mode is simulated. The objective was to build scenarios similar to a real satellite, in order to evaluate the IMA On-Board computer in a typical space application. System life cycle was broken in four phases: ground, launch, orbit fix (safe mode) and normal mode. Transition sequence between phases is in this same order. Once the system enters a phase, it is not possible to revert to the previous phase (except by means of a simulation reset). 3.1 Ground Phase Ground phase is the first one after the system is powered up. Usually, the system is powered by an external source through an umbilical cable. This phase is broken in two modes: 1. external power source is on (ground support mode); 2. external power source is off (ground safe mode). At Ground support mode avionic functions (software) as well as devices (hardware) can be tested. 2

3 3.2 Launch Phase This phase simulates the launch stage, during which the satellite is still connected to the launch vehicle. For the user to follow satellite status and the system to save energy, only telemetry is operational in this phase. 3.3 Attitude Acquisition Phase In this phase, the system starts looking for the reference attitude. To find this position, MuSat uses sensors, actuators and a control algorithm to align to the reference attitude and stabilize. Once stabilized, all subsystems that were not already running are powered up automatically. When MuSat is unable to acquire the reference attitude within a pre-defined timeout period (possible fault in sensors, actuators or other peripheral device used to execute this task) the system goes into Safe Mode. 3.4 Normal Phase In normal phase, the system tracks reference attitude and wait for a request containing the position from which it must take a picture. Normal phase is broken in three modes: 1. Attitude Control Mode; 2. Payload Mode; 3. Safe Mode. The Attitude Control Mode is used for attitude corrections according to the sensors measurements. When MuSat receives a telecommand to make a picture acquisition, the system goes into Payload Mode. If the camera or the sensors needed for the image acquisition are not functional, this must be reported to the ground control. If any peripheral (sensors, actuator or others) or the attitude control software fails, MuSat goes into Safe Mode. In Safe Mode, MuSat cannot execute any telecommand (it cannot revert to Payload Mode). The system will be locked in this phase until a reset command is received or when the system powered off. 4 MuSat Architecture The following Figure introduces the architecture used in the project, including the software tools used for the development, simulation and code analysis (Figure 2). Figure 2 IMA4Brazil General Architecture 3

4 4.1 The MuSat prototype satellite The MuSat Prototype Satellite comprises an aluminium sphere with 25 cm outer diameter and 15kg weight floating without friction on a compressed air bearing (a hemispheric concave surface with the same diameter). The sphere accommodates the satellite sensors (gyroscope, digital compass and accelerometer), reaction wheels with their motors, wireless communications circuitry (Wi-Fi) and antenna, battery and power management unit, and a CCD camera as the payload. The interface bus between the IMA computer and all the other subsystems is simulated through a Wi-Fi connection using Ethernet UDP protocol. A CCD camera is the satellite payload embedded in the sphere and connected with an FPGA. The micro camera takes a picture in standard definition and the FPGA is used to translate the picture into IP packages. The payload image data are sent to the IMA computer which then transmits them to the ground station via the data downlink. The Inertial platform combines a 3-axis accelerometer, a 3-axis gyroscope and a 3-axis magnetometer. The magnetometer supports the IMA computer in finding the satellite s absolute initial attitude. The accelerometer and the gyroscope aid the IMA computer in calculating the satellite s attitude. This inertial platform is used to control the three drivers of the reaction wheels. A microcontroller reads sensors data through an I2C bus and controls motor speed by an RS232 network. Reaction wheels are three brass discs, each turning on a different axis (X, Y, and Z) to control the sphere s movement. The wheel rotation speed is controllable by commands sent by the IMA computer to the inertial platform. The inertial platform translates these computer commands into electric commands processed by the wheel motor drivers. 4.2 Development Tools The Development and Simulation PC encompasses the software tools that will support all development and testing activities. MATLAB is both a language and an interactive environment for the computation, visualization and programming widely used in the development of space-based architectures, as well as in many other fields. MATLAB along with Simulink will be used in this project to study, simulate and develop the dynamics of MuSat, in the form of its Attitude and Control System (ACS). SIMA is an execution environment that implements the ARINC 653 API on the GNU/Linux operating system and provides tools to simulate and validate IMA applications and configurations. This simulator allowed IMA4Brazil developers to verify the application and the system s functional aspects, without requiring further definitions about the hosting platform such as OS, drivers or hardware. This allowed developers to focus on applications logic and module configuration since the early stages of system development, without an actual target. TSIM is a SPARC architecture instruction level simulator, capable of emulating LEON processors in the development host. TSIM provides LEON s Memory Management Unit (MMU) emulation and a fast simulation speed, along with a set of debugging and monitoring facilities such as remote debugging with GDB (the GNU Project Debugger), execution time profiling and code coverage monitoring. TSIM had a central role throughout all the development effort of the IMA4Brazil prototype. GRMON is a debug monitor for LEON processors that provides a fully-equipped debugging environment and allows the execution of applications on the real target hardware. It supports a range of debug links such as USB, JTAG, RS232, PCI, Ethernet and SpaceWire. GRMON was used extensively in the verification and validation activities of this project. A Worst-Case Execution Time (WCET) analysis tool was used to measure the platform and applications timing behavior. It was used to test the reliability and correct functional behaviour of IMA4Brazil s real-time embedded platform. The WCET tool chosen was the RVS, from Rapita Systems Ltd. 4.3 IMA Platform As in common IMA platforms, the general architecture of the IMA4Brazil system is composed of three major elements: the target processor, the partitioning real-time operating system and the partitions themselves, which will execute the mission software (Figure 3). 4

5 Figure 3 IMA Platform High-Level Architecture The AIR Partitioning Real-Time Operating System is central to the IMA platform architecture. The AIR partitioning kernel executes in the on-board computer providing an ARINC 653 compliant run-time environment that, along with the implementation of the IMA-SP API, allowed the controll the MuSat and respective payload. AIR follows a two-level software architecture: the lower level is composed of a hypervisor that segregates computing resources among partitions (time and space partitioning); a second level, the application level, is composed of system s or user s applications running in an isolated environment (partition), and is supported by a set of services provided by the (AIR) platform. The AIR partitioning kernel thus manages the partitions devised for the system, namely those responsible for the Attitude Control, the On-Board Data Handling and the payload application, as well as the communication between the space platform prototype and the ground console. Each Partition executes a separate application running in a virtualized RTOS, following a static pre-configured schedule. The partitions can be logically divided into two types: application partitions are user-mode partitions developed to accomplish the objectives of the mission; system partitions have special privileges and execute system-related operations like fault detection or I/O management. The following partitions have been implemented: ACS (Attitude Control System) partition is responsible for controlling MuSat s changing orientation according to sensor measurements of the current attitude and the mission commands specifying a desired attitude. OBDH (On-Board Data Handling) partition is responsible for the management receiving, storing, forwarding, downlinking of telecommand/telemetry data exchange between the MuSat prototype and the ground console. Payload partition manages the CCD camera operation, implementing the mission s functional aspects according to the operational scenarios specified. FDIR (Fault-Detection, Isolation and Recovery) partition is a system partition dedicated to monitoring the space platform, identifying when a fault occurs, categorizing the type of fault and its location, and reacting accordingly, either to isolate it and/or to recover from it. IOP (I/O partition) is a system partition that provides an encapsulation of all I/O related tasks in one component that is independent from the operating system. IOP implements all low-level I/O access services with focus on the data buses selected for the IMA4Brazil platform. 5 IMA Platform Detailed Description This section details the IMA system configuration in terms of time scheduling and memory requirements. 5

6 5.1 System Configuration The Table 1 provides a summary of the frequency requirements of each of the platform s sensors, associated to the partitions that manage and process each sensor s data. The I/O partition is inherently associated with all the devices frequencies, as it performs the direct interface with every device. Sensor Table 1 Sensors throughput and frequency requirements Throughput Frequency required (min value) Frequency (millisec) Processing Partition Gyroscope 3200 Hz 100 Hz 10 ms ACS Digital Compass 1000 Hz 100 Hz 10 ms ACS Accelerometer 3200 Hz 100 Hz 10 ms ACS Camera Payload 1 image (644kB)/sec 1 Hz 1000 ms Payload By analyzing the desired functionality for each partition and aggregating such functionality with the defined periodic occurrences, we defined the minimum periods and duration for each partition as shown in Table 2. Table 2 Partitions Scheduling Summary Partition Period Duration ACS 100 ms 10 ms OBDH 200 ms (=MTF) 10ms Payload 200 ms (=MTF) 15 ms IOP 100 ms 30 ms FDIR 200 ms (=MTF) 10 ms More than one module schedule can be used in an IMA system life cycle, all the available module schedules are defined by configuration. The many module configurations allow the attribution of more or less CPU times for a given avionic function at different stages of a mission. During ground phase, for instance, avionic functions can be tested and the connection to the devices can be verified. The amount of time required for that initialization or testing operations is different than the time required when images are being acquired. At launch phase, the payload function is not expected to be active as the satellite will only receive ground control requests at normal phase. Therefore, different module schedules are adopted for each of operating modes. At launch phase, the payload and ACS functions can be inactive and have no execution window attributed to it - no CPU allocation. Suppressing or enabling functions execution times is provided by a service requested by an IMA application (multiple module schedules). Simple guidelines were used when defining the mockup module configuration: 1. IOP partition runs always before the ACS partition; 2. The schedule will never have idle times; 3. There will be MMS (Multiple Module Schedules), where: a) A second schedule has Payload partition disabled; b) A third schedule has ACS and Payload partition disabled; 4. IOP partition occurs before the OBDH partition. Figure 4 MuSat Schedule 1 - IMA4Brazil MTF Schedule with All Partitions Enabled 6

7 Figure 5 MuSat Schedule 2 - IMA4Brazil MTF with Payload Partition Disabled Figure 6 MuSat Schedule 3 - IMA4Brazil MTF with Payload and ACS Partition Disabled Table 3, Table 4 and Table 5 describes partitions windows and the total time each partition runs per MTF (Major Time Frame the time frame repeated cyclically by the module scheduler), as well as the period and period duration values that can be used to express this schedule in terms of a concrete AIR configuration for the three used schedules. Table 3 Partitions Scheduling Summary with All Partitions Enabled Partition # windows / MTF total time / MTF Period Duration ACS 2 20 ms 80 ms 10 ms OBDH 1 10 ms 160 ms (=MTF) 10 ms Payload 1 15 ms 160 ms (=MTF) 15 ms IOP ms 40 ms 30 ms FDIR 1 5 ms 160 ms (=MTF) 5 ms Table 4 Partitions Scheduling Summary with Payload Partition Disabled Partition # windows / MTF total time / MTF Period Duration ACS 2 20 ms 80 ms 10 ms OBDH 1 10 ms 160 ms (=MTF) 10 ms IOP ms 40 ms 30 ms FDIR 1 10 ms 160 ms (=MTF) 10 ms Table 5 Partitions Scheduling Summary with ACS and PAYLOAD Partitions Disabled Partition # windows / MTF total time / MTF Period Duration OBDH 1 10 ms 160 ms (=MTF) 10 ms IOP ms 40 ms 30 ms FDIR 3 30 ms 160 ms (=MTF) 10 ms Table 6 makes the correspondence from the schedules to the different MuSat phases specified in scenarios and requirements specifications. 7

8 Table 6 MuSat states vs. schedules correspondence MuSat Phase/Mode Start ACS Payload function Function Schedule Ground Safe Not Present Not Present MuSat schedule 3 no ACS and no Payload partitions Ground Support Present Present MuSat schedule 1 all partitions enabled Launch Nominal Not Present Not Present MuSat schedule 3 no ACS and no Payload partitions Attitude Acquisition Nominal Present Not Present MuSat schedule 2 no Payload partition Attitude Acquisition Safe Present Not Present MuSat schedule 2 no Payload partition Normal Attitude Control Present Present MuSat schedule 1 all partitions enabled Normal Payload Present Present MuSat schedule 1 all partitions enabled Normal Safe Present Not Present MuSat schedule 2 no Payload partition 5.2 Communication Channels Analysis The communication between the different partitions is performed through the ARINC 653 inter-partition communication means implemented in AIR, i.e. ARINC 653 channels and the corresponding queuing and sampling ports Platform Data Flows From the requirements and the operational scenarios specification, avionic functions were designed into partitions and an interface control document was devised to specify all the aspects of the interactions between subsystems in the demonstrator. This document defined all the messages exchanged (i) between the partitions; (ii) between partitions and devices and (iii) between the onboard system and the ground control. It also specified the circumstances of those exchanges and the format of each message. The following diagrams illustrate an abstract profile of the communications in the platform. Partitions are represented as rectangular boxes whilst other entities are represented by different shapes. Figure 7 Generic Telecommand Data Flow Generic Telecommand: telecommands are every message sent from the ground control to the MuSat, it could be request for satellite phase changes or for images. Figure 8 illustrates the flow of messages that is triggered by a telecommand. Figure 8 Payload Telecommand Data Flow Payload Telecommand: The payload telecommand is the specific case of generic telecommand and specifies the request for an image. This is the only command related to MuSat mission and the flow of messages exchanged through the partitions is depicted in Figure 9. 8

9 Figure 9 Generic Attitude Control Data Flow Generic Attitude Control: Figure 10 illustrates the communication flow triggered by data input from sensors. Sensors provide the input to the attitude control algorithm in the ACS partition, which computes the stabilization of MuSat according to a reference attitude. Figure 10 Generic Telemetry Data Flow Generic Telemetry: Figure 11 illustrates the communication flow triggered by data input from devices and used by the FIDR for generating the periodic system health status messages. A periodic telemetry report is sent to the ground containing data read from every sensor, actuator and other devices as well as the current mission phase. Figure 11 FDIR Data Flow Generic FDIR: The FDIR partition also generates reports every time a device provides discrepancies in the inputs data. This communication flow allows the generation of reports for the ground control alerting about onboard inconsistent behavior Inter-Partitions Connections Based in the previously specified data flows, the diagram in Figure 12 illustrates the connections and data exchanges between the different partitions that are hosted in MuSat s IMA platform. The term connection used herein describes the data exchanged between two partitions. Such data exchange was implemented via one or more ARINC 653 channels and the corresponding ports. Figure 12 Connections and data exchanges between partitions 9

10 5.3 Platform Memory Analysis The Table 7 indicates the memory used by each partition individually, taking into account only the memory elements particular to each. The ports size and particularly the number of ports at each partition, takes into account the data exchanges. Table 7 Estimation of the memory usage for each partition Partition Item Memory Usage Rationale ACS Application user code and libs Computes the ACS algorithm. Mem Usage: low Memory Usage Estimation 250 KB OBDH Payload partition IOP FDIR Ports Inter-Partitions Connections 16 KB Application user code and libs Computes inbound and outbound TM/TC packets storage and forwarding. Mem Usage: high 1 MB Ports Inter-Partitions Connections 512 KB Application user code and libs Computes image data with large buffering activity. Mem usage: high 2 MB Ports Inter-Partitions Connections 512 KB Application user code and libs Computes all data from all devices and partitions in the platform. Mem usage: high 1 MB Ports Inter-Partitions Connections 512 KB Application user code and libs Computes FDIR data: receives reports and events and issues commands. Mem usage: low 250 KB Ports Inter-Partitions Connections 512 KB 6 Partitions Developments Process GMV IMA tools supported the configuration of the system as well as the simulation of each partition comprising the mission. Different roles of the system development process were played by each partner involved in the project, once all the requirements and operational scenarios on the demonstrator were analyzed; the capabilities it should support were identified per function/partition. GMV development team assumed the development of the OBDH, FDIR and I/O partitions while Equatorial team assumed the development of the Payload and ACS partition with ITA contribution on the attitude control algorithms. Partitioning allowed each of the avionic functions to be designed with a higher level of independence from the rest of the system. The definition of the interface control document was enough to allow the remaining subsystems development to be carried off independently by each partner of the project. By the end of each function design, the development was first supported by SIMA simulation tool that provides ARINC 653 static partition schedule. The development of the prototypes in the simulation tool allowed the verification of the systems flow of communication, scheduling feasibility of partitions and the testing of the multiple module schedules. Communication flow and partition scheduling have high impact in the time required by the onboard system to achieve a requested operational mode, respond to a command from the ground station or generate system health reports. Because most of the communication flows involved on those operations could be simulated, both teams could refine the functions they were developing to achieve a module schedule with lower response times. A ground control application was also developed as part of the demonstrator. The ground control console enable users to send requests to the MuSat sphere and to verify that (i) the images were successfully acquired by the 10

11 sphere; (ii) the commands were successfully processed and (iii) the mockup health status conforms to what is expected. The MuSat demonstrator simulates a complete satellite operational cycle: from the ground stage, when the satellite is at the launch platform; until the operational phase, when the satellite is able to respond to commands coming from ground control. 6.1 Partitions Implementations and Unit Tests Executions At the early prototyping in the simulation tool all module schedule as well as communication channels used in demonstrator were defined. Many of the requirements imposed to the functions scheduling originated from the devices runtime behavior. Partitions had to ensure no information from the devices was lost, and that it had enough time to process the messages they would generate. 6.2 Integration and Validation At system integration, subsystems of both partners were finally assembled into one module. Minor adjustments to the module schedules were applied mainly because the simulation do not provide the same timing behavior as the target platform but the design of the functions did not suffer any change. The components were integrated on the satellite prototype platform including the MuSat simulation [4]. At the end of this activity, the test bed was running correctly and exchanging data as planned between all components. The team specified in detail all the validation activities scenarios and procedures. Each scenario was verified against the projects goal. 6.3 Code Coverage and Worst Case Execution Time Measurement Code coverage analysis usually applied to critical real-time embedded systems were also applied to the demonstrator on-board code. The code coverage and worst-case execution time analysis of MuSat platform and applications was performed by RAPITA tools RapitaCover and RapitaTime. Partitions reports were generated with both tools. 7 Results IMA4Brazil successfully achieved its goals through the development of the MuSat demonstrator: an IMA attitude control algorithm testing platform. Beyond the purpose of testing attitude control algorithms, the MuSat platform provides a sophisticated test bed for the development of IMA applications, using standards being developed and enhanced by ESA today. The configuration and simulation tools used throughout this entire project are now available within ITA laboratories, as well as the tools for simulating and debugging developed applications. Therefore, students, professors and researchers can extend or even modify the entire demonstrator with the support of simulation, configuration and timing analysis tools; from the IMA platform, to the AIR operating system, to the partitions defining the avionic functions. The project achieved the objective of transferring IMA knowledge and technology to the Brazilian university and the industry. Its Industry professionals and researchers may now have theoretical and practical experience with the integrated modular avionics development process, opening wider possibilities of research within the academic community in areas in the forefront of the technology being addressed by ESA today. A collateral positive result from the project is the experience gained in playing the different IMA development process roles and the impact of changing roles when looking at the supporting development tools. Important feedback on the usage and understanding of the concepts and tools inherent to the project will allow the enhancement of GMV IMA tools, user manual and roadmap. 8 Conclusion We have demonstrated, for the first time, the operation of a single modular on-board computer running several real-time applications to perform all necessary functions within a space satellite. Each application, with its particular criticality level, is confined in space and time within its own partition, providing for save mission performance. The modular concept also provides for a safe and cost-effective method for the development, verification and validation of the various applications within a spacecraft. IMA4Brazil also achieved successful results concerning the transfer of know-how and technology in the space domain. It was a productive experience of cooperation between two different countries and companies, and proved, by experience, the IMA advantages concerning the enforcement of independent development of avionic 11

12 functions. Project partners played the different roles of IMA development process (system architect, application supplier, platform supplier, system integrator) in each of the project work packages. All project-produced avionic functions and platforms passed through most of the phases of real systems development process (certification was out of the scope of IMA4Brazil). All the software used and developed throughout the project has been made available to ITA and will support students further explorations on top of the demonstrator. This work was supported by an offset contract between Airbus Military and the Brazilian Air Force. 9 References [1] [2] Windsor, J.; Deredempt, M.-H.; De-Ferluc, R., Integrated modular avionics for spacecraft - User requirements, architecture and role definition, Digital Avionics Systems Conference (DASC), 2011 IEEE/AIAA 30th [3] [4] Costa e Silva, M. A., et al., Framework for development of satellite attitude control algorithm, 2014 Journal of Control, Automation and Electrical Systems 12