Impacts of the Space Technology Evolution in the V\&V of Embedded Software-Intensive Systems
Carlos Leandro Gomes Batista, Tania Basso, Fátima Mattiello-Francisco, Regina Moraes
IImpacts of the Space Technology Evolution in theV&V of Embedded Software-Intensive Systems
Carlos L. G. Batista ∗ , Tania Basso † , F´atima Mattiello-Francisco ∗ , Regina Moraes † ‡∗ National Institute for Space Research (INPE), S˜ao Jos´e dos Campos, Brazilcarlos.batista, fatima.mattiello { @inpe.br } † University of Campinas (UNICAMP), Limeira, Braziltaniabasso, regina { @ft.unicamp.br } ‡ University of Coimbra (UC), Coimbra, Portugal - Full / Regular Research Paper (CSCI - ISSE)
Abstract —CubeSat-based nanosatellites are composed ofCOTS components and rely on its structure and standardizedinterfaces. A challenge in the nanosatellites context is to adaptthe V&V (Verification and Validation) process to answer to theincrease importance of the embedded software, to reduce theartefacts to be delivered aiming at cutting cost and time and stillcomplying with international standards. This work presents ananalysis of the strategy adopted in a real nanosatellite for thedevelopment of the OBDH software embedded in NanosatC-BR2mission. The goal is to discuss the impact that the standardizationof the structure and interfaces of the CubeSat impose on the V&Vprocess of the SiS and to highlight the challenges of “New SpaceAge” for the use of existing V&V techniques and methods.
Index Terms —CubeSat, nanosatellites, V&V techniques
I. I
NTRODUCTION
In the last decade the space area has evolved significantly,thanks for the advent of microprocessors and the spreadof software as a service that allowed the development ofmicro and nanosatellites programs. The advent of the CubeSatstandard has made the development cycle of small satelliteprojects (nanosatellites) much faster and cheaper, compared tolarger space missions. In addition to the use of COTS (com-ponents off-the-shelf), that reduce cost, the standardization ofthe satellite structure and its interfaces helps improving thearchitectural satellite solutions based on CubeSat [1].With the technological evolution of embedded electronics,memories and satellites processors, the functionalities imple-mented by software have increased. The so-called software-intensive systems (SiS) embedded in satellites are increasingin terms of complexity and becoming critical elements for themission. Moreover, the “new space age”, i.e., greater access tospace by different segments of the society, demands for newspace products and services, requiring regulation and well-established development processes. CubeSat can be taken byan example due to its popularity within the academia andindustry. The complexity of CubeSat structure, cabling andinterfaces has been significantly simplified with the standard-ization, but the software has not.Addressing this problem, SiS suppliers are reducing boththe design artifacts to be delivered in the reviews baselineand the number of reviews in the development cycle ofmany SiS embedded in nanosatellites. However, negative sideeffects of this strategy in the quality of the nanosatellite V&V process (unknown software requirements in the beginof the development cycle, immaturity of the stakeholders andexpertise of the development time in the space area projects)have been observed regarding the lack of compliance withinternational standards. The challenge is to establish effectiveV&V approaches that can contribute to make the nanosatellitesV&V process shorter and cheaper but mainly compliant withthe international standards.This work presents the V&V strategy adopted in the de-velopment of NanosatC-Br2, a scientific nanosatellite leadingby the Brazilian Institute for Space Research (INPE) withpartners in Brazilian Universities and software private supplier.Considered the main SiS element of the mission, and the focusof this study, the On-Board Data Handling (OBDH) softwareis responsible to the implementation of the interfaces withthe mission payload and the ground systems. The approachaddresses the V&V activities with the respective techniquesand methodologies adopted by INPE in the development ofSiS projects embedded in satellites based on the guidelines ofthe European Cooperation for Space Standardization (ECSS)[2]The V&V activities rely on baseline reviews and Model-Based Testing (MBT) to generate, automatically, test cases,being able to systematize the OBDH testing.In addition to the introduction, Section II presents thebackground and related work. Section III presents the V&Vprocess adopted by INPE in the development of OBDH SiS.Section IV presents research opportunities to improve theV&V process of standard Cubesat satellites, ending with theconclusions and future work in Section V.II. B
ACKGROUND AND RELATED WORK
The CubeSat standard emerged from an effort by CaliforniaPolytechnic State University and Stanford University in 1999.It is a simple and small satellite model, developed with low-cost (less than one million Euro) and a short project cycle(less than two years to flight readiness) educational objectives,both in development and in launch [1]. It is a cube-shapednanosatellite, whose edges measure 10 centimeters, volumeof one liter and can hold a bus and payload with mass of1.3 kilograms. More than one unit (or 1U) can be combinedto form larger satellites (e.g. 2U, 8U) and can use ejectionsystems in standardized orbits (e.g. P-POD - Poly Picosatellite a r X i v : . [ c s . OH ] N ov rbital Deployer), allowing to release several satellites throughthe same interface and to launch several CubeSat in a singlelaunch vehicle or share trips with supplies in the refuelingoperations from ISS (International Space Station).The architecture of a satellite mission is composed of fourparts: the space, the launch, the ground and the user segments.The space segment is the more important one for this work.Within it are the payload (set of equipment dedicated to theapplication of the space mission) and the platform (set ofsubsystems designed to support the operation of the mission inorbit, also referred as bus ). Figure 1 shows the typical architec-ture of a satellite platform, with the space segment subsystemsand its communication with the ground segment. We highlightthe OBDH (On-Board Data Handling) subsystem, a typicalSiS, which is responsible for monitoring the health of the othersubsystems of the satellite platform, for interacting with thepayloads of the mission and for ensuring communication withthe ground in the operation of the mission. Fig. 1. Architecture of the space and ground segments
Besides dataprocessing, OBDH plays the role of the space-craft command & control and telemetry data management .The command & control functions on satellites enableremote operation of the satellite subsystems, allowing theground controller to change the behavior of the spacecraftas, for example, change the operational mode and coordinateorbital maneuvers.The functions associated with telemetry on board includereal-time monitoring of the platform’s equipment and subsys-tems and also of the payload in terms of critical parametersto the mission’s survival. The data packaging and temporarystorage of mission on board are also functions performed bythe OBDH software, responsible to transmit those data to theground in the window of visibility of the satellite and GroundStations. The platform telemetry generally encompasses twocategories of data: housekeeping (parameters needed to checkthe health and state of the spacecraft) and attitude parameters.The payload telemetry consists of the application’s data set(the mission’s data). Computing on board of satellites is alsoused to reduce the telemetry, such as compressing data onboard to reduce the amount of data and reduce the needs ofhigh downlink bit rates.Software engineering is normally addressed in the spaceproject standards. Best practices are recommended by NASAand ESA in cooperation with the industry [2] [3] . In fact, standardization is important to reduce risks, costs and improvequality and communication in the space for any spacecraftmission, including CubeSat [1]. Scholz [4] presents a stan-dard handbook reviewing existing space standards and theirpotential application within CubeSat mission.Focused on the V&V process, the interests of this work areon techniques and tools to assure the quality of the softwareembedded in the spacecraft. The most frequent techniquesbeing applied to improve and assure quality in space softwareare reviews and tests. According to ECSS standard [5], reviewsassure good quality of documents and are a good opportunityfor customers to check, gradually, the comprehension of thesuppliers about the software details. The tests demonstrate thatthe implementation meets the requirements and performanceconstraints are correctly and completely implemented.Figure 2 presents the basic mission (column 1) and relatedsoftware (rightest column) life cycle activities recommendedin ECSS, along the typical space mission phases: MissionAnalysis/ Needs Identification (O), Feasibility (A), Prelimi-nary Definition (Project and Product)(B), Detailed Definition(Product) (C), Production/Ground Qualification Testing (D),Utilization (E), Disposal (F) depicted in the central part ofthis figure . The darker bars represent the period that eachspace mission activity is carried out under system point ofview. The lighter bars correspond to the software activitiesrelated to the software life-cycle development under softwaresubsystem point of view (i.e., phases B, C and D).
Fig. 2. ECSS Space Mission Project Life Cycle
On the bottom of Figure 2, can be observed the sequenceof reviews in the space mission project, at system engineeringlevel. They are: MDR - Mission Definition Review, PRR -Preliminary Requirements Review, SRR - System RequirementReview, PDR - Preliminary Design Review, DDR - DetailedDesign Review, CDR – Critical Design Review, QR - Quali-fication Review, AR - Acceptance Review, ORR - OperationRequirements Review, FRR - Flight Readiness Review. Thesoftware project (a subsystem in the hierarchy of space systemdevelopment) shall be synchronized with those milestones.Along the life cycle a series of models must be electedto help the V&V processes. Three main physical models ofhe satellite are considered: (i) Engineering Model (EM) -the development environment based on prototyping with non-qualified components; (ii) Qualification Model (QM) - thesatellite integrated in the flight structure to be stressed ontesting; and (iii) Flight Model (FM) - the flight structureassembled for flying. From a software project perspective QMand FM are considered identical. Note the bar associated withthe software verification activities. It considers the software atCDR is already embedded in the hardware, being the OBDHsubsystem (software and hardware integrated).In CubeSats, the OBDH grows in complexity as long asthe hardware gets miniaturized. More and more services aredelegated to the on board software replacing functions oncedone by hardware. More pieces of software are developed tointerface, control and operate different subsystems. These newfeatures increase the overall complexity of the satellite andalso increase the number of vulnerabilities . The success ofthe mission relies on the perfect operation of the OBDH ,even more for CubeSats.Different works have been proposing solutions to mitigatevulnerabilities without increase the costs of a V&V process.Some focusing on specific pieces of software [6] [7], othersnew methodologies [8] [9], others to develop models in model-driven approaches [10] [11], and, even more, some of themexploit the standards tailoring [12] [13].III. V&V
PROCESS FOR
OBDH
DEVELOPED AT
INPECubeSat establishes in its minimum structure (1U) electricalinterfaces with standardized connectors through which thesubsystems of the satellite platform connect themselves ( bus ).In this way, the architectural complexity of the satellite interms of structure and cabling becomes significantly smaller,adding the advantage of several COTS subsystems that theindustry is able to supply.Due to increased demand of nanosatellite mission for thepurpose of new technology demonstration in orbit, in 2016,the European Space Agency (ESA) released a documententitled
Tailored ECSS Engineering Standard for In-OrbitDemonstration (IOD) CubeSat Projects . IOD Cubesats areconsidered structure (1-U or multiple) generally characterizedby the following attributes: (i) Complete stand-alone systemsincluding platform, payload, ground segment and operations;(ii) Higher risk acceptance profile; (iii) Low level of com-plexity (relative to other space ESA project); (iv) Low costand short schedule; (v) Short operational life-cycle (less thanone year); (vi) Acceptance of single point of failures; (vii)Limited redundancy and fault tolerance; (viii) Robust safemode; (ix) Extensive use of COTS elements and extensivetests focusing on system level (functional and environment,qualification and acceptance); (x) Simple project organizationwith well integrated teams (few suppliers or subcontractors).ESA states that only a few in the list of classical acquisitionstandards may be selected as applicable. Thus, “The IOD https://copernicus-masters.com/wp-content/uploads/2017/03/IOD CubeSatECSS Eng Tailoring Iss1 Rev3.pdf verification process shall be adapted to reflect the reducedcomplexity of work and the absence of one or more dis-ciplines”. Regarding software discipline, INPE has investedin reducing complexity of the verification process of OBDHsoftware developed for being used in two ongoing Cubesat-based missions, named NanosatC-Br2 and CONASAT-0.The V&V process is still supported by reviews at designtime as recommended in ECSS. However, in the light of theECSS Mission Project Life Cycle, already presented in Figure2 and fully implemented for the traditional satellites, CubeSatproject has eliminated the revisions DDR - Detailed DesignReview and
QR - Qualification Review . The justification is thatDDR aims, in traditional satellites, to verify with the teamhired for the development, the consistency of the design ofthe drivers and software libraries with the hardware also underdevelopment. In the case of Cubesat nanosatellite, the use ofstandardized interfaces and protocols available as third-partycomponents (COTS) guarantees the necessary compatibility.Similarly, since the basic Cubesat 1-U platform is alreadyprovided as a qualified COTS, QR review that is justified ontraditional satellites to demonstrate that the satellite structure(QM) with its integrated subsystems has been verified andcan be manufactured for flight (FM) is no more necessary.However, the AR - Acceptance Review was maintained, as itis a system-level review. Figure 3 shows the adaptation of theECSS Mission Software Life Cycle carried out at INPE fornanosatellites. The standardization of hardware benefits theembedded software design due to the availability, during itsdevelopment, of COTS on-board computer architectures wherethe software should be embedded.
Fig. 3. Software Development Life Cycle for Nanosatellites
Thus, with the help of Model Driven Engineering (MDE)approaches, early in the development cycle, it is possibleto support the requirements definition using techniques thatallow to verify the behavior of the embedded software asexpected by means executable models (Model-in-the-loop -MIL) in the PDR revision and effectively embedded in thetarget hardware (Hardware-in-the-loop - HIL) in the CDRrevision (see Figure 3). MIL prototyping makes it possible toanticipate, in the mission development cycle, the identificationof SiS interoperability and robustness problems that mightoccur on the interaction of two communicatiing SiS [14] . . Deliverables for Mission Reviews
This section presents an example of a typical V&V processtailored by INPE for the development of an On-Board DataHandling (OBDH) subsystem embedded into Cubesat-basedsatellite missions. The process outputs include both a set ofdeliverables considered input for each mission review in Figure3 and the testing method used for the integration of the OBDHwith other subsystems of the platform, and other SiS such asthe satellite payloads.The deliverables related to each review of the softwaredevelopment life cycle for Cubesat-based missions are in thethird column of Figure I. It is shown in bold the final deliveryversion and the respective reviews are the ones in whichthe document is considered closed.
Requirement Baseline and
Interface Requirements are not closed at the end of SRRreview, as in traditional satellites, but only at the end of CDR.This is feasible in software designing that follows prototypingand incremental approaches.
TABLE IOBDH (S I S) M
ISSION R EVIEW AND D ELIVERABLES
Mission Reviews Deriverables - Traditional Satellite Deriverables - CubeSats Deriverable Owner
SRR
Requirements Baseline
Requirements Baseline Customer
Interface Requirements
Interface Requirements CustomerSW Development Plan SupplierV&V Plan V&V Plan V&V TeamPDR
SW Development Plan
SW Design Supplier
Technical Specification
Requirements Baseline SupplierV&V Plan V&V TeamInterface Requirements CustomerSW Test Plan SupplierSW Test Report SupplierCDR
SW Design SW Design
Supplier
SW Source Code SW Source Code
Supplier
SW Test Plan SW Test Plan
Supplier
SW Test Reports SW Test Reports
SupplierUser Manual User Manual SupplierV&V Plan V&V Plan V&V TeamV&V Plan Instrument System AIT Plan V&V TeamV&V Specification Mission Operation Concept V&V TeamV&V Plan Subsystem V&V TeamV&V Specification Subsystem V&V Team
Requirements Baseline
Customer
Interface Requirements
CustomerAR
SW approval SW approval
Customer
User Manual User Manual
Supplier
V&V Plan System System AIT Plan
V&V Team
V&V Specification System System AIT Report
V&V Team
V&V Report System Mission Operation Concept
V&V Team
B. MIL and HIL prototyping for SiS integration purpose
Inspired by the antecipation of issues related to OBDHSiS integration with the nanosatC-BR2 payloads, the InRobtesting process originally proposed in [15] and its extensionin InRob-UML [16] have been used to guide the constructionof communicating models (MIL). These models represent theexpected behaviour when two communicating SiS perform agiven service collaboratively. The models execution allows toboth verify interoperability and robustness requirements bysimulating and deriving tests cases using MBT tools. Figure 4presents InRob Testing Process in three phases: A) Modeling;B) Test case Generation; C) Test case Execution.The inputs for the service modeling (phase A) are: (i) theproject artifacts that specify among others the system func-tional requirements, the subsystem user manual and time con-straints; (ii) the service profile development, which supportsthe prioritization of a particular service to be modeled. Thenominal behavior of the elected service is formally specified.An interoperability TIOA model results in the nominal TIOA
Fig. 4. InRob Testing Process model. From the nominal service model and time constraintsimposed on the communicating SIS, the concept of Major and/ or Minor timing deviations are used to deal with timinghazards related to the communication channel failures. Thus,the nominal service model is extended to represent the robustbehavior of each communicating SIS, facing those considereddeviations. The output is the extended model of the service.The extended TIOA models outputs in Phase A are the basisfor the test cases generation methods oriented to test purpose(TP) approaches in Phase B. A TP is a formal description ofa property (or a sequence of properties) represented in theTIOA models. On-the-fly methods for test case generationsearch for a specific property during the simulation and thetest case is generated by recording a trace on traversing themodel aiming at the property verification. This test case isable to validate the behavior of the implementation concerningthat property. Robustness test case generation considers hazardscenarios (e.g. rushed and duplicate messages) specified by thetest purpose approach.In Phase C of the testing process, the test cases wereperformed in real SUT. The testing architecture relies on aFailure Emulator Mechanism (FEM), which is considered aspart of the Testing System (TS).The InRob approach has been used in the V&V activ-ities of the nanosatellite named NanosatC-Br2, a scientific2U Cubesat-based nanosatellite under development at INPE.NanosatC-BR2 carries on Earth orbit 5 payloads being 2scientific instruments and 3 new technologies for validationin the space. InRob aids to create representative modelsfor interoperability and robustness analysis of the OBDHexpected behavior (requirements) in the interactions with thenanosatellite payloads. Following InRob Fase A, the modelingwas built with the aid of UPPAAL tool, using timed automataformalism, enabling the analysis of the requirements throughmodel simulation. Ten models in total output from Fase A,being two for each payload. Figure 5 shows the nominalmodels of the interactions between OBDH and payload SLP(Scientific Langmuir Proble payload) that occur on the channelI2C in a master-slave communication. From those models, testases can be automatically derived through the verificationof properties in the simulation of the models using model-checking technique, in Fase B.To start the reading, the on-board computer will send acommand to the reading initialization SLP, which will containbytes referring to the local date and time (a timestamp to dealwith the lack of a Real Time Clock). So, the SLP will printat the beginning of each reading the date and time of thebeginning of the collection. The SLP must respond to theOBDH the correct receipt of the command (acknowledge).After starting the reading, the OBDH should estimate a periodof more than 5 minutes to start asking for data transmission(avoiding to interrupt the SLP in the collection). If an erroroccurs and the OBDH requests data transmission to the SLP,the SLP must ignore the request.The implementation of Fase C in the NanosatC-BR2 counton a Scalable Architecture Test System (SATS) based onArduino computer boards proposed in Figure 6 [14] . SATSsupports the V&V process on the MIL and HIL perspectives.In MIL the codes generated from models presented in Figure5 are embedded in the Arduinos and the interactions betweenOBDH and SLP can be verified from a behavioral point ofview. That facility allows us to anticipate requirement’s ambi-guities and specification faults. Moreover, functional test casescan be derived from those models. Those test cases will beexecuted in the HIL environment when the communicating SiSare embedded in the real hardware, for acceptance purposes.The Failure Emulator Mechanism (FEM) in the InRob TestArchitecture (see Figure 6) supports faut injections in the com-munication channel that is used for the SiSs (SUT1 and SUT2)interactions in order to validate robustness requirements. FEMis able to intercept the exchanged messages between twosubsystems under testing and inject different faults: (i) timerelated faults, i.e. delay; (ii) value related faults, i.e. bit-flip and(iii) specific communication bus faults, i.e. verbose subsystem.Figure 7 presents the number of Test Cases derived fromthe ten models generated with the aid of UPPAAL tool inFase A. For each interaction between the SUTs models ofinteroperability, which is considered a Test Purpose (TP), oneTest Case classified as nominal was automatically generated.Regarding the interoperability models OBDH and SLP, thereare 8 interactions specified, therefore 8 nominal TCs. More-over, for each nominal TC, at least 3 TCs are supplementedby FEM during test execution, associated with the three faultmodels implemented. In total 32 TCs were executed. For thefive payloads of NanosatC-Br2, from 10 interoperability mod-els specified using InRob, 232 test cases were automaticallycreated, 58 nominal functional and 174 fault injection testcases (applied by FEM).The conception of a HIL environment starts in the EMintegration as a continuous integration until the CDR. Eachsubsystem, in special the payloads, needs to be validated.In terms of interoperability, behaviour and requirements con-formity, all the payloads engineering models must present acertain level of acceptance from the OBDH point of view. TheHIL environment is a great opportunity to isolate the possible sources of failures, once each payload and even the OBDH canbe tested on 1-by-1 operation. The Test Reports from the MILenvironment (SATS) should guide this phase and point out thenon-conformities and misunderstandings of the developmentteam (OBDH and payloads). Due to some lack of expertiseof the NanoSatC-BR2 development team, the HIL approachwas not that much exercised and the project was rushed to beready for complete integration. We will discuss the EM andFM integration at the Section IV.IV. L
EARNING L ESSONS AND R EDUCE C OMPLEXITY OF V ERIFICATION W ORK
This section discusses the effect of the V&V processesadopted by INPE for CubeSat standard nanosatellites projects,highlighting the changes introduced by the use of Model-Based approaches. The process is supported by ECSS stan-dards, but it is affected by COTS at very low procurementcost and a simple standardized architecture. The way a spaceorganization deals with downsizing its traditional V&V pro-cess to carry on V&V of nanosatellites is not obvious.It is observed in the SiS V&V process presented in SectionIII that the process applied to nanosatellites is incrementaldue to both the characteristics of the requirements that aremore volatile and the greater importance of interoperabilityin the integration of the nanosatellites subsystems. Due to thevolatility of the requirements and the higher acceptable risk inthe nanosatellites project, the closing of the review documentsis quite delayed, reaching cases in which the release is made acouple of phases later in the development process (see FigureI, the release of the Requirements Baseline and InterfaceRequirement Document) or even not being formally produced(in Software Development Plan and Technical Specification).However, problems are identified when we start to deal withthe spacecraft integration, EM and FM.Both integration phases will point to all kind of misun-derstandings, non-conformities and errors, even mechanical,electrical or logical, or all of them, at the same time. Agreat part of the documents are released during this phasesas result of gaps found during the integration. Thus, manyrequirements and constraints are added to the project to fit thesolutions – reworking hardware/software development is moredifficult than reworking a document – instead of the solutionsto fit the requirements and constraints. This ends up withlack of information on the documents, lack of traceability andvulnerabilities associated with conflicting implementations.Regarding the SiS discipline, the reduced complexity ofverification of nanosatellites has been obtained by INPE withthe lessons learned to support an automatic test generationadopted in the V&V process of traditional satellites. Althoughthe modelling activities are very time consuming, the benefitsof the effective test suite provided allows INPE to increaseconfidence in model-based approaches. However, instead ofeffort in acceptance testing, which does not make sensein the nanosatellite projects, INPE focused on the use ofmodeling approaches to anticipate the detection and treatmentof embedded software-intensive communicating subsystems in ig. 5. OBDH and Payload SLP interoperability modelsFig. 6. InRob Test Architecture instantiated by SATS [14]Fig. 7. Number of Test Cases generated by InRob the development life cycle of SiS. The goal is to avoid softwarerework due to interoperability faults usually evidenced only inthe integration testing.The EM integration is aimed at the verification of everysoftware subsystem interoperability, beyond the mechanicaland electrical integration. Being the OBDH the core of thesatellite coordination, all the EM integration tests focus on howthe OBDH software deals with other subsystems, centralizingtheir control and monitoring. The Test Cases used at MIL andHIL environments can be used at this point as a guide forthe expected behaviour of the OBDH and its payloads. In thiscase, the models can be used as the single source of truth(SSOT). However, to ensure the closing of the EM integrationphase, the space-to-ground integration must be addressed.Not only the spacecraft must be working properly on theinside, it must be controllable from the ground. The model-based approach can be useful here, as the concept of spacecraft operation can be modelled in a higher level than the way it wasdone before with the subsystems. However, between the spaceand ground segments there is a communication channel thatcannot be modelled in the same way preventing us to directlymodel the validation of interoperability between them. So, weuse both the EM model and the Satellite Control Softwaredirectly to verify the complete operation of the spacecraft andexercise possible flight plans for the mission.Ending the CDR, the FM integration can start. This phasedoes not differ much from the EM integration as we are tryingto replicate the expected behaviour found at the EM. Themain differences occur in the replacement of the subsystemengineering models by their flight models. Some of themare more fragile (e.g. solar panels instead of dummy PrintedCircuit Boards - PCBs) or more robust (e.g. aluminium struc-ture instead of a mock-up). The possible problems that canbe found here are more related to the assembly and cabling,items that it is not possible to model or measure in the initialphases. At this stage, the chance of finding logical errors inthe spacecraft software and its operation is lower.For the NanoSatC-BR2 mission, all these lessons werepointed out. They allowed us to learn how to reduce thecomplexity of the V&V process, in qualitative and quantitativeways. The gaps in the team expertise is difficult to by-pass as,most of time, the missions are university-class projects.Therefore, INPE has made progress on research that con-tributes with a model-based approach in terms of (i) alternativemodeling formalisms [17]; (ii) new tools to aim deriving testcases from models; (iii) open architectures to support thetest cases execution. A Scalable Architecture Test System(SATS) based on Arduino computer boards is proposed in[14] . It allows to systematize test scenarios based on theconcept of model and hardware in the loop. The approachcombines Model-Based Testing (MBT) and Model-DrivenEngineering (MDE) techniques to support: (i) specification ofinteroperability requirements, whose behavior is modeled instate machines; (ii) automated software code generation fromthose models to be embedded in Arduino computer boards;(iii) automated generation of nominal test cases focusingon interoperability properties; (iv) extension of models withobustness aspects; and finally (v) automated generation oftest cases focusing on robustness properties. Moreover, afailure emulator mechanism framework (FEM) is proposed in[18] for robustness testing of interoperable software-intensivesubsystems on-board nanosatellite. FEM acts in the communi-cation channel being part of the integration test workbench intwo phases of nanosatellite design: (i) robustness requirementspecification using model in the loop (MIL) and (ii) robustnessvalidation using hardware in the loop (HIL). Both approacheshave been applied in the V&V process of NanosatC-BR2 [17].V. C
ONCLUSIONS AND FUTURE WORK
This work presented the V&V process, used at INPE,applied in nanosatellites projects that follow the CubeSat stan-dard. The structure or even the subsystems of these nanosatel-lites are fully acquired as COTS. Therefore, the V&V processusually adopted in traditional satellites, as recommended byECSS standards, needs to be adapted to reflect the reducedcomplexity of work and the absence of one or more disciplines.We presented the rationale to conceive a V&V processfor software-intensive subsystem on-board nanosatellites de-veloped by INPE aiming to downsize the practices used intraditional satellite V&V process. The rationale highlights theimportance of the interoperability among the OBDH SiS andthe satellite payloads. Being key elements, the success of themission in orbit depends on confidence in their operation.Research opportunities were identified to improve the useof MBT approach, firstly applied in the process of the tra-ditional satellites, and then to anticipate integration testingin the development life cycle of the Cubesat-based spacemissions using InRob. The development of standardized testenvironments using model-based methods and tools allowedthe establishment of integration testing processes for satellitesubsystems that are more effective in time and cost. Thecomplexity of the subsystems, increasing in functionalitiesimplemented by software (SiS) is supported by the systemati-zation of the generation and execution of interoperability androbustness tests provided by inRob, which has shown a strongalignment with the new philosophy of small satellite projects.So, standardisation, systematisation and automation of theV&V process may help to work around problems (unknownrequirements in the begin of the development cycle and theirconstant evolution, immaturity of the stakeholders and the lackof expertise of the development team regarding the specificitiesof software engineering for space area and low budget forcingthe allocation of inexperienced developers in the SiS context)and reach a more compliant results. Furthermore, we believethat this V&V process can have a broader impact to severalembedded systems and infrastructures for critical machines.In the near future, through scientific partnerships withnational and international academic institutions, INPE hopesto consolidate the V&V process, based on a test system thatsupports the approach of evolutionary integration tests forthe development of SiS embedded in nanosatellites. The goalis to use the InRob method and associated tools at scale(model construction, automatic test generation and automated instrumentation in the execution of tests), systematizing theverification of the SiS shipped in the different nanosatellitesthat will constitute the new generation of The Brazilian Envi-ronmental Data Collecting Systems (BEDCS), in accordancewith the CONASAT project.VI. A CKNOWLEDGMENT
EFERENCES[1] R. Twiggs, “Origin of cubesat,”
Small Satellites: Past, Present, Future,Eds: Helvajian H., Janson SW, The Aerosp Press, California , 2008.[2] E. C. for Space Standardization, “SECSS-E-ST-10C: Space eng. -System eng. general requirements,” ECSS, Active Standards, 2017.[3] NASA,
NASA System Engineering Handbook Revision 2 . NASAHeadquarters, 2016.[4] A. Scholz, “Cubesat standards handbook,”
The LibreCube Initiative ,2017.[5] E. C. for Space Standard., “ECSS-E-40 Part 1B: Space eng. – Software– Part 1: Principles and requirements,” ECSS, Active Standards, 2003.[6] J. Kiesbye, D. Messmann, M. Preisinger, G. Reina, D. Nagy, F. Schum-mer, M. Mostad, T. Kale, and M. Langer, “Hardware-in-the-loop andsoftware-in-the-loop testing of the move-ii cubesat,”
Aerospace , vol. 6,no. 12, p. 130, 2019.[7] H. Leppinen, P. Niemel¨a, N. Silva, H. Sanmark, H. Forst´en, A. Yanes,R. Modrzewski, A. Kestil¨a, and J. Praks, “Developing a linux-basednanosatellite on-board computer: flight results from the aalto-1 mission,”
IEEE Aerospace and Elect. Syst. Magaz. , vol. 34, no. 1, pp. 4–14, 2019.[8] A. Alanazi and J. Straub, “Engineering methodology for student-drivencubesats,”
Aerospace , vol. 6, no. 5, p. 54, 2019.[9] C. Venturini, B. Braun, D. Hinkley, and G. Berg, “Improving missionsuccess of cubesats,” 2018.[10] J. Eickhoff, R. Hendricks, and J. Flemmig, “Model based developmentand verification environment,” in , vol. 3. AIAA, dec 2003, pp. 1275–1285.[11] M. Omair Khan, M. Sievers, and S. Standley, “Model-based V&V ofspacecraft avionics,”
AIAA Infotech at Aerospace Conf. and Exhibit2012 , pp. 1–11, 2012.[12] B. Tiseo, V. Quaranta, G. Bruno, and G. Sisinni, “Tailoring of ECSSStandard for Space Qualification Test of CubeSat Nano-Satellite,”vol. 13, no. 4, pp. 295–302, 2019.[13] R. Feldt, R. Torkar, E. Ahmad, and B. Raza, “Challenges with softwareV&V activities in the space industry,”
ICST 2010 - 3rd Int Conf on SwTest, V&V , pp. 225–234, 2010.[14] C. Conceic¸˜ao, “Abordagem sistem´atica de testes de softwarecomunicante embarcado em nanosat´elites com foco emfalhas de interoperabilidade,” Ph.D. dissertation, CSE/INPE,http://urlib.net/8JMKD3MGP3W34R/3TBGC2H, 5 2019, in Portuguese.[15] F. Mattiello-Francisco, E. Martins, A. R. Cavalli, and E. T. Yano, “Inrob:An approach for testing interoperability and robustness of real-timeembedded software,”
Journ. of Syst. and Soft. , vol. 85, no. 1, pp. 3–15, 2012.[16] A. C. Weller, E. Martins, and F. Mattiello-Francisco, “Inrob-uml: umaabordagem para testes de interoperabilidade e robustez baseados emmodelos,”
SAST 2015 , p. 71, 2015.[17] D. Almeida and F. Mattiello-Francisco, “Modeling of the interoperabilitybetween on-board computer and payloads of the nanosat-br2 withsupport of the uppaal tool,” in , vol. 9, 2017.[18] C. Batista, A. Weller, E. Martins, and M. Mattiello-Francisco, “Towardsincreasing nanosatellite subsystem robustness,”
Acta Astronautica , vol.156, pp. 187–196, 2019.2