S Gaudan

G Motet

Forecasting of Object-Oriented Faults

Keywords: Object-oriented languages, dependable software, risk management, fault assessment, guidelines

Object-Oriented Technologies, such as Java, provide efficient features to develop software applications. In particular, they allow the development costs to be reduced. However, issues highlighted by the "Object-Oriented Technology in Aviation" group have to be handled to guarantee a high level of safety, in order to use such technologies in avionics software. In particular, the risk of Object-Oriented Technologies design faults has to be reduced to an acceptable level. These risk reduction actions must be preceded by forecasting the actual risk level of the developed application. The paper aims at presenting a method used to forecast the risk of the presence of these Object-Oriented Technologies faults in a given program. The approach proposed is based on Bayesian networks. Its principles are introduced. It is illustrated on an example of faults: the Accidental Overriding (AO). We highlight that our approach takes into account the complex relationships existing between the various object-oriented features: inheritance, distribution of the attributes and methods, etc. To conclude, we show how the obtained data can be analysed to specify design guidelines allowing an acceptable risk level to be reached.

Introduction

Avionics systems suppliers are considering Objectoriented technologies as they provide numerous advantages. The most interesting one is certainly the development cost reduction. However, as for any new technologies, its use in critical systems requires its control to be justified. The OOTiA group (Object-Oriented Technology in Aviation) highlighted that the object-oriented technologies cause two kinds of issues [START_REF] Ootia | Handbook for Object-Oriented Technology in Aviation[END_REF]: they introduce new types of faults at design time and new types of failures in operation. These last issues are coming from the implementation of the virtual machine often associated with these technologies. For instance, they are illustrated by the unpredictable activation of the garbage collector. We did not handle this kind of problem. We focus on the introduction of design faults which are specific to these technologies. The OOTiA handbook enumerates numerous types of characteristic design faults. For each of them, it proposes guidelines to prevent these faults. However, the origins of these guidelines are not justified and their actual impacts are not assessed. For instance, the OOTiA handbook signals that the inheritance mechanism is a hazardous feature whose use is acceptable if the inheritance depth is less than 6. However, numerous other factors must be taken into account including, for example, the number of methods declared in classes [START_REF] Li | Another metric suite for object-oriented programming[END_REF]. Moreover, each factor cannot be handled separately. For instance, more than 6 inheritances do not lead to faults if the inherited classes contain few methods or attributes. Our goal is to allow a justified fault risk control to be obtained to guarantee that an expected fault risk level is reached when new proposed guidelines are applied. To achieve this goal, we used a risk management process. This process is based on a well-known standard [START_REF]ISO/IEC Guide 73. Risk Management, Vocabulary, Guidelines for use in standards[END_REF]. At first, the origins of the faults were studied. This step provides the various factors impacting the risk of a given fault type [START_REF] Gaudan | Identification model of the object-oriented technology's risks for an avionics certification[END_REF]. Then their impact on the risk evaluation must be assessed. At first, we proposed to estimate the value of each factor. This result is obtained considering an object-oriented program or model as a nested structure. The faults come from the difficulty in knowing the available pieces of information in a given class due to the inheritance phenomena [START_REF] Motet | Assessment of the risks for using object-oriented technologies in critical software[END_REF]. The understanding factors of the fault risk are estimated by a method based on the Shannon theory [START_REF] Gaudan | A new structural complexity metrics applied to object-oriented design reliability assessment[END_REF]. However, multiple factors jointly impact the presence of faults whose effects have to be combined to obtain the global estimation of the risk. The control of these various influences also allows prevention guidelines to be proposed which impact various factors and not only one.

In section 2, we introduce a type of fault, the Accidental Overriding (AO), and its identification model presenting its sources. Section 3, summarizes the assessment method of the factors. In section 4, we introduce the global assessment model based on the Bayesian networks. Section 5, shows how this model can be analysed to define guidelines fitted to the program characteristics, that is, acting on the various factors. 1 2 Fault type identification

Accidental Overriding example

Accidental Overriding occurs when a designer introduces a method whose name and parameters describe a signature corresponding to an inherited method, whereas he/she would like to define a new method. It is concretised by a conflict of signatures between two methods accessible in a given class. This conflict leads to the accidental redefinition of the second method by the first one. This modification is hazardous due to the presence of the other existing methods. However, it does not always lead to a fault but just to a risk of fault as

• the added method could be introduced to define a new method; in this case the fault is actual;

• the added method could be introduced to override the existing method; in this case there is no fault;

Identification models

In [START_REF] Gaudan | Identification model of the object-oriented technology's risks for an avionics certification[END_REF], we proposed a conceptual identification model introducing the risk features and their relationships: hazard, environment, hazardous situation, event and consequence. This model allows a fault to be setted as a risk problem. This conceptual identification model was illustrated modelling the "Accidental Overriding" issue. We also proposed an analytic identification model based on the fault-tree method. From the inheritance mechanism defined in the Java language specification, we deduce the causes of the "Accidental overriding". The figure 2 presents this model. It highlights the various Object-Oriented features at the origin of the risk of fault.

Estimation concern

The analytic identification model is used to estimate the risk of the presence of this fault in a program.

This estimation needs two steps.

• At first, the various factors of the risk, that is the leaves of the tree, have to be estimated by means of specific metrics.

• Then, using the relationships expressed by the analytic identification model, the global risk has to be deduced.

Concerning the first step, numerous software metrics were proposed to estimated the various factors. However, we identified a lack concerning the consideration of the designer understanding. Indeed, the inheritance mechanism leads to the implicit availability of numerous methods and attributes inherited. To handle this issue we defined specific metrics based on the entropy theory [START_REF] Gaudan | A new structural complexity metrics applied to object-oriented design reliability assessment[END_REF].

Then, the various values of the factors have to be integrated to obtain the global value of the risk. It is an essential and difficult step symbolized by figure 3.

We established a risk estimation method based on the Bayesian Networks. The principles of the Bayesian Networks are introduced in the following section. They are illustrated on the considered example. The following section shows how this method can be used to specify guidelines allowing a safety level to be reached.

Bayesian Networks

Bayesian Networks are frequently used in risk estimation. In this section we present how the Bayesian Networks can be used to estimate the risk of faults and illustrate it on the "Accidental Overriding" (AO) issue.

A Bayesian Network is defined by [START_REF] Naïm | Réseaux bayésiens[END_REF]:

1. a set of identified factors, 2. a set of possible values of each identified factor, A "Goal" factor can be specified, representing a particular event whose occurrence has to be estimated from the network factors.

∃ meth ∈ A, ∃ redef ∈ C / redef redefines meth ∧ ∃ meth ∈ A ∃ redef ∈ C C = subclass (A) Signature (redef) = Signature (meth)) ∨ NbParam (meth) = NbParam (redef) ∧ ∧ ∧ Package (A) = Package (C) ∨ isPublic (
The following subsections present how the Bayesian networks can be built. This introduction is illustrated on the AO issue.

Factors of a Bayesian Network

To define the model, the factors influencing the studied risk have to be identified. This set of factors is not obligatory completed. However the most it is exhaustive, the most the estimation will be precise.

Certain factors affect several distinguished risks of faults. This will allow coupling between risks of various faults to be detected and the correlations between the factors of a Bayesian Network to be established.

We deduce the factors of a Bayesian Network from the identification of the risks of faults. For the estimation of the risk of AO faults, the identified factors are illustrated on figure 4. The proposed illustrations were produced using the tool BayesiaLab [START_REF] Bayesia | [END_REF]. The node representing the "goal" or "target" is identified by concentric circles.

Domains of values

The following step consists in defining the domain of value of each factor. It contains a discrete set of values which often identify ranges when the possible values are continue or plentiful. The definition of these ranges is based on expertise or experience feedback (statistics on the programs, impact of the coding standards, etc.).

The domains of values must be defined for each factor. For instance, two values estimate the goal AO: Occur or For the studied example of AO, we defined the following domains:

• The domain of the factor AO is Occur or Absent (fault occurence or absence of a fault).

• • etc.

The considered values can be precise or modified taking into account the applied coding rules. For instance, if a coding rule defines a maximum number of methods in a class, the considered estimation ranges can be In the same way, we propose stochastic distributions for each factor as illustrated on figure 5. These distributions are defined by expertize. They can be improved taking statistics on program into account as described in section 5.2.

Let us remark that the BayesiaLab tool used to produce the following figures define the stochastic distributions using percentages.

Causalities structure between factors

All the factors of the AO risk influence, directly or undirectly, the Accidental Overriding occurrence probability. This influence is described using arrows in the Bayesian Networks. They represent the causality between factors as illustrated by figure 6. • 1 hypothesis: proba(AO = Occur | Identifier-Size = [26+]): probability that a method cause an accidental overriding knowing that its identifier size is bigger than 25 characters,

• 2 hypothesis: proba(AO = Occur | Identifier-Size = [26+] ∧ In- heritanceNb = 0), • 3 hypothesis: proba(AO = Occur | Identifier-Size = [26+] ∧ In- heritanceNb = [1-2] ∧ MethodNb = [17-30]).
In the following, we only take 2 risk factors of AO present in the Bayesian Network into account to simplify the figures: Identifier-Size and Keyword. At first, let us consider that the influence of the factor Keyword on the AO risk is known. This knowledge is illustrated by the array provided on figure 7.

This figure shows that if a keyword exists, its knowledge determines in a deterministic way, the occurence or the absence of an Accidental Overriding (determinstic stochastic distribution: probabilities representing Figure 7: AO | Keyword the certitude). When a keyword exists or when an annotation is used to express the designer intention to define a new method, each method redefinition is automatically accidental as the designer intention expressed by the keyword is to create a new method. On the contrary, when no keyword is present, not any knowledge allows us to specify the estimation of the AO values.

For instance, let us consider that our knowledge concerns the size of the identifier of a method and the potential keyword. Figure 8 proposes a definition of the influences between the factors of the AO risk. This example shows that the conditional properties have to be defined for each possible combination of the considered factors (here, 3 × 4 = 12 distinguished). The deterministic knowledge defined on figure 7 is preserved when a known keyword exists. Any additional piece of information gained does not modify the risk estimation which is null (0%) if the keyword is "Override", and which is maximum (100%) if the keyword is "NewMeth". On the other hand, without further keyword, knowledge on the size of identifier of the method precises the estimation of the AO risk associated with this method.

Indeed, when a method possesses an identifier having less than 5 characters (high risk of name conflict) and a keyword "Override", the AO risk is null as illustrated on figure 9. The green bars representing probabilities characterize factors whose values are fixed.

In spite of an identifier whose size is very small, the AO risk is null for a method preceeded by the keyword "Override" as it expressed the intent of the redefinition. This determines with certainty the absence of unvolontary redefinition.

In the next figures, the nodes colored in yellow (left part) represent the factors on which we observe the distributions of values (included in the right part). The blue nodes are not observed. The observation of the factor "goal" is distinguished by a red background frame (factor on the right bottom part of figure 9). Finally, the green nodes represent factors whose value was settled. They represent the knowledge available on an element of the code or hypothesis which are made.

In our example, the knowledge of the identifier size has no impact on the estimation of the risk of Accidental Overriding when the factor "Keyword" is "Override" or "NewMeth". Figure 10 shows that the estimation of AO is not modified by the absence of knowledge on the factor "Keyword" (distribution by default of the possible values), relatively to the knowledge illustrated on figure 9 in which the identifier size is fixed between 0 and 4.

On the contrary, we observe that when there is no knowledge on the factor "Keyword" of a method, the estimation of the AO risk is precised by the knowledge of the small size of the identifier. Figure 11 illustrates this remark. Indeed, when no information exists on the keyword, the only knowledge on the identifier size (0-4) does not allow a conclusive estimation to be obtained (67.5% Occur, 32.5% Absence).

We infer that the various values observable for each factors are more or less significant for risk estimation.

All the knowledge about the values of factors and about their influences must be used to express the arrays defining the associated conditional probabilities.

When the knowledge is formalised in the whole in the model, the Bayesian network design is completed. Then this network can be handled by various proposed analysis.

The quality of the established network depends on the quality of the information available to define the network. In particular, this concerns the nodes connection knowledge. Indeed, the more the network is complete and the more the factors are correlated, the more the analysis deduced will be meaningfull.

Bayesian networks applied to

OOTiA faults

Bayesian networks applied to Object-Oriented Technologies

The networks for estimating each risk associated with the methods or the attributes were separately defined. It We introduce a factor "Element Type" whose value "Method" or "Attribute" determines the estimation efforts in accordance with the element type.

Figure 12 proposes a Bayesian network to estimate the risks associated with the elements of an object-oriented code for the types of faults cited in the OOTiA document.

Of course, due to its definition mode, it is quite easy to add to the network the estimation of any other useful type of fault.

For instance, we notice on figure 12 that the risks SDIH 1 and IC 2 , which concern elements of different types (SDIH concerns the attributs and IC the constructors), have a common factor (the number of classes in which an accessible constructor is not redefined). This means that a correlation exists between the estimations of these two types of faults.

The factors corresponding to the various metrics using information theory [START_REF] Gaudan | A new structural complexity metrics applied to object-oriented design reliability assessment[END_REF] (green nodes) present a high cost as their calculation requires a complex static analysis of the code. On the contrary, the yellow nodes represent the type of the analyzed element. This information is easily obtained as the method visibility or the number of local attributes. However, the factors requiring a run in the inheritance chain lead to a non trivial static analysis of the code. Therefore, their cost is more important.

Definition of guidelines

When the Bayesian network associated with the fault risk estimation is defined, various exploitations are available, providing several interesting results. It is possible to use the Bayesian network to process

• generic estimations (independent on the programs), and to process

• particular estimations (on the element of a specific program).

The various kinds of exploitations of the networks are enumerated here after and will be detailed later on.

• Specific estimation of a risk on a given element of a given code (attribut, method);

• Generic estimations:

definition of coding rules to reach a specified risk level, definition of coding rules to reach a specified risk level, considering a set of fixed factors;

• Inference: definition of static analysis of code optimized on the more meaningfull factor to obtain a precise estimation of a fault risk;

• Learning techniques and graphical analysis.

Specific estimation of a risk of a given element (attribute, method)

At first, we present the most simple type of analysis: the use of the Bayesian network to estimate the risk of a specific fault type for a given element of a code. To do it, information about the element whose risk has to be estimated must be gathered. Then these pieces of information must be introduced in the Bayesian network fixing the values of the associated factors. Thus, we deduce the risk occurence likelihood of the studied fault on the considered element. Sometimes, the values associated with some of the factors are not available and so are not considered in the estimation calculus (treatment of the uncertainty). Each unfixed factor also influences the global estimation. Each possible value of a factor has an impact taken into account proportionately to its likelihood a priori. For that purpose, the factor values distributions defined in the Bayesian Network are used.

Figure 13 provides an example of the risk estimation on an Accidental Overriding. It assumes that a method is labelled by the keyword "NewMeth", has an identifier size between 5 et 10 characters, possesses a public visibility and has no parameters (factor ParameterType is estimated as Simple), redefines a method inherited from 3, 4 or 5 inheritance levels, and is in a class which provides from 31 to 55 defined methods.

The estimation of AO obtained in such a configuration is a deterministic estimation of the occurence of an accidental overriding (100% Occur of AO) due to the presence of the keyword "NewMeth" (100% NewMeth).

Definition of coding rules from a given risk level

One of the main goal of our work is to propose a set of coding rules for object-oriented technologies that provide guarantees that a given risk level is not overtaken. This means that the actual risk is lower than the acceptable risk threshold. For example, assume that the maximum acceptable probability of the occurence of an AO fault is 10 -4 for each method. Each risk whose estimation value is higher than 10 -4 is considered as unacceptable.

Then, to reach an acceptable level, it is necessary to define coding rules on the language features impacting the pieces of information used to estimate the risk.

To achieve this objective, a maximum value for the factor "Occur" of the goal AO is fixed. Figure 14 shows how this value is specified in the red frame which define the likelihood associated with the various values of AO (Occur and Absence).

Thanks to the property of reversibility of the Bayesian networks, a combination of likelihoods of the factors values can be deduced allowing the fixed risk threshold to be achieved.

Figure 15 presents on our example, the impact of the fixed value for the factor "goal" on the factors. For instance, it shows that the likelihood of presence of the keyword "NewMeth" and that the likelihood associated with a small size of identifiers strongly decreased. Therefore, a coding rule excluding identifiers whose size is less than 10 characters for a redefining method should maintain the risk estimation at an acceptable level. To check its efficiency, we fix the forbidden values to a null likelihood. Then we observe the change of the likelihoods of AO values depending on the various possible configurations of the other factors.

In figure 14, the probability of the presence of a keyword "NewMeth" is 30%. This value is modified when the threshold of presence of AO is fixed at 0.01%. Indeed, we observe on figure 15 that the probability of the keyword "NewMeth" became close to null (0,01%). This kind of the Bayesian network analysis suggests to exclude this type of values.

For such an exploitation of the Bayesian networks, an acceptable threshold has to be defined. Then, processing the network, the constraints on the various factors of the program are deduced.

The risk acceptability threshold is specified depending on the considered criticality level (DAL A, B, etc.). According to the types of applications, the risk acceptability threshold evolves.

The dependency between DAL and design constraints The Bayesian networks allow to deduce coding rules specific for each risk acceptability threshold, that is, criticality level, fixing a value to the factor "goal".

However, the definition of a given risk acceptability threshold for each criticality level must be proposed or validated by the certification authorities as they previously specified the required verification techniques for each criticality level.

Definition of coding rules relatively to a risk threshold and a set of fixed factors

At first, we justify the interest of the Bayesian networks considering an example of coding rule proposed by OOTiA [START_REF] Ootia | Handbook for Object-Oriented Technology in Aviation[END_REF]. This coding rule excludes the use of inheritance chain whose lenght is greater than 5 levels. This requirement does not depend on the criticality level. For this coding rule, the factor "InheritanceNb" is constrained independently to the other risk factors. Moreover the constraint is restrictive. In such a case, we want to propose more adaptable constraints concerning the inheritance depth. In return, it is necessary to propose additional constraints on other factors to preserve the risk acceptability. So the designer has more freedom degrees to take into account the design constraints as well as the safety requirements. The Bayesian networks applied to fault risks help in defining such coding rules. Fixing a risk acceptability threshold (depending on the considered criticality level) and other risk factors (for instance, more than 5 levels of inheritance), the Bayesian networks deduce the consequences on the other factors of the risk of fault. Thus, one or several constraints can be relaxed which are compensated by stonger restrictions on other factors. So, the same safety level is obtained with adjustable rules than with generic and restrictive coding rules.

Consider our simple example used to estimate the risk of Accidental Overriding taking 2 factors into account. At first, we fix the acceptability threshold of the presence of this type of fault at 0.01%. This means that an occurence probability of such a fault lower than 10 -4 is acceptable for applications whose DAL is C (for example). Then we observe the consequences on the other factors (one factor in this simplified example). Two distinguished infuences are illustrated on figure 16.

The first proposes to measure the impact of the presence of a method whose identifier is very short in order to reach the acceptable level. It shows that the favoured value of the factor keyword is "Override". On the con-trary, in the second example provided on figure 16, the important size of the identifier largely compensates the absence of keyword. Realistic Bayesian networks possess a large number of factors. A value of one attribute can be fixed to relax conventional constraints. Then, the Bayesian networks running provides combinations of other factors allowing the acceptable level of risk to be achieved. The values of several factors can be fixed. Then the coding rules are such as "If the inheritance chain depth is greater than 5, the presence of keywords is obligatory if methods are redefined, and the identifier size must be greater than 10".

Consider again the Accidental Overriding. It is important to propose other coding rules than the obligation to use keywords since numerous object-oriented languages do not offer these features.

Conclusion

To conclude, let us first underline that our approach proposed to define design constraints is generic. Thus it should be used to define good practices to manage other types of software risks (memory risks, time execution risks, etc.), or to manage system risk, at the sytsem level.

Then, we want to mention one more time that the major contribution by applying our risk management methodology is to provide means to mesure the guarantees on the safety that are provided, when using the defined guidelines.

Finally, as the design constraints represent a significant part of the developpers environment, and thus influence significantly the development costs, they should be defined by a strategic analysis, taking into account their efficientness on safety, but also their cost.

Figure 1 :

 1 Figure 1: Accidental Overriding

Figure 3 :

 3 Figure 3: From factors estimation to risk estimation

  Type (Param ((redef,i)) = Type (Param (meth,i)))

Figure 2 :

 2 Figure 2: Analytic model to identify the risk of an Accidental Overriding

Figure 4 :

 4 Figure 4: Risk factors of the Accidental Overriding

••

  The domain of the factor Identifier-Size is defined by 4 values (the numerous possible values were discritized by intervals): [1-4], [5-10], [11-25], [26+]. The domain of the factor Number of methods (MethodNb) is defined by 4 values (discretization intervals): [0-15], [16-30], [31-55], [56+]. The domain of the factor Number of inheritances (InheritanceNb) is défined by 4 values (discretization intervals): [0], [1-2], [3-5], [6+].

Figure 5 :

 5 Figure 5: Distributions of the values of the AO factors

4. 3

 3 Domain and distribution of the values of the factorsThe stochastic distribution of the possible values of the factors must be defined. As previously, these distributions have to be justified by experience feedbacks, best practices (such as coding rules), statistics, etc.For instance, in a firm which requires that the identifiers should have more than 4 characters (coding rule) and taking into account the fact that most of the identifier lenghts are in the range [11-25] characters, we propose the following stochastic distribution for the factor "Identifier-Size" :• Proba(Identifier-Size = [0-4]) = 0.01,• Proba(Identifier-Size = [5-10]) = 0.2,• Proba(Identifier-Size = [11-25]) = 0.7,• Proba(Identifier-Size = [25+]) = 0.09.

Figure 6 :

 6 Figure 6: Relationships between factors and AO

Figure 8 :

 8 Figure 8: AO | Key-word ∧ Ident-Size

Figure 9 : 4 Figure 10 :

 9410 Figure 9: RI | Keyword = Override ∧ Ident-Size = 0-4

Figure 12 :

 12 Figure 12: Bayesian network to estimate OOT fault risks

Figure 13 :

 13 Figure 13: Factors of risk of AO fixed for a specific estimation

Figure 14 :

 14 Figure 14: Definition of an acceptable risk level

Figure 16 :

 16 Figure 16: Taille-Identifier influences

a causality structure correlating the factors (network), and

4. a valuation of the influences existing between the factors, that is, the influence of the possible values of each attribute, on the correlated attributes (directly connected in the network).


Pascal Traverse

Systems safety in a few nutshells

Keywords: safety, aviation, system, architecture, resilience

Safety is THE priority in aviation. The reason is obvious: people's lives are at stake and this is ingrained in the industry (operators and manufacturers, regulation agencies). Instead of a wide description of the systems safety process, which is generally known and well documented, we will rather focus on a few important points, not always part of conventional wisdom. We intend to show that safety process is fully embedded in design, that the ubiquitous and magic number of 10 -9 is only a tiny part of the solution, the multiple dimension of the issues and the overall resilience of the process.

Introduction

As mentioned in the abstract, safety is THE priority in aviation. Instead of a wide description of the systems safety process, which is generally known and well documented (see for system safety [START_REF]Guidelines and methods for conducting the safety assessment process on civil airborne systems and equipment[END_REF] or considerations in [START_REF] Avizienis | Fundamental Concepts of Dependability[END_REF]), we will rather focus on a few important points. They will also help decipher our team logo: a balance with an aircraft viewpoint! Flying is safe, thanks to a global ethics, and is shared at all levels of the aviation industry. Safety needs to be addressed everywhere: during airplane development obviously, but also in airline personnel excellence (pilots, commercial crew, maintenance personnel), air and airport traffic management, weather forecast, security, Flight Operation Quality Assurance, Airworthiness Authorities. These are allimportant links in the global safety chain.

The airplane taken alone is safe when designed correctly (human factors consideration, lift capability, structural strength amongst many other parameters), with the adequate manufacturing quality, including the systems. Systems are not a significant cause of accidents. However, continuous care has to be taken to ensure that systems are properly designed, easy to maintain and failures handled adequately.

Conversely, systems significantly help pilots in their tasks, at different levels, as expressed by this diagram (inspired from Reason's one [START_REF]Reason: Human Error[END_REF]). Others are more specific to Airbus airplanes, like Flyby-Wire flight envelope protections [START_REF] Favre | Fly-by-Wire for commercial aircraft -the Airbus experience[END_REF]. These protections are still progressing; latest improvement is an avoidance system in case of TCAS warning while autopilot is engaged (A/P TCAS mode [START_REF] Averseng | Automatic Guidance for traffic avoidance[END_REF]).

Fully embedded in design

Safety process starts by capturing safety requirements by applying a Functional Hazard Analysis (FHA) methodology.

Catastrophic

Failure condition which would result in multiple fatalities, usually with the loss of the aeroplane

Hazardous

Failure condition which would reduce the capability of the aeroplane or the ability of the crew to cope with adverse operating conditions to the extend that there would be:

-A large reduction in safety margins or functional capabilities -Physical distress or excessive work load such that the flight crew cannot relied upon to perform their tasks accurately and completely; or -Serious or fatal injuries to a relatively small number of occupants other than flight crew

Major

Failure condition which would reduce the capability of the aeroplane or the ability of the crew to cope with adverse operating conditions to the extend that there would be for example:

-A significant reduction in safety margin or functional capabilities; or -A significant increase in crew workload or in condition impairing crew efficiency; or -Discomfort to flight crew, or physical distress to passengers or cabin crew, possibly including injuries.

Minor

Failure condition which would not significantly reduce aeroplane safety and which involve crew actions that are well within their capabilities.

Minor failure conditions may include, for example: -A slight reduction in safety margin or functional capabilities, -A slight increase in crew work load such as routine flight plan changes or -Some physical discomfort to passengers or cabin crew. Each of them (aircraft deceleration of ground, passenger accommodation…) is decomposed and for each sub-functions, failures are considered, the least being the consequences of the loss of the subfunction and of an erratic behaviour. Although each FHA is part of a single System Safety Assessment (SSA), the function is evaluated taking into account all systems that participate to its implementation. Combinations with flight phases, and of such functional failures are also covered. Consequences are assessed at aircraft level and classified by the well-known Minor to Catastrophic terms.

Based on this classification, safety objectives are determined (probability of the loss of this subfunction shall be less than 10 -5 /Flight Hour (FH) for example if the classification is Major). Design of the airplane has then to comply with these requirements: from the overall systems architecture and installation routing, down to the definition of monitorings, reconfiguration logics, wiring connectors.

Safety engineers are also usually embedded in design teams or at least in very close contact. This allows the safety requirements to be fully understood and taken into account by the design, and the safety documents to be relevant, thanks to deep system knowledge by the designers. In addition, safety engineers provide an independent line of reporting. Their independence in term of organisation is subject to a sufficient knowledge, allowing them to assess most of a design by themselves.

Extremely Improbable

A Catastrophic failure condition must be Extremely Improbable. It is always understood that its occurrence probability per flight hour must be less than a famous number: 10 -9 . Meeting this number means that the risk on passenger life is reduced to a minimum. This is a strong statement from a passenger standpoint. However, the aviation community has the honesty to recognise that there is no such thing as zero risk and this way of designing airplane has proven to be successful.

The magic and ubiquitous number is only one side of Extreme Improbability. Qualitative assessments are just as important.

First of all, a single failure shall not be Catastrophic, whatever its probability. This is difficult to handle: what is a single failure? How to limit imagination and to prove that, as an example, a microprocessor will never output errors and in the meantime radiate energy that will fry some monitoring device? In practical terms, Regulation states that experienced engineering judgement may enable an assessment that such a failure mode is not a practical possibility. If this is the case, it will not be considered.

Again, when probabilities are multiplied, then the associated failures are supposed to occur independently. This is checked through the Common Mode Analysis. A typical common mode is the design of the system and its equipment. Development Assurance Level [START_REF]Airworthiness Standards: Transport Category Airplane[END_REF] is intended to minimise the occurrence of design errors to a level consistent with the risk, along with some dissimilarity, partitioning and so on.

Putting aside fault-trees and failure diagrams, it is also assumed that some events may occur, without stated probability: a partial bulkhead rupture, an engine rotor burst whose debris strike the systems in the fuselage for example, as in picture. These are called Particular Risks. Here again, a difficulty is to determine the analysis perimeter. Models for these risks are coming from experience of in-service events, or from theoretical studies. Even if we cannot prove that all future events are taken into account, these fixed cases are driving the system design and installation to separate redundant item as reasonably feasible. Cases occurred which were not in the model, but were survived by the airplane.

A Particular Risk Assessment participates to Security evaluation: Survivability of Systems. It consists in ensuring that the airplane will survive to the destruction of all the systems within a physical sphere. This sphere is deemed representative of a small explosion; its diameter is consistent with the hole in the fuselage that is used to size the structure against depressurisation.

The Zonal Safety Assessment piloted by safety engineers and systems installers will now check that our hypotheses are correct. It consists in inspecting the aircraft by experienced engineers with support of checklists.

It is also important to recognize that flight and ground crews will make errors, even when well trained, experienced and rested individuals using well-designed systems. Therefore the designed cockpit and all other human-machine interface must enable the crew to manage errors that can be reasonably expected in service, assuming crews acting in good faith.

Architecture and Integration

Safety of an item cannot be fully assessed without taking into account its effect on other systems and then on the airplane. It is thus required for safety assessment to go down to the reconfiguration logic embedded in the 527 th line of code and to the 3 rd bearing inside the actuator, but also to go up to the functional interface between systems, to the crew awareness and the effect on the airplane trajectory. Control surfaces and some aircraft performances have to be sized to cover failure cases. More and more we have also to think about the whole air traffic management system and to navigation performance and integrity. Particular Risk Assessment addresses on one side the physical distance between a given wire and the trajectory of debris or the location of a heat source and on another side overall airplane effect. They have a direct impact on structure architecture; hence they must be taken into account very early in the design process to reduce the risk of late modification, and proper trade-off have to be made to avoid heavy design solutions.

Safety activity involves multiple disciplines: all systems (avionics, engine, mechanical systems, air, fuel, cabin, design assurance) engineering, flight physics (handling quality, performance, loads), structure (capability to resist a system failure or a shock from a bird for example), system installation engineering (including DMU (Digital Mock-Up)), the world of airplane operations: maintenance engineering, human factors, flight test pilots and engineers, and of course the management. These disciplines are involved through their respective organisations.

It is thus mandatory for the safety engineer to integrate most aircraft disciplines and aircraft and systems architecture.

Mission assurance (Operational Reliability and Safety)

A failure has some likelihood to occur on a flight departing its "home", to an airport without available spare. In this case, we will try to take benefit of existing safety margins to allow the dispatch of the airplane with a known failure on board. This is the purpose of the Master Minimum Equipment List (MMEL). This Airbus document provides a list of equipment that can be failed prior to dispatch, often associated with some mitigation means; the airlines are deriving their own rule, the MEL, from it. . The decision to add a flying spare is difficult to take: this is additional cost for the airplane, and weight. This has to be balanced with the operational need of the airlines. It is also possible to ask for maintenance checks, to uncover some potentially existing hidden failures.

To put an item in this MMEL list, first criterion is to do as much as we can to mitigate the risk; then we have to check that safety objectives are still reached.

Safety and certification

Certification major objective is to ensure safety. It comes quite naturally then that safety assessments are a means to show compliance with certification requirements, most notably the famous 25.1309 [START_REF]DAL for system), Certification Considerations for Highly-integrated or Complex Systems[END_REF], plus some others. This sets a minimum standard common to all aircraft manufacturers. On top of it, two kinds of margins are taken: some to improve the availability of systems and then to allow dispatch with failed equipment (MMEL). Others are more the result of a given aircraft manufacturer history and belief. For example, Boeing and Airbus Fly-by-Wire systems are tolerant to some design errors, but not exactly the same [START_REF] Yeh | Unique Dependability Issues for Commercial Airplane Fly By Wire Systems[END_REF][START_REF] Traverse | Airbus Fly-by-Wire : a total approach to dependability[END_REF]. The usefulness of these margins is not proven … neither the contrary, which makes it very difficult to get rid of them once they have been introduced.

As often in the safety process, we have to ensure a safe baseline, to then balance safety margins within the aviation business: airplane operability, weight, recurring and maintenance cost among others. This requires competencies, but also a strong decision making process.

Life after Type Certification

When the airplane gets its Type Certificate, there are both a feeling of relief, but also some uneasiness: excitation to meet the milestone is no more present and activities are going to be different from plain development. On safety side, this new era is filled with small developments (modifications) and also with in-service events. Airlines regulation requires them to report any event that is more or less safetyrelated. Airbus has to assess them. This needs a lot of balance! First of all, when an event occurs with some safety concern, the first and most common reaction would be to ask for all airplanes to be grounded while a comprehensive study of the event is done. However, no airplane would be flying if this were the rule. So, there is a need to think fast and smart to understand most of the event and to find a way to mitigate the risk.

And here we enter a second exercise that is to balance practicality of what will be proposed to airlines and potential safety margins in the design. We must keep the fleet safe. Fortunately there are always some margins (like MMEL) that we can leverage to reduce customer burden. A third exercise is to draw lessons from in-service events. We can see that airplanes are not operated as we engineers have in mind; we also sometimes discover system behaviours that were unexpected.

We thus need to improve our methods, to integrate this experience in future design (for both safety and operational reliability), and also to think about the whole flying fleet to wonder if a given event is not revealing a weakness on another system or another airplane type.

Resilience

There is some resilience in both the airplane and in the process. Airplane resilience is shown by the cases which occurred, which were not design cases but which were covered by the global margins that are taken. The pit-bull on the loose in a cargo bay is a typical example. This is not a design case, but it occurred once and precautions to separate resources were effective in protecting essential systems. Another example is the A300B hit by a missile in Baghdad [START_REF] Lemaignan | Flying with no Flight Controls: Handling Qualities Analyses of the Baghdad Event[END_REF]. It was saved by the extraordinary skills of the crew and some inherent characteristics of the airplane.

A breakthrough may have been done on A380 with the introduction of flight controls electrical actuation [START_REF] Traverse | Airbus Fly-by-Wire : a total approach to dependability[END_REF][START_REF] Todeschi | A380 flight control actuation -lessons learned on EHAs design[END_REF]. Covering engine rotor burst is the safety requirement that lead to their introduction. On top of this (and of the weight saving performed) electrical actuation could bring some benefit against events which are not in-line with the model on engine rotor burst that is used in the aviation community. It is also a dissimilar power source, fundamentally different from hydraulic system. Hopefully, we will never benefit of this resilience, but who knows?

In term of process resilience, the aviation world is continuously learning. First of all, the incidents and accidents that are occurring must be reported. As per [START_REF]Implementing Rules for the airworthiness[END_REF], airplane manufacturer must have a system for collecting, investigating and analysing information related to occurrences that might cause adverse effects on the safety on the airplane. This system must be made available to all operators of the airplane. If a potential unsafe condition is identified, it must be reported within 72 hours to EASA. It must be analysed, and the Authority may mandate actions such as a modification or an operational limitation. When the regulation is found insufficient, then it evolves. New regulation may be required on existing and already delivered airplane if safety benefits are deemed significant.

The regulation is also updated to address new technologies. Regulation is thus very stringent (we have to comply) and versatile, constantly evolving.

On top of the mandatory reporting system for all significant events according to the regulation, voluntary incident reporting system are also in place in several countries. The aim is to collect and disseminate data to track and address potential or actual safety issues. These "Safety Management Systems" are confidential and non-punitive ("just culture" is often used) and useful to identify potential precursors to accident [START_REF] Werfelman | Keys to Safety, in Aerosafety world[END_REF]. Dissemination of information is done several ways, including by public domain by such publication as the Journal of Flight Safety Foundation and the Airbus Safety Magazine [14].

Conclusion: What about the future?

Apart from workload issues and the health consequences of the inherent paranoia of all safety engineers, the situation appears bright. This is not a reason to keep going without any changes. A methodological step has been taken with A380: a significant formalisation effort has been done, which leads to more rigor in the assessment; the use of Digital Mock-Up changed also significantly the process for PRA and ZSA.

In the future we can expect some process improvement thanks to all the models that will be available (models of system, of airplane physics, of systems installation), to their interconnection, and to new analysis methods such as formal proof [START_REF] Traverse | Airbus Fly-by-Wire : a total approach to dependability[END_REF][START_REF] Akerlund | ISAAC, a framework for integrated safety analysis of functional, geometrical and human aspects[END_REF]. A better confidence in the result, obtained more efficiently is at stake. Some progress is also foreseen without needing a high level of technology improvement in the area of getting more synthetic documents and leveraging operational reliability on the safety process and data. Another area of progress is to evaluate the trend of the aviation industry to identify future threats and future opportunities (new technologies that could provide safety benefit).

Glossary

Figure 1 :

 1 Figure 1: logo of Airbus systems safety and reliability team

Figure 2 :

 2 Figure 2: Multiple safety layers Basic capability of the airplane and basic airmanship of the crew are the first barriers. Then, through Systems, the crew is informed and kept aware of the aircraft situation, performance and health status etc. Systems are able to warn the crew. Moreover, systems are able to add safety barriers. Some of these barriers are available on most modern airplanes: Traffic and Collision Avoidance System, Ground Proximity Warning System, or weather radar for example. Others are more specific to Airbus airplanes, like Flyby-Wire flight envelope protections [4]. These protections are still progressing; latest improvement

Figure 3 :

 3 Figure 3: basic failure classification A top level FHA provides a global framework, and then an FHA is performed for each A/C function. Each of them (aircraft deceleration of ground, passenger accommodation…) is decomposed and

Figure 4 :

 4 Figure 4: engine rotor burst trajectories

Figure 5 :

 5 Figure 5: Getting to grips with the MEL We are taking benefit of the redundancy level: quite often systems are designed with an additional computer on top of what is absolutely needed to meet the famous 10 -9. The decision to add a flying spare is difficult to take: this is additional cost for the airplane, and weight. This has to be balanced with the operational need of the airlines. It is also possible to ask for maintenance checks, to uncover some potentially existing hidden failures.

Figure 6 :

 6 Figure 6: In-service aircraft

Figure 7 :

 7 Figure 7: What about the future?

Acknowledgement

The author acknowledges the significant contribution of his colleagues to this work: Christine Bezard, Jean-Pierre Daniel, François Raillat and Johannes Wohlfart.


Theofanis P Raptis
email: theofanis.raptis@iit.cnr.it

Andrea -2906-584x]

