Fabien Coulon
email: fabien.coulon@obeo.fr

Alex Auvolat
email: alex.auvolat@inria.fr

François Taïani
email: francois.taiani@irisa.fr

Olivier Barais
email: olivier.barais@irisa.fr

Modular and Distributed IDE

Keywords: Microservice, IDE, Generative approach

Integrated Development Environments (IDEs) are indispensable companions to programming languages. They are increasingly turning towards Web-based infrastructure. The rise of a protocol such as the Language Server Protocol (LSP) that standardizes the separation between a languageagnostic IDE, and a language server that provides all language services (e.g., auto completion, compiler...) has allowed the emergence of high quality generic Web components to build the IDE part that runs in the browser. However, all language services require different computing capacities and response times to guarantee a user-friendly experience within the IDE. The monolithic distribution of all language services prevents to leverage on the available execution platforms (e.g., local platform, application server, cloud). In contrast with the current approaches that provide IDEs in the form of a monolithic client-server architecture, we explore in this paper the modularization of all language services to support their individual deployment and dynamic adaptation within an IDE. We evaluate the performance impact of the distribution of the language services across the available execution platforms on four EMF-based languages, and demonstrate the benefit of a custom distribution.

CCS Concepts: • Software and its engineering → Domain specific languages.

Introduction

Modern Integrated Development Environments (IDE) are moving to the Software as a Service (SaaS) model [START_REF] Dubey | Delivering software as a service[END_REF] in order to benefit from advantages [START_REF] Heiser | Hype cycle for software as a service[END_REF] such as better accessibility (since the application is already installed and configured), lower costs to maintain and/or upgrade, scalability, etc. The rise of a protocol such as the Language Server Protocol (LSP) that standardizes the protocol used between a languageagnostic IDE and a language server that provides language services (as defined in Definition 1.1) such as auto completion, search for definition, search for all references, compilation, etc. has allowed the emergence of high quality generic Web components to build the IDE part that runs in the browser. For instance, Monaco 1 (used in VSCode 2 , Theia 3 , . . . ), Atom 4 , CodeMirror 5 (CodePen 6 , Jupyter 7 ), are now embeddable Web components with a direct support of most of the LSP features, thereby simplifying the development of Web-based IDEs. Definition 1.1. We consider as language service any languagespecific functionality that can be used by a language user, and that takes a program as input. Such service can be a functionality related to editing programs giving quick feedback to the user (e.g., auto completion, goto definition, etc) but can also be a more long running functionality related to other activities (e.g., compiler, debugger, etc).

However, defining the architecture of an LSP server implementation and more generally the server implementation for a particular language remains a complex step. The simplistic deployment of the language server part in a sufficiently powerful cloud does not in reality provide the optimal userexperience. Each of language services has specific requirements in terms of latency and bandwidth, but also in terms of specific computing capacity. It is therefore important to tune the deployment according to the services of a particular language but also according to the context of use of the IDE for a given user, and the available execution platforms. For example, it could be required to reduce the network requirements if the quality of the network decreases for a specific user. Such an implementation of a language server should therefore be essentially a Dynamically Adaptive System (DAS) [START_REF] Ramirez | Design Patterns for Developing Dynamically Adaptive Systems[END_REF] in which we could provide tailored distribution of the language services that optimizes the user experience and their overall performance. Defining the architecture of such a system requires fine-grained modularity in both design and deployment, and the ability to run in a distributed and heterogeneous environment.

In contrast with the current approaches that provide IDEs in the form of a monolithic client-server architecture, we explore in this paper the modularization of all language services to support their individual deployment and dynamic adaptation within an IDE. Since the distribution requires both the modularization of the language services, and the deployment (and possibly the dynamic reconfiguration) over the available environment, we propose a generative approach to automatically obtain microservices implementing language services from a language specification, complemented with a feature model that drives the safe configuration and automates the deployment of IDE features. We explicit IDE feature in Definition 1.2. Definition 1.2. We define an IDE feature as the deployment unit of a distributed IDE. It is a coherent group of language services intended to always be deployed together.

We study the impact on performances when distributing the language services across the available execution platforms. We evaluate our approach on four EMF-based languages and demonstrate the benefit of a custom distribution of the various language services. In particular, we apply our approach to NabLab8 , our own implementation of the Logo language 9 , MiniJava 10 and ThingML 11 to compare response times of language services in our approach with monolithic language server. This paper is organized as follows. Section 2 motivates this work by describing the example of a monolithic language server, and the heterogeneity of the different proposed language services. Section 3 gives the big picture of our approach and explains why we use microservices and feature modeling. Section 4 describes how we generate microservices, as well as the feature model and its associated deployment approach. In section 5 we study our approach on four EMF-based languages and we evaluate the cost by comparing the response times of the language services of our microservice-based architecture with that of monolithic language servers.

Motivating example

To illustrate the heterogeneity of the various services provided by modern IDEs, we use in this section and throughout this paper the open-source and industrial Domain-Specific Language (DSL) NabLab. NabLab provides a productive development environment for numerical analysis over exascale HPC technologies. The associated IDE provides all the common editing services (syntax coloring, auto-completion, validators...) and a complex compilation chain targeting various backends. NabLab users are mathematicians and physicists that write algorithms for numerical analysis. NabLab programs are mainly composed of jobs with complex data flow between them, representing physical systems. As the computation used to simulate physical systems is expensive, NabLab programs are given to a compilation chain generating efficient source code to run the different jobs in parallel.

Figure 1 represents the current IDE architecture according to the state of practices. This architecture separates the IDE client, which is the language-agnostic interface for language users, from the language server which implements the language-specific services. The IDE client remotely calls these services by sending JSON-RPC 12 messages to the language server. This architecture allows to deploy the IDE client and the language server possibly in different execution platforms (e.g., the client on the development laptop, and the server on the cloud or an application server). In practice, NabLab has been developed using the Eclipse Modeling Framework [START_REF] Steinberg | EMF: Eclipse Modeling Framework 2.0[END_REF], including the Ecore 13 , Xtext14 and Sirius15 technologies.

For the sake of illustration, we selected four representative language services provided by the NabLab IDE: completion is a content assist that returns a list of proposals for a given context, references searches for elements in a file referring to a given symbol, rename changes names for a given element and for all its referring elements, and compiler performs graph analysis of the concurrent job to generate optimized Current IDE Architecture, including a languageagnostic client that provides the user interface, and a language-specific server that provides all the language services for a given language Java source code (one of the possible backends in NabLab).

We have chosen these language services to be representative of language user's activities: editing of code, navigation in the code, code refactoring, and code transformation. In the NabLab IDE, completion, references and rename are obtained with Xtext and the support of the Language Server Protocol (LSP), while compiler is a separate compilation chain integrated and prompted from the IDE. To illustrate the heterogeneity of these language services and the potential benefits of distributing them, we measured their response times on NabLab files of increasing size. The measurements were performed 100 times for each language service, with a client and a server both deployed on the same machine with an Intel Core i7-7600U CPU at 2.80GHz, 32 GiB of RAM, and the HotSpot JVM 11.0.5. Figure 2 presents the means of the response times expressed in milliseconds (ms) for the different files and, due to the large range of values, with a logarithmic scale.

We observe significant heterogeneity among language services, ranging from completion that lasts about 5 ms constantly over the files, to references that goes up to about 188 ms, rename that goes up to 7.106 seconds, and finally compiler that goes up to 14.78 minutes. This difference in response times between the language services is of several orders of magnitude. It can be explained by the amount of computation performed by each service: completion traverses object's references, reference is a query in a graph of objects, rename rewrites the file and compiler performs complex graph analysis and generates source code. This motivates the need for an individual and distributed deployment of each language service to leverage better the available execution platforms, fit the activities performed, and eventually provide the best user experience within the IDE client. In particular, in this paper, we focus on the following research questions:

RQ1 Is it possible to provide a systematic approach that automates the modularization of the language service implementations, supports their individual deployment, and enables their dynamic adaptation according to a given context (e.g. usage, environment)? RQ2 Is it possible to optimize the distribution of the language services across the available runtime platforms (e.g., local platform, application server, cloud) to improve their performances within the IDE?

Approach overview

We propose a systematic approach that eases the modularization and distribution of highly configurable IDEs for DSLs. The approach takes as inputs i) a software language specification, in the form of a metamodel, a syntax description, and any additional concerns such as validators, compilers, etc., and ii) a set of desired features (i.e., coherent groups of services) that the IDE must or may provide. As output, the approach generates a set of modular, language-specific, IDE features and a tool-supported feature model to configure and automate their distribution and integration within a Web-based IDE.

We distinguish two different user roles: language users, and language designers. In our process, configurability of an IDE by an end user relies on software product line principles: using a language specification as input, language designers build in fact a family of distributed IDEs. Language designers, or even language users, can then configure the family to deploy a distributed IDE that suits the user's needs and experience. Since the needs of language user can evolve over time, the deployment of the IDE can be dynamically reconfigured Figure 3 presents the overall approach, from the specifications to the deployment of an IDE. First, a language designer provides a language specification along with a protocol specification that describes the expected modularity of the language services and their interactions. From these specifications, we automatically generate a set of microservices implementing the IDE features and a feature model that captures their valid configurations (step 1 ○). The feature model offers a description of the variability of a system, here our variability is the availability of IDE features and their deployment configuration, presented as a tree of features enriched with logical constraints. ○ IDE microservicesation and 2 ○ IDE deployment alternatives are, their dependencies and whether they are mandatory or optional. Since dependencies form a graph, we compute a minimum spanning tree to create the hierarchy of the feature model and we encode as logical constraints the remaining dependencies. The IDE and its deployment can then be configured by a language designer or user (step 2 ○), depending on who has the knowledge to decide where to deploy the microservices. Configurations could also be proposed by an automated process involving a predictive model in the deployment, or through dynamic reconfiguration, in an attempt to maintain metrics such as user experience. The IDE configuration consists of selecting the microservices that will be available to the language user, together with information on where to deploy them. The feature model is used to validate the set of microservices to be deployed by checking the variability constraints. At the end, the microservices are distributed to different execution platforms such as development laptop, cloud or application servers. At this stage, the language services are running and the language user can use them through an IDE client.

