Received May 21, 2020, accepted May 29, 2020, date of publication June 2, 2020, date of current version

June 15, 2020.

Digital Object Identifier 10.1109/ACCESS.2020.2999544

A Unified Model-Based Framework for the

Simplified Execution of Static and Dynamic
Assertion-Based Verification
MUHAMMAD WASEEM ANWAR 1 , MUHAMMAD RASHID 2 , (Member, IEEE),
FAROOQUE AZAM 1 , AAMIR NAEEM 1 , MUHAMMAD KASHIF 3 ,
AND WASI HAIDER BUTT 1
1 Department of Computer and Software Engineering, CEME, National University of Sciences and Technology (NUST), Islamabad 44000, Pakistan
2 Computer Engineering Department, Umm Al-Qura University, Makkah 21955, Saudi Arabia
3 College of Computer Science and Engineering, Hamad Bin Khalifa University, Doha, Qatar
Corresponding author: Muhammad Waseem Anwar ([email protected])

ABSTRACT The improved productivity and reduced time-to-market are essential requirements for the
development of modern embedded systems and, therefore, the comprehensive as well as timely design
verification is critical. Assertion Based Verification (ABV) is a renowned paradigm to timely achieve an
optimum test coverage, either through static or dynamic techniques. However, the major limitation with ABV
is its inherited low-level implementation complexity. In order to simplify its execution, various Model Based
System Engineering approaches provide a higher abstraction layer. Nevertheless, the complete verification
requirements, targeting the static as well as dynamic ABV at the same time in a unified framework, are
not being addressed. Furthermore, the dynamic verification support is provided through some traditional
languages (like C, Verilog) where the advanced ABV features cannot be exploited. Consequently, this
article introduces the MODEVES (MOdel-based DEsign Verification for Embedded Systems) framework
to simultaneously support the static and dynamic ABV. Particularly, the UML (Unified Modeling Language)
and SysML (Systems Modeling Language) diagrams are used to model the structural and behavioral require-
ments. Moreover, the NLCTL (Natural Language for Computation Tree Logic) is proposed to include the
verification requirements for static ABV while the SVOCL (SystemVerilog in Object Constraint Language)
is used to represent the dynamic verification constraints. An open source transformation engine is developed
to automatically generate the SystemVerilog Register Transfer Level (RTL) code, Timed Automata model,
SystemVerilog assertions and Computation Tree Logic (CTL) assertions with minimum transformation
losses. The significance of the MODEVES framework is established through several case studies and the
quantitative analysis shows an improvement of almost 100% in design productivity, as compared to the
conventional low-level implementations.

INDEX TERMS Assertion based verification, computation tree logic, embedded systems, model based
system engineering, systemverilog assertions, timed automata, unified modeling language (UML).

I. INTRODUCTION is generally classified into static and dynamic verification

The complexity and demand of embedded systems have categories [2]. The static verification techniques deal with
increased exponentially. In order to manage the reduced the mathematical models to verify the correctness of sys-
time-to-market and improved productivity goals, the com- tem design [3]. On the other hand, the dynamic verification
prehensive design verification in an optimal time duration techniques are based on the simulation of Register Transfer
is critical [1]. The design verification of embedded systems Level (RTL) code for system validation. Although, the static
verification techniques provide some sophisticated features,
The associate editor coordinating the review of this manuscript and the issues like state explosion problem [4] and the reliable
approving it for publication was Wen-Sheng Zhao . tool support restrict their applicability on large and complex

This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/
VOLUME 8, 2020 104407
 M. W. Anwar et al.: Unified Model-Based Framework for the Simplified Execution of Static and Dynamic ABV

designs. Similarly, an exhaustive testing is required for the To the best of our knowledge (Section V), an MBSE frame-
dynamic verification process to achieve the maximum test work to support both static and dynamic ABV, by means of a
coverage [5]. well-known Timed Automata formalism and SystemVerilog
In order to address the limitations of conventional static language respectively, is hard to find in the literature and
and dynamic verification techniques, Assertion Based Veri- industrial projects.
fication (ABV) is employed which deals with the functional
properties (assertions) of the system in a reduced simulation B. THE PROPOSED FRAMEWORK
time [6], [7]. The two major types of ABV are static and In order to address the limitations of existing frameworks, this
dynamic [8]. In static ABV, the desired assertions are verified article has proposed the MODEVES (MOdel-based DEsign
through formal methods. In this regard, Timed Automata [9] Verification for Embedded Systems) framework. The objec-
is a renowned formalism, particularly designed to validate tive is to improve the design productivity (Section IV-D)
the correctness of critical temporal aspects. On the other by providing a higher abstraction layer for both static and
hand, the code of hardware design languages at RTL is dynamic ABV, where the design as well as verification
simulated to perform dynamic ABV. However, in traditional aspects are modeled collectively. Particularly, the idea is to
hardware languages (Verilog, VHDL), ABV is not inherently enable the accurate transformation of a single/unified design
supported [10], [11] as such languages mainly deal with model into SystemVerilog and Timed Automata simultane-
the system design only. In this context, SystemVerilog [12] ously. Furthermore, the verification properties included in the
is an increasingly popular language that operates at RTL high-level models are also transformed into SVAs and CTL
and provides dynamic ABV support through SystemVerilog assertions.
Assertions (SVAs). The overview of MODEVES framework is shown
Despite the effectiveness of ABV in improving the design in Figure 1. A complete end-to-end MODEVES Modeling
verification process, its low-level implementation complexi- Methodology (MMM) is introduced in Section II to model
ties result in several verification delays [30]. In this regard, the structural, behavioral and verification (static as well as
Model Based System Engineering (MBSE) plays an impor- dynamic) requirements collectively. Particularly, a UML and
tant role by providing a higher abstraction layer [2]. It first SysML based approach is introduced to model the system
deals with the modeling phase to capture the design require- design (Section II-A) i.e. Block Definition Diagram (BDD)
ments and constraints at higher abstraction level (source concepts are used to represent the system structure and
models). Subsequently, a transformation phase is employed State Machine Diagram (SMD) concepts are employed to
to automatically transform the source models into the target represent the system behavior. Moreover, the NLCTL (Nat-
models at lower level of abstraction. Finally, the design veri- ural Language for Computation Tree Logic) is proposed
fication (formal and/or dynamic) can be instantly performed (Section II-B) to include the verification properties for static
through the automatically generated code. The Object Man- verification. Furthermore, the SVOCL [15] is integrated in
agement Group (OMG) has introduced a standard Unified the framework for dynamic verification constraints.
Modeling Language (UML) profile and its extensions like Once the modeling of design and verification aspects
Systems Modeling Language (SysML) [20] to simplify the is performed, an open source MODEVES Transformation
modeling phase. Engine (MTE) [19] is developed (Section III) to automat-
ically generate the target low level codes. It includes the
A. LIMITATIONS OF EXISTING MBSE FRAMEWORKS SystemVerilog RTL code, SVAs, Timed Automata model
Several MBSE frameworks have already been pro- and CTL (Computational Tree Logic) assertions. Particularly,
posed to overcome the low-level complexities of ABV certain transformation rules are developed to perform a con-
(e.g. [8], [14], [30] etc.). However, the existing frameworks ceptual mapping between BDD/SMD constructs and Sys-
either deal with the static or dynamic verification at a time. temVerilog RTL/Timed Automata constructs in Section III-B
On the other hand, the complexity of modern embedded and Section III-C respectively. Similarly, multiple rules are
systems is significantly increased due to a higher degree also developed to convert the NLCTL verification properties
of heterogeneity in terms of both software and hardware into CTL assertions while the transformation of SVOCL is
components [39]. As a result, the complex designs usually integrated to generate SVAs (Section III-D). Subsequently,
require the application of both (static as well as dynamic) the implementation of transformation rules is performed in
types collectively in a unified design environment, to achieve JAVA and Acceleo [16].
the maximum verification coverage in an optimum time [7]. While the MODEVES framework proposes a unified
In addition to the lack of a unified design environment, design model for the automatic generation of SystemVerilog
the existing frameworks do not usually include the verifica- and Timed Automata, it advocates the use of two differ-
tion properties in the actual design models which creates a ent formalism for the representation of static and dynamic
gap between design and its verification. Consequently, there properties. The reason is that a unified approach is only
is a need for a unified model based framework, where the veri- beneficial where a single requirement can be simultane-
fication properties can be directly included in the design mod- ously and correctly transformed into the respective SVA and
els, to simultaneously support the static and dynamic ABV. CTL properties. Therefore, the unified representation for

104408 VOLUME 8, 2020

M. W. Anwar et al.: Unified Model-Based Framework for the Simplified Execution of Static and Dynamic ABV

FIGURE 1. Overview of the MODEVES framework.

verification constraints is not feasible without compromising transformation engine. Finally, the QuestaSIM simulator [17]
the critical transformation losses due to the significant syntax and UPPAAL tool [18] are used to perform dynamic and
and semantic differences between CTL and SVAs. static ABV respectively. After the successful design ver-
ification, the SystemVerilog RTL code can be deployed
C. VALIDATION AND QUANTITATIVE ANALYSIS to the target device as shown in Figure 1. The quanti-
The validation of MODEVES framework is performed tative analysis of MODEVES framework with respect to
(Section IV) through eight case studies i.e. Traffic Lights the native SystemVerilog and Timed Automata technologies
Controller, Car Collison Avoidance System, Arbiter, Eleva- shows 100% productivity gain (Section IV-D). It is impor-
tor, Unmanned Aerial Vehicle, Automated Teller Machine, tant to note that this article only includes the details of
Train Gate and Bridge Crossing system. The system three case studies due to space limitations while the models
design and verification aspects are modeled through the of all the eight case studies, along with the source code
proposed modeling methodology and the required target of transformation engine, are available at [19] for further
codes are automatically generated through the developed evaluation.

VOLUME 8, 2020 104409

 M. W. Anwar et al.: Unified Model-Based Framework for the Simplified Execution of Static and Dynamic ABV

TABLE 1. Notations for the modeling of system structure.

D. SUMMARY OF NOVEL CONTRIBUTIONS A. MODELING OF SYSTEM DESIGN