Marco Passarella
email: andrea.passarella@iit.cnr.it

Conti

Distributed Path Reconfiguration and Data Forwarding in Industrial IoT Networks

Keywords: Industry 4.0, Internet of Things, Data Distribution

In today's typical industrial environments, the computation of the data distribution schedules is highly centralised. Typically, a central entity configures the data forwarding paths so as to guarantee low delivery delays between data producers and consumers. However, these requirements might become impossible to meet later on, due to link or node failures, or excessive degradation of their performance. In this paper, we focus on maintaining the network functionality required by the applications after such events. We avoid continuously recomputing the configuration centrally, by designing an energy efficient local and distributed path reconfiguration method. Specifically, given the operational parameters required by the applications, we provide several algorithmic functions which locally reconfigure the data distribution paths, when a communication link or a network node fails. We compare our method through simulations to other state of the art methods and we demonstrate performance gains in terms of energy consumption and data delivery success rate as well as some emerging key insights which can lead to further performance gains.

Introduction

With the introduction of Internet of Things (IoT) concepts in industrial application scenarios, industrial automation is undergoing a tremendous change. This is made possible in part by recent advances in technology that allow interconnection on a wider and more fine-grained scale [START_REF] Wollschlaeger | The future of industrial communication: Automation networks in the era of the internet of things and Industry 4.0[END_REF]. The core of distributed automation systems and networks is essentially the reliable exchange of data. Any attempt to steer processes independently of continuous human interaction requires, in a very wide sense, the flow of data between some kind of sensors, controllers, and actuators [START_REF] Sauter | The evolution of factory and building automation[END_REF].