The following quality criteria guided our current implementation of this systematic approach:

• IDE configurability for the end user: it is supported by a feature model driving the safe deployment of the language services • efficiency of resource usage (CPU time, bandwidth, reactivity as perceived by the end user): it is allowed by the modularization of language services which are individually deployables according to their expected optimal quality of service • extendibility and reusability from the point of the language designer, i.e., when the set of features evolve or when distributed platform technologies change (long term, human driven adaptation): they are enabled thanks to the specification of the protocol by the language designer which defines the granularity of the language services and their dependencies

• adaptability, possibly dynamically (according to the usage and environment): it is reached through the stateless nature of generated microservices that supports dynamic reconfiguration (maintenance, evolution, deployment, ...)

Our process design decisions were taken to obtain a satisfactory balance of these criteria.

In the rest of this section, we detail the two main steps of our approach ( 1○ and 2 ○ in Figure 3).

Designing IDE microservices

The design of an IDE family is based on two main inputs that are required to improve flexibility and reusability of elementary design elements, thereby supporting the language designer in providing a highly and dynamically customizable distributed IDE.

Language specification. The language designer needs a language specification. In our prototype, the language specification comes as an Ecore metamodel, and Xtext grammar description, and additional services such as compilers. Using tools such as Xtext, the language designer is able to produce a software module that acts as a parser and builds a model from a program file, as an internal, metamodel compliant, form of the program.

Protocol specification. The language designer also provides a description of the expected modularity of the language services in the form of a so called protocol. Code completion, symbol renaming, compiler, are examples of such language services (capabilities) that may be grouped into IDE features as deployment units. The grouping of the language services into IDE features, and their inter-dependencies, are expressed in a specific model, for which we provide a specific DSL with a concrete syntax, and a metamodel shown in Figure 4.

Using this DSL the language designer is able to declare the properties and relationships of each feature declared in a protocol specification. The DSL relies on the following types (cf. Figure 4): From the language specification and the protocol specification, we implemented a generative approach ( 1 ○ in Figure 3) that produces:

• a set of modular language services in the form of cloudnative applications as microservices, and the required code that will take care of the communication between language services as described in the protocol. • a feature model that represents the IDE family.

The feature model can then be enriched with deployments constraints, e.g.:

• for efficiency reason some capabilities need to be implemented by the same feature, and therefore deployed on the same execution node; • some features are alternatives in a group, e.g., if at run time the currently deployed feature becomes unavailable then one alternative will be deployed automatically.

IDE Deployment

The final task to build a usable, running IDE is the deployment phase. As mentioned before, we aim at providing a family of IDEs to the final language user, as different users have different needs, and a given user may also wish to tailor the IDE depending on the current tasks she is involved in. To support this flexibility we provide a deployment configurator, which is parameterized by the feature model generated from the protocol specification, to allow user control on which capabilities to deploy and where, while maintaining the constraints defined in the feature model. A point to consider in order to support reconfiguration of the deployment (i.e., to move microservices) is that we implement language services as stateless microservices. This has benefits for the scalability of distributed applications since a microservice can be replicated and the requests dispatched among the different instances to handle load increases. It also allows the microservices to be moved easily from one location to another, and it avoids data loss in case of a microservice crash. However, stateless microservice does not keep any states between requests that involve retrieving programs from a persistence storage and parsing them to get a model before processing language services, which increases response times compared to stateful microservices. This additional cost on response times must be taken into account to benefit from the reconfiguration of a distributed IDE.

The proposed generative approach ( 2 ○ in Figure 3) takes as inputs a specific configuration of the feature model and the microservices, and produces a distributed IDE integrated with the Web-based client.

Towards a modular and distributed NabLab IDE

In this section we use a running example to detail the steps introduced in the previous section. Our task is the design of a distributed IDE for Nablab users. We chose NabLab as a language for our experiments on modular and distributed IDE construction because developing NabLab software provides a wide range of requirements, from responsive editing operations of code to CPU intensive compilation and execution. Taking care of this range of requirements is best addressed by distributing language services on various types of execution platforms. NabLab users are supported by a set of tools that form a specific IDE:

• A textual editor supports contextual code completion, code folding, syntax highlighting, error detection, quick fixes, variable scoping, and type checking. • A model explorer provides a dedicated outline view and a contextual LaTeX view. • A debugging environment provides variable inspection, plot display and 2D/3D visualization. • A NabLab compiler generates efficient implementations thanks to the associated compilation chain.

Language and protocol specifications

As mentioned in the previous section, in our approach a language specification consists of defining a metamodel, a concrete syntax and semantics. We use the Eclipse Modeling The concrete syntax of NabLab is a grammar defined with Xtext [START_REF] Eysholdt | Xtext: Implement Your Language Faster than the Quick and Dirty Way[END_REF]. Taking a grammar as input, Xtext is able to generate the source code implementing a set of language services for a text editor. Xtext can also generate a language server, which embeds the language services that are then callable remotely. In our approach we use this generator to produce implementations of IDE features.

The compilation chain comes as a separate language service implemented with Xtend17 , and this service is integrated and prompted from the IDE client.

Listing 1 is an excerpt from the protocol specification for NabLab. This protocol specification conforms to the metamodel described in Figure 4. Our tool to edit a protocol textual specification and simultaneously build a protocol model is based on Xtext. As a language designer, through the protocol specification we made the choice for NabLab to define the language services as stateless services and we defined the granularity of the deployment units by declaring how the language services are grouped in the IDE features. Our NabLab protocol model declares the storage and completion features, and a dependency between their respective capabilities. The storage feature provides the following capabilities: document, to retrieve a persisted document (a program), and update, to change the contents of a program. The completion feature provides the complete capability to get content assist proposals. In the dependencies, the complete capability first retrieves a program by calling the document capability before computing the set of completion choices. The protocol specification of NabLab, in addition to the storage and completion features shown in the listing, also has the following features: workspace, which computes diagnostics for programs and indexes their content, definition, which gives the location of an element's definition, highlight, which looks up the element's definition as well as other elements linked to the same definition, hover, which returns the element's description, documentSymbol, which returns all the elements of a program, formatting, which computes text edition operations to normalize program's indentation, rename, which returns text edition operations to rename an element's definition and other elements linked to the same definition, references, which finds elements having the same definition, symbol, which returns all the symbols in the opened program matching a query, and compiler, which generates a Java source file from a NabLab file.

Feature model generation

In a second step we generate a NabLab feature model by taking the NabLab protocol specification as input. Figure 5 presents the resulting feature model built by applying the approach described in the previous section. The features of the model match the IDE features of the protocol specification and the hierarchy is derived from the dependencies between capabilities. For example, in the protocol specification symbol has a capability calling the index capability declared in workspace. We infer that symbol requires workspace to run, and we set a parent-child relationship in the feature model. It means that a configuration of this feature model containing symbol is valid only if workspace is also present. We compute similarly the hierarchy for other features.

Our implementation of the feature model generator relies on the Feature IDE framework [START_REF] Thüm | FeatureIDE: An extensible framework for feature-oriented software development[END_REF], which provides facilities to construct and manipulate feature models.

The feature model generated with this framework is then used to configure the expected deployment and ensure its validity with regards to the constraints defined in the feature model.

Microservice generation

We use the Quarkus 18 framework to implement Java microservices for each IDE feature defined in the protocol specification. A Java class is generated with methods corresponding to the Capabilities of the IDE feature. Each Capability is implemented as a REST API, by annotating methods with HTTP verbs, query parameters, and endpoint paths. These methods are callbacks for the HTTP requests. We process the Capability's JSON definition file to generate arguments and return type for the methods. We also generate proxy classes from the dependencies of the IDE features. These classes provide methods to remotely call the capabilities implemented in the other microservices.

The language service implementations of NabLab are provided by Xtext, except for the compiler. We leverage on these available implementations by providing a generative approach that reuses the Xtext generators to complete microservice implementations. The integration with an IDE client is not addressed by this work and it is up to the language designer to implement the calls to the microservices from the client. However, this can be facilitated by using an integration protocol such as the LSP that provides interoperability between client IDEs and language services.

Deployment configuration

Our distribution of the IDE features relies on Docker 19 and the container orchestrator Kubernetes20 . The microservices are packaged in Docker containers, which isolate the microservices and ease the deployment by embedding their runtime environment (e.g., a JVM). We deploy containers in a cluster by using a container orchestrator, since it allows to plan their deployment at different locations and move them at runtime. Our deployment configurator monitors the deployment using the Kubernetes API, to get the list of deployed microservices with their locations to construct the configuration representing the current deployment. We provide a frontend for the configurator as a web page that displays configurations to the language user and designer. Through this web page, the language user can change the deployment configuration by disabling microservices, selecting new ones and change their deployment location. If the new configuration is valid, a deployment plan is sent to the Kubernetes API. Although we implemented our deployment configurator with Kubernetes, other container orchestrators like Nomad21 can be used to distribute IDE features (as shown in section 5 where we manually deploy IDE features on a Nomad cluster)

Experimentations

In this section we present our experiments to answer the research questions introduced in Section 2 (RQ1 and RQ2).

We conducted these experiments on four EMF-based languages: NabLab, our own implementation of the Logo language, ThingML and MiniJava. Logo is an educational programming language dedicated to 2D drawings, ThingML is dedicated to applications for the Internet of Things, and MiniJava is a subset of the Java language. We selected this mix of general purpose and domain specific languages of distinct domains to be representative of the generalization of the proposed approach.

