Frédéric Boniol

Youcef Bouchebaba

Julien Brunel

Kevin Delmas

Thomas Loquen

Alfonso Mascarenas Gonzalez

Claire Pagetti

Thomas Polacsek

Nathanaël Sensfelder

PHYLOG certification methodology: a sane way to embed multi-core processors

The PHYLOG project aims at offering a modelbased software-aided certification framework for aeronautical systems based on multi/many-core architectures. Certifying such platforms will entail fulfilling the high level objectives of the MCP-CRI / CAST-32A position paper. To reach this general objective, we have defined a certification framework based on patterns to express any argumentation; as well as formal and automatic analyses to support the proof of the argumentation. In this paper, we will introduce the certification methodology and apply it on the KEYSTONE platform.

I. INTRODUCTION

A. Context

Aeronautical safety critical systems are subject to certification, meaning that a certification authority assesses the compliance of the product with the regulatory requirements. An accepted means of compliance for an applicant is to show the compliance with a set of adequate standards. A way to show the compliance with a given standard is to prepare, for each high level objective identified by the standard, an assurance case which can be defined as "an organized argument that a system is acceptable for its intended use with respect to specified concerns (such as safety, security, correctness)" [START_REF] David | Current practices in constructing and evaluating assurance cases with applications to aviation[END_REF]. Thus, the applicant provides a certain number of elements that go from design activities, organizational description, development process to V&V (Verification and Validation) operations.

For multi-core-based systems, several standards are applicable, such as the ARP 4754 [START_REF]Aerospace Recommended Practices ARP4754a -development of civil aircraft and systems[END_REF] or the DO 178 C [START_REF]DO-178 ED-12C -Software Considerations in Airborne Systems and Equipment Certification[END_REF]. However, a specific position paper, named Multi-Core Certification Review Item (MCP-CRI) [START_REF]The Use of Multi-Core Processors in Safety-Critical Applications -CRI[END_REF] (also known as the CAST-32A position paper [Cer16]), has been written by aeronautic industries and certification authorities to provide a set of guidances for software planning and verification on those chips. PHYLOG aims at preparing certification activities related to the MCP-CRI / CAST-32A position paper. In particular, the purpose is to provide a framework that allows any applicant to prepare their certification assurance cases.

B. PHYLOG objectives

To reach this general objective, we have defined a certification framework based on:

1. argumentation patterns to express any argumentation. The idea is to organize any argumentation around structured graphical notations diagrams. We have translated most of the CAST-32A objectives to patterns, partly published in [BBB + 18b], [BBB + 19];

2. formal and automatic analyses to support the proof of the argumentation. A pattern comes with a series of evidences that support the reasoning. Among those evidences, two types of analysis are required by the MCP-CRI: interference analysis and safety analysis. We propose several automated analyses to help the applicant provide evidences.

C. Paper objective

The first objective of the paper is to present the overall PHYLOG framework, something which has never been done, as we have only presented pieces here and there. The second objective is to validate the approach by applying it to a real use case composed of an application executing on the KEYSTONE. The paper is organized as follows: in section II, we introduce the overall framework; we present the use case in section III and we apply the PHYLOG methodology to the use case section IV. For that, we have refined some former PHYLOG results.

II. PHYLOG FRAMEWORK OVERVIEW

The PHYLOG framework is schematized in figure 1. There are three inputs: 1) the MCP-CRI / CAST-32A standard, which is the starting point of the methodology, as the applicant must answer its 9 objectives; 2) the detailed design documentation that contains, in particular, the detailed configuration settings and how the multi-core is programmed (e.g. bare-metal, hypervisor); 3) some other external documents, such as the documentation of the multi-core hardware or the results of some external activities (e.g. FHA derived objectives for the applications hosted by the multi-core).

The framework itself contains two boxes: argumentation for the methodology and model-based formal analyses for the set of proposed analyses. We introduce both contributions in the next sub-sections.

A. Argumentation-based certification

Several papers have proposed high level strategies to tackle the MCP-CRI / CAST-32A. [START_REF] Agirre | On the Tailoring of CAST-32A Certification Guidance to Real COTS Multicore Architectures[END_REF] has adapt the MCP-CRI certification objectives and has rephrased some of the requirements. [START_REF] Athavale | Flight safety certification implications for complex multi-core processor based avionics systems[END_REF] proposes some leads to tackle safety issues. However, we are the first to define clear patterns for several objectives.

The applicant must fulfill the 9 MCP-CRI / CAST-32A objectives (P1, P2, RU1, RU2, RU3, RU4, S1, S2, and EH). Some simply require descriptive enumeration, such as planning (P1 and P2). Some, on the other hand, require more complex activities. Refining those as sub-objectives (or even deducing justifications) is not a simple break-down that leads to a set of activities. Instead, it is necessary to detail sub-objectives and to explain both why the inference step is correct and why it is sufficient to conclude the objective from these justifications. Thus, more than a decomposition, we must associate justifications to a certification objective and also the reasons that allow the passage from justifications to conclusion.

There is a tremendous literature on how to build an assurance case and on how to make a graphical or textual representation. On the academic side, we can cite the Goal Structuring Notation (GSN) [START_REF] Mcdermid | Support for safety cases and safety arguments using sam[END_REF], [START_REF] Kelly | The goal structuring notation /a safety argument notation[END_REF], Claim-Argument-Evidence (CAE) [START_REF] Emmet | Graphical notations, narratives and persuasion: a pliant systems approach to hypertext tool design[END_REF], a textual approach from Rushby [START_REF] Rushby | Understanding and evaluating assurance cases[END_REF], and Justification Diagram (JD) [START_REF] Polacsek | Validation, accreditation or certification: a new kind of diagram to provide confidence[END_REF], [START_REF] Duffau | Support of justification elicitation: Two industrial reports[END_REF]. On the standardization organism side, there is the Structured Assurance Case Meta-model [START_REF] Omg | Structured assurance case meta-model (sacm)[END_REF], and the Generic Methodology for Verification and Validation [START_REF] Roza | The generic methodology for verification and validation to support acceptance of models, simulations and data[END_REF].

Concerning the usage of argumentation on COTS, the authors of [START_REF] Forsberg | Emerging cots-based computing platforms in avionics need a new assurance concept[END_REF] provide some material to argue that a COTS possesses a set of high level properties (called overarching properties) ensuring its airworthiness. The presented methodoglogy is not designed to handle such a standardagnostic reasoning since the certification requirements are already provided by the MCP-CRI. Nevertheless the argumentations and analyses presented in the remainder of this paper can be used as building blocks for the high level argumentation presented in [START_REF] Forsberg | Emerging cots-based computing platforms in avionics need a new assurance concept[END_REF].

All of them rely on the model defined by Stephen Toulmin [START_REF] Toulmin | The Uses of Argument[END_REF], which focuses on three concepts: claim, strategy and evidence (or sub-claim). The claim is the conclusion, the objective to demonstrate. Evidence are the facts on which the claim is based and rely on given elements provided by external knowledge or specific V&V activities. The strategy adds information about the reasoning and justifies the passage from evidence to claim. A strategy may come with a backing that is an explanation of why the strategy is indeed applicable.

In the rest of the paper, to represent our argumentations, we have chosen an agnostic notation approach based on a simple graphical notation (which is kind of an abstract syntax) compliant with all existing notations (which are kind of a concrete syntax). We will not present all patterns but will instead focus on the Resource Usage 3 (RU3) objective and the Error Handling (EH) objective. Let us first provide a reminder of these objectives.

Objective RU3

The applicant has identified the interference channels that could permit interference to affect the software applications hosted on the multi-core processor cores, and has verified the applicant's chosen means of mitigation of the interference. Figure 2 shows its transcription as a pattern. Evidence (E1) states that the existing interferences have been identified and classified. This has been achieved because an expert, who masters the architecture, has reviewed and double-checked two activities (strategy (S2)). Evidence (E3) points to a report that summarizes which interferences have been identified, how they have been identified, and why the identification is sound and complete. Evidence (E4) points to a safety report that details the effects of each interference on the hosted applications. Those effects can be expressed in different units (e.g. delay, bandwidth). If expressed in delays, the questions are what will be the impact of interference on the WCET (Worst Case Execution Time) and/or on the WCRT (Worst Case Response Time) of each application? and are these slow downs acceptable? From this information, the applicant has defined adequate means of mitigation to prevent, for instance, unacceptable effects. Evidence (E2) collects all those means of mitigation, how they mitigate each unacceptable interference and how they were verified. The applicant can argue the compliance with RU3 because an expert, who masters the architecture, has reviewed and double-checked that each interference has been correctly mitigated (S1).

The applicant shall also identify the possible hardware failures, their impact, and the means of mitigation. This requirement is called error handling -EH in the MCP-CRI.