In today's typical industrial configurations, the computation of the data exchange and distribution schedules is quite primitive and highly centralised. Usually, the generated data are transferred to a central network controller or intermediate network proxy nodes using wireless links. The controller analyses the received information and, if needed, reconfigures the network paths, the data forwarding mechanisms, the caching proxy locations and changes the behaviour of the physical environment through actuator devices. Traditional data distribution schemes can be implemented over relevant industrial protocols and standards, like IEC WirelessHART and IEEE 802.15.4e.

Those entirely centralised and offline computations regarding data distribution scheduling, can become inefficient in terms of energy, when applied in industrial IoT networks. In industrial environments, the topology and connectivity of the network may vary due to link and sensor-node failures [START_REF] Shrouf | Smart factories in Industry 4.0: A review of the concept and of energy management approached in production based on the internet of things paradigm[END_REF]. Also, very dynamic conditions, which make communication performance much different from when the central schedule was computed, possibly causing sub-optimal performance, may result in not guaranteeing application requirements. These dynamic network topologies may cause a portion of industrial sensor nodes to malfunction. With the increasing number of involved battery-powered devices, industrial IoT networks may consume substantial amounts of energy; more than would be needed if local, distributed computations were used.

Our contribution. In this paper we consider an industrial IoT network comprised of sensor and actuator nodes. Data consumers (actuators) and producers (sensors) are known. A number of intermediate resource-rich nodes act as proxies. We assume that applications require a certain upper bound on the data delivery delay from proxies to consumers, and that, at some point in time, a central controller computes an optimal set of multi-hop paths from producers to proxies, and from proxies to consumers, which guarantee a maximum delivery delay, while maximising the energy lifetime of the network (i.e., the time until the first node in the network exhaust energy resources). We focus on maintaining the network configuration in a way such that application requirements are met after important network operational parameters change due to some unplanned events (e.g., heavy interference, excessive energy consumption), while guaranteeing an appropriate utilisation of energy resources. We provide several efficient algorithmic functions which locally reconfigure the paths of the data distribution process, when a communication link or a network node fails. The functions regulate how the local path reconfiguration should be implemented and how a node can join a new path or modify an already existing path, ensuring that there will be no loops. The proposed method can be implemented on top of existing data forwarding schemes designed for industrial IoT networks. We demonstrate through simulations the performance gains of our method in terms of energy consumption and data delivery success rate.

Related works

There are numerous relevant previous works in the literature, but due to lack of space, we provide some information about the most representative and most related ones to this paper, which are [START_REF] Ha | On-demand cache placement protocol for content delivery sensor networks[END_REF], [START_REF] Raptis | A distributed data management scheme for industrial IoT environments[END_REF], [START_REF] Sun | Traffic load balancing among brokers at the IoT application layer[END_REF], [START_REF] Raptis | Maximizing industrial IoT network lifetime under latency constraints through edge data distribution[END_REF], [START_REF] Saifullah | End-to-end communication delay analysis in industrial wireless networks[END_REF] and [START_REF] Han | Reliable and real-time communication in industrial wireless mesh networks[END_REF]. Although some of those works use proxy nodes for the efficient distributed management of network data, they all perform path selection computations centrally. Placement and selection strategies of caching proxies in industrial IoT networks have been investigated in [START_REF] Ha | On-demand cache placement protocol for content delivery sensor networks[END_REF]. Efficient proxy-consumer assignments are presented in [START_REF] Raptis | A distributed data management scheme for industrial IoT environments[END_REF].

Data re-allocation methods among proxies for better traffic balancing are presented in [START_REF] Sun | Traffic load balancing among brokers at the IoT application layer[END_REF]. Scheduling of the data distribution process maximising the time until the first network node dies is suggested in [START_REF] Raptis | Maximizing industrial IoT network lifetime under latency constraints through edge data distribution[END_REF], respecting end-to-end data access latency constraints of the order of 100 ms, as imposed by the industrial operators [START_REF]Network-based communication for Industrie 4.0[END_REF]. Delay aspects in a realistic industrial IoT network model (based on WirelessHART), and bounding of the worst case delay in the network are considered in [START_REF] Saifullah | End-to-end communication delay analysis in industrial wireless networks[END_REF]. Reliable routing, improved communication latency and stable real-time communication, at the cost of modest overhead in device configuration, are demonstrated in [START_REF] Han | Reliable and real-time communication in industrial wireless mesh networks[END_REF]. Different to those works, in this paper, we present a method which exploits the local knowledge of the network nodes so as to perform distributed, local path reconfiguration computations towards more efficient energy dissipation across the network.

