Michel Batteux
email: michel.batteux@irt-systemx.fr

Tatiana Prosvirnova
email: tatiana.prosvirnova@centralesupelec.fr

Antoine Rauzy
email: antoine.rauzy@ntnu.no

Liu Yang
email: liu.yang@ntnu.no

Reliability assessment of phased-mission systems with AltaRica 3.0

Keywords: phased-mission systems, AltaRica 3.0, modeling patterns

In this article, we show how phased-mission systems can be described and assessed by means of the AltaRica 3.0 technology. AltaRica 3.0 is a formal, object-oriented modeling language dedicated to probabilitic risk/safety analyses. We illustrate here its power by introducing a modeling pattern making it possible to represent phased-mission systems in an elegant way. This modeling pattern fits with the CESAMES framework for systems engineering. We show that AltaRica 3.0 models for phased-mission systems can be assessed efficiently by means of the stepwise simulator and the stochastic simulator we developed for the language.

I. INTRODUCTION

It is often the case that the mission of complex systems can be decomposed into successive phases. Such systems are called phased-mission systems (PMS). Typically, the flight of an aircraft involves take-off, ascent, level-flight, descent, and landing phases. During each of these phases, the aircraft has to accomplish a specific task and is subject to different stresses as well as different dependability requirements, hence justifying different reliability assessment models. Phases are however not independent: if a certain capacity is lost during a phase, it has good chance to remain lost for the subsequent phases. Reference [START_REF] Xing | Reliability of phased-mission systems[END_REF] presents a state of the art on different techniques and assessment methods for PMS.

In this article, we show how phased-mission systems can be described and assessed by means of the AltaRica 3.0 technology. AltaRica 3.0 is a formal, object-oriented modeling language dedicated to probabilitic risk/safety analyses [START_REF] Prosvirnova | The altarica 3.0 project for model-based safety assessment[END_REF]. AltaRica 3.0 can be seen as a combination of two parts:

• Its mathematical framework, based on guarded transition systems (GTS) [START_REF] Batteux | Altarica 3.0 assertions: the why and the wherefore[END_REF], [START_REF] Rauzy | Guarded transition systems: a new states/events formalism for reliability studies[END_REF]; • Its set of structuring constructs, based on the system structure modeling language (S2ML) [START_REF] Batteux | S2ml for structuring models[END_REF]. GTS are stochastic state automata. They have been designed to increase as much as possible the expressive power of the language without increasing the computational cost of the assessment algorithms. S2ML gathers and unifies structuring constructs stemmed from object-oriented programming [START_REF] Abadi | A Theory of Objects[END_REF], and prototype-oriented programming [START_REF] Noble | Prototype-Based Programming: Concepts, Languages and Applications[END_REF]. The combination of GTS and S2ML results in a powerful, versatile language which exploits assessment algorithms in an optimum way.

One of the big advantages of high level modeling is the possibility to reuse modeling components within models and between models. In this way, the modeling process is made both more efficient and less error prone. In languages such as Modelica [START_REF] Fritzson | Principles of ObjectOriented Modeling and Simulation with Modelica 3.3: A CyberPhysical Approach[END_REF], reuse is achieved via the design of libraries of "on-the-shelf" modeling components. This approach is also feasible in probabilistic risk and safety analyses, but to a much lesser extent. The reason is that these analyses represent systems at a high level of abstraction. Modeling components, except for very basic ones, tend thus to be specific to each system.

In AltaRica 3.0, reuse is mostly achieved by the design of modeling patterns, i.e. examples of models representing remarkable features of the system under study. Once identified, patterns can be duplicated and adjusted for specific needs [START_REF] Batteux | Altarica 3.0 in 10 modeling patterns[END_REF]. Patterns are not only a mean to organize and to document models, but also and more fundamentally a way to reason about systems under study.

In this article, we introduce a new modeling pattern dedicated to the phased-mission systems. We show that this modeling pattern fits into the CESAMES framework for systems architecting [START_REF] Krob | CESAM: CESAMES Systems Architecting Method: A Pocket Guide[END_REF]. We illustrate the proposed approach by applying this pattern to model a satellite communication system. We show how phased-mission systems can be assessed using the AltaRica Wizard modeling and simulation environment.

The remainder of this article is organized as follows. Section II presents a phased-mission system used as an illustrative example throughout this article. Section III gives an overview of the key concepts of the AltaRica 3.0 modeling language. Section IV describes the modeling pattern for phased-mission systems and applies it to the case study. Section V discusses why this pattern fits into the CESAMES framework. Section VI gives some numerical results. Finally, section VII concludes the article.

II. CASE STUDY

As an illustrative example, we shall consider a phasedmission system borrowed from [START_REF] Lu | Reliability analysis of large phased-mission systems with repairable components based on success-state sampling[END_REF], which represents the communication mission between a given satellite Sat and the ground stations F1 and F2, as shown Fig. 1.

Telecommunications between the satellite Sat and the ground stations rely on different equipment at different periods of time. Generally there are two channels available for Sat to communicate with the stations: the first channel uses geostationary satellites SatRelay1 and SatRelay2 as the relay (and then SatRelay1 or SatRelay2 retransmit images to the stations); the second channel allows the satellite Sat to communicate directly with the stations when they are visible to each other. The communication channel can be considered as a subsystem which may contain antennas, batteries, transmitters, and receivers as shown in the reliability block diagrams Fig. 1. The satellite Sat orbits the Earth for 300 laps, each orbital lap contains four phases. The subsystems used in each phase are represented by the reliability block diagrams shown Fig. 2. The durations of the different phases are given Table I. The satellite communication system is thus a PMS made of 28 independent components and operating through 1200 successive phases. All components may fail in operation even if they are not in use during the considered phase. The radar (ground station) components can be repaired while the satellite components cannot. Failure and repair rates are shown in Table I.