Objective EH The applicant has identified the effects of failures that may occur within the MCP and has planned, designed, implemented and verified means (which may include a 'safety net' external to the MCP) commensurate with the safety objectives, by which to detect and handle those failures in a fail-safe manner that contains the effects of any failures within the equipment in which the MCP is installed. As depicted by Figure 3, the argumentation structure for EH is quite similar to the one of RU3. The top level claim is EH with a shorten textual description. The applicant can argue the compliance with EH because a traceability matrix (for instance) shows the coverage between the identified failure modes and the associated mitigation means (S1). Evidence (E1) is a report that collects all the identified failure modes and their effects [START_REF] Villemeur | Reliability, availability, maintainability and safety assessment[END_REF]; whereas evidence (E2) describes the associated mitigation means. The latter should enforce that the effects of the failure modes are handled in a fail-safe manner (i.e contained within the equipment on which the multi-core processor is installed).

B. Interference and safety analyses

As illustrated before, a pattern comes with a series of evidences that support the reasoning. Among these evidences, two types of analyses are required by the MCP-CRI: interference analysis and safety analysis. However, these two kinds of analysis are made quite independently from each other and often rely on different abstractions and tools (e.g. WCET static analysis [AEF + 14] for interference and MBSA -model based safety assessment -[BV Å+ 03] for safety). An idea to overcome this divergence is to unify both analyses and to base them on a common abstract representation of multicore processors. For that purpose, we have developed a modelling language, PML (PHYLOG Meta-Model) [BBB + 18a], representing a multi-core-based system.

1) Interference analysis: Due to resource sharing, coupling exists at the platform level, which can cause interferences between the applications. Certification requires interference situations to be fully controlled and mastered in any configuration for safety critical applications, as explained for resource usage 3 -RU3. Moreover, the applicant shall also identify the shared resources and shall describe a usage domain for each of them (how the resources are shared and how to prevent resource capabilities from being exceeded). This requirement is called resource usage 4 -RU4 in the MCP-CRI.

We have defined two approaches to compute topological interference in [BBB + 18a], [START_REF] Boniol | Identification of multi-core interference[END_REF] and cache coherence interference [START_REF] Sensfelder | Modeling Cache Coherence to Expose Interference[END_REF]. With these solutions, the argumentation pattern can directly be filled. Notice that some complementary analyses are proposed in the literature. The first widespread approach is intensive benchmarking to observe interference and part of their effects [START_REF] Nowotsch | Leveraging multi-core computing architectures in avionics[END_REF], [RGG + 12], [GJlR + 15], [START_REF] Cavicchioli | Memory interference characterization between CPU cores and integrated gpus in mixed-criticality platforms[END_REF] As an example, [PSJ + 19] studies the impact of Time Division Multipla Access (TDMA) and Acquisition-Execution-Restitution (AER) execution models on interference on the NXP T2080 platform. The second approach is more recent and proposed a profiling of applications [START_REF] Girbal | METrICS: a measurement environment for multi-core time critical systems[END_REF] to quantifiy the transactions. With these characterization methods, the argumentation pattern for RU3 must be adapted to link benchmark and envelope with exact interference and effects.

2) Safety analysis: Due to the high integration density, the complexity of internal components and the mix of hardware / software inside multi-core chips, their behaviors under random failures are hard to define and to characterize. Thus, two specific objectives are defined for dependability and safety issues in the MCP-CRI / CAST-32A. First, the applicant shall argue that the critical configuration settings are static and are protected against inadvertent changes at run-time. This requirement is called resource usage 2 -RU2 in the MCP-CRI. Second, the applicant shall also identify the possible hardware failures, their impact and the means of mitigation. This requirement is called error handling -EH in the MCP-CRI.

As identified by [START_REF] Prosvirnova | AltaRica 3.0: a Model-Based approach for Safety Analyses[END_REF], performing safety analyses with classical techniques like FMEAs, fault-trees or Markov chains raises two main challenges. First, since multi-core are highly hierarchical and complex systems, their modelling with classic formalisms will be cumbersome and error-prone. Second, classic formalisms require an in-depth knowledge of the multicore architecture and internal components failure modes. Such knowledge is seldom available, since the chip makers will not commit themselves to provide detailed information about multi-core architectures.

To tackle these challenges, we have developed a pragmatic model-based safety assessment in [BBB + 18b], [BBB + 19], which can be performed with the first functional level of the multi-core (like the one depicted in Figure 4) and abstract failures modes based on the services provided by components.

III. USE CASE: ROSACE EXECUTING ON THE KEYSTONE

Before going into further details, we introduce the use case on which we apply the PHYLOG methodology: an application executing on a multi-core. The application is the ROSACE [PSG + 14] longitudinal controller, which has been extended to include neural network representations of aerodynamic coefficients in the flight dynamic model. The application runs on bare metal on the KEYSTONE TCI6630K2L [START_REF]TCI6630K2L Multicore DSP+ARM Key-Stone II System-on-Chip[END_REF] from Texas Instruments, which is depicted in Figure 4.

A. KEYSTONE

This platform is composed of:

1) an eight C66 DSP pack, in which each core comes with dedicated L1 and L2 caches, and a memory extension and protection unit (MPAX); 2) a four ARM pack, in which each core comes with dedicated L1 caches, and a memory management unit (MMU); Due to the complexity of flight control laws (including guidance, mode selection, protection, and control), and a high safety level, some flight parameters are critical to ensure the good behaviour of the aircraft. Thus, the availability of all or part of system states has become essential, and erroneous values can reduce performance or stability. A classic approach consists in estimating these parameters thanks to signal processing (Extended Kalman Filter [START_REF] Seren | Adaptive extended kalman filtering for virtual sensing of longitudinal flight parameters[END_REF]) or model-based techniques which propose to embed all or part of the aircraft flight dynamic model. This model includes some mechanical parameters like mass, inertia, and aerodynamic coefficients which represent forces and moments applied on the system in motion. Such aerodynamic coefficients are often issued from CFD (computational fluid dynamics) computations, wind tunnel or flight testing. Usually, these data are only available in the form of look-up tables, which are not very convenient for on-board implementation, and that is why analytical and differentiable approximations are preferred, especially because of their lower memory requirements. Neural networks are good candidates for representing such complex nonlinear parameters [START_REF] Hardier | Recurrent rbf networks for suspension system modeling and wear diagnosis of a damper[END_REF].

M a = SP d lC m (1)
where S, P d , l refer respectively to reference area, dynamic pressure, and mean aerodynamic chord. The aerodynamic coefficient C m can be written as

C m = C m0 + C mδ δ e + C mα α + C mq * f (q, V ) (2)
where δ e , α, q, V are, respectively, elevator deflection, angle of attack, airspeed, and pitch rate. Coefficients C m0 , C mα , C mq are non-linear effects mainly depending of M the Mach number.

We use a Radial Basis Function Network (RBFN) to approximate the MISO (multi input -single output) equation 2 as Finally, by considering 5 cells for each of the 4 inputs, we obtain an RBFN with 625 cells with optimized centers and radii. For validation and code generation purposes, the RBFN is implemented in MATLAB/Simulink as presented in Figure 6, and the efficiency of the RBFN is illustrated in Figure 8.

C N N m = n cel k=1 w k exp   - 4 j=1 e j -c k,j r k,j 2   + b (3)

IV. APPLICATION OF PHYLOG METHODOLOGY ON THE KEYSTONE

In this section, we apply the PHYLOG methodology for the system defined previously: ROSACE executing on the KEYSTONE.

A. PML overview

Both EH and RU3 heavily rely on a mastering of the multi-core processor architecture. Moreover, a modelling of the hardware and software components of the platform must be achieved prior to any safety or interference analysis. We propose to perform this modelling using the PHYLOG Modelling Language (PML), whose model is depicted by the Figure 7. The model contains 3 types of components: hardware components in yellow, service components in green and software components in blue. • Composite (e.g. CorePac), i.e a composition of hardware components.

1) Hardware components: The classification of hardware components proposed in PML is directly inspired from the initiator-target model introduced in [BR14], [JMB16], [MJB16], [MJB

The components of Figure 4 are colored according to their type, the color code being: red for smart initiators, blue for transporters, green for targets, and orange for non-smart initiators.

2) Software components: The software components that will be executed by the platform are user applications. At this step, we consider only bare metal applications and partitioned non preemptive schedules computed off-line. Thus, each piece of software is allocated to a unique initiator. The allocation of ROSACE is defined in Figure 5: functions altitude hold, vz control, az control, and h filter are allocated on the ARM 0 . Any software may request some data that are potentially distributed over several components. To retrieve these data, the initiator executing the software initiates communications within a multi-core called transactions. Definition 4.2 (Transaction): A transaction starts from an initiator and follows pre-defined path(s) to its final target, a transaction may include the response(s) of the target.