Our experiments compare language services implemented by monolithic servers deployed locally and modular servers distributed over the available execution platforms. Our results show that monolithic servers deployed locally (i.e., on the same execution platform than the client) offer better response times when not resource demanding but quickly limited for computationally intensive IDE features, and that parsing models and loading model elements constitute a bottleneck for microservices, which would prevent the design of an entirely stateless architecture.

Experimental setup

The evaluation was performed on three machines in a Nomad cluster. All machines were Dell PowerEdge R330 with Intel(R) Xeon(R) CPU E3-1280 v6 @ 3.90GHz 4 cores, hyper-threading and 31GB of RAM. The IDE features were deployed in Docker containers and running on OpenJDK 11.0.5.

The evaluation measured the response times of language services implemented as monolithic language servers, and as distributed language servers with microservices. Both are implementing the Language Server Protocol22 (LSP), and possibly additional services such as a compiler. Monolithic language servers were deployed on a single machine of the cluster. We generated programs of a similar number of lines of code based on the content of existing examples for each language 23 . For each program, we initialized an LSP session and opened the program. After the initialization is completed, we then called 100 times each language service in a row and compute the average of the time elapsed between the request and the reply measured from the client's point of view.

We performed the same experiments with the distributed servers after distribution of the language services over the available cluster. On the first machine we deployed the language service storage, on the second machine workspace, completion, definition, highlight, documentSymbol and on the third machine hover, references, rename, symbol. Since we wanted to measure the cost of message exchanges, we deployed depending IDE features on different machines: for instance, workspace feature was not on the same machine as references and symbol, that storage is on its own machine. The client that sends the requests to language services was deployed outside of the cluster, on a machine connected to the cluster by a local network.

In the case of the distributed servers, we also measured the times taken to load and resolve the references of models, in order to highlight the impact of load and resolve phases in the response time of the microservices. More precisely, models are graphs of objects that reference each other but these references are not resolved at the first load, they are resolved on demand when language services browse the models, which has an impact on the processing time of the language services. For each language we repeated 100 times the measure of loading and resolution time of each program.

Results

To investigate the gains and the costs of distributing language services, we first compared the response times of language services of the motivating example in Section 2, which are implemented by a monolithic server running on a laptop (client co-located on the laptop), to the response times of the same language services implemented by microservices running on the Nomad cluster (client outside of the cluster, and connected by a local network) for the NabLab language. In a second experiment, we compared the response times of language services for monolithic and distributed architectures running both on the Nomad cluster to evaluate the cost of the distribution for the languages NabLab, Logo, ThingML and MiniJava. We then measured the loading time of the programs for these four languages and compare them to the response times of language services to evaluate the impact of the stateless architecture.

Microservice-based version.

We measured the response times of microservices running on a cluster implementing the language services of the motivating example presented in Figure 2 and compare them with the response times of language services running locally on the laptop. Figure 6 presents response times of these microservices deployed in the Nomad cluster. The percentage given for each bar represents the overhead with regard to the time presented in Figure 2. Response times of the feature completion increase with file size and are several orders higher than in Figure 2, where they are between 2 and 6 milliseconds. Response times for references are 2 to 10 times higher than those in Figure 2. Feature rename takes 6% more on the 121line file, but gains between 16% and 25% for the other files. Feature compiler gains 51% on the 121-line file and gains between 9% and 21% on the other files.

Protocol.

To evaluate the cost of modularization and distribution of the language services, we measured response times on programs of increasing sizes for the languages Logo, NabLab, ThingML and MiniJava, with both monolithic and distributed servers. For the distributed architecture, we also measured the overheads from message exchanges between the microservices to fulfill the request to language services (i.e., the total time spent by a microservice waiting for responses to requests for additional inputs from other microservices that are necessary to process its internal logic). We performed 100 measurements for each language service on each program and for both servers, and computed the means. For the 320 measured means, 232 of them have a coefficient of variation (i.e., the ratio of the standard deviation to the mean) below 30%.

Figures 7,8, 9 and 10 presents a comparison of the response times of the language services for the monolithic and distributed architectures on programs of increasing size, respectively for NabLab, Logo, MiniJava and ThingML. The cumulative times resulting from the modularization and the distribution of language services are represented by the protocol overhead parts, in grey in the response times of the distributed architecture. They measure the times taken by the exchanges between the distributed microservices, which include the retrieval of programs from the storage microservice, and the retrieval of the workspace's index (only for references and symbol features). The upper parts of the bar displayed in orange represent the times not due to the exchanges between the microservices, which include the processing times In most cases, the distributed architecture introduces an overhead in comparison to the monolithic implementation. However, we observe that the overhead is marginally due to the protocol (the means for each file are between 24.63 ms and 57.64 ms for NabLab, 11.43 ms and 22.88 ms for Logo, 14.21 ms and 21.94 ms for MiniJava, 9.31 ms and 15.96 ms for ThingML), but mostly lies in the orange parts and is rather due to the stateless nature of microservices. We further explore this in the rest of this section.

Statelessness impact.

The microservices being stateless, they all require to fetch and load the necessary part of the model in addition to executing the corresponding language service(s). To evaluate the impact on response times of the stateless nature of microservices implementing language services, we measured the initial load times and the full references resolution times for the four languages NabLab, Logo, Minijava and ThingML on the same programs used before. The considered programs are EMF models, in the form of graphs of objects which are loaded lazily. An initial load is Figure 8. Comparison of response times in monolithic and distributed architectures for language services of Logo performed to build the objects of the model but references between them are resolved on demand. Language services browse models when performing their internal logic. This process requires resolving visited references, which consist of finding the referenced elements in the model, and therefore has a cost in time. This means that language services performing simple queries on a program, such as the completion feature which browses few object references, are less impacted by model loading than language services that browse the whole model, such as for instance the documentSymbol feature which collects all named elements of a model.

Figure 11 shows the means of the measurements for the four languages, on programs of increasing size. Since models are loaded lazily, we measured the initial load times and the reference resolution times. The load curve represents the times to parse programs and build the corresponding model. The resolve curve represents the times to resolve all the references between objects in the model. The load and resolve are cumulative times that correspond to the complete model loading.

In all cases we observe a linear time for load, while resolve can be exponential according to the size of the considered To further compare the load and resolution times of model with language service response times, we measured completion, which is one of the fastest of our language services and documentSymbol which is one of the most time consuming. Figure 12 shows their response times on programs of increasing size for the monolithic and distributed architectures of the four languages. The differences of response times of completion and documentSymbol between monolithic and distributed architectures go up to 355 ms and 220 ms respectively for Logo, 347 ms and 2058 ms for NabLab, 229 ms and 242 ms for MiniJava, and 110 ms and 174 ms for ThingML.

Discussion

We modularized and distributed language services in a cluster and we compared their response times with monolithic servers implementing the same features. In this section we discuss these results to answer the research questions introduced in section 2. We present in this paper a first generative approach to modularize all services of a language server in the form of deployment units as microservices, and a second generative approach in charge of establishing the communication between the various microservices corresponding to a given configuration of the expected IDE. The granularity of the IDE features in terms of the language services to be included in a given microservice, as well as the information on the possible dependencies between them, are given by a protocol specification taken as input of our overall approach. The microservices are stateless, and support custom and possibly dynamic adaptation of their configuration.

Systematic approach to automate the modularization and individual deployment of language services

We experiment our approach on four representative EMFbased languages, namely NabLab, Logo, MiniJava and ThingML, and demonstrate the ability of our approach to be applied to all of them. We generate deployment configurators for these four languages, and select language services to be deployed, distribute them on the machines of a cluster and dynamically change the deployment configuration. For all languages, the monolithic and distributed implementations of the language server are functionally equivalent.

Our evaluation shows that language services last longer in distributed architectures compared to monolithic architectures. We have identified three sources of overhead, measured in figures 7 to 12 which we discuss afterward: the modularization, the distribution, and the stateless nature of language services.

The results from Figures 7 to 10 show that the overhead due to message exchanges induced by the modularization and latencies due to the distribution (the grey parts) is only a small part of the overall overhead in the response times of the distributed features. The overhead for features rename and symbol last longer, which can be explained by the fact that these two features query the symbol index in addition to retrieving the model while the other features only send requests to retrieve the model. The most of the overall overhead comes from the orange parts, which represent the times to load models and process the language services.

The differences of response times between the monolithic architecture and the distributed architectures can be explained by the fact that the monolithic servers are stateful and the microservices are stateless. The monolithic servers load models only once at initialization and perform model validation to find errors, a process that requires traversing all elements of the model. This means that models are loaded and all their references are resolved when the internal logic of the feature is running. In the case of microservices, models are loaded at each request and references are resolved on demand while the internal logic of the feature is running. We notice in Figure 12, that the differences in response time between the monolithic and distributed curves are at least equal to the loading times of the models in Figure 11 and even close to the full resolution time of the models for NabLab. We also notice that the completion feature has less overhead than the documentSymbol feature. This difference is due to the lazy loading of the model since completion has to resolve few model object references whereas documentSymbol has to resolve all containment references of the model.

From these observations we conclude that the protocol for stateless microservices implementing IDE features introduces a small overhead corresponding to message exchanges. The differences of response times between the monolithic and distributed architectures are mostly due to the stateless nature of microservices that requires to load the model and to resolve the references lazily. 5.3.2 Distribution of the language services to improve the overall performances of the IDE (RQ2). Our generator uses the specification of a communication protocol to generate microservices communicating by HTTP requests. Each microservice is associated with an HTTP resource, which is identified by a URL address. To send a request to a resource, a Domain Name System (DNS) must translate the destination URL into an IP address. This process abstracts the actual destination address of a request. We use HTTP to convey messages to microservices that can dynamically change their location after a reconfiguration of their deployment. Since microservices are by nature isolated from each other, HTTP communication allows the microservices to be distributed over different execution platforms.