The model

We model an industrial IoT network as a graph G = (V, E). Typically, the network features three types of devices [START_REF] Xu | Internet of things in industries: A survey[END_REF]: resource constrained sensor and actuator nodes u ∈ V , a central network controller C, and a set of proxy nodes in a set P , with P ⊂ V , |P | |V -P |. Every node u ∈ V , at time t, has an available amount of finite energy E t u . In general, normal nodes u have limited amounts of initial energy supplies E 0 u , and proxy nodes have significantly higher amounts of initial energy supplies E 0 p , with E 0 p E 0 u , ∀u ∈ V, p ∈ P . A node u ∈ V can achieve one-hop data propagation using suitable industrial wireless technologies (e.g., IEEE 802.15.4e) to a set of nodes which lie in its neighbourhood N u . N u contains the nodes v ∈ V for which it holds that ρ u ≥ δ(u, v), where ρ u is the transmission range of node u (defined by the output power of the antenna) and δ(u, v) is the Euclidean distance between u and v. The sets N u are thus defining the set of edges E of the graph G. Each one-hop data propagation from u to v results in a latency l uv . Assuming that all network nodes operate with the same output power, each one-hop data propagation from u to v requires and amount of uv of energy dissipated by u so as to transmit one data piece to v. A node can also transmit control messages to the network controller C by consuming cc amount of energy. For this kind of transmissions, we assume that more expensive wireless technology is needed, and thus we have that cc uv (for example, the former can occur over WiFi or LTE links, while the latter over 802.15.4 links).

Occasionally, data generation occurs in the network, relevant to the industrial process. The data are modelled as a set of data pieces D = {D i }. Each data piece is defined as D i = (s i , c i , r i ), where s i ∈ V is the source of data piece D i , c i ∈ V is the consumer 1 of data piece D i , and r i is the data generation rate of D i . Each data piece D i is circulated in the network through a multi-hop path Π sici . Each node u ∈ Π sici knows which is the previous node previous(i, u) ∈ Π sici and the next node next(i, u) ∈ Π sici in the path of data piece D i . Without loss of generality, we divide time in time cycles τ and we assume that the data may be generated (according to rate r i ) at each source s i at the beginning of each τ , and circulated during τ . The data generation and request patterns are not necessarily synchronous, and therefore, the data pieces need to be cached temporarily for future requests by consumers. This asynchronous data distribution is usually implemented through an industrial pub/sub system [START_REF] Raptis | A distributed data management scheme for industrial IoT environments[END_REF]. A critical aspect in the industrial operation is the timely data access by the consumers upon request, and, typically, the data distribution system must guarantee that a given maximum data access latency constraint (defined by the specific industrial process) is satisfied. We denote this threshold as L max .

Due to the fact that the set P of proxy nodes is strong in terms of computation, storage and energy supplies, nodes p ∈ P can act as proxy in the network and cache data originated from the sources, for access from the consumers when needed. This relieves the IoT devices from the burden of storing data they generate (which might require excessive local storage), and helps meeting the latency constraint. Proxy selection placement strategies have been studied in recent literature [START_REF] Raptis | A distributed data management scheme for industrial IoT environments[END_REF][START_REF] Ha | On-demand cache placement protocol for content delivery sensor networks[END_REF]. We denote as L uv the latency of the multi-hop data propagation of the path Π uv , where L uv = l ui +l i(i+1) +...+l (i+n)v . Upon a request from c i , data piece D i can be delivered from p via a (distinct) multi-hop path. We denote as L ci the data access latency of c i , with L ci = L cip + L pci . We assume an existing mechanism of initial centrally computed configuration of the data forwarding paths in the network, e.g., as presented in [START_REF] Raptis | Maximizing industrial IoT network lifetime under latency constraints through edge data distribution[END_REF]. In order to meet the industrial requirements the following constraint must be met:

L ci ≤ L max , ∀c i ∈ V .

Network epochs and their maximum duration

In order to better formulate the data forwarding process through a lifetimebased metric, we define the network epoch. A network epoch j is characterised by the time J (τ divides J) elapsed between two consecutive, significant changes in the main network operational parameters. A characteristic example of such change is a sharp increase of uv between two consecutive time cycles, due to sudden, increased interference on node u, which in turn leads to increased retransmissions on edge (u, v) and thus higher energy consumption. In other words,

uv (τ )-uv (τ -1) uv (τ )
> γ, where γ is a predefined threshold. During a network epoch, (all or some of) the nodes initially take part in a configuration phase (central or distributed), during which they acquire the plan for the data distribution process by spending an amount of e cfg u energy for communication. Then, they run the data distribution process. A network epoch is thus comprised of two phases: Configuration phase. During this initial phase, the nodes acquire the set of neighbours from/to which they must receive/forward data pieces in the next epoch. Data forwarding phase. During this phase the data pieces are circulated in the network according to the underlying network directives.

Network epochs are just an abstraction that is useful for the design and presentation of the algorithmic functions, but does not need global synchronisation. As it will be clear later on, each node locally identifies the condition for which an epoch is finished from its perspective, and acts accordingly. Different nodes "see" in general different epochs. Although some events which affect the epoch duration cannot be predicted and thus controlled, we are interested in the events which could be affected by the data distribution process and which could potentially influence the maximum epoch duration. We observe that an epoch cannot last longer than the time that the next node in the network dies. Consequently, if we manage to maximise the time until a node dies due to energy consumption, we also make a step forward for the maximisation of the epoch duration.