To summarize, the novel contributions of the proposed frame- In MMM, we select the standard UML/SysML notations
work are as follows: for the modeling of system design (structure and behavior).
1) A unified model-based design approach, by utilizing The structure of a system includes different variables and
the standard UML/SysML notations, is proposed. The hardware elements like registers, ports etc. The BDD diagram
high-level models contain the necessary information, in SysML, which has been extended from the UML class
required to concurrently transform them with minimum diagram, provides several modeling concepts like blocks,
transformation losses. flow ports etc. for a realistic representation of the sys-
2) A formalism (NLCTL) is proposed to include the tem structure. Therefore, the proposed MMM advocates the
properties in design models with simplicity for use of particular BDD concepts for the modeling of struc-
static ABV. On the other hand, the SVOCL [15] tural requirements, as given in Table 1. The first column
is used to include the verification properties for ‘‘Sr. #’’ represents the serial number of a given modeling
dynamic ABV. notation. The names and graphical representations are given
3) The design and implementation of transformation rules in the second and third columns. Finally, the description is
to automatically generate the SystemVerilog RTL code, provided in the last column.
Timed Automata model, CTL properties and SVAs are While it is relatively simple to model the structural ele-
proposed. ments of a system design process, the correct and meaningful
modeling of the system behavior is relatively complex. Partic-
ularly, the behavior of embedded systems involves complex
II. MODEVES MODELING METHODOLOGY temporal aspects with several constraints while achieving
The modeling phase provides a higher abstraction layer for the correct sequence of an execution flow. In this context,
some particular low-level technologies [2]. Subsequently, the SMD in SysML/UML provides several notations which
the transformation is performed to automatically gener- are based on the principal of finite-state-transitions. There-
ate the target low-level codes. Therefore, it is essential to fore, the SMD notations allows a systematic modeling of both
systematically include the necessary information of the target simple as well as complex behavioral requirements, as given
technologies in the modeling phase to perform accurate trans- in Table 2.
formations. In the MODEVES framework, we are dealing For a better understating of MMM, consider a guiding
with SystemVerilog, Timed Automata, SVAs and CTL tech- example of Traffic Lights Controller (TLC). The functional-
nologies. Consequently, the objective of MODEVES Mod- ity of TLC is to manage the road traffic at North-South (NS)
eling Methodology (MMM) is to enable the modeling of and East-West (EW) roads intersection. There is a sensor
general design and verification concepts at higher level while attached at the EW road to detect the presence of a vehicle.
logically preserving the semantics of target technologies. The EW light should only be turned green to pass the traffic
This section briefly describes the details of MMM regard- on the EW road if the EW sensor is activated. An emer-
ing design (Section II-A) and verification (Section II-B) gency sensor is also deployed at the NS/EW intersection to
requirements. manage the passage of emergency vehicles. To demonstrate

104410 VOLUME 8, 2020

M. W. Anwar et al.: Unified Model-Based Framework for the Simplified Execution of Static and Dynamic ABV

TABLE 2. Notations for the modeling of system behavior.

FIGURE 2. Modeling the (a) Structure and (b) Behavior of Traffic Light Controller.

the effectiveness of MMM, the structure and behavior of initial state, green, yellow etc. are modeled through state node
TCL is modeled in Figure 2 (a) and Figure 2 (b) respec- (Sr. 1 in Table 2). Furthermore, several transitions (Sr. 2 in
tively where the circled numbers demonstrate the usage of Table 2) are utilized to model the desired flow between
respective UML/SysML notation in Table 1 and Table 2 different states by applying the associated trigger and guard
respectively. For simplicity, we only consider the model- conditions. However, the complete trigger and guard condi-
ing of NS behavioral requirements rather than complete tions of transitions cannot be represented graphically due to
TLC system. space limitations and only true/ false is displayed on each
Figure 2 (a) shows that the registers, sensors and other transition as shown in Figure 2 (b).
elements are modeled through flow ports (Sr. 1 in Table 1), In order to achieve certain behavioral requirements
while different states are represented through enumeration between the execution flows of different states, the pseu-
(Sr. 3 in Table 1). Furthermore, the built-in clock and timer dostate like join (Sr. 4 in Table 2) and choice (Sr. 5 in
are declared with associated variables through block and sig- Table 2) are used. For example, assume there is a behavioral
nal events (Sr. 4 in Table 1). The modeling of TLC behavior requirement that the TLC should only move from yellow to
(only NS) is shown in Figure 2 (b). The different states like red state if NS timer for green state is equal to 3 and reset is

VOLUME 8, 2020 104411

 M. W. Anwar et al.: Unified Model-Based Framework for the Simplified Execution of Static and Dynamic ABV

false. The both conditions (i.e. ns-timer = 3 and reset = false) Stimulus Standard (PSS) [28] etc. The grammar of NLCTL is
are managed separately through two different transitions from defined using EBNF concepts through the following fourteen
the yellow state. Subsequently, if both conditions become rules:
true simultaneously, the join pseudostate combines these two 1. < Requirement>:: =<Property><Type>
transitions from the yellow state into a single one and take the The first rule states that the verification requirement/CTL
system in the red state as shown in Figure 2 (b). Similarly, assertion, represented as a <Requirement>, can be defined
other pseudostates like fork, choice are used as per given through ‘‘Property’’ and ‘‘Type’’ non-terminal symbols. The
behavioral requirements. definition of Property and Type is given in Rule 2 and 14
To summarize, the MMM is capable of modeling both sim- respectively.
ple as well as complex system designs. It is important to note 2. <Property> :: = <Exp>
that we have only explained some of the modeling concepts | if <Exp> then <Exp>
here, through the TLC guiding example. However, the model- | <Deadlock_Exp>
ing and transformation capabilities of the MODEVES frame- | <Exp> and <Exp>
work are comprehensively explained in Section IV through | <Exp> or <Exp>
some complete case studies.Furthermore, the interested read- The second rule defines that the property can be stated
ers can find the detailed modeling guidelines with examples through expression <Exp> or ‘‘if then expression’’ or
at [21]. ‘‘deadlock expression’’ <Deadlock_Exp>. Furthermore,
the property can be defined through and/or expressions
B. MODELING OF VERIFICATION REQUIREMENTS <Exp>. The definitions of expression <Exp> and dead-
While the system design is based on a unified model lock expression <Deadlock_Exp> are given in Rule 4 & 3
(as shown in Section II-A), the system verification in respectively.
the proposed framework requires two different formalisms: 3. <Deadlock_Exp> ::= never deadlock
(1) the NLCTL is proposed to represent CTL properties in | system is deadlock free
design models for static ABV, (2) the SVOCL is used to | deadlock
include SVAs for dynamic ABV. It is important to note that | system has deadlock
the SVOCL is already proposed in [15] and only its overview The third rule defines the syntax of a deadlock expression
is provided here for the completeness of the framework. with four terminal symbols i.e. never deadlock, system is
deadlock free, deadlock and system has deadlock.
1) NATURAL LANGUAGE FOR COMPUTATION TREE 4. <Exp> :: = (<property>)∗
LOGIC (NLCTL) | never <Exp>
The motivation behind the NLCTL is to provide a simple | <State_Exp>
and logical modeling approach to include the CTL properties | <Time_Exp>
directly in the design models through a natural language alike | <Logical_Exp>
syntax. The CTL [26] is a well-known temporal logic to | <Deadlock_Exp>
specify the branching time constraints and deals with two The fourth rule implies that it is possible to use the property
temporal operators for paths quantifiers i.e. All and Exist. non terminal symbol (Rule 2) in the expression repeatedly i.e.
Furthermore, it also provides some temporal operators for the zero to n times. Furthermore, the expression can be defined
path specific quantifiers i.e. Next, Globally, Finally, Until and along with ‘‘never’’ terminal symbol. In addition, the expres-
Weak Until. sion can be defined through <State_Exp>, <Time_Exp>,
The proposed framework directly loads the Timed <Logical_Exp> and <Deadlock_Exp >, as given in the
Automata model and the CTL properties in UPPAAL tool to Rule 5, 6, 8 & 3 respectively.
perform static ABV instantly [18]. In this context, a subset of 5. <State_Exp>:: = <Process_Name> state is
standard CTL is utilized in UPPAAL to express the properties <State_Name>
for the verification of Timed Automata model. Particularly, | <Process_Name> state is
five temporal operators, based on the standard CTL concepts, equal to <State_Name>
are used. The Possibly operator deals with the reachability It defines the syntax of state expression <State_Exp>. The
properties while the Invariantly and Potentially Always oper- terminal symbol ‘‘state is’’ should be used between the pro-
ators deal with the safety properties. Finally, the Eventually cess name and the state name. Similarly, the terminal symbol
and Leads to operators deal with the liveness properties. ‘‘state is equal to’’ can also be used between the process name
In NLCTL, we consider all the aforementioned five operators and the state name non terminal symbols. The definitions of
for the modeling and transformation of both simple as well as <Process_Name> and <State_Name> are given in Rule 13
complex CTL properties. & 12 respectively.
Proposed Formalism: We systematically develop NLCTL 6. <Time_Exp>:: = <Variable_Name><OPT>
by utilizing the concepts of Extended Backus–Naur Form <Value>
(EBNF) [27], which is a standard approach for the devel- | <Variable_Name><OPT>
opment of new languages e.g. Accellera Portable Test and <Variable_Name>

104412 VOLUME 8, 2020

M. W. Anwar et al.: Unified Model-Based Framework for the Simplified Execution of Static and Dynamic ABV

It defines the syntax of time expression <Time_Exp>.