We observed from Figure 6 that there is a real benefit on the response times to distribute some computationally intensive features (e.g., compiler) on powerful machines, even if they are stateless and are not co-located with the client, while others that are less demanding in terms of resources are better deployed locally to keep the best user experience (e.g., completion and references). The size of the program considered is also important on the result (cf. rename).

We conclude that there is an important benefit in modularizing the language services, and in distributing them in a relevant way such as we can optimize the response time of each feature individually, and improve the overall user experience of the IDE. As future work, we plan to use a learning model to estimate the pros and cons of the distribution of each feature according to the communications and the available execution platforms, and then to infer automatically the best configuration for a given context.

Related work

Our approach to the distribution of an IDE involves the specification of IDE features, the generation of microservices implementing IDE features and the configuration of deployments of IDE features.

Eclipse Che [START_REF]Eclipse Che | Eclipse Next-Generation IDE for developer teams[END_REF] is an online IDE using containers to the provision of IDE features. All the IDE features for a language are embedded in a container. Eclipse Che is only configurable at the granularity of a language and doesn't allow to select the deployment location of the containers. Our configurator operates at a granularity of the IDE feature and allows to distribute them on different locations.

Monto [START_REF] Keidel | The IDE Portability Problem and Its Solution in Monto[END_REF] is an approach to decouple IDE from IDE features. The authors manually implemented IDE features as microservices and specified IDE agnostics intermediate representations (IR) for four IDE features to communicate with them. Our approach is to generate microservices from specifications. Monto does not cover the concern of IDE configuration.

DISTIL [START_REF] Carrascal-Manzanares | Building MDE cloud services with DISTIL[END_REF] is a DSL to describe cloud-based Model-Driven Engineering (MDE) services (e.g., model transformation, model queries, ...) that are close to what we call IDE features. This DSL allows to generate persistence service, REST services and HTML front-end. MDE service descriptions can declare input and output and a validator checks correctness of connected inputs and outputs based on their types. DISTIL allows to describe the data structure of elements stored in the persistence service. Our approach does not provide a generator for the front-end and we do not generate persistence service. Our approach allows to specify dependencies of IDE features and provide a feature model to ensure a safe configuration.

Jolie [START_REF] Guidi | Microservices: a Language-based Approach[END_REF] is a programming language to implement microservices and specify microservice architectures. It provides abstractions for microservices coordination to be used in implementations. We provide a language to describe the dependencies between language services, and based on such descriptions, we automatically generate for each microservice the source code needed to call the dependencies. However, we rely on the language designer to complete microservice implementations by calling the dependencies in the right order. Our language could benefit from such coordination abstractions to go further in the automatic generation of microservices.

MicroBuilder [START_REF] Terzic | Development and evaluation of Mi-croBuilder: a Model-Driven tool for the specification of REST Microservice Software Architectures[END_REF] is an approach to generate microservices with REST API from a specification of a microservice architecture. Their specification uses REST concepts, such as HTTP verbs and does not describe dependencies between microservices. Our specification uses a domain specific model to define such information to not be tied to one technology. The description of dependencies between IDE features allows us to generate source code to call other microservices.

In [START_REF] Düllmann | Model-Driven Generation of Microservice Architectures for Benchmarking Performance and Resilience Engineering Approaches[END_REF], authors propose a metamodel to specify microservice architectures to generate synthetic microservices for benchmarking. Their metamodel allows specifying microservices with REST API and their dependencies, which is close to our protocol metamodel, and allows specifying deployment configuration composed of instances of the microservices. Our approach does not allow to describe microservice instances, as we let the cluster manage their replication automatically.

In [START_REF] Tato | ShareLatex on the Edge: Evaluation of the Hybrid Core/Edge Deployment of a Microservices-Based Application[END_REF], authors report experience on manually splitting Sharelatex (a web editor for Latex documents) into microservices, using a hybrid core/edge deployment of this application. They identified criteria to split the state of microservices for replication and criteria to decide on the deployment location of the microservices. Our approach does not address the concern of microservice replication and we do not describe deployment location criteria for IDE features, but we provide a method to automatically generate microservices and support reconfiguration of their deployment.

Our approach proposes an end to end solution, from a language specification to the IDE deployment, to configure and distribute IDEs by automatically generate microservices for IDE features and a configurator for their individual deployment. Our experiments demonstrate the benefits of such an individual deployment.

Conclusion and Perspectives

This paper discusses the modularization of language services to support their individual deployment and dynamic adaptation within an IDE. We propose a generative approach to automatically obtain microservices implementing IDE features from a language specification, complemented with a feature model that drives the safe configuration and automate the deployment of IDE features. We study the impact on performances when distributing the language services across the available execution platforms. We evaluate our approach on four EMF-based languages and demonstrate the benefit of a custom distribution of the various language services. Our experiments highlight the usefulness of distributing computationally intensive language services. Indeed, the use of distant application servers improves the performances of some language services (e.g., rename and compile), thereby compensating the overhead due to the distribution. Experiments also show the benefits of retaining locally other features that should be reactive and less demanding in resources.

These experiments highlight three important research locks that we identify as directions to be investigated by the community. Firstly, the load of models implied by stateless microservices is costly. Hence, choosing its location and proposing effective caching or replication techniques decided on the basis of the information contained in the language specification is an area to be explored, especially when we integrate collaborative editing scenarios. These scenarios were outside the scope of this paper. Stateless microservices open the possibility to share sets of load-balanced instances of language services between language users. It could be interesting to study the scalability and the resource consumption of stateless microservices and compare it with a monolithic architecture in a multi-users scenario. We demonstrated in this paper it exists a trade-off between stateless and stateful language services but further investigations are needed to determine which nature is better for each language service.

Secondly, the availability of the WebAssembly 24 technology creates a new technical environment that facilitates the development of modules that can run both on the client side and on the server side in an efficient manner. Reflecting on the granularity of these services and the technology stack that allows one to embrace as many programming languages as possible in designing these services while allowing both client-side and server-side execution remains a great challenge.

Finally, the construction of the adaptation logic adapted to the IDE operation to improve the user experience and follow the evolution of its needs by automatically migrating or reconfiguring a service is still a widely open research field.

These three locks will require further investigation to characterize language services. For example, studying their frequency of use and how they access the model will help determine whether they should be stateless or stateful and whether it is better to query part of the model on demand rather than obtaining all of it. Studying their memory or CPU needs will help determine the best deployment. The application of static analysis techniques on the source code of monolithic software implementing language services is another direction that could be explored to automatically extract protocol specifications and determine which service can be asynchronous.

If these three challenges are widely addressed by distributed computing communities, web engineering communities or adaptive systems communities, the specific case of IDEs brings a certain amount of information that allows specific reflections on each of these topics.

Figure 1 .

 1 Figure1. Current IDE Architecture, including a languageagnostic client that provides the user interface, and a language-specific server that provides all the language services for a given language

Figure 2 .

 2 Figure 2. Response times of four NabLab services (client and server deployed on the same local development laptop)

Figure 3 .

 3 Figure 3. Approach overview, with the two main steps: 1 ○ IDE microservicesation and 2 ○ IDE deployment

Figure 4 .

 4 Figure 4. The metamodel used to describe a protocol for IDE features

Listing 1 .

 1 P r o t o c o l { mandatory f e a t u r e s t o r a g e { c a p a b i l i t i e s : document u p d a t e } f e a t u r e c o m p l e t i o n { c a p a b i l i t i e s : c o m p l e t e } ( . . . ) dependencies { c o m p l e t i o n . c o m p l e t e -> s t o r a g e . document ( . . . ) } } Excerpt of the protocol specification for the completion feature of NabLab Framework 16 (EMF) and its ecosystem to define our language specification.

Figure 5 .

 5 Figure 5. Feature model of the language NabLab

Figure 6 .

 6 Figure 6. Response times of language services of the motivating example deployed as microservices in the Nomad cluster, and comparison with the response times from Figure 2.

Figure 7 .

 7 Figure 7. Comparison of response times in monolithic and distributed architectures for language services of NabLab

Figure 9 .

 9 Figure 9. Comparison of response times in monolithic and distributed architectures for language services of MiniJava

Figure 10 .Figure 11 .

 1011 Figure 10. Comparison of response times in monolithic and distributed architectures for language services of ThingML

Figure 12 .

 12 Figure 12. Comparison of services browsing few model references (completion) and many model references (doc-umentSymbol) for the languages Logo, NabLab, MiniJava and ThingML in the monolithic and the distributed architectures

