Sam Van Den Vonder

Joeri De Koster
email: jdekoste@vub.be

Wolfgang De Meuter
email: wdmeuter@vub.be

Composable Actor Behaviour

Keywords: actors, delegation, active objects, code reusability

Introduction

In object-oriented programming, the principle of "programming against an interface" helps to foster code reuse and reduce complexity, thus increasing the reliability of individual components [START_REF] Meyer | Applying "design by contract[END_REF]. Essentially it is beneficial for the overall complexity of the program to design components as black boxes, because it is then the sole responsibility of each individual component to ensure the functionality it offers through its interface is correct. This principle manifests itself in many reuse mechanisms, such as inheritance [START_REF] Johnson | Designing reusable classes[END_REF] and trait composition [START_REF] Ducasse | Traits: A mechanism for fine-grained reuse[END_REF] for class-based languages, and delegation for prototype-based languages [START_REF] Lieberman | Using prototypical objects to implement shared behavior in object oriented systems[END_REF]. In actor-based programs, using components as black boxes is equally important but for reasons other than just modularity and code reuse.

The behaviour of an actor is usually a combination of its internal state and its interface, which is the set of messages that an actor can process [START_REF] Koster | 43 years of actors: a taxonomy of actor models and their key properties[END_REF]. The only way to communicate with an actor is to send it a message that matches an entry in its interface, which is important for two reasons. First, it makes it easier for actors to protect their internal state from race conditions via interface control [START_REF] Kafura | Inheritance in actor based concurrent object-oriented languages[END_REF] (essentially by asynchronously processing messages one by one).

Second, a message-passing communication model is beneficial for (among others) concurrency, fault tolerance, and distribution over a network.

Despite the principle of "programming against an interface" being ingrained in the actor model almost by definition, it is rarely leveraged to facilitate modularisation and code reuse among actors. More specifically, currently there is limited language support for composing the behaviour of an actor, i.e. its interface, out of reusable parts.

Since code reuse is an important aspect of software engineering, we argue that actor-based programs can benefit from a simple and well-defined code reuse mechanism to control and reduce their complexity. To this end we introduce Stella, a prototype language that implements an actor composition mechanism based on asynchronous message delegation. The main contributions of this paper are the design and definition of Stella, and a formalisation of a subset of Stella that captures the precise semantics of the reuse mechanism.

In Section 2 we discuss the requirements of a suitable code reuse mechanism for actors, and we discuss reuse mechanisms in a number of state-of-the-art actor languages. In Section 3 we define Stella, and in Section 4 we define an operational semantics for a subset of Stella.

Code Reuse in Actor-Based Languages

Before we look into existing reuse mechanisms, we define the term actor behaviour and we specify the requirements of a reuse mechanism suitable for actors. We adopt the terminology of [START_REF] Koster | 43 years of actors: a taxonomy of actor models and their key properties[END_REF] that defines the behaviour of an actor as the description of its interface and state. The interface defines the list (and possibly types) of messages that an actor can process, as well as the program logic to process them. The state of an actor is defined as all the program state that is synchronously accessible by the actor.

From a software engineering point of view it is beneficial to split up a monolithic behaviour into multiple "reusable components" that can be composed using a composition mechanism. We devise 2 goals or requirements for such a mechanism that is suitable for the actor model, which we base on well-established design principles for object-oriented programming [START_REF] Rumbaugh | Objectoriented modeling and design[END_REF]Chapter 14].

Extensibility. The interface of behaviours can be extended to accept new messages, and a behaviour can specialise the acquired components to adapt them to its own needs. Relating this to object-oriented programming, this is similar to how a class can add, override, and specialise methods of a superclass, or to how traits can add methods to a class which may also be further specialised. Reusability. Pre-existing behaviours can be reused by extending, adapting or specialising them via new behaviour definitions, without modifying the original behaviour. In object-oriented programming this is similar to how a class may be specialised via subclassing, while it remains independently instantiatable regardless of new class definitions that rely on it.

Over the years a number of reuse mechanisms have been proposed in different kinds of actor languages that implement different kinds of actor model. In the following sections we discuss inheritance, trait composition, function composition, and reuse via prototypes in the Communicating Event-Loops model.

Inheritance

The relation between inheritance and concurrent object-oriented programming has been thoroughly researched. Part of this research is focussed specifically on inheritance in actor-based languages such as Act3 [START_REF] Agha | A model of concurrent computation in distributed systems[END_REF] and ACT++ [START_REF] Kafura | Concurrent object-oriented real-times systems research[END_REF], which are based on the work of Agha [START_REF] Agha | Concurrent object-oriented programming[END_REF]. In these languages, a become statement (fundamental to the model) is used to replace the behaviour of the current actor with a new behaviour. This statement causes severe reusability issues due to the Actor-Inheritance Conflict [START_REF] Kafura | Inheritance in actor based concurrent object-oriented languages[END_REF]. Consider a behaviour as being similar to a class, then the conflict describes a fundamental issue where adding a new method to a subclass may invalidate many superclass methods.

Classes in combination with inheritance fulfil the requirements of extensibility and reusability. However, inheritance is known to have reusability issues when used as the sole reuse mechanism [START_REF] Ducasse | Traits: A mechanism for fine-grained reuse[END_REF]. Furthermore, nowadays it is generally accepted as a good design principe in object-oriented programming to favour object composition over class inheritance [START_REF] Bloch | Effective Java, 2nd Edition. The Java series[END_REF][START_REF] Gamma | Design patterns: Elements of reusable object-oriented software[END_REF]. For these reasons we do not consider inheritance by itself to be a suitable reuse mechanism for actors.

Trait Composition

The Active Objects model is based on the work on ABCL/1 [START_REF] Yonezawa | Object-oriented concurrent programming in ABCL/1[END_REF], and has modern implementations in languages such as Pony [START_REF] Clebsch | Deny capabilities for safe, fast actors[END_REF] and Encore [START_REF] Brandauer | Parallel objects for multicores: A glimpse at the parallel language encore[END_REF]. Here, actors are typically instances of an active object class which describes mutable fields and a set of methods that can be asynchronously invoked via message passing. Pony and Encore support neither a become statement (which caused the Actor-Inheritance Conflict from the previous section) nor reuse via inheritance. In the case of Pony it is mentioned that composition is preferred to inheritance [START_REF]What about inheritance?[END_REF].

Instead of inheritance, Pony and Encore support stateless traits [START_REF] Ducasse | Traits: A mechanism for fine-grained reuse[END_REF]. Traits can be composed with behaviours and other traits to add new methods to the composer. However, they do not fulfil our 2 requirements. Extensibility is only partially fulfilled because, while traits can be used to extend a behaviour with new functionality, they have a number of drawbacks. Most notably, stateless traits are likely to be an incomplete implementation of some functionality unless it is completely stateless [START_REF] Bergel | Stateful traits and their formalization[END_REF]. The follow-up work on stateful traits also has some drawbacks such as possibly breaking black-box encapsulation, and difficulties regarding a linear object layout in memory [START_REF] Bergel | Stateful traits and their formalization[END_REF]. Reusability is unfulfilled because the trait composition mechanism cannot be used to compose behaviours.

Function Composition

Popular languages and libraries such as Erlang [START_REF] Armstrong | Concurrent programming in ERLANG[END_REF], Elixir [START_REF] Thomas | Programming Elixir[END_REF] and Akka [START_REF] Roestenburg | Akka in action[END_REF] closely link behaviours and functional programming. In Erlang and Elixir, a blocking receive statement is used as part of a function body to dequeue 1 message from the mailbox of the current actor, and local actor state is encapsulated via lexical scoping. In Akka (a library for Scala), the behaviour of an actor is represented as a Scala partial function that is continually applied to messages by the receiving actor. Consequentially, behaviour composition is based on function composition. For example, in Akka, the Scala andThen and orElse function combinators compose two behaviours by respectively chaining two functions (pass the output of 1 into the next) or switching over 2 functions (if the given argument is not in the domain of the first, try the second).

We do not consider function composition to be a suitable reuse mechanism because it does not support extensibility. Logically switching over behaviours can be used to emulate some features of extensibility, e.g. the behaviour that is the result of the composition (behaviourA orElse behaviourB) will accept the union of messages accepted by both behaviours. However, the end result is highly susceptible to the composition order; messages matched by both behaviours will always be processed exclusively by behaviourA. Furthermore, there is no mechanism to deal with conflict resolution, for example when behaviourA accidentally captures messages that should be processed by behaviourB.

Communicating Event-Loops