Our objective is to assess the reliability of this phasedmission system for a 3600 hours mission.

III. ALTARICA 3.0 A. Guarded Transition Systems

Guarded transition systems, introduced in [START_REF] Rauzy | Guarded transition systems: a new states/events formalism for reliability studies[END_REF], are at the core of AltaRica 3.0. Formally, a guarded transition system is a quintuple V, E, T, A, ι , where:

• V is a set of variables. Each variable v of V has a type, i.e. can take its value in a certain set of constants (Booleans, integers, reals or set of symbolic constants), called its domain and denoted by dom(v). V is actually the disjoint union of two subsets S and F , where S is the subset of state variables and F is the subset of flow variables. • E is a set of events. Each event e of E can be associated with a non-decreasing invertible function delay e from [0, 1] to R + ∪{+∞}. The inverse delay -1 e of this function is a cumulative probability distribution.

• T is a set of transitions. A transition t is a triple e, g, a , denoted by g e -→ a, where e is an event of E, g is a Boolean condition on variables of V called the guard of the transition, and a is an instruction, called the action of the transition, that changes the value of (some of) the state variables.

• A is an instruction, called the assertion, that calculates the values of flow variables from the values of state variables. • Finally, ι is a function that gives the initial value of state variables and the default value of flow variables. As an illustration, we shall consider a non-repairable component in Fig. 3. This modeling component is reused in many different models and often many times within a model. For this reason, it is declared as a class in the code of Fig. 3. A class is an onthe-shelf modeling component. It can be instantiated as many times as necessary into models. The state of a component is represented by a Boolean variable named vsWorking (declared line 2). Initially, the component is working, so the attribute init of the variable vsWorking is set to true. This attribute indicates also that vsWorking is a state variable. The component has a failure transition (declared line 6) that goes from the state working to the state failed. In the code of Fig. 3, the event failure (declared line 3) is associated with a delay obeying the inverse of a negative exponential distribution of parameter pLambda. This parameter is declared at line 4. AltaRica 3.0 provides several built-in distributions, like Dirac, exponential, Weibull as well as empirical distributions (given as a list of points).

AltaRica 3.0 comes with a standard library that declares a number of classes such as NonRepairableComponent to represent various types of components.

B. Composition

The class NonRepairableComponent involves no flow variable and therefore no assertion. Flow variables are mainly a mean to connect components. The composition of two (or more) guarded transition systems is actually a guarded transition system. Formally, let

M 1 : V 1 , E 1 , T 1 , A 1 , ι 1 and M 2 : V 2 , E 2 , T 2 , A 2 , ι 2 be two guarded transition systems. Then M 1 ⊗ M 2 is simply the guarded transition system V, E, T, A, ι such that V = V 1 ∪ V 2 , E = E 1 ∪ E 2 , T = T 1 ∪ T 2 , A = A 2 • A 1 and ι = ι 2 • ι 1 .
Larger models can thus be obtained by composing smaller models.

Consider the satellite subsystem of our illustrative example. It is composed of two batteries, two transmitters and two receivers. All the components may fail in operation and cannot be repaired. They can be represented as instances of the class NonRepairableComponent. The model of the whole satellite subsystem is given Fig. 4. This code declares first the class NonRepairableInOutComponent (lines 1-6). This class inherits from the class NonRepairableComponent (via the extends clause, line 2). This means that a NonRepairableInOutComponent is a NonRepairableComponent with additional properties. In this case, Boolean flow variables vfInput and vfOutput are declared (line 3). Their default values are set to false via the attribute reset. This attribute indicates also that vfInput and vfOutput are flow variables. Finally, the assertion line 4 tells how the value of the flow variable vfOutput is calculated from the value of the state variable vsWroking and the flow variable vfInput.

The satellite subsystem itself is encoded as a class as it shall be reused several times in the model (lines 8-30). The class SatelliteSubSystem declares as many instances of NonRepairableInOutComponent as there are components (lines 9-14) and a Boolean flow variable vfOutput (line 15). The assertion consists then simply in connecting together the inputs and outputs of the components (lines 18-29). Variables declared inside a component (prototype or instance of class) are accessed via the dot notation: Battery1.vfInput denotes the variable vfInput of the component Battery1.

Note that as in the code Fig. 3, the values of the parameters pLambda can be redefined at instantiation, if necessary. It is even possible to change the distributions themselves at instantiation. This makes it possible to design generic classes for components.

To represent the radar subsystem from our illustrative example, we need first to define a class RepairableInOutComponent which inherits from the class NonRepairableComponent and defines a new event repair and the associated transition; second we shall use this class to define the class RadarSubSystem in the same way as the class SatelliteSubSystem given Fig. 4.

C. Aggregation

Composition describes a "is-part-of" relation. This relation assumes that a component cannot belong to two different parent components. There are cases however where the same component is used in several places or to contribute to different functions of the system. This kind of "uses" relations can be described by means of aggregation.

As an illustration, consider again our satellite communication system. This system is made of five sub-systems; these sub-systems are further decomposed, and so on. This structural breakdown is correct, but does not represent the whole system. The system description is completed by the reliability block diagrams Fig. 2 for each phase of the system. These reliability block diagrams encode more functional than physical groupings. Physical components are shared by different reliability block diagrams. Therefore, we need to be able to describe hierarchical breakdowns with branches sharing components. This is the very purpose of the notion of aggregation. It is implemented in AltaRica 3.0 by the "embeds-as" clause.

The AltaRica 3.0 code describing the 1st phase of the satellite communication system is shown Fig. The satellite communication system itself is encoded as a prototype, i.e. a modeling component with a unique occurrence (lines 1-15). There is a little chance for this modeling component to be reused somewhere. It is specific to the system under study, conversely to the components NonRepairableInOutComponent or RepairableInOutComponent that are reused several times in this and other models. Prototypes are introduced by the keyword block.

