AltaRica

AltaRica is an object-oriented modeling language dedicated to probabilistic risk and safety analyses. It is a representative of the so-called model-based approach in engineering. Since its version 3.0, it is developed by the non-profit AltaRica Association, which develops jointly the associated modeling environment AltaRica Wizard.
History.
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 , or . These formalisms lack actually either of expressive power, or of structuring constructs, or both. The first scientific articles. about the language were published from 1998 to 2008. 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, structured programming taking inspiration of the modeling language Lustre, and constraint programming. 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. A first turn has been therefore taken with the design of a data-flow version of the language. 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. 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. 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 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.
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 and later refined
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.
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 formula_1 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.
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 -&gt; _state := WORKING;
 failureOnDemand: demand and _state==STANDBY -&gt; _state := FAILED;
 stop: not demand and _state==WORKING -&gt; _state := STANDBY;
 failure: _state==WORKING -&gt; _state := FAILED;
 repair: _state==FAILED -&gt; _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.
System Structure Modeling Language.
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. As of today, S2ML gathers in a coherent way a versatile set of structuring constructs stemmed from object-oriented and prototype-oriented programming.
S2ML consists of height key concepts: the concepts of port, connection, container, prototype, class, cloning, instantiation, inheritance and aggregation.
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
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. Patterns are pervasive in engineering. They have been developed for instance in the field of technical system architecture, as well as in software engineering. 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.
Tooling and applications.
In industrial practice, AltaRica model uses include four main functions:
As these applications require different types of simulations and calculations, several tools have been developed, including: