AltaRica

The design of AltaRica started at the end of the nineties at the computer science department of Bordeaux University (LaBRI). The rationale for the creation of a new modeling language was to overcome difficulties encountered by safety analysts (in avionic, nuclear, automotive and oil and gas industries) with "classical" modeling formalisms such as fault trees, Markov chains or stochastic Petri nets. These formalisms lack actually either of expressive power, or of structuring constructs, or both. The first scientific articles.[1][2][3][4] about the language were published from 1998 to 2008.[5][6][7] The original version of the language relied of three technologies: finite state automata that were extensively studied by the LaBRI's team working of the formal methods for software verification,[8] structured programming taking inspiration of the modeling language Lustre, and constraint programming.[9] This last technology, though elegant and powerful, proved inefficient in practice. Constraint resolution was too computationally expensive to scale on industrial size systems. The LaBRI team went on working however on this original version, mainly for educational purposes, improving tools over the years.[10][11][12][13] A first turn has been therefore taken with the design of a data-flow version of the language.[14][15] In AltaRica data-flow, variables are updated by propagating values in a fixed order. This order is determined at compile time, from the annotations given in the model. AltaRica Data-Flow raised a significant academic and industrial interest. Integrated modeling environments have been developed for the language: Cecilia OCAS by Dassault Aviation, Simfia v2 by Airbus-Apsys and Safety Designer by Dassault Systèmes (this latter tool was initially a clone of Cecilia OCAS, but evolved separately afterward). Successful industrial applications have been realized.[16][17][18][19] For example, AltaRica Data-Flow was used to certify the flight control system of the aircraft Falcon 7X (Dassault Aviation). A number of PhD theses were also dedicated to the language and its use in various contexts.[20][21][22][23][24][25][26][27] In a word, AltaRica Data-Flow reached scientific and industrial maturity. It is still daily used for a wide variety of applications.

Experience showed however that AltaRica Data-Flow could be improved in several ways, hence justifying to seriously rework the language. This rework gave eventually raise to AltaRica 3.0[28][29] which improves AltaRica Data-Flow into several directions. The syntax of AltaRica 3.0 is closer to Modelica than to AltaRica data-flow, so to facilitate bridges between multiphysics modeling and simulation and probabilistic risk and safety analyses. Object-oriented and prototype-oriented structuring constructs have been assembled so to give the language a versatile and coherent set of structuring constructs, via S2ML (for System Structure Modeling Language), which is probably the most complete of all existing behavioral modeling languages. Moreover, AltaRica 3.0 semantics has been reinforced, via GTS (for Guarded Transition Systems), which opens new opportunities in terms of assessment of models.

Guarded transition systems belong to the family of mathematical models of computation gathered under the generic term of (stochastic) finite-state machines or (stochastic) finite-state automata. They have been introduced in 2008[30] and later refined[31]

To illustrate the ideas behind guarded transition systems, consider a motor pump that is normally in stand-by, that can be started on demand and stopped when there is no more demand. Assume moreover that this pump may fail in operation, with a certain failure rate λ, and that it can also fail on-demand with a certain probability γ, Assume finally that the pump can be repaired, with a certain mean time to repair τ.

We can then represent the behavior of this pump by means of a (stochastic) finite state automaton pictured hereafter.

Model of a motor operated pump

From outside, the motor pump can be seen as a black box with an input flow of liquid "in", an input flow of information "demand" and an output flow of liquid "out", i.e. as a transfer function that given the values "in" and "demand" calculates the value "out". In the framework on reliability studies, the behavior of systems must be abstracted out to avoid the combinatorial explosion of situations to look at. Flows are thus typically abstracted as Boolean values, true interpreted as the presence of the flow and false as its absence.

The equation linking "in" and "demand" to "out" cannot be written directly since the motor pump has an internal state. Namely, we can consider that the pump can be in three states: "STANDBY", "WORKING" or "FAILED". On the figure before, states are represented as rounded rectangle. The output flow "out" takes the value true if and only if the pump is working and the input flow "in" is true (hence the equation on the right hand side of the figure above).

A fundamental abstraction made by finite state automata consists in considering that the system under study can change of state only under the occurrence of an event. In between two occurrences of events, nothing changes. Occurrences of events are described by means of transitions, represented as arrows on the figure. In guarded transition systems, a transition is labeled with an event, has a certain pre-condition called the guard of the transition and a certain effect called the action of the transition. For instance, the event "failure" can only occur in the state "WORKING". Its effect is to make the pump pass from this state "WORKING" to the state "FAILED". The event "start" can occur if the pump is in the state "STANDBY" and if the input flow "demand" is true. Its effect is to make the pump pass from the state "STANDBY" to the state "WORKING". And so on.

Now, some changes of states may take time, while some other happen as soon as they are possible. For instance, a failure takes a certain time before occurring, while the pump is started as soon as needed (at least at the level of abstraction of reliability models). Guarded transition systems associate delays with events, and thus transitions. These delays can be either deterministic as for the event "start", or stochastic as for the event "failure". On the figure, deterministic delays are represented by dashed arrows while stochastic ones are represented by plain arrows.

To finish, transitions can be in competition in a state. For instance, the transition "stop" is in competition with the transition "failure" in the state "WORKING". This competition is however not a real one as the transition "stop" is immediately fired (performed) when the input flow "demand" ceases to be true. A real competition occurs between the transitions "start" and "failureOnDemand" in the state "STANDBY". Both are fired immediately when the input flow "demand" becomes true. In guarded transition systems, it is possible to associate a probability of occurrence to each transition in competition, namely γ to "failureOnDemand" and ${\displaystyle 1-\gamma }$ to "start" in our example.