The block SatelliteCommunicationSystem is composed of five subsystems defined as the instantiation of the previously defined classes SatelliteSubSystem and RadarSubSystem (lines 3-4).

The block Phase1 aggregates (via the clause embeds) the components used during the 1st phase (lines 7-13). It also defines a Boolean variable vfWorking (a flow variable) which is true when the system is working and false otherwise (line 10). The assertion (lines 11-12) defines the value of the flow variable vfWorking according to the outputs of all the components.

IV. ARCHITECTURAL PATTERN FOR PHASED-MISSION SYSTEMS Fig. 6 gives a snapshot of the architectural modeling pattern we designed for phased-mission systems. This pattern consists in organizing the model in 4 parts:

1) The system breakdown structure (the hierarchy of components together with their behavior); 2) A unit that monitors the changes of phases, called "Phase controller"; 3) The set of modeling units representing each phase of the system. Each phase unit aggregates the components used during this phase and declares interactions between them. 4) The global assertion, called "Multiplexer". This assertion describes whether the system is able to perform its mission in the current phase (decided by the phase controller). Performance indicators (e.g. system reliability) are calculated thanks to this assertion.

Connections between the 4 parts are described by two types of relations:

• "Flow propagation" by means of assertions, represented by plain arrows Fig. 6.

• "Aggregation" relation, represented by dashed arrows Fig. 6; As an illustration consider the satellite communication system described Section II. The structure of the AltaRica 3.0 model representing this system is given Fig. 7.

Inside the block SatelliteCommunicationSystem, the breakdown structure of the whole system is described lines 3-4) by instantiating previously defined classes SatelliteSubSystem and RadarSubSystem. This part corresponds to the block 1 in Fig. 6.

Second, the unit representing changes of phases is defined by the block PhaseController (lines 7-9). This block is specific to this system, that is why it is defined as a prototype. Its behavior is detailed Fig. 9. Changes of phases are represented by an automaton graphically represented Fig. 8. The phase is represented by a state variable vsPhase which is an Integer and can take 4 values. Changes of states are represented by the transitions which are labeled by deterministic events. Each event is thus associated with a deterministic delay defined by the parameters Dj. Their values are taken from Table I.

Note that it is possible to use an enumeration to define different phases. For example, domain PhaseDomain {PHASE1, PHASE2, PHASE3, PHASE4}

This block corresponds to the block 2, "Phase Controller", Fig. 6.

Third, the architecture of the subsystem used during each phase is defined by the blocks Phase1, Phase2, Phase3 and Phase4 (lines 10-34). Consider for instance the block Phase4. This block aggregates (via the clause embeds) the Finally, the global assertion (lines 36-42) defines the value of the flow variable vfWorking (declared line 5) according to the phase (state variable Phases.vsPhase) and the status of the corresponding phase unit (flow variable PhaseJ.vfWorking). This part corresponds to the block 4, "Multiplexer", Fig. 6.

Note that subsystems Sat, F1, F2, SatRelay1 and SatRelay2 are shared between the blocks Phase1, Phase2, Phase3 and Phase4, which define the system configuration used in each phase. It is achieved thanks to the aggregation relation (embeds clause). The aggregation relation allows to define phased mission systems in an elegant way.