The time expression can be specified by using variable name
<Variable_Name>, operator <OPT> and value <Value>
non terminal symbols where the operator non terminal sym-
bol should be used between the variable name and the
value non terminal symbols. Similarly, time expression can
also be defined by using the operator non terminal symbol
between the two variable name non terminal symbols. The FIGURE 3. NLCTL Syntax Tree for Example 1.
definitions of <Variable_Name>, <OPT> and <Value>
non terminal symbols are given in Rule 11, 7 and 10
respectively. five terminal symbols (Possibly, Invariantly, Potentially
7. <OPT> :: = less than always, Eventually and Leads to).
| greater than equal to Application of NLCTL: This section demonstrates the
The syntax of operator <OPT> can be defined either application of NLCTL, based on the proposed EBNF gram-
through ‘‘less than’’ or ‘‘greater than equal to’’ terminal mar, with examples. Particularly, the objective is to demon-
symbols. strate the systematic working of NLCTL grammar through
8. <Logical_Exp> :: = <Variable_Name> syntax tree.
<Logical_OPT><Value> Example 1: This example is taken from the TLC system
The logical expression <Logical_Exp> can be speci- where the requirement is to check a deadlock in the system.
fied by using the variable name <Variable_Name>, logical This property can be represented in NLCTL as:
operator <Logical_OPT > and value <Value> non termi-
Property = System is deadlock free, Type = Invariantly
nal symbols where logical operator non terminal symbol
should be used between the variable name and the value The syntax tree of NLCTL grammar for a given property
non terminal symbols. The definitions of <Variable_Name>, is shown in Figure 3. Please note that the terminal symbols
<Logical_OPT>, <Value> non terminal symbols are given are highlighted in blue color and the sequence of terminal
in Rule 11, 9 and 10 respectively. symbols during parsing is shown in red color with a respective
9. <Logical_OPT> :: = equal to number.
| less than Figure 3 shows that the given verification requirement
| greater than equal to is expressed through Property and Type non terminal sym-
| less than equal to bols (rule 1 of the NLCTL grammar). The Property non
The logical operator <Logical_OPT> can be defined in terminal symbol can be directly represented through dead-
four different ways, as shown above. lock expression (rule 2). Finally, the deadlock expression can
10. <Value> :: = ([a-z][A-Z][0-9])∗ be represented through ‘‘system is deadlock free’’ terminal
11. <Variable_Name> :: = ([a-z][A-Z][0-9])∗ symbol (rule 3). On the other hand, Type non terminal symbol
12. <State_Name> :: = ([a-z][A-Z][0-9])∗ can be represented through ‘‘invariantly’’ symbol (rule 14).
13. <Process_Name> :: = ([a-z][A-Z][0-9])∗ Consequently, the given requirement is correctly expressed
The rules 10, 11, 12 and 13 provide the definitions for through NLCTL grammar rules.
declaring a value, variable name, state name and the process Example 2: This example is taken from an elevator sys-
name non terminal symbols respectively. The value can be tem. Particularly, the requirement is to check the reachability
defined through the combination of 0-9 integers e.g. 12, 987 of warning, overload and weight reduced states while the
etc. Moreover, both small as well as capital alphabetical let- weight_sensor is under the allowed limit (i.e. 800 KG) and
ters (i.e. a to z or A to Z) can be used in different combinations motion_sensor is activated. It can be expressed as:
to define a particular value. Furthermore, an alpha numeric Property = If (weight_sensor less than equal to 800 and
combination can also be used to define a value. Similarly, the motion_sensor equal to true) then never (P1 state is Warn-
variable, state and process names can be defined as per given ingState or P1 state is OverLoad or P1 state is WeightRe-
aforementioned value rules. duced), Type = Possibly
14. <Type> :: = Possibly The syntax tree for Example 2, as shown in Figure 4,
| Invariantly utilizes most of the NLCTL grammar rules. The given exam-
| Potentially always ple is started through rule 1 by utilizing the property and
| Eventually type non terminal symbols. Subsequently, the property can be
| Leads to defined through ‘‘if <exp> then <exp>’’ as per rule 2 of the
There are three major types of CTL queries (i.e. Reachabil- NLCTL grammar. Therefore, the rule 2 is applied to achieve
ity, Safety, Liveness) for the verification of Timed Automata the desired representation, as shown in Figure 4. According
model in UPPAAL tool. To include all the four types of to rule 4, expression <exp> can be defined as a property
verification queries in NLCTL, type <Type> non termi- recursively. Similarly, various NLCTL rules are utilized to
nal symbol is introduced. The type can be defined through correctly express the given requirements.

VOLUME 8, 2020 104413

 M. W. Anwar et al.: Unified Model-Based Framework for the Simplified Execution of Static and Dynamic ABV

FIGURE 4. NLCTL Syntax Tree for Example 2.

To summarize, the NLCTL is a significant step to express SystemVerilog constructs is defined in Section III-B. For
the verification properties at a higher abstraction level. system behavior, the conceptual mapping of SystemVerilog
To complete the MBSE flow, its grammar is implemented and Timed Automata constructs with respect to SMD nota-
in the transformation engine, so that, the high-level NLCTL tions is described (Section III-C). Finally, the transformation
constraints can be automatically transformed to the corre- rules to generate CTL assertions from NLCTL constraints are
sponding CTL assertions (See Section III-D for the details of provided in Section III-D.
transformation process). The user manual and further details
of NLCTL can be found at [31].
A. GENERAL ARCHITECTURE
2) SVOCL FOR SystemVerilog ASSERTIONS We practice a Model-to-Text (M2T) transformation approach,
We have already developed an OCL extension, named as using the open source Acceleo tool [16], for the implementa-
SVOCL [15], to include the dynamic verification require- tion of MODEVES Transformation Engine (MTE). Acceleo
ments in high-level models. In this regard, seven functions is a well-known tool for a seamless execution of transforma-
are included in SVOCL, as shown in Table 3 (sr. # 1 to tions in MBSE [29]. Figure 5 shows that the implementa-
sr. # 7). Furthermore, Disif expression (sr. # 8 of Table 3) tion of MTE is accomplished through three main modules:
is incorporated for conditional statements. In the proposed (1) User Interface, (2) Generator and (3) Java Services. In the
framework, we have integrated the SVOCL for dynamic following, the brief description of each module and respective
ABV. In this regard, the practical usage of SVOCL functions sub-modules is presented.
(Table 3), along with the complete technical details, can be User Interface: It launches the application and displays
found at [15]. the user interface of MTE on the screen. It takes the MMM
compliant models in .UML extension and sends their address
III. MODEVES TRANSFORMATION ENGINE (MTE) to Generator module for further processing (e.g. extraction
This section describes the MODEVES Transformation of model elements etc.). Furthermore, it also sends the des-
Engine (MTE). Firstly, the general architecture is described tination folder address (where the target models are required
in Section III-A. In order to develop some appropri- to be generated) to the Generator module.
ate transformation rules for system structure, the con- Generator: It receives the input UML models and gener-
ceptual mapping between SysML BDD notations and ates the target SystemVerilog RTL, Timed Automata model,

104414 VOLUME 8, 2020

M. W. Anwar et al.: Unified Model-Based Framework for the Simplified Execution of Static and Dynamic ABV

TABLE 3. Fundamental constructs of SVOCL.

FIGURE 5. Implementation architecture of MODEVES transformation engine.

SVAs and CTL assertions. Particularly, the source model and NLCTL assertions. The processed transformation rules
extractor extract the required UML elements (e.g. BDD from Java services component are sent back to the Generator
attributes, state and transition elements etc.) from the input module to ultimately generate the target codes, as shown
models which are then passed to Java Services module for in Figure 5.
further processing. Finally, the target model generator gen- It can be seen from Figure 5 that the architecture of MTE
erates the target models after receiving the processed infor- is based on a modular approach as the coupling between
mation from the Java Services. Lastly, the model refiner is different modules is as minimum as possible. Consequently,
responsible to manage the formatting issues in the generated the MTE is highly supportive in terms of scalability and
target models. usability. For example, some additional CTL constructs can
Java Services: It implements the logic of transformation be added in the current version by only updating the NLCTL
rules (Section III-B, Section III-C and Section III-D). Par- sub-component. Similarly, the other components can also
ticularly, the SystemVerilog sub-module contains the corre- be upgraded with simplicity according to some particular
sponding transformation rules for the RTL code and SVOCL. requirements.
It is important to note that the SVOCL sub-module is already In addition to the scalability, the architecture of MTE
implemented [15] and only the integration is performed here. also provides the usability features as different components
On the other hand, the Timed Automata sub-module imple- can be used in other implementations with slight modifi-
ments the transformation rules for the Timed Automata model cations. For example, it is fairly possible to include the

VOLUME 8, 2020 104415

 M. W. Anwar et al.: Unified Model-Based Framework for the Simplified Execution of Static and Dynamic ABV

TABLE 4. Conceptual mapping of smd notations w.r.t to systemverilog and timed automata concepts.

functionality of NLCTL in other frameworks with simplicity. of clock, on the basis of signal type and associated properties,
The only requirement is to use the ‘‘GenerateCTL.java’’ file is generated in the target structural code.
of NLCTL sub-component and a small portion of existing It is important to note that although we consider major
code is required from the Generator and Java Services com- SystemVerilog data types in the transformation process in
ponents. To conclude, the further addition of functions in order to define the structural aspects of system in RTL
MTE is easy to implement and the integration of a particular code, SystemVerilog supports different variations in standard
MTE function in other frameworks is quite simple. datatypes e.g. integer datatype can be signed or unsigned etc.
We do not include the complete MTE details here due In transformation, we do not consider such variations in stan-
to space limitations and further details like user/installation dard SystemVerilog datatypes and one can manually include
manual, the low-level architecture containing implementation such information in generated RTL code after transformation.
details, the download link (source code) and the sample case Similarly, SystemVerilog also supports advanced datatypes
studies can be found at [19]. However, the summary of MTE like chandle to store pointers during Direct Programming
transformation rules is provided in subsequent sections. Interface (DPI) [6]. We also do not consider such advanced
datatypes in transformation.
B. TRANSFORMATION FOR SYSTEM STRUCTURE
The SysML BDD notations are proposed in Section II
(Table 1) for the modeling of system structure. Here, C. TRANSFORMATION FOR SYSTEM BEHAVIOR
the generic transformation rules are defined to generate The behavioral models are simultaneously transformed into
SystemVerilog structural code from the BDD notations as SystemVerilog RTL and Timed Automata model to perform
follows: both dynamic as well as static ABV. In this regard, it is
1) Flow ports are transformed to SystemVerilog registers essential to develop various rules to transform SMD notations
where in and out flow port types are mapped to SystemVer- into the corresponding SystemVerilog and Timed Automata
ilog input and output registers/logic respectively. Further- concepts, as given in Table 4.
more, the flow port with inout direction type is mapped to Table 4 shows that the mappings between SMD notations
SysemVerilog wire. and Timed Automata are straightforward, as both are based on
2) The UML/SysML primitive data types are transformed the principal of finite-state-transition. For example, the SMD
to equivalent SystemVerilog variable types like integer. transition is logically equivalent to Timed Automata edge.
3) The UML/SysML enumeration type is transformed to Therefore, the attributes of a transition like guard, trigger and
equivalent SystemVerilog enumeration (typedef enum). effect can be directly mapped to the edge attributes like gurad,
4) Although the activity diagram is used to implement the Sync and update respectively. Similarly, the SMD state is
clock and timer, the signal type is actually used to represent logically equivalent to Timed Automata location. Therefore,
it in the model. On the other hand, the SystemVerilog has the state attributes like entry can be directly mapped to the
inherited process for clocking. Therefore, only the definition location invariant. Moreover, the SMD Pseudostates like fork,