3) Service components: The transactions are issued thanks to a platform service call. The idea of PML is to abstract the platform as a set of services. Compared to what we have presented in [BBB + 18a], we have developed a second version based on the notion of service. Definition 4.3 (Platform service): A platform offers a set of services that can be called upon by the initiators and that generate transactions. We have identified the following services:

• EXECUTE: execution of a piece of software on some core;

• LOAD: retrieval of some data from a given target t by an initiator i.

• STORE: writing of some data to a given target t by an initiator i.

• COPY: copy of some data from one memory area t 1 to another t 2 by a non-smart initiator i.

• AUTHORIZE: forbidding of transactions outside of an authorized address; the set of authorized addresses is defined at configuration by a table memorized by the service.

• DISPATCH: handling of simultaneous accesses to subsequent services.

B. PML representation of the KEYSTONE

1) General model: The instantiation of the PML model for the KEYSTONE provides 1) The physical components of the platform depicted by the Figure 4 categorised according to the Initiator-Transporter-Target model, 2) The software components, here ROSACE has been split into three pieces, 3) The physical links between physical components (used or not), 4) The services provided by each platform component. For the KEYSTONE, we consider that all components provides both the STORE and LOAD services, an Initiator additionally provides a unique EXECUTE service, a Transporter (resp. Virtualizer) provides a unique DISPATCH (resp. AUTHORIZE) service.

At this step, the platform is said to be "unconfigured", that is, the relations allocated and connected (for services) are unknown. Without any further information, any connection between services is possible (if a physical connection exists between the components providing these services) and any software allocation is possible.

Due to the lack of space, we do not provide the full instantiation of the unconfigured KEYSTONE platform1 . These instantiations can be tedious to perform for commercial platforms (like the KEYSTONE). That is why a simple Domain Specific Language (DSL) has been defined and integrated in a translation tool.

2) Configuration of the platform:

The platform can then be configured by populating the allocation and connection relations. In our case, the allocation, mapping, and schedule over the platform are fully static:

• the ROSACE application is split in three pieces, namely ROSACE 0 allocated to ARM 0 , ROSACE 1 allocated to ARM 1 , and the Neural Network (NN) allocated to the DSP 0 ; • ARM 0 and ARM 1 store their code and data in the DDR memory. DSP 0 stores its code and data in its local SRAM. • All global variables exchanged between the ARMs and DSP are stored in the global SRAM controlled by the MSMC.

These information make it possible to connect the services of the platform used to perform the EXECUTE, LOAD, and STORE requests of the applications. An excerpt of the KEYSTONE service connection 1 is provided in Figure 9. In this excerpt, we do not consider the private memories and caches, nor the TeraNet connecting the MSMC to the cores' memory management units (MPAX for DSPs, MMU for ARM). Nevertheless, this simple excerpt contains the main types of components, allowing it to illustrate the different kinds of transactions transiting through the platform.

The software components uses the EXECUTE, LOAD, and STORE services provided by the cores on which it is allocated. The initiator (core) does not request any additional service to provide the execution service. Concerning LOAD and STORE services, the ROSACE application will request some accesses to the DDR and the MSMC SRAM. Consequently, the LOAD and STORE services of the initiators are connected to the LOAD and Since MPAX and MMU are virtualizers, they provide an AUTHORIZE service enforcing the memory allocation considered in the configuration. For instance, the DSP is only allowed to access the MSMC SRAM, so any transaction involving a communication with the DDR will be rejected by the AUTHORIZE service of the MPAX.

Eventually, the transporter components, like the MSMC, that may be involved in several simultaneous transactions provide a DISPATCH service handling this concurrency. For instance, in Figure 9, the DISPATCH service of the MSMC is able to handle concurrent loads and stores if the target of these requests are different. The potential conflicts are depicted in Figure 9 by the dotted lines using the same service.

C. Interference analysis on the KEYSTONE

Back to RU3 pattern of Figure 2, strategy (S2) needs to identify all interferences (E3) and to classify them (E4).

1) Interference identification (E3):

Existing interference analyses consists in enumerating all combination of transactions (more or less deeply). An interference analysis applied to a service-based modelling identifies the simultaneous service calls that may cause a degradation of QoS. A transaction is a sequence of service calls in PML and looking at Figure 9, we can observe the LOAD from ROSACE 0 on ARM 0 to the LOAD of the Target DDR (sequence of arrows and sevices). Thus, if there exists a service s reached by two arrows from two services s 1 and s 2 , it means that s can be used by two transactions from s 1 and s 2 . If the transactions arrive at the same time on s, they will provoke a contention on s, and one of them will have to wait until s becomes free again. From that point of view, an "interference channel" is a set of services targeted by simultaneous transactions produced by different initiators.

In the system under study, shown in Figure 9, 12 services can be simultaneously reached from different initiators:

• the three services of the AXI component (reached for instance when the two ROSACE i initiators run two LOAD or STORE transactions); • the five services of the MSMC component (reached for instance when NN and one of the ROSACE i initiators try to access at the same time the SRAM or the DDR memory); • and the four services of the SRAM and DDR components.

Thus, these services are part of the interference channels that can occur in the system.

To answer objective RU3, one needs to identify all the interference channels and all the interferences generated by simultaneous transactions involving these channels. For that purpose the KEYSTONE case-study PML model is transformed into an interference oriented view. This view is modeled in IDP 2 , a knowledge-based system allowing formal modeling and analysis in a first-order logic language. Based on this formal modeling, an exhaustive analysis identifies:

• 32 binary interference transactions (i.e., involving 2 initiators), and 32 ternary interference transactions (i.e., involving the 3 initiators); • 10 interference channels, i.e., 10 sets of shared services that can be simultaneously reached by at least one of these 64 interference transactions. These interference channels are: 1) {msmc-dispatch}, involved in 12 binary transaction and 30 ternary transactions, 2) {msmc-dispatch, msmc-store-sram, srm-store}, involved in 3 transactions 3) {axi-dispatch, msmc-dispatch}, involved in 8 transactions 4) {axi-dispatch, axi-store, msmc-dispatch}, involved in 2 transactions 5) {axi-dispatch, axi-load, msmc-dispatch}, involved in 2 transactions 6) {axi-dispatch, axi-load, msmc-dispatch, msmc-loadsram, sram-load}, involved in 1 transaction 7) {msmc-dispatch, msmc-load-sram, sram-load}, involved in 3 transactions 8) {axi-dispatch, axi-load, msmc-dispatch, msmc-loadddr, ddr-load}, involved in 1 transaction 9) {axi-dispatch, axi-store, msmc-dispatch, msmc-store-ddr, ddr-store}, involved in 1 transaction 10) {axi-dispatch, axi-store, msmc-dispatch, msmc-storesram, sram-store}, involved in 1 transaction.

Classifying the extra-cost due to these interference channels would require testing each of these 64 interference transactions. However, it is possible to take advantage of the symmetries of the architecture to reduce the number of transactions to run. For instance, if we notice (and can argue) that the two ARM blocks are symmetric and that the two ROSACE i initiators are able to produce similar LOAD and STORE requests, then, for each of the 10 previous interference channels, it is possible to regroup the transactions by symmetric classes, i.e., groups of transactions that produce the same effect when crossing the shared ressources. For instance, let us again consider the first interference channel {msmc-dispatch}. Among the 12 binary transactions crossing it, we have:

• t 0 = ROSACE 0 ddr-store NN sram-load • t 1 = ROSACE 1 ddr-store NN sram-load
Thanks to the symmetry between ARM 0 and ARM 1 and between ROSACE 0 and ROSACE 1 , t 0 and t 1 will produce the same worst-case interference on msmc-dispatch. To classify the interference on msmc-dispatch, it is sufficient to only focus on t 0 instead of the two of them. Using the IDP formal modeling, we can show that it is sufficient to consider only 6 transactions over the 12 double transactions involved in the {msmc-dispatch} interference channel to classify it.

2) Interference classification: Once the interferences have been identified, the second step is to classify them. For that purpose, one benchmark is associated with each interference transaction. For the sake of conciseness, let us consider the interference transaction:

t = ROSACE 0 sram-store ROSACE 1 sram-store
The interference channel involved in t is {axi-dispatch, axistore, msmc-dispatch, msms-sram-store, sram-store, }. To classify the cost of t, we define a benchmark composed of two processes: p 0 (resp. p 1 ) hosted by ARM 0 (resp. ARM 1 ) simulating STORE requests from ROSACE 0 (resp. ROSACE 1 ). p 0 and p 1 execute the same infinite loop:

while(1) { time1 = current cycle number assembly(str r9 [r8]) time2 = current cycle number d = time2 -time1 } d = time2 -time1 denotes the duration to store the content of register r9 at the address contained in register r8. Only the d parameter produced by p 0 is measured. Figure 10 shows the variation of d. In the first part of the trace, p 0 runs alone. d approximatively varies around 158 clock cycles). At time 460, p 1 runs on ARM 1 , causing an interference. Then d increases to 180 cycles. At time 900, p 1 stops. The value of d returns to 158. Following this benchmark, running two STORE transactions in parallel on ARM 0 and ARM 1 can lead to an extra cost of 14%. 3) indicates that a safety assessment must be performed to identify the possible failure modes of the platform and their safety impact for the considered applications. Such an assessment can be performed using Model-Based Safety Assessment (MBSA) using the service oriented representation of the platform provided in the Figure 9.

1) Modelling of the platform: The modelling of the platform is based on a library of reusable components formalized with the mode automata [START_REF] Rauzy | Mode automata and their compilation into fault trees[END_REF]. Such a formalization enables us to: 1) be generic and formal, 2) implement the following definitions as a library of components coded with ALTARICA, 3) use pre-existing tools to perform automatic safety assessments.

Up to now, there have been very few FMEA identifying the failure modes for a given platform. This can be explained by the in-depth architecture knowledge required to perform an FMEA, and by the reluctance of chip makers to (legally) commit themselves to provide a detailed FMEA. Therefore, the failure modes are derived from pragmatic reasoning. In the remainder of the paper we consider: 1) err: the component does not provide a proper service, 2) lost: the component does not provide anything. These abstract failure modes, and the link with concrete failure modes, are summarized in Table I The applications are affected by the LOAD/STORE transactions failures, which result from the considered atomic component failures. For instance, in Figure 9, if ARM 0 asks to LOAD a data from DDR, and if the MMU is lost, the LOAD service to DDR is no more provided to ARM 0 . Similarly, if the DSP asks to STORE a value in the SRAM, and if the MSMC is err, then an erroneous value is stored in the SRAM, corrupting its content.

The impact of the atomic components' (initiator, target and transporter) failure mode on the incoming transactions are modelled using the mode automaton formalism. Once these local safety effects are modelled, the analyst can instantiate and connect these component to provide the model of the complete platform.

The platform model 3 built for the KEYSTONE is depicted by Figure 11. Since the components of the library model the behavior of initiators, transporters, and targets, the obtained safety model can be easily deduced from the service-oriented architecture depicted in Figure 9. 2) Safety objective assessment: Let us consider that the loss of any application (ROSACE 0 , ROSACE 1 or NN) is a feared event, called FC. Thanks to CECILIA-OCAS, we are able to automatically compute the smallest combinations of 3 the complete ALTARICA model is available at https://www.onera.fr/sites/ default/files/274/ERTS material.zip physical failures (so-called minimal cutsets) leading to FC. The analyzer provides a set of single failures triggering FC, the most obvious ones being the direct loss of the resource upon which the application directly rely on, that is: 1) the loss or erroneous behavior of the executing unit, i.eDSP for the NN and the ARM for ROSACE, 2) the loss or corruption of the target, i.e DDR for ROSACE and the SRAM for both ROSACE and the NN, 3) the loss of a transporter on the transaction path to the final target, i.e the MPAX and the MSMC for the NN and the MMU, AXI Bus and the MSMC for ROSACE.

In addition to these obvious failures, the assessment is able to detect some failure propagation through successive data exchanges between the NN and ROSACE i . For instance, an erroneous DDR leads to an erroneous providing to the LOAD service for ROSACE i applications. Because of this erroneous LOAD, the applications then perform an erroneous STORE in the SRAM, eventually resulting in the erroneous behaviour of the NN itself. The identification of such failure propagation is paramount to the safety assessment of platforms implementing robust partitioning to enforce safety.

V. CONCLUSION

We have presented the PHYLOG framework and applied it to a real use case. We believe the approach to be valuable and adapted to certification. Our patterns and analyses have been presented to EASA, who are open to the idea of applicants relying on these kinds of techniques.

PHYLOG will end in December 2020. By then, we will put our argumentation patterns online. We will describe the PML formalism more in details. We will refine the interference analysis to take into account symmetries. We will develop automated transformations from PML to IDP and ALTARICA.

Fig. 1 :

 1 Fig. 1: Overview of the PHYLOG framework

RU3:

  Fig. 2: RU3 pattern

Fig. 3 :

 3 Fig. 3: Justification pattern for EH

Fig. 4 :Fig. 5 :

 45 Fig. 4: Keystone -simplified view

Fig. 6 :

 6 Fig. 6: SIMULINK implementation of the 625 cells RBFN

  Fig. 7: PML model

Fig. 8 :

 8 Fig. 8: Temporal simulation of a climb manoeuvre -blue: C m -red: C N N m

Fig. 9 :

 9 Fig. 9: Excerpt of the KEYSTONE service-oriented architecture

Fig. 10 :

 10 Fig. 10: Interference ROSACE 0 sram-store ROSACE 1 sram-store

Fig. 11 :

 11 Fig. 11: Safety model of the KEYSTONE platform

  Transporter (e.g. bus), i.e any intermediate component between initiators and targets. A Transporter can be a Virtualizer (e.g. MMU), i.e any intermediate component between initiators and targets providing a virtual resource segregation. A Transporter can contain an Arbiter (e.g. Serializer), i.e a component handling the concurrent accesses to a given resource.

	Definition 4.1 (Initiator-target model): A multi-core is composed of four types of components:
	• Initiator, which is subdivided in two types. Smart initia-tor (e.

+ 17]

. g. core), i.e components which can initiate single transactions through the architecture to target components. Non smart initiator (e.g. DMA), i.e components which can only initiate dual transactions (i.e with two targets at the same time);

• Target (e.g. DDR or PCIe), i.e end-components targeted by initiators;

•

  .

	Component family	Abstract FM	Comments	Example of concrete FM
	Core	err lost	mis-execution and corrup-tion of LOAD/STORE trans-actions no software execution	Register corruption by SEU OPCODE corruption
	Memory	err lost	LOAD/STORE a corrupted data no LOAD/STORE service	Memory area corruption DDR controller stalled
	Interconnect	err lost	corruption of the transac-tions transactions are not dis-patched	Internal queue corruption Queue overflow

TABLE I :

 I Atomic component failure modes

the interested reader can find the diagrams at https://www.onera.fr/sites/ default/files/274/ERTS material.zip

https://dtai.cs.kuleuven.be/software/idp


Pierre-Julien Chaine
email: pierre-julien.chaine@airbus.com

Marc Boyer
email: marc.boyer@onera.fr

Claire Pagetti
email: claire.pagetti@onera.fr

Franck Wartel
email: franck.wartel@airbus.com

TSN Support for Quality of Service in Space

Keywords: Time Sensitive Network (TSN), Embedded Networks, Satellites, SAVOIR-OSRA, Ethernet

The European spacecraft industry has developed guidelines for generic satellite development known as SAVOIR (Space AVionics Open Interface Architecture). While the current satellites on-board networks implementations are compliant with this standard, their evolution opportunities are strongly limited. New missions and new clients are always more demanding on performance on-board, leading to the conclusion that the satellite embedded network must be upgraded. One opportunity appears with Time Sensitive Networking, an IEEE Ethernet technology capable of supporting both real-time and high-bandwidth traffic. The goal of this paper is to discuss, in a qualitative study, how TSN protocols can help to integrate Quality of Service in new generation satellites.

I. SATELLITE ARCHITECTURE OVERVIEW

A. Introduction

For a long time, agencies and space companies, at prime and supplier levels, have raised the need of increasing the level of reuse and standardization in spacecraft avionics systems in order to improve efficiency and reduce development costs. This has led to studies and initiatives which are now federated under the Space Avionics Open Interface Architecture (SAVOIR) [START_REF]SAVOIR Functional Reference Architecture[END_REF] initiative through different working groups.

SAVOIR is, in a way, a reference to which any satellite manufacturer can rely on when designing a satellite. Plus, it does not contain any industrials' proprietary information and therefore is a good support for discussions and publications dealing with satellite architectures. SAVOIR vocabulary and reference architecture will be the terminology used in the paper.

B. SAVOIR reference architecture