It is also possible to define conditional connections between components depending on the phase. Again consider our illustrative example. First, we declare a flow variable vfPhase inside of each phase unit (Fig. 10,line 4). Second, we connect it to the state variable Phases.vsPhase in the global assertion (Fig. 10, lines [START_REF] Rauzy | Guarded transition systems: a new states/events formalism for reliability studies[END_REF][START_REF] Xing | Reliability of phased-mission systems[END_REF]. Finally, we make the local assertion depend on the variable vfPhase (Fig. 10, lines 9-13). V. FROM SYSTEM ARCHITECTURES TO SAFETY ANALYSES System architecture is an emerging discipline. It provides a conceptual framework making it possible to merge in a coherent way all of the point of views on a system, and to reason about the system in an accurate way relying on approach by levels of abstraction. System architects apply methodologies that involve the design of models. These methodologies are often called architecture frameworks [START_REF]Systems and software engineering -architecture description[END_REF].

The CESAMES method for systems architecting [START_REF] Krob | CESAM: CESAMES Systems Architecting Method: A Pocket Guide[END_REF] considers three different abstraction levels of a system: the operational level, the functional level and the physical level (see Fig. 11). The operational level is the analysis of the environment of the system. It considers the system (more or less) as a black box and models the interactions of the system with the external systems. The result of the operational analysis is thus a description of the missions of the system, i.e. of the services it provides to its users.

The functional level is an abstract analysis of the inside of the system. It considers the system as a white box and models abstract functions/capacities of the system.

Finally, the physical level is a concrete analysis of the inside of the system. It considers also the system as a white box and models the concrete components of the system, in terms of hardware, sofware and human elements. The physical level describes thus the concrete resources the system involves.

Models produced at the three different levels are strongly connected. The operational level is connected with the two other levels because missions are naturally implemented by functions and by components. The functional level is connected with the physical level because each (abstract) function must be concretely allocated to, or implemented by, some set of physical components. In the reverse way, physical components implement functions which are required by missions.

The CESAMES method for systems architecting proposes five types of SysML diagrams for each abstraction level. They are summarized Table II.

Safety analyses need to gather in the same model operational, functional and physical aspects of the system under study. Typically, the top event of a fault tree represents the loss of a function/capacity, i.e. the incapacity to accomplish a mission, and the basic events represent the failures of physical components.

Nevertheless, the architectural pattern in the previous section can be seen as an implementation of the CESAMES method for systems architecting for the specific case of phased-mission systems, as illustrated Fig. 12. The block "Phase Controller" (block 2), which describes the different phases of the system, belongs to the operational level and corresponds to the lifecycle diagram of the CESAMES method.

The block "System breakdown structure and behavior" (block 1) belongs to the physical abstraction level and corresponds to the physical breakdown structure, which represents the hierarchy of physical components.

The blocks "Phases"(block 3) and "Multiplexer"(block 4) are parts of the functional abstraction level. They correspond to functional interaction diagrams and represent functions (or capacities) provided by the system. Performance indicators (e.g. system reliability) are calculated from the values of the capacities.

Links between different abstraction levels (or different diagrams) are represented by two different means:

• The links between functional and physical levels are carried out by the "aggregation" relation. Phases (or functions) aggregate physical components/resources and define interactions needed to produce the capacity.

• The links between operational and functional levels are implemented by "Flow propagation", also called connections.

VI. EXPERIMENTS

An integrated modeling environment for AltaRica 3.0 (Al-taRica Wizard) is currently under development as joint effort of the OpenAltaRica team at IRT SystemX (Paris, France) and the Norwegian University of Science and Technology. Industrial partners (Airbus, Safran and Thales) support this project. A versatile set of assessment tools has been developed, which includes:

• A stepwise simulator,

• A Fault Tree compiler [START_REF] Prosvirnova | Automated generation of minimal cutsets from altarica 3.0 models[END_REF],

• A Markov chain generator [START_REF] Brameret | Automated generation of partial markov chain from high level descriptions[END_REF],

• A stochastic simulator,

• A sequence generator. AltaRica Wizard [START_REF] Batteux | Altarica wizard: an integrated modeling and simulation environment for altarica 3.0[END_REF] already integrates three calculation engines: a stepwise simulator, a Fault Tree compiler and a stochastic simulator. Phased mission systems can be assessed with the stepwise simulator in order to validate the model and with the stochastic simulator in order to calculate different types of indicators, for example its reliability or mean down time.

First a step by step simulator has been used to play scenarios and to validate the model. Fig. 13 shows an example of the stepwise simulation of the satellite communication system. In the tab "Tree View" the simulator displays the current system configuration: the value of state and flow variables, the enabled transitions and the value of observers. It is possible to fire transitions by double clicking on them in the tab "Tree View". The simulation history is shown in the tab "Sequences". Users can go back to the initial configuration using the "Restart" button and backtrack using the button "Backtrack".

In Fig. 13, in the initial configuration the system is in the phase 1 and it is working (the value of the observer oFailed is false). Then the antenna of the station F1 used in the phase 1 fails (the transition labeled by the event F1.Antenna.evFailure is fired). The system is failed (the value of the observer oFailed becomes true). Then the system goes in the phase 2 (the transition labeled by the event PhaseController.evChangePhase1_2 is fired). The system is working (the value of the observer oFailed becomes false) because in the phase 2 both stations F1 and F2 are used in parallel. And so on.

Second, to calculate the reliability of the satellite communication system, the stochastic simulator has been used [START_REF] Aupetit | Towards a defintion of an evaluation kit for stochastic simulators[END_REF]. It is a versatile tool to assess performance indicators of discrete event systems [START_REF] Zio | The Monte Carlo Simulation Method for System Reliability and Risk Analysis[END_REF]. The principle of stochastic, or Monte-Carlo, simulation is quite simple. It consists in drawing at random a sample of executions of the model, to observe a number of quantities during these executions, and to make statistics on these observations. Quantities to observe depend indeed on the performance indicators one wants to obtain. In AltaRica 3.0, they are defined in two steps. First, one declares observers in the model. These observers can be either symbolic (Boolean or symbolic constants) or numerical (integers or real numbers). In both cases, their values evolve through an execution. Second, one declares indicators, which are elements separated from the AltaRica 3.0 model (they are defined into a separate file). An indicator defines what to measure about the evolution of an observer, i.e. on which quantity to make statistics. It can be for instance:

• the first date at which an observer takes a specified value;

• the number of times an observer takes a specified value during an execution; • the average value of an observer during an execution; etc. Each execution runs from time 0 to a given mission time T . Statistics are indeed made on the values of indicators at time T . It may be interesting to make statistics on their values, at least for some of them, at intermediate times 0 ≤ t 1 < t 2 < . . . < t k < T . For our purpose the mission time is T = 3600h. We define the following Boolean observer observer Boolean oFailed = not vfWorking;

and the associated indicator first-occurrence-date(oFailed, true) defining, for a run, the first date at which the observer oFailed took the value true over the time period [0, 3600].

The stochastic simulator have been parametrized to perform 10 5 histories and to compute the reliability for different mission times. The results are given Fig. 14.

We have also performed a sensitivity analysis. In order to determine the most critical components we have calculated the system mean down time considering each component being failed. The results are presented Fig. 15. These results are not surprising in view of the architecture of the system under study. The most critical components are the components of the main satellite SatR as they cannot be repaired and are used in each phase. The antennas of the stations F1 and F2 are also critical as they are not redundant. There are different ways to improve the overall system availability:

• Use redundant antennas which is costly and sure.

• Improve the antennas' reliability and decrease their mean time to repair.

VII. CONCLUSION

In this article, we proposed an architectural pattern for phased-mission systems. We showed how to implement this pattern in AltaRica 3.0. We applied the proposed modeling pattern to a satellite communication system and calculated its reliability and mean down time using the stochastic simulator developed for the language.

The systematic exploration and design of modeling patterns is at the core of our research projects. It is actually of primary importance, in order to make the modeling process efficient, to reuse as much as possible modeling components within models and between models.

An another important issue is the synchronization of models developed by the different engineering disciplines. With that respect, the connection of systems engineering modeling

Fig. 1 .

 1 Fig. 1. Satellite communication system.

Fig. 2 .

 2 Fig. 2. Phases of the satellite communication system.

1 class 2 4 parameter 7 endFig. 3 .

 12473 Fig. 3. AltaRica 3.0 code representing a non-repairable component.

Fig. 4 .

 4 Fig. 4. AltaRica 3.0 code implementing the satellite subsystem.

5

 5

Fig. 5 .

 5 Fig. 5. AltaRica 3.0 code describing phase 1.

Fig. 6 .

 6 Fig. 6. Architectural pattern for phased-mission systems

Fig. 7 .

 7 Fig. 7. Global view of the satellite communication system model.

Fig. 8 . 16 endFig. 9 .

 8169 Fig. 8. Automaton defining the changes of phases.

Fig. 10 .

 10 Fig. 10. AltaRica 3.0 code implementing conditional connections.

Fig. 11 .

 11 Fig. 11. CESAM systems architecture pyramid.

Fig. 12 .

 12 Fig. 12. The architectural pattern for phased-mission systems view from the perspective of the CESAMES method for systems architecting.

Fig. 13 .

 13 Fig. 13. Stepwise simulation of the satellite communication system

Fig. 15 .

 15 Fig. 15. Sensitivity analysis of the satellite communication system

TABLE I PARAMETERS

 I

	Parameters	Values
	Failure rates	10 -5 h -1
	Repair rates for radars	0.025h -1
	Phase duration	D1 = D3 = 2h, D2 = 1h, D4 = 7h

TABLE II CESAMES

 II SYSTEMS ARCHITECTURE DIAGRAMS.


Michel Batteux

Tatiana Prosvirnova

Antoine Rauzy

ALTARICA WIZARD

Cette communication propose au lecteur une visite guidée de AltaRica Wizard, un nouvel environnement intégré de modélisation et simulation pour AltaRica 3.0. AltaRica 3.0 est un langage de modélisation orienté objet dédié aux analyses probabilistes du risque de systèmes complexes. AltaRica Wizard fourni l'ensemble des fonctionnalités attendues d'un environnement de conception pour un tel langage. Il permet de gérer les modèles AltaRica 3.0 en mode projets, qui rassemblent les différents fichiers source d'un modèle, ainsi que les fichiers de configuration et de résultats issus des outils d'évaluation. Il facilite l'écriture, la modification, la correction et l'évaluation des modèles en fournissant une interface graphique unifiée. AltaRica Wizard est actuellement relié à trois chaînes outillées pour évaluer les modèles AltaRica 3.0 : un simulateur pas-à-pas, un générateur d'arbres de défaillances ainsi qu'un simulateur stochastique.

Introduction

This article invites the reader to a guided tour of AltaRica Wizard, a new integrated modeling and simulation environment for AltaRica 3.0. AltaRica 3.0 is an objectoriented modeling language dedicated to reliability engineering of complex technical systems, see e.g. (Batteux & al. 2018, c) for an introduction. AltaRica 3.0 is a very powerful language, more expressive for example than Figaro (Bouissou & al. 1991), extensions of stochastic Petri nets such as the one implemented in the GRIF tool [START_REF] Signoret | Make your Petri nets understandable: Reliability block diagrams driven Petri nets[END_REF] or AltaRica Data-Flow [START_REF] Boiteau | The AltaRica Data-Flow Language in Use: Assessment of Production Availability of a MultiStates System[END_REF], the previous version of the language. It comes with a versatile set of assessment tools. As of today, AltaRica 3.0 is probably the most advance available technology to perform probabilistic risk and safety analyses.

AltaRica 3.0 models are stochastic discrete event systems. Their design and assessment go through several steps, requiring typically to create auxiliary files describing where the source files are located, what is the chosen mission profile, which performance indicators to calculate, what kind of statistics to get on these indicators, where the result files should be located and so on. AltaRica Wizard aims at simplifying these tasks by providing a unique environment from which everything can be done in a userfriendly way.

The design of AltaRica Wizard is strongly inspired from integrated development environments for programming languages such as Python, C++ or Java. Just as these tools, AltaRica Wizard is designed to maximize analyst productivity by providing tight-knit components with similar user interfaces. It presents a single program in which all modeling and simulation is done. It provides features for authoring, modifying, debugging and assessing AltaRica 3.0 models by means of different technologies.

AltaRica Wizard provides thus the expected functionalities of a code editor: syntax highlighting, management of copy and paste, line numbering and so on. It manages AltaRica 3.0 models into projects that gather the different source files of a model, as well as the files generated by assessment tools. At the time we write these lines, AltaRica Wizard embeds three tool chains to assess AltaRica 3.0 models:  A graphical stepwise simulator, also called stepper.

This tool is used to animate models. It can be seen also as the equivalent of debuggers of programming languages and plays a central role in the validation of models (Batteux & al. 2018, a).  A compiler to fault trees at Open-AltaRica format (Epstein & al 2009). This compiler is chained with the powerful fault tree engine XFTA [START_REF] Rauzy | Anatomy of an Efficient Fault Tree Assessment Engine[END_REF]).  A stochastic simulator. Stochastic simulation is a versatile tool for performance engineering, see e.g. (Zio 2013) A compiler to Markov chains and a generator of critical sequences will be released in the coming months. Both tools are currently under test AltaRica Wizard is designed by the nonprofit AltaRica Association which has the full copyright of the tool. It is developed in C++ using the Qt5 framework by the Qt Company. This makes the development very efficient and the program portable across different platforms (Windows, Linux, MacOS). This choice has some legal consequences the user should know and accept: AltaRica Wizard can be used, free of charge, for any academic or commercial purposes. It is however distributed as is in the hope that it will be useful, but without any warranty of any kind. Assessment tools embedded in AltaRica Wizard are the copyrights of their respective owners. Most of them are either developed at IRT System X, in the framework of the Open-AltaRica project (which is supported by EADS Apsys, Safran and Thales) or by the AltaRica Association. The user is thus invited to check that he or she has all rights to use these tools for the purpose he or she uses them. As of today, and as permitted by the LGLPv3 license of Qt5, AltaRica Wizard is not an open source tool. This situation will last until the AltaRica Association has established with its partners the economic model of AltaRica tools. The mid-term objective is to put in place a dual licensing model, just as the Qt framework.

