The MODUS Approach to Formal Verification

Abstract Background: Software reliability is of great importance for the development of embedded systems that are often used in applications that have requirements for safety. Since the life cycle of embedded products is becoming shorter, productivity and quality simultaneously required and closely in the process of providing competitive products Objectives: In relation to this, MODUS (Method and supporting toolset advancing embedded systems quality) project aims to provide small and medium-sized businesses ways to improve their position in the embedded market through a pragmatic and viable solution Methods/Approach: This paper will describe the MODUS project with focus on the technical methodologies that can assist formal verification and formal model checking. Results: Based on automated analysis of the characteristics of the system and by controlling the choice of the existing opensource model verification engines, model verification producing inputs to be fed into these engines. Conclusions: The MODUS approach is aligned with present market needs; the familiarity with tools, the ease of use and compatibility/interoperability remain among the most important criteria when selecting the development environment for a project


Introduction
The MODUS project was initiated to provide a sustainable and pragmatic tool set that will allow small and medium-sized businesses to improve their ranking in embedded systems engeneering.
By the use of formal description Techniques, MODUS will develop and validate a set of technical methods, as well as an open and customizable toolsets enhancing embedded systems by providing (MODUS (2013a)) : o Model verification by performing the selection of the available open-source model verification engines can be supplied, based on the automated analysis of system characteristics and the production inputs in these engines.o Connection to standard simulation platform for HW / SW co-simulation.o Software to optimize performance through automated design transformations.o Customizable source-code generation in line with coding standards and conventions.The project will also provide features and open interfaces to customize and extend MODUS toolkit for use with various formal specification techniques, modeling techniques, programming languages, platforms, etc. MODUS is not intended to be low competition with CASE tools used in embedded software engineering at the moment.On the other hand, you want the project to allow the adoption of quality strategies by supplementing these tools and allow existing investments in technicalknow with continued use.In the next section, the tools for formal verification is described, followed by methods to control the selection of techniques and strategies for the selection tool.

Supported verification tools/languages and their properties
The selected model verification tools to be supported by the MODUS toolset are SPIN and RAISE.Both of the tools are LTL (Linear Temporal Logic) model checkers.The sections below present more details about the properties of these tools and the languages they use for model description.

SPIN
SPIN and PROMELA are focusing on the process interaction, i.e., describing how system components communicate with each other (Holzmann, 2003).As already, mentioned not much attention is given to internal computation processes.The process interaction can be modelled in a number of ways: o rendezvous primitives (synchronous) o asynchronous message passing through buffered channels o access to shared variables o any combination of the above SPIN itself provides a methodology for matching the system design expressed in PROMELA language and the LTL formula describing desired/correct behaviour of the system.
PROMELA is a language crafted for describing models of distributed systems.It expresses the model description using a language similar to C with some notation from the guarded command language by Dijkstra and the CSP language from Hoare (particularly to describe interaction between processes).A PROMELA model consists of (Holzmann, 2003): o variable declarations with their types o channel declarations o type declarations o process declarations o init process (optional) In PROMELA a process is a basic building unit of the system It is defined by a so called "proctype" definition that contains the process' name, the process' list of parameters, its declaration of local variables, and the sequence of local statements.Meenakshi (2004) provides a following example of process definition: proctype Sender(chan in; chan out) { bit sndB, rcvB; do :: out ! MSG, sndB -> in ?ACK, rcvB; if :: sndB == rcvB -> sndB = 1-sndB :: else -> skip fi od } Models written in PROMELA can (and usually will) contain more than one process.Multiple processes will run in parallel, communicating with each other using the interaction methods described at the beginning of this section.The state of the process is defined by its local variables and the process counter.Processes are invoked by using a run statement inside the init process or by adding to active keyword.The process creation can be placed in arbitrary places within the model.The variables in PROMELA require declaration defining the type and name of the variable, prior to its use.