The SAVOIR framework defines the SAVOIR Functional Reference Architecture based on the needs of all kinds of missions (scientific, telecommunication, earth observation, etc.). For the SAVOIR Advisory Group, the term avionic is defined as a set of key elements of an on-board system, e.g. hardwares, softwares and interfaces of the satellite platform, in charge on ensuring the good behaviour of the satellite and handling payload data. The SAVOIR Functional Reference Architecture suggests a physical implementation for the electronic units of the platform; the On-Board Computer (OBC) architecture and the payload units. It aims at defining standard building blocks and their associated functions. It focuses on data compliant interfaces interconnecting the blocks. In order to be relevant to a sizeable range of mission, generic specifications, considered as a common-core of avionic specifications have been gathered in several SAVOIR documents. An example of such a requirement is the presence of an attitude and orbit control function.

C. Current Satellite Architecture

Our representative generic satellite network topology shown in Fig. 1 is compliant with SAVOIR reference architecture: it contains several equipments corresponding to different functions interconnected with communication links.

First of all, this architecture is split in two parts: Payload and Platform. On the one hand, the payload is the purpose of the satellite, it is the part of the satellite that generates added value for our clients, it is specific to each and every mission. Generally, the payload is composed of instruments such as antennas or transponders for a telecommunication satellite, telescopes or cameras for an Earth observation satellite, or any form of scientific instruments for a scientific mission (radiation sensors, magneto-sensors, etc.).

On the other hand, the platform is what allows the satellite to achieve its mission. If this part of the satellite does not work properly, the satellite is useless or might even be lost. The platform is composed of all the systems and subsystems that ensure a nominal behaviour of the satellite. Some notable systems are the Power Supply system, the Attitude and Orbit Control Subsystem (AOCS), the control and monitoring of the payload status, the telecommunication with ground stations system, etc.

The architecture itself has one (duplicated) On-Board Computer or OBC. This OBC is the master that manages all the platform equipments. Using a platform bus, it handles a polling mechanism to all the sensors or actuators, being eventually gathered in a Remote Interface Unit -RIU -also called Data Concentrator. OBC N, for Nominal, (and OBC R, for Redundant) is also hosting AOCS functions. To do so, it gathers information from several sensors, including one or several Star Trackers and Inertial Measurement Units, processes and exploits them in order to control the propulsion system, or the wheels and magnetorquers of the satellite. OBC is also connected to a data storage system, usually a solid state mass memory, mainly used for storing payload data, which is connected to the instruments through a payload network. Finally, it is generally in charge of routing both platform and payload telecommand and telemetry over command & control and mission datalinks i.e. between the communication subsystem and the equipments of the satellite.

In order to avoid single points of failure (for reliability and availability purposes), the network itself, platform and payload, is mirrored. There are always 2 distinct links from one device to one other. On the platform side, as well as on the payload side, there is only 1 active bus at any given time, resulting in a cold redundancy scheme. On the payload side, there is also only one active payload switch. This active switch is constantly monitored in order to be able to trigger the other switch in case of failure.

D. Current Satellite Network

Let us now focus a little bit closer on the communication links. As mentioned in the previous section, there are two interconnected networks in our generic satellite architecture: the platform and the payload networks.

On the one hand, the platform network is in charge of conveying all the necessary information in order to guarantee the nominal behaviour of the satellite. It transmits data from sensors (position, magnetic field, temperature) as well as, among others, flight control commands. This kind of traffic, often described as time critical traffic, requires bounded latency and low jitter communications. However, due to the small size and small volume of messages, a low data rate is enough to achieve the platform needs. In general, the platform network is implemented using a dual MIL-STD-1553 bus [Dep78] or CAN [ISO16] bus.

On the other hand, the payload network requires a very high data rate in order to convey the huge amount of raw data generated by the payload instruments such as pictures from optical instruments (GAIA, SPOT), telemeters from a weather sensor or IoT (Internet of Things) data. However, the constraints are less stringent for a payload network: a delay in the packet communication path will not impact the nominal behaviour of the satellite. The payload network is based in general on SpaceWire [START_REF]Spacewire-Links, nodes, routers and network[END_REF].

II. OPPORTUNITY FOR A UNIFIED TSN NETWORK

A. Reasons for a change

Although the actual architecture works perfectly fine, it has started to show its limits: new instruments and more generally new equipments are capable of generating gigabits of data that the network cannot handle in its current version (100Mbits/s on a SpaceWire network). Using a gigabit-capable network could allow satellite users to access this huge amount of raw data. Furthermore, Spacewire bus is only used in the spacecraft industry, thus its development and update are quite expensive. Using a technology based on Ethernet and COTS -Commercial-off-the-shelves -components shared, for some parts or as a whole, with other industrial sectors (automotive, industrial automation, aeronautics, etc.) could help lower the overall price of the satellite network. Having a wide-spread technology could also facilitate the interaction between the spacecraft industry and the academic world. Finally, adding Quality of Service mechanisms provided by TSN could ease the integration of an increasing number of equipments onboard.

Thus, an Ethernet (and even a TSN)-based network is a path to investigate in order to define the upgrade of the satellite onboard network. However, the behaviour of Ethernet networks is often complex and non deterministic in general. Plus, the hardware available in the market has not been qualified for a space environment yet. Finally, the current platform sensors do not have any Ethernet interface, there is hence a risk of redesigning some "legacy" devices. The interest of TSN over the current technologies (1553 and SpaceWire) really needs to be discussed.

B. Challenge

To determine whether a unified TSN-based network could be a viable architecture for the next generation of satellite, independently from the already identified possible limitations (II-A), we need to answer the following question: We provide some answers in the next sections.

Is

III. ON-BOARD NETWORK: CURRENT AND FUTURE

REQUIREMENTS

This section introduces the requirements that a future unified network would have to fulfil. The specification of the requirements that we will use for the rest of the study will be based on two elements: the current (refined) and future (expected) requirements and OSRA-NET, an ESA-funded network specification.

A. Challenge

One may think that describing the current and future requirements would be easy, however today, these requirements are not explicitly formulated and thus they need to be refined. Indeed, in the current on-board network specification, many of them suffer from over-specification i.e. being more inherited from the currently deployed network technology than driven by the satellite architecture itself. Hence, the first job will consist in identifying this over-specification.

Once this has been done, the network requirements will be classified into two categories: performance & real-time properties requirements on the one hand and FDIR -Fault Detection Isolation and Recovery requirements on the other hand. The rest of the paper will deal with the first category of requirements only.

B. OSRA-NET: SAVOIR Network Specification

A specific SAVOIR document focuses on the network aspects of the functional architecture: OSRA-NET [START_REF]OSRA Communication Network Specification[END_REF]. The goal of this On-Board Software Reference Architecture Network Communication Specification (OSRA-NET) is to provide generic requirements related to the on-board communications needs of a satellite. It has been built by taking into account the foreseen needs for the on-board application of future missions.

Definition 1 (End-point, End-system). Component of network that needs to transmit or receive data. It is called end-point because this component will not forward the messages it receives to another network element (by opposition to a switch). It is also called End-System (ES) in the Airbus terminology and End-Station in the IEEE terminology.

OSRA-NET defines one communication system as the union of a number of end points and the network (with a defined topology: bus or network). This network is designed to offer a set of properties that can be guaranteed. Theses properties are referred to as Quality of Service (QoS). Those properties group: bandwidth, communication delays, jitter (understood as communication delays variation), packet loss statistics, data stream segregation, priority management, etc. Among them, OSRA-NET defines an important property: the QoS Level that defines the retransmission strategy for a data exchange in case of packet loss. In fact, three QoS Levels are defined for data transfers in OSRA-NET, they will not be directly used in this paper but this knowledge will be helpful when specifying the data flows requirements between all the devices in the network. QoS level 0 can be likened to a Best Effort quality of service. In a communication happening at QoS 0, there is no retransmission whatsoever of a missing message on the receiving side. It is also called QoS 0 -At Most Once level i.e. a message cannot be received more than once by the end point. At QoS 1 -At least Once, a re-emission is possible in case of unsuccessful transmission or communication time-out (at application level). This QoS is supported at network level by the use of duplicates and at higher level by acknowledgements. Finally, at QoS 2, a retransmission is only possible in the case of an unsuccessful transmission (and not in case of communication time-out). In this QoS level, called QoS 2 -Exactly once, a message cannot be received more or less than once by the end point. It is generally used for very critical operations.

Definition 2 (QoS). The Quality of Service for a data exchange is a set of properties that can be guaranteed during the exchange. For instance, for a given data exchange, the Quality of Service can be to have a maximum jitter of 1 microsecond for all messages of the exchange.

It is important to emphasize that even if this QoS specification is only relevant at network level, it cannot be guaranteed if the other elements of the system do not fit this QoS requirement. For instance, having a network operating at 1Gbits per second but an end point capable of exploiting only 500Mbits per second of data will create a bottleneck and make it impossible to fulfil a 1Gbits/sec requirement at system level while it would still be fulfilled at network level. OSRA-NET also defines a set of seven communication classes that are identified through a combination of communication specifications (frequency, message size, level of determinism, time stamp, data rate, etc.) and QoS properties (e.g. QoS level). These seven communication classes are deeply detailed in [START_REF]OSRA Communication Network Specification[END_REF] and are introduced in the table of Fig. 2. In Fig. 2, the communication specifications are in dark grey and the QoS properties in light grey.