104416 VOLUME 8, 2020

M. W. Anwar et al.: Unified Model-Based Framework for the Simplified Execution of Static and Dynamic ABV

join and choice are logically equivalent to location in Timed and assertions code can be optimized manually. In addition,
Automata. it is also important to note that SystemVerilog is a complete
It is important to note that we target all the major elements design and verification language with several advanced fea-
of Timed Automata (i.e. initial location, location, commit- tures [33]. Therefore, it is not possible to consider all the
ted location, edge with guard, update and sync attributes aspects of SystemVerilog in the proposed framework. For
and invariant), which are defined in UPPAAL tool. How- example, SystemVerilog fully supports the object oriented
ever, few customized features of UPPAAL tool like urgent concepts [33] like inheritance, polymorphism etc. to develop
channel/location are not considered in the proposed transfor- some complex test benches. Similarly, it can interact with
mation. Similarly, few variables are needed to be declared other hardware languages through DPI features [6]. We do not
in UPPAAL tool in order to perform simulation. How- consider the modeling and transformation of such advanced
ever, the information of global declaration variables cannot SystemVerilog features as these concepts are irrelevant in the
be incorporated systematically without compromising the given research context.
simplicity and generic applicability of the framework. One In Table 4, the major details regarding the conceptual
possibility is to include the information of global declara- mapping of SystemVerilog and Timed Automata with respect
tion variables through UML comments; however, this is a to SMD constructs are provided, without going into the
non-standard way and of least use for researchers and prac- low-level implementation details. It is important to men-
titioners. Therefore, we do not provide the modeling and tion here that the OCL basic operators like arithmetic, com-
transformation provision for global declaration variables as parison etc. are logically equivalent to the SystemVerilog
this information can easily be included in the automatically operators [34]. Consequently, it is straightforward to con-
generated Timed Automata model manually. vert the OCL expressions, given in the SMD attributes like
On the other hand, it can be seen from Table 4 that the map- guard, effect etc., into the corresponding SystemVerilog code.
pings between SMD notations and SystemVerilog are indirect On the other hand, the OCL basic operators are also available
as the former is based on finite-state-transition concepts while in Timed Automata. We are not including the low-level imple-
the latter is a low-level hardware language. For example, mentation details of Timed Automata operators and concepts
the entry attribute of a state refers to the specific condition like locations, edges etc. because such details can be found
while the system is entering into a particular state. In Sys- at [9]. Furthermore, the source code of MTE is publically
temVerilog, this refers to a low-level code for a specific condi- available [19], where all the low-level details are available
tion in the context of a particular state. Therefore, the flow of with proper comments.
states and the transitions along with the respective attributes
in the model is considered for the transformation of respective D. TRANSFORMATION FOR NLCTL
SystemVerilog RTL code. For example, the sequence of states The proposed NLCTL grammar is implemented, to
belongs to the major (outer) structure of SystemVerilog RTL accurately generate the corresponding CTL assertions. For
code while the sequence of transitions belongs to the inner example, the NLCTL rule 1 states that the requirement can
code within the main structure. In this regard, the SMD be expressed through Property and Type terminal symbols.
region attribute is used to provide further division in the main In MTE, the Requirement is transformed to property attribute
structure i.e. a separate code block in RTL code for each in CTL. Moreover, the NLCTL Property terminal symbol is
region. transformed to Query attribute in CTL. Furthermore, the Type
Similarly, the initial node provides a starting point for a terminal symbol of NLCTL is transformed to Query Operator
particular block of code. Consequently, in order to gener- in CTL.
ate the RTL code for the main structure (based on states) Particularly, the Type terminal symbol is ultimately rep-
and the inner logic (based on transitions), we consider cer- resented through five nonterminal symbols in NLCTL as
tain low-level SystemVerilog constructs in the transformation per rule 14. To implement rule 14 in MTE, the NLCTL
process. Type nonterminal symbols ‘‘Possibly, Invariantly, Potentially
For example, we consider certain procedural statements always, Eventually and Leads to’’ are transformed into the
(i.e. initial, final, always and function) during the transfor- CTL operators ‘‘E<>, A[], E[], A<> and →’’ respectively.
mation process to generate the main structure of behavioral Similarly, all the proposed NLCTL grammar rules are imple-
code. Moreover, the conditional branching (based on SMD mented. Consequently, the MTE is able to accurately generate
Choice Pseudostate) is achieved in transformation process CLT properties from NLCTL assertions.
through SystemVerilog if / else and case statements. Sim- For a better understanding of MTE capabilities, consider
ilarly, we consider SystemVerilog for and foreach loops in the transformation of TLC guiding example (introduced
the transformation process. To summarize, all the signifi- in Section II) as given in Figure 6. Particularly, the
cant SystemVerilog constructs have been considered in the MMM-compliant model of TLC is given to MTE which
transformation process which are essential to specify both automatically generates four files i.e. SystemVerilog RTL,
simple as well as complex design and verification require- SVAs, timed automata and CTL properties. As ‘SV’ is a
ments in RTL code and SVAs respectively. Furthermore, standard extension for SystemVerilog, the dynamic ABV
in case of any particular requirement, the generated RTL can be performed instantly in existing Universal Verification

VOLUME 8, 2020 104417

 M. W. Anwar et al.: Unified Model-Based Framework for the Simplified Execution of Static and Dynamic ABV

FIGURE 6. Transformation of traffic lights controller guiding example.

Methodology (UVM) [38] based simulators like QuestaSIM. 1) REQUIREMENTS SPECIFICATION

On the other hand, the static ABV can also be performed Figure 7 shows the structural requirements of arbiter, cap-
instantly in UPPAAL tool as it fully recognizes the timed tured through the MMM guidelines. The arbiter states have
automata model and CTL properties through ‘XTA’ and been represented through enumeration. We identify and cap-
‘Q’ formats respectively. ture the following behavioral requirements:
• State machine goes to the IDLE state on system reset.
IV. VALIDATION
• In the IDLE state, any or all the masters can send a
The applicability of MODEVES framework is demonstrated
request to acquire the bus. The decision of bus grant
through eight benchmark case studies i.e. Traffic Lights
is taken in a priority-encoding fashion. For example,
Controller (TLC), Car Collison Avoidance System (CCAS),
the bus will be granted to the MASTER1 device if all
Arbiter, Elevator, Unmanned Aerial Vehicle (UAV), Auto-
the master devices request for the bus in the IDLE state.
mated Teller Machine (ATM), Train Gate and Bridge Cross-
In the MASTER state, the grant signal will be asserted
ing system. However, this article includes the details of
to the respective master device. The master device will
only three case studies (i.e. Arbiter, Elevator and Unmanned
free the bus by sending the done signal and consequently
Aerial Vehicle) due to space limitations. In this regard,
the system moves to the IDLE state of the corresponding
the models of all the eight case studies, along with the
master device (e.g. IDLE1).
source code of MTE, are available at [19] for further eval-
• When the system is in IDLE1 state, it prioritizes the
uation. The MMM is applied to capture the structural,
assignment of a bus to the master devices in the
behavioral and verification requirements (Section IV-A,
order of MASTER2, MASTER3 and then MASTER1.
Section IV-B and Section IV-C), using the Papyrus modeling
Similarly, the priority of bus assignment is MAS-
editor [35]. Subsequently, the MTE is utilized to generate the
TER3, MASTER1 and then MASTER2 if the system
target code.
is in IDLE2 state. Finally for IDLE3 state, the prior-
A. ARBITER CASE STUDY ity of bus assignment is MASTER1, MASTER2 and
This case study represents the design of an arbiter that then MASTER3.
is implemented as one-hot coding style state machine. The behavior of arbiter is modeled and verification aspects
It has seven possible states i.e. MASTER1, MASTER2, are included in the models through both SVOCL as well
MASTER3, IDLE, IDLE1, IDLE2 and IDLE3. Any or all as NLCTL, as shown in Figure 8. The following verifica-
of the three master devices can make a request for the grant tion aspects have been identified and included in the arbiter
of the bus and the arbiter will select who gets the bus by model:
using the round robin policy. The master device will be 1. A grant should be asserted for every request received
able to perform certain transactions after acquiring the bus. by the arbiter. The ‘‘gnt’’ signal should be asserted
The bus is available for other requests after the completion of within 1 clock cycle for any one of the requesting
transaction. masters.

104418 VOLUME 8, 2020

M. W. Anwar et al.: Unified Model-Based Framework for the Simplified Execution of Static and Dynamic ABV

FIGURE 7. Structural requirements of arbiter through MMM.

