Towards a Model Level Replication Technique for Fault Tolerant Systems Using AADL

Towards a Model Level Replication Technique for Fault Tolerant Systems Using AADL Abstract—The replication, a technique widely used for fault tolerance purposes, is defined as the redundancy of software, hardware or both units and their consideration in the execution of the application. In this paper, we propose a new technique to design replication using the AADL language and its extensibility with property sets. We choose AADL to take advantage of its strong semantics at architecture level. We enable the designer to model his application using AADL and to enrich it with the property set Replication_Properties. We defined this property set to describe the adopted concepts of replication. Then, based on a set of transformation rules, we generate an intermediate AADL model enriched with different replicas. Currently, we are extending the Ocarina tool suite to support automatic generation of the target model. Keywords—Fault tolerance, modeling, replication, AADL, transformation rules, real-time systems. I. I NTRODUCTION As the real-time critical systems are more and more complex and evolved, new requirements for high dependability, fault tolerance and error recovery emerge. To cope with this evolution, researchers focus on how to guarantee the dependability of such systems since the design level. The dependability is defined as the ability to deliver a service that can be justifiably trusted. There are several means to ensure dependability such as fault tolerance which is defined as the capability of a system to continue providing services even in the presence of errors [1]. A widely used technique to achieve fault tolerance is the replication [9]. This technique involves repetition and multiplicity of different or symetric components or treatments. It consists on considering multiple copies of a software or hardware component and deploying them on different nodes in order to avoid the failure of the system. Thus, critical hardware or software components, or even entire systems, are replicated. Three main replication techniques are distinguished in the literature [9]: 1) Active replication: All replicas have the same inputs, keeping their internal state synchronised and voting all on the same outputs. In this case, we must have a voting algorithm to choose one between all the outputs. 2) Passive or primary-backup replication: Only one replica, called primary copy, can ensure the inputs treatment. When the primary copy fails, one of the others, called backup copies, is elected to take its place to provide the same functionality. 3) Semi-Active replication: Similar to the active one, all replicas receive the same inputs and can thus treat them. However, similar to the passive replication, there is a privileged copy (the primary) responsible for taking decisions without needing a consensus algorithm to vote between replicas. There are several work aiming at modeling or implementing fault tolerance techniques based on replication. In our context, we deal with active and passive replication of both hardware and software components. We have chosen AADL (Architecture Analysis & Design Language) [10], as an architecture description language, to model fault tolerant real-time dynamically reconfigurable systems. At the design level, as for replication modeling, existing approaches were consisting on manual and explicit redundancy by replicating components, connections and behaviors of AADL components. In the case of a very important number of replicated components or even replicas number, this may cause on one hand the risk of errors and the loss of design time on the other hand. Besides, both the design and the implementation of the software systems are no longer focusing only on functional concerns but also on crosscutting ones. To solve this problem, we propose in this paper our approach, based on model transformation, to allow us to enrich an AADL model by replication concepts. Our contribution consists on proposing a new technique to design replication using the properties extension provided by AADL in three steps. The first consists on defining and validating the core model of the system using AADL. This model can be expanded with annexes or properties to have finally the AADL model application. The second step consits on enriching this model with properties declared within our defined property set, to describe the desired replication mechanism. In fact, we defined Replication_Properties as a property set that contains a list of property definitions. These properties describe the adopted replication concepts such as the replication style and the number of replicas. Then, they are applied to AADL specification in order to design the replication of some AADL components at model level. The final step consists of applying a list of transformation rules to reach an expanded AADL model containing the different replicas. Thus, this approach takes advantage of the extensions provided by the AADL language. It guarantees reducing the complexity of fault tolerant system and gaining the design time based on the separation of concerns and the automatic model transformation. The three steps will be detailed in the remainder of this paper which is organized as follows: in section II, we present an overview of the AADL language. Then, we detail the basic concepts of software and hardware FT techniques. Then we review some related work in section III. After that, we briefly describe our global approach in section IV to design both active and passive replication with the property set detailed in section V. Section VI describes the established transformation rules. Then, we illustrate the use of our approach by a case study in section VII. Finally, section VIII concludes this paper and gives future work. II. BACKGROUND This section presents an overview about the AADL language. Then, it introduces the basic concepts of software fault tolerance. A. Introduction to the AADL language AADL is a standard consisting of both textual and graphical representations with precise execution semantics for embedded software systems. AADL is a typed language providing formal modeling concepts to design the runtime architectures of complex systems and the mapping of software components onto hardware ones through interfaces. This standard defines several categories of components grouped into three subsets: 1) Software components including process, thread, data, and subprogram components. They may have associated source text specified using property associations. In order to obtain a binary executable image, software source text, coded either in a very-high-level or domain-specific language or in a traditional programming language, can be processed by source text tools. 2) Hardware or execution platform components including device, bus, memory, and processor components. They represent computing hardware components. 3) Composite component including only the system component. It represents a composition of software, execution platform, or other system components. System modeling reflects a structure of interacting components organized into a hierarchy. All hardware, software or composite AADL components of an AADL model correspond to concrete entities that is why AADL is a concrete language. Each of these components can be connected to others through features. These features contain event and data ports, subprogram access, data access and bus access, among others. Moreover, AADL can be also used to describe the dynamic behavior of the runtime architecture due to its modes and mode transitions. A mode represents an operational mode state, which manifests itself as an execution platform or an application system configuration. A mode transition consists on changing the system to a different configuration triggered by an event or an event data on ports named in a mode transition or an event raised by the component itself. Finally, this language can be extended with either properties or annexes. An AADL property provides descriptive information about model entities such as component types, component implementations or subcomponents through a named grouping of property declarations known as property set. Thus, AADL offers the possibility to define new properties and property types that can be included in an AADL specification. Therefore, the declaration and use of properties become part of the specification unlike to annexes. Annexes libraries enable a designer to extend and customize the AADL core specification with other concepts specified in a language other than AADL. We can for example enrich an AADL specification with the AADL Error Model annex [11] to specify fault tolerance requirements for core components like propagation. B. Software Fault Tolerance Fault tolerance [1], one of the different means of dependability, is defined as the capability of a system to continue providing offered services even in the presence of errors. Fault tolerance, together with the other means of dependability, address all similar threats that are faults, errors and failures. A fault is a physical hardware or software defect causing service degradation. An error is an incorrect value causing a system failure. A failure manifestes a deviation of the system relative to its specification. The error propagation is a major risk for dependability, in particular fault tolerance. In fact, an error is the manifestation of the fault on the system. When an error is propagated to the service interface and deviates the service from its correct specification, a service failure occurs as a result. The service failure can cause in turn the failure of the whole system. In order to avoid it, software and hardware fault tolerance are accomplished through the following techniques: 1) Error detection : consists on detecting error occurrence. It is either concomitant or preemptive. 2) System recovery : consists on replacing the erroneous state of the system by another safe state. This technique is based on two mechanisms: • • Error handling, eliminates errors from the state of the system. This is using one of the following techniques or combining some of them in particular situations. The first one, called Rollback recovery, turns up the erroneous state of the system to an earlier saved state. The second, called Rollforward recovery moves the system to a new steady state in order to correct it. The last one is the compensation that provides from the beginning enough redundancy of the system to be able to mask erroneous states. Fault handling, prevents the activation of fault once more. This can be achieved by various ways such as diagnosis, isolation, reconfiguration and reinitialization. III. R ELATED W ORK The literature about fault tolerance techniques used to handle software faults is fairly vast. For example, the authors of [3] gave a survey of software techniques to handle software faults developed in the fault tolerance and the autonomic computing domains. As these techniques are all practically exploiting some form of redundancy, they considered the impact of replication on the software architecture. After that, in order to compare and classify techniques to handle software faults, they proposed a taxonomy based on the nature and use of redundancy in such systems. Authors in [4] applied redundancy patterns in the architecture design level using Aspect Oriented Paradigm. They focused on the weaving of an original (non-redundant) architecture model with redundancy related design patterns. This approach aims at seperating functional and non-functional design. The base model is designed using UML. Then, an aspect model is integrated within the base one using a model weaver. Thus, reusable fault tolerance and redundancy management mechanisms together with their specific analysis sub-models were available in the form of a design pattern library. Based also on UML designs, authors in [2] propose MARTE-DAM : a profile to support the dependability modeling and quantitative analysis. Unlike several works aiming at extending UML models with dependability annotations, this profile covers different dependability aspects through rich domain models. The defined domain conepts are then mapped to elements of the UML profile. In particular, a redundancy model introduces fault tolerant components which can provide a redundant structure such as variants, deciders (adjudicators), and FT strategies. For performance and dependability analysis and assessment purposes, authors translated the annotated MARTE-DAM into Deterministic and Stochastic Petri Nets (DSPN) models. Even if authors have been proposed the model refinement and dependability assessment, they did not support code generation for MARTE-DAM. In [8], authors proposed an approach to model and to formally verify replication patterns in the AADL language and then analyze potentially unintended behaviors. This approach is based on designing two AADL models. The first defines the intended behavior in synchronous call sequences and the second describes the replication architecture. A primarybackup replication approach is designed using AADL based on modes and mode transitions. Authors propose two replicas: one primary and one backup. The transitions between primary and backup modes is triggered with an event port. The latter is then connected to a transition controller unit that represents either the human operator or the failure detection module. In [7], authors gave an example of a primary-backup replication strategy designed with AADL and its behavioral Annex (AADL-BA). They modeled the core system using AADL components and their connections through features. Threads in this case are synchronised using dispatched events. Then, based on AADL-BA, they modeled the automaton showing different states where the application can be blocked to describe the executed call sequences of different threads. They proved also that AADL-BA provides an interesting additional strategy to define critical regions. This work difficulties reside in the design of complex synchronization mechanisms commonly used in distributed system design such as mutual exclusion. Besides, designers who applied this approach must specify both their core system and the replication pattern manually. There are no automatic tasks to help them generating consistent model. The main difference between the reviewed approaches above and our own is the focus on: (i) the two replication styles, active and passive one, using the same concepts based on extending the core model with AADL property set (ii) the automatic code generation of the enriched AADL model following a set of model transformation rules. That is they proposed manual extension of their model integrating active or primary-backup replication style but not both. Also they do not take into consideration the automatic code generation of replication mechanisms. (iii) the seperation of functional and non-functional design as the fault tolerance requirements are specified seperately by property set. IV. P ROPOSED APPROACH As we have already mentioned, we choose AADL [10] to model fault tolerant real-time dynamically reconfigurable systems. This is for all reasons quoted in section II-A. We used AADL to design not only functional concerns but also crosscutting ones using its different annexes. We decided to use the AADL standard annex E: Error Model Annex [11] to integrate fault tolerant requirements since the design level. In fact, this annex lets us design all types of faults, fault behavior, fault propagation, fault detection and also fault recovery mechanisms. Despite its support of several concepts related to fault tolerance and more generally dependability, this annex does not support the design of replication techniques. It consists of manual redundancy of AADL components, connections and also behaviors. However, the more the replicas or the replicated component are, the more complex and error prone the model is. For that, we decided to propose our own approach in order to help the designer modeling the fault tolerant system easier with integrating replication techniques. Our approach takes advantage of the possible extensions of AADL using property sets and annexes. To integrate the model of replication techniques since the design level, we decided to enrich the basic AADL model by a property set that we defined and baptised Replication_Properties. It has a set of property declarations and property types describing the adopted replication mechanism as detailed in section V. For that, we propose a model driven approach based on AADL model transformation as shown in figure 1. Our approach consists on three steps. We start from a basic (non-redundant) AADL specification model describing an embedded real-time system. We offer the possibility to the designer to enhance his model by predefined part of an AADL specification into Ada, C, or Real Time Java. Once the intermediate model is generated and validated, Ocarina tool suite allows us to generate functional concerns into Ada as it is well adapted to implement real-time embedded systems. For compliance reasons, to generate crosscutting concerns code, we selected AspectAda [5] language. This separation of concerns is aiming at guaranteeing better code quality and modularity. It also allows to simplify the validation of either model or code application without effecting each other. Thereby, we can either ensure model analysis or verification of the generated AADL resulting model or generate its corresponding application code (into Ada , C or RTSJ) or re-enriching it again by the Replication_Properties applied to another component as mentioned in figure 1. Fig. 1. V. D ESCRIPTION OF OUR PROPERTY SET Replication design process properties and annexes. For example, the designer extends his model by clauses from the Error Model Annex for fault tolerance purposes. After that, the designer enriches his AADL model by some properties related to the replication strategies through our property set Replication_Properties. After specifying all properties, we validate them before generating automatically an intermediate AADL model enriched with different replicas and deciders. The application of the replication techniques may violate real-time constraints or the original model properties like scheduling or access rights to shared data. Furthermore, if a replicated component of the model is enriched by properties or annexes, then all replicas should inherit them. For example, replicated components may be enriched with the Error Model Annex to model detected and propagated errors and their behaviors in case of errors. So, if a thread is at the same time a replication object and has a particular behavior in case of detected errors, then all generated threads should have the same behavior if the same error is detected. Thus, the replicas are enriched also with the same annex as well as the replicated one. For this, we defined a set of transformation rules to govern the model generation process to map between the basic AADL model and its extended version with replication concepts. It concerns the generation of either new components (like replicas and deciders) or connections between original and generated ones. It ensures also the treatment of the behaviors of the replicas and the decider. These rules are first established manually and then translated into some algorithms implemented from scratch to ensure model transformation. We implemented these rules as an extension of the Ocarina tool suite [13] for these reasons. Ocarina is used to manipulate AADL models. It ensures their syntactic and semantic analysis. In addition, this tool supports scheduling analysis of AADL model with Cheddar [12]. Besides, it offers formal model generation from AADL models with Petri nets. Finally, it allows to generate the code corresponding to the functional In the previous section, we have described our approach based on the extension of an AADL model with the Replication_Properties property set to enrich it by replication concepts. It contains several properties describing with details the adopted replication mechanism. In this section, we list and explain properties specifically defined for replication purposes. A. Replication context description To describe the context of replication, we defined a property baptised Description. The designer gives details about the purpose of replication, its manner or its requirements. Since this property provides information about the context of replication without any impact on the replication policies, it will be generated as a comment. It is to contribute to the documentation of the generated intermediate model helping the designer understand it. B. Number of replicas Using our approach, a single model can support several replicated components. To set the number of replicas that we desire model, we defined a property named Replica_Number applied to a given replicated component. This property is set by the designer and corresponds exactly to the number of replicated components at the generated model level. According to [6], the number of replicas (variants) depends not only on the FT strategy (RB1 , NSCP2 or NVP3 )but also on the number and the nature (soft or solid) of faults to be tolerated. Thus, we decided to bound the number of replicas through two parametrized constants, Min_Nbr_Replica and Max_Nbr_Replica, which define respectively the minimal and the maximal number of replicas in the application. In order to give more flexibility to our approach, both constants can be changed by the designer when using our property set. 1 Recovery Block Self-Checking Programming 3 N Version Programming 2N C. Identifiers of replicas In order to identify each of the generated replicas, we defined a property named Replica_Identifiers composed of a list of string. Each represents an identifier of a generated replica. D. Replication style As said above, we are interested in our context to active and passive replication of both hardware and software components. For that, we have defined a property type called Replication_Types to describe the adopted style of replication. Such a property specifies the associated replication type to a given replicated component. The replication style is then set by the defined property named Replica_Type. The value of this property may be either ACTIVE or PASSIVE. There is no default value for such a property: if this property is not specified, the replication type is undefined and an error is raised to the designer. E. Consensus algorithm The consensus (or agreement) algorithm is required in two cases related to the replication style. The first is to elect a new primary copy in case of failure of the current from one or more secondary copies in the context of passive replication. The second is to vote between the different replicas in the context of active replication. In both cases, this algorithm can be described via an AADL subprogram component. The implementation of an AADL subprogram is supplied by the user as an external file written with another language like Ada or C, or as an element of the AADL model itself executed by a thread. In order to refer to elements of the AADL model itself, AADL defines two kinds of property types: the classifier and the reference. For that, to cover all possible cases, we have defined 3 properties: Consensus_Algorithm_Source_Text, Consensus_Algorithm_Class and Consensus_Algorithm_Ref. These three properties are applied to different kinds of components. They can be applied to features (ports or data access) in the case of active replication of either software or hardware components. In case of active replication, to make decision about same outputs from several replicated components, we apply the consensus algorithm to these features. In case of passive replication, the property describing consensus algorithm must be applied to the replicated component as it is an election algorithm for the decision about the choice of primary copy. There are no default values for all these properties: if one of them is not specified for a given replicated component, the replication extension is not performed and an error is raised to the designer. All of these properties contained in the property set Replication_Properties were validated by the Ocarina tool suite. Considering it as an AADL specification, this property set was parsed successfully. It was then validated using a set of AADL model examples. In the following, we present a set of transformation rules illustrated by some examples. Some proofs of validation are given and other less important are omitted due to the lack of space 4 . VI. M ODEL T RANSFORMATION As noted previously, we propose in this work the extension of AADL with replication concepts. In the first step, the designer specifies his architectural model. The conceived model is then enriched by a set of properties that we defined in the previous section. After that, based on defined transformation rules, we generate automatically an intermediate AADL model extended with replicas and decider specification. It consists on a direct-manipulation M2M transformation to integrate replication policies to the initial simple model in order to save effort and reduce errors. Based on automatic generation, we aim at applying a set of transformation rules to get a new enriched model that has to be itself consistent and coherent. The transformation rules, to map the replication concepts into the enriched AADL model, depend on various constraints described in the following subsections. A. Replicated AADL component subset The replication of software component is quite different from hardware or hybrid components. This difference is due to the containment hierarchy of these components and then the possible connections that can be established, the modes clauses that can be or cannot be declared and finally the conjunction with the decider regarding the AADL hierarchy. In addition, by FT communities (for example in [6]), software and hardware fault tolerance architectures and even implementations are not similarly applicable. For that, we have studied the possibility of replication for each type of component. We support the replication of threads and processes as software components and processors, devices as hardware components. We support also the replication of the component system. We do not support the replication of data and subprogram components as we require in this case to apply diversity concepts and not replication ones [3]. In fact, the diversity aims at providing the same service through a distinct model and implementation. Replication of identical subprograms does not guarantee better reliability from the treatment viewpoint. For that, we have applied the property declarations defined in the Replication_Properties property set into only a subset of the AADL components that we find necessary and consistent. B. Replication Type The generation of the AADL model enriched by replicas strongly depends on the type of replication defined by the property Replication_Properties::Replica_Type. 4 More details about the Replication_Properties property set, the transformation algorithms and the case study are available at http://goo.gl/ EEQhLK Replicated Component Type Thread Software Process Hardware or Hybrid Generated voter - Thread. - Located at the same containment hierarchy of the replicated component (process). - Calls the voter subprogram. - Process. - Located at the same containment hierarchy of the replicated component (system). - If not specified, runs on the same processor of the original replica. - Contains itself one voter thread calling the voter subprogram. - Thread. - The voter must be generated inside a software component to be executed. For that, we have to follow the routing connections starting from each feature of the replicated component until reaching the process to which it is linked. TABLE I G ENERATED VOTER DEPENDING ON THE REPLICATED COMPONENT TYPE The adopted replication policies are not the same in the case of active or passive replication. • Active Replication: The generated model contains Replica_Number replicas generated inside the same containment hierarchy of the replicated component. Each of them is then connected directly or remotely to a generated or called decider (voter in this case) depending on the property used to specify the consensus algorithm and the type of the replicated component. This replication type distinguishes between software, hardware and system component. • Primary-backup Replication: Unlike active replication, passive one does not distinguish between the different possible types of replication component object. This type of replication, based on the migration between two or more configurations, imposes the generation of Replica_Number identical components supporting the dynamic reconfiguration to obey the adaptation needs. To do this, we decided to use the concepts of modes and mode transitions provided by the AADL standard to describe the dynamic behavior of the runtime architecture. Therefore, it is necessary to establish the suitable reconfiguration constraints, responsible of switching between modes, to guarantee that mode transition always bring us to a new safe mode. C. Features of the replicated component The type of features (ports, data access or subprogram access) affects the assumed replication policies. For each feature of replicated component of type in out or out port or data access, we specify its correspondent voter subprogram. That means that the consensus algorithm property is applied to each feature of the replicated component and not to the component itself in the case of active replication unlike the passive replication. D. Consensus algorithm The property describing the consensus algorithm has a significant impact on the generated model. The different proper- ties, described in section V-E, support several configurations of the decider. So, such a property specifies the way that connects replicas to voter even by remote connection in the case of hardware component. For that, we conducted a depth study aiming at discussing all possible cases of active replication of AADL components to tolerate both software and hardware faults. The description of the consensus algorithm is set through one of the three properties that we have already defined. This property, applied to the replicated component to each of its features, is then transformed to an AADL subprogram. To be executed, this subprogram must be called by an existent or a generated thread located itself in a process component. For that, we consider the following different cases summarized in table I. Currently, we are implementing the different transformation algorithms as an extension of the Ocarina tool suite to support replication mechanisms. VII. C ASE S TUDY To validate our approach, we describe in this section an example of a simple AADL specification we choose as a case study. This system, presented in figure 2, is composed of an AADL system containing three devices describing different sensors and two processes bound onto the same processor. This system is then extended progressively to illustrate our approach. For example, to apply an active replication of the temperature_sensor component described with a device AADL component, we extended its textual description by the lines described in listing 2. We illustrate in this listing the use of the properties defined and explained in previous sections. We show in figure 3 the generated model after applying the active replication of the temperature sensor described in figure 2 and specified by the properties extensions described in listing 1. As previously noted, the replication of software component is distinct to the hardware or composite components. For that, we give an other example enriching our case study to illustrate Listing 1. 1 2 3 4 5 6 7 8 9 10 11 Replication of the temperature_Sensor device component system implementation g l o b a l . impl ... properties R e p l i c a t i o n P r o p e r t i e s : : D e s c r i p t i o n => ” R e p l i c a t i o n o f t h e t e m p e r a t u r e s e n s o r component ” a p p l i e s t o temperature Sensor ; R e p l i c a t i o n P r o p e r t i e s : : R e p l i c a N u m b e r => 3 a p p l i e s t o t e m p e r a t u r e S e n s o r ; R e p l i c a t i o n P r o p e r t i e s : : R e p l i c a T y p e => ACTIVE a p p l i e s t o t e m p e r a t u r e S e n s o r ; R e p l i c a t i o n P r o p e r t i e s : : R e p l i c a I d e n t i f i e r s => ( ” temp1 ” , ” temp2 ” , ” temp3 ” ) a p p l i e s t o temperature Sensor ; R e p l i c a t i o n P r o p e r t i e s : : C o n s e n s u s A l g o r i t h m S o u r c e T e x t => ” V o t i n g . Do Vote ” a p p l i e s t o temperature Sensor . sensor Out ; Listing 2. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Example of replication of a process Replication system implementation g l o b a l . impl ... properties R e p l i c a t i o n P r o p e r t i e s : : D e s c r i p t i o n => ” R e p l i c a t i o n o f t h e h a n d l i n g p r o c e s s component ” a p p l i e s t o handling Pro ; R e p l i c a t i o n P r o p e r t i e s : : R e p l i c a N u m b e r => 2 a p p l i e s t o h a n d l i n g P r o ; R e p l i c a t i o n P r o p e r t i e s : : R e p l i c a T y p e => ACTIVE a p p l i e s t o h a n d l i n g P r o ; R e p l i c a t i o n P r o p e r t i e s : : R e p l i c a I d e n t i f i e r s => ( ” h a n d l i n g P r o ” , ” h a n d l i n g P r o b i s ” ) a p p l i e s t o handling Pro ; R e p l i c a t i o n P r o p e r t i e s : : C o n s e n s u s A l g o r i t h m S o u r c e T e x t => ” V o t i n g . Do Vote ” a p p l i e s t o handling Pro . ProOut data ; R e p l i c a t i o n P r o p e r t i e s : : C o n s e n s u s A l g o r i t h m R e f => r e f e r e n c e ( a c t u a t i n g P r o . a c t i o n T h r e a d . s p g c a l l ) a p p l i e s to handling Pro . DataAccess ; R e p l i c a t i o n P r o p e r t i e s : : C o n s e n s u s A l g o r i t h m C l a s s => c l a s s i f i e r ( D o t r e a t m e n t ) a p p l i e s t o h a n d l i n g P r o . ProOut ; Global.impl Global.impl data_sensor Handling_Pro data_sensor Actuating_Pro 1ms Sensor_Out Handling_Pro Pro_In Sensor_Out 1ms Th_In Pro_In Th_In th2 Th_Out Pro_Out_data Pro_In_Data temp1 Pro_In_ Event_temp1 Sensor_Out S: Pro_In Pro_In_Event Th_In temperature_sensor Th_Out Pro_In_ Event_temp2 temp2 Pro_Out Pro_Out_data Pro_In_Data Pro_Out Pro_In Th_In_Event1 Do_Vote Th_Out Shared_data Param_In_1 Param_In_2 Param_In_3 Th_In_Event3 Pro_In_ Event_temp3 temp3 Data_Access position_sensor S: Sensor_Out Sensor_Out Failure_In Th_Out Voter Th_In_Event2 Shared_data th1 Actuating_Pro th2 Data_Access Sensor_Out S: Sensor_Out Pro_In_Failure Th_In Th_Out share cpu position_sensor Sensor_Out th1 Pro_In_Failure share Failure_In cpu Fig. 2. AADL specification of the basic case study the active replication of a process component. In fact, we extended the generated intermediate model by the properties presented in listing 2. We show also in this example, the application of the different consensus algorithm into each kind of feature of the replicated process component. The textual model generated after applying the list of transformation rules of the model shown in figure 3 and Fig. 3. Active replication of a device component enriched with properties in listing 2 is available at http: //goo.gl/EEQhLK. The resulting model was validated and instanciated using ocarina. The code application can be after that generated into Ada, C or RTSJ. If desired, other analyses can thereby be applied on this resulting model such as schedubility analysis with cheddar or evaluation of the dependability measures with petri nets. We deduce from this case study how much the generated model is complicated. Instead of doing it manually, our approach helps the designers to save efforts and reduce the design time and the risk of errors that may appear due to the important number of components and connections. This is by ensuring automatic model transformation using our extension of the Ocarina tool suite. VIII. C ONCLUSION AND FUTURE WORK We proposed, in this paper, a model level replication approach based on AADL extension to ensure fault tolerance. We took advantage of the extensions possible for AADL language. We defined our property set to support replication concepts since the design level. Then, based on a set of transformation rules, we offer the automatic generation of a new AADL specification enriched with replication concepts. Thus, we help the designer to model his fault tolerant system using AADL easier, at lower costs and more safely. We have achieved the definition of the transformation rules. We have also integrated the property set Replication_Properties into the Ocarina tool support and extended it by the implementation of the transformation rules. To validate our approach, we tested the model generation for some examples. We gave an example of an AADL specification enriched by active replication of both a device and a process component. As future work, we aim at accomplishing the implementation of the transformation rules related to the primary-backup replication based on modes and mode transitions. Finally, we aim at formally verifying and proving the correctness of the generated model using a model checker. R EFERENCES [1] A. Avizienis, J.-C. Laprie, B. Randell, and C. Landwehr. Basic concepts and taxonomy of dependable and secure computing. IEEE Transactions on Dependable and Secure Computing, 1(1):11–33, 2004. [2] S. Bernardi, J. Merseguer, and D. Petriu. A dependability profile within marte. Software & Systems Modeling, 10(3):313–336, 2011. [3] A. Carzaniga, A. Gorla, and M. Pezz. Handling software faults with redundancy. In R. Lemos, J.-C. Fabre, C. Gacek, F. Gadducci, and M. Beek, editors, Architecting Dependable Systems VI, volume 5835 of Lecture Notes in Computer Science, pages 148–171. Springer Berlin Heidelberg, 2009. [4] P. Domokos and I. Majzik. Design and analysis of fault tolerant architectures by model weaving. In International Symposium on HighAssurance Systems Engineering (HASE), 2005. [5] W. Gabsi, R. Bouaziz, and B. Zalila. Towards an aspect oriented language compliant with real time constraints. In WETICE - AROSA, pages 68–73, Hammamet, Tunisia, 2013. IEEE Computer Society. [6] J.-C. Laprie, C. Béounes, and K. Kanoun. Definition and analysis of hardware- and software-fault-tolerant architectures. Computer, 23(7):39– 51, July 1990. [7] G. Lasnier, T. Robert, L. Pautet, and F. Kordon. Behavioral modular description of fault tolerant distributed systems with aadl behavioral annex. In NOTERE, pages 17–24, 2010. [8] D. D. Niz and P. H. Feiler. Verification of replication architectures in aadl. In ICECCS, pages 365–370, 2009. [9] L. Pinho, F. Vasques, and A. Wellings. Replication management in reliable real-time systems. Real-Time Systems, 26(3):261–296, 2004. [10] SAE. Architecture Analysis & Design Language, April 2011. [11] SAE. Architecture Analysis & Design Language Annex E: Error Model Annex, June 2014. [12] F. Singhoff, J. Legrand, L. Nana, and L. Marcé. Cheddar: a flexible real time scheduling framework. International ACM SIGADA Conference, Atlanta, pages 1–8, 2004. [13] T. Vergnaud, B. Zalila, and J. Hugues. Ocarina: a Compiler for the AADL. Technical report, Telecom Paristech - France, 2006.