Definition 3 (OSRA-NET traffic class). An OSRA-NET traffic class is a shared set of characteristics associated to data exchange. These characteristics include the specification (such as the frequency of data exchanges, data rate) and the expected QoS properties (such as QoS level, maximum jitter, maximum end-to-end latency and level of determinism).

C. Application of OSRA-NET to our satellite architecture

The traffic classes introduced above may not match perfectly the exact industrial requirement. However, we want to stay as close as possible to a generic satellite network specification and architecture, hence when working with a traffic flow, we will assimilate it to the closest OSRA-NET traffic class even if some values (jitter, latency, etc.) may be different. In a way, OSRA-NET will help us define "traffic families" more than an exact traffic flow specification.

Among all OSRA-NET requirements, we have selected two of them that summarize well our network requirements:

OSRA-Requirement 1. An OSRA-NET compliant network shall be able to transfer time-critical data with timing requirements and non-time-critical data, concurrently or separately, while providing a time distribution service.

OSRA-Requirement 2. An OSRA-NET compliant network shall support cold, warm or hot redundancy and provide error detection at data link, network or transport layer. This requirement will not be discussed in this paper.

D. Performance & real-time properties requirements

From our experience, we have also listed a series of requirements that the current and future networks should satisfy in terms of performance and real-time properties.

Requirement 1. The future unified satellite network shall be capable of having up to 25 end-points. This is to support all the sensors and actuators of the platform plus more or less instruments depending on the mission type (Earth Observation, Telecommunication, Space exploration, etc.).

Requirement 2. The future unified satellite network shall be capable of handling low speed traffic (around 1Mbits per second) and high speed traffic (around 1Gbits per second) concurrently or separately. This is to handle the platform and payload traffic.

Requirement 3. The future unified satellite network shall be capable of handling low latency, low/very low jitter traffic and high average throughput traffic, concurrently or separately.

Again, this is to handle the time critical messages of the platform with the huge volume of data of the payload.

Requirement 4. The future unified satellite network shall be capable of handling small and large frame payload.

Messages of the platform are generally small whereas messages in the payload are somewhat big.

Requirement 5. The future unified satellite network shall have a simple behaviour, that is easy to analyse and configure.

The rationale for this requirement is quite obvious: the simpler the system is, the easier it is to validate and certify.

The table in Fig 3 gives an overview of the very first

performance & real-time properties requirements that we have identified for the satellite network. It is still a work in progress: the current requirements may be clarified and new ones may be added to the list. The goal is now to find whether TSN is indeed capable of satisfying the previous requirements.

E. Future work

Currently, we have on one hand generic traffic classes with network performance requirements and on the other hand some high level requirements. The remaining job is to instantiate these requirements on a specific topology in order to perform a network performance analysis. This will help enlighten bottle-necks or difficult points in the network that will need a specific, in detail, analysis. To do such instantiation, we have already identified all the messages exchanged between all end-points and defined an encapsulation strategy. We are now currently struggling in assigning each message to a traffic class. Hopefully, this should be solved by the end of the year.

IV. TSN: A SOLUTION FOR A UNIFIED NETWORK?

A. Compliance of TSN w.r.t. the network performance requirements This section is dedicated to showing how TSN protocols and associated mechanisms could solve the previously introduced requirements. The table of Fig. 4 summarizes what we will discuss in this section.

Requirements TSN Capabilities

Req. 1 Req. 2 Req. 3 ? Req. 4 Req. 5 ? Satisfying the first requirement with TSN is really straightforward: the number of supported end-points in TSN is theoretically limited by the number of available MAC addresses in Ethernet, which is way higher than what we are requesting for a space use. In reality, it will be more likely less than the number of available MAC addresses because switch manufacturers may have limitations in the number of streams that can be supported in their devices. However, our system is pretty small compared to other industrial applications. Thus we believe that we will not be affected by this limitation and hence that Req. 1 is satisfied using TSN.

The second requirement deals with the throughput available in the future network. The requirement is at least 1Gbits/s. Ethernet TSN can support this data rate and even more as some manufacturers already showcase 10Gbits/s capable switches. As a consequence, we consider that Req. 2 is satisfied using TSN.

The third requirements states that the future unified onboard network shall be capable of handling both low latency, low jitter traffic and high throughput traffic. This is the million dollar question for all network systems. We will discuss the capabilities of Time Sensitive Networking with respect to Req. 3 in section V.

The fourth requirement requires that TSN shall be able to handle large and small payloads (in the sense of size of data transfers). This is something possible with Ethernet TSN: an Ethernet frame is capable of handling a data payload between 46 and 1500 bytes (jumbo frames are not in the perimeter of this paper). Hence directly, Ethernet TSN is a solution for data payloads between 46 and 1500 bytes. For payload bigger than 1500 bytes, we will have to implement a fragmentation strategy at higher ISO level (Network or Transport); one solution for that could be to use IP fragmentation. For the smallest payloads (under 46 bytes), we will still be able to use Ethernet but some padding will be added to the data payload in order to reach the minimum Ethernet payload size (46 bytes). This may add a significant overhead (62 bytes) to the data (2 bytes) we want to send (42 bytes for padding + 20 bytes for the Ethernet header). However, our calculations lead us to the following result: considering a 1Gbits/s physical link for TSN, it takes less time to transfer those 64 bytes than to transfer the 2 bytes on a legacy low speed bus. As a consequence, we consider that Req. 4 is satisfied. The reader may comment that we could consider grouping some messages in order to reduce this overhead. This is a point that we might consider in the future, but for now, we would like to reduce as much as possible the impact on the legacy equipments i.e. do not modify the software as much as possible. That is why we will keep these 2 bytes data payloads in this study.

The fifth network performance requirement says that the future unified on-board network must have a simple behaviour that is easy to analyse. At first glance, this is not guaranteed at all with TSN. IEEE Time Sensitive Networking is a wide "standard", composed by more than 20 published protocols and still others are on their way, along with some revisions. Having a system implementing all TSN protocols will, for sure, be extremely complex to analyse and certify. If a lot of complex protocols are required for a single and simple performance requirement, this might be a show-stopper for TSN. That is why, in the challenge introduced in section II-B, we decided to search the minimum subset of TSN protocols that satisfies all the network requirements. We hope that the fewer protocols involved, the easier the analysis will be. The rationale for this "complexity" requirement will not be further discussed in this paper. Definition 4 (Topology). A topology is a network organization of all the devices of the satellite, including End-Systems and switches.

The trade-off between topologies is complex because it is not limited only to matching network device capabilities with network requirements. It must also take into account the number of devices in the final topology, their weight, their power consumption, their thermal properties, and other parameters. The goal here would be to find a topology that is at least equivalent if not better, with respect to the parameters cited above, than the current topology.

C. Overview of TSN protocols

For the last years, an IEEE Ethernet technology capable of supporting both real-time and high-bandwidth traffic has been defined in the working group TSN (Time Sensitive Networking) [START_REF]Time Sensitive Networking Task Group[END_REF], continuing the work of the former AVB (Audio Video Broadcasting) working group. Founded in 2012, the working group has already published a dozen of amendments to the 802.1 standard family in order to ensure a behaviour that is simultaneously real-time, adaptive and flexible, mixing synchronous and asynchronous approaches. Fig. 6 summarizes the available TSN protocols/features. This list is not exhaustive as some protocols are still under development today, however, it seems to be the TSN core protocols. From all available TSN addenda, five main directions/families have been identified. The first offers a network level synchronization service and it groups 802.1AS, 802.1AS-rev. 802.1AS defines synchronization and time distribution protocols for a TSN network. 802.1AS-rev defines upgrades to 802.1AS, mainly specifying a redundancy protocol for the synchronization service.

The second family concerns Ultra Reliability (802.1CB, 802.1Qca, 802.1Qci, 802.1As-Rev). It aims at preventing, as much as possible, the loss of a frame a application level by duplicating frames and/or by controlling that bandwidth reservation is respected by all streams. 802.1CB is a protocol used to support seamless network redundancy. 802.1Qca defines explicit path control and bandwidth and resource reservation protocol. 802.1Qci defines ingress policing strategies for TSN switches and end-points.