Eventually, the AltaRica code for the guarded transition system we sketched is given in the Figure hereafter. The motor pump is represented as a "block", i.e. as a container for basic elements. The block declares four variables: a state variable "_state" that takes its value in the domain (set of symbolic constants) "MotorPumpState", and three Boolean flow variables "demand", "in", and "out". Initially, "_state" takes the value "STANDBY". The transfer function is represented by means of the assertion. Assertions tell how to calculate the values of output flow variables from the values of input flow variables and the values of state variables.

domain MotorPumpState {STANDBY, WORKING, FAILED}

block MotorPump
	MotorPumpState _state (init = STANDBY);
	Boolean demand, in, out (reset = false);
	event start (delay = Dirac(0), expectation=gamma);
	event failureOnDemand (delay = Dirac(0), expectation=1-gamma);
	event stop (delay = Dirac(0));
	event failure (delay = exponential(lambda));
	event repair (delay = exponential(1/tau));
	parameter Real lambda = 1.0e-4;
	parameter Real tau = 8;
	parameter Real gamma = 0.02;
	transition
		start: demand and _state==STANDBY -> _state := WORKING;
		failureOnDemand: demand and _state==STANDBY -> _state := FAILED;
		stop: not demand and _state==WORKING -> _state := STANDBY;
		failure: _state==WORKING -> _state := FAILED;
		repair: _state==FAILED -> _state := STANDBY;
	assertion
		out := in and _state==WORKING;
end

The block "MotorPump" declares also five events and as many transitions. Guards of transitions are Boolean conditions on state and flow variables. Actions of transitions modify the values of state variables. Events are associated with delays and possibly expectations (which are used to calculate probabilities of occurrence of transitions in competition). The description of both delays and expectations may involve parameters.

In general, systems under study are not made of a single, simple components as the above motor operated pump. Rather, they consists of a network of such components that interact in an organized in a hierarchical way.

To reflect the architecture of the system in the model, one needs dedicated constructs. This is where S2ML (system structure modeling language) comes into the play. S2ML emerged first as the set of structuring constructs for AltaRica 3.0. Then, it has been studied on its own.[32][33] As of today, S2ML gathers in a coherent way a versatile set of structuring constructs stemmed from object-oriented and prototype-oriented programming.[34][35]

S2ML consists of height key concepts: the concepts of port, connection, container, prototype, class, cloning, instantiation, inheritance and aggregation.

Ports

They are basic modeling elements such as domains, state and flow variables, events and parameters.

Connections

They are relations amongst ports such as definitions of domains, probability distributions associated with state variables, definitions of parameters, transitions and assertions.

Containers

They gather declarations of ports and connections as well as of other containers forming nested hierarchies. The block describing the motor pump is such a container.

Prototype and cloning

Prototypes are individual containers. In AltaRica, blocks are prototypes. When the system under study contains two or more similar parts, it would be both tedious and error prone to duplicate the code. Cloning provides a solution to this problem: the first part is described, then the others are just obtained by cloning the first one. The dot notation makes it possible to access to ports declared in nested blocks, as illustrated by the assertion in the above code.

block System
	// ...
	block Line1
		// description of line 1
	end
	clones Line1 as Line2;
	// ...
	assertion
		out := Line1.out or Line2.out;
end

class MotorPump
	// description of the motor pump.
end

block System
	// ...
	MotorPump P1; // 1st instance
	MotorPump P2; // 2nd instance
	// ...
end

Classes and instances

It is often the case that some modeling components are reused from model to model. It is then possible to create libraries of on-the-shelf modeling components and to instantiate them into model. Classes are used for this purpose. They are just containers (or prototypes) defined outside the model. Instances of classes, also called objects, are clones of these containers defined outside the model.

Inheritance

It is the mechanism by which one specializes modeling component. If a derived component D inherits from a base component B, all modeling elements of B are reproduced in D. D may declare additional ports, connections and containers.

Aggregation

Cloning and instantiation create components inside components. The inner component is part of the outer one. There are cases however where a component is used by another one, without being part of this component. This mechanism is reflected into model by a mechanism called aggregation. Aggregation is extremely useful to project a functional architecture onto a physical one, and to represent so-called functional chains[36]

AltaRica 3.0 involves a few other constructs, such as a powerful mechanism to synchronize events. The essential has however been presented above.

Adding S2ML on top of a mathematical framework (GTS in the case of AltaRica), makes it possible to pass automatically and at no cost from the model as designed, which reflects the architecture of the system under study, to the model as assessed from which calculations of indicators and simulations can be performed efficiently.

The transformation preserves the semantics of the models and is reversible for the most part: results of calculations and simulations are directly interpretable in the model as designed.

A recent trend in the AltaRica community is the design of modeling patterns.[37] Patterns are pervasive in engineering. They have been developed for instance in the field of technical system architecture,[38] as well as in software engineering.[39] They are useful in reliability engineering also, as they ease design and maintenance of models. They are also a tool for risk analysts to communicate about the models they develop and share.

In industrial practice, AltaRica model uses include four main functions:

• Develop a common understanding among stakeholders about how a system works and may fail
• Ensure that the system under study is safe enough to operate
• Optimize maintenance policies
• Assess the average production (or loss of production) of units subject to failure, malfunction, or human error

As these applications require different types of simulations and calculations, several tools have been developed, including:

• Stepwise simulators that interactively play scenarios of evolution
• Compilers that lower level modeling formalisms, primarily fault trees but also Markov chains, to benefit of existing efficient assessment algorithms
• Stochastic simulators that calculate a wide range of risk indicators
• Sequence generators and model-checkers that validate models and extract critical failure scenarios

• Official website