The contribution of this article is to provide the reader with a snapshot of AltaRica Wizard features. Doing so, it highlights also AltaRica 3.0 expressive power, elegance and simplicity of use. The remainder of this article is organized as follows. The next section gives an overview of the AltaRica 3.0 technology. The following sections present successively each of the assessment tools. Finally, the last section concludes the article and gives some perspectives on the forthcoming developments. Files of a project can be not only AltaRica source files (having usually the extension ".alt"), but also files used to configure assessment tools and result files generated by these tools.

The AltaRica 3.0 Technology at a glance

Projects can be created, populated with folders and files, saved and (re)loaded from AltaRica Wizard. Files and folders of a project are those of the underlying operating system. In particular, the project itself is located into a folder of the underlying operating system. All paths to folders and files are considered relatively to the project folder and the file describing the project is saved into this folder. In this way, projects can be moved from one place to another one just by moving their folder. The same principle applies indeed to project copy: to duplicate a project it suffices to copy the folder that contains this project.

Folders are automatically added to and removed from projects when adding and removing files. This means that a project contains a folder if and only if this folder contains a file of the project (possibly in located in a sub-folder, a sub-sub-folder … of that folder). A contrario, sub-folders of the project folder do not belong automatically to the project. Only those containing a file of the project do.

Projects make it possible to design libraries of reusable modeling components and to assemble them to create models, or simply to split a model into several files so to make it easier to design and to maintain. Projects make also it possible to add to the model files recording reliability data. These contains typically cumulative distribution functions associated with failures of basic components. They may be automatically extracted from reliability data bases.