Communication. As indicated earlier channels are used to enable communication between processes. There can be the following two types of communications:
o Message-passing or asynchronous o Rendezvous or synchronous Channels are of a FIFO (First-In First-Out) type and is defined using array type defining the number of messages that can be occupied by the channel.The declaration also specifies the type of elements that can be passed using this channel.
Rendezvous communication is established using channels with dimension zero.If you send through a channel is enabled, and if there is a corresponding receiver that can be performed simultaneously, so both statements are enabled.Both statements will be able to perform a single transition.

Statements.
Promela statements are separated by a semicolon.One of the basic statements Promela projections ( do something ) to distinguish , printf , assert (expression) (Check whether the expressions property is valid in a state ) if statements ( executable if at least one of the options is non-blocking) and submit observations .The feasibility of Promela statement depends on its type and value -expression is evaluated .Assignment statements , skip, pause, printf are statements that are always executable .Expressions are executable if it does not evaluate to zero.This means that if or executable statement is , if at least one guard evaluates to true.The communication settings are executable statements , depending on the status of the channel , a transmit executable for non-channels and a receiver statement executable for non-empty channels.To the statements of the group for a specific process in a sequence in a single step , which does not include statements of other processes performed nested , one can use an atomic statement.The feasibility of the atomic statement depends executablility to the first survey.If one of the following statements is not executable , the indivisibility of atomic propositions are broken and other processes can be nested .
Another example of a one-step embodiment, a d-point .In contrast to the statement if the atomic d-step involves blocking mode , it causes a runtime error.Finally timeout statement is a statement that is executed if no other statements contained in any of the other processes are executable ( this function can not be used to be modeled timeouts that are involved in the system design.) RAISE RAISE (Rigorous Approach to Industrial Software Engineering) is a tool-set that consists of: a method for software development, RSL (RAISE Specification Language) specification language, and a computer tools for automated model checking, analysis, and translation (George, 2008).
The key for system verification using the RAISE tool-set is to obtain a specification in RSL.RSL, as a specification language, provides a wide range of opportunities for expressing the modelled system: it allows property and model-oriented styles, applicative and imperative styles, as well as sequentiality and concurrency.

Modules.
A RSL specification is divided into modules.A module should capture the types, values and axioms that characterize the system or its parts.A generic module definition in RSL has the following form: A declaration will start with a keyword identifying the kind of declaration (e.g.type, value, axiom).The following RSL specification of a database illustrates RSL type declaration.This is further clarified in the following subsections (George, 2008) Another kind of type declaration is using the "=" operator.Using "=" expresses that the new type is representing the expression on the right side of the operator.Back to the previous example, using "=" declares the Database as a set of people i.e., the type containing all finite subsets of the set of values in Person.RSL Atomic types with their values and operators are listed below (Haxthausen, 2010)

Value declaration.
Values can be named in the value declaration.The simplest example of value declaration is in the form "id : value" and can be seen in the provided example of the RSL declaration of a database (see empty).The actual value that is identified by empty is described in one of the axioms (described later).The next value example (register) represented in that example, declares a function that adds a person to the database, it represents a database after performing the registration i.e., when the person was added.
Finally, the third type of value definition in that example, defines a function check.When check is applied to database and a person, depending on whether particular person is part of Person-set defined by Database, a Boolean true of false is returned.

Relevant model properties
The most important feature that should be considered when deciding on the formal methodology tools is the possibility of representing the properties of the system in the formal language selected for performing the verification and validation.Different formal description languages have different set of features that they can express.During validation it is important to identify the crucial system properties and ensure that these properties can be expressed using a particular formal description.
Otherwise the verification makes no sense since, when important parts of specification are lost; essentially it is a different system that is validated.UML and SysML diagrams are the sources of the model descriptions, as far as MODUS tool-set is considered, as presented in previous deliverables (MODUS 2013a, 2013b, 2013c, 2013d).As such, the set of the features contained in these diagrams will depend on the types of the diagrams that are integrated in the model.
Definitely system is described in different degree of details depending if it contains structural or behavioural modelling data.This is clarified in the following: The most commonly used diagram during the software development is a class diagram.These types of diagrams present the system structure by showing classes with their properties and relations between them.
On the other hand, behavioural diagrams can express a dynamic nature of the system.They describe states of an object during its lifetime Two translation tools selected for the integration with the MODUS tool-set, i.e.UML2RSL and Hugo/RT have different capabilities when it comes to translation model.The following sections present the capabilities of the tools and describe certain translation possibilities and examples.