We now define the maximum epoch duration, as it can serve as a useful metric for the decision making process of the distributed path reconfiguration. The maximum epoch duration is the time interval between two consecutive node deaths in the network. Specifically, each epoch's duration is bounded by the lifetime of the node with the shortest lifetime in the network, given a specific data forwarding configuration. Without loss of generality, we assume that the duration of the configuration phase equals τ . We define the variables, x ij uv which hold the necessary information regarding the transmission of the data pieces across the edges of the graph. More specifically, for epoch j, x ij uv = 1 when edge (u, v) is activated for data piece D i . On the contrary, x ij uv = 0 when edge (u, v) is inactive for the transmission of data piece D i . We denote as a j uv =

d i=1 r i x ij uv
the aggregate data rate of (u, v) for epoch j. Stacking all a j uv together, we get x j u = [a j uv ], the data rate vector of node u for every v ∈ N u . Following this formulation (and if we assumed that J → ∞) the maximum lifetime of u during epoch j can be defined as:

T u (x j u ) =        E j u v∈Nu uv a j uv if E j u > e cfg u τ if E j u ≤ e cfg u 0 if E j u = 0 , (1)
where e cfg u is the amount of energy that is needed by u in order to complete the configuration phase. Consequently, given an epoch j, the maximum epoch duration is J max = min u∈V T u (x j u ) | v∈Nu x ij uv > 0 . There have already been works in the literature which identify, for each data source s i , the proxy p where its data should be cached, in order to maximise the total lifetime of the network until the first node dies [START_REF] Raptis | Maximizing industrial IoT network lifetime under latency constraints through edge data distribution[END_REF] (or, in other words, maximise the duration of the first epoch: max min u∈V T u (x 1 u ) | v∈Nu x i1 uv > 0 ), and configure the data forwarding paths accordingly. Reconfigurations can be triggered also when the conditions under which a configuration has been computed, change. Therefore, (i) epoch duration can be shorter than J, and (ii) we do not need any centralised synchronisation in order to define the actual epoch duration. We consider the epoch as only an abstraction (but not a working parameter for the functions), which is defined as the time between two consecutive reconfigurations of the network, following the functions presented in Section 5.

Path reconfiguration and data forwarding

The main idea behind our method is the following: the nodes are initially provided with a centralised data forwarding plan. When a significant change in the network occurs, the nodes involved are locally adjusting the paths, using lightweight communication links among them (e.g., 802.15.4) instead of communicating with the central network controller (e.g., LTE, WiFi). The main metric used for the path adjustment is the epoch-related T u (x j u ), as defined in Eq. 1. The functions' pseudocode is presented in the following subsections. Due to lack of space we omit the presentation of some functions' pseudocodes, but those can be found in the extended version of the paper [START_REF] Raptis | Distributed path reconfiguration and data forwarding in industrial IoT networks[END_REF]. The functions are presented in upright typewriter font and the messages which are being sent and received are presented in italics typewriter font. The arguments in the parentheses of the functions are the necessary information that the functions need in order to compute the desired output. The arguments in the brackets of the messages are the destination nodes of the messages and the arguments in the parentheses of the messages are the information carried by the messages. We assume that a node u complies with the following rules: u knows the positions of every v ∈ N u , u knows the neighbourhood N v of every node v in its own neighbourhood N u , and u stores only local information or temporarily present data pieces in transit.

Distributed data forwarding. The distributed data forwarding function DistrDataFwd(u) pseudocode is being ran on every node u of the network and is provided in the body of Alg. 1. At first, if E 0 u > 0, the node communicates its status to the central network controller (which uses the method presented in [START_REF] Raptis | Maximizing industrial IoT network lifetime under latency constraints through edge data distribution[END_REF] for computing the data distribution parameters (proxy allocation, data forwarding paths) in an initial setup phase of the network), it receives the data forwarding plan and it initiates the first time cycle (lines 1-4). Then, for every time cycle u repeats the following process, until either it is almost dead, or more than half of its associated wireless links spend more energy compared to the previous time cycle, according to the system parameter γ (lines 5-18): u starts the data forwarding process according to the data distribution plan received by C (line 6). Afterwards, it checks if a set of control messages have been received from any v ∈ N u and acts accordingly, by calling the necessary functions (lines 7-16).

If u detects that a link is consuming too much energy and has to be deactivated, it deactivates this link (by causing a path disconnection for every D i that is using this link) and notifies the previous node in the path of every D i that was using this link, previous(i, u), by sending an alert message (lines 7-9). For a given deactivated link (u, v) for data piece D i , alert messages contain information about D i and about the two nodes u, v in the path prior to disconnection. Then, u checks whether there has been an alert message received (line 10), and calls function LocalPathConfig (displayed in Alg. 2). Through this function the paths can be reconfigured accordingly, for all involved data pieces D i . Due to the fact that LocalPathConfig sends some additional messages regarding joining a new path and modifying an existing one, u then checks for reception of any of Algorithm 1: DistrDataFwd(u) until Eu = 0 or uv (τ )-uv (τ -1)