The Communicating Event-Loops model (CEL) originated in the E [START_REF] Miller | Concurrency among strangers[END_REF] language and was later adopted by AmbientTalk [START_REF] Cutsem | Ambienttalk: programming responsive mobile peer-to-peer applications with actors[END_REF]. Here, an actor is not described by a behaviour. Instead, an actor is a vat of plain objects that are said to be owned by the actor. Objects owned by one actor can have near references to objects within the same vat and far references to objects in another vat. Method calls via a near reference are synchronous; method calls via a far reference are asynchronous, are sent to the actor that owns the object, which will eventually invoke the method. In this model, the behaviour of an actor depends on which of its objects are accessible via far references, since those determine which messages are accepted.

Both E and AmbientTalk define a prototype-based object model, which relies on functions and lexical scoping for object instantiation and information hiding. A problem occurs when two similar actors attempt to share a behaviour, which in this model amounts to sharing an object. If two actors could reference the same behaviour, they would have access to shared mutable state either via the shared lexical scope, or via the shared object. Therefore, a CEL model in combination with a prototype-based object model does not offer a suitable reuse mechanism because, idiomatically, behaviours cannot be freely reused by different actors.

A possible avenue to explore could be to design a class-based CEL language which can eliminate shared mutable state. While we consider this to be a viable approach to our problem, in this paper we opt for a different approach that we consider to be simpler and more applicable to other actor languages.

Problem Statement

In the previous sections we discussed different kinds of reuse mechanisms in different kinds of actor model. In Section 2.1 we discussed the relationship between inheritance and actors, and concluded that inheritance by itself is not a suitable reuse mechanism for actors. For Active Objects (Section 2.2) we discussed trait composition and how it does not fulfil our requirements, because traits have a number of drawbacks and cannot be used to compose behaviours themselves. We discussed actor languages where behaviours are encapsulated by functions (Section 2.3), where we motivated that function composition is not a suitable composition mechanism. Finally, for the Communicating Event-Loops model (Section 2.4) we discussed that a prototype-based object model would lead to shared mutable state between actors if behaviours could be reused.

The problem that we tackle in this paper is to define a code reuse mechanism for behaviours that fulfils the requirements of extensibility and reusability. The mechanism defines (1) how the interface of behaviours can be extended with functionality defined by different components (extensibility), and (2) how behaviours themselves can be reused to define new behaviours (reusability).

Delegation-based Actor Composition in Stella

In this section we introduce Stella, a prototype language based on the Active Objects model, where behaviours can be composed with a mechanism based on delegation-based trait composition [START_REF] Cutsem | Adding state and visibility control to traits using lexical nesting[END_REF]. We opted for a language-based approach (rather than a library) to convey the mechanism in a clear and concise manner. It also ensures consistent run-time semantics, particularly with respect to the definition of behaviours and message sending between actors. We first give a motivating example that benefits from reusable behaviours, and in the sections thereafter we gradually introduce the different aspects of Stella. For brevity we only implement parts of the motivating example to introduce the base language and to explain behaviour composition (the precise semantics of which are formalised in Section 4)1 .

Motivating Example

A modern approach to building "real-time" or "live" applications are streambased frameworks such as ReactiveX, which describes the API of a class of streaming frameworks in over 18 languages [START_REF]ReactiveX: An api for asynchronous programmingwith observable streams[END_REF]. These frameworks provide abstractions for data streams together with an extensive collection of built-in operators to transform and combine them. Consider a temperature monitoring application that visualises live measurements of many heterogenous sensors. Depending on units of measurement and user preferences, measurements may have to be transformed from one unit to another. This can be done by mapping a conversion function over a stream of measurements using some built-in map operator, resulting in a new stream of data.

Streaming frameworks are often designed sequentially, i.e. new input data is first propagated to all connected streams before the next input can be accepted, and parallelising this process is non-trivial. With composable behaviours we can design a simple framework where streams and operators are actors, such that multiple computations can run in parallel.

Figure 1 depicts the different behaviours involved in our streaming framework. Every behaviour lists the methods that it provides, and for clarity we also list when a behaviour expects a certain method to be present in its composer that it does not implement itself. The framework provides a SocketStream behaviour to abstract over a typical socket connection as a data stream, and also 1 built-in Map operator to map a function over a stream. Common functionality for operators is factored out into an Operator behaviour (which also behaves like a stream), and common functionality of streams is factored out into Stream and Subscribable. Stream implements functionality for publishing and receiving values, Subscribable simply keeps a list of other streams (actors) that should receive new publications.

The Base Stella Language

In this section we introduce the base Stella language without behaviour composition. Similar to other Active Object languages, Stella has an active layer of active object classes and actors, and a passive layer of regular classes and objects We omit the details of the passive object layer since its definition is irrelevant to the problem of behaviour composition.

A program written in Stella is a set of top-level behaviour definitions and regular class definitions. Every program must define a Main behaviour that is instantiated as the first actor of the program. Listing 1 implements two behaviours Stream (Lines 1-5) and Subscribable (Lines 7-14). Stream implements generic stream functionality for publishing and receiving data. It has two methods called publish and receive with 1 formal parameter data (Lines 2-4 and 5). Publishing data to a stream simply amounts to sending a receive message to all subscribers. The logic of sending that message is contained within local definition ( set! subscribers ( add subscribers subscriber ) ) ) 14

( d e f -m e t h o d ( collect f ) ( for-each subscribers f ) ) )

Listing 1: Implementation of the Stream and Subscribable behaviours.

f (Line 3) that is bound to a lambda function 2 . When the lambda is invoked, it sends the receive message to subscriber with the data to be published as single argument. Iterating over subscribers of the stream is done by sending a collect-subscribers message to the current actor via pseudo-variable self with f as argument. The default receive method on Line 5 simply returns the symbol 'do-nothing.

The Subscribable behaviour stores a list of subscribers to a stream. Its definition is analogous to Stream but shows the use of fields (local actor state) and constructors. In this case there is 1 field subscribers (Line 8), a constructor named init (Line 10), and 2 methods subscribe and collect (Lines 12-13 and 14). A constructor is a special method that is called exactly once when an actor is spawned. Behaviours without a constructor will be initialized by a default constructor. In this case the init constructor initializes the local field subscribers to an empty list via the special form set! (assignment).

Bodies of constructors and methods contain either special forms (like set!) or synchronous method invocations on regular objects. Here, we use the following syntax where methodName is invoked on object target with the given argument expressions.

(methodN ame target arg1 ... argn )

In that vein, the invocation of send in Stream (Listing 1 Line 3 and 4) is simply the invocation of the send method on an object that represents a reference to an actor. Similarly, the add and for-each methods (Line 13 and 14) are invocations on a list object.

Actors can be spawned via a spawn special form that returns a reference object that can be used to send asynchronous messages to the newly spawned actor. For example, the following expression spawns an actor with the Subscribable behaviour that is initialized by calling the init constructor.

( spawn Subscribable init ) 2 Stella does not have functions. Using a process similar to Lambda Lifting, a lambda statement is transformed to an object with an apply method

Delegation-based Behaviour Composition in Stella

In this section we introduce a new composition mechanism for behaviours inspired by delegation-based trait composition in AmbientTalk [START_REF] Cutsem | Adding state and visibility control to traits using lexical nesting[END_REF]. In a nutshell, a behaviour can statically acquire the methods of other behaviours, and spawning an actor from a compound behaviour creates multiple actors that each run part of the compound behaviour. We will refer to these actors as the delegate actors. Messages that match an acquired method are automatically delegated to the corresponding delegate actor. To explain the different aspects of behaviour composition, we implement the Operator behaviour from Figure 1. The Operator behaviour implements common functionality for all streaming operators in our motivating example, which in this case only amounts to ensuring that every instance of an operator behaves like a stream of data. Its implementation is shown in Listing 2. A delegate-to statement (Line 2-3) is used to declare that (at compile-time) all methods from the behaviours Stream and Subscribable are acquired. A conflict may occur when acquiring two or more methods with the same name. These must be explicitly resolved by aliasing or excluding certain methods using a rename or exclude statement respectively. In this case, the collect method from Subscribable is renamed to collect-subscribers for clarity rather than solving a conflict.

Before we can explain the run-time semantics of acquired methods (which is different from traditional trait composition), we first show the effects of a delegate-to statement at compile-time. Listing 3 shows the compile-time expanded version of the Operator behaviour of Listing 2, which incorporates the acquired methods. The added lines of code are Line 2 -a pseudocode statement to explain the run-time semantics -that declares 2 new (special) fields, Lines 9-12 which are the acquired methods from the Subscribable behaviour (note that the collect method is renamed), and finally Lines 14-15 which are the acquired methods from the Stream behaviour.

