On the Use of Real-Time Maude for Architecture Description and Verification: A Case Study

Real-Time Maude is an executable rewriting logic language particularly well suited for the specification of object-oriented open and distributed real time systems. In this paper we explore the possibility of using Real-Time Maude as a formal notation for software architecture description and verification of real time systems. The system model is composed of two kinds of descriptions: static and dynamic. The static description consists in identifying the different elements composing the architecture, while the dynamic description is the definition of the rules governing the system behaviour in terms of the possible actions allowed. The correspondence between software architecture concepts and the Real-Time Maude concepts are developed for this purpose. The step towards verifying system architecture is realized by applying Real-Time Maude simulation and analysis techniques to the described model and the properties that must be satisfied. An example is used to illustrate our proposal and to compare it with other architecture description languages.


INTRODUCTION
During the past decade, architectural design has emerged as an important subfield of software engineering.In fact, a good architecture can help ensure that a system will satisfy key requirements.Consequently, a new discipline emerged, which concerns formal notations for representing and analyzing architectural designs: Architecture Description Languages (ADL) [4].ADL allow to model hierarchical components systems.After modelling step, designers want to make sure that the built application is safe.
Rewriting Logic formalism has been used in the verification of systems models.This logic differs from the standard logics, as first or higher order logics, by the fact that it is a logic of change whose models are concurrent systems and whose deduction is concurrent computation in such systems.Real-Time Maude [16] is an executable specification language based on rewriting logic.This system is particularly well suited for formal specification and analysis of real-time systems.
In this paper we would like to explore another alternative for describing and verifying real time systems' architectures.We propose Real-Time Maude, since it is dedicated to the specification of real time object-oriented open and distributed systems.This paper is organized as follows: in section 2, we recall basic concepts related to software architecture, rewriting logic and Real-Time Maude system.Section 3 introduces rewriting semantics of software architecture description, based on Real-Time Maude system, while section 4 presents how to perform formal verification and analysis.The following section illustrates our approach through the case study of an aircraft aileron controller system.In section 6, we discuss related work.Finally, we conclude the paper in section 7 and give some perspectives about further work.

Software Architecture
Software architecture plays typically a key role as a bridge between requirements and code.By providing an abstract description (or model) of a system, the architecture exposes certain properties, while hiding others.Initially, the architectural design was largely an ad hoc affair [4].One development has been the creation of formal notations for representing and analyzing architectural designs.ADL usually provide both a conceptual framework and a concrete syntax for characterizing software architectures [4,9].The use of these languages offers several advantages.Indeed, ADL allow: the reuse of architectural design specifications, rapid prototyping, supports use for evolution and re-engineering and better understanding of architectural designs through early errors detection, and quality of service analysis [4,9].
A number of ADL have been proposed for specifying and verifying architectures, both within a particular domain and as general-purpose architecture modelling languages.As example of ADL, we note Rapide [5] and Wright [1].There were many attempts to classify software architecture description languages [3,6,8,9].As Medvidovic and Taylor's classification and comparison framework [9] is the most recent and complete, we use their results as a basis for our work.Indeed, figure 1 identifies the desired kinds of representation, manipulation, and qualities of architectural models described in architecture description languages.We conclude from this figure that the main architectural building blocks are: components, components interfaces, connectors and configurations.

Rewriting logic
The theory of rewriting logic has proved to be very useful to find a unifying framework for concurrency formalisms [10].In [12], Meseguer showed in a number of examples that it is suitable as a common framework for concurrency.For rewriting logic, the entities in question are concurrent systems having states and evolving by means of transitions.Rewrite rules in the theory describe which elementary local transitions are possible in the distributed state by concurrent local transformations [7].We give the definition of a labelled rewrite specification.Readers may refer to [11] for more detailed information about rewriting logic.
In object oriented rewriting logic, object oriented message-passing style and functional styles can be freely mixed.Messages are then exchanged between objects, and cause communication events by application of rewrite rules.Concurrent rewriting modulo structural axioms of associativity, commutativity and identity capture abstractly the essential aspects of communication in a distributed object oriented configuration made up of concurrent objects and messages [7].
In recent years, several executable specification languages based on rewriting logic have been designed and implemented.Maude system is an efficient tool for systems' specification and analysis based on rewrite logic.In [14], it has been used for software architecture verification.Typically, Maude specifications are executable [2].Maude system provides syntax for representing object oriented concepts.Maude's object oriented syntax models the concurrent state of the system (or configuration) as a multi-set of objects and messages.An object is given by the term: < O : C | atv >, where O is the object identifier instance of the class C and atv is its set of the attributes and there values.This set is given with respect to the following syntax : a1 : v1 , ... , an : vn, where ai, i 1..n, are the object's attribute and vi their respective values.The concurrent interactions between the objects are controlled by rewriting rules.The general form of a conditional rewrite rule in Maude is as follows: where RuleLabel is the label of the rule, Ms, s 1..n, and M'r, r 1..q are messages, i1, ...,ik are numbers in 1..m and Cond is the rule condition.If the rule is non conditional, then the keyword crl is replaced by rl and the "if Cond" clause is removed.For additional details about Maude's syntax, readers may refer to [2].