1 if E 0 u > 0 then 2 send status [C](Eu, uv , luv) 3 receive plan [u] 4 τ = 1 5 repeat 6 run DataForwarding(τ ) 7 if ∃(u, v) with uv (τ )-uv (τ -
uv (τ ) > γ for > 50% of active edges (u, v) of u 19 send alert [previous(i, u)](u, v), ∀Di, ∀v ∈ Nu 20 Disconnect(u)
those messages (lines 13 and 15) and calls the necessary functions JoinPath and ModifyPath.

Finally, u sends an alert message to the previous nodes in the existing paths prior to final disconnection due to energy supplies shortage (line 19).

Local path configuration. A node u calls the path configuration function LocalPathConfig when it receives an alert which signifies cease of operation of an edge (u, v) due to a sudden significant increase of energy consumption due to interference uv (τ )-uv (τ -1) uv (τ ) > γ or a cease of operation of a node v due to heavy interference in all of v's edges or due to low energy supplies (Alg. 1, lines 9 and 19).

LocalPathConfig is inherently local and distributed. The goal of this function is to restore a functional path between nodes u and v by replacing the problematic node previous(v) with a better performing node w, or if w does not exist, with a new efficient multi-hop path Π uv . At first, u checks if there are nodes ι in its neighbourhood N u which can directly connect to v and achieve a similar or better one-hop latency than the old configuration (line 1). If there are, then the w selected is the node ι which given the new data piece, will achieve a maximum lifetime compared to the rest of the possible replacements, i.e., w = arg max ι∈Nu T ι (x j u ), and an acceptable latency l uw + l wv (line 2). u then sends to w a join message (line 3). Following the loop elimination process, loop freedom is guaranteed for the cases where there are available nodes w ∈ N u which can directly replace v. In the case where this is not true and LocalPathConfig calls local aodv+ instead (Alg. 2, line 6), then the loop freedom is guaranteed by the AODV path configuration process, which has been proven to be loop free [START_REF] Zhou | The proof of AODV loop freedom[END_REF].

Performance evaluation

We implemented DistrDataFwd method and we conducted simulations in order to demonstrate its performance. We configured the simulation environment (Matlab) according to realistic parameters and assumptions. A table presenting the parameter configuration in details can be found in the extended version of the paper [START_REF] Raptis | Distributed path reconfiguration and data forwarding in industrial IoT networks[END_REF]. Briefly, we assume an industrial IoT network, comprised of devices equipped with ultra low-power MCUs like MSP430 and IEEE 802.15.4 antennae like CC2420, able to support industrial IoT standards and protocols like WirelessHART and IEEE 802.15.4e. We assume a structured topology (as in usual controlled industrial settings) of 18 nodes with 4 proxies which form a 2D grid with dimensions of 7.5 m × 16.0 m. We set the transmission power of the nodes for multi-hop communication to -25 dBm (typical low-power) which results in a transmission range of 3 m. For the more expensive communication with the network controller, we set the transmission power to 15 dBm, typical of wireless LAN settings. We set the time cycle τ = 1 second, the percentage of consumers over the population 0.05 -45% and we produce 1 -8 D i /τ per consumer. In order to perform the simulations in the most realistic way, we align the L max value with the official requirements of future network-based communications for Industry 4.0 [START_REF]Network-based communication for Industrie 4.0[END_REF], and set the latency threshold to L max = 100 ms. We set γ = 50%, the T T L argument of local aodv+ equal to 2, we assume a maximum battery capacity of 830 mAh (3.7 V) and equip the nodes with energy supplies of E 0 u = 0 -1 Wh and E 0 p = 3 Wh. Last but not least, in order to have a realistic basis for the values of the one-hop latencies l uv used in the simulations, we aligned the different l uv values to one-hop propagation measurements with real devices, for different pairs of transmitting and receiving nodes. Specifically, we used the measurements provided in Fig. 3b of [START_REF] Raptis | Maximizing industrial IoT network lifetime under latency constraints through edge data distribution[END_REF].

In order to have a benchmark for our method, we compared its performance to the performance of the PDD data forwarding method which was provided in [START_REF] Raptis | Maximizing industrial IoT network lifetime under latency constraints through edge data distribution[END_REF]. Due to the fact that PDD was designed for static environments without significant network parameter changes, we also compare to a modified version of PDD, which incorporates central reconfiguration when needed (we denote this version as PDD-CR). Specifically, PDD-CR runs PDD until time t, when a significant change in the network happens, and then, all network nodes communicate their status (E t u , e uv , l uv ) to the network controller C by spending e cc amount of energy. C computes centrally a new (near-optimal as shown in [START_REF] Raptis | Maximizing industrial IoT network lifetime under latency constraints through edge data distribution[END_REF]) data forwarding plan and the nodes run the new plan. In our case, we run the PDD-CR reconfigurations for each case where we would do the same if we were running DistrDataFwd. As noted before, the conditions that trigger a change of the forwarding paths are either node related (a node dies) or link related (change of interference which results in uv (τ )-uv (τ -1) uv (τ ) > γ)2 . Energy efficiency. The energy consumption over the entire network during 2000 hours of operation is depicted in Fig. 3a. The energy consumption values include the energy consumed for both the data distribution process and the reconfiguration. Our method achieves comparable energy consumption as PDD, despite being a local, adaptive method. This is explained by the following facts: PDD-CR requires more energy than DistrDataFwd for the path reconfiguration process, as during each epoch alteration every node has to spend e cc amount of energy for the configuration phase. On the contrary, in the DistrDataFwd case, only some of the nodes have to participate in a new configuration phase (usually the nodes in the neighbourhood of the problematic node), and spend significantly less amounts of energy. In the case of PDD, the nodes do not participate in configuration phases, so they save high amounts of energy. In Fig. 3b, we can also see the energy consumption of DistrDataFwd and PDD-CR for different percentages of reconfigurations (w.r.t. the number of time cycles τ ). It is clear that the more the reconfigurations that we have in the network, the more the gap between the performance of DistrDataFwd and PDD-CR increases.

Data delivery rate. The data pieces lost during 2000 hours of operation are depicted in Fig. 3c. We consider a data piece as lost when the required nodes or path segments are not being available anymore so as to achieve a proper delivery. When a data piece is delivered, but misses the deadline L max , it is not considered as lost, but we measure the high delivery latency instead. We can see that the low energy consumption of the PDD method comes at a high cost: it achieves a significantly lower data delivery rate than the PDD-CR and the DistrDataFwd methods. This is natural, because as noted before, PDD computes an initial centralised paths configuration and follows it throughout the entire data distribution process. The performance of the DistrDataFwd method stays very close to the performance of the PDD-CR method, which demonstrates the efficiency of DistrDataFwd in terms of successfully delivering the data pieces.

Maximum data access latency. The maximum data access latency during 2000 hours of operation is depicted in Fig. 3d. The measured value is the maximum value observed among the consumers, after asynchronous data requests to the corresponding proxies. PDD does not perform well, due to the fact that it is prone to early disconnections without reconfiguration functionality. The fluctuation of PDD-CR's curve is explained by the re-computation from scratch of the data forwarding paths which might result in entirely new data distribution patterns in the network. DistrDataFwd respects the L max threshold for most of the time, however at around 1700 hours of network operation it slightly exceeds it for a single proxy-consumer pair. On the contrary, PDD-CR does not exceed the threshold. This performance is explained by the fact that DistrDataFwd, although efficient, does not provide any strict guarantee for respecting L max , for all proxy-consumer pairs, mainly due to the absence of global knowledge on the network parameters during the local computations. PDD-CR, with the expense of additional energy for communication, is able to centrally compute near optimal paths and consequently achieve the desired latency. There are two simple ways of improving DistrDataFwd's performance in terms of respecting the L max threshold: (i) insert strict latency checking mechanisms in the local aodv+ function, with the risk of not finding appropriate (in terms of latency) path replacements, and thus lowering the data delivery ratio due to disconnected paths, and (ii) increase the T T L argument of local aodv+, with the risk of circulating excessive amounts of route discovery messages, and thus increasing the energy consumption in the network. Including those mechanisms is left for future work.

Conclusion

We identified the need for a distributed reconfiguration method for data forwarding paths in industrial IoT networks. Given the operational parameters the network, we provided several efficient algorithmic functions which reconfigure the paths of the data distribution process, when a communication link or a network node fails. The functions regulate how the local path reconfiguration is implemented, ensuring that there will be no loops. We demonstrated the performance gains of our method in terms of energy consumption and data delivery success rate compared to other state of the art solutions.

Fig. 1 :Fig. 2 :

 12 Fig. 1: Loop avoidance -forward loop

  Max. acc. lat.

Fig. 3 :

 3 Fig. 3: Performance results.

If the same data of a source, e.g., s1, is requested by more than one consumers, e.g., c1 and c2, we have two distinct data pieces, D1 = (s1, c1, r1) and D2 = (s2, c2, r2), where s1 = s2.

The qualitative behaviour would not change in case of additional reconfiguration events, which simply increase the number of reconfigurations.

Acknowledgments. This work was funded by the European Commission through the FoF-RIA Project AUTOWARE: Wireless Autonomous, Reliable and Resilient Production Operation Architecture for Cognitive Manufacturing (No. 723909).

If such a node does not exist, then u runs local aodv+, a modified, local version of AODV protocol for route discovery, between nodes u and v. local aodv+ is able to add more than one replacement node in the path. The main modification of local aodv+ with respect to the traditional AODV protocol is that local aodv+ selects the route which provides the maximum lifetime T w (x j u ) for the nodes w which are included in the route. Specifically, this modification with respect to the classic AODV is implemented as follows: The nodes piggyback in the route request messages the minimum lifetime T w (x j u ) that has been identified so far on the specific path. Then when the first route request message arrives at v, instead of setting this path as the new path, v waits for a predefined timeout for more route request messages to arrive. Then, v selects the path which provided the max min w∈Nu T w (x j u ). The reader can find more details about the AODV protocol in [START_REF] Perkins | Ad hoc on-demand distance vector (AODV) routing[END_REF].

Joining new paths, modifying existing paths and avoiding loops. In this subsection, we briefly describe the functions regarding joining a new path and modifying an already existing path for loop elimination. Due to lack of space, we do not include the pseudocode of those functions; however, they can be found at the extended version of this paper [START_REF] Raptis | Distributed path reconfiguration and data forwarding in industrial IoT networks[END_REF]. JoinPath(i, w, v) is the function which regulates how, for data piece D i , a node u will join an existing path between nodes w and v and how u will trigger a path modification and avoid potential loops which could result in unnecessary traffic in the network. Due to the fact that the reconfigurations do not use global knowledge, we can have three cases of u joining a path: (i) u is not already included in the path (u / ∈ Π sici ), (ii) u is already included in the path (u ∈ Π sici ), and w is preceding u in the new path (previous(i, u) = w) with a new link (w, u), and (iii) u is already included in the path (u ∈ Π sici ), and u is preceding w in the new path (previous(i, w) = u) with a new link (u, w). In all three cases, JoinPath sends a modification message to the next node to join the path, with the appropriate arguments concerning the deletion of parts of the paths, and the direction of the deletion, for avoidance of potential loops (see [START_REF] Raptis | Distributed path reconfiguration and data forwarding in industrial IoT networks[END_REF]). This message triggers the function ModifyPath (see [START_REF] Raptis | Distributed path reconfiguration and data forwarding in industrial IoT networks[END_REF]). In case (i) it is apparent that there is no danger of loop creation, so there is no argument for deleting parts of the path. In order to better understand cases (ii) and (iii) we provide Figures 1 and2. In those Figures we can see how the function ModifyPath eliminates newly created loops on u from path reconfigurations which follow unplanned network changes.