2. The arbiter IDLE state should be working correctly i.e. in the respective tools. Here, we use QuestaSIM to per-
it cannot go to IDLE 1, IDLE 2 and IDLE 3 from the form dynamic ABV by utilizing the SystemVerilog RTL and
IDLE state. assertions files which are generated through MTE. During
3. The arbiter master states should work as: 1) arbiter can- the design varication (simulation), we encounter failure of
not go to IDLE2, IDLE3, MASTER2 and MASTER3 an assertion. We analyze the cause of failure by utilizing
states from MASTER1 state 2) arbiter cannot go to the advance features of QuestaSIM, as shown in Figure 10.
IDLE1, IDLE3, MASTER1 and MASTER3 states We investigated the cause of this failure and correct the
from MASTER2 state 3) arbiter cannot go to IDLE1, design accordingly. Finally, after rigorous simulation, it has
IDLE2, MASTER1 and MASTER2 states from been analyzed that the arbiter design is free of errors. Here,
MASTER3 state. we include the summary of design verification, however, the
4. Arbiter idle states should work as: (1) arbiter cannot complete details can be found at [36].
go to IDLE2 and IDLE3 states from IDLE1 state. In addition to dynamic ABV, we also perform static ABV
(2) arbiter cannot go to IDLE1 and IDLE3 states by using open source UPPAAL tool. Particularly, we use
from IDLE2 state. (3) arbiter cannot go to IDLE1 and Timed Automata model and CTL assertions files that are
IDLE2 states from IDLE3 state. generated through MTE. We verify different properties like
5. Ensure the fairness of arbiter i.e. the grants should be deadlock etc. as included in the model through NLCTL. The
assigned to masters on equal basis. verification of one property in UPPAAL tool is shown in
Figure 11. Further details regarding the static ABV of arbiter
As design and verification requirements are modeled alto-
can be found at [36].
gether (Figure 8), this provides the basis to generate both
After successful verification, we employ Xilinx
SVAs and CTL assertions along with SystemVerilog RTL
Vivado [37] to perform the code synthesis of SystemVer-
code and Timed Automata model through MTE. It is impor-
ilog RTL code. However, we are not including the details
tant to note that we differentiate SVOCL and NLCTL asser-
of dynamic ABV (QuestaSim) and code synthesis (Xilinx
tions through Requirement key word of NLCTL, as shown in
Vivado) here due to space limitations. The interested readers
Figure 8. The next step is to utilize the MTE to transform the
can find the complete design verification and code synthesis
source models into the target models, as shown in Figure 9.
details at [36].
The MTE generates model_asserts.sv, model_behavior.sv,
model_timed_automata.xta and model_properties.q files for
SVAs, SystemVerilog RTL code, Timed Automata model and B. ELEVATOR CASE STUDY
CTL assertions respectively. It is not possible to describe the The case study represents the design of an elevator which is
complete MTE details due to space limitations. However, used to move the people and goods between different floors
we upload MTE and arbiter case study here [19], so that, of a building. A weight sensor is installed to calculate the
the interested readers can perform further evaluation. overall load. The maximum allowed wait is 800 kg. The panel
is attached in the elevator to select the desired floors in a
2) DESIGN VERIFICATION sequence as per requirements. The emergency sensor is also
After the automatic generation of target models through installed to instantly stop and open exit passage of the moving
MTE, both static as well as dynamic ABV can be performed elevator in the case of emergency situations.

VOLUME 8, 2020 104419

 M. W. Anwar et al.: Unified Model-Based Framework for the Simplified Execution of Static and Dynamic ABV

FIGURE 8. Modeling behavioral and verification requirements of arbiter through MMM.

1) REQUIREMENTS SPECIFICATION The following verifications aspects of elevator are

The structure of elevator is modeled through the MMM identified:
guidelines, as shown in Figure 12. The following behavioral
1. Confirm that whenever an elevator is moving, it should
requirements of elevator are required:
not be in the IDLE state.
• Initially, elevator should be in the IDLE state. Once 2. Confirm the correct operating mechanism of elevator
persons are entered into an elevator, the overall weight i.e. It shouldn’t move in the upward and downward
is calculated. Subsequently, if the weight of elevator is direction at the same time.
greater than 800 than it is moved to the IDLE state by 3. Confirm that when the elevator is moving either upward
producing weight overload alarm. Otherwise, elevator or downward, the door of elevator should not be
should move further to check the desired floor number. opened.
• The elevator should move upward or downward depend- 4. Confirm that the overall weight of the elevator should
ing upon desired floor number and current floor of ele- be within the given limits (less than 800 KG).
vator. 5. Confirm that whenever the emergency sensor gets acti-
• Finally, the elevator should reach to desired floor and vated, the emergency exit should also be activated at
subsequently move to initial state (IDLE). the same time.

104420 VOLUME 8, 2020

M. W. Anwar et al.: Unified Model-Based Framework for the Simplified Execution of Static and Dynamic ABV

FIGURE 9. Generating target files for the arbiter model through MTE.

The aforementioned verification requirements are included pre-programmed flight plans. It has quite complex dynamic
in the behavioral model of elevator by utilizing both SVOCL automation systems. This case study demonstrates the design
and NLCTL approaches as shown in Figure 13. Once the of UAVs with various safety constraints.
design and verification requirements have been successfully
modeled (Figure 12 and Figure 13), we generate SystemVer-
ilog RTL, Timed Automata model, SystemVerilog Assertions 1) REQUIREMENTS SPECIFICATION AND DESIGN
and CTL assertions through MTE. However, we are not VERIFICATION
including the details of code generation here because such The structure of UAV system comprises one major block
details are already given in Section IV-A-2. that contains required ports/registers. Furthermore, various
UAV states are represented through enumeration, as shown
in Figure 15. The following behavioral requirements are
2) DESIGN VERIFICATION
identified:
We have performed both static as well as dynamic ABV
for elevator system by utilizing the generated target files i.e.
• Initially, the system is in FLYING state and continuously
SystemVerilog RTL, Timed Automata model, SystemVerilog
monitoring the engine failure and GPS failure states.
Assertions and CTL assertions. Firstly, we perform static
The system moves to either ENGINE FAILURE state
ABV by utilizing UPPAAL tool. Particularly, the Timed
or GPS FAILURE state depending on the sensor values
Automata model and CTL assertions file, generated through
(engine_failure_sensor and gps_failure_sensor). Simi-
MTE, are given to UPPAAL tool. Subsequently, design ver-
larly, the system is also monitoring TERMINATION
ification is performed through UPPAAL tool as shown in
COMMAND RECEIVED, 2.4GHz LINK FAILURE,
Figure 14. Once, all the given properties are successfully
SOFT GEOFENCE BREACH and DATALINK FAIL-
verified through UPPAAL, we perform dynamic ABV. Partic-
URE states through the termination_command_recieved,
ularly, SystemVerilog RTL and assertions files are given as an
2.5GHz_link_failue_senor, geo_fencing_sensor and
input to QuestaSIM simulator. Subsequently, the simulation
datalink_failure_sensor respectively.
is performed to verify the given properties.
• Once the system is in ENGINE FAILURE state, it has
to be landed on emergency basis within 3 clock cycles.
C. UNMANNED AERIAL VEHICLE (UAV) SYSTEM In the TERMINATION COMMAND RECEIVED state,
The UAV is typically an aircraft that can be con- the system should move to the FLIGHT TERMINA-
trolled remotely or fly autonomously on the basis of TION INITIATED state after one clock cycle and

VOLUME 8, 2020 104421

 M. W. Anwar et al.: Unified Model-Based Framework for the Simplified Execution of Static and Dynamic ABV

FIGURE 10. Performing design verification of arbiter in QuestaSIM.

subsequently move to the MANUALLY LAND 2. Property2: From AutoRestoring state, the system
AIRCRAFT state within three clock cycles. should move to Flying state in 4 clock cycles on the
• Once the system is in SOFT GEOFENCE BREACH activation of auto_restore and ground_station_restore.
state, it should move to RESTORING FROM NO FLY 3. Property3: From RestoringFromNoFlyZone, the sys-
ZONE state on the next clock cycle and perform cer- tem should move to CheckFlyZone within 1 to 3 clock
tain checks to move into respective state. Similarly, cycles. However, on the deactivation of safe_zone,
in the DATA LINK FAILURE state, the system evaluates the system should move to FlightTerminationInitiated
certain conditions (e.g. 900MHz_link_failure_sensor, state within 3 clock cycles and subsequently to Manu-
5.8GHz_link_failure_sensor etc.) to move into a partic- allyLandAirCraft state within 2 to 4 clock cycles.
ular state accordingly. 4. Property4: The system should move from Restor-
• In case of GPS failure, the system continues nor- ingFromNoFlyZone to CheckFlyZone within 1 to
mal flight on a successful GPS auto restore. Oth- 3 clock cycles and upon the activation of safe_zone,
erwise, the system should move to the FLIGHT the system should move to the Flying state after 3 clock
BACK TO STATION state and subsequently moves cycles.
to either REACHED BACK TO STATION state or 5. Property5: In case of a GPS failure with an unsuccess-
AIRCRAFT LOST state, depending on the underlying ful automatic restore, the system should go back to
conditions. station within 4 clock cycles.
In arbiter and elevator case studies, we represent the veri-
Following safety constraints are identified (Figure 16):
fication aspects through both SVOCL as well as NLCTL to
1. Property1: In case of termination command during demonstrate the simultaneous application of both approaches.
the flight, the system should move to FlightTermina- Now, we prove the application of SVOCL and NLCTL indi-
tionInitiated within two clock cycles and subsequently vidually. Particularly, the idea is to show that SVOCL and
enters into ManuallyLandAirCraft state within two to NLCTL can be used separately through the MODEVES
four clock cycles. framework as per requirements. Here, we include the

104422 VOLUME 8, 2020

M. W. Anwar et al.: Unified Model-Based Framework for the Simplified Execution of Static and Dynamic ABV

FIGURE 11. Performing design verification of Arbiter in UPPAAL.

FIGURE 12. Structure of the elevator in BDD.

verification aspects of UAV system in the model through complete model of UAV case study along with the MTE
SVOCL only, as shown in Figure 16. Subsequently, only at [19].
the SystemVerilog RTL and assertions files are generated. In this section, we applied MMM on three industrial case
Once the design and verification requirements have been studies to successfully model the structural, behavioral and
successfully modeled (Figure 15 &Figure 16), we utilize verification requirements. Furthermore, we demonstrate the
MTE to generate the target code for design verification. Due applicability of MTE by correctly transforming the models of
to space limitations, we are not including the MTE and design two case studies into SystemVerilog RTL, Timed Automata
verification details and the interested readers can found a model, SystemVerilog Assertions and CTL assertions.