Microservices Feature Model IDE Microservicesation IDE Deployment Storage ✔Completion

  It essentially describes what the feature

									Language user
									/ designer	Application Server #1
											Application Server #2
									IDE & Deployment Configuration
										Development Laptop	Compiler	References
									✔Compiler	Application Server #1
									Interpreter
									✔Rename	Development Laptop
	Protocol Specification		Completion	References			IDE	✔Workspace ✔Storage	Application Server #2 MyCloud	Workspace
	Language Designer	1	Compiler	Workspace Rename Interpreter	Runtime Completion	Rename	Workspace	…	2	Internet) (local or over JSON-RPC
	Specification Language		Storage	…	Compiler	Interpreter	References		MyCloud
											Storage
											Development Laptop
											Completion
											Rename

https://github.com/cea-hpc/NabLab

https://github.com/fcoulon/sle2020-dev/tree/master/logo/logo.xtext.parent

https://github.com/tetrabox/minijava

https://github.com/TelluIoT/ThingML

https://www.jsonrpc.org/

https://www.eclipse.org/ecoretools

https://www.eclipse.org/Xtext

https://www.eclipse.org/sirius

https://www.eclipse.org/modeling/emf/

https://www.eclipse.org/xtend/

https://www.docker.com/

https://kubernetes.io/

https://www.nomadproject.io/

https://microsoft.github.io/language-server-protocol/

https://anonymous.4open.science/r/e03961ac-9f27-4c52-ab28-87cf105a83f4/


Sami Mekki

Jean-Luc Danger
email: danger@enst.fr

Benoit Miscopein

Joseph J Boutros
email: boutros@tamu.edu

EM Channel Estimation in a Low-cost UWB Receiver based on Energy Detection

The Expectation-Maximization (EM) algorithm is studied to perform channel estimation in a low cost and high data rate impulse radio UWB receiver. The system under consideration uses a pulse position modulation with a simple analog energy detector. In order to overcome the problems inherent to high data rates, such as inter-symbol interferences, a probabilistic equalizer is used. The EM algorithm and the equalizer are embedded into the loop of an iterative channel decoder. This permits to refine both the channel parameters and the signal probability at each iteration. We present numerical results performed on the channel models from the IEEE 802.15.3a task group. These results show that the EM algorithm contributes to achieve data rate greater than 100Mb/s with a simple impulse radio UWB receiver.

I. I

The future of ultra-wideband (UWB) system is bound to the system cost at both the receiver and transmitter side. For instance, a low cost communication system could simplify the deployment of sensor or ad-hoc networks. The cheapest electronic architectures are achieved with impulse radio (IR) transmissions [START_REF] Win | Impulse radio: how it works[END_REF] whereas high data rates take advantage from OFDM [START_REF]Multiband ofdm physical layer proposal for ieee[END_REF] or Direct Sequence modulation schemes [START_REF] Fisher | Ds-uwb physical layer submission to 802.15 task group 3a[END_REF]. Among the architectures in IR UWB, the energy detector (ED) based on a simple schottky diode and a capacitor is by far the less complex. The other alternative is the transmitted reference (TR) receiver [START_REF] Choi | Performance of ultra-wideband communications with suboptimal receivers in multipath channels[END_REF], [START_REF] D'amico | Energy-detection uwb receivers with multiple energy measurements[END_REF] or coherent detector using a Rake receiver [START_REF] Cassioli | Low complexity rake receivers in ultra-wideband channels[END_REF], [START_REF] Molisch | A low-cost time-hopping impulse radio system for high data rate transmission[END_REF]. With regards to the ED receiver these electronic architectures are more complex with the necessity of analog delay lines and/or frequency mixers.

The increase of data rate in IR UWB transmission is directly dependent on the equalization process quality in a dispersive multipath channel as defined in [START_REF] Foerster | Channel modeling sub-committee report final[END_REF]. We consider the basic IR receiver based on a low-cost ED analog front-end and a digital processor in charge of the baseband processing. The modulation is a non-linear M-ary pulse position modulation (M-PPM) which, at high data rate, is impaired with intersymbol interference (ISI) in high dispersive communication channels as those defined in [START_REF] Foerster | Channel modeling sub-committee report final[END_REF].

To fight these impairments a new method of equalization based on a probabilistic equalizer is defined in [START_REF] Mekki | Probabilistic equalizer for ultra-wideband energy detection[END_REF]. However, this approach needs realistic channel parameters. The expectation-maximization (EM) algorithm [START_REF] Dempster | Maximum likelihood from incomplete data via the em algorithm[END_REF] provides a numerical method for obtaining maximum likelihood of estimates that might not be available otherwise. Previous research for joint channel parameter estimation and symbol detection have been developed in [START_REF] Kaleh | Joint parameter estimation and symbol detection for linear or nonlinear unknown channels[END_REF], [START_REF] Stoica | Parameter estimation with missing data via equalization-maximization[END_REF]. In [START_REF] Perry | Em algorithms for sequence estimation over random isi channels[END_REF], the EM algorithm has been investigated over random ISI channels.

In this work, we present an new method for joint channel parameters estimation and energy equalization via the EM algorithm applied to IR UWB with ED. The derived algorithm is inserted into the channel decoder loop to benefit from the iterative capacity of the decoder.

A training sequence is first exploited to get an initial estimate of the channel, then the equalizer is performed and feeds the channel decoder which in turn gives updated probabilities to the EM estimator. This loop is illustrated by a simplified schematic in Figure 1. This work is organized as follow: In Section II, the system model and energy distribution are specified. The considered probabilistic equalizer is described in III. Section IV presents the EM algorithm adapted to the energy detection. In section V, simulation results are presented for different interference levels and compared to the perfect channel state information (CSI) condition. Finally, a conclusion of this study is summarized in Section VI.

II. S M

We consider a pulse-based UWB transmission of a sequence of independent symbols c = (c 1 , c 2 , . . . , c N ) over an additive white Gaussian noise (AWGN). We assume that the sequence c is a codeword of channel code C .

As depicted in Figure 2, the encoded data is mapped into channel symbols suitable for modulation. We adopt an M-PPM modulation with M slots per symbol c n . Thus, inter-symbol and inter-slot interferences are unavoidable at high data rate transmission in a dispersive channel. The designed receiver assumes that the number of interfered symbols is K, that is equivalent to P = (K -1)M + 1 interfered slots. So, the signal at the output of the filter can be written as follows:

s n (t) = K-1 k=0 x n-k (t) (1)
where x n-k (t) is the channel response of (n -k) th transmitted symbol defined by

x n-k (t) = p n-k (t) ⊗ h(t) (2)
where ⊗ denotes the convolution product, h(t) is the impulse response of the channel and reasoning.

p n-k (t) = p(t -A n-k T slot )
The detected energy at slot position m for n th symbol has the following expression

E n,m = nTs+(m)T slot nTs+(m-1)T slot (s n (t) + z n (t)) 2 dt ( 3
)
where T s = MT slot is the symbol duration and z n (t) is an additive white Gaussian noise, with mean zero and variance σ 2 . This energy can be approximated, for a process which has a bandwidth W, by a set of 2T slot W sample [START_REF] Urkowitz | Energy detection of unknown deterministic signals[END_REF] as follows

E n,m = 2L =1 (s n,m + z n,m ) 2 (4)
where 2L = 2T slot W is the number of freedom degrees over the interval T slot , and s n,m and z n,m are respectively the th sample of s n (t) and z n (t) in m th slot of n th symbol. According to the received energy at each slot, the detector computes the probability of getting it. As it is showed in [START_REF] Mekki | Probabilistic equalizer for ultra-wideband energy detection[END_REF], the energy E n,m follows a non-central chi-square (χ 2 ) distribution with 2L degrees of freedom if B n,m = 2L =1 (s n,m ) 2 0; i.e. B is called the non-centrality parameter; defined by

p(E n,m |B n,m ) = 1 2σ 2 E n,m B n,m L-1 2 e - (En,m+Bn,m ) 2σ 2 I L-1        B n,m E n,m σ 2        (5)
where I L-1 (u) is the (L-1) th -order modified Bessel function of the first kind [START_REF] Abramowitz | Handbook of Mathematical Functions with Formulas, Graphs,and Mathematical Tables[END_REF]. The energy

E n,m follows a central chi-square distribution with 2L degrees of freedom if B n,m = 2L =1 (s n,m ) 2 = 0, defined by p(E n,m |0) = 1 σ 2L 2 L Γ(L) (E n,m ) L-1 exp -E n,m 2σ 2 (6)
where Γ(z) is the gamma function [START_REF] Abramowitz | Handbook of Mathematical Functions with Formulas, Graphs,and Mathematical Tables[END_REF].

III. E E

In order to overcome the different types of interferences due to high data rate, it is necessary to integrate an equalizer. The selected equalizer that matches our receiver is described in [START_REF] Mekki | Probabilistic equalizer for ultra-wideband energy detection[END_REF]. Equalization is performed according to the slot energy distribution computed by the detector. Then, the receiver computes the probability density function p(E n |x n ) to get the transmitted symbol x n , this probability is given by

p(E n |x n ) = x n-1 ,...,x n-K+1        M m=1 p(E n,m |B n,m ) K-1 k=1 p(x n-k )        (7)
where

p(E n,m |B n,m ) = p(E n,m |s n,m
) defined in section II. The interested reader should refer to [START_REF] Mekki | Probabilistic equalizer for ultra-wideband energy detection[END_REF] for details on the proof of [START_REF] D'amico | Energy-detection uwb receivers with multiple energy measurements[END_REF]. The parameter B n,m defines the energy in slot m for the symbol n if the noise is null. Let B represents the set of all possible value that B n,m can take. At the receiver side, if we consider that the number on interfered symbols does not exceed K, the cardinal of B is finite. In Table I We notice that |B| grows approximately in O(M K ). In the sequel, B j refers to an element of B = {B j }.

IV. EM    

A. EM algorithm overview

As we noticed in the previous section some specific channel parameters must be computed to perform the equalizer. To estimate the (CSI), the EM algorithm [START_REF] Boutros | A tutorial on iterative probabilistic decoding and channel estimation: Graph representation, information flow and probabilistic algorithm in decoding and communication[END_REF], [START_REF] Dempster | Maximum likelihood from incomplete data via the em algorithm[END_REF] is a good candidate. It allows to build a probabilistic equalizer which could be used to feed the decoder in the iterative decoding loop. The EM algorithm is applied to find the maximum likelihood log p(x,y|θ) and it is especially effective when the likelihood of the incomplete data is much more difficult to maximize than the likelihood of the complete data. We denote by incomplete data the received vector y, by missing data the transmitted vector x, by complete data the couple (x, y) and by θ the parameter to be estimated. θ is the channel parameter in our case. The EM algorithm starts from an initial value of θ 0 and it improves this value iteratively. This algorithm proceeds in two steps at each iteration: the first one consists of the expectation step (E-step), and the second one consists of the maximization step (M-step). Given a current parameter value θ i at iteration i, the EM algorithm computes an update θ i+1 . The final EM estimate depends on the initial value θ 0 . In each iteration, the likelihood increases monotonously.

To summarize:

1) Start with θ 0 2) Repeat the following two steps for each iteration i (i=1,2,. . . ), a) E-step: compute the expectation value of log-likelihood of complete data conditioned by observed samples and the current solution of θ i :

Q(θ|θ i ) = E x [log p(x, y|θ)|y, θ i ] (8)
b) M-step: find θ i+1 that maximize the auxiliary function Q(θ|θ i ),

θ i+1 = arg max θ Q(θ|θ i ) (9)
In the case of unknown source distribution and by the means of Bayes' rule and considering that x and θ are independent, we get

p(x, y|θ) = p(y|x, θ)p(x|θ) = p(y|x, θ)p(x) ∝ p(y|x, θ) (10)
then the new auxiliary function (8) expression is

Q(θ|θ i ) = E x [log p(y|x, θ)|y, θ i ] = x log p(y|x, θ)P(x|y, θ i ) = x log p(y|x, θ)APP i (x) (11)
where APP i (x) = P(x|y, θ i ) is the a posteriori probability of x at the i th iteration of the EM algorithm.

B. EM application to energy detection

As described in section II, the incomplete data is the vector of energy E = (E 1 , E 2 , . . . , E N ) where E n is the energy per symbol that is equal to (E n,1 , E n,2 , . . . , E n,M ). The missing data is the vector of transmitted symbols x = (x 1 , x 2 , . . . , x N ) and the parameter to be estimated which characterize the channel is θ = (B, σ 2 ), with B = {B j }. Then, the auxiliary function in energy domain is given by

Q(θ|θ i ) = x log p(E|x, θ) APP i (x) (12)
Equation ( 12) can be decomposed into a product of probabilities by expending the conditioned probability p(E|x, θ) as follows

p(E|x, θ) = p(E 1 , . . . , E N |x 1 , . . . , x n , θ) (13)
since the collected energy per symbol is independent from one symbol to another and it depends only on the interfering symbols, one can write

p(E|x, θ) = N n=1 p(E n |x n-K+1 , . . . , x n-1 , x n , θ) = N n=1 p(E n |B n , θ i ) ( 14
)
the last equation comes from the unicity of the resultant energy for a given interfering symbols, i.e. (x n-K+1 , . . . , x n ) is equivalent to

B n = (B n,1 , . . . , B n,M
). Moreover, the received energy per slot E n,m , that forms E n , depends on B n only throw B n,m . Thus, equation ( 14) becomes

p(E|x, θ) = N n=1 M m=1 p(E n,m |B n,m , θ) (15)
Applying ( 5) and ( 15) into ( 12), leads to the following auxiliary function

Q(θ|θ i ) = x N n=1 M m=1 log p(E n,m |B n,m , θ)APP(x) (16)
= x N n=1 M m=1 log 1 2σ 2 + L -1 2 log E n,m - L -1 2 log B n,m - E n,m + B n,m 2σ 2 + log I L-1        B n,m E n,m σ 2        APP i (x) (17)
It is noted that the missing data {B n,m } is also the estimated parameter. So to get rid of the parameter x in [START_REF] Spruill | Computation of the maximum likelihood estimate of a noncentrality parameter[END_REF], it is necessary to rewrite APP i (x) according to {B n,m }, we use the following approximation which has a negligible degradation on EM performance and a very low evaluation complexity [START_REF] Boutros | A tutorial on iterative probabilistic decoding and channel estimation: Graph representation, information flow and probabilistic algorithm in decoding and communication[END_REF], the a posteriori probability is conditioned on the received energy E, since it is the only information available at the receiver: 17) and deriving it with respect to θ. The derivative in terms of B j of equation ( 23) is given by

x B n,m APP i (x) = x B n,m P(x|E, θ i ) (18) = x 1 ,...,
∂ ∂B j Bn,m B n,m P(B n,m |E, θ i ) = P(B n,m = B j |E, θ i ) ( 24
)
where P(B n,m = B j |E, θ i ) is the probability to get B j in slot m for symbol n. With no loss of generality and for notation simplicity, p i (B n,m = B j ) stands for P(B n,m = B j |E, θ i ). Using (24) to drive [START_REF] Spruill | Computation of the maximum likelihood estimate of a noncentrality parameter[END_REF] according to B j , it yields to

∂Q(θ|θ i ) ∂B j = N n=1 M m=1 - 1 2σ 2 p i (B n,m = B j ) + E n,m 2σ 2 B j I L √ B j En,m σ 2 I L-1 √ B j En,m σ 2 p i (B n,m = B j ) (25)
Solving ∂Q(θ|θ i )

∂B j = 0 with respect to B j , it leads to:

B j N n=1 M m=1 p i (B n,m = B j ) = N n=1 M m=1 E n,m I L √ B j En,m σ 2 I L-1 √ B j En,m σ 2 p i (B n,m = B j ) (26)
Equation ( 26) has no explicit solution. Some researches looked for an approximation of the non-centrality parameter of a chi-squared distribution [START_REF] Lisnanski | Low complexity generalized em algorithm for blind channel estimation and data detection in optical communication systems[END_REF], [START_REF] Saxena | Estimation of the non-centrality parameter of a chi squared distribution[END_REF], [START_REF] Spruill | Computation of the maximum likelihood estimate of a noncentrality parameter[END_REF]. We investigated a new approximation of the non-centrality parameter that has better results than those presented in the literature defined by

B (i+1) j ≈                      N n=1 M m=1 f (E n,m , 2Lσ 2 (i) ) p i (B n,m = B (i) j ) N n=1 M m=1 p i (B n,m = B (i) j )                      2 ( 27
)
where B (i+1) j is the value of B j at (i + 1) th iteration and

f (E n,m , 2Lσ 2 (i) ) =        E n,m -2Lσ 2 (i) if E n,m > 2Lσ 2 (i) 0 if E n,m < 2Lσ 2 (i) ( 28
)
where σ 2 (i) is the updated of the noise variance at the i th iteration of the EM algorithm. We have not been able to show why ( 27) is a good approximation, but we conjecture it to be true.

To obtain the update parameter for σ 2 we proceed as for B j . So, we derive the auxiliary function with respect to σ 2 and forcing the derivative to zero. After considering the approximation (23), we get the expression (29):

N n=1 M m=1 Bn,m E n,m + B n,m 2σ 2 -L P(B n,m |E, θ i ) = N n=1 M m=1 Bn,m B n,m E n,m σ 2 I L E n,m I L-1 √ B j En,m σ 2 P(B n,m |E, θ i ) (29)
where Bn,m is the summation over all the possible value that B n,m could take, so it can be replaced by the sum over B j ∈ B multiplied by the probability that in slot m of the n th symbol we get B j at the i th iteration of the EM algorithm. Such probability is defined previously by p i (B n,m = B j ). Equation (29) becomes then

B j N n=1 M m=1 E n,m + B j 2σ 2 -L p i (B n,m = B j ) = B j B j σ 2 N n=1 M m=1 E n,m I L E n,m I L-1 √ B j En,m σ 2 p i (B n,m = B j ) (30)
The update parameter of σ 2 at (i + 1) th iteration is obtained by applying (26) into the right hand side of (30), that gives

σ 2 (i+1) = 1 2LMN N n=1 M m=1 B (i) j (E n,m -B (i) j )p i (B n,m = B (i) j ) (31)
It should be noticed that M m=1

B j p i (B n,m = B j ) = M. V. S R
The simulations are computed with a bit interleaved coded modulation (BICM) [START_REF] Caire | Bit-iterleaved coded modulation[END_REF] and a data rate of 100 Mb/s. A convolutional channel encoder at rate 1/2 with octal generator (23, 35) followed by a pseudo-random bit-inter-leaver is implemented. A 4-PPM modulation is assumed. The frame has a length of 1024 bits and the SISO decoder computes 10 iterations. We consider two hypothesis. The first one, a perfect CSI is considered: only the equalizer is implemented and the different channel parameters are given to the receiver. We simulate for different values of K which is the number of intersymbol interferences which are processed, but not the true number which could be greater. That means that if K is low, the receiver is both less complex and less effective.

In second case, the channel parameters are estimated by the mean of the EM algorithm which is combined to the SISO decoder. Only one iteration of the EM algorithm is computed per decoder iteration, so we perform a total of 10 EM iterations, since the decoder computes 10 iterations.

A. Perfect CSI condition

Perfect CSI is assumed. Figure 3 shows the BER for considered value of K = 2. The performances of the receiver can be improved in high dispersive channel; such as CM3 and CM4; if the receiver increases the value of K as shown in Figure 4 and Figure 5 for K = 3 and K = 4 respectively. In fact, the maximum excess delays for CM1, CM2, CM3 and CM4 are respectively around 50ns, 80ns, 140ns and 200ns, according to [START_REF] Foerster | Channel modeling sub-committee report final[END_REF]. So with a 4-PPM modulation at 100Mb/s; i.e. the symbol duration T s = 20ns; the real number of interfered symbols for each channel model are approximately 3, 4, 7 and 10 for CM1, CM2, CM3 and CM4 respectively.

Results with K = 4 show no BER improvement. It is then preferable to stay at K = 3 because the number of energy coefficients B n,m to calculate is smaller, as shown in Table I.

B. Channel estimation consideration

The EM algorithm is used and initialized by a set of training sequences. In our simulation, only 20 symbols are used as a training sequence, especially chosen to get the maximum of possible interferences. Simulations with K = 2 and 3 are depicted in Figure 6 and Figure 7 respectively. Results with K = 4, being very similar to those with K = 3, are not shown in this paper.

