Modelling a CubeSat-based Space Mission and its Operation
MModelling a CubeSat-based Space Mission and itsOperation
Carlos L. G. Batista ∗ , F´atima Mattiello-Francisco ∗∗ National Institute for Space Research (INPE)Space Systems EngineeringS˜ao Jos´e dos Campos, BrazilEmail: { carlos.batista, fatima.mattiello } @inpe.br Abstract —Since the early 2000’ years, the CubeSats have beengrowing and getting more and more “space” in the Space indus-try. Their short development schedule, low cost equipment andpiggyback launches create a new way to access the space, providenew services and enable the development of new technologies forprocesses and applications. That is the case of the Verificationand Validation of these missions. As they are cheaper to launchthan traditional space missions, CubeSats win by numbers. Withmore than 1000 CubeSats launched they still achieve less than50% rate of successful missions and that is caused mainly by poorV&V processes. Model Based approaches are trying to help inthese problems as they help software developers along the lastyears. As complex systems, space products can be helped by theintroduction of models in different levels. Operational goals canbe achieved by modeling behavioral scenarios and simulatingoperational procedures. Here, we present a possible modelingsolution using a tool that integrates the functionalities of FSMand Statechartes, the ATOM SysVAP (System for Validation ofFinite Automatons and Execution Plans). With this tool we areable to model the behaviour of a space mission, from its toplevel (i.e. system and segments) to its low level (subsystems) andsimulate their interactions (operation). With the help of LuaProgramming Language, it is possible to generate analysis files,specific scenarios and control internal variables.
Index Terms —cubesat, model based, operations, finite statemachines, verification and validation
I. I
NTRODUCTION
The innovation through the micro/nano/picosatellites hasbeen creating a new whole market and habitat for the spacesector. With a short life cycle, low cost and the use of standard-ized platforms, these satellites enable the in-orbit qualificationof new space technologies, high science and human resources[1]. The CubeSat standard , a.k.a. U-class, has predefined me-chanical and electrical interfaces, including launcher interfaces[2]. They brought a new satellite development philosophy, notonly for the university satellites but also for all the small-size ones. More than 1300 nanosatellites have been launchedin the last fifteen years, 1200 of them are CubeSats and theforeseeable future expect more than 6 thousand in the next sixyears [3].The real deal is that in order to develop these missionsin universities, reliability requirements, usually specified attraditional space missions, were reduced. Therefore, thesesatellites have demonstrated high failure rate. Some recentstudies [3], [4] pointed out that 50% of the CubeSat-basedmissions fail, and 70% of them are developed by inexperienced teams. The big difference between the traditional developersand these “hobbyists” is the lack of good practices in design,assembly, and tests. We still have a lack of studies showing usthe main problems that cause these missions to fail, especiallyduring the operational phase. For most of them the absence ofprocesses and procedures documentation is the main problemto investigate this kind of operation failure [5].In this context we can point out the lack of testing methodsand operational procedures validated in ground, which aretechniques used in the satellite development cycle to supportthe verification of the expected behavior of the system in theoperational environment, increasing the system reliability [6].The Verification and Validation – V&V – processes arecrucial to all space missions to be successful. But for mosttraditional space missions they are usually onerous in termsof time and money costs, which is incompatible with the U-class development philosophy, ”faster and cheaper” [7].The fundamental for any V&V processes is the systemrequirements specification. Most CubeSat-based projects havegiven less importance to the mission requirements definitionand analysis phase because the use of the CubeSat standard isconsidered the architectural solution to the satellite platform.Although CubeSat provides COTS (Commercial Off The-Shelf) subsystems with standardized interfaces and commu-nication protocols, they are not enough to define the missiongoals. The mission requirements and constraints are the majorelements to drive the use of the COTS in right way, asresult of Phase 0 analysis, i.e. mission conception analysisand feasibility.The mission concept of operation – ConOps – is a disciplinein space system engineering that plays a very important rolein the mission requirements analysis. ConOps addresses themission analysis under the user’s perspective. It traverses bothground and space segments, aiming to highlight dependenciesamong mission elements and the space environment to meetthe mission operation requirements [8]. The mission ConOpsanalysis deals with multiple operation scenarios that revealrequirements and needed design functions.V&V and ConOps are intimately related because the systemrequirements and specifications derived from the operationalneeds shall be verified and the intended use of the systemshall be validated considering the stakeholders expectations[9], [10]. a r X i v : . [ c s . S E ] F e b odelling the expected behavior of a system for require-ments analysis purpose has been helping different engineeringareas across the years. Model Based approaches are get-ting more and more of this piece of the market, includingCube/NanoSats due to its speed, reliability, and reproducibility.Modelling allows to represent the system in different levelof abstraction, under different perspective. Depending on thepurpose, appropriated modelling formalism is used to exploreparticular aspect of the system.Focusing on the concept of operation aspects of a Cubesat-based mission, we present an experience on the use of a mod-elling tool developed at INPE, by space system engineeringstudent. The tool aids the mission design analysis allowinganticipate requirements verification by means of operationalscenarios validation. The purpose is to increase confidence inthe mission requirements, reducing the cost of design reworkin terms of time and resources consuming.II. R ELATED W ORKS
New initiatives have been trying to increase the chance ofsuccess of CubeSat-based missions using different approaches,mainly Model-Based and Model-Driven approaches. Mod-elling tools have helped many projects and missions to achievethe confidence on their projects design and development beforegoing to production and operations since the beginning ofspace racing.[11] presents the CubeSat Reference Model – CRM – areference example that is being developed by the INCOSESpace Systems Working Group – SSWG. The goal of theCRM is to facilitate the design, verification and validation ofa CubeSat project using SysML. The CRM is being developedflexible enough to be used in different missions and differentteams.Other studies, [12], [13], focus on Model Driven Engi-neering, aiming to automate the V&V of on-board embeddedsoftware. The description of a MDV&V, or Model DrivenVerification and Validation, uses SysML to anticipate theplatform V&V, suggesting a systemic approach to simulateall the real spacecraft tests. And the usage of a new modelsphilosophy (activity of space product V&V where differentmodels are specified for the space mission, like MockUps,Engineering Model, Qualification Model, Flight Model, etc)with intermediate models, e.g. FlatSats and DevSats [14].Two highlighted works on this field are: (i) the devel-opment of a process and metamodel, in Arcadia Method,using Capella, for the flux of information and functionalitiesof an spacecraft from its ConOps in order to automaticallyfulfil the parametric information of a configuration file ina orbiter/operational simulator [15] and; (ii) the proposedScalable Architecture Test System – SATS –, in order tosupport the V&V, combine MDE and MBT to anticipate thepossible problems of interoperability and robustness [16].III. M
ODELLING A S PACE M ISSION
Aiming at representing the behavior of Cubesat-based mis-sion under the perspective of operation for studies purpose concerning operation scenarios telecommanded from groundstations, the ATOM SysVAP modelling tool was used. Fourmain reasons support the choice: (i) the tool was developedin-house. ATOM SysVAP is a result from an INPE’s masterstudent work; open source and available online in a git repos-itory; (ii) this tool has been used in graduation class, at INPE,to aid students on the specification of Operational Procedures,visualizing their execution on an operational simulator (iii)the use of Lua Programming scripts creates a new level ofmodeling where it is possible to associate full operationalscripts to different states and events and; (iv) the use of FSMis more simple and easy to deal and interfacing it with othermodelling and model checking tools, if necessary.
A. ATOM SysVAP
The ATOM SysVAP – Atom SYStem for Validation offinite Automatons and execution Plans – is a tool developedto validate an architecture proposed to execute executionoperational plans [17].The ATOM enables the modeler to: (i) represent the Tran-sition and States Domain as Mealy, Moore Machines andStatecharts; (ii) represent sub-FSM as part of other FSM; (iii)execute and validate operational plans in debug/real time modeand; (iv) access to environmental variables in order to evaluatethe results and determine if the operational plan can or cannotbe accepted.Also, the ATOM uses the Lua Programming language forthe development of the Domain Language. This capabilitysupports the model execution offering new facilities for thedata description.
B. Elements of the Model
The element of the modelled space systems follows thehierarchical sequence presented at the Figure 1.Fig. 1: Model breakdown hierarchyAt Figure 1, the rounded shapes represent FSM withoutsub-FSM (bottom level of abstraction) as the square shapesrepresent FSM that can be grained in order to lower the levelof abstraction.rom the top level, the FSM “model” represents the modelas a whole, their sub-FSM are representations of what is insidethe system to be modeled, “system”, and what is outsidebut still interferes with the system, the “environment”. Asa space system, we are able to divide into two other sub-FSM, “space segment” and “ground segment”. This separationis common at space missions to more easily organize theattributions, needs and capabilities of each one. At this pointthe ground segment can be divided into “tracking”, a modelto deal with the pointing and passover constraints of groundstations and satellite, and “control”, the model responsible todeal with the operation of the satellite, this model can representspecific operational plans as multiple FSM. Similarly, thespace segment can be divided into the “service” and “payload”buses. As a service bus, the platform is divided again intothe different subsystems. As an example of granularity, theonboard computer model can be splitted into a sub-FSMto represent only the logical functioning of the embeddedsoftware, “obsw”.Considering the launcher requirements for CubeSats, (a) thesatellite must be in “off” state while inside the dispenser;(b) the satellite must have a device to ensure the batteriesare disconnected to the power system, a killswitch, whileinside the dispenser and; (c) the satellite must not enter anyoperational state or boot mode for at least 30 minutes afterthe launch from the dispenser.So, the Figure 2 represents the models used for this situ-ation, once the space segment receive the event “launched”(fig. 2a), the variable “killswitch” turns false, activating theevent at the EPS – Electric Power Subsystem – model (fig2b). The powering on of the EPS activates two events in twodifferent FSM: (i) the OBSw – On Board Software – FSMstarts a countdown of 30 minutes to start the booting process,BOOT state, (fig 2c) and; (ii) at the Antennas Subsystem, thedeployment process of the antennas is started also (fig.2d).Only after the 30 minutes, the OBSw is able to go to theDEPLOYMENT state, where it awaits for the state of theantennas (deployed or not, i.e. ants flag variable) changing itsstate to SAFE. DEPLOYMENT, SAFE and NOMINAL arestates considered as operational for satellite already.
C. Analysis Files
Besides the modelling capabilities of the ATOM SysVAPtool, one great advantage and feature of the IDE is theintegration with the Lua Programming Language. With that weare capable of reading and writing “comma separated values”files, a.k.a. csv files.Once we have modelled the behaviour of the intended spacesystem, some routines and functions in Lua can be usedto generate analysis files, as csv files. These analysis filesrepresent the internal variables that we want to monitorate,such as telemetries and more.For example, Figure 3 shows an analysis file, read by apython notebook, with information about the spacecraft batteryvoltage level, the subsystems FSM actual states, and even data (a) SpaceFSM (b) Electric Power Subsystem FSM(c) OnBoard Software FSM(d) Antennas FSM
Fig. 2: Examples of modelled FSMabout a reliability model implemented and the number of faultsin the system, also implemented due to the Lua capabilities.Fig. 3: Example of analysis file opened in Jupyter NotebookThe generation of these analysis files can help the devel-opment team to check the behaviour of specific variablesof the spacecraft and how to control them and also helpthe operational team to understand them even during theoperational phase.Figure 4 helps us to understand some graphs that can beplotted in order to evaluate the behaviour of some variables.At Figure 4a we can access information about the battery levelas each state of the environment changes (i.e. sun or eclipse)and if a certain number of subsystems are powered or not. Asthis, we can monitor the depth of discharge of the battery andsimulate different conditions of operation taking into accountthe power budget. Figure 4b represents a derived comparison,from a fault model minimally implemented from a reliabilitymodel (a Weibull distribution). In this case, the chance of afault occurrence, at the system level, is calculated as a normaldistribution from 0 to 1. Once the chance of a fault is less thanthe reliability level at the same point in time, a fault occurs.That is a simple fault model implemented without any faultbehaviour associated with. a) Battery Level(b) Reliability and Fault Count
Fig. 4: Examples of graphs derived from the analysis fileIV. C
ONCLUSIONS AND F UTURE WORK
As we evolve the technologies for the access of space, theprocesses, procedures, activities and methods should evolvetogether.We presented an experience on the use of a modelling tool,ATOM SysVAP, to represent the behavior of Cubesat-basedmission, under operational perspective, for the purpose of theverification and validation as a point of view from ConOps.The purpose is to highlight the dependencies among themajor elements of the mission and space environment underperspective of the mission operation, which contributes toincrease confidence on the definition of system requirements,reducing the project development cycle and the time spendduring V&V processes.The ATOM SysVAP has demonstrated, so far, its capabilityto, not only, model the operational phase of a space system, butalso help the conception, development, and V&V (validationof specific FSM paths). With the use of Lua as scriptinglanguage, the ATOM exploits its usage being capable ofgenerating telemetry files, payload data, mathematical mod-els, evaluating behaviour in real time (debug) and, modelingfaults (using fault/error/failure behaviours and scenarios). Thiscapability enables the FSM to be more reduced and the modelssimpler.Moreover, the method used at this point is not completely tool independent. Based on the capabilities of the ATOMSysVAP, the models were evolved and implemented in order torepresent the space mission elements and behaviour. Comparedto other approaches, this paper does not goes too much faraway. FSM is a well known modeling method and scriptinglanguages are being used for a long time in the contextof repetitive activities. The use of both methods together inthe same tool enables the conception of a single modelingenvironment that can be shard during the space product lifecycle (from concept to operations).The idea for the future of these models is to evolvethem in order to model the behaviour for different opera-tional plans/situations and being capable of modeling faultsat the subsystem level. Some studies are being developedto use the ATOM to simulate the operational procedures ofthe NanoSatC-BR2, 2U CubeSat developed by INPE to belaunched in March/2021. These models will help the Opera-tional Team, at the Ground Stations, to be trained to deal withpossible situations that can happen at the in-orbit phases andto analyze the autonomous operation of the payloads on boardof the nanosatellite. R
EFERENCES[1] G. Martin, “Newspace: The emerging commercial space industry,” 2015.[2] H. Heidt, J. Puig-Suari, A. Moore, S. Nakasuka, and R. Twiggs,“Cubesat: A new generation of picosatellite for education and industrylow-cost space experimentation,” 2000.[3] T. Villela, C. A. Costa, A. M. Brand˜ao, F. T. Bueno, and R. Leonardi,“Towards the Thousandth CubeSat: A Statistical Overview,”
Interna-tional Journal of Aerospace Engineering , vol. 2019, pp. 1–13, jan 2019.[4] M. Swartwout, “Secondary spacecraft in 2016: Why some succeed(And too many do not),” in . IEEE,mar 2016, pp. 1–13. [Online]. Available: http://ieeexplore.ieee.org/document/7500791/[5] C. L. G. Batista, T. Basso, F. Mattiello-Francisco, and R. Moraes,“Impacts of the space technology evolution in the V&V of embeddedsoftware-intensive systems,” arXiv preprint arXiv:2011.14914 , 2020.[6] L. Berthoud, M. Swartwout, L. Blvd, S. Louis, J. Cutler, andD. Klumpar, “University CubeSat Project Management for Success,”2019.[7] K. Forsberg and H. Mooz, “System engineering for faster, cheaper,better,” in
INCOSE International Symposium , vol. 9. Wiley OnlineLibrary, 1999, pp. 924–932.[8] W. J. Larson and J. R. Wertz,
Space mission analysis and design , 1999,vol. 29, no. 09.[9] NASA,
NASA System Engineering Handbook Revision 2 , 2016.[10] ECSS, “ECSS-E-HB-10-02A Space engineering: Verification guide-lines,”
ECSS Standard , no. December, 2010.[11] D. Kaslow and A. M. Madni, “Validation and Verification of MBSE-Compliant CubeSat Reference Model,” in
Disciplinary Convergence inSystems Engineering Research , no. January, 2018, pp. 1–1201.[12] S. A. Jacklin, “Survey of Verification and Validation Techniques forSmall Satellite Software Development,” pp. 138–147, 2017.[13] M. Omair Khan, M. Sievers, and S. Standley, “Model-based verificationand validation of spacecraft avionics,”
AIAA Infotech at AerospaceConference and Exhibit 2012 , pp. 1–11, 2012.[14] J. Eickhoff, R. Hendricks, and J. Flemmig, “Model based developmentand verification environment,” in , vol. 3. AIAA,dec 2003, pp. 1275–1285.[15] D. P. d. Almeida, F. Mattiello-Francisco, and F. L. d. Sousa, “Towardsmodeling the concept of operations for cubesat-based missions,” XWETE. S˜ao Jos´e dos Campos: INPE, 2019.[16] C. A. C. Conceicao, F. Mattiello-Francisco, and C. C. L. Batista, “De-pendability Verification of Nanosatellite Embedded Software Supportedby a Reusable Test System,” in