VOLUME 8, 2020 104423

 M. W. Anwar et al.: Unified Model-Based Framework for the Simplified Execution of Static and Dynamic ABV

FIGURE 13. Modeling behavioral and verification requirements of elevator through MMM.

Consequently, it can be concluded that the MODEVES following important questions are difficult to answer without
framework is widely applicable on a variety of embedded performing a systematic quantitative analysis:
systems. It is important to note that MODEVES framework is Q1: Why there is a need to propose UML/SysML based
validated through eight benchmark case studies. The models modeling approach for the system design that can support
of all eight case studies, MTE source code and user manual formal and dynamic ABV at the same time?
can be found at [19] for further evaluation. Furthermore, Q2: What is the improvement in design productivity
the complete modeling guidelines of MODEVES framework through the proposed framework?
can be found at [21], so that, the interested readers can model Q3: Does the proposed methods lead to fewer design mis-
and transform any case study of their choice. takes and/or easier to correct the corresponding design errors?
Q4: Do the benefits of the proposed methodology out-
D. QUANTITATIVE ANALYSIS OF THE MODEVES weigh by any transformation losses?
FRAMEWORK Q5: How easy is to learn the proposed framework, as com-
To this point, we have demonstrated the modeling and pared to the low-level technologies?
transformation capabilities of the MODEVES framework in Without answering the aforementioned questions, the nov-
Section IV-A, Section IV-B and Section IV-C. However, the elty, contributions and benefits of the MODEVES framework

104424 VOLUME 8, 2020

M. W. Anwar et al.: Unified Model-Based Framework for the Simplified Execution of Static and Dynamic ABV

FIGURE 14. Design verification of elevator in UPPAAL.

FIGURE 15. Structure of the UAV System.

cannot be established. Therefore, we perform a quantita- benchmark case studies (UAV, Arbiter and Elevator) given
tive analysis of the proposed framework to get the genuine in the article have been selected. The professional P1 is
answers of aforementioned questions. required to implement the system design and verification
In order to perform a quantitative analysis of the proposed constraints for each case study through SystemVerilog while
framework, we chose three professionals (i.e. P1, P2 and P2 is required to develop each case study in Timed Automata
P3) from industry. Particularly, professional 1 (P1) has more and CTL using UPPAAL tool. On the other hand, P3 is
than five years of experience in digital design using Ver- required to develop the system design and verification con-
ilog/SystemVerilog while professional 2 (P2) has three years straints for each case study through the proposed frame-
of formal verification experience in Timed Automata/Petri work (MODEVES). Subsequently, P3 is supposed to gener-
nets using UPPAAL/TAPAAL tools. Similarly, professional 3 ate SystemVerilog RTL, SVAs, Timed Automata and CTL
(P3) has more than five years of experience in UML/SysML properties from models by using the proposed transformation
based system development and is well familiar with the engine (MTE).
model transformation process. To perform a competitive The evaluation results of all the three case studies are
quantitative analysis of MODEVES framework, the three summarized in Table 5. It can be observed from Table 5

VOLUME 8, 2020 104425

 M. W. Anwar et al.: Unified Model-Based Framework for the Simplified Execution of Static and Dynamic ABV

FIGURE 16. Modeling behavioral and verification requirements of UAV through MMM.

that SVOCL has saved only two hours for each case study as Particularly, the productivity gains regarding NLCTL are
compared to native SVAs. In this regard, Professional 3 also 150%, 100%, and 100% for UAV, Arbiter and Elevator case
reported that the modeling of assertions through SVOCL studies respectively, as shown in Table 5. In this regard,
is a bit complex. In other words, it is required to care- Professional 3 also highlighted that it is very simple to spec-
fully call different SVOCL functions recursively in order to ify verification properties through NLCTL. Furthermore, the
specify complex assertions. Furthermore, it is also essential correctness of NLCTL assertions with respect to the given
to exactly follow the syntax of SVOCL. Actually, SVOCL grammar can be verified before transformation which is very
has been developed to represent low-level SVAs concepts useful in an industry environment.
in high-level models. Therefore, the modeling of assertions So far, we have evaluated the productivity of MODEVES
in SVOCL is relatively complex [15]. However, SVOCL is framework with respect to the native SystemVerilog and
still marginally better than native SVAs as far as productivity Timed Automata technologies, as given in Table 5. However,
gain is concerned. Moreover, the major benefit of SVOCL the analysis of transformation losses is equally important.
is the simultaneous modeling of assertions along with the In this regard, a test engineer with three years industry expe-
system design. Furthermore, the complexity of SVOCL is rience was selected. Particularly, the SystemVerilog RTL and
comparable with existing state-of-the-art property specifica- assertions codes for all the case studies, implemented by P1 in
tion approaches [15], [22]–[25]. the native SystemVerilog, were given to the test engineer
It can be analyzed from Table 5 that NLCTL fairly in order to develop the corresponding test benches. Subse-
improves the productivity as compared to native CTL quently, the test engineer reported that there are no syntax
while dealing with the modeling of verification properties. errors in the SystemVerilog RTL and assertions codes which

104426 VOLUME 8, 2020

M. W. Anwar et al.: Unified Model-Based Framework for the Simplified Execution of Static and Dynamic ABV

TABLE 5. Quantitative analysis of the MODEVES framework.

were implemented by P1. Furthermore, the test engineer lines of codes as compared to native SystemVerilog, the auto-
also confirmed that the design verification was successfully matically generated RTL code is synthesizable, as confirmed
performed for all the case studies. by the test engineer, for all the three case studies.
Once the native implementations were verified, the Sys- To analyze the quality and transformation losses regarding
temVerilog RTL and assertions codes for all the case studies, the static ABV, the automatically generated codes were given
design and transformed through the proposed framework by to P2. Subsequently, he confirmed that the CTL properties
P3, were given to the test engineer. Subsequently, he reported are transformed without any syntax or logical errors through
that the structural aspects in RTL and SVAs for all the case the proposed framework for all the case studies. He also
studies were successfully transformed through the proposed confirmed that the essential Timed Automata concepts (like
framework with 100% accuracy. Even the binding statements, locations, guards etc.) are successfully transformed through
required to bind the assertions file with RTL, have been the proposed framework. In fact, P2 was able to load the
successfully generated. He also confirmed that the proposed generated Timed Automata model (.xta) and properties (.q)
framework also successfully generated all the behavioral in UPPAAL tool without any changes. However, few state-
logic in RTL code. However, few syntax errors like missing ments/variables in the global declaration section are missing
semicolon, incorrect sequence of start and ending brackets in the automatically generated code. This is because we do not
and repetition of few statements are found in the behavioral include such information in MMM and subsequently no sup-
code. In this regard, the test engineer took 2, 3 and 2 working port is available in the transformation engine. In this regard,
hours for the correction of syntax errors in UAV, Arbiter and P2 took approximately one hour for each case study to include
Elevator case studies respectively. We believe that such slight the global declaration information in the automatically gener-
additional time periods for the corrections of syntax errors ated Timed Automata models. Subsequently, P2 successfully
in behavioral code are acceptable considering the broader verified the automatically generated CTL properties of all the
applicability of the proposed framework. Finally, the test case studies in UPPAAL.
engineer successfully performed design verification of all the In addition to the productivity gain in terms of working
case studies in QuestaSIM. hours, the proposed framework also provides several benefits
The test engineer was also asked to analyze the qual- for the achievement of certain business objectives like time-
ity of automatically generated code. Subsequently, the test to-market and cost effectiveness. For example, it can be seen
engineer confirmed that the proposed framework structural from Table 5 that it is required to employ two resources (i.e.
as well as SVAs code were almost similar, as implemented P1 and P2) for implementation at lower level. On the other
through SystemVerilog natively by P1. However, more lines hand, the same goals can be achieved with a single resource
of behavioral code were generated through the proposed (i.e. P3) through the proposed framework. Another benefit is
framework, as compared to the native SystemVerilog code. the simplified identification and correction of design errors.
This is because we have developed some generic transforma- Particularly, it is hard to track the errors during verification,
tion rules in the proposed framework by utilizing the con- where a single design requirement is represented in two
cepts of system states. Particularly, all the control statements different technologies. In the MODEVES framework, any
and required variables in the behavioral code are generated error reported during the verification process is required to
based on modeled states. This is necessary for the broader be corrected in a single design model only. Subsequently,
applicability of the proposed framework. Despite the more the corrections are automatically transferred to both low-

VOLUME 8, 2020 104427

 M. W. Anwar et al.: Unified Model-Based Framework for the Simplified Execution of Static and Dynamic ABV

