190
IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING,
VOL. 12,
NO. 2,
MARCH/APRIL 2015
Modeling Dependability Features for Real-Time Embedded Systems Siru Ni, Yi Zhuang, Zining Cao, and Xiangying Kong Abstract—Ensuring dependability is significant in the development process of Real-Time Embedded Systems (RTESs). The dependability of a system model is usually presented by temporal and data constraints, which are ambiguous and incomplete when using semi-formal methods. Formal methods have precise semantics and strong verifiability, but few can capture the dependability features for RTESs. This paper presents Z-MARTE, an extensible modeling method combining MARTE profile and Z notation, to provide rigorous specifications towards the dependability features of RTESs. To extend the descriptive ability of Z, we design the time model, structure model and behavior model in Z-MARTE, specifying temporal and data constraints in the form of predicates. Z-MARTE can be edited and verified by the existing tools for Z. The converting from MARTE to Z-MARTE is supported by ZMT, a model transformation tool we design. A case study of a communication system is given to illustrate the modeling and verification procedure of Z-MARTE. Index Terms—Dependability, formal methods, real-time and embedded systems
Ç 1
INTRODUCTION
R
EAL-TIME Embedded Systems (RTESs) are wildly used in industrial, medical and military equipment, for it can be working in very uncertain or unmanned conditions. RTESs have become more complex and open-ended in recent years. Consequently, ensuring the dependability properties during the process of design, implementation and verification of RTESs is facing with great challenges. ACCORDING to Avizienis et al. [1], the dependability of software is defined as the ability to avoid failures that are more frequent and more severe than acceptable. Liu et al. [2] defined the attributes of software dependability, which include Availability, Reliability, Security, RealTime, Maintainability and Survivability. Modeling and evaluating these Non-Functional Properties (NFPs) is crucial while developing dependable RTESs. Construction approaches of software are classified into two categories: semi-formal and formal methods. The semi-formal methods, such as UML, have better maturity and are more intuitive for engineers to build system models. Modeling and Analysis of Real Time and Embedded systems (MARTE) [3] is an extension of UML proposed in 2005. It presents a suitable time model to express real-time concepts, as well as elements to describe NFPs of RTESs. A few extensions of UML/ MARTE have been proposed to capture the dependability
S. Ni, Y. Zhuang, and Z. Cao are with the College of Computer Science and Technology, Nanjing University of Aeronautics and Astronautics, PO box 162, Nanjing, Jiangsu 210016, P.R. China. E-mail: {nisr, zy16, caozn}@nuaa.edu.cn. X. Kong is with the Electronic Equipment Business Unit, Jiangsu Automation Research Institute, PO box 102-8, Lianyungang, Jiangsu 222000, P. R. China. E-mail:
[email protected].
Manuscript received 13 Mar. 2013; revised 10 Apr. 2014; accepted 23 Apr. 2014. Date of publication 28 Apr. 2014; date of current version 13 Mar. 2015. For information on obtaining reprints of this article, please send e-mail to:
[email protected], and reference the Digital Object Identifier below. Digital Object Identifier no. 10.1109/TDSC.2014.2320714
features of RTESs [4], [5], [6]. However, models and constraints in semi-formal methods are imprecise and incomplete at the semantic layer. It is not satisfying that we cannot verify the expected properties of RTESs in the early design phase, since the detection and correction of errors and flaws in the testing phase could cost a lot more effort and time. In July 2001, the Object Management Group (OMG) presented Model-Driven Architecture (MDA) [7]. The application of Formal Specification Languages (FSLs) in MDA provides the precise and complete semantics for the modeling elements. The dependability of RTESs is presented by constraints described by FSLs in the structure and behavior models of the system. Model-Driven Development (MDD) can maintain these properties of the models during the formal deduction procedures, and could prove these properties using rigorous verification methods. Although utilizing formal modeling methods brings some obvious benefits, it also has some drawbacks, such as poor readability and time-consuming process. Besides, the direct transformation from the informal requirements to formal specifications is relatively difficult. We believe, and the former researches have also demonstrated, that formal and semi-formal methods could be complementary to each other in both semantic and developmental aspects. As a result, the formal semantics of UML was studied [8], and several transformation or integration methods between UML and formal methods have been proposed [6], [9]. The researchers choose different FSLs to obtain the description ability of certain features they concern, for example, Petri Net to describe the concurrency structures, Finite Automata (FA) to describe the temporal behavior, or Z to describe the data constraints within the models. However, most of the existing FSLs usually focus on one of the attributes of dependability, such as security or real-time, and lack the ability to
1545-5971 ß 2014 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
NI ET AL.: MODELING DEPENDABILITY FEATURES FOR REAL-TIME EMBEDDED SYSTEMS
capture both static and dynamic features of the system. FSLs like Petri Net and FA cannot specify the data constraints in the system model because of the absence of operation specifications, while Z lacks the elements to model the temporal behavior. Moreover, the modeling requirements of RTESs have not been considered in the previous studies. In this paper, we propose a modeling and verification method for RTESs combining MARTE profile and Z notation. The meta-model of Z is extended to capture both static and dynamic features of dependability. Z-MARTE consists of time model, structure model and behavior model. Z-MARTE time model is derived from the core elements of MARTE time model, providing basic temporal modeling elements. Z-MARTE structure model and behavior model represent the structural and behavioral views of RTESs, specifying the temporal and data constraints that present the dependability features. We define Z-MARTE models using a set of structured Z schemas, called templates, to provide the mathematical expression of the dependability constraints. The description ability of Z-MARTE is more comprehensive than existing models. It is able to perform targeted modeling of dependability features regarding both structural and behavioral aspects of RTESs, and is highly extensible because of the modularity of Z. Moreover, Z-MARTE enhances the verifiability of UML/MARTE. The extended elements in Z-MARTE enable us to validate the inconsistency between the dependability constraints in the structure and behavior models of RTESs. In this paper, the modeling and verification procedure of Z-MARTE is illustrated through a case study of a communication system. We have designed a transformation tool called Z-marte Model Transformer (ZMT) based on Extensible Stylesheet Language Transformations (XSLT) to perform the automated converting from UML/MARTE to Z-MARTE models, which are then enriched with operation specifications and their dependability constraints under the Community Z Tools, version 1.5.0 (CZT) [10] environment. The formal models are analyzed by an animation tool Jaza (version 1.1) [11], to validate the expected dependability properties. The remainder of this paper is organized as follows: The related work of modeling RTESs is given in Section 2. Section 3 presents the definitions of Z-MARTE and its overall modeling procedure. Section 4 illustrates the modeling and verification method of Z-MARTE through a case study. Section 5 gives the conclusion and discusses the future work.
2
RELATED WORK
Z [12] was first proposed by Programming Design Group (PRG) in Oxford as a set-theoretic and predicate language for the specification of data structure, state spaces and state transitions. The basic construct of Z is a box structure called schema, which consists of declaration and predicate. The former introduces state spaces and local variables, and the latter defines the relationships among the variables using first-order logic. Z has been applied to numerous industrial projects, and has been integrated with other modeling
191
methods due to its simplified syntactic structure and procedure-oriented description nature. Z is suitable for describing static properties as predicates, and is verifiable with schema calculus or animation technique. ISO/IEC 13568:2002 [13] was promulgated to standardize the definition and usage of Z. Z has also been extended as Object-Z [14], Zþþ [15], etc., to support the description of ObjectOriented (OO) architecture. However, the absence of behavioral and temporal constructs in Z makes it difficult to verify their dynamic properties. It is necessary to extend Z with such elements to quadrate with dependability modeling of RTESs. TCOZ [16] integrates Object-Z and Timed CSP to specify the real-time feature of concurrent systems. Similar methods such as Real-Time Object-Z [17], which combines Object-Z and Timed Refinement Calculus, have also been studied. The combination of two formalisms enhances the expressiveness of both FSLs, but does not provide a solution to establishing the formal models from the informal requirements. It is not novel to use semi-formal methods as a primary step to advance the practical use of FSLs. The technique of mapping UML diagrams to Z is previously studied by a number of researchers. Am alio et al. [18] advocated an approach based on combining UML with Z notations to build the engineering environments for rigorous MDD. They proposed a formal language of templates using Z to support the modeling and the proof with meta-theorems. Hahn and Fischer [9] proposed an approach to formalize the semantics of Dsml4mas, a modeling language for multi-agent systems, to support the Verification & Validation (V&V) of the generated design. The static and dynamic semantics of Dsml4mas are defined using Object-Z, and the transformation method from Object-Z to OCL constraints is also presented. Kim et al. [19] integrated Object-Z with UML through model transformation, and provided an effective V&V technique within the MDA framework. Chen [20] proposed a transformation method from UML diagrams to Object-Z specifications. A transformation tool based on XML format is designed and implemented. However, these methods mapping UML to Z are not enough for us to establish a dependable RTES model. First, the modeling elements in MARTE, such as time model and NFP model, are not considered, so that the formal model obtained through the transformation is not competent to describe the features of RTESs. Second, UML lacks the operation specifications to specify the data constraints in the state transitions, so that the obtained formal model is not able to describe the dynamic features of dependability. Finally, there are no suitable constructs in Z to describe dependability features, such as security, reliability and real-time. It is necessary to extend Z with the elements of RTESs and the dependable structures at the meta-model level, to acquire the ability of modeling the dependability features of RTESs. As we mentioned in the last section, we choose Z to integrate with UML/MARTE because of its advantages in specifying the operations and their data constraints. Since Z already has multiple extensions to express the OO structure, we need to determine which one is the most suitable
192
IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING,
language for our purpose of modeling dependable RTESs. The pros and cons of choosing Z or Object-Z to integrate with UML were well discussed by N. Am alio and F. Polack [21]. The reasons why we choose Z to be the basis of ZMARTE are that it is more extensible, and its tool support is more developed than Object-Z. In Object-Z, state spaces and operations are both specified in a nested schema, which can be fully expressed by a set of Z schemas without information lost. We define the semantics for most of the OO concepts using separate schemas in Z-MARTE, and extend them with elements modeling dynamic behavior and dependable features of RTESs. Essentially, a Z-MARTE model is a Z model with fixed schemas, hence the verification methods and tools of Z [10], [11], [22], [23] can be fully adopted by Z-MARTE.
3
FORMAL DEFINITION OF Z-MARTE MODELS
The software models based on OO architecture consist of structural and behavioral views at the top level of abstraction. To add dependability features to the model, we must specify the temporal and data constraints that represent the attributes of dependability. As Z does not have the proper temporal and behavior constructs, we extend the meta-model of Z with such elements. Temporal constraints are described by Z-MARTE time model, which is derived from a set of core elements of the MARTE time model. Z-MARTE structure model and behavior model are designed to describe the structural and behavioral views of RTESs, using predicates to specify the data constraints. In Z-MARTE structure model, we introduce dependability stereotypes to tailor different attributes of dependability into state spaces, which are declared and constrained in the schemas of Z-MARTE to specify the concerned NFPs. The attributes of dependability stereotypes can be either qualitative or quantitative, because Z allows us to define free types and given sets, which are very customizable and descriptive. Taking security as an example, we could define a dependability stereotype whose attributes include crucial resource, security level, access level, etc., to model the security structure of a class or an operation. Necessary constraints such as access control or data flow control policies can be specified using these attributes. We give the formal definitions of the modeling elements of Z-MARTE using templates, which are instantiated to schemas in the procedure of formal modeling.
3.1 Time Model MARTE time model is a successor of UML and SPT (The UML Profile for Schedulability, Performance, and Time). MARTE considers a wider scope of time concept suitable for RTES modeling. In MARTE, time has physical or logical natures, which can be related to either physical time or user-defined clocks. The time instances in a model can be multiform, progressing in a non-uniform fashion [24]. MARTE time model is able to describe the relationships among these time instances. We extract a set of core elements of MARTE time model as the temporal modeling elements for RTESs in Z-MARTE.
VOL. 12,
NO. 2,
MARCH/APRIL 2015
Fig. 1. The meta-model of Z-MARTE time model.
The temporal modeling elements of Z-MARTE include clock type, clock and timed stereotypes. A clock is instantiated from a clock type by assigning its attributes such as nature, unit, resolution, offset, etc. Timed stereotypes include timed event and timed process. The former is defined as a time occurrence recorded by a clock instance, and the latter is defined as a start timed event, a finish timed event and the time duration between the two timed events. Clock instances and timed stereotypes can be bound to operations which have real-time concerns, to specify the temporal constraints of RTESs. The meta-model of Z-MARTE time model is shown in Fig. 1, where the rectangles with rounded corners refer to the core elements given above, and the ones with sharp corners refer to the basic types of Z-MARTE time model. The formal definitions of Z-MARTE time model are as follows: Definition 1. The basic type in Z-MARTE time model is TimeValueType, which includes TimeNatureType, TimeUnitType, TimeInstantType, TimeConstraint and TimeDurationType, where TimeNatureType can be assigned as dense or discretized, TimeUnitType can be either assigned as default time units {year, month, day, hour, min, s, ms} or user-defined time units, TimeInstantType and TimeDurationType is of real type, and TimeConstraint is denoted by first-order logic regarding above basic types. Definition 2. A Z-MARTE time model ZMtime ¼ ðClockType; Clock; TimedEvent; TimedProcessingÞ consists of following elements: ClockType is a set of clock types that derive all the clock instances of the system. The elements of ClockType can be ideal clock type IdealClockType, which refers to the standard physical time, or user-defined clock type ClockType. The template ClockType is composed of a state space ClockTypeState and necessary predicates, according to the structure of a Z schema. The attributes defined in the state space ClockTypeState include nature, unit type, resolution, and offset, etc. The values of these attributes are specified during the instantiation of this template. The constraints of the userdefined clock types are specified as TCs, which is a sequence of TimeConstraint. The ClockType template is defined as follows:
NI ET AL.: MODELING DEPENDABILITY FEATURES FOR REAL-TIME EMBEDDED SYSTEMS
193
TimedProcessing is a set of timed process types. The execution of a timed process refers to two points of time (start and finish instants) and a time duration of the execution. The two time instants are declared as two state spaces of timed event in the schema of timed process type TP, using subscripts to distinguish their attributes. The two timed events must refer to the same clock instance as the timed process, which is specified as a constraint in the predicate of the TP template. The TimedProcessing template is defined as follows:
In Z-MARTE templates, J refers to the state space declared in the schema as inheritance. In the above templates, all of the attributes in ClockTypeState is declared in ClockType. The element between ““ is replaceable. The notation “seq” is the sequence type in standard Z. The postfix “ClockType” is the irreplaceable part of the template name, indicating the type of the template. Clock is a set of clock instances that can be bound with timed events or processes. The attributes in its state space ClockState include unit type, clock type, referring clock (physical time or user-defined clock), and resolution, etc. A clock of a user-defined clock type must declare the clock type to specify the regarding constraints. Constraints of a clock instance are specified as TCs. The Clock template is defined as follows:
To provide a default clock instance for RTESs referring to physical time, we define idealClock of the clock type IdealClockType. The default status of Z-MARTE time model, before any user-defined clock types and clock instances, is as follows: ZMtime ¼ ðfIdealClockTypeg; fidealClockg; ; Þ:
TimedEvent is a set of timed event types. The occurrence of a timed event refers to a point of time. The attributes of the state space TimedEventState is composed of the clock instance the timed event refers to, and a time instant value. The timed event type TE also consists of the necessary temporal constraints TCs. The TimedEvent template is defined as follows:
3.2 Structure Model The formalism of the basic concepts in UML class diagram, including class, attribute, operation, and association, etc., is studied by many researchers [19], [20]. However, the elements representing RTESs’ features, such as time model, are not taken into consideration in previous works. Besides, the formal model converted from UML/MARTE lacks the operation specifications to describe the data constraints during the state transitions, which represent the attributes of dependability. Consequently, we must extend the formal model with such elements, to establish dependable models with rigorous semantics for RTESs. Z-MARTE structure model presents the OO architecture to coordinate with UML/MARTE model, and specifies the data constraints in the targeted system. We define the basic elements of the UML class diagram and the NFP concepts of MARTE as templates, using the operation schemas of Z to specify the data constraints representing the attributes of dependability. The meta-model of Z-MARTE structure model is shown in Fig. 2, which includes most of the OO concepts we need to describe the structure of RTESs. The element TimedProcessing is related to Operation, indicating the relationship between Z-MARTE time model and structure model is that the former provides temporal constraints to the latter. Compared with Object-Z [14], the inheritance of class in ZMARTE is expressed by declaring the state spaces, which makes the structure of Z-MARTE schemas more simplified and verifiable, as stated by N. Am alio and F. Polack [21].
194
IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING,
VOL. 12,
NO. 2,
MARCH/APRIL 2015
Class is a set of system classes. The template of Class is composed of a class state space, attributes (necessary local variables used to specify the invariants), operations, associations and invariants. Dependability stereotypes can also be declared as state spaces < sNamei > Statei in the schema of Class to provide additional dependability constraints. The Class template is defined as follows:
Fig. 2. The meta-model of Z-MARTE structure model.
The formal definitions of Z-MARTE structure model are as follows: Definition 3. The basic types in Z-MARTE structure model are Property and Constraint. Property types include Attribute, GlobalVariable and Parameter, and Constraint types include Invariant and Predicate. Definition 4. A Z-MARTE structure model ZMstructure ¼ ðDataType; GlobalVar; State; Class; Asso; OperationÞ
Asso is a set of class associations as a part of Class schema. Attributes of Asso include association end (a class name on the other side of the association), association kind (including association, dependency, aggregation, and composition), and multiplicity (a set of integers or “”). Asso provides certain information for the verification based on dependability stereotypes, for example, the information of data flow for security verification, and the multiplicity between redundancy modules and repair modules for reliability verification. The Asso template is defined as follows:
consists of following elements: DataType is a set of user-defined data types. The DataType template is defined as follows: ½½½data Typei : In the above template, the element between “½½” and “” is optional, and the element with the subscript i is repeatable. GlobalVar is a set of global variables. The template of GlobalVar is composed of the declaration of the variable and necessary invariants. The GlobalVar template is defined as follows:
Operation is a set of operations. Each of the operations inherits a State schema of a class. The attributes of Operation include state spaces, input/output parameters, pre/postconditions, and temporal constraints. Particularly, the state spaces declared in Operation schema can be class states, dependability stereotypes, and timed stereotypes. The bound timed stereotypes provide attributes for the temporal constraints of the operations. The Operation template is defined as follows:
State is a set of state spaces, which specifies a combination of attributes and their constraints for the system classes or stereotypes that we need to describe certain structure. The State template is defined as follows:
To extend Z with dependability constructs in a modular way, we use state spaces to define dependability stereotypes. Binding with classes or operations of Z-MARTE models, dependability stereotypes are used to specify the data constraints representing the attributes of dependability.
In the above template, D is used to declare a changed state space, that is, all the attributes in both the pre- and post- state spaces. The attributes of the post-state space are attached with a single quotation mark. The variables with a
NI ET AL.: MODELING DEPENDABILITY FEATURES FOR REAL-TIME EMBEDDED SYSTEMS
195
DClock is a set of clock instances, which is a subset of Clock of Z-MARTE time model. The formal definition of Clock is in Section 3.1, Definition 2. Object is a set of instantiations of classes in Class, therefore we must declare the state space of the inherited class in the Object schema and assign the values of its attributes. The Object template is defined as follows:
Fig. 3. The meta-model of Z-MARTE behavior model.
question mark indicate the input parameters, and the ones with an exclamation mark indicate the output parameters.
3.3 Behavior Model The modeling and verification methods towards software behavior is mostly based on automata as the state transition model, for example, the UML state machine [25] and timed automata [26], [27]. These methods describe software behavior as sequences of state transitions, but could not describe the accurate data constraints within these transitions. Besides, the existing behavior models are loosely coupled with the structure models. We define Z-MARTE behavior model using the basic elements of automata, which are bound with the schemas of Z-MARTE time/ structure models to extend the ability of modeling data constraints in the behavior of RTESs. In our consideration of dependability, the behavior of RTESs is considered as the executions of operations and their impact on the system states. The state of a system represents the states of all the current objects. The state of an object is an instantiation of the state space of its class, which is defined previously in Z-MARTE structure model. Z-MARTE behavior model is based on automata, thus could be mapped from a simple UML state machine, allowing our formal model to be compliant with the semi-formal models. In Z-MARTE behavior model, a transition consists of a source state, a target state and an action with temporal and data conditions (or guards in the automata theory). A Z-MARTE behavior model refers to a set of clocks, so that the temporal constraints of the transitions can be specified by the schemas of Z-MARTE time model and further be verified. The data constraints are specified by the bound schemas of Z-MARTE structure model. Fig. 3 shows the meta-model of Z-MARTE behavior model and its relationships with Z-MARTE time/structure models. The three models are tightly coupled because their elements are bound together, so that we can expediently check the consistency among the different views of a system. The formal definitions of Z-MARTE behavior model are as follows: Definition 5. A Z-MARTE behavior model ZMbehavior ¼ ðDClock; Object; StateVertex; TransitionÞ consists of following elements:
StateVertex is a set of instantiations of states in State. A state vertex could be the source or target of a state transition, using entry/exit operations to describe the necessary actions before or after the transition. If a state vertex is an initial state, the attribute isStart must be assigned 1, otherwise assigned 0. In the process of building the behavior model, the corresponding object Ob and the operations defined earlier in the structure model are declared. The StateVertex template is defined as follows:
Transition is a set of state transitions describing the behavior of RTESs. A transition consists of the source and target state vertexes, an action derived from Operation of ZMARTE structure model and temporal constraints TCs that derived from the real-time requirements of the action. The action is declared as Op, and can be omitted if a transition is not triggered by any actions. The Transition template is defined as follows:
3.4 Modeling Procedure of Z-MARTE The relationships between the three models of Z-MARTE are shown in Fig. 4. Z-MARTE time model provides the temporal modeling elements, such as timed processing types, to specify the temporal constraints of the operations in Z-MARTE structure/behavior model. Z-MARTE structure model provides the basic constructs of the OO structure, the operation specification, and the data constraints representing dependability for Z-MARTE behavior model. Z-MARTE behavior model is bound with the elements of ZMARTE time/structure, to specify the temporal/data constraints of the behavior of RTESs. Because of the flexibility
196
IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING,
Fig. 4. Relationship between Z-MARTE models.
and descriptive nature of Z, Z-MARTE models are highly suitable to model dependable RTESs, compared with the existing formal methods. In order to perform the modeling and verification of Z-MARTE models, we must integrate the semi-formal modeling environment for MARTE and the formal modeling environment for Z by a model transformation procedure. The model transformation rules from UML functional models to Z/Object-Z have already been studied by many researchers [19], [20]. However, the mapping between Z constructs and MARTE modeling elements, such as elements for NFPs and timed concepts, has not been considered in the existing works. In this paper, we have designed and implemented a transformation tool Z-marte Model Transformer based on Extensible Stylesheet Language Transformations technique, converting UML/MARTE models generated by the OpenEmbeDD platform [28] to Z-MARTE schemas to automate our modeling procedure. Because UML/MARTE lacks the operation specifications, we can only convert the basic structure and the attributes of NFPs into Z-MARTE schemas. These preliminary schemas are then complemented with the operation specifications and dependability constraints under the environment of Community Z Tools, version 1.5.0 [10]. Here we present the three steps of the modeling procedure for RTESs based on Z-MARTE. The mapping relationships between UML/MARTE and Z-MARTE elements in ZMT are detailed in these steps. 1.
2.
3.
Requirement analysis. Design the software components according to the functional requirements. Determine the dependability features of the system, and give the expressions of the required dependability properties or constraints of the system. Semi-formal modeling. Build the UML diagrams of the system according to the designed components from step 1. Add RTESs’ features and NFPs to the diagrams using the MARTE profile. Specifying Z-MARTE models. Map the diagrams from step 2, or dependability-critical sub-diagrams, to the corresponding Z-MARTE templates to generate the preliminary Z-MARTE schemas. Complete ZMARTE models by specifying the operation specifications and dependability constraints of the system. 3.1. Map the clock instances and their relations to ZMARTE time model, and define the corresponding timed stereotypes in Z-MARTE time model. 3.2. Map the data types, global variables, and classes of the class diagram to Z-MARTE structure
VOL. 12,
NO. 2,
MARCH/APRIL 2015
model. Define dependability stereotypes according to the required dependability features, and specify the operation specifications and dependability constraints of the system. 3.3. Map the state vertexes, actions, and transitions of the statechart diagram to Z-MARTE behavior model. Define the objects and bind them with the state vertexes. Specify the temporal and data constraints in the transitions according to the operation specifications. It is our ultimate goal to obtain more verifiable models of RTESs using Z-MARTE and to analyze the expected dependability properties of them. The extended elements in Z-MARTE enable us to check the inconsistency between the dependability constraints in the structure and behavior models of RTESs. As we mentioned in Section 2, we choose Z to integrate with UML/MARTE in order to adopt its mature verification methods to our model. Formal analysis on Z-MARTE can be done by many existing verification tools, including the theorem proving tools [22] and the animation tools [10], [11], [23]. There are a lot of previous verification experiences on Z using these tools [29], [30], [31].
4
ILLUSTRATION
The methodology proposed in this paper is illustrated through a case study. According to the modeling procedure presented in Section 3.4, we show how Z-MARTE models are established, and how the concerned dependability properties are analyzed. In this paper, the UML/MARTE diagrams are generated on the platform of OpenEmbeDD [28], and transformed into a set of preliminary schemas of Z-MARTE, which are edited under the environment of Community Z Tools, version 1.5.0 [10]. We have designed and implemented a transformation tool ZMT (Z-marte Model Transformer) to support the automatic conversion from the UML/MARTE models to the Z-MARTE schemas. The converted and complemented formal model is verified by the animation tool Jaza (version 1.1) [11]. Alternative tools include ZLive [32], whose current version has an insufficient coverage of the necessary Z constructs, compared with Jaza.
4.1 Requirement Analysis Andre et al. [24] used a communication system as a case study of the usage of MARTE time model. We detailed the function and dependability requirements of this system to illustrate our modeling method of Z-MARTE. The communication system is designed to collect data from a collect module to a process module by performing the writing/reading operations to a shared memory. We take the case of an immediate communication with undersampling (the collecting module is dispatched twice faster than the processing module), according to Andre’s design. Dependability requirements of our system include: 1.
The dispatch time of the collecting module is 1 ms, and that of the processing module is 2 ms. Assume that the delay of communication between processes
NI ET AL.: MODELING DEPENDABILITY FEATURES FOR REAL-TIME EMBEDDED SYSTEMS
197
Fig. 6. State machine of the communication system.
Fig. 5. Class diagram of the communication system.
2.
3.
is negligible compared with the dispatch time of the modules. The shared memory has a size limit of 10 units of data. And the processing of the data queue obeys the rule of First Input First Output (FIFO). An access control policy is required to protect data from any unauthorized tampering, thus to achieve certain level of security. In our case, a simple authority check policy is required to be applied before any execution of operations. The access levels of the data are denoted by 0 to 3, representing four confidentiality levels from low to high.
4.2 Semi-Formal Modeling The class diagram of the system is shown in Fig. 5. The classes of the system include Collector, Buffer, and Processor. The state machine of the system is given in Fig. 6 to clarify the whole procedure of the communication through the buffer. Collector and Processor refer to different clock instances in the allocation view of the system, which is not presented in this paper. There is no formal notation in UML/MARTE to specify proper constraints in the operations and how the variables in the system states change after the executions of operations. In our case study, as demonstrated in Fig. 5, we are able to specify the security structure of the system as a MARTE NFP type SecLevel. However, the loose coupling between the diagrams makes it difficult to specify either how writing/reading operations change the state of Buffer or the data conditions of their execution. As a result, we cannot analyze or evaluate their impact on the dependability properties of the system, such as the required security policy, in the phase of semi-formal modeling. 4.3 Specifying Z-MARTE Time Model Z-MARTE time model of the communication system is specified as follows: 0 1 fChronometricClockType; IdealClockTypeg; ZMtime ¼ @ fcClock; pClock; idealClockg; fcTE; pTE g; A: fcTP; pTP g ClockType and Clock First, we specify ChronometricClockType, a clock type which is discrete and not logical (therefore chronometric). Then we define two clock instances cClock and pClock of this type for Collector and Processor, respectively. These two
clocks are identical, with the unit of microsecond and the resolution of 0.01. They both refer to idealClock, a given dense clock modeling the physical time. The schemas of ChronometricClockType and cClock are defined as follows. The schema of pClock is omitted.
TimedEvent and TimedProcessing The timed event types and timed process types used in the system are referring to cClock or pClock, respectively. We give the two types cTE and cTP referring to cClock as follows. The schemas of pTE and pTP are omitted.
4.4 Specifying Z-MARTE Structure Model The basic elements of a UML/MARTE class diagram are intuitively mapped to Z-MARTE structure model. The ability to describe dependability features will be enhanced after completing Z-MARTE structure model with the extensions we defined earlier for dependable RTESs. The completed ZMARTE structure model is as follows: 0 1 fDatag; fDataSLg; B fCState; BState; PState; SecStateg; C B C C: f CClass; BClass; PClass g; ZMstructure ¼ B B C @ fCBAsso; BCAsso; PBAsso; BPAssog; A fwriteOp; readOpg
198
IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING,
We present some of the key schemas in Z-MARTE structure model to explain the instantiation of the templates: DataType. The user-defined data type in the system is Data, which is a set of integers. The schemas to declare DataType are defined as follows:
VOL. 12,
NO. 2,
MARCH/APRIL 2015
Class. The classes of the system are also mapped from the class diagram. These classes are defined as follows:
½Data Data ¼ fiji 2 Ng: GlobalVariable. In order to describe the security requirement given in Section 4.1, we set a global variable to describe the access level of Data, which will be checked before any execution of operations. Assuming that the access level of Data is 1, therefore the global variable DataSL is described as follows:
State. The state spaces of the classes are directly mapped from the class diagram. Schemas in State are defined as follows:
In the BState schema, the symbol “#” is used to denote the size of a set. Dependability stereotype. The constraints of security in our case study cannot be specified by the above definitions, because we do not have any additional structure in the basic modeling elements of Z-MARTE to describe the access control policy. In order to define this additional structure, we set an access level for each operation as an authority, which is obtained by a function getSL, and ensure that we check the value before the execution of the operation. Besides, we can record the data flow between the modules for further analysis or process, such as security log or data interception, through a function getOutputClass. We define this security structure as a dependability stereotype named SecState containing these functions, which is defined as follows:
Asso. The associations of classes are derived from the class diagram, too. For example, the association CBAsso between Collector and Buffer is defined as follows:
Operation. The operation specification is significant to the modeling and verification of dependability features in ZMARTE. In an operation schema, we declare the timed processing types (pTE and pTP) to constrain its execution time and period, and dependability stereotypes (SecState) to specify certain data constraints. In our case study, the access control policy is described by declaring SecState in the operation, and specifying a precondition to check the value of DataSL and the access level of this operation. The schemas of writeOp and readOp are as follows:
NI ET AL.: MODELING DEPENDABILITY FEATURES FOR REAL-TIME EMBEDDED SYSTEMS
199
the schemas related to transition EWNT to explain the procedure of defining Z-MARTE behavior model: DClock. The clocks in Z-MARTE behavior model are the clocks referred by all its operations, which are cClock and pClock in our case. Their schemas have been defined previously, thus are omitted here. Object. The object in this Z-MARTE behavior model is the instantiation of the state space of Buffer, because its state represents the state of the whole system. The object Buffer is defined as follows:
StateVertex. The source state vertex of EWNT is EVtx, which represents the state when dataSet of Buffer is empty. The target state vertex is NVtx, which represents the state when dataSet is not empty. The definitions of these state vertexes are as follows:
Fig. 7. The established Z-MARTE models in CZT.
Transition. The action triggers EWNT is writeOp. Temporal constraints in EWNT are specified by writeOp, which is defined earlier in Z-MARTE structure model. The schema of EWNT is defined as below:
In the schema of writeOp, the preconditions are “timeOccur1 ¼ 1” and “DataSL getSL (writeOp)”. The schema of readOp is similar to writeOp.
4.5 Specifying Z-MARTE Behavior Model The basic elements of UML/MARTE state machine are intuitively mapped to Z-MARTE behavior model. After the mapping process, we can complete this model by binding State and Operation of Z-MARTE structure model to the state vertexes and transitions. Temporal and data constraints are specified by the attached schemas. The completed ZMARTE behavior model is as follows: 0
ZMbehavior
1 fcClock; pClockg; fBObg; A ¼ @ fSVtx; EVtx; NVtx; EndVtxg; fSET; EWNT; NWNT; NRNT; NRET; EEndT g
The name of a transition in this paper is the conjunction of the initials of a source state vertex, an action, a target state vertex, and a postfix T . The initial of the action can be omitted if the transition is not triggered by any actions. We give
4.6 Verification on Z-MARTE Z-MARTE models are converted from UML/MARTE and complemented under the environment of CZT [10], which is shown in Fig. 7. CZT supports LATEX as one of the standard exchange formats. Therefore, we are able to use an animation tool Jaza [11] to analyze the concerned properties of our case study. Animation is used to validate Z models based on the inquiry of operation sequences. Jaza is able to return the changed system state in LATEX format, according to an initialized system state and the inputs of the inquired operations. If any operation cannot be accepted by the constraints in the current system state, Jaza returns “No solutions”. In this paper, our analysis is primarily based on checking the inconsistency between the dependability constraints in the structure and behavior models of
200
IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING,
Fig. 8. Two of the tested execution patterns.
RTESs. During this procedure, the input sequence of operations must be accepted by Z-MARTE behavior model, that is, operations in the acceptable sequence should be actions in a legal transition sequence. If an operation is rejected by Jaza, we are able to discover the inconsistencies among the dependability constraints in the system specification.
4.6.1 Real-Time Property The real-time property is represented by the dispatch pattern of Collector and Processor. Z-MARTE behavior model enriches Z with dynamic modeling elements, enabling us to simulate the dispatch pattern of these two components. Z-MARTE time model provides some timerelated elements to describe the temporal constraints in their dispatch behavior, such as time occurrences and time durations. However, in the verification phase, we are only able to verify the real-time designs and some of the constraints in our model, because there is no timed constructs such as timers in the existing Z tools. We can manually input the time instants as the values of getTime attribute of clocks, to simulate the time occurrences. Consider the timed processes writeOp and readOp, and the two identical but separate clocks cClock and pClock they refer to. Because cClock and pClock are both referring to idealClock and have no offset, we can obtain the execution time sequences of writeOp and readOp according to their temporal constraints. The temporal constraints in writeOp are the precondition “timeOccur1 ¼ 1”, which constrains the start time of writeOp as every 1 ms, and the postcondition “setTime ¼ 0”, which resets cClock and starts the next execution period of writeOp. Similarly, the start time constraint of readOp is “timeOccur1 ¼ 2”, indicating an execution of the read action in every 2 ms. Different patterns can be checked by using Jaza, input with various sequences of operations, to verify their validity. Two of the tested patterns are intuitively given in Fig. 8, using timelines of the clocks defined in our model. The black dots on the timelines indicate the execution time of the operations. The results of the example pattern in Fig. 8 (a) are as follows:
VOL. 12,
NO. 2,
MARCH/APRIL 2015
In the above animation procedure, Jaza rejected the second operation readOp due to the violation to the constraint “timeOccur1 ¼ 2”. According to the temporal and data constraints in our specification, the only accepted execution pattern is shown in Fig. 8 (b). The dispatch of writeOp is twice faster than that of readOp, which is consistent with Requirement 1. However, some of the flaws in the run-time behavior are temporary beyond our detection scope, since we cannot assure the coverage of all the paths in the behavior model in the procedure of animation. The behavior verification could be more systematic and automatic, if we add some constructs of timed automata into Z-MARTE behavior model and enable the model checking of the timed transition system, which is our next goal on the study of Z-MARTE.
4.6.2 Security Property The verifiability of data constraints within the formal models, on the other hand, is what motivated us to integrate Z notation into the methodology. First of all, we validate the required access control policy, which is modeled using a function getSL in SecState. We set its elements in the initiation schema of our models:
The above inputs set the access levels of writeOp and readOp as 1 and 2, respectively. By the inquiries of writeOp and readOp, we can verify that whether these operations can be executed only when their access levels are equal as or higher than the global variable DataSL, the access level of Data. When the value of DataSL is initialized as 1, the results from Jaza are as follows:
NI ET AL.: MODELING DEPENDABILITY FEATURES FOR REAL-TIME EMBEDDED SYSTEMS
201
When we change the initialization of DataSL to 2, Jaza returns “No solutions” to the inquiry of writeOp. We can see from the optimized operation schema returned by the why command that the execution is rejected due to the false predicate “1 2”, which is consistent with Requirement 3:
The schema of w1 w2 r and the above animation results both indicate that every time the dispatch pattern is executed, there are two units of data added to the end of the sequence dataSet, and there is one unit of data removed from the top of it. It is obvious that the repetition of this pattern will increase the size of dataSet. When this pattern is executed repeatedly, we will encounter a violation against Requirement 2 depending on the size limit of Buffer, which is set as 10 units of data in our case study. The results of the rejected operation are as follows: Second, we analyze the impact of the system behavior on the security property, by inputting an execution sequence of operations according to the dispatch pattern as Fig. 8 (b). Assume that there is no draft between the clocks, and the operation writeOp is executed prior to readOp. Because Z allows operations to be combined using schema calculus to describe more comprehensive system behavior, we give a schema w1 w2 r of the combined three operations in the pattern “writeOp, writeOp, readOp” as follows, to explicitly explain their impact on the system state:
In the schema of w1 w2 r, we use asterisks to denote the intermediate states of the variables, and single quotation marks to denote the final states of the variables. The results of the execution of this pattern on an empty Buffer is as follows:
We can now draw the conclusion of our analysis: the inquired sequence of operations is a legitimate input of the established Z-MARTE behavior model, but will cause an overflow of dataSet, and violate the invariant of the schema BState. After identifying and locating the potential flaw, we must find a way to correct our specification. In order to maintain the security property, the system needs to either resistant or tolerant the input that can cause the failure. Although the operation readOp have a precondition to check whether dataSet is empty before reading data from it, the operation writeOp does not check whether dataSet have any space to write into. Accordingly, this flaw can be fixed by adding a precondition “#dataSet < 10” in writeOp. Another method to fix this flaw is to add a state and a
202
IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING,
transition from NVtx in Z-MARTE behavior model, preventing the system from deadlocks or entering unknown states.
[4] [5]
5
CONCLUSION
This paper proposes Z-MARTE time model, structure model, and behavior model, specifying the necessary data constraints to present the expected dependability properties in both structural and behavioral views of RTESs. We extend the meta-model of Z with timed elements and dynamic elements to enhance its dynamic modeling ability. We also define an OO structure of Z-MARTE with the extensions of operation specifications and dependability stereotypes, using some of the core elements of MARTE for reference. The tight coupling between Z-MARTE time/structure/ behavior models enables us to validate the inconsistency between the dependability constraints in the system specifications using the existing tools. Semi-formal methods are not suitable for rigorous verification, while the existing formal methods are not sufficient for capturing both static and dynamic features of dependable RTESs. Our modeling and verification procedure based on Z-MARTE is able to build a bridge between the semi-formal and formal methods, enhancing both the verifiability of the semi-formal method and the practical usage of the formal method. UML/MARTE elements are converted to the corresponding schemas of Z-MARTE, using a model transformation tool we design called ZMT. The converted schemas are then completed with the extended construct, under the CZT environment. The verification is performed using an animation tool Jaza in this paper. Illustration on a case study of a communication system shows that the usage of Z-MARTE is effective at modeling and verifying most of the dependability requirements, especially those that can be fully described as invariants. To provide more integrated description for RTESs, other modeling elements of RTESs such as physical resources and allocation structures will be included in Z-MARTE in our future work. The model checking method towards the dependable behavior of RTESs by combining Z-MARTE behavior model with timed automata is also in our vision, to enhance the verifiability of the dynamic properties modeled by Z-MARTE.
ACKNOWLEDGMENTS This work was supported by the National Natural Science Foundation for Youth of China under Grant No. 61202351, the Aviation Science Fund of China under Grant No. 20128052064, and the Funding of Jiangsu Innovation Program for Graduate Education under Grant No. CXLX12_0163.
[6] [7] [8] [9]
[10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29]
REFERENCES [1]
[2] [3]
A. Avizienis, J.-C. Laprie, B. Randell, and C. Landwehr, “Basic concepts and taxonomy of dependable and secure computing,” IEEE Trans. Dependable Secure Comput., vol. 1, no. 1, pp. 11–33, Jan.-Mar. 2004. X. Liu, B. Lang, and B. Xie, “Software trustworthiness classification specification,” Tech. Rep. TRUSTIE-STC V 2.0, National University of Defense Technology, Changsha, China, May 2009. UML Profile for MARTE: Modeling and Analysis of Real-Time Embedded Systems. Version 1.1, Jun, 2011..
[30] [31] [32]
VOL. 12,
NO. 2,
MARCH/APRIL 2015
J. J€ urjens, H. Hussmann, and S. Cook, “UMLsec: Extending UML for secure systems development,” in Proc. 5th Int. Conf. Unified Model. Language, 2002, pp. 412–425. T. Lodderstedt, D. Basin, and J. Doser, “SecureUML: A UMLbased modeling language for model-driven security,” in Proc. 5th Int. Conf. Unified Model. Language, 2002, pp. 426–441. S. Bernardi, J. Merseguer, and D. C. Petriu, “A dependability profile within MARTE,” Softw. Syst. Model., vol. 10, no. 3, pp. 313–336, 2011. R. Soley, OMG Model Driven ArchitectureTM , Object Manage. Group, Needham, MA, USA, 2000. M. Broy, M. L. Crane, J. Dingel, A. Hartman, B. Rumpe, and B. Selic, “2nd UML 2 semantics symposium: Formal semantics for UML,” in Proc. Int. Conf. Models Softw. Eng., 2007, pp. 318–323. C. Hahn and K. Fischer, “The formal semantics of the domain specific modeling language for multiagent systems,” in Agent-Oriented Software Engineering IX, New York, NY, USA: Springer, 2009 pp. 145–158. (2013). CZT: Community Z tools (2.0 preview) [Online]. Available: http://czt.sourceforge.net/ M. Utting. (2005). JAZA: Just another z animator [Online]. Available: http://www.cs.waikato.ac.nz/marku/jaza/. J. M. Spivey, The Z Notation: A Reference Manual. Englewood Cliffs, NJ, USA: Prentice-Hall, 1992. ISO/IEC 13568(E), “Information technology–Z formal specification notation–Syntax, type system and semantics,” ISO, pp. 1–196, Jul. 2002. G. Smith, “The Object-Z specification language,” Software Verification Research Centre, Univ. Queensland, Brisbane, Queensland, Australia, Jul. 1999. K. Lano and H. Haughton, "The Zþþ manual" Lloyd’s Register of Shipping, London, U.K., 1994. B. Mahony and J. S. Dong, “Timed communicating object Z,” IEEE Trans. Softw. Eng., vol. 26, no. 2, pp. 150–177, Feb. 2000. G. Smith and I. Hayes, “An introduction to real-time object-Z,” Formal Aspects Comput., vol. 13, no. 2, pp. 128–141, 2002. N. Amalio, F. Polack, and S. Stepney, “Frameworks based on templates for rigorous model-driven development,” Electron. Notes Theoretical Comput. Sci. 191, vol. 191, pp. 3–23, 2007. S. K. Kim, D. Burger, and D. Carrington, “An MDA approach towards integrating formal and informal modeling languages,” in Proc. Int. Conf. Formal Methods, 2005, pp. 448–464. Y. H. Chen, “The study of construction and validation of objectoriented formal specification,” Ph.D. thesis, School Comput. Eng. Sci., Shanghai Univ., Shanghai, China, 2007. N. Amalio and F. Polack, “Comparison of formalisation approaches of UML class constructs in Z and object-Z,” in Proc. 3rd Int. Conf. Formal Specification Develop. Z B, 2003, pp. 339–358. I. Meisels and M. Saaltink, “The Z/EVES Reference Manual (for Version 1.5),” Reference manual, ORA Canada, 1997. (2013). ProB Homepage [Online]. Available: http://www.stups. uni-duesseldorf.de/ProB/index.php5/Main_Page C. Andre, F. Mallet, and R. De Simone, “Modeling time (s),” in Proc. 10th Int. Conf. Model Driven Eng. Language Syst., 2007, pp. 559–573. S. K. Kim and D. Carrington, “A formal metamodeling approach to a transformation between the UML state machine and ObjectZ,” in Proc. Int. Conf. Formal Methods Softw. Eng., 2002, pp. 548–560. P.-A. Hsiung, Y.-R. Chen, and Y.-H. Lin, “Model checking safetycritical systems using safecharts,” IEEE Trans. Comput., vol. 56, no. 5, pp. 692–705, May. 2007. C. Miller, “Bounded model checking of incomplete networks of timed automata,” in Proc. 11th Int. Workshop Microprocessor Test Verification, Dec. 2010, pp. 61–66. (2009). OpenEmbeDD home: Model driven engineering opensource platform for real-time & embedded systems [Online]. Available: http://openembedd.org/home_html N. Qamar, Y. Ledru, and A. Idani, “Validation of security-design models using Z,” in Proc. 13th Int. Conf. Formal Methods Softw. Eng., 2011, pp. 259–274. S. Kallel, M. H. Kacem, and M. Jmaiel, “Modeling and enforcing invariants of dynamic software architectures,” Softw. Syst. Model., vol. 11, no. 1, pp. 127–149, 2012. D. Plagge and M. Leuschel, “Validating B, Z and TLAþ using ProB and Kodkod,” in Proc. Int. Symp. Formal Methods, 2012, pp. 372–386. (2006). ZLive animator [Online]. Available: http://czt.sourceforge.net/zlive/index.html
NI ET AL.: MODELING DEPENDABILITY FEATURES FOR REAL-TIME EMBEDDED SYSTEMS
203
Siru Ni received the BS degree in information security from the Nanjing University of Aeronautics and Astronautics in 2009. She is currently working toward the PhD degree at the College of Computer Science and Technology, Nanjing University of Aeronautics and Astronautics. Her research interests include dependable computing, software engineering, and formal methods. She is a student member of the ACM (No.3110484) and CCF (No. E200030669G).
Zining Cao received the BS, MS, and PhD degrees in 1995, 1998, and 2001, respectively. He is a teacher at the Nanjing University of Aeronautics and Astronautics since 2004. He is currently a professor in the College of Computer Science and Technology. He has published more than 30 papers. His current research interests include formal methods and logic in computer science.
Yi Zhuang received the graduate degree from the Department of Computer Science, Nanjing University of Aeronautics and Astronautics in 1981. She is currently a PhD supervisor in the Nanjing University of Aeronautics and Astronautics. Her research interests include network and distributed computing, and information security.
Xiangying Kong received the BS degree from Xi’an Jiaotong University in 1995, the MS degree from China Ship Research and Development Academy in 1998, and is currently working toward the PhD degree at the Nanjing University of Aeronautics and Astronautics. He is with the Jiangsu Automation Research Institute since 1998. He is an editorial board member and a researcher of command control and dimulation. His current research interests include dependable computing and real-time embedded systems.
" For more information on this or any other computing topic, please visit our Digital Library at www.computer.org/publications/dlib.