Real-Time Maude
Real-Time Maude is an extension of Full-Maude [15].It is a language and a tool supporting the formal specification and analysis of real-time and hybrid systems.The specification formalism is particularly suitable to specify object oriented real-time systems.In [15], the authors introduced an approach for modelling real-time systems as real-time rewrite theories.A real-time rewrite theory contains: • a specification of a data sort Time specifying the time domain, which may be discrete or dense, • the sort GlobalSystem and a free constructor, denoting that t is the whole system in state t, • ordinary rewrite rules that model instantaneous change, • and tick rewrite rules, that model the elapsing of time in a system.Tick rules have the following form: where t and t' are of sort System, D is a term of sort Time denoting the duration of the tick rule and cond is the condition.Real-time rewrite theories are specified in Real-Time Maude as timed modules or object oriented timed modules at the user level by enclosing the module body between the keywords tmod and endtm, or between tomod and endtom for object oriented timed modules.In Maude system, we can use properties specifications, expressed in LTL and implemented model checking procedures, to check properties in a given module starting from an initial state [2].As an extension of Maude, Real-Time Maude offers a wide range of analysis techniques, including timed rewriting for simulation purposes, untimed and time-bound search for states that are reachable from the initial state and match a given search pattern, and timebound linear temporal logic model checking [16].

SOFTWARE ARCHITECTURE DESCRIPTION IN REAL-TIME MAUDE
In general, software architectures are modelled in terms of components, connectors and configurations.Components are system entities which contain information and offer services (through interfaces), while connectors ensure communication between them.A system is therefore composed of interacting components through connectors.The rules governing interaction events are specified by the means of configurations.
As previously defined in sub-section 2.1, architecture description may include other modelling elements, as semantics (high-level model of an element's behaviour), constraints (a property or assertion about a system or one of its parts, the violation of which will render the system unacceptable), non-functional properties (properties which are not entirely derivable from the specification of the element's semantics), compositionality (the mechanism that allows architectures to describe software systems at different levels of detail: Complex structure) and analysis (the ability to evaluate the properties of such systems in order to lessen the cost of any error).
The step towards building system architecture description is to identify the different elements for static and dynamic description, which can be done according to the following process: 1. Identify the components, the connectors and the configurations, 2. Identify the interfaces, 3. Identify compositionality, 4. Finally, identify the semantics.
Points 1, 2 and 3 deal with the static aspect of the system.Point 4 defines the rules governing the system's behaviour in terms of the possible actions allowed, that is its dynamic aspect.
Once we have identified all these entities, we are ready to model the system.
For that, we propose Real-Time Maude, using the following modelling approach: 1.Each component is modelled by a Real-Time Maude class, whose members must include at least the attribute computation describing the instance status.The name of the class modelling a component is the same as the component name.The class may declare clock and dly attributes (which allow performing time advance), as it may declare any additional attributes (that characterize the component fulfilling its role).2. Each connector is modelled by a set of rewrite rules describing communication events.
These events are shown up by the mean of Real-Time Maude messages.7. Finally, behaviour semantic is modelled by rewrite rules.The left-hand side and guard of a rewrite rule represent the conditions that must satisfy a particular subsystem for a rule to be triggered on it, that is, what has to happen for an action to take place; its right-hand side represents the effect of such an action on such subsystem.
The following table summarizes the correspondence between software architecture concepts and the Real-Time Maude concepts used to model them.In order to carry on a modular description, the following rules are applied: • All the declarations and rewrite rules that are relative to a given component are gathered in a distinct and single Real-Time Maude module.If the component should be equipped with a clock for time measuring purposes, then the built module is a real-time object oriented Real-Time Maude module, else it is an object oriented Real-Time Maude module.• Connectors specifications are grouped in one single real-time object-oriented module.
• Configuration specification is set in a real-time object-oriented module that imports all components and connector modules.
Figure 2 shows a visual outline of these rules.Once the system specifications are written using this modelling approach, what we get is a rewrite logic specification of the system, which can be executed in Real-Time Maude, thus simulating its behaviour.This means that, in addition to being able to formally reason about such a system, we will have a running prototype.