The performance is very close to that obtained in a perfect CSI receiver. We remark that the performance of the receiver when K = 2; Figure 6; is better than that obtained with the perfect CSI receiver; Figure 3. This can be explained by the receiver assumption that time excess delay of the channel does not exceed (K -1)T s + T slot ; i.e. not more than K = 2 interfering symbols; but in reality, the excess delay of the channel is much longer than that. With the EM algorithm, the number of estimated energy coefficients is still 15 but the coefficients are corrected if the channel has more than 2 intersymbol interferences. We noticed that it is not necessary to increase the complexity of the receiver with a greater value of K when the data rate is 100 Mb/s, even if the channels are highly dispersive (case of CM3 and CM4).

VI. C

The EM algorithm has been studied to estimate the channel parameters of an M-PPM UWB communication. The parameters are composed of the noise signal and energy coefficients corresponding to K inter-symbol interferences caused by high data-rate communications in dispersive channels. The channel estimation is used iteratively and jointly with a probabilistic equalization and a channel decoder. At 100 Mbits/s the EM is capable of a good estimation of parameters since the results are close to the perfect CSI implementation of the probabilistic equalizer. Moreover, the value of K can be low even if the real value is greater for highly dispersive channels like CM1 and CM2. Further simulations have to be carried out at higher bit rates to study the exact value of K for different communication speeds. Future works will also include the complexity refinement, as for instance the reduction of the energy coefficients to optimize the digital processing cost.

R

Fig. 1 .

 1 Fig. 1. Simplified receiver architecture.

Fig. 2 .

 2 Fig. 2. Transmitter and receiver design.

Fig. 3 .

 3 Fig. 3. BER for different channel models using BICM(23,35) at rate 1/2 with K = 2 in perfect CSI.

Fig. 4 .

 4 Fig. 4. BER for different channel models using BICM(23,35) at rate 1/2 with K = 3 in perfect CSI.

Fig. 5 .

 5 Fig. 5. BER for different channel models using BICM(23,35) at rate 1/2 with K = 4 in perfect CSI.

Fig. 6 .

 6 Fig. 6. BER for different channel models using BICM(23,35) at rate 1/2 with K = 2 in non perfect CSI.

Fig. 7 .

 7 Fig. 7. BER for different channel models using BICM(23,35) at rate 1/2 with K = 3 in non perfect CSI.