Authoring and Flattening Process

AltaRica models are authored in the AltaRica Wizard code editor. Figure 2 shows a screenshot of the code editor. This editor is very classical. Its commands (or opening and saving files, for cut and paste...) are the usual one. Its look and feel of the code editor (font type, size and color, syntax highlighting …) can be modifier at will. The first step of all AltaRica 3.0 assessment tools consists in compiling the AltaRica model into a guarded transitions system. The AltaRica model is made of all declarations appearing in all AltaRica files of the current project. A guarded transitions system (GTS) can be seen a "flat" AltaRica model, i.e. a model made of a single block. This is the reason why this compilation process is also called flattening and the compiler a flattener. For efficiency reasons however, guarded transitions systems, as implemented by the AltaRica 3.0 tools, are slightly different from flat AltaRica models. Nevertheless, the flattening process preserves the semantics of the original model. For this reason, the analyst does not need to look at the generated guarded transitions system. We could even have hide it completely. The general philosophy of AltaRica is however to give the analyst access to all intermediate files. This approach makes it possible to introduce intermediate steps performed outside of the AltaRica Wizard environment.

The flattening process serves actually two purposes: first, as the first step of any assessment, it is in charge of checking the model against syntax errors, missing declarations, typing problems and the like. Second, it simplifies greatly the task of assessment tools by instantiating classes, resolving references and so on.

Figure 2. Screenshot of the AltaRica Wizard code editor Assessment Tools

As already said in the introduction, at the time we write these lines, AltaRica Wizard embeds tool chains to assess AltaRica 3.0 models:  A graphical stepwise simulator, also called stepper.  A compiler into fault trees at Open-PSA format.  A stochastic simulator. We shall describe by means of examples the use of each of these tools in the next sections.

Two additional tool chains will be released in the forthcoming months:  A compiler to Markov chains. This compiler produces exact or approximated Markov chains according to the principles defined in reference [START_REF] Brameret | Automated generation of partial Markov chain from high level descriptions[END_REF]. This makes it possible to assess very large model without suffering, at least to some extent, of the combinatorial explosion of the numbers of states and transitions. The Markov chains generated by the compiler are then assessed by means of the XMRK calculation engine. This program is derived from previous work of one of the author [START_REF] Rauzy | An Experimental Study on Six Algorithms to Compute Transient Solutions of Large Markov Systems[END_REF]).  A generator of critical sequences relying of efficient algorithmic techniques, not published yet. This versatile set of tool chains, all implementing state-ofthe-art algorithms, makes it possible:  To use the best suited tool for each analysis purpose. This is of paramount importance as the assessment of probabilistic performance indicators is provably computationally hard, see [START_REF] Rauzy | Notes on Computational Uncertainties in Probabilistic Risk/Safety Assessment[END_REF]

Stepwise Simulation

The stepper, or stepwise simulator, makes it possible to animate AltaRica 3.0 models by firing and backtracking transitions, and looking at the value of variables and observers. For this reason, it is very useful to validate models. It plays actually a very similar role as debuggers such as gbd (Matloff & Salzman 2008) of programming languages. The stepper is a command interpreter. There are commands to print out the value of variables, observers and enabled transitions, to fire a given transition, to undo last the firing, to restart a simulation from scratch, to save and reload as sequence of transition firings and so on.

AltaRica Wizard provides a graphical interface that encapsulates the stepper. This interface makes it easier to browse models and to enter commands (basically, the analyst does not need to remember the syntax of commands). Figure 3 shows a screenshot of this graphical interface.

The central panel of this interface shows a tree-like view of the model. Elements (variables, transitions, observers...) are organized by blocks, sub-blocks, sub-sub-blocks and so on. Values of variables and observers as well as status of transitions are displayed in a clear way. Block items are foldable and expandable so to ease the visualization of large models. Enabled transitions can be fired just by double clicking on the corresponding line.