SOFTWARE ARCHITECTURE VERIFICATION IN REAL-TIME MAUDE
Since we obtain a running prototype written in Real-Time Maude, we may perform analysis and verification tasks.Indeed, Real-Time Maude offers a wide range of analysis techniques, including timed rewriting for simulation purposes, un-timed and time-bounded search for states that are reachable from the initial state and match a given search pattern, and time-bounded linear temporal logic model checking [18].It has been used to model and analyze scheduling algorithms [17] and sophisticated communication protocols [19].
The step towards verifying system architecture described with Real-Time Maude as introduced in the previous section is to identify these elements: • The constraints and the non-functional properties, • Analysis mechanisms.
The first point defines the properties that must be satisfied, while the second consists in applying Real-Time Maude simulation and analysis techniques.
An interesting issue worth pointing out is that designers may use Maude's strategies for controlling the execution or model-checking the system behaviour based on the different occurrence of the actions.

A CASE STUDY
In order to illustrate our proposal, we will specify in Real-Time Maude an aircraft controller system, inspired from [13].This system is responsible for controlling the right aircraft aileron (figure 3).The system is synchronous and manages the communication between the different components.This example is a simplified aileron aircraft controller which aims at drive a motivator by generating periodically its control (2 time units period).Since the aileron control is critical, this system is composed of three redundant functions implemented on different calculators which communicate via buses.These functions are as follows: • The master function (MF): this function is initially in driving mode until its failure.While sending a command towards the aileron via an analogical bus, MF also sends a command towards the two other systems' functions (RF1 and RF2) via digital buses.• The first rescue function (RF1): this function is initially in off mode.It passes in driving mode when MF fails.According to RF1, MF is considered as failing if this one did not receive any command coming from MF within 4 ms.While sending a command towards aileron, RF1 also sends a command towards the second rescue function (RF2).
• The second rescue function (RF2): this function is also initially in off mode.It passes in driving mode when both, the master function and the first rescue function, fail.According to RF2, the failure of MF and RF1 are interpreted by the non reception of any command coming from one of them within 10 ms.
This system contains two different types of buses: • Analogical buses: these buses allow the effective transmission of the command towards the aileron.The transmission is instantaneous.• Digital buses: these buses allow exchanging control signals between the control modules.
The transmission is done within a variable elapse of time.
The communication buses are characterized by execution latencies.In table 2, we summarize the latencies of each bus.

Modelling Components
Let us begin with the system's components constituting its architecture.Following our proposed approach, we can identify here four main components, namely the master function, the first rescue function, the second rescue function and the aileron.
The master function component is modelled by the MF class, which has four attributes: clock, dly, computation and mode.As explained in previous section, the first two attributes are used for time measuring purposes, while the third is used for describing class computations.The additional attribute mode stores the information about the component's mode.This function may provide three services: CmdService, RF1Service and RF2Service, towards respectively the aileron, RF1 and RF2.The first rescue function component is modelled by the RF1 class, which has the same attributes as MF class.In one hand, this function may provide two services: CmdService and RF2Service, towards respectively the aileron and RF2.In the other hand, it requires one service, which is RF1Service.The second rescue function component is modelled by the RF2 class, which also has the same attributes as MF class.This function may provide only one service (that is CmdService) towards the aileron, and requires one service, which is RF2Service.Finally, we have the aileron component.This last is modelled by the Aileron class, which has only three attributes: clock, dly and computation.This component requires only one service, which is CmdService.This service can be received from one of the three functions.

Rules modelling components behaviours
The behaviour of each component is specified through a set of rewrite rules.We start first by modelling the master function component behaviour.Indeed, this component computes the position then sends the control towards the aileron and the other two functions at each cycle.The table 3 gives these rules.
In Real-Time Maude, the object attributes that are not relevant for a rewrite rule do not need to be mentioned.Indeed, attributes not appearing in the right-hand side of a rule will maintain their previous values unmodified [16].
In these rules, we notice the modification of computation attribute's value, which underlines the behaviour.We note as well the presence of three messages (provide messages) in the lefthand side of the second rule, which underlines communication events creation.In the third rule, the values 0 and step of dly attribute is the key concept for advancing time.
The behaviour of the first rescue function component is given in table 4. Indeed, it is initially in off mode.Each time this component receives a message (require(RF1Service)), its clock is reset to zero.If no message is received within 12 time units, the component mode becomes Cmd and it starts controlling the aileron in a way similar to the master function component.
The behaviour of the second rescue function component is similar to that of the first one.The main difference is that the time condition for moving to Cmd mode is 12 instead of 4.
The behaviour of aileron component is specified through two rewrite rules.The first describes the clock reset operation following the reception of a require message, while the second describes time advancing if such a message does not exist.