The 2 new fields on Line 2 are generated by the compiler and carry the name of the delegate behaviours. They are populated by the spawn-delegate statements in the constructor (Lines 5-6), which is a special version of a regular spawn. Instead of returning the address of the new actor, it is stored in the corresponding (generated) field that carries the name of the spawned behaviour. Thus, when Operator is spawned, it also spawns 2 delegate actors, and by storing their addresses in generated fields we can guarantee that the contents of these fields cannot be directly modified or retrieved. Consequentially, because the address of delegate actors can never be shared with other actors, we keep the process of spawning delegates completely transparent to users of a behaviour.

In contrast with regular trait composition for object-oriented programming, the implementation of acquired methods is not copied over. Instead, a delegate statement is generated that serves 2 purposes. First, delegate retrieves the delegate actor (from the generated fields) referenced by its first argument. Second, it sends a special message to the delegate actor that, when the message is executed, changes the self pointer of the delegate actor to that of the sender. This is a crucial mechanism of trait composition that allows the delegate to communicate with its delegator, which is similar to the unchanged this pointer for regular trait composition in object-oriented programming [START_REF] Cutsem | Adding state and visibility control to traits using lexical nesting[END_REF][START_REF] Ducasse | Traits: A mechanism for fine-grained reuse[END_REF]. The effect is that, any time the delegate actor sends a message to self, the message is actually received by its delegator. An example of where this mechanism is necessary is the Stream behaviour of Listing 1 Line 4, where a collect-subscribers message is sent to self to iterate over a list of subscribers stored in another behaviour.

Operational Semantics of Stella

In this section we formalise a subset of Stella via an operational semantics. The formalisation entails the necessary details about actors, behaviours and delegation. For brevity we omit the sequential class-based object-oriented subset of the language, since this concern is orthogonal to actors and behaviours. The goal of this formalisation is to describe the precise semantics of the composition mechanism such that it can be reproduced in other languages. Our semantics is based on the formalisation of JCoBox [START_REF] Schäfer | Jcobox: Generalizing active objects to concurrent components[END_REF] and AmbientTalk [START_REF] Cutsem | Ambienttalk: programming responsive mobile peer-to-peer applications with actors[END_REF].

Syntax

The abstract syntax of Stella is shown in Figure 2. Capital letters denote sets, and overlines denote sequences (ordered sets). We may implicitly treat single elements as sequences or sets of size 1 (e.g. A(. . .) is equivalent to {A(. . .)}). Most of the syntax is shown in Section 3. Note that in this section we talk about (active object) classes instead of behaviours. -A program p is a set actor class declarations, one of which we assume will be called Main. -For simplicity, classes have no constructor.

k ∈ K ∈ Configuration ::= K(A, C) Configurations C ⊆ ActorClass ::= C(n, f , d, M ) Actor Classes a ∈ A ⊆ Actor ::= A(i, M, Q, F, F d , e) Actors Q ⊆ Queue ::= msg Queues F, F d ⊆ Field ::= F(f, v) Fields msg ∈ Message ::= Msg(i, m, v) Messages M ⊆ Method ::= M(m, x, e) Methods v ∈ Value ::= i | null Values e ∈ E ⊆ Expression ::= . . . | v Runtime Expressions i ∈ ActorId
-Because there are no constructors, there is no explicit spawn-delegate statement required in the syntax because delegate actors can now be created ex nihilo (i.e. without initializing them with run-time values). -Methods have just one expression as their body, and there are no variable definitions (e.g. via a let statement). -Fields are accessed explicitly via get and set! statements.

Semantic Entities

The static and dynamic semantics are formulated as a small-step operational semantics whose semantic entities are listed in Figure 3. Calligraphic letters such as K and C are used as "constructors" to distinguish different semantic entities syntactically.

The state of a program is represented by a configuration k which contains a set of concurrently executing actors and a set of classes.

A class has a unique name n, fields f , delegate fields d (these are the generated fields to store references to delegate actors, see Section 3.3), and a set of methods M . In Section 4.4 we show how a class is produced from the abstract syntax.

An actor has a unique identifier i that we use as its address, a set of methods M that can be invoked by the actor, a queue Q that holds a sequence of messages to be processed, a set F that maps fields to values, a set F d that maps delegate fields to delegate actors, and an expression e that the actor is currently executing.

A message msg is a triplet of a self address i to be used during execution of the message (either the message receiver or the delegator), the name m of a method to invoke, and a sequence of values v which are the method arguments.

A method M is a triplet containing the name of the method m, a sequence of formal parameters x, and a body e.

Our reduction rules in Section 4.5 operate on "runtime expressions" which are simply all expressions e extended with run-time values v, can be actor references i and null.

Notation

We use the • ∪ (disjoint union) operator to lookup and extract values from sets. For example, S = S • ∪ s splits the set S into element s and the set S = S \ {s}. When the order of elements is important (e.g. for representing the message queue of an actor) we use the notation S = S • s to deconstruct a sequence S into sequence S = S \ {s} and s which is the last element of S. We denote both the empty set and the empty sequence as ∅.

Static Semantics

Our reuse mechanism requires an additional compilation step to transform a class declaration from the abstract syntax into a class that can be used at runtime. In Figure 4 we define a number of auxiliary functions in a declarative style to generate such a run-time class. We sum up their purpose: gen Generates a set of methods (to be acquired by a class) based on a set of pre-existing methods and a set of delegate-to statements. M represents a set of pre-existing (non-acquired) methods of a class, C is a set of compiled run-time classes, and D a set of delegation declarations. For each delegation declaration, lookup the corresponding run-time class and generate a set of methods to be acquired for this particular delegate. genMethods Given a set of pre-existing methods M , a classname n, a set of excluded methods m excl , a set of aliased methods m alias and a set of methods M to acquire, return a new set of methods possibly extended with newly acquired ones. Methods in M with name m are excluded if m ∈ m excl , or if a method m already exists in the pre-existing set of methods M . The latter ensures that methods from the base class take precedence over acquired methods (they are not "overridden" by the delegate). genMethod Generate the method to be acquired by a class. M is the original method from the delegate class, n is the name of said class, and m alias is a set of tuples to possibly rename the generated method. The body of the generated method is a delegate expression where n will refer to the delegate actor. name Given a method name m and a set of possibly aliased methods m alias , return the (possibly aliased) method name. methodsOf Given a delegation declaration and a set of run-time classes C, return the set of all method names that would be acquired by C using the delegation declaration.

Figure 5 defines a reduction → c to compile a set of class declarations B. The reduction is defined as B, C → c B , C where the tuple B, C initially contains all class declarations B in the program, and C is empty. Compilation fails when the conditions of the rule are not met and no element in B can be reduced. This signifies an error in the program. Another possible error is explicitly formulated by a precondition given on the first line of the premise that prevents method conflicts between delegates, which means that the intersection of the acquired methods for any 2 delegates is empty. A set of delegate fields d is created using the classnames of delegates.

Field-Get F(f, v) ∈ F A(i, M, Q, F, F d , e [(get f )]) →a A(i, M, Q, F, F d , e [v]) Field-Set F = F • ∪ F (f, v0) F = F ∪ {F (f, v)} A(i, M, Q, F, F d , e [(set! f v)]) →a A(i, M, Q, F , F d , e [v]) Process-Msg Q = Q • Msg(i , m, v) M(m, x, e) ∈ M A(i, M, Q, F, F d , v) →a A(i, M, Q , F, F d , e[i /self ][v/x])
Figure 6: Actor-local reduction rules.

Dynamic Semantics

Evaluation Contexts We use evaluation contexts [START_REF] Felleisen | The revised report on the syntactic theories of sequential control and state[END_REF] to abstract over the context of an expression, and to indicate which subexpressions should be fully reduced before a compound expression can be reduced. The expression e denotes an expression with a "hole" to identify the next subexpression to be reduced. The notation e [e] indicates that expression e is part of an abstracted compound expression e , and that e should be reduced first before e can be reduced. Evaluation Rules Our evaluation rules are defined in terms of a reduction on sets of configurations K → K . For clarity we split the rules defining this reduction in two parts. Actor-local rules are defined in terms of a reduction a → a a and can be applied in isolation (within one actor). Actor-global rules are defined in terms of a reduction K → k K and indicate interactions between actors.

Actor-local Evaluation Rules