level SystemVerilog and Timed Automata models during the SystemVerilog support, there exist an MBSE approach [30]
transformation process. This leads to significantly improve where the support for only dynamic ABV is provided through
the time-to-market objective. SystemVerilog. Particularly, a UML profile for SystemVer-
To summarize, the aforementioned quantitative analysis ilog (UMLSV) is proposed to model the design and verifi-
reveals that the MODEVES framework certainly improves cation requirements. However, the UMLSV is not complete
the design productivity and supports the automatic transfor- in a sense that the support for static verification has not
mation of high-level models into SystemVerilog RTL, SVAs, been provided at all. On the other hand, the MODEVES is
Timed Automata model and CTL properties with minimal a complete end-to-end framework providing a simultaneous
transformation losses. support for both static as well as dynamic ABV with a
significantly improved productivity as compared to UMLSV
V. COMPARATIVE ANALYSIS OF MODEVES FRAMEWORK (Section IV-D).
This section compares the MODEVES framework with those In addition to the aforementioned ABV-based
state-of-the-art approaches where the UML/SysML based frameworks [8], [13], [14], [30], [32], there exist several
solutions are provided in the context of ABV. For example, state-of-the-art studies [41]–[43] where the UML/SysML
Di Guglielmo et al. [8] propose a complete model-driven profiles have been exploited to provide a particular solution
framework for embedded systems to support the dynamic other than ABV. For example, Nicola Bombieri et al. [41]
ABV. The standard UML diagrams are used to represent the introduce an integrated approach to represent the existing
system design while the verification properties are expressed heterogeneous components through some equivalent SysML
in Properties Specification Language (PSL) through a sepa- behavioral models. In another study [42], a transformation
rate editor. The limitation of [8] lies in the fact that it deals approach is proposed to generate the synthesizable hardware
only with the dynamic ABV, taking C language as the target descriptions from UML state machine diagrams. Addition-
model. The proposed work in this article supports both static ally, Wolfgang Mueller et al. [43] introduce the SysML
as well as dynamic ABV through Timed Automata and Sys- based SATURN methodology for co-design. Although these
temVerilog. Even the target model for dynamic verification in approaches [41]–[43] provide significant UML/SysML based
our case (SystemVerilog) provides more advanced capabili- solutions, we are unable to perform a meaningful comparison
ties as compared to the native C language which is targeted with the MODEVES framework as their scope is different in
in [8]. In addition, the proposed framework advocates the the given research context.
representation of verification properties in actual models, In addition to the existing approaches in academia, it is
and not through a separate editor, to significantly reduce the interesting to consider few industrial projects for comparative
design and verification gap. analysis. For example, PolarSys1 is a free platform, where
While the work in [8] employs standard UML diagrams, various model-based techniques can be employed. However,
Luciano Baresi el al. [14] propose the extension of standard in the context of the proposed framework, the CHESS and
UML diagrams through some temporal logic for the repre- Papyrus-RT projects are largely related. A CHESS-ML pro-
sentation of system design. Furthermore, Corretto Property file is presented by employing the notations of UML, SysML
Language (CPL) is introduced to include the verification and MARTE profiles. In Papyrus-RT project, an end-to-end
properties. In contrast to the MODEVES framework, environment is provided for UML-RT [40] profile which
the work in [14] only deals with the static ABV. Furthermore, is based on the concepts of capsules, ports, protocol and
the modeling approach of [14] is relatively complex as stan- connectors to represent the system structure and behavior.
dard UML diagrams are annotated with some temporal logic The major limitation of these projects is the lack of a genuine
concepts. property specification approach to include the verification
In addition to [8] and [14], where either dynamic or static constraints directly in the design models as proposed in this
verification has been targeted, there exist few state-of-the- article through SVOCL and NLCTL. In addition to this, none
art MBSE frameworks like MADES [13] and Gaspard [32] of the PolarSys project simultaneously support both static and
which support both static as well as dynamic ABV. However, dynamic ABV through Timed Automata and SystemVerilog
both Gaspard and MADES frameworks do not support Sys- respectively.
temVerilog along with the Timed Automata platforms, and It can be argued that the expressiveness of SVOCL and
therefore, the advanced ABV features cannot be exploited. NLCTL can be unified in a single language for a more real-
In this regard, the MODEVES is the first framework that istic representation of verification aspects. However, the sys-
simultaneously support static as well as dynamic verifica- tematic merging of SVOCL and NLCTL in a single language
tion with advanced ABV features through Timed Automata is not possible without compromising the substantial trans-
and SystemVerilog respectively. This combination signifi- formation losses as there are significant syntax and seman-
cantly improves the design productivity (Section IV-D) while tic differences between SVAs and CTL. Therefore, unifying
achieving the maximum test coverage during the verification SVOCL and NLCTL in a single language is not feasible.
process. For example, the extension of SVOCL for CTL properties
While the work in [13] and [32] lack the exploita-
tion of advanced ABV features due to the absence of 1 https://www.polarsys.org/list-of-projects

104428 VOLUME 8, 2020

M. W. Anwar et al.: Unified Model-Based Framework for the Simplified Execution of Static and Dynamic ABV

eventually make SVOCL impracticable due to severe com- individually as well as collectively, for a particular
plexity while the transformation losses is another issue. research objective.
On the other hand, few separate rules may be added in
NLCTL for SVAs. However, this will actually lead to two VI. CONCLUSIONS AND FUTURE WORK
separate languages (i.e. few rules for CTL and other rules for A model driven framework (MODEVES), with a
SVAs) under the umbrella of NLCTL which is unsystematic. simultaneous support for static and dynamic assertions based
To summarize, both SVOCL and NLCTL have their own verification, has been proposed which is capable to cap-
importance in certain situations, therefore, it is more suitable ture the structural, behavioral and verification requirements
to manage them separately in the MODEVES framework. collectively. The modeling methodology for system design
Despite the introduction of two separate modeling lan- has exploited the well-known notations in UML/SysML
guages, the combination of SVOCL and NLCTL provides diagrams while a simple formalism (NLCTL) has been pro-
several benefits to designers over the traditional ABV meth- posed to model the static verification properties. Moreover,
ods: 1) SVOCL enables the exact inclusion of SVAs in design the SVOCL has been used to support the dynamic verification
models while NLCTL allows the modeling of CTL proper- process. Subsequently, an open source transformation engine
ties in natural language alike syntax with simplicity. This has been developed to automatically transform the high-level
leads to an effective and accurate transformation of SVOCL source models into SystemVerilog RTL, Timed Automata
and NLCTL properties into corresponding SVAs and CTL model, SVAs and CTL assertions. This enables the execution
assertions. (2) SVOCL and NLCTL enable the concurrent of both static and dynamic ABV in early development phases.
modeling of assertions along with the system design, while The applicability of the proposed framework is demonstrated
in traditional methods, it is essential to first develop system through various case studies and the experimental results
design (RTL or formal model) before the specifications of have shown that the MODEVES framework is almost 100%
assertions. (3) Their combination has improved the design more efficient as compared to the conventional low-level
productivity, as compared to the traditional low level SVAs implementations.
and CTL properties, as established in Section IV-D. Being a fully open source solution, which is based on
It can be argued that the objectives of MODEVES some renowned MBSE standards, several extensions of the
framework can be achieved through existing state-of-the-art MODEVES framework are possible. For example, it can
approaches. For example, the approach in [30] can be used to be extended for System of Systems (SoS) by incorporating
perform dynamic ABV and the work in [14] can be employed various integration aspects. In addition to this, the modeling
to perform static ABV. As a result, both static as well as and transformation support for test benches can be included
dynamic ABV can be achieved. However, the utilization of to completely automate the dynamic ABV process. Similarly,
existing methods (such as [30] and [14]) in an ad hoc manner the support for modern verification standards like Portable
is not practically feasible without compromising the design Test and Stimulus Standard (PSS) can be encompassed to
productivity. Particularly, it is required to model the system meet the growing verification demands of embedded systems.
design twice i.e. modeling in [30] for dynamic ABV and
modeling in [14] for static ABV. This is time consuming and REFERENCES
may lead to several verification errors as it is always difficult [1] R. Xu, L. Zhang, and N. Ge, ‘‘Modeling and timing analysis for
to trace and correct the errors in the presence of two separate microkernel-based real-time embedded system,’’ IEEE Access, vol. 7,
design models. Such issues significantly reduce the design pp. 39547–39563, 2019.
[2] M. Rashid, M. W. Anwar, and A. khan, ‘‘Towards the tools selection in
productivity and time-to-market. model based system engineering for embedded systems—A systematic
To summarize, the key benefits of the proposed work are: literature review,’’ J. Syst. Softw., vol. 106, pp. 150–163, Oct. 2015.
1. Simplicity: It allows to model the system design in a [3] J. Hooman, H. Kugler, I. Ober, A. Votintseva, and Y. Yushtein, ‘‘Supporting
UML-based development of embedded systems by formal techniques,’’
unified way through standard UML/SysML notations. Softw. Syst. Model., vol. 7, no. 2, pp. 131–155, May 2008.
The verification is supported through two different [4] M. Edmund Clarke, W. Klieber, M. Nováek, and P. Zuliani, ‘‘Model
formalisms to make the verification process easy and checking and the state explosion problem,’’ in Tools for Practical Soft-
ware Verification (Lecture Notes in Computer Science), vol. 7682. Berlin,
accurate. Germany: Springer, 2011, pp. 1–30.
2. Early Design Verification: The seamless and auto- [5] H. Foster, ‘‘Applied assertion-based verification: An industry perspective,’’
matic translation of ‘‘complete models’’, in terms of J. Found. Trends Electron. Design Autom., vol. 2009, Volume 3, no. 1,
pp. 1–95.
design as well as verification, leads to early verification
[6] H. Sohofi and Z. Navabi, ‘‘System-level assertions approach for elec-
by simply employing state-of-the-art tools. tronic system-level verification,’’ IET Comput. Digit. Techn., vol. 9, no. 3,
3. Productivity Gain: It is almost 100% more efficient pp. 142–152, 2015.
(Section IV-D) as compared to the corresponding [7] M. Loghi, T. Margaria, G. Pravadelli, and B. Steffen, ‘‘Dynamic and formal
verification of embedded systems: A comparative survey,’’ Int. J. Parallel
native technologies (SystemVerilog, Timed Automata Program., vol. 33, no. 6, pp. 585–611, Dec. 2005, doi: 10.1007/s10766-
and CTL). 005-8911-2.
4. Open Source: It is publically available [19] for prac- [8] G. Di Guglielmo, L. Di Guglielmo, A. Foltinek, M. Fujita, F. Fummi,
C. Marconcini, and G. Pravadelli, ‘‘On the integration of model-driven
tical usage and, therefore, enables the researchers design and dynamic assertion-based verification for embedded software,’’
and practitioners to customize its various components, J. Syst. Softw., vol. 86, no. 8, pp. 2013–2033, Aug. 2013.

VOLUME 8, 2020 104429

 M. W. Anwar et al.: Unified Model-Based Framework for the Simplified Execution of Static and Dynamic ABV