The currently distributed version of the stepper implements the regular semantics of AltaRica 3.0, except on one point: the current version ignores delays and expectations associated with events and transitions. Consequently, some of the sequences of events that are enabled with the stepper are impossible to fire with other simulation-based tools such as the stochastic simulator. Assume for instance that, at a given step of the simulation, two transitions have their guards satisfied, and are thus enabled. Assume moreover that the events of the first and second transitions are associated respectively with an exponential distribution and a Dirac(0) distribution. Then, according to the temporized semantics of AltaRica 3.0, only the second transition is actually enabled. The stepper allows however to fire both. It is thus up to the analyst to ensure that the sequences of events he or she fires are accepted by the timed semantics of AltaRica 3.0. This inconvenient has been recently solved by introducing an abstract semantics for AltaRica 3.0 (Batteux & al. 2018, a). This abstract semantics verifies that each concrete execution can be simulated by a unique abstract execution and each abstract execution corresponds to at least one concrete execution. The next release of AltaRica Wizard will implement this abstract semantics, making the stepper even more interesting to validate AltaRica 3.0 models.

Figure 3. Screenshot of the AltaRica Wizard Stepper

Compilation into Fault Trees

The compilation into fault trees made the initial success of AltaRica. AltaRica makes it possible reduce the gap between system specifications and safety model. This gap makes safety models hard to share with stakeholders and, even more importantly, to maintain through the life-cycle of systems. Another advantage of AltaRica is that the same model can be used to assess several safety goals. The first efficient algorithm to compile AltaRica Data-Flow models into fault trees has been proposed in reference [START_REF] Rauzy | Modes Automata and their Compilation into Fault Trees[END_REF]. This algorithm has been lifted-up to AltaRica 3.0 models [START_REF] Prosvirnova | Automated generation of Minimal Cutsets from AltaRica 3.0 models[END_REF] and improved recently (Batteux & al. 2018, b).

The idea of the compilation algorithm is to map each sequence of transition firings that goes from the initial state to a failure state onto the conjunction of the events labeling the fired transition. The set of failure sequences is mapped onto the disjunction of these conjunction. Applied directly, this idea would suffer from the combinatorial explosion of the number of a failure sequences. To avoid this problem, the model is split into independent parts, thanks to static analysis techniques. Disjunctions of conjunctions are then calculated locally on each independent part and then assembled into a fault tree.

In general, the resulting fault tree does not look like what a human would have designed, even though minimal cutsets are the same. This is the reason why, visualization of fault tree does not play a fundamental role in the assessment process. On the contrary, browsing minimal cutsets may be of great interest. As of today, we rely usually on the tool "Arbre Analyste" developed by E. Clément [START_REF] Clément | Arbre Analyste : un outil d'arbres de défaillances respectant le standard Open-PSA et utilisant le moteur XFTA[END_REF] to visualize fault trees when needed.

The compiler to fault trees needs only a target file to be ran. It interface is thus minimal. The generated fault tree is generated at the Open-PSA format [START_REF] Epstein | Open-PSA Model Exchange format[END_REF]. This format is read by fault tree assessment tools, including Arbre Analyste, SCRAM, GRIF and XFTA.

AltaRica Wizard proposes a (limited) graphical interface to work with XFTA. A specific dialog makes it possible to create a XFTA command file and then to launch XFTA with this command file. A screenshot of this interface is given Figure 4. This dialog dialog is restricted to relatively simple, although powerful, scenarios:  The top event for the analysis is specified and minimal cutsets are calculated. It is possible to define cutoffs (maximum order and/or minimum probability) for cutsets.  Minimal cutsets can be then printed-out into a file (together with their order, probability and contribution to the top-event probability).

Various calculations of indicators can then be performed from the extract minimal cutsets:  Top event probability and importance factors of basic events at a given mission time.  Sensitivity analysis on the top event probability at a given mission time.  Evolution of the system unavailability (probability of failure on demand), average unavailability and safety integrity levels (for low demand safety systems) throughout a period of time.

 Evolution of the conditional failure intensity, average conditional failure intensity, probability of failure per hour, approximate system reliability and safety integrity levels (for high demand safety systems) throughout a period of time.

The results of these calculations are saved into text files that can be exploited outside of AltaRicaWizard (typically in spreadsheet tools).

Mathematical definitions and calculation algorithms can be found in reference [START_REF] Rauzy | XFTA: an Open-PSA fault-tree engine[END_REF]. The principle of stochastic, or Monte-Carlo, simulation is quite simple. It consists in drawing at random a sample of executions of the model, to observe a number of quantities during these executions, and to make statistics on these observations. To apply this principle, one has to answer the following questions:  What are the quantities to observe and how to define them?  When to observe these quantities?  What kind of statistics should be made on these quantities?  What is good size of the sample so to get sufficiently robust results?

Quantities to observe depend indeed on the performance indicators one wants to obtain. In AltaRica 3.0, they are defined in two steps: first, one declares observers in the model. These observers can be either symbolic (Boolean or symbolic constants) or numerical (integers or real numbers). In both cases, their values evolve through an execution. Second, one declares indicators in the "indicator declaration file" of the stochastic simulator. This file is automatically generated by AltaRica Wizard.

An indicator defines what to measure about the evolution of an observer, i.e. on which quantity to make statistics. Each execution runs from time 0 to a given mission time T. Statistics are indeed made on the values of indicators at time T. It may be interesting to make statistics on their values, at least for some of them, at intermediate times 0  t1 < t2 <... < tk  T. The mission time as well as possible intermediate times are described into the mission description file. This file is automatically generated by AltaRica Wizard. It contains also the number of executions the analyst wants to perform.

Process

Figure 5 shows the AltaRica 3.0 stochastic simulation process.

The first step consists in transforming this model into an equivalent guarded transitions system. This step is achieved by the AltaRica 3.0 flattener. Guarded transitions systems are usually stored in files with extension ``.gts''.