The third family is the Bounded Low Latency (802.1Qav, 802.1Qbu, 802.1Qbv, 802.1Qch, 802.1Qcr). It aims at providing protocols that a bounded end-to-end (network) latency for specific streams in the TSN network. This can be made possible through bandwidth reservation, traffic shaping (synchronous and asynchronous) and preemption strategies. 802.1Qav defines traffic shaping strategies for TSN switches and end-points. 802.1Qbu defines a preemption protocol at ISO Layer 2 (Ethernet frame level). 802.1Qbv refines and upgrades 802.1Qav. 802.1Qch is a combination of other TSN protocols, aiming at building a TSN network with fixed latency and jitter. 802.1Qcr defines an asynchronous traffic shaping strategy for TSN switches and end-points.

The fourth family is Dedicated Resources and API (802.1Qat, 802.1Qcc, 802.1Qcp). It defines resource management protocols as well as configuration strategies for a TSN network. 802.1Qat defines a resource reservation protocol for TSN. This can be done statically or dynamically. 802.1Qcc refines and upgrades 802.1Qat, it also defines a configuration protocol for TSN. 802.1Qcp defines a standardized model (YANG model) used to describe a TSN network, the capabilities of its devices, and potentially its configuration.

The last family is Zero Congestion Loss (802.1Qav, 802.1Qbu, 802.1Qbv, 802.1Qch, 802.1Qcr, 802.1Qat, 802.1Qcc, 802.1Qcp). It aims at guaranteeing that no frames are lost due to congestion i.e. buffer overflow in switches. There are not much more details on this family as its protocols have already been introduced in other families.

D. Definitions

Let us introduce some vocabulary and notations, useful for the remainder of the paper.

Definition 5 (Protocol).

A protocol refers to a standard or a substandard. For instance, 802.1Qbv is a protocol. Let us consider a motivating example and try to find the right Qbv configuration (i.e. picking a value for each of the four elements) for it.

The network of Fig. 8 has 3 end-points (ES), 1 Switch (SW) the output port of which uses TSN-802.1Qbv protocol, all of them are 1Gbits/s capable. The physical medium is also capable of conveying a 1 Gbits/s traffic load. The nature of the physical medium (optical or copper) is outside of the scope of this study. ES1 sends video traffic to ES3 and ES2 sends C&C traffic to ES3. The characteristics and requirements of both flows are listed in the table in Fig. 9. The priority field correspond to OSRA-NET priorities management Quality of Service property. However, it did not appear in the definition of the OSRA-NET traffic classes. In fact it is used, by the system designer, in order to define a priority order between streams. In this motivating example, we specify that the C&C stream is more important than the Video stream.

B. Associating the traffic classes to the traffic types

First of all, a port can have between 1 and 8 output queues (implementation dependent), associated to 1-8 traffic classes.

Definition 10 (TSN traffic type, Qbv traffic class). A difference shall be made between TSN traffic type :

• TSN traffic types correspond to the traffic specification of the TSN network. In the OSRA-NET vocabulary, TSN traffic types correspond to OSRA-NET traffic classes. • Qbv traffic classes corresponds to the 8 available queues of a specific 802.1Qbv output port (End-point or Switch).

Definition 11 (Time critical traffic). In this paper, time critical traffic is understood as traffic with real time constraints i.e. bounded low latency and low jitter. By contrast, best effort traffic barely has any constraints on latency nor jitter.

These queues are ordered by priority i.e. priority of queue 0 is higher than priority of queue 7. The allocation challenge is to find how to associate traffic types or messages to one specific queue i.e. finding a traffic type to traffic class mapping. For instance, one possible mapping could be to have all time critical messages in one queue and the rest of the traffic in the other queues. However, one might then wonder if this mapping is the best one ? (in terms of memory usage, waiting time, etc.). It is all the more difficult that this mapping can change on the path of a specific stream (of a certain traffic type).

For the motivation example, we assign the high priority queue (i.e. queue 0) to C&C and low to Video. There is already some literature existing on this subject, for instance, [START_REF] Gavrilut | Traffic Type Assignment for TSN-based Mixed-Criticality Cyber-Physical System[END_REF] proposes a Tabu-search algorithm to assign streams (classified in Hard Real Time, Soft Real Time and Non Critical) into Qbv traffic classes. 1) Configuring the TSA algorithms: Each queue within an output port can have a specific transmission selection algorithm. These algorithms decide when a queue is allowed to try to access the medium in order to send its frames. Example of these algorithms can be Credit Based Shaper (IEEE 802.1Qav), Asynchronous Traffic Shaper (IEEE 802.1Qcr), Round Robin, and user defined (ad hoc) algorithm. The goal of these shapers is to define a formal way to share the bandwidth between all the queues of the output port. The challenge here is to find which TSA to associate to which queues. A well known and studied configuration is the TT-CBS-BE configuration where the highest priority queue has no TSA, it uses transmission gates to guarantee a certain bandwidth for its queue (see after), the two following use Credit-Based Shaper and the rest share the bandwidth using strict priority. In particular, the modelling and performance analysis of this configuration has been addressed in [START_REF] Daigmorte | Modelling in network calculus a TSN architecture mixing Time-Triggered, Credit Based Shaper and Best-Effort queues[END_REF].

C. Configuring the output port

2) Configuring the transmission gates: The second element is the transmission gate. Again, each queue within an output port is associated with a specific transmission gate. As for the Transmission Selection Algorithm, the transmission gate can be used to define when a specific queue is granted the right to try to access the medium. These gates can be configured individually with a specific schedule consisting in closing and opening sequences. Basically, these gates will be, in most cases, used to create a "time-triggered" (TT) queue and ensure that no other queues are granted access to the medium while the TT queue is emitting ("exclusive gating"). Finding the right schedule for the gate (i.e. finding a Gate Control List) is a complex open problem. It has already been addressed in [START_REF] Silviu | Scheduling real-time communication in ieee 802.1qbv time sensitive networks[END_REF] 3) Configuring the transmission selection block: Finally, the last element is the transmission selection block. This block is the final element that decides which queue is, in the end, granted access to the medium. It works with static priority. From all the queues that are available for transmission (i.e. their gate is open and their transmission selection algorithm allows them to try to access the medium), this block chooses the queue of highest priority first. This elements is coupled with another configurable TSN protocol, IEEE 802.1Qbu -Frame Preemption (and 802.3br) for improved performances [START_REF] Thiele | Formal worst-case performance analysis of time-sensitive ethernet with frame preemption[END_REF].

A. First configuration: Static Priority

In this first configuration, the TSN port has no transmission selection algorithm configured, no gate control list configured, and no frame preemption. In that case, this port is equivalent to a port with two queues arbitrated using static priority. In fact, it behaves like a standard Ethernet switch port would i.e. without any TSN or AVB protocols.

As specified in Fig. 3, for this example, C&C traffic has a higher priority than Video traffic. In terms of delay:

• The best-case scenario for this configuration is the following: a C&C frames arrives in the switch, no other packet is being processed or stored by the switch and the frame is "immediately" transmitted to ES3. In this best-case, the delay induced by SW1 is its technological latency. Let us assume that this latency is not significant when compared to the frame's delay requirements.

• The worst-case scenario is as follows: if a C&C frame arrives just after the beginning of the transmission of a Video frame of 1518 bytes (max. length for an Ethernet frame without inter frame gap and start frame delimiter), the C&C frame will have to wait for that frame to be transmitted before being granted access to the medium. The waiting time is obtained by computing the formula below: M essageSize LinkSpeed = 1518 * 8 1.10 9 = 12.144µs

In this configuration, the jitter induced by the switch, understood as delay variability, for a C&C frame, has a value of 12.144µs, which is higher than the maximum admissible jitter for this class of traffic. Obviously, this is only one part of the delay analysis that should be realised End-to-End on this network example for this configuration. Nevertheless, if the jitter is already higher than the requirements in the switch only, the rest of the analysis does not matter: this configuration is declared not valid and Req. 3 is not satisfied.

B. Second configuration: Static Priority + Frame Preemption

In the first configuration, the length of the Video frame, in the worst case, was too big; so was the C&C frames' jitter. One solution to reduce this jitter would be to reduce the size of the Video frame. However, this will lead to a significant overhead hence a reduction of the usable bandwidth in the network. We do not consider this path as a good idea to reduce the jitter.

Fortunately, TSN introduced 802.1Qbu (with the help of 802.3br): a protocol dedicated to Frame Preemption. Thanks to this feature, an Ethernet frame of lower priority can now be preempted by a higher priority frame. With this new protocol, the length of the shortest non-preemptable frame drops down to 143 bytes with a small impact on the available bandwidth [START_REF] Thiele | Formal worst-case performance analysis of time-sensitive ethernet with frame preemption[END_REF]. By re-applying (VI-A) with this new frame size, the delay is reduced to 1.144µs.

This result looks appealing but again, this jitter is only the jitter induced by the switch and the end-to-end analysis must be realised to validate that is it compatible with with C&C traffic class jitter requirement. Let us assume that this is the case. Considering that C&C traffic has its constraints satisfied, it is necessary to check that Video frames still have enough bandwidth. C&C traffic uses less than 1% of the available bandwidth and Video requires 1%. Hence there should be enough bandwidth available for Video frames and Video constraints are fulfilled (formal analysis pending). As a result, this configuration is a valid configuration with respect to the initial goal and Req. 3 is satisfied.

C. Third configuration: Use of gate control lists

The previous section showcased a first Qbv configuration that seems to satisfying the network performance requirements of our motivating example. Let us now slightly modify our motivating example (changes shown in grey in 12). In this new network specification, the Command&Control frames now require an End-to-End jitter of 1µs.

With this new requirement, the solution presented in section VI-B is not valid any-more. The jitter, at switch level is greater than the End-to-End required jitter. There is no possibility to reduce even more the size of the smallest nonpreemptable frame (because it would lead to not respecting Ethernet minimum frame size). We must then explore a new direction to try to even more reduce the jitter. From there, two paths are possible: using using Transmission Gates. In this paper, we will introduce the second path.

For this new possible configuration, we will still do not use any Transmission Selection Algorithm and we will keep preemption. In addition, we will use a Gate Control List. The goal now is to find a gate schedule i.e. a sequence of gate closing and opening for both queues that allows to satisfy the jitter requirements while guaranteeing enough bandwidth for the Video traffic.

Learning from the last two configurations, jitter appeared because of the interaction between frames from different traffic classes. As a consequence, the first thing that we can do to configure the queues to work in "exclusive gating". This means that when the gate for one queue is open, the other one is always closed. This will prevent the interaction between traffic classes.

The only thing left,which is not easy, is to compute a schedule of gate for our streams. A gate control list has several configurable parameters: With this motivating example, let us take a very simple and naive configuration for this protocol (we will not justify this configuration in the paper). In a Time Cycle of 100µs, there will be 10 states of 10µs each. During the first four states, the gate for C&C will be open, and the gate for Video will be closed. During the following six states, the gate for C&C will be closed and the gate for Video will be open. This configuration is summarized by the drawing below (Fig. 13).

With this Gate Control List configuration, if a C&C frame arrives in the switch output port right at the time when its associated gate opens, then the frame will be immediately given access to the medium. In that situation, the jitter induced by the switch is minimal and fits our requirements. However, using this configuration is also very risky. In fact, if a C&C frame arrives just after its associated gate closes, it will have to wait 60µs before being granted access to the medium which does not match the network requirements at all ! In order to avoid this problem, two things must be put in place. First of all, all the devices along the "time-triggered" path in the network must be synchronized in order to ensure that the gate will open at the right time i.e. at the time when the C&C frame is supposed to arrive at the output port of the device (will have to be computed a priori). The second thing that must be realized is to set up a software-network synchronization. The reason for this need is that the End-to-End jitter requirement considered for the satellite is not at network level but at application level. Therefore, this means that the variability of the transmission time must be bounded from the sending to the receiving application and not endpoint. To ensure that when an application emits a packet, it arrives at the end-point output port right when its associated gate is open, this synchronization must be defined. If both of those points are set, then this configuration of TSN will:

• First, be compliant with Req. 3 and OSRA-Req. 1. We did not discuss the time distribution requirement but we assume that if the network is synchronized, then time is distributed across the network. • Second, provide a "zero jitter" communication path for the C&C frames. We did not analyse in this last configuration the requirements of the Video traffic, but the configuration was thought to provide enough bandwidth for the Video traffic requirement.

D. Way Forward

The last section gave a hint of the level of complexity associated with the upgrade of the satellite on-board network using TSN, only focusing on a very basic motivating example with two traffic classes and a very low load of the network. With this example, Standard Ethernet (using static priority) is not enough for a future satellite network. One simple asynchronous solution relies on TSN Frame Preemption and offer a minimal jitter of 1.144µs at low cost on a 1Gbits/s network. For applications demanding an even higher jitter, one possible solution relies on using 802.1Qbv synchronous feature i.e. configure a schedule for the transmission gates. The analysis is still pending but it could potentially help building a "zero-jitter" path under for the C&C flow under the conditions explained before. Going to a synchronous TSN configuration however implies using time distribution and time synchronization services at both network and application layer in the current architecture. Although it does not look like a big issue, we fear it might heavily impact the FDIR analysis during satellite design.

What is left to do is: 1) Generalize the configuration search process to all the satellite requirements and all the TSN protocols, instantiated on a pre-determined topology like Fig. 5. This could lead to the development of a configuration software, similar to the one being developed by switch manufacturers. 2) Define a way to choose between several possible configurations. The last section of this paper will propose a methodology for how to chose between configurations.

VII. CONCLUSION

In this paper, we have introduced generic satellite network requirements with the help of OSRA-NET, ESA's network specification. We have then identified TSN as a good opportunity for the satellite network upgrade. In the last sections, we have started to show how TSN could indeed satisfy the satellite network requirements. Finally, we underlined the configuration challenge of TSN. It is a complex problem and we conjecture it to be NP-Hard. Thus scalability will be a huge issue. Once some configurations have been computed, one must be selected to be part of the final network implementation. How to choose one configuration from one another is an interesting question, specific to every vertical i.e. every field of application of TSN. Our future work will consist in finishing the network requirements definition while going further by formally tackling the configuration challenge of TSN. We will also evaluate TSN-ready hardware components in order to estimate the gap between standard TSN and its implementations.

Figure 1 .

 1 Figure 1. Traditional Satellite Network Topology

Figure 4 .

 4 Figure 4. TSN capabilities with respect to the satellite network performance requirements

BFigure 5 .

 5 Figure 5. Possible network topology using TSN

Figure 6 .

 6 Figure6. TSN available services, excerpt from[START_REF] Farkas | Introduction to 802.1, Focus on the Time-Sensitive Network Task Group[END_REF]

Definition 6 (Figure 7 .

 67 Figure 7. Switch Qbv Output Port

Figure 9 .

 9 Figure 8. Motivating network example

For•

  Figure 10. SW1 Output port schematic view

  VI. CONFIGURATION ANALYSIS FOR THE MOTIVATING EXAMPLE Already, with only 3 mechanisms and their possible values, many 802.1Qbv configurations exist and each of them should be analysed to see if Video and C&C requirements are met. In the sequel, we consider and analyse 3 configurations, detailed in Fig 11.

  Figure 13. GCL-Configuration

  it possible to satisfy both Platform and Payload network requirements using this technology?

	Class	Freq. scale (Hz) Min-Max	Data Rate scale Min-Max	Timestamp Mandatory/Optional	Max. Jitter ms	Max. Latency ms	Level of determinism Low/Medium/High	QoS Level 0/1/2
	1	0.1-1	100bits-10kbits/s	Optional	10	10	Medium	0/1
	2-a	8-10	<1Mbits/s	Optional	5-10	10	High	2
	2-b	8-10	<1Mbits/s	Mandatory	5-10	10	Medium	1/2
	3	8-10	<250kbits/s	Optional	10	10	High	2
	4	0.1-1	>100Mbits/s	Optional	<100	<100	Low/Medium	0/1
	5-a	10-1000	<3Mbits/s	Optional	0.5-1	0.5	High	2
	5-b	10-1000	<3Mbits/s	Mandatory	0.5-1	0.5	Medium	1/2
	6	1-10	>100Mbits	Mandatory	2	10	High	1/2
	7	1-10	100bits-1kbits/s	Optional	1	2	High	0/1
				Figure 2. OSRA-NET Traffic Classes
					In order to tackle this open question, we propose to decompose
					it as a series of intermediate steps:
					1) What are the requirements of the satellite network ?
					2) What are the protocols/features offered by TSN ?
					3) What are the valid topologies for the future on-board
					network?
					4) Which combination of TSN protocols/features satisfies
					the satellite requirements ?
					5) What is the minimum subset of TSN protocols/features
					satisfying these requirements ?

  Transmission Selection Algorithm or

	Type	C&C	Video
	OSRA-Net Traffic Type Family OSRA-4 OSRA-5a
	Size	512bits	10Mbits
	Frequency	100Hz	8Hz
	Max. Latency requirement	1ms	100ms
	Max. Jitter requirement	1µs	100ms
	Priority	High	Low
	Figure 12. Traffic characteristics and requirements

•

  Time Cycle, the duration of the whole sequence of gate actions • Number of states, the number of gate states in the Time Cycle • Time interval, the duration of a gate state in the Time Cycle • State, the status of the gate, it can be Open (o) or Closed

	(C)
	Again, finding a configuration for the Gate Control List
	corresponds to choosing values to each of these parameters.