[9] R. David and L. Dill, ‘‘A theory of timed automata,’’ Theor. Comput. Sci., [34] M. Rashid, M. W. Anwar, F. Azam, and M. Kashif, ‘‘Exploring the platform
vol. 126, no. 2, pp. 183–235, 1994. for expressing systemVerilog assertions in model based system engineer-
[10] E. Cindy and D. Fismana, A Practical Introduction to PSL. New York, NY, ing,’’ in Information Science and Applications (Lecture Notes in Electrical
USA: Springer-Verlag 2006. Engineering), vol. 376. Singapore: Springer, 2016, pp. 533–544.
[11] (Aug. 2019). IEEE Standard for Property Specification Language. [35] (Dec. 2019). Papyrus MDT. [Online]. Available: http://www.eclipse.org/
[Online]. Available: http://ieeexplore.ieee.org/xpl/articleDetails.jsp? modeling/mdt/papyrus/
arnumber=5446004 [36] MODEVES Project. (Mar. 2020). Design Verification Details. [Online].
[12] (Aug. 2019). IEEE SystemVerilog Standard IEEE STD 1800-2009. Available: http://www.modeves.com/dvquesta.html
[Online]. Available: http://ieeexplore.ieee.org/xpl/mostRecentIssue. [37] (Feb. 2019). Xilinx Vivado Design Suite. [Online]. Available:
jsp?punumber=5354133 http://www.xilinx.com/products/design-tools/vivado.html
[13] R. I. Quadri, E. Brosse, I. Gray, N. Matragkas, L. S. Indrusiak, M. Rossi, [38] (Nov. 2018). Accellera Universal Verification Methodology Standard.
A. Bagnato, and A. Sadovykh, ‘‘MADES FP7 EU project: Effective high [Online]. Available: http://www.accellera.org/downloads/standards/uvm
level SysML/MARTE methodology for real-time and embedded avionics [39] M. Lora, S. Vinco, and F. Fummi, ‘‘Translation, abstraction and integration
systems,’’ in Proc. 7th Int. Workshop Reconfigurable Commun.-Centric for effective smart system design,’’ IEEE Trans. Comput., vol. 68, no. 10,
Syst. Chip (ReCoSoC), 2012, pp. 1–8. pp. 1525–1538, Oct. 2019.
[14] L. Baresi, A. Morzenti, A. Motta, M. M. P. K., and M. Rossi, ‘‘A logic- [40] B. Selic, ‘‘Using UML for modeling complex real-time systems,’’ in Proc.
based approach for the verification of UML timed models,’’ ACM Trans. Lang., Compliers Tools Embedded Syst. (LCTES), 1998, pp. 250–260.
Softw. Eng. Methodol., vol. 26, no. 2, pp. 1–47, Oct. 2017. [41] N. Bombieri, ‘‘On the reuse of heterogeneous IPs into SysML models
[15] M. W. Anwar, M. Rashid, F. Azam, and M. Kashif, ‘‘Model-based design for integration validation,’’ J. Electron. Test, vol. 29, p. 647, May 2013,
verification for embedded systems through SVOCL: An OCL extension for doi: 10.1007/s10836-013-5409-5.
systemVerilog,’’ An Int. J. Design Autom. Embedded Syst., vol. 21, no. 1, [42] M. Lora, F. Martinelli, and F. Fummi, ‘‘Hardware synthesis from software-
pp. 1–36, 2017. oriented UML descriptions,’’ in Proc. 15th Int. Microprocessor Test Veri-
[16] (Dec. 2019). Eclipse Acceleo. [Online]. Available: https://eclipse. fication Workshop, New York, NY, USA, Dec. 2014, pp. 33–38.
org/acceleo/ [43] W. Mueller, ‘‘The SATURN approach to SysML-based HW/SW,’’ in Proc.
[17] Mentor Graphics. (Dec. 2019). QuestaSim. [Online]. Available: IEEE Comput. Soc. Annu. Symp., 2010, pp. 151–164.
https://www.mentor.com/products/fv/questa/
[18] A. Hessel, K. G. Larsen, M. Mikucionis, B. Nielsen, P. Pettersson, and
A. Skou, ‘‘Testing real-time systems using UPPAAL,’’ in Formal Meth-
ods and Testing (Lecture Notes in Computer Science), vol. 4949,
R. M. Hierons, J. P. Bowen, and M. Harman, Eds. Berlin, Germany: MUHAMMAD WASEEM ANWAR is currently
Springer, 2018. pursuing the Ph.D. degree with the Department
[19] MODEVES Project. (Mar. 2020). Transformation Engine. [Online].
of Computer and Software Engineering, CEME,
Available: http://modeves.com/mte.html
[20] (Mar. 2019). Object Management Group (OMG) Systems National University of Sciences and Technology,
Modeling Language Specification. [Online]. Available: http://www. Pakistan. He is also a Senior Researcher and an
omg.org/spec/SysML/1.3/ Industry Practitioner in the field of model-based
[21] MODEVES Framework. (Feb. 2020). MODEVES Modeling Methodology. system engineering (MBSE) for embedded and
[Online]. Available: http://modeves.com/docs/MMM.pdf control systems. His major research interest
[22] M. Rashid, M. W. Anwar, F. Azam, and M. Kashif, ‘‘Model-based require- includes MBSE for complex and large systems.
ments and properties specifications trends for early design verification of
embedded systems,’’ in Proc. 11th Syst. Syst. Eng. Conf. (SoSE), Jun. 2016,
pp. 1–15.
[23] R. Bill, S. Gabmeyer, P. Kaufmann, and M. Seid, ‘‘Model checking of CTL-
extended OCL specifications,’’ Softw. Lang. Eng., vol. 8706, pp. 221–240,
Dec. 2014, doi: 10.1007/978-3-319-11245-9_13. MUHAMMAD RASHID (Member, IEEE)
[24] S. Flake and W. Mueller, ‘‘Real-time systems, specification properties received the bachelor’s degree in electrical engi-
UML,’’ in Proc. HICSS, 2002, pp. 3977–3986. neering from the University of Engineering and
[25] A. Louati, K. Barkaoui, and C. Jerad, ‘‘Properties verification of real-
Technology, Peshawar, Pakistan, in 2000, the mas-
time systems using UML/MARTE/OCL-RT,’’ Formalisms Reuse Syst.
ter’s degree in embedded systems design from
Integr. Adv. Intell. Syst. Comput., vol. 346, pp. 133–147, Oct. 2015,
doi: 10.1007/978-3-319-16577-6_6. the University of Nice, Sophia-Antipolis, France,
[26] A. C. Patthak, I. Bhattacharya, A. Dasgupta, P. Dasgupta, and in 2006, and the Ph.D. degree in embedded sys-
P. P. Chakrabarti, ‘‘Quantified computation tree logic,’’ Inf. Process. Lett., tems design from the University of Bretagne Occi-
vol. 82, no. 3, pp. 123–129, May 2002. dentale, Brest, France, in 2009. He is currently an
[27] F. Essalmi and L. J. B. Ayed, ‘‘Graphical UML view from extended backus- Assistant Professor with the Computer Engineer-
naur form grammars,’’ in Proc. 6th IEEE Int. Conf. Adv. Learn. Technol., ing Department, Umm Al-Qura University, Mecca, Saudi Arabia.
2006, pp. 455–456.
[28] (Sep. 2019). Accellera Portable Test and Stimulus Standard (PSS).
[Online]. Available: https://www.accellera.org/downloads/standards/
portable-stimulus
[29] I. Qasim, M. W. Anwar, F. Azam, H. Tufail, W. H. Butt, and M. N. Zafar, FAROOQUE AZAM is currently a Key Faculty
‘‘A model-driven mobile HMI framework (MMHF) for industrial control Member with the Department of Computer and
systems,’’ IEEE Access, vol. 8, pp. 10827–10846, 2020. Software Engineering, EME College, National
[30] M. W. Anwar, M. Rashid, F. Azam, M. Kashif, and W. H. Butt, University of Sciences and Technology (NUST),
‘‘A model-driven framework for design and verification of embedded
Pakistan. He has been involving in post graduate
systems through SystemVerilog,’’ Design Autom. Embedded Syst., vol. 23,
teaching and research, since 2007. His research
nos. 3–4, pp. 179–223, Dec. 2019.
[31] MODEVES Project. (Dec. 2019). NLCTL Grammar and Validation. interests include model driven software engineer-
[Online]. Available: http://modeves.com/nlctl.html ing, model driven testing, model driven embedded
[32] A. Gamatié, S. Le Beux, É. Piel, R. Ben Atitallah, A. Etien, P. Marquet, and applications, model driven web engineering, soft-
J.-L. Dekeyser, ‘‘A model-driven design framework for massively parallel ware design and architectures, and so on. He is a
embedded systems,’’ ACM Trans. Embedded Comput. Syst., vol. 10, no. 4, Regular Member of Evaluation Committees of Pakistan Engineering Coun-
pp. 1–36, Nov. 2011. cil (PEC) and Higher Education Commission’s Technological Development
[33] T. Fitzpatrick, ‘‘SystemVerilog for VHDL users,’’ in Proc. Design, Autom. Funding (HEC-TDF). Since April 2020, he has 138 international journal and
Test Eur. Conf. Exhibit., 2004, pp. 1334–1349. conference publications on his credit.

104430 VOLUME 8, 2020

M. W. Anwar et al.: Unified Model-Based Framework for the Simplified Execution of Static and Dynamic ABV

AAMIR NAEEM received the master’s degree WASI HAIDER BUTT is currently an Assis-
from the Department of Computer and Software tant Professor with the Department of Computer
Engineering, CEME, National University of Sci- and Software Engineering, College of Electrical
ences and Technology (NUST), Pakistan. He is and Mechanical Engineering, National Univer-
currently working as a Research Associate with sity of Sciences and Technology, Pakistan. His
the Model Driven Software Engineering Group, research interests include model driven software
CEME-NUST. His research interests include for- engineering, and web development and require-
mal verification and model-based development for ment engineering.
embedded systems.

MUHAMMAD KASHIF received the master’s

degree from Istanbul şehir University, Turkey,
in 2019. He is currently pursuing the Ph.D. degree
in computer science and engineering with Hamad
Bin Khalifa University, Qatar. His research inter-
ests include system level modeling, early design
verification of embedded systems, hardware secu-
rity, quantum computing, and machine learning.

VOLUME 8, 2020 104431