TABLE I R

 I        K  |B| 

		 4-PPM
	K 2	P 5	|B| 15
	3	9	88
	4	13	424

  , so the sum over x n-K+1 , . . . , x n can be replaced by the sum over the possible value that B n can take. It yields to

				Bn	B n,m P(B n |E, θ i ) (21)
				Proceeding as for equation (20), we get
				Bn,m	B n,m P(B n,m |E, θ i )	(23)
				where B n,m ∈ B. The updated parameters are obtained by applying (23) into (
		x N	B n,m P(x 1 , . . . , x N |E, θ i )	(19)
	=	n-K+1,...,xn	B n,m P(x n-K+1 , . . . , x n |E, θ i )
				(20)

Equation

[START_REF] Win | Impulse radio: how it works[END_REF]

comes from the fact that B n,m depends only on K interfering symbols in the n th symbol position. For each value of the interfering symbols set (x n-K+1 , . . . , x n ), we get a unique vector of B n x B n,m P(x n-K+1 , . . . , x n |E, θ i ) = Bn B n,m P(B n |E, θ i ) = Bn B n,m P(B n,1 , . . . , B n,M |E, θ i ) (22) =


Cristian Maiorano
email: cristian.maiorano@ansaldo-sts.fr

Emanuele Pascale
email: emanuele.pascale@ansaldo-sts.com

Fred Shenkelberg

Laurent Bouillaut
email: laurent.bouillaut@ifsttar.fr

Paolo Sannino
email: paolo.sannino@ansaldo-sts.com

Yusmery Solorzano
email: yusmery.solorzano@ansaldo-sts.com

Stanislao Borriello
email: stanislao.borriello@ansaldo-sts.com

Pietro Marmo
email: pietro.marmo@ansaldo-sts.com

MTBF (Metric That Betrays Folk)

Keywords: MTBF, Reliability, Engineering, Railway, RAM, Safety, Weibull

à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

The role of reliability in railway industry

Railway signalling domain deals with the development and deployment of equipment used to increase the efficiency of operations for both mass transit and high-speed lines. Governments, local communities and rail operators have growingly focused on solutions allowing connecting points of the same city, region or state in efficiency growing ways. Trains, tracks and stations have been filled with electronic based equipment allowing the automation of tasks previously performed by human operators. Consequently, the need of efficiency has constantly increased over the time. It is clear that the concept of "reliability" is essential within this perspective. European standards (CENELEC) taken as reference for railway signalling equipment encompass reliability concept. All the bids and contracts devote paragraphs to ensure the technical solution respects the highest reliability. However, how this concept is formulated? What are the figures to demonstrate this requirement is met? Despite CENELEC standards, such the latest EN50129:2018, provide clear indications about the need of reliability requirements to be met, they adopt reliability data handbooks that in several cases are built on strong assumptions: one of them is the constant failure rate over the time, and on the abuse of MTBF.

What the MTBF is?

The term MTBF stands for Mean Time Between Failures or, Mean operating Time Between

Failures. Within maintenance management, it is the most important KPI after Physical Availability. Unlike MTTF (Mean Time To Failure), which relates directly to available equipment time, MTBF also adds up the time spent inside a repair. That is, it starts its count from a certain failure and only stops its counter when this fault was remedied, started and repeated itself again. MTBF can only be used for nonrepairable equipment and for repairable equipment where at each repair an as-good-asnew situation is restored. The MTBF in the Fig. 1, is obtained by adding the times T1 and T2 and dividing by two. That is, the average of all times between one failure and another and its return is calculated. It is, therefore, a simple arithmetical calculation.

Generally, this indicator is associated with the reliability of assets or asset systems. In general, the higher the MTBF the better, or fewer times of breaks and repairs over the analysed period - (Shenkelberg F (2018)).

MTBF-Reliability relationship

Reliability is defined as the ability to perform as required, without failure, for a given time interval, under given conditions. MTBF is defined by the arithmetic mean value of the reliability function R(t):

𝑀𝑇𝐵𝐹 𝑅 𝑡 𝑑𝑡 𝑡 𝑓 𝑡 𝑑𝑡 # 1

A constant (time independent) failure rate λ is often considered for products. Assuming that the item is as-good-as-new after each repair, successive failure-free times are then independent random variables, exponentially distributed (R(t) = e -λt ) with the same parameter λ, and with mean MTBF = 1 / λ.

MTBF: Reasons of Success

The reason behind MTBF success is quickly explained: the constant failure rate assumption makes the conversion failure rate vs MTBF too convenient for daily use. The acronym increases its appeal. Though it is less common, MTBF is sometimes referred to as a failure free time. The illusion of quantifying with a single parameter such important information is quite irresistible.

The Constant Failure Rate Hypothesis

As mentioned before, the constant failure rate hypothesis is often used.

The reasons behind this choice are multiple:  products operate during their useful life period;  electronic equipment do not wear-out;  preventive replacement is performed when necessary so that failure rate stays constant;  etc. Reliability handbooks, guidelines and standards are often behind this ambiguous assumption.

US DoD-MIL-217 handbook is often recognized as the father of electronics reliability prediction. According to many, it is not applicable anymore, as it doesn't take into account the improvement made by modern electronic components. Further, it doesn't consider environmental constraints which have been demonstrated to influence reliability performance. The result is inaccurate (often pessimistic) evaluation of components reliability. Modern standards claim to have solved this issue. However, the wrong constant failure rate assumption is still present in modern reliability handbooks.

Let's consider one of the latest reliability handbooks: the IEC TR 62380. It has recently been superseded by IEC 61709 v3. However they are based on similar components reliability models.

The above mentioned handbook makes use of the constant failure rate assumption: "Failure rates are assumed to be constant either for an unlimited period of operation (general case) or for limited periods: in these particular cases the laws governing failure rates versus time have not been adopted in the interests of simplicity. Apart from a few exceptions, the wear-out period is never reached by electronic components.

[…]NOTE: As before, and in the interests of simplicity, this handbook does not give the wearout failure mathematical model (for which the failure rate increases over time), but a period during which the rate can be considered constant (in some cases the period at 10% of the cumulative failure rate).

That is, only for some components showing wear-out phenomena after a certain amount of time, the life expectancy calculation model is provided. If we stay within the specified lifetime range, failure-rate can be considered constant. Limited life expectancy components are: Power transistors (for cyclic operation applications) Opto-couplers, electromechanical relays, capacitors, light emitting diodes, laser diodes, non-solid electrolyte capacitors, several relay types, switches and connectors.

Therefore, for all the remaining components we would expect a constant failure rate along their whole life.

Most Common Errors about MTBF

Among the improper uses of MTBF, following listed are the most common errors to be avoided:

(i)
Constant failure rate assumption during the whole life duration of an item is rarely applicable. MTBF use should be limited to those few cases. MTBF solely value doesn't provide any information about an item's reliability. Field failure data can be hardly described by MTBF; (ii) MTBF is not a duration and doesn't represent the time an item will operate without failures; (iii) MTBF is not the same as the life expectancy of an item.

Constant Failure Rate

In a recent study, the failure model of a railway signalling application product has been investigated in order to identify the best preventive maintenance policy aimed to reduce asset life cycle cost.

Failure data from infrastructure manager and repair warehouse have been collected, filtered and analysed.

The concerned product is an old designed piece of equipment. The rude circuitry is mainly made up by passive components, with, according to the above mentioned standard, constant failure rate within unlimited period of operation. We would therefore expect its failure rate to be constant over time and no wear-out signs to be found.

Cumulated failures and TTF information have been reported on a Weibull chart. A rough graphic approach quickly helps understanding that the form (beta) factor is far from assuming '1' value. Consequently, the hypothesis of constant failure rate, proper of exponential distribution, can't be retained. Despite of this, field data is often analysed as this hypothesis is true.

Let's consider another real case application where an electronic board used in railway signalling application failure data along almost 10 years is analysed. Fig. 3 shows failures over time for the above-mentioned board. A visual analysis reveals how the failure distribution is far from being uniform. MTBF value alone doesn't provide any information about products reliability over time.

Failure free time

MTBF metric is mostly used under the assumption of constant failure rate hypothesis. Though, even when this hypothesis is valid, MTBF use is often mistaken.

Let us consider the hypothesis of constant failure rate to be acceptable. The concerned item reliability can be thus described by an exponential function with constant failure rate λ = 1/MTBF. In this distribution, the MTBF time corresponds to 63.2% probability of failure. In other words, if an item with a given MTBF is put in operation, there is a 63% probability that it will fail before its operating time reaches a value equal to its MTBF.

Despite this, often the term MTBF is used to denote the average operating time before an item fails (failure free time). Weibull -Equipment 1 0 10000 20000 30000 40000 50000 60000 70000 80000 90000

MTBF vs Life expectancy

Failures over time

Typical railway signalling system call for tenders, specify requirements similar to following one: "The design life of signalling system shall be a minimum of 30 years".

The above mentioned requirement clearly refers to the life duration of the equipment. In other words: "For how long the system can operate without the need for a massive overhaul?"

When limited lifetime components are used, preventive replacements are planned in order to renovate the installed material and extend the life duration of the system up to the specified value e.g. average life duration of a PC is around 5 years. If a PC with 10 years life duration is required, we need to plan an overhaul after 5 years use to replace wear parts (keyboards, mouse), upgrade RAM memory and extend storage capacity (HDD, SSD). Too often, vendors do answer this question by providing an MTBF value and vice versa; MTBF requirements are answered by providing items life expectancy.

Though, life expectancy doesn't tell anything about item's reliability and item's reliability can't answer questions about life expectancy.

The only relationship between the life duration of an item and its reliability is the so-called bathtub-curve (Fig. 5.). In general, three phases are distinguishable during such a lifetime (or "bathtub") curve:

 An initial phase where residual (design) problems ("early failure" or "infant mortality") lead to relatively high-but decreasing-failure rate  A plateau over a longer time with a more or less constant failure rate  An increase of the failure rate at the end of life of the components ("tear and wear") That is, reliability model is strictly linked to lifetime distribution, but, their quantitative assessments are not: hence, poor reliability is not necessarily linked to a long life expectancy and vice versa.

As already mentioned MTBF use should be as far as possible limited to cases where constant failure rate assumption is acceptable. Hence, MTBF use should be used only during useful life period (flat part of the bathtub curve). But MTBF doesn't give any indication about the duration of the useful life period. Furthermore, life expectancy is not the same as useful life.

When an assessment of the life expectancy of a product is asked the first thing should be asked back is: "What the end-of-life conditions are?"

End-of-life condition could be specified as the moment where the reliability of the item goes below a given threshold or as the moment where the failure rate of the item starts to rise (end of the flat zone of the lifetime period) and reaches a given value, or as the moment where the wear-out of the item has as affect the loss of the item's main function.

In railways, there are many examples of high reliability and short life expectancy.

LED Railway signals are normally characterised by very low failure rate values (high MTBF under the hypothesis of constant failure rate). High-brightness LEDs tend not to burn out rapidly. Rather, they slowly fade away. A carefully designed LED lighting system can see the light source last for around 50,000 to 70,000 hours (6 to 8 years) before the illumination is no longer sufficient for the intended job. But, as already mentioned MTBF is simply the probability that one item fails in a given time.

However, we could define differently the threshold "the illumination is no longer sufficient for the intended job" and instantaneously the life expectancy would be extended the probability to fail being the same or even worse as the wear-out phenomena would be more pronounced when close to the end-of-life limit.

The knowledge of lifetime distribution is a fundamental prerequisite to life expectancy assessment.

In conclusion, life expectancy evaluation is complementary to item's reliability or failure intensity evaluation. Moreover, and especially for items subject to wear-out and, therefore, limited life expectancy, MTBF is by far the less useful metric. Any use of this metric should be followed by very clear statement about the period of applicability. In these cases the use of MTBF has to be strongly discouraged, also in the light of its frequent misinterpretation as duration.

MTBF vs Reliability decision making

Problem Statement

We want to boost the business of our young railway company by participating to the railway showroom that takes place every month (excluding July and august) and lasts one week.

We are willing to buy a diesel generator to power up electric equipment of our stand.

The use of this generator is for 168 hour (1 week) run and we'd like to maintain a relatively high reliability over each exposition.

The manufacturers we are considering claims his product has 500 hours MTBF. We ask the supplier to provide us with the failure data of the last endurance test performed on the concerned product: 10 units have been tested and the times to failure (in hours) are as follows {1, 25, 45, 60, 122, 517, 750, 1000, 1250, 1500}.

MTTF based decision

The classic way to calculate MTTF point estimate is to sum up the times to failure and divide by the number of failures (this is only applicable if at least one failure has occurred). We have a sum of 5,270 hours and 10 failures; MTTF point estimate is therefore 527.0 hours. This is above the vendor's claim of 500 so we are supporting the notion these are good generators.

After a quick inspection of the failure data provided by the supplier, we realize that a cluster of early failures exist which could reveal a variable decreasing failure rate of the product concerned. Thus, our assumption of constant failure rate and consequent use of MTTF metric may be wrong.

We decide to fit a Weibull distribution to the data. For a Weibull 2-parameter distribution we find beta = 0.44 and eta = 328.37. The data has a beta below 1 thus shows a decreasing failure rate over time.

The MTTF of our Weibull distribution is 868 hours. This gives us even more confidence that product performance is well above the vendor's claim of 500 hours MTTF. We have been confirmed that this product perfectly fits our needs.

Reliability based decision

As said, we use the generator for 168 hours at a time. What is the probability a generator will survive 168 hours once installed? Using the exponential distribution (MTTF point estimate) we find the reliability at 168 hours is:

𝑅 𝑡 𝑒 → 𝑒 73%# 2
As during the last showroom in December the most important Railway operators will participate, we are particularly interested into knowing what is the chance of successful operation over 168 hours the 10th time we run the generator (from 1,512 to 1680 hours of life time operation). This is done by assuming the generator has survived through 9 runs (1512 hours). In this case, we find, not surprisingly given the assumed constant failure rate and memoryless property of the exponential distribution, the expected reliability is still 73%.

In fact, let X be exponentially distributed with parameter λ = 1/MTTF; The probability of an exponential random variable exceeding the value "t+s" hours given t is the same as the variable originally exceeding that value s, regardless of t.

Using the Weibull distribution we find the reliability from time 0 till 168 hours is:

𝑅 𝑡 𝑒 → 𝑒 . . 47%# 5
The result is much lower than the estimate based on the MTTF calculation. We could make a decision based on the 868 hours MTTF value or the estimate of a 50% survival rate over the first 168 hours. 50% is not high reliability, yet 868 hours seems rather high (if compared to the 168 hours mission duration).

The reliability of the generator at the 10 th run, considering Weibull distribution and assuming it has survived during 9 runs (or 1,512 hours), is:

𝑃 𝑋 1680|𝑋 1512 𝑃 𝑋 1680 𝑃 𝑋 1512 𝑒 . . 𝑒 . .

91%# 6

The reliability over the 10th run is 91%. Much higher if compared to the MTTF based estimate.

Hence, this example demonstrated that decision based on MTTF, especially when considering constant failure rate model, could hide a considerable risk.

On the other hand, the use of reliability and correct reliability model not only reduces the risks of taking wrong decision but also gives us the means of making the best use of our assets. In this example, for instance, we could ask our supplier to apply a burn-in test to the generators and sell us one of those survived to the test. This would give us better chance to avoid a defecting item.

The reasons of MTBF popularity resilience

MTBF use, under the assumption of constant failure rate, entails a great simplicity of calculation and reliability assessment that vendors are resilient to drop. On their side, Clients do their best to obstacle the diffusion of more meaningful and proper metrics.

Here are some examples of some "Call for Tenders" RAM requirements extract from concrete railway use-cases:

1) "For each material constituting the Signalling system, the manufacturer must guarantee at least the following reliability objectives (MTBF values):  Workstation (PC, screen, hard disk, etc ... excluding keyboard and mouse):> 40,000 hours;  Network hardware (switch, router, etc.) We, the Vendors, attempt to provide just the right information at the right time to permit moving forward with a project. Development team focuses on delivering new designs on time and within budget with little more than cursory review of the few field issues they have heard about at some point.

Conclusions

This paper aimed at presenting the main misunderstandings related to the concept of reliability. Despite reliability is a wide topic, it is common habit to summarize it with synthetic metrics such as MTBF. The reasons explaining the success of the MTBF are indeed related to the attempt of describing complex behaviours by means of only one metric. As explained, the abuse of MTBF, especially in railways signalling domain, is linked to two main causes:

-The presence of reliability handbooks used as a reference to demonstrate requirements in terms of reliability are met; -The shortcut of the unverified hypothesis of constant failure rate describing the system under analysis.

The inadequacy of this metric has been evidenced by means of practical examples aiming at demonstrating that systems with high MTBF can be associated to low reliability behaviours. The stress of all these points flows into general misunderstandings from both vendors and customer's points of view. This article is a call to action for the persons involved in reliability demonstrations. It can help reviewing hypothesis and ways of working for those who use (and abuse) MTBF when demonstrating reliability. It also helps reliability practitioners that do not use MTBF to endorse their approach in front of customers not having clear in mind the mind traps related to the abuse of MTBF.

Fig. 1 .

 1 Fig. 1. Mean Time Between Failures

Fig. 2 .

 2 Fig. 2. Weibull chart of equipment 1

Fig. 3 .

 3 Fig. 3. Failures over time

Fig. 5 .

 5 Fig. 5. Bathtub curve (hypothetical failure rate vs time)