The second step consists in generating a C++ program from the guarded transitions system and the indicator description file. This C++ program is a stochastic simulator specialized for the model and the indicators. This step is achieved by the AltaRica 3.0 stochastic simulator generator. Technically, the indicator description file is a XML file, which usually has the extension ``.idf''.

The third step consists in compiling the C++ file into an executable file. This step is achieved by a public domain portable C++ compiler (in the current version, mingw).

The fourth and last step consists in running the stochastic simulation, i.e. in executing the stochastic simulator. The executable stochastic simulator takes the mission description file as input. Consequently, it is possible to use the same simulator for different missions, i.e. for different number of executions, different mission time and intermediate observation dates. Technically, the mission description file is a XML file, which usually has the extension ``.mdf''.

The AltaRica Wizard integrated modeling environment makes it possible to perform these four steps in a (relatively) transparent way. In particular, the analyst does not have to learn the syntax of indicator and mission description files, nor how to call the different tools involved in the process.

The results of the stochastic simulation can be written out in different formats: a textual format, the ``.csv'' format that eases the loading into a spreadsheet tool and a XML format that eases the loading into a post-treatment tool.

Indicators

They are two types of observers with respect to the definition of indicators:  symbolic observers, which include both Boolean observers and observers taking their value into a finite set of symbolic constants,  and numerical observers, which include both integervalued and real valued observers.

We shall examine them in a row.

Indicators for symbolic observers are actually defined for the observer and a particular value of the observer.

Let O be a symbolic observer and v be a constant of the domain of O. Finally, let t be the time at which the indicator is assessed. The following indicators can be defined for O, v and t. Note that if one is interested in the average time the system spends in a state where the value of a given numerical variable is over a given threshold, then it is possible to define a Boolean observer that describes exactly this situation.

Statistics

The following statistical measures can be obtained on an indicator I after n realizations I1, I2, ... In obtained through n random executions of the model (which statistics should be made on which indicators is described in the indicator description file).  The empirical mean value of the indicator.  The empirical standard-deviation of the indicator.  The empirical 95% confidence range of the indicator.

In addition to the above statistical measures, it is possible to calculate the empirical distribution of the indicator. The idea is as follows.

 Sort the values I1, I2, ... In in increasing order.  Divide the n values into k buckets of nearly equal size. Each bucket contains thus about n/k values (10 or 20 are typical values for k).  Calculate for each of the buckets the minimum, the mean and the maximum values in the bucket.

Note that maximum values of each bucket are the k quantiles of the indicator.

As it is in general not possible to store all of the values, minimum, the mean and the maximum values of buckets are calculated on the fly. This technique gives in general good estimations.

Discussion

The stochastic simulation process described in this section may seem a bit complex at a first glance. However, it is both versatile and efficient:  Available indicators provide a very rich palette of measures that make it possible to characterize a wide set of properties of the system.

 These indicators are defined outside the model which avoid polluting the model with constructs that are not related to the system behavior.  Nevertheless, indicators are stored into description files so to keep track of experimental protocols and to be able to replay them.  Mission profiles are also stored into description files, for the very same reasons.  The stochastic simulation is performed by compiling the AltaRica model into an executable program (for a given set of indicators and via the compilation into GTS, then C++). This makes it extremely efficient. The compilation process itself is efficient as both the AltaRica compiler and the C++ compiler are. Thanks to AltaRica Wizard this process is greatly facilitated and made transparent for the analyst: compilers are installed with the AltaRica Wizard distribution and description files are automatically generated by filling forms through the graphical interface.

Conclusion

The AltaRica 3.0 technology is now mature and ready for industrial deployment. A number of experiments have been performed, showing its efficiency (several publications are on the way). A lot has been achieved the last four years, with eventually relatively limited means: the AltaRica development team never counted more than three members at a time, and none of them was working full time on the project. The sponsoring by Safran of the chair Blériot-Fabre at CentraleSupélec and the support of Apsys, Safran and Thalès to the OpenAltaRica project have been decisive: they simply made the story possible. Of course, the AltaRica 3.0 language specification will probably evolve, the AltaRica Wizard environment will be improved, the assessment tools will be given more possibilities and will be made more efficient in the future. But the core of the technology is here that outperforms already all other implementations of the so-called "modelbased" approach in reliability engineering and system safety.

To conclude this article, we would like to say few words about mention graphical representations of models. There is a debate about this question each time the model-based approach in reliability engineering is discussed. Our experience goes against the tide: we believe that, although graphical representations are very useful as communication mean, pure graphical modeling is counterproductive in most of the cases. Analysts spend eventually more time in making their drawing "elegant" than in thinking about the system they are studying and the mathematical object they are designing, namely the model. If the system under study is complex, models of this system must be complex as well, or at least simplex in the sense given to this term by Berthoz [START_REF] Berthoz | Simplexity: Simplifying Principles for a Complex World[END_REF]. In a word, complexity cannot vanish. Modeling is not a magic wand. But as soon a model gets complex, it is not possible to represent it fully graphically. Models are mathematical artifacts. Complex models are complex mathematical artifacts which are better represented by texts. With that respect, we must draw lessons from decades of software engineering: all attempts to design graphical programming languages failed, but for pedagogical purposes (e.g. the Scratch language from the MIT). Drawings are definitely useful to understand the global architecture of a program, but the code remains the ultimate reference. Moreover, drawings (such as UML class diagrams) are never more useful than when they are automatically generated from the code (and not the reverse). We strongly believe that models engineering will follow the same path. At the end of the day, mankind invented writing because drawing was not sufficient to transmit complex thoughts.

Figure 1

 1 Figure1gives a global picture of the AltaRica 3.0 technology, as of today.

Figure 1 .

 1 Figure 1. The AltaRica 3.0 Technology at a glance

Figure

  Figure 4. Screenshot of the XFTA interface Stochastic Simulation

Figure 5 .

 5 Figure 5. The AltaRica 3.0 stochastic simulation process