Modeling connectors
Connectors are responsible of service exchange between components.As we have shown is section 3, the corresponding Real-Time Maude concept is a set of rewrite rules.In our case, buses are treated as connectors.In table 5, we give the Real-Time Maude specification of these connectors.
The analogical bus behaviour is described by one rewrite rule, which transforms directly a provide message into a require message.However, the digital bus with maximal latency 2 is described by two rewrite rules.The first generates from the provide message a temporary message (tempRequire) of maximum time elapse 2. The second rule explains that the transformation of the temporary message into a require message can happen at any time between the first and the second time arguments.The Real-Time Maude specification of the digital bus with maximal latency 4 is similar to that with maximal latency 2. The difference appears only in time delays of the tempRequire message.

Advancing time
Since all components clock attribute values describe elapsed time, we specify their increase with the synchronous rule below: In this rule, mte operation describes advancing time condition.Consequently, it is executed only when all dly attributes are different from 0 and there is no require or provide messages.Indeed, when such message appears, it should be immediately consumed.The operation delta models the effect of time elapse on the system.It increases all the clock attribute values and decreases all dly attribute values.provide("RF2Service") => tempRequire("RF2Service", 4, 0, 0) .

System verification
Considering the aileron aircraft controller system, we need to check these two properties: • The aileron should not remain without control more than 16 ms (AileronCMD property).
• There must be only one function controlling the aileron at a time (NbrFCmd property).
Properties specification as well, is done by declaring constants.

RELATED WORK AND DISCUSSION
Description and verification in architecture specification are key concepts employed in ADL.Among the proposed approaches, we will focus here on two axes: the axe that concerns the description and the axe that concerns using rewriting logic for verification in ADL.
In the first axe, the use of Real-Time Maude for specifying software architectures, among known ADL as Wright and Rapide, may present the following advantages: • We showed in section 3 that we can express a set of essential architecture description elements using Real-Time Maude.• Wright ADL does not support explicit time constrains expression, while Real-Time Maude supports it.• Rapide ADL offers only three time operators that are pause, after and delay.However, these operators have relatively close semantics, while we can express more timing constrains using Real-Time Maude.
With regard to the verification in architecture description, there are other proposed formal notations like posets and CPS.However, Rewriting logic, which is the underlying formalism that Real-Time Maude is based on, is a common framework for concurrency formalisms.Consequently, this point emphasizes the main advantage of using simulation and analysis techniques of Real-Time Maude.
Despite the advantages we pointed out, some attributes of software architectures introduced in section 2.1 cannot be adequately captured in Real-Time Maude, like refinement and traceability [9].Indeed, ADL may enable correct and consistent refinement of architectures into executable systems and traceability of changes across levels of architectural refinement.However, Real-Time Maude system does not yet support refinement techniques.In the same way, active specification and implementation generation cannot be captured using this system.

CONCLUSION
Real-Time Maude is an executable rewriting logic language especially well suited for the specification of object-oriented open and distributed systems.In this paper, we have explored the possibility of using Real-Time Maude for specifying the architecture of real time software systems, and we are now in a position to formally reason about the specifications produced.The example of an aileron aircraft controller is used to illustrate our proposal.
Different languages have been proposed for architecture description.It has been shown that rewriting logic and its associated language Maude constitute an appropriate logical and semantic framework making much easier the integration and interoperability of different models and languages in a rigorous way.Thus, Real-Time Maude seems to be a promising option as a unifying framework for ADL.
An interesting topic of research, that is worth pointing out, is the use of the reflective capabilities of rewriting logic and Maude.These capabilities can be used for specifying and reasoning about different system properties, such as QoS, as well as specifying strategies for controlling the execution or model-checking the system behaviour based on the different occurrence of the actions.

FIGURE 2 :
FIGURE 2: Visual outline of modular description.
3. Types are modelled by sorts.4. Configuration is a constant term of sort System fixed by an equation the set of initial components.
BCS International Academic Conference 2008 -Visions of Computer Science 5. Each interface is modelled by a term of sort Service.6. Compositionality is obtained by sub-class relationship.

TABLE 1 :
Correspondence between software architecture concepts and Real-Time Maude concepts.

TABLE 2 :
Bus communication latencies of the aileron controller system.

TABLE 3 :
Rules describing the master function component behaviour.

TABLE 4 :
Rules describing the first rescue function component behaviour.
These constants have the term Prop on top.The constraint semantics is established by the mean of an equation.We illustrate properties declaration by AileronCmd property: Therefore, we may conclude that both properties are satisfied.In addition, we can find out deadlock states.This is performed through Real-Time Maude's search command that can be unbound timed.The following execution result shows up deadlock freeness property.