Actors continually dequeue the first message from their message queue, retrieve the correct expression to process this message, and reduce this expression to a value. The next message can only be processed after the expression is reduced to a value. An actor is considered idle when its message queue is empty and its current expression has been completely reduced. This is the only situation in which no rules apply to a particular actor. Otherwise, if an actor is not idle and no rules can reduce its current expression, there is an error in the program. We summarise the actor-local reduction rules in Figure 6.

Field-Get, Field-Set Values of fields are stored in a set F of 2-tuples that map fields to values. A get expression is a simple lookup of the field, and set! replaces the current association with a new one. Process-Msg Processing a message is only possible when the message queue Q is not empty and the current expression is reduced to a value. The last entry of the queue is removed and the corresponding method is retrieved. To evaluate the body of the method we substitute the formal parameters x and self with the values contained within the message. Note that self is either the current actor (when the message was sent via a normal message send) or the delegator (when the message was delegated).

Send A = A • ∪ A(i , M , Q , F , F d , e ) Q = Msg(i , m, v) • Q K(A • ∪ A(i, M, Q, F, F d , e [(send i m v)]), C) → k K(A ∪ {A(i, M, Q, F, F d , e [null]), A(i , M , Q , F , F d , e )}, C) Delegate F(d, i ) ∈ F d A = A • ∪ A(i , M , Q , F , F d , e ) Q = Msg(i, m, v) • Q K(A • ∪ A(i, M, Q, F, F d , e [(delegate d m v)]), C) → k K(A ∪ {A(i, M, Q, F, F d , e [null]), A(i , M , Q , F , F d , e )}, C) Spawn makeActor(n, C) = A(i , M , Q , F , F d , e ) • delegates K(A • ∪ A(i, M, Q, F, F d , e [(spawn n)]), C) → k K(A ∪ {A(i, M, Q, F, F d , e [i ]), A(i , M , Q , F , F d , e )} ∪ delegates, C) Congruence a →a a K • ∪ K(A • ∪ a, C) → k K ∪ K(A ∪ a , C)
zipFields(∅, ∅) = ∅ zipFields(d • ∪ d, A(i, M, Q, F, F d , e) • ∪ delegates) = {F(d, i)} ∪ zipFields(d, delegates) makeActor(n, C) = {A(i, M, ∅, F, F d , null)} • delegates with i fresh, C(n, f , d, M ) ∈ C, F = {F(f, null) | f ∈ f } delegates = {makeActor(n , C) | n ∈ d} F d = zipFields(d, delegates)

Actor-global Evaluation Rules

We summarise the actor-global evaluation rules of Figure 7.

Send Describes an asynchronous message send to an actor. A new message is added at the front of the queue Q of the receiving actor i . The address of the self reference passed as an argument in the message is also i . This means that the receiving actor will execute the message using its own address as self parameter. Semantically, all arguments v are passed to the other actor via a (deep) copy, but in our case there is no assignment other than local fields, and therefore we do not explicitly create copies in this formalisation. The send expression reduces to null. Delegate Describes delegating messages. This rule is almost identical to Send, except that the address of the receiver i is stored in a delegate field d in F d , and that the address of the sender i is passed in the message instead of i . Thus, when the receiver eventually processes this message, any messages it sends to self during execution will be sent to the delegator i. Spawn This rule describes the spawning of an actor given a classname n. Spawning an actor may add multiple actors to the program, namely the actor with the spawned behaviour and all of its delegates (and all of their delegates, ...).

To create these actors in a single evaluation step we define an auxiliary function makeActor in Figure 8 Finally, the rule in Figure 9 bridges compilation and evaluation, and shows how to reduce a fully compiled program represented by a tuple ∅, C into the first configuration of the program. The first actor is an instance of the Main class and contains a start message in its mailbox.

Conclusion

Code reusability is an important aspect of software engineering that can improve software quality and reliability of actor-based systems. We approach this topic in Section 2 by discussing different kinds of code reusability mechanisms in different kinds of actor models. The discussed mechanisms do not fulfil 2 requirements that we find essential for programming actor-based systems: extensibility and reusability.

We introduce a prototype language in Section 3 called Stella with a behaviour composition mechanism based on delegation-based trait composition. Here, a compound behaviour essentially describes a collection of actors that are composed at runtime such that some messages are implicitly delegated from one actor to another. It fulfils the requirement of extensibility because behaviours can be easily extended with new methods defined elsewhere, and it fulfils selfcontainment because every part of a composed behaviour can, by itself, also be used to create new actors.

Figure 1 :

 1 Figure 1: Composition of behaviours in an actor-based streaming framework.

1 ( actor Stream 2 (

 2 d e f -m e t h o d ( publish data ) 3 ( def f ( lambda ( subscriber ) ( send subscriber receive data ) ) ) 4 ( send self c o l l e c t -s u b s c r i b e r s f ) ) 5 ( d e f -m e t h o d ( receive data ) do-nothing ) ) 6 7 ( actor Subscribable 8 ( fields subscribers ) 9 10 ( d e f -c o n s t r u c t o r ( init ) ( set! subscribers () ) ) 11 12 ( d e f -m e t h o d ( subscribe subscriber ) 13

1 ( actor Operator 2 ( d e l e g a t e -t o Stream ) 3 ( 5 ( d e f -c o n s t r u c t o r ( init stream ) 6 ( s p a w n -d e l e g a t e Subscribable init ) 7 ( s p a w n -d e l e g a t e Stream ) 8 (Listing 2 :1 ( actor Operator 2 ( d e l e g a t e -f i e l d s 4 ( d e f -c o n s t r u c t o r ( init stream ) 5 ( s p a w n -d e l e g a t e

 2356782245 d e l e g a t e -t o Subscribable ( rename collect c o l l e c t -s u b s c r i b e r s ) ) 4 send stream subscribe self ) ) ) Implementation of the Operator behaviour. Subscribable Stream ) // run-time syntax 3 Subscribable init ) // populate special field 6 ( s p a w n -d e l e g a t e Stream ) // populate special field 7 ( send stream subscribe self ) ) 8 9 ( d e f -m e t h o d ( subscribe subscriber ) 10 ( d e l e g a t e Subscribable subscribe subscriber ) ) 11 ( d e f -m e t h o d ( c o l l e c t -s u b s c r i b e r s f ) // renamed method 12 ( d e l e g a t e Subscribable collect f ) ) 13 14 ( d e f -m e t h o d ( publish data ) ( d e l e g a t e Stream publish data ) ) 15 ( d e f -m e t h o d ( receive data ) ( d e l e g a t e Stream receive data ) ) ) Listing 3: Compile-time expanded version of the Operator behaviour.

pFigure 2 :

 2 Figure 2: Abstract syntax.

Figure 3 :

 3 Figure 3: Semantic entities.

Figure 4 :Figure 5 :

 45 Figure 4: Auxiliary functions for class compilation.

  e ::= | (set! f e ) | (send e m e) | (send v m v e e) | (delegate d m v e e)

Figure 7 :

 7 Figure 7: Actor-global reduction rules.

Figure 8 :

 8 Figure 8: Auxiliary functions to create actors.

  that, given a classname n and all classes C, returnsmakeActor(M ain, C) = A(i, M, Q, F, F d , null) ∅, C → K(A(i, M, {Msg(i, start, ∅)}, F, F d , null), C)

Figure 9 :

 9 Figure 9: Program initialization.

The code for the complete example is available and can be run at http://soft.vub. ac.be/~svdvonde/examples/DAIS19/.

Acknowledgements

We would like to thank Thierry Renaux for his insightful comments on drafts of this paper. Sam Van den Vonder is supported by the Research Foundation -Flanders (FWO) under grant No. 1S95318N.


Junesol Song

Dr Carl Milner

Dr Ikhlas Selmi

Sara Bouterfas

Dr Olivier Julien

Assessment of Dual-frequency Signal Quality Monitor to Support CAT II/III GBAS

Her research interests include dual-frequency/multi-constellation GBAS fault monitoring, multi-GNSS Network RTK, Compact RTK, carrier phase-based algorithms and positioning

INTRODUCTION

Signal Quality Monitoring (SQM) must detect one of the ranging source faults, satellite signal distortions to prevent user receivers from misleading information (MI) in high-integrity augmentation systems such as the Ground-Based Augmentation System (GBAS) and the Satellite-Based Augmentation System (SBAS). These distortions have occurred on the GPS C/A code due to a satellite malfunction [START_REF] Daly | Recent Advances in the Implementation of GNSS[END_REF] and could potentially reoccur in the future in spite of improved satellite design. Consequently, under failure the correlation function is distorted and it leads to an incorrectly estimated code delay, leading to a bias-like error being included in the pseudorange measurement. Moreover, this range error can vary according to receiver tracking configurations in terms of chip spacing, pre-correlation filter type and its bandwidth. To protect ground and user receivers against this type of range fault, it is mandatory to have monitors to detect and remove those distorted signals.

Currently, single-frequency GBAS solutions known as GBAS Approach Service Types (GAST) C and D can support CAT I and CAT II/III precision approach respectively using the GPS L1 C/A signal. In the future, GBAS will utilize additional modernized signals such as GPS L5 and Galileo E1c/E5a to improve navigation accuracy and integrity performance under a solution designated GAST F to support CAT II/III. The additional signals should also be protected against signal distortions. GAST D provides requirements of the Probability of Missed Detection (PMD) for monitors to detect ranging source faults [START_REF]Conceptual Framework for the Proposal for GBAS to Support CAT III Operations[END_REF] and the same requirement may be applied to GAST F subject to caveats regarding the processing mode. An ionosphere-free processing leads to greater differential ranging errors under failure and this would need to be taken in to account. The PMD compliance of signal quality monitors for GAST D has been assessed for GPS L1 C/A [START_REF] Brenner | Ranging Source Fault Detection Performance for Category III GBAS[END_REF], however, the assessment for GAST F using multi-constellation and multifrequency signals has not been conducted thoroughly.

This study focuses on the assessment of GBAS signal quality monitors under the proposed GAST F solution. The threat model for GPS L1 C/A signal has been defined in the International Civil Aviation Organization (ICAO) standards [START_REF] Icao | Aeronautical Telecommunications Volume 1 Radio Navigation Aids[END_REF]. Agreement on the threat space of the modernized signals has not yet been reached at standardization level. However, research has proposed threat spaces for those signals, taking into account different chipping rates and correlation functions [START_REF] Pagot | Modeling and Monitoring of New GNSS Signal Distortions in the Context of Civil Aviation[END_REF]. Among them, the threat spaces for Galileo signals are under a validation process prior to standardization. Based on these threat models, signal quality monitors are tested for dual-frequency modes. To be more specific, dual-frequency signal quality monitors for GPS L1/L5 and Galileo E1c/E5a are tested under dual-frequency navigation mode (i.e. ionosphere-free (IF) navigation mode) whether they comply with the PMD requirement according to the differential range errors. The differential range error in IF navigation mode can have larger values than those in the single-frequency navigation mode, because the range errors on the two frequencies of L1/E1 and L5/E5a are multiplied by 2.26 and -1.26, respectively, according to the factors used to form the linear combination of an IF measurement.

In the work undertaken, new dual-frequency monitors have been designed; as well as the definition of a combination of monitors to protect against signal distortions. Three types of monitors are used to detect signal distortions in this study: the first is the signal quality monitor developed by Honeywell in 2006 [START_REF] Liu | Signal Deformation Monitoring Scheme Implemented in a Prototype Local Area Augmentation System Ground Installation[END_REF], the second is a variation of the Code-Carrier Divergence (CCD) monitor developed by ENAC [START_REF] Jiang | Code carrier divergence monitoring for dual-frequency GBAS[END_REF] and the third is a novel Divergence-Free (DF) Innovation monitor. This novel DF-Innovation monitor compares a dummy pseudorange computed using the divergence-free combination to the predicted DF pseudorange at the current epoch, which is propagated from the previous epoch using variations of the carrier phase. Accordingly, the novel monitor is sensitive to capturing step faults in the pseudorange measurements, yet is not impacted by ionospheric noise which reduces the efficiency of existing step detectors. When determining thresholds for the monitors of the CCD and the DF-Innovation monitor, statistics were computed using measurements collected from the GBAS reference receivers at Tenerife airport.

In this assessment, not only the performance of the monitors but also the differential range errors between ground and airborne receivers play a critical role is determining PMD compliance. The differential range error can vary according to the bias errors associated with signal distortion as well as a function of the different pseudorange smoothing filter initialization times at ground and airborne sides. The nominal case can be that both filters at the ground and airborne are initialized far earlier than the fault onset time (post-convergence case). The worst case for the PMD compliance occurs when the airborne smoothing is initialized just after the fault onset time. In this case the differential range error becomes large before the fault is fully incorporated in the monitor (transient case). In this case the pseudorange smoothing filter at the ground is initialized far earlier which is guaranteed by ground subsystem wait times specified in the standards. Consequently, PMD compliance was tested for various filter initialization times of the airborne receiver.

The monitoring performance also varies with the time constant used for pseudorange smoothing filter. A 30-second time constant is used for GAST D solution. For GAST F, it is under discussion to use a 100-second time constant in order to leverage the existing 100s corrections provided in GBAS Message Type 1 (MT1). Thus, this study further assesses the effect of the time constant used for the pseudorange smoothing filter on the PMD compliance.

Simulations have then been performed to investigate the monitoring performance and check under what conditions compliance with the requirement is achieved. The simulation has the following procedure: firstly, the GNSS code sequences are generated and the distortion is added onto the code sequences according to values given by the threat model parameters, which represent the lead/lag of a chip, resonant frequency and damping factor. This is made for the full range of parameter combinations within the threat space. Secondly, the correlation function is computed, and it is applied to the pre-correlation filters according to the types of filters and associated bandwidths. By inspecting the filtered correlation function with the Early-Late correlator, the code tracking offset is computed. The resultant code delay can vary according to the values of chip spacings selected for Early-Late correlator. Thirdly, the range error can be computed by comparing code delay values from nominal and distorted correlation functions, and it represents the error associated with the signal distortion. The ground and airborne receivers experience different range errors if they have different receiver configurations. Finally, the computed range error is added to the simulated pseudorange measurement. The Honeywell signal quality monitor uses multi-correlator outputs directly to detect the signal distortion. On the other hand, the CCD and DF-Innovation monitor use the code pseudorange and phase measurements to detect the effect of signal distortion in the range domain. Taking into account the different ground latency for GAST D and proposed latency for GAST F, which reflects the update interval of the correction message and ground processing delay, the PMD is plotted against the absolute value of the differential range error. In this simulation, Time-To-Detect and Affect Broadcast (TTDABA) is set to 1.5 seconds for GAST F, since the update interval of the integrity message must remain the same as for GAST D [START_REF] Milner | Evolution of Corrections Processing for the MC/MF Ground Based Augmentation System (GBAS)[END_REF]. As a result, the proposed dual-frequency signal quality monitoring solution within GAST F, which consists of the Honeywell signal quality monitor, ENAC DF CCD monitor and new DF-Innovation monitor complies with the PMD requirement for GPS L1/L5 and Galileo E1c/E1a signals when the 100-second time constant is used for pseudorange smoothing filter. The 145-second time delay, which indicates the time delay from initialization of the airborne filter to incorporation in the solution, needs to be set for PMD compliance under the transient case when only the existing Honeywell SQM and ENAC CCD monitors are used. On the other hand, when the proposed DF-Innovation monitor is used additionally, the time delay can be reduced to 30 seconds. In addition, from the results of an additional test for the pseudorange smoothing filter with the 30-second time constant, it was observed that the effect of the smoothing filter time constant acts differently on post-convergent and transient cases. That is, a longer time constant gives more compliant results for the post-convergent case, on contrary, a shorter time constant is more beneficial for the transient case.

MONITORS USED FOR SIGNAL DEFORMATION FAULTS

There have been few related works undertaken on the assessment of the signal deformation monitors for GAST D and F. For GAST D, Honeywell has assessed the minimum value of the PMD of Honeywell SQM, CCD monitors and step detector for GPS L1 C/A signal [START_REF] Brenner | Ranging Source Fault Detection Performance for Category III GBAS[END_REF]. It concludes that the under 25-sec of time delay, the PMD of the monitor was compliant for all fault cases and receiver configurations. However, the work has been done only for the GPS L1 C/A signal. For GAST F, Thales has assessed the PMD of three monitors for signal deformation faults for GPS and Galileo signals [START_REF]D3.7.1 Monitoring[END_REF]. However, the monitors used for the test and the threat space for GPS L5 and Galileo signals were not presented within the public domain. In this paper, the performance of the existing Honeywell SQM, ENAC CCD and the proposed DF-Innovation monitors is assessed for GAST F using the standardized threat space for GPS L1 C/A and the previously proposed threat spaces for GPS L5 and Galileo E1c/E5a [START_REF] Pagot | Modeling and Monitoring of New GNSS Signal Distortions in the Context of Civil Aviation[END_REF].

The Honeywell SQM monitor utilizes the correlator outputs from eight different correlator locations as shown in Error! Reference source not found. [START_REF] Liu | Signal Deformation Monitoring Scheme Implemented in a Prototype Local Area Augmentation System Ground Installation[END_REF]. The differences of correlator outputs between neighboring correlator locations are computed to form a vector, X, which has seven elements. The mean of the vector X is subtracted from the vector X and it is further normalized. Using the normalized vector, the square sum error, denoted as T, is computed and is used as the metric of the Honeywell SQM monitor. In this test, the theoretical standard deviations of correlator outputs are computed based on the approach introduced in [START_REF] Pagot | Modeling and Monitoring of New GNSS Signal Distortions in the Context of Civil Aviation[END_REF]. These theoretical values have been validated by the actual correlator output collection at the ENAC site using an iFen SX3 software receiver. The Honeywell SQM metric follows a chi-square distribution with 7 degrees of freedom. The continuity requirement for signal deformation fault is 1.5×10 -7 per 15 seconds. Since a 30-second time constant for a smoothing filter for the correlator outputs is used in the test, four independent samples are assumed in 15 seconds of exposure time following the updated analysis in [START_REF] Pervan | Test Statistic Auto-and Cross-correlation Effects on Monitor False Alert and Missed Detection Probabilities[END_REF]. Furthermore, considering a maximum of 15 tracked satellites, a threshold of 53.87 for the Honeywell SQM monitor is obtained.

ENAC DF CCD monitors [START_REF] Jiang | Code carrier divergence monitoring for dual-frequency GBAS[END_REF] are also used in the assessment. These monitors are based on the rate of the DF measurement combinations, which can be defined as the following equations.

        1 5 1 1 5 5 1 1 1 1 5 1 5 5 5 1 5 5 1 2 2 1 1 2 1 2 1 1 DF DF M M                                                                      ( 1 )
The symbols of ρ and 𝜙 are pseudorange and carrier phase measurements, respectively. The subscripts 1 and 5 indicate L1 and L5

frequencies. The symbols of M, ε and γ are multipath, noise error and the squared ratio of L1 and L5 frequencies, respectively. The ENAC DF CCD monitors take the filtered rate of the DF measurement combinations by two cascades 1 st order smoothing filter with 30-second of time constant. The threshold of this monitor is computed based on the statistics obtained from the Tenerife GBAS ground receiver, which will be given in the later section. The threshold of the ENAC DF CCD monitor has been determined according to the same approach used in previous research [START_REF] Jiang | Code carrier divergence monitoring for dual-frequency GBAS[END_REF].

ENAC Divergence-Free (DF) Innovation Monitor

Since the existing Honeywell SQM and ENAC CCD monitors both have to some degree a delayed response time, in some rare fault cases within the threat space, they cannot achieve sufficiently low PMDs right after the fault onset. This can be problematic when the airborne filter is initialized at or right after the fault onset, which has been defined as the 'transient case'. To deal with this problem, this paper proposes the ENAC DF-Innovation Monitor, which has high sensitivity in detecting step-type errors. This monitor simply measures the difference between a predicted pseudorange and a raw pseudorange at current epoch as shown as the following equation.

 1 , 1 , 1 , , 1 , 1 k
S C H E M Ek S C H E M Ek SCHEME k SCHEME k SCHEME k Y                    ( 2 )
The subscripts k and k+1 indicate previous and current epochs, respectively. In addition, the subscript, SCHEME can be either 'DF1' and 'DF5', which represent divergence-free (DF) L1 and L5 measurement combination. The operator tilde (˜) and Δ indicate the filtered value using 1 st order smoothing filter and a time difference operator. The computation of filtered ρ SCHEME can be seen in Figure 2. And the ρ SCHEME and 𝜙 SCHEME used for the DF1-and DF5-Innovation Monitors, filtered value of 𝜌 and their error components are shown in Table 1.

SCHEME ρSCHEME 𝜙SCHEME 𝜌 Error components in Y DF1 1 L  1 5 1 2 1            1 1 1 1 1 1 2 5 5 DF d b B T M                                 1 1 1 1 1 5 1 5 , , 1
, , 1 1 , 2 , 1 , 1 2 , 1 k k k k k k k k M M                                  DF5 5 L  1 5 5 2 1             5 5 5
1 1 1 2 5 5 DF d b B T M                                 5 5 5 5 1 5 1 5 , , 1
, , 1 1 , 2 , 1 , 1 2 , 1 k
k k k k k k k M M                                  Note 1 2 1 2 1 2 2 1 , , , 1 1 1 1
                      
To improve the performance of the monitor, the error level of the monitor needs to be reduced as much as possible. As shown in Table 1, the errors of the DF-Innovation monitor, denoted as Y, consist of multipath and noise errors. Looking closely at the equation, the multipath related term is the difference between the filtered multipath at the previous epoch and the raw multipath at the current epoch. Because the multipath is temporally correlated, this differenced value will have a smaller value if a small time constant for the smoothing filter is used. On the other hand, it is obvious that using a larger smoothing time constant is more effective in reducing error level of white noise components. That is, there is trade-off relationship in reducing error terms of multipath and noise error. To determine the time constant that is the most effective in reducing the error level of the DF-Innovation monitor, we collected two data sets from GBAS ground receivers in Barcelona and Tenerife Airports within the frame of the SESAR 2020 Pj14-03-01 WP8 T04.

The former is equipped with choke ring antenna and the latter with Low-Noise Antenna (MLA). Both sites used Novaltel ProPak 6 receivers. The Barcelona data is collected on day-of-year (DOY) 316-317 in 2017 with 2 Hz sampling and the Tenerife data is collected on DOY 128 in 2019 with the same sampling rate. Using these data collections, the standard deviations of the DF1-Innovation Monitors are computed according to elevation angles as shown in Figure 3. As a result, the smaller the time constant of the smoothing filter was used, the smaller the standard deviation of the monitor we could obtain. We think that the impact of multipath is dominant over that of noise error. In this paper, we choose to use a standard deviation obtained from Tenerife airport using the smoothing filter with 1-second time constant for the DF-Innovation Monitor when the measurement sampling interval is 0.5 second. Note that this is not the final decision of the time constant for the proposed monitor. More data analysis is needed to finalize the design of the DF-Innovation Monitor. But for now, a 1-second time constant is used for filtering the DF-Innovation Monitor. The obtained standard deviations for the ENAC CCD and DF-Innovation monitors are summarized in Table 2. We took standard deviation computed for low elevation angles (5-10deg) for conservative analysis. The over-bound factor is determined such that the inflated theoretical normal distribution bounds the actual distribution based on a Q-Q plot. The threshold of the DF-Innovation monitor is determined based on the continuity requirement of signal deformation fault given as 1.5×10 -7 per 15 seconds. When we compute the probability of false alarm rate, we assume the worst case that there are 15 independent samples during the 15-second of exposure time and 15 satellites being tracked simultaneously.

REQUIREMENT ON RANGE FAULT MONITOR FOR GAST D

The requirement on the ranging source fault monitor for GAST D has been defined in the standard document as shown in Figure 4 [2]. For GAST F, this requirement may be relaxed in the future since the satellite geometry will be improved for the multiconstellation geometries. However, this requirement specific for GAST F has not been defined yet in the standards document, so the same requirement for GAST D is used for GAST F in this assessment. For the assessment of the performance of the signal quality monitors, the differential range error and the PMD needs to be computed correctly. As recommended in the standard document [START_REF]Conceptual Framework for the Proposal for GBAS to Support CAT III Operations[END_REF], ground latency, which represents the correction broadcast delay and margin, is considered when computing differential range error and integrity message latency and time-to-alert is taken into account when computing the PMD. The values for these parameters will be given in the next section.

SIMULATION ENVIRONMENT

In this study, the PMD compliance of the monitors for the satellite signal deformation is assessed in two modes. One is for singlefrequency mode and the other is for dual-frequency mode. For single-frequency mode, the performance of the signal distortion monitors is assessed on GPS L1, Galileo E1c and GPS L5/Galileo E5a separately, assuming that the GAST D can be applied not only for GPS L1 but also for other GNSS signals on single-frequency basis. For dual-frequency mode, the test assumes that a single fault occurs on one frequency. The performance of the monitors is assessed for the following types of test.

Assessment Process

Simulations have been performed to investigate the monitor performance and to check under what conditions compliance with the requirement is achieved. The simulation has the following procedure: firstly, the GNSS code sequences are generated and the distortion is added onto the code sequences according to values given by the threat model parameters, which represent the lead/lag of a chip, resonant frequency and damping factor. This is made for the full range of parameter combinations within the threat space. Secondly, the correlation function is computed, and it is applied to the pre-correlation filters according to the types of filters and associated bandwidths. By inspecting the filtered correlation function with the Early-Late correlator, the code tracking offset is computed. The resultant code delay can vary according to the values of chip spacings selected for Early-Late correlator. Thirdly, the range error can be computed by comparing code delay values from nominal and distorted correlation functions, and it represents the error associated with the signal deformation. The ground and airborne receivers experience different range errors if they have different receiver configurations. Finally, the computed range error is added to the simulated pseudorange measurement. This procedure has been programmed in Matlab by ENAC [START_REF] Pagot | Modeling and Monitoring of New GNSS Signal Distortions in the Context of Civil Aviation[END_REF] and validated for several years.

Receiver configuration

For some specific satellite signal deformations, the effect on the range error can differ according to receiver configurations in terms of precorrelation bandwidth, Early-Late correlator chip spacing and the types of precorrelation filter used. To take into account all possible cases of differential range errors, the test has been conducted for various receiver configurations at the airborne receiver.

Considering the GPS tracking constraints given in [START_REF]Minimum Operational Performance Standards (MOPS) for GPS Local Area Augmentation System Airborne Equipment[END_REF], the precorrelation bandwidth and Early-Late correlator chip spacing for ground airborne receivers are set as shown in Figure 5. It should be noted that there are no tracking constraints defined for GPS L5, Galileo E1c/E5a signals yet. For those signals, the types of precorrelation filters are set to the same ones used by [START_REF] Pagot | Modeling and Monitoring of New GNSS Signal Distortions in the Context of Civil Aviation[END_REF]. At the ground receiver, 6th-order Butterworth filter was used and at airborne receiver, the following 4 types of filters are tested: 6th-order Butterworth filter, 0-group delay resonator, 150 ns differential group delay resonator and 150 ns differential group delay resonator.

Threat spaces for GPS L1/L5 and Galileo E1c/E5a signals

The signal deformation fault for GPS L1 C/A has been defined in the standard document [START_REF] Brenner | Ranging Source Fault Detection Performance for Category III GBAS[END_REF]. There are three types of threat models, which are classified into threat model A, B and C. Threat model A represents the digital fault when the chips are leaded or lagged to some amount of chips (Δ). Threat model B is the analog faults, which adopts the unit step response of a second order system that is modeled by resonant frequency (f d ) and damping factor (σ). There has not been defined standard model for GPS L5 and Galileo E1c/E5a signals yet, however, [START_REF] Pagot | Modeling and Monitoring of New GNSS Signal Distortions in the Context of Civil Aviation[END_REF] proposed the threat models for those signals using the same threat model structures. This paper adopts the threat model in [START_REF] Pagot | Modeling and Monitoring of New GNSS Signal Distortions in the Context of Civil Aviation[END_REF] for GPS L5 and Galileo E1c/E5a signals. Table 3 and Table 4 show the threat model parameters for all signals.

Test configuration

The timing values that are used in this test are defined in Table 5. The latency of the correction message is set to different values for GAST D and F because the message update interval will be increased in GAST F [START_REF] Milner | Evolution of Corrections Processing for the MC/MF Ground Based Augmentation System (GBAS)[END_REF][START_REF]D3.7.1 Monitoring[END_REF]. On the other hand, the update interval of the integrity message will stay the same for GAST F, the value of 1.5second is set for GAST D and F. Time-To-Detect and Affect the Broadcast (TTDABA) is 1.5seconds for both GAST D and F, because the time-to-alert requirement will not change for GAST F [START_REF]Conceptual Framework for the Proposal for GBAS to Support CAT III Operations[END_REF][START_REF] Milner | Evolution of Corrections Processing for the MC/MF Ground Based Augmentation System (GBAS)[END_REF]. The time constant used for smoothing filter is set to 30second for GAST D and 100second for GAST F [START_REF] Jiang | Code carrier divergence monitoring for dual-frequency GBAS[END_REF][START_REF]D3.7.1 Monitoring[END_REF]. The fault onset time is set to 180second, and the ground filter is assumed to be initialized at 0 second. We considered two cases for the airborne filter initialization time: one represents the post-convergence case and the other is transientcase. These two cases need to be taken into account because there is a possibility of having various differential range error even under the same fault cases and receiver configurations. Figure 6 shows time histories of the range error at ground and airborne, associated differential range error and ground monitor for post-convergence and transient cases. The post-convergence case indicates when the airborne filter is initialized far earlier than the time of the fault onset. In this case, the differential range error gradually increases starting from zero and at the same time, the ground monitor metric also gradually increases after the fault onset. If you recall the PMD requirement defined in Figure 4, there is a high possibility that the associated situation can be plotted within the requirement PMD, that is, the PMD compliance region. On the other hand, in the transient-case, the airborne filter is initialized at or right after the fault onset, and accordingly, the differential range error starts from nonzero value and gradually decreases. However, as the ground monitor behaves as the same as the post-convergence case, there is a high change that the associated differential range error and the PMD of ground monitor falls outside of the PMD requirement plot. Therefore, it may be more difficult to achieve compliance for the monitors in the transient case. To deal with this problem, the term 'time delay', denoted as t delay , is introduced, which indicates the time from the airborne filter initialization to the moment when the airborne incorporates the correction and measurement for navigation. Generally, the value of 50 seconds is recommended for this parameter [START_REF] Jiang | Code carrier divergence monitoring for dual-frequency GBAS[END_REF].

Simulation parameters Values

Latency of correction message (τ G ) GAST D: 1.5sec (message update interval 0.5sec + ground delay 1sec) GAST F: 3sec (message update interval 2.0sec + ground delay 1sec) [START_REF] Milner | Evolution of Corrections Processing for the MC/MF Ground Based Augmentation System (GBAS)[END_REF][START_REF]D3.7.1 Monitoring[END_REF] Latency of Integrity message (τ I ) GAST D: 1.5sec (message update interval 0.5sec + ground delay 1sec) GAST F: 1.5sec (message update interval 0.5sec + ground delay 1sec) [START_REF] Milner | Evolution of Corrections Processing for the MC/MF Ground Based Augmentation System (GBAS)[END_REF] Time-To-Detect and Affect the Broadcast (TTDABA)

GAST D, GAST F: 1.5sec (0.5sec missed integrity messages + 1.0sec margin) [START_REF]Conceptual Framework for the Proposal for GBAS to Support CAT III Operations[END_REF][START_REF] Milner | Evolution of Corrections Processing for the MC/MF Ground Based Augmentation System (GBAS)[END_REF] Time constant for carrier smoothing GAST D: 30sec GAST F: 100sec Time of fault onset (t f ) 180 sec Filter initialization time at ground (t g ) 0 sec

Filter initialization time at airborne (t a ) Post-convergence case: 50sec Transient case: 180sec

TEST RESULTS

Firstly, the performance of the monitors for single frequency mode is assessed. Table 6 shows the PMD compliance results for all fault cases and receiver configurations. The green shade indicates the compliance and the red shade indicates the non-compliance. During the assessment, the time delay, t delay is set to 50 seconds for transient case, which is commonly used value for this parameter.

For GPS L1 signal, the time constant for carrier smoothing filter, TTDABA and ground latency are recommended in the standard document. However, those values for other signals are not recommended yet, therefore two values of time constant for carrier smoothing filter is tested for GPS L5 and Galileo E1c/E5a signals. In the meanwhile, the update interval of the correction message is planned to increase for multi-constellation and multi-frequency modes, the latency of correction message is set to 3.0 seconds for GPS L5 and Galileo E1c/E5a signals. As a result, the PMD of the monitors was compliant for all fault cases and receiver configurations for GPS L1 signal. However, for Galileo E1c signal, the PMD was not compliant for the TMB and TMC fault cases under post-convergence case when 30-second of time constant is used for a carrier smoothing filter. If the time constant is increased to 100 seconds, the PMD was compliant for all fault cases under post-convergence case, however, there was one non-compliant result only for the TMA-type fault under transient case. For GPS L5 or Galileo E5a signal, the PMD was all compliant when 30-second of time constant for smoothing filter is used. If the time constant is increased to 100 seconds, for transient case, the PMD becomes noncompliant. For transient case, to make the monitor become compliant with the requirement, t delay needs to be increased over 50 seconds.

CONCLUSIONS

This paper proposed the ENAC DF-Innovation monitor, which can improve detection performance right after the fault onset where the existing Honeywell SQM and ENAC CCD monitors are vulnerable due to the response time of each metric. By analyzing the error components in the DF-Innovation monitor, a 1-second time constant was determined which can reduce the errors in the monitor to the lowest level for two data collections at Barcelona and Tenerife airports. Since not every detail has been standardized for GAST F so far, the values of a time constant for carrier smoothing filter, latencies of correction and integrity messages and TTDABA are selected appropriately based on the recent agreements on GAST F within SESAR studies and former research. In addition, the threat spaces for GPS L5 and Galileo E1c/E5a are adopted from the previous ENAC work.

The assessment has been conducted in two modes: single-frequency mode (GAST D or GAST D like) and dual-frequency mode (GAST F). In the results for the single-frequency mode, the PMD was compliant for GPS L1 signal for all fault cases and receiver configurations. For Galileo E1c, the PMD was compliant except for the TMB and TMC under post-convergence case when the 30 seconds of time constant was used, and for the TMA under transient case when the time constant was set to 100 seconds. For Galileo E5a, all cases are compliant when a 30-second time constant for the carrier smoothing filter is used. However, if the time constant is increased to 100 seconds, all transient cases become non-compliant. Unlike the single-frequency mode, the PMD was compliant with the requirement for all fault cases and receiver configurations for all signals under the dual-frequency mode. The improvement of the performance of the ENAC CCD monitor due to the elimination of the ionospheric delay and the utilization of the ENAC DF-Innovation monitor seem to play a critical role for making PMD compliant for dual-frequency mode. We also check the advantage of using the proposed ENAC DF-Innovation monitor that it can reduce the required t delay by 80% compared to the case without using the proposed monitor. The proposed monitor also can reduce the recommended t delay below 50 seconds, which can allow airborne users to wait less time to compute their positions.

In this research, only a single fault on a single frequency has been considered. We need to check if there is any possibility of having dual faults on two frequencies simultaneously. However, the general consensus appears to be that this threat may be neglected [START_REF]Baseline development standards for the validation of draft Annex 10, Volume I amendments relating to dual-frequency, multi-constellation (DFMC) SBAS[END_REF].

In addition, the minimum PMD among the PMDs of three monitors is used for assessment of the PMD compliance in this test. We think that it is more realistic to compute the PMD by considering the correlations among monitors in the future. Furthermore, we are planning to use the extended threat space for Galileo signals which are discussed upon for standardization for the PMD assessment when it becomes available.

Figure 1 Figure 2 Table 1

 121 Figure 1 Description of Honeywell SQM Monitor[START_REF] Pagot | Modeling and Monitoring of New GNSS Signal Distortions in the Context of Civil Aviation[END_REF]

Figure 3

 3 Figure 3 Standard deviation of DF1-Innovation Monitor at (a) Barcelona airport (Choke-ring antenna) and (b) Tenerife airport (MLA antenna)

Figure 4

 4 Figure4PMD constraints according to differential range error[START_REF]Conceptual Framework for the Proposal for GBAS to Support CAT III Operations[END_REF]

  • GPS L1/L5: a single fault occurred on L1 frequency, DF1 monitors are used under ionosphere-free (IF) navigation mode • GPS L1/L5: a single fault occurred on L5 frequency, DF5 monitors are used under IF navigation mode • Galileo E1/E5: a single fault occurred on E1c frequency, DF1 monitors are used under IF navigation mode • Galileo E1/E5: a single fault occurred on E5a frequency, DF5 monitors are used under IF navigation mode

Figure 5

 5 Figure 5 Receiver configuration at ground and airborne for GPS L1/Galileo E1c and GPS L5/Galileo E5a

  0.12:0.01:0.12 (chip) f d = 0 (MHz) σ = 0 (Mnepers/s) Δ = 0 (chip) f d = 4:0.1:17 (MHz) σ = 0.8:0.5:8.8 (Mnepers/s) Δ = -0.12:0.01:0.12 (chip) f d = 7.3:0.1:13 (MHz) σ = 0.8:0.5:8.8 (Mnepers/s)

Figure 6 Figure 7

 67 Figure 6 Differential range error and ground monitor for (a) post-convergence case and (b) transient case

Table 2

 2 The standard deviation obtained from Tenerife GBAS ground receiver for ENAC CCD and DF-Innovation monitors

		GPS		Galileo
	Monitors	Standard deviation	Over-bound factor	Standard deviation	Over-bound factor
	ENAC CCD DF1	0.0009 m/s	2.53	0.0028 m/s	1.39
	ENAC CCD DF5	0.0011 m/s	1.76	0.0028 m/s	1.82
	DF1-Innovation Monitor	0.0102 m	1.29	0.0086 m	1.41
	DF5-Innovation Monitor	0.0113 m	1.20	0.0124 m	1.37

Table 3

 3 Threat model parameter of GPS L1 C/A[START_REF] Brenner | Ranging Source Fault Detection Performance for Category III GBAS[END_REF]

Table 4

 4 Threat model parameters for GPS L5, Galileo E1c/E5a[START_REF] Pagot | Modeling and Monitoring of New GNSS Signal Distortions in the Context of Civil Aviation[END_REF]

	TMC

Table 5

 5 Test configuration

Table 6

 6

	PMD compliance results for single-frequency mode (GAST D, GAST D like)
				PMD compliance results
			GPS L1	Galileo E1c	GPS L5/Galileo E5a
	Time constant for carrier smoothing	30sec	30sec	100sec	30sec	100sec
		Post-
	TMA	convergence
		Transient

Table 8 Required

 8

			Minimum required t delay (sec)
		GPS L1	GAL E1c	GPS L5	GAL E5a	Overall
	Honeywell SQM +ENAC CCD	30	145	20	20	145
	Honeywell SQM
	+ENAC CCD	30	30	20	20	30
	+ENAC DF-Innovation Monitor

tdelay for all signals and its overall value for (Honeywell SQM+ENAC CCD) vs. (Honeywell SQM+ENAC CCD+ENAC DF-Innovation monitor)

ACKNOWLEDGEMENTS

This work is funded by Single European Sky ATM Research (SESAR) Joint Undertaking within the frame of the SESAR 2020 Pj14-03-01 WP8 T04. The authors would like to thank INDRA Navia, INDRA Satnav and ENAIRE for the use of data collection under the SESAR Program.

is currently part of the SIGnal processing and NAVigation (SIGNAVSara Bouterfas is a research assistant at the Signal Processing and Navigation (SIGNAV) research She received her Engineering degree (equivalent MSc.) in

Secondly, the performance of the monitors for dual-frequency modes is assessed. Table 7 shows that the PMD of the monitors was compliant under all fault cases and all receiver configurations for all signals when Honeywell SQM, ENAC CCD and ENAC DF-Innovation monitors are used. For transient case, the value of t delay is set to 50 seconds as the previous test. We think that the reason why the PMD was compliant for all cases for dual-frequency mode unlike single-frequency mode is because the performance of the ENAC CCD monitor has been improved through elimination of the ionospheric delay in the monitor and the use of the proposed ENAC DF-Innovation monitor. To see the advantage of using ENAC DF-Innovation monitor, the required value of t delay is plotted for Galileo E1c transient case under TMC2 fault cases when the value of Δ equals to -0.02 chip in Figure 7. The left figure is plotted for the case when only Honeywell SQM and ENAC CCD monitors are used, and the right figure shows the result when the ENAC DF-Innovation monitor is additionally used. For some specific values of f d and 𝜎/𝑓 , the first case requires at least 145 seconds of t delay to make the monitor become compliant with the requirement. On the other hand, when the ENAC DF-Innovation monitor is added, the required t delay is reduced to 30 seconds where the gain is approximately 80%. Table 8 summarizes the required t delay for each signal and for two cases where the one without the ENAC DF-Innovation monitor and the other with the proposed monitor. For the monitors to be compliant with the requirement regardless of types of signals, the first case needs minimum 145 seconds of t delay , on the other hand, the second case with the proposed monitor requires only 30 seconds. To sum up, the addition of the ENAC DF-Innovation monitor can reduce the required t delay by 80 and thus avoid unnecessary delays for the use of newly available satellites. Moreover, it also suggests that the addition of the ENAC DF-Innovation monitor can even reduce the recommended t delay from 50 seconds to 30 seconds if considering only the signal deformation fault.