UML2RSL
UML2RSL used class diagram, to formulate RSL specification.As a result of the translation, in order to obtain a specification of a plurality of modular RSL files.A top-level module is stored in the file S.rsl.It contains a specification of the model with the whole class diagram.S.rsl uses one set of modules containing a specification of one of the classes from the diagram.The name of these modules is given to match the class name in capital letters, followed by "S_".Each RSL module for a class is created with a lower level module corresponds to an object of the given class, named after the class in capital letters, followed by "_".Each of these lower level modules used TYPES.rslmodule where all the abstract types defined in the illustration (George,2008).
Considering a simple example of a class diagram presented below six files will be created (Figure 1   The remaining files that are output from the UML -to-RSL transition, listed in Appendix A: Translation results UML2RSL.A class, in addition to the normal function of returning the value of an attribute, very often contains operations change the attributes.It could be an event that occurs, this attribute modification in a particular state.This is handled by the compiler to generate the RSL functions for this purpose.Their claim is to be completed by the user (see e.g.preupdate_Association).
According to this example of the type described MyClasss is the set of all possible states of the class MyClasss, representing a number of groups of articles or MyClass all possible sets of objects that can be observed at a given time.It can be described as the class of container.
For each class in the class can create new objects and damaged or altered existing objects.This is the existence of some typical features (empty, add part is_in, sheep, and update) that can be on the set of instances of each class and the work of a translator resist.Seen an example of these features in CLASSOUTOFPACKAGES_ and MYCLASSS_ files (see Appendix A: Translation results UML2RSL).
To check the consistency of the whole system in order to verify that keep all constraints are a number of axioms defined top-level.This makes it possible to check whether the system is done in a consistent state before and after each change in status.For this reason, a number is generated by similar functions.They are included in the top level module S, but also a set of Boolean functions is formed in the lower level modules the.Lower level texture features, the user to check the consistency of objects and classes.The top feature using features lower level checks the consistency of the whole system.
This simple example also shows the association, which is translated as two RSL functions between the classes involved (or, if the association is navigable in only one direction).
The UML2RSL translation tool also accepts and executes test: Composition, aggregation, generalization (but only translates single inheritance) abstract, root, leaf and template classes.Dependencies ignored (details can be found in (George 2008).

HUGO/RT
A translation performed by Hugo/RT goes beyond the basic class diagram translation (Knapp, 2008).Hugo/RT can translate the UML models that contain classes with state machines, collaborations, interactions, and OCL (Object Constraint Language) constraints.
The state machines describing the state the objects can be in, can be complemented by another dynamic view of the system, namely, the sequence and collaboration diagrams, describing the interactions between different objects in the system.Hugo/RT can be used to verify whether these complementary views of dynamic properties of the system are coherent.In other words it allows verifying whether the system described by the state machines can fulfil the interaction described in the collaboration.
The UML state machines should be described in the context of a UML class.The classes need to declare all events that its state machine can handle (Knapp, 2008).Hugo/RT translation for every state machine creates a separate PROMELA process.Considering an example borrowed from (Schäfer, Knapp, Merz, 2001).It is possible to define a system that is composed of an ATM and a Bank, presented by a simple class diagram in Figure 3.Each of the classes contains a state machine.For instance let's consider a state machine of the ATM module (see Figure 4).This state diagram contains simple and composite states together with guarded and unguarded transitions.

Strategies for selection of the formal description tools
This section covers the possible strategies for selecting a proper formal verification/ validation path.This includes a selection of the UML to formal language translator and as such also the model checker.The strategy included in this deliverable is taking into account only the tools considered for the first stage of the MODUS toolset development.
As described earlier, the two model checkers that are identified as first priority tools to be integrated within MODUS tool-set are SPIN and RAISE (SAL).This means that Hugo/RT and UML2RSL will be the tools that perform the translation between a UML model and a formal description.Considering different properties of the aforementioned translators, the strategy for the selection of the tools for the formal verification and validation is rather simple (at least at this stage of the development).Since UML2RSL handles only UML diagrams containing class diagrams it can only be considered for this basic types of models.
UML diagrams containing state machines, within their classes, cannot be translated into RSL, because the translator is not processing behavioural diagram types.As such, large part of the system description would be lost.For diagrams that contain state machines describing the behaviour of the objects of a certain class type, Hugo/RT should be used in the currently planned MODUS toolset formal verification block.The resulting PROMELA model produced by the Hugo/RT translation can later be fed to SPIN for formal verification according to collaboration diagrams and OCL constraints.
If class diagrams that do not contain any state diagrams are translated using Hugo/RT, the tool will prompt a warning indicating that no behaviour description was detected and almost empty file (containing only idle process) will be generated.This strategy for selection of the formal verification tool to be used in each case can be implemented as a simple algorithm as depicted in Figure 5.

Conclusions
MODUS is targeting the market of tools for embedded software engineering.The project will develop a toolset advancing embedded systems quality that will target the growing group of SMEs (and bigger companies as well) specialising in the development of embedded systems in different industrial sectors (e.g.avionics, automotive systems, consumer electronics, telecommunications systems, etc).
It should be emphasized that MODE does not aim to compete with the major suppliers of CASE tools currently used in embedded software engineering to become.On the contrary, the project aims to facilitate the implementation of quality strategies by preserving existing investments in technical know-how and tools.The MODUS approach is aligned with present market needs; the familiarity with tools, ease of use and compatibility/interoperability remain among the most important criteria when selecting the development environment for a project.Specifically, this paper has focused on the formal verification part of the MODUS toolsets, but the uniqueness of the MODUS toolsets lies in the combination of formal verification, HW/SW co-simulation, SW performance tuning and customizable source code generation.

Figure 1
Figure 1 Simple class diagram for UML2RSL translation

Figure 2 RSL
Figure 2 RSL output dependency diagram

Figure 3
Figure 3 ATM -Bank class diagram

Figure 4
Figure 4 ATM state machine

Figure 5
Figure 5Formal methods selection A type is a collection of logically related values.There exists a number of build in types that are predefined in RSL.Beside those, a RAISE user can also define his/her own types.One can create an abstract type like Person in the example above.Abstract types do not have any predefined operators for manipulating their value (beside the "=" operator, used for comparison of two values).
(Haxthausen, 2010r previous value expression the axiom contains a detailed characterisation of this value.One can distinguish 3 three forms of value definition in RSL(Haxthausen, 2010): Brought to you by | DTU -Technical Information Center of Denmark (DTIC) Authenticated | 192.38.67.112Download Date | 7/7/14 1:12 PM ∀ p : Person, db : Database • is_in(p, register(p, db)) ≡ true Axiom declarations.Axioms are used to bring the property value names for expression.Let's go back to the database, for example, the first axiom is an expression of type bool and declares that the value expression is empty, and {} are the same.All axioms are Boolean expressions evaluate to true.The second axiom is presented in our example suppresses the register function.It uses level expressions show that for all people and all databases, the data for a couple of person p and database db is used, is equivalent to a union subsets).Axiom defines Check the function that will be registered if it belongs to the group hosting the database.Module extension.RAISE also allows for module extension where one can declare a new module that adds type, values, and axioms to existing module.For that purpose one should use extend <module_name> with expression.