On Verification and Validation of State
73
Vol 02, Issue 02; June 2011
International Journal of Communication Engineering Applications-IJCEA
http://technicaljournals.org
ISSN: 2230-8520; e-ISSN-2230-8539
On Verification and Validation of State based Internal Behavioral
Models of Embedded Systems
V. Chandra Prakash, Sastry JKR, D. Bala Krishna Kamesh
K L University, Vaddeswaram, Guntur District 522502
ABSTRACT
Designing and Development of high quality systems require that in process verification and validation of Design
models be carried and not leaving the verification and validation till the end of code development. Clean Room
Software Engineering (CRSE) methodology advocates that verification and validation be done in process after
completion of designing of different models. CRSE has in it the verification and validation process models after
completion of designing of Black Box (BB), State Box (SB) and Clear Box (CB). CRSE advocated formal models
for carrying the verification and validation. While very recently the authors of this paper have published
automated formal models for verifying and validating the Black Box structures, no such automated and formal
models existed earlier for validation and verifying the state models which are primarily meant for designing the
internal behavior of the embedded systems. In this paper a verification and validation method has been
proposed to validate the internal behavior represented by state charts models. The refined CRSE methodology
incorporating the proposed verification and validation method has been presented. The model is used for
verifying and validating the State model proposed earlier by the authors for verifying and validating the internal
behavior of a pilot project called “Temperature Monitoring and Controlling of Nuclear Reactor System
(TMCNRS)”.
Key words: Embedded Systems, Sate Box, Clean Room Software Engineering, Verification and Validation,
UML models
1.
INTRODUCTION:
Clean Room Software Engineering methodology is basically aimed at developing high quality systems through
implementation of formalism and continuous verification and validation models implemented at every stage of
the development. Formal methods which are mathematics oriented have been suggested to present all the phases
which are presented covering the development flow of the methodology. CRSE methodology involves two
parallel flows; while in one flow the design is undertaken and the other flow deals with undertaking the testing
of the code developed through Design Flow. Fig 1.1 shows the CRSE methodology.
Embedded systems must be high quality and fault tolerant, and are built around the internal and external
behavior modeling as they are basically stimulus-response models. Many features of CRSE match with the
development requirements of the embedded systems. However, some changes are needed in the CRSE
methodology so that the methodology can be conveniently used for the development of the embedded systems.
Sastry, Chandra Praksh et al. [1] [2] [3] [4] have recommended the improvement of CRSE model for
formalizing the development and verification and validation of external behavior model. The authors [5] have
also proposed a method for formalizing and automating the development of internal behavioral model
represented in the state charts. The revised CRSE model recommended by them is shown in the Figure 1.2
2011 - TECHNICALJOURNALS®, Peer Reviewed International Journals-IJCEA, IJESR, RJCSE, PAPER, ERL - PBPC, India;
Indexing in Process - Scopus, EMBASE, COMPENDEX, EmCARE, Electronics & Communication Abstracts, SCIRUS, SPARC, GOOGLE Database, EBSCO, NewJour, Worldcat,
DOAJ, and other major databases etc.,
74
Vol 02, Issue 02; June 2011
International Journal of Communication Engineering Applications-IJCEA
http://technicaljournals.org
ISSN: 2230-8520; e-ISSN-2230-8539
Fig 1.1 Original CRSE Model
The authors further moved on to inventing the formal models, algorithms and the processes for formalizing the
development of the internal behavioral models through State Box structures.
.
Fig 1.2 Refined CRSE for formalizing the external and internal behavior model and V&V of external model
The authors now propose a method for verifying and validating state model meant for modeling the internal
behavior of the embedded systems.
2.0 RELATED WORK
Verification and Validation (V&V) methods differ when internal behavior is designed using the external
behavior or when internal behavior is designed independent of external behavior. In this paper, the V&V of
internal behavior is addressed when internal behavior is designed independent of external behavior modeling.
Michael Deck [7] has clearly made a distinction between specification and design. While the specification is the
abstract description of the behavior of the system, the design is towards the implementation of the behavior. A
design could be evaluated through assessing correctness and design quality. A design is correct with respect to a
specification if the designed behavior and the specified behavior are exactly the same under all circumstances of
use. A verification method should be used to verify whether the design is in accordance with the expected
behavior.
2011 - TECHNICALJOURNALS®, Peer Reviewed International Journals-IJCEA, IJESR, RJCSE, PAPER, ERL - PBPC, India;
Indexing in Process - Scopus, EMBASE, COMPENDEX, EmCARE, Electronics & Communication Abstracts, SCIRUS, SPARC, GOOGLE Database, EBSCO, NewJour, Worldcat,
DOAJ, and other major databases etc.,
75
Vol 02, Issue 02; June 2011
International Journal of Communication Engineering Applications-IJCEA
http://technicaljournals.org
ISSN: 2230-8520; e-ISSN-2230-8539
The evaluation of the quality, on the other hand, is subjective because while the design meets the behavioral
requirements, may not necessarily be correct. Therefore, it is necessary that the correctness of the design be
assured by testing the design for performance, simplicity, robustness, obviousness, load sharing between
components and narrowness of interfaces. A variety of techniques are proposed in Cleanroom Software
Engineering methodology to evaluate the correctness through a review process. But here again, no formal
mechanism is suggested for evaluating the quality of the design.
Harlan D. Mills [6] advocates discovering state data requirements from the responses which define the
necessary information to be maintained in the State Box. By appending the state transitions to the state data, the
complete State Box is obtained. This State Box is verified by comparing the intended Black Box with the
derived Black Box obtained by eliminating the state data.
Michael Deck [7] advocated the usage of representative mapping function that defines a correspondence
between elements of the Black Box data space and elements of the State Box data space. The mapping between
the State Box data space and the black box data space is usually many-to-one and every point in Black Box must
match at least with one point in the Sate Box. During the definition of the concrete model the State Box designer
should define the representation mapping properly.
State boxes correspond closely to the traditional view of objects as encapsulations of state data and services, or
methods, on that data. In this view, stimuli and responses are inputs and outputs, respectively, of specific service
invocations.[8]. Box structures bring correctness verification to object architectures. State boxes can be verified
with respect to their black boxes, and clear boxes verified with respect to their state boxes. [9]
In all the methods mentioned above, not much formalism has been considered and as such the integration of the
methods proposed by them into CRSE methodology has not been advocated.
3.0 PILOT PROJECT – TEMPERATURE MONITORING AND CONTROLLING OF NUCLEAR
REACTOR SYSTEM (TMCNRS)
The block diagram at Figure 3.1 shows various hardware components and the integration between them related
to TMCNRS.. The mechanical setups that simulate the Nuclear reactors are connected with sensing devices such
as Temperature sensors, and actuating devices such as heaters and pumps. Both the sensing and actuating
devices are connected to the embedded system (TARGET) and the embedded system is connected to a remote
computer (HOST) through which the operator monitors and controls the operation of the nuclear reactor.
The temperature sensors are connected to signal conditioners and the outputs of signal conditioners are
connected to A/D converter which communicates with Micro Controller using I2C Communication protocol.
The output devices which include LCD, interface to HOST, and Relays to actuate pumps are connected to the
Micro Controller through its output ports. The access to the embedded system is controlled through a password
entered through the key board which in connected to A/D converter. The application running in the embedded
system captures the key board strokes and verifies the validity of the password. The rest of the application is
invoked when the password is valid.
Different types of outputs are written on LCD such as Help messages, Sensed temperatures, reference
temperatures, and temperature mismatches etc. The HOST is connected to the Micro Controller using RS232C
interface. The ES application has the interface for reading the reference temperatures and displaying the same on
LCD A buzzer is connected to Micro Controller and the buzzer is triggered when the difference in temperatures
read is more than a threshold level. The ES board is provided with regulated power supply to drive the Micro
Controller and to the relays for activating the pumps. The sensors are mounted on the water tube situated in the
mechanical setup. Flow control is achieved through activation and deactivation of the relays that control the
Start-Stop mechanism of the pumps. Heaters are used to raise the temperature of the tubes. The mechanical
setup for such an arrangement is shown in the Figure 3.2.
2011 - TECHNICALJOURNALS®, Peer Reviewed International Journals-IJCEA, IJESR, RJCSE, PAPER, ERL - PBPC, India;
Indexing in Process - Scopus, EMBASE, COMPENDEX, EmCARE, Electronics & Communication Abstracts, SCIRUS, SPARC, GOOGLE Database, EBSCO, NewJour, Worldcat,
DOAJ, and other major databases etc.,
76
Vol 02, Issue 02; June 2011
International Journal of Communication Engineering Applications-IJCEA
http://technicaljournals.org
ISSN: 2230-8520; e-ISSN-2230-8539
Figure 3.1 TMCNRS Hardware Integration diagram
Figure 3.2 Mechanical setup of the TMCNRS
The Embedded application that runs within the Micro Controller has the following tasks:
1. Read Key Board input
2. Validate the Password
3. Read Reference Temperatures from the HOST
4. Write Initialization output to LCD
5. Write actual outputs to LCD
6. Read the sensed Temperatures
7. Compare the Temperatures
8. Actuate the buzzer
9. Set and reset the relays to control the pumps
10. Communicate with HOST to transmit the sensed Temperatures
2011 - TECHNICALJOURNALS®, Peer Reviewed International Journals-IJCEA, IJESR, RJCSE, PAPER, ERL - PBPC, India;
Indexing in Process - Scopus, EMBASE, COMPENDEX, EmCARE, Electronics & Communication Abstracts, SCIRUS, SPARC, GOOGLE Database, EBSCO, NewJour, Worldcat,
DOAJ, and other major databases etc.,
77
Vol 02, Issue 02; June 2011
International Journal of Communication Engineering Applications-IJCEA
http://technicaljournals.org
ISSN: 2230-8520; e-ISSN-2230-8539
4.0 DESIGNING FORMAL AND AUTOMATED STATE MODELS
Chandra Prakash, Sastry et al. [5] have proposed models for designing the internal behavior of the embedded
systems and shown the incorporation of the models in the design flow of CRSE methodology. They have
proposed the following sequence of operations for arriving at the state models.
1.
2.
3.
4.
5.
6.
From the specification of the embedded system, object modeling is done using Class diagrams. The
UML artifact identifies the Objects and the relationships between them.
A repository of the objects is created clearly identifying the precedence relationship between them.
All the flow sequences that exist among the objects are generated using the repository of the objects
and a Flow Graph Matrix is created. Each of the columns in the Flow Graph Matrix indicates a
sequence flow with the object structure responsible for realizing a use case. A sample Flow Graph
Matrix is shown in the Flow is shown in the Table 4.1
Flow sequences are drawn using the Flow Graph Matrix.
The State diagram is developed using a separate algorithm which not only presents the top level state
structure but also using the sub charts which completely explain the internal processing of the
embedded system.
Each state in the top level State diagram is exploded into further state diagrams based in the
composition of elementary level of the states undertaken.
A hierarchical State Box structure is developed using the interconnected state diagrams.
The sequence flows shown in the Flow Graph Matrix truly represent the state structure that indicates the internal
behavior of the embedded systems. Thus, the Flow Graph Matrix provides the fundamental basis of undertaking
the verification and validation of the state models.
5.0 FORMAL FRAMEWORK FOR VERIFICATION AND VALIDATION OF THE STATE MODELS
In embedded systems, End-to-End (E2E) processing is important as it refers to the minimal of the processing
required. For the TMCNRS system, 19 different process flows have been identified. Each process flow is called
as thin thread. The thin threads can be combined to form complex thin threads based on the commonality of
processing, thus providing the hierarchical structure to the process flow.
Embedded systems are event driven. The events are either system driven or initiated by an external environment
through sensing devices such as Temperature sensors. The sensed data is transmitted and captured by an
embedded system. The inputs are processed and the processed results are used to trigger signals that control the
physical environment. The entire processing can be represented in terms of a physical thread of execution. An
event process is a functional requirement, and the devices involved need that a function be executed as per
certain timing considerations and the timing is to be achieved by following a particular pattern.
Event processing within the embedded systems has been a challenge as several issues related to interaction
between the Hardware Components, Software Components and in between Hardware and Software Components
have to be considered.
E2E processing of an embedded system is more relevant as the entire processing can be recognized in terms of
event based processing starting from initiation of an interrupt by the hardware to the processing of emergent
requirements and passing the control to mundane tasks which can be executed in a predefined process flow
leading to control of physical parameters. This means that the E2E processing can be carried considering the
entire system as a whole and not as part of a system. Given a scenario of an embedded system, it is necessary
that the processing be completed rather quickly thereby reducing the time required for processing the event.
Raymond Paul [9] presented the concept of thin threads which are true representatives of the functional
requirements of a system from the end user point of view. This model typically suits to loaded systems and can
be used to present the processing requirements by using the hierarchical structures. The thin threads to be used
as processing structures can be presented as a Tree structure.
2011 - TECHNICALJOURNALS®, Peer Reviewed International Journals-IJCEA, IJESR, RJCSE, PAPER, ERL - PBPC, India;
Indexing in Process - Scopus, EMBASE, COMPENDEX, EmCARE, Electronics & Communication Abstracts, SCIRUS, SPARC, GOOGLE Database, EBSCO, NewJour, Worldcat,
DOAJ, and other major databases etc.,
78
Vol 02, Issue 02; June 2011
International Journal of Communication Engineering Applications-IJCEA
http://technicaljournals.org
ISSN: 2230-8520; e-ISSN-2230-8539
Unlike the loaded systems, the embedded systems are event driven and the events either occur randomly or in a
cooperated sequence. The occurrence of some of the events is conditional. The occurrence of the events can
also happen in terms of some patterns. Feng Zhu et al. [10] have presented event patterns which together form
the basis for processing occurrence of a set of events in a sequence.
About 80% of time is to be spent on integrated processing of the embedded systems as the integration of
Hardware devices, integration of Software components and the integration of software components with the
Hardware devices is the major effort to complete the entire processing. The integrated processing of the
embedded system must be conducted considering the entire system as a whole.
The functional requirements traced from the description of the embedded system shall be the basis of identifying
the thin threads. Table 5.1 shows the functional requirements of the TMCNRS. From the functional
requirements one can trace stimulus –responses and each stimulus-response shall represent a thin thread in the
system. The list of stimulus-response sequences for the TMCNRS is presented in Table 5.2. Fig 5.1 to 5.5
shows some samples of E2E flows of the TMCNRS.
Fig 5.1 Thin Thread for reading the Temperature-1 and writing to LCD
Fig 5.2 Thin Thread for reading the Temperature-1 and actuating the pump control
2011 - TECHNICALJOURNALS®, Peer Reviewed International Journals-IJCEA, IJESR, RJCSE, PAPER, ERL - PBPC, India;
Indexing in Process - Scopus, EMBASE, COMPENDEX, EmCARE, Electronics & Communication Abstracts, SCIRUS, SPARC, GOOGLE Database, EBSCO, NewJour, Worldcat,
DOAJ, and other major databases etc.,
79
Vol 02, Issue 02; June 2011
International Journal of Communication Engineering Applications-IJCEA
http://technicaljournals.org
ISSN: 2230-8520; e-ISSN-2230-8539
Fig 5.3 Thin Thread for comparing Temperature -1 and Temperature -2 and actuating the buzzer in case of
mismatch
Fig 5.3 Thin Thread for processing Reset Button
2011 - TECHNICALJOURNALS®, Peer Reviewed International Journals-IJCEA, IJESR, RJCSE, PAPER, ERL - PBPC, India;
Indexing in Process - Scopus, EMBASE, COMPENDEX, EmCARE, Electronics & Communication Abstracts, SCIRUS, SPARC, GOOGLE Database, EBSCO, NewJour, Worldcat,
DOAJ, and other major databases etc.,
80
Vol 02, Issue 02; June 2011
International Journal of Communication Engineering Applications-IJCEA
http://technicaljournals.org
ISSN: 2230-8520; e-ISSN-2230-8539
Fig 5.3 Thin Thread for password validation
All the thin threads have process components and the process components exist in a sequence. A repository of
relationships between the process components can be captured and maintained. The table showing the
relationships is shown in Table 5.3. Using the threads mentioned above, a Flow Graph Matrix is formed by
using the following Algorithm. For each of the thin threads, add a column to the Flow Graph Matrix and map
the process components to the respective rows by following the logic below:
{
For each of the Process components, identify its preceding components by referring to the Table 5.3
{
If any of the preceding components exists in any of the existing row, then create a row after the last
preceding component and map the component to the row-column
If the current component is preceding component to the existing component, then create a row before
the existing component and map the component to row-column
}
For each of the row pair related to two process components, check the precedence using the Table 5.3.
If the precedence fails, then interchange the rows
}
The Flow Graph Matrix thus prepared by executing the above mentioned algorithm is shown in the Table 5.4.
One can easily verify that the Flow Graph Matrix generated to develop the state model and the Flow Graph
Matrix generated through E2E are same and therefore the state model has been built correctly representing the
internal behavior of the system.
6.0 Conclusions
CRSE methodology has been recommended keeping in view of the formalism for presentation of accurate
specification, hierarchical structure for handling complexity, and gradual development through incremental and
iterative models. CRSE however have not recommended formal models for undertaking different phases of
development as recommended in the methodology. CRSE has not only recommended the formal models for the
design of internal behavioral models but also the formal models required for verification and validation of the
behavioral model. No formal models are in existence in the literature as today to conduct verification and
validation using the formal models.
UML has provided excellent platform to deliver different types of formal models. In this paper an approach is
recommended using UML artifacts for formalizing the verification and validation of internal behavior of
embedded systems through generation of sequence flows using class models and E2E processing models. The
verification and validation is presented through development of data repositories from two sources which
include classes and E2E processing and proving that the repositories are the same.
The models presented in this paper or formal and can be used to automate verification and validation of internal
behavior models represented as state charts. This paper has provided a verification framework for verifying and
validating the State models developed to exhibit the internal behavior of the embedded systems.
References
[1] Dr Sastry JKR, Prof. V. Chandra Prakash et al., “A Formal Framework for verification and validation of
external behavioral models of embedded systems represented through Black Box structures”, Proceedings
of IEEE sponsored 2nd International Advance Computing Conference (IACC), Feb.2010.
2011 - TECHNICALJOURNALS®, Peer Reviewed International Journals-IJCEA, IJESR, RJCSE, PAPER, ERL - PBPC, India;
Indexing in Process - Scopus, EMBASE, COMPENDEX, EmCARE, Electronics & Communication Abstracts, SCIRUS, SPARC, GOOGLE Database, EBSCO, NewJour, Worldcat,
DOAJ, and other major databases etc.,
81
Vol 02, Issue 02; June 2011
International Journal of Communication Engineering Applications-IJCEA
http://technicaljournals.org
ISSN: 2230-8520; e-ISSN-2230-8539
[2] Dr Sastry JKR, Prof. V Chandra Prakash et al., “A formal framework for presenting requirement
specifications of an embedded systems as a Black Box structure”, Proceedings of International Joint
Conference on Information and Communication Technology (IJCICT-2010) January, 2010
[3] Dr Sastry JKR, Prof. V Chandra Prakash et al., “A Formal Framework for Modeling External Behavior of an
embedded system as a Black Box structure”, Proceedings of IEEE sponsored 4th International Conference
on "Embedded and Multimedia Computing", EM-Com 2009 Dec. 2009.
[4] Dr Sastry JKR, Prof. V. Chandra Prakash et al., “A formal Framework for Verification and Validation of
External Behavior models of embedded systems through Use Case Models”, IEEE sponsored 4th
International Conference on "Embedded and Multimedia Computing", EM-Com 2009 Dec. 2009.
[5] Prof. V. Chandra Prakash, Dr. Sastry JKR, et al. “Internal Behavioral Modeling of Embedded Systems
through State Box Structures”, Paper communicated to “International Journal on Advanced Networks and
Applications” for publication.
[6] Harlan D. Mills, “Stepwise Refinement and Verification in Box-Structured Systems”, Journal IEEE
Computer, Jun-88, Volume 21 Issue 6, Page 23-36
[7] Michael Deck, “Data Abstraction in the Box structures Approach”, 3rd International conference on
Cleanroom Software Engineering practices, Oct 10-11, 1996, college park, MD
[8] Linger, R.C., “Clean room Software Engineering for Zero- Defect Software”, Proceedings of 15th
International Conference on Software Engineering, 1993.
[9] Mills, 13. D., R. C. Linger, and A. R. Hevner, “Principles of Information Systems Analysis and Design”,
Academic Press, San Diego, CA, 1986.
[10] Paul Raymond, “End-to-End Integration Testing ”, Ph.D. thesis, Dept. of Computer Science and
Engineering, University of Minnesota, Minneapolis, MN, 2001
[11] Feng Zhu, “A Requirement Verification Framework for Real-time Embedded Systems”, Ph.D. thesis, Dept.
of Computer Science and Engineering, University of Minnesota, Minneapolis, MN, 2002
2011 - TECHNICALJOURNALS®, Peer Reviewed International Journals-IJCEA, IJESR, RJCSE, PAPER, ERL - PBPC, India;
Indexing in Process - Scopus, EMBASE, COMPENDEX, EmCARE, Electronics & Communication Abstracts, SCIRUS, SPARC, GOOGLE Database, EBSCO, NewJour, Worldcat,
DOAJ, and other major databases etc.,
82
International Journal of Communication Engineering Applications-IJCEA
Vol 02, Issue 02; June 2011
http://technicaljournals.org
ISSN: 2230-8520; e-ISSN-2230-8539
Serial
Number
of
Compo
nent
Name of the
Component
0101
Reset Button
Type of
componen
t
(Hhardware,
SSoftware)
H
0102
0202
Wait-1
Key Board
H
0303
Temp1-Sensor
H
0404
Temp2-Sensor
H
0505
Operational
Amplifier-1
Operational
Amplifier-2
A/D Converter
HOST
H
0606
0707
0808
0909
1010
1111
1212
1313
1414
1515
1616
1717
1818
1919
2020
2112
2211
2309
2408
2525
2626
2727
2828
2929
3030
Communication with
HOST
Micro Controller
Initialization Process
Validate process
Process Key
Temp-1 Task
Temp2-Task
Compare Temp1 with
Ref1
Compare Temp2 with
Ref2
Process Temp1 and
Temp2
Process LCD
LCD
Validation process
Initialization Process
Communication with
HOST
HOST
Process Buzzer
Buzzer
Relay-1
Pump-1
Relay-2
Pump-2
Events
Push Reset
Button
ST1
Press Key1 to Key5
Validate
Password
Read Temp-1
and process
pump
Compare
temp-1 and
Temp2 and
assert
√
√
√
√
√
√
√
√
H
√
H
H
√
√
√
√
S
H
S
S
S
S
S
S
√
√
√
√
√
√
√
√
√
√
S
√
S
S
H
S
S
S
√
√
√
√
√
√
√
√
H
S
H
H
H
H
H
Table 4.1 Flow Graph Matrix for Sequence Flows
√
√
√
√
2011 - TECHNICALJOURNALS®, Peer Reviewed International Journals-IJCEA, IJESR, RJCSE, PAPER, ERL - PBPC, India;
Indexing in Process - Scopus, EMBASE, COMPENDEX, EmCARE, Electronics & Communication Abstracts, SCIRUS, SPARC, GOOGLE Database, EBSCO, NewJour, Worldcat,
DOAJ, and other major databases etc.,
83
International Journal of Communication Engineering Applications-IJCEA
Vol 02, Issue 02; June 2011
http://technicaljournals.org
ISSN: 2230-8520; e-ISSN-2230-8539
Serial
Number
REQ1
REQ 2
REQ 3
REQ 4
REQ 5
REQ 6
REQ 7
REQ 8
REQ 9
REQ10
REQ11
REQ12
REQ13
Thin
No
1
Functional requirements
On reset, TMCNRS must display Title of the Application on LCD
On Reset, Prompt for entering Password must be displayed on the LCD
On pressing 1st Key an * is displayed on the LCD retaining the Key value in the memory. The key pressed
should be one of A-F and 0-9
On pressing 2nd Key an * must be displayed on the LCD retaining the Key value in the memory. The key
pressed should be one of A-F and 0-9
On pressing 3rd Key an * must be displayed on the LCD retaining the Key value in the memory. The key
pressed should be one of A-F and 0-9
On pressing 4th Key an * must be displayed on the LCD retaining the Key value in the memory. The key
pressed should be one of A-F and 0-9
On pressing 5th Key an * must be displayed on the LCD retaining the Key value in the memory. The key
pressed should be one of A-F and 0-9. A display message must be made on the LCD if the entered password is
invalid and a prompt must be displayed to reenter the password once again
Display a message on the LCD prompting to input reference Temperatures
Read Reference Temperature-1 from the HOST and store the same in the memory
Read Reference temperature-2 from the HOST and store the same in the memory
Sense Temperature-1 once in 10 milli Seconds and display the same on LCD and send the Temperature-1 to
HOST
If the Temperature-1 sensed > reference Temperature-2 then the Relay connected to the Pump-1 must be
activated; else deactivated
After sensing the Temperature -1, sense Temperature-2 after 10 milli seconds and displays the same on LCD
and send the Temperature-2 to HOST. If the Temperature-2 sensed > reference Temperature-2 then the Relay
connected to the Pump-2 must be activated, else deactivated
If ABS (Temp-1 – Temp-2) > 2 Assert the Buzzer; else de-assert the Buzzer.
Table 5.1 Functional Specification of TMCNRS
Stimulus
Response
Read Temp-1
Send Temp-1 to HOST
7
8
9
10
11
12
13
14
15
Read Temp-1
Compare Temp-1 with
Ref-1 Temperature
Read Temp-2
Read Temp-2
Compare Temp-2 with
Ref-2 Temperature
If ABS (Temp-1 – Temp-2) > 2
If ABS (Temp-1 – Temp-2) > 2
Reset
Press Key-1
Press Key-2
Press Key-3
Press Key-4
Press Key-5
Send request to HOST
16
17
Read Ref-1 temperature from Host
Read Ref-2 temperature from Host
Write on LCD
if Temp-1 > Ref-1 start Pump-1 ;
else stop Pump-1
Send Temp-2 to HOST
Write on LCD
if Temp-2 > Ref-2 start Pump-2;
else stop Pump-2
Write mismatch on LCD
Assert Buzzer; else de-assert Buzzer
Display messages on LCD
Display Key-1
Display Key-2
Display Key-3
Display Key-4
Display Key-5
Display message on LCD requesting HOST to transmit Reference
Temperatures
Write Ref-1 on LCD
Write Ref-2 on LCD
2
3
4
5
6
Table 5.2 Stimulus-Response Sequence for TMCNRS
2011 - TECHNICALJOURNALS®, Peer Reviewed International Journals-IJCEA, IJESR, RJCSE, PAPER, ERL - PBPC, India;
Indexing in Process - Scopus, EMBASE, COMPENDEX, EmCARE, Electronics & Communication Abstracts, SCIRUS, SPARC, GOOGLE Database, EBSCO, NewJour, Worldcat,
DOAJ, and other major databases etc.,
84
International Journal of Communication Engineering Applications-IJCEA
Vol 02, Issue 02; June 2011
http://technicaljournals.org
ISSN: 2230-8520; e-ISSN-2230-8539
Serial
Number of
Component
1
2
Reset Button
Micro Controller
Type of Process
Component
(H- hardware,
S-Software)
H
H
3
HOST
H
4
LCD
H
5
A/D Converter
H
6
7
8
9
H
H
H
H
Temp1-Sensor
H
Temp2-Sensor
11
Key Board
Temp1-Sensor
Temp2-Sensor
Operational
Amplifier-1
Operational
Amplifier-2
Buzzer
H
12
13
14
Pump-1
Pump-2
Relay-1
H
H
H
15
Relay-2
H
16
17
18
Process Key
Validate Password
Process LCD
S
S
S
Process Buzzer
Micro Controller
Relay-1
Relay-2
Compare Temp1 with Ref1
Micro Controller
Compare Temp2 with Ref2
Micro Controller
Initialization Process
Initialization Process
Initialization Process
Name of the Process
Component
10
Preceding Components
Reset Button
A/D Converter
HOST
Communicate with Host
Micro Controller
Process LCD
Micro Controller
Process Key
TEMP 1 TASK
TEMP 2 TASK
KEY BOARD
Operational Amplifier-1
Operational Amplifier-2
19
20
Initialization Process
Communication with
HOST
S
S
21
Temp-1 Task
S
22
Temp2-Task
S
23
Compare Temp1 with
Ref1
Compare Temp2 with
Ref2
Process Temp1 and
S
Validate Password
Temp 1 Task
Temp 2 Task
Communicate with HOST
Process Temp-1 and Temp2 Task
Micro Controller
Initialization Process
Temp1-Task
Temp2-Task
HOST
Micro Controller
A/D Converter
Micro Controller
A/D Converter
Temp1 Task
S
Temp2 Task
S
Micro Controller
24
25
2011 - TECHNICALJOURNALS®, Peer Reviewed International Journals-IJCEA, IJESR, RJCSE, PAPER, ERL - PBPC, India;
Indexing in Process - Scopus, EMBASE, COMPENDEX, EmCARE, Electronics & Communication Abstracts, SCIRUS, SPARC, GOOGLE Database, EBSCO, NewJour, Worldcat,
DOAJ, and other major databases etc.,
85
International Journal of Communication Engineering Applications-IJCEA
Vol 02, Issue 02; June 2011
http://technicaljournals.org
ISSN: 2230-8520; e-ISSN-2230-8539
Temp2
26
Process Buzzer
Micro Controller
Process Temp1 and Temp2
S
Table 5.3 Relationships between the process components of the thin threads
Serial
Numb
er of
Comp
onent
Name of the process
Type of
Process
(Hhardware,
SSoftware)
0101
0102
Reset Button
Wait-1
H
0202
Key Board
H
0303
Temp1-Sensor
H
0404
Temp2-Sensor
H
0505
0606
Operational Amplifier-1
Operational Amplifier-2
H
H
0707
0808
A/D Converter
HOST
H
H
0909
Communication with
HOST
Micro Controller
Initialization Process
Validate process
Process Key
Temp-1 Task
Temp2-Task
Compare Temp1 with Ref1
Compare Temp2 with Ref2
Process Temp1 and Temp2
Process LCD
LCD
Validation process
Initialization Process
Communication with
HOST
HOST
Process Buzzer
Buzzer
Relay-1
Pump-1
Relay-2
Pump-2
S
1010
1111
1212
1313
1414
1515
1616
1717
1818
1919
2020
2112
2211
2309
2408
2525
2626
2727
2828
2929
3030
H
S
S
S
S
S
S
S
S
S
H
S
S
S
Thin
Thread-9
Push
Reset
Button
ST1
Thin
Thread-10 to
Thin
Thread-14
Press Key-1
to Key5
ThinThreda-15
Validate
Password
√
Thin
Thread-3
Thin
Thread-7
Read Temp1 and
process
pump
Compare
temp-1
and
Temp2
and
assert
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
H
S
H
H
H
H
H
√
√
√
√
Table 5.4 Flow Graph Matrix generated through thin threads
2011 - TECHNICALJOURNALS®, Peer Reviewed International Journals-IJCEA, IJESR, RJCSE, PAPER, ERL - PBPC, India;
Indexing in Process - Scopus, EMBASE, COMPENDEX, EmCARE, Electronics & Communication Abstracts, SCIRUS, SPARC, GOOGLE Database, EBSCO, NewJour, Worldcat,
DOAJ, and other major databases etc.,
Vol 02, Issue 02; June 2011
International Journal of Communication Engineering Applications-IJCEA
http://technicaljournals.org
ISSN: 2230-8520; e-ISSN-2230-8539
On Verification and Validation of State based Internal Behavioral
Models of Embedded Systems
V. Chandra Prakash, Sastry JKR, D. Bala Krishna Kamesh
K L University, Vaddeswaram, Guntur District 522502
ABSTRACT
Designing and Development of high quality systems require that in process verification and validation of Design
models be carried and not leaving the verification and validation till the end of code development. Clean Room
Software Engineering (CRSE) methodology advocates that verification and validation be done in process after
completion of designing of different models. CRSE has in it the verification and validation process models after
completion of designing of Black Box (BB), State Box (SB) and Clear Box (CB). CRSE advocated formal models
for carrying the verification and validation. While very recently the authors of this paper have published
automated formal models for verifying and validating the Black Box structures, no such automated and formal
models existed earlier for validation and verifying the state models which are primarily meant for designing the
internal behavior of the embedded systems. In this paper a verification and validation method has been
proposed to validate the internal behavior represented by state charts models. The refined CRSE methodology
incorporating the proposed verification and validation method has been presented. The model is used for
verifying and validating the State model proposed earlier by the authors for verifying and validating the internal
behavior of a pilot project called “Temperature Monitoring and Controlling of Nuclear Reactor System
(TMCNRS)”.
Key words: Embedded Systems, Sate Box, Clean Room Software Engineering, Verification and Validation,
UML models
1.
INTRODUCTION:
Clean Room Software Engineering methodology is basically aimed at developing high quality systems through
implementation of formalism and continuous verification and validation models implemented at every stage of
the development. Formal methods which are mathematics oriented have been suggested to present all the phases
which are presented covering the development flow of the methodology. CRSE methodology involves two
parallel flows; while in one flow the design is undertaken and the other flow deals with undertaking the testing
of the code developed through Design Flow. Fig 1.1 shows the CRSE methodology.
Embedded systems must be high quality and fault tolerant, and are built around the internal and external
behavior modeling as they are basically stimulus-response models. Many features of CRSE match with the
development requirements of the embedded systems. However, some changes are needed in the CRSE
methodology so that the methodology can be conveniently used for the development of the embedded systems.
Sastry, Chandra Praksh et al. [1] [2] [3] [4] have recommended the improvement of CRSE model for
formalizing the development and verification and validation of external behavior model. The authors [5] have
also proposed a method for formalizing and automating the development of internal behavioral model
represented in the state charts. The revised CRSE model recommended by them is shown in the Figure 1.2
2011 - TECHNICALJOURNALS®, Peer Reviewed International Journals-IJCEA, IJESR, RJCSE, PAPER, ERL - PBPC, India;
Indexing in Process - Scopus, EMBASE, COMPENDEX, EmCARE, Electronics & Communication Abstracts, SCIRUS, SPARC, GOOGLE Database, EBSCO, NewJour, Worldcat,
DOAJ, and other major databases etc.,
74
Vol 02, Issue 02; June 2011
International Journal of Communication Engineering Applications-IJCEA
http://technicaljournals.org
ISSN: 2230-8520; e-ISSN-2230-8539
Fig 1.1 Original CRSE Model
The authors further moved on to inventing the formal models, algorithms and the processes for formalizing the
development of the internal behavioral models through State Box structures.
.
Fig 1.2 Refined CRSE for formalizing the external and internal behavior model and V&V of external model
The authors now propose a method for verifying and validating state model meant for modeling the internal
behavior of the embedded systems.
2.0 RELATED WORK
Verification and Validation (V&V) methods differ when internal behavior is designed using the external
behavior or when internal behavior is designed independent of external behavior. In this paper, the V&V of
internal behavior is addressed when internal behavior is designed independent of external behavior modeling.
Michael Deck [7] has clearly made a distinction between specification and design. While the specification is the
abstract description of the behavior of the system, the design is towards the implementation of the behavior. A
design could be evaluated through assessing correctness and design quality. A design is correct with respect to a
specification if the designed behavior and the specified behavior are exactly the same under all circumstances of
use. A verification method should be used to verify whether the design is in accordance with the expected
behavior.
2011 - TECHNICALJOURNALS®, Peer Reviewed International Journals-IJCEA, IJESR, RJCSE, PAPER, ERL - PBPC, India;
Indexing in Process - Scopus, EMBASE, COMPENDEX, EmCARE, Electronics & Communication Abstracts, SCIRUS, SPARC, GOOGLE Database, EBSCO, NewJour, Worldcat,
DOAJ, and other major databases etc.,
75
Vol 02, Issue 02; June 2011
International Journal of Communication Engineering Applications-IJCEA
http://technicaljournals.org
ISSN: 2230-8520; e-ISSN-2230-8539
The evaluation of the quality, on the other hand, is subjective because while the design meets the behavioral
requirements, may not necessarily be correct. Therefore, it is necessary that the correctness of the design be
assured by testing the design for performance, simplicity, robustness, obviousness, load sharing between
components and narrowness of interfaces. A variety of techniques are proposed in Cleanroom Software
Engineering methodology to evaluate the correctness through a review process. But here again, no formal
mechanism is suggested for evaluating the quality of the design.
Harlan D. Mills [6] advocates discovering state data requirements from the responses which define the
necessary information to be maintained in the State Box. By appending the state transitions to the state data, the
complete State Box is obtained. This State Box is verified by comparing the intended Black Box with the
derived Black Box obtained by eliminating the state data.
Michael Deck [7] advocated the usage of representative mapping function that defines a correspondence
between elements of the Black Box data space and elements of the State Box data space. The mapping between
the State Box data space and the black box data space is usually many-to-one and every point in Black Box must
match at least with one point in the Sate Box. During the definition of the concrete model the State Box designer
should define the representation mapping properly.
State boxes correspond closely to the traditional view of objects as encapsulations of state data and services, or
methods, on that data. In this view, stimuli and responses are inputs and outputs, respectively, of specific service
invocations.[8]. Box structures bring correctness verification to object architectures. State boxes can be verified
with respect to their black boxes, and clear boxes verified with respect to their state boxes. [9]
In all the methods mentioned above, not much formalism has been considered and as such the integration of the
methods proposed by them into CRSE methodology has not been advocated.
3.0 PILOT PROJECT – TEMPERATURE MONITORING AND CONTROLLING OF NUCLEAR
REACTOR SYSTEM (TMCNRS)
The block diagram at Figure 3.1 shows various hardware components and the integration between them related
to TMCNRS.. The mechanical setups that simulate the Nuclear reactors are connected with sensing devices such
as Temperature sensors, and actuating devices such as heaters and pumps. Both the sensing and actuating
devices are connected to the embedded system (TARGET) and the embedded system is connected to a remote
computer (HOST) through which the operator monitors and controls the operation of the nuclear reactor.
The temperature sensors are connected to signal conditioners and the outputs of signal conditioners are
connected to A/D converter which communicates with Micro Controller using I2C Communication protocol.
The output devices which include LCD, interface to HOST, and Relays to actuate pumps are connected to the
Micro Controller through its output ports. The access to the embedded system is controlled through a password
entered through the key board which in connected to A/D converter. The application running in the embedded
system captures the key board strokes and verifies the validity of the password. The rest of the application is
invoked when the password is valid.
Different types of outputs are written on LCD such as Help messages, Sensed temperatures, reference
temperatures, and temperature mismatches etc. The HOST is connected to the Micro Controller using RS232C
interface. The ES application has the interface for reading the reference temperatures and displaying the same on
LCD A buzzer is connected to Micro Controller and the buzzer is triggered when the difference in temperatures
read is more than a threshold level. The ES board is provided with regulated power supply to drive the Micro
Controller and to the relays for activating the pumps. The sensors are mounted on the water tube situated in the
mechanical setup. Flow control is achieved through activation and deactivation of the relays that control the
Start-Stop mechanism of the pumps. Heaters are used to raise the temperature of the tubes. The mechanical
setup for such an arrangement is shown in the Figure 3.2.
2011 - TECHNICALJOURNALS®, Peer Reviewed International Journals-IJCEA, IJESR, RJCSE, PAPER, ERL - PBPC, India;
Indexing in Process - Scopus, EMBASE, COMPENDEX, EmCARE, Electronics & Communication Abstracts, SCIRUS, SPARC, GOOGLE Database, EBSCO, NewJour, Worldcat,
DOAJ, and other major databases etc.,
76
Vol 02, Issue 02; June 2011
International Journal of Communication Engineering Applications-IJCEA
http://technicaljournals.org
ISSN: 2230-8520; e-ISSN-2230-8539
Figure 3.1 TMCNRS Hardware Integration diagram
Figure 3.2 Mechanical setup of the TMCNRS
The Embedded application that runs within the Micro Controller has the following tasks:
1. Read Key Board input
2. Validate the Password
3. Read Reference Temperatures from the HOST
4. Write Initialization output to LCD
5. Write actual outputs to LCD
6. Read the sensed Temperatures
7. Compare the Temperatures
8. Actuate the buzzer
9. Set and reset the relays to control the pumps
10. Communicate with HOST to transmit the sensed Temperatures
2011 - TECHNICALJOURNALS®, Peer Reviewed International Journals-IJCEA, IJESR, RJCSE, PAPER, ERL - PBPC, India;
Indexing in Process - Scopus, EMBASE, COMPENDEX, EmCARE, Electronics & Communication Abstracts, SCIRUS, SPARC, GOOGLE Database, EBSCO, NewJour, Worldcat,
DOAJ, and other major databases etc.,
77
Vol 02, Issue 02; June 2011
International Journal of Communication Engineering Applications-IJCEA
http://technicaljournals.org
ISSN: 2230-8520; e-ISSN-2230-8539
4.0 DESIGNING FORMAL AND AUTOMATED STATE MODELS
Chandra Prakash, Sastry et al. [5] have proposed models for designing the internal behavior of the embedded
systems and shown the incorporation of the models in the design flow of CRSE methodology. They have
proposed the following sequence of operations for arriving at the state models.
1.
2.
3.
4.
5.
6.
From the specification of the embedded system, object modeling is done using Class diagrams. The
UML artifact identifies the Objects and the relationships between them.
A repository of the objects is created clearly identifying the precedence relationship between them.
All the flow sequences that exist among the objects are generated using the repository of the objects
and a Flow Graph Matrix is created. Each of the columns in the Flow Graph Matrix indicates a
sequence flow with the object structure responsible for realizing a use case. A sample Flow Graph
Matrix is shown in the Flow is shown in the Table 4.1
Flow sequences are drawn using the Flow Graph Matrix.
The State diagram is developed using a separate algorithm which not only presents the top level state
structure but also using the sub charts which completely explain the internal processing of the
embedded system.
Each state in the top level State diagram is exploded into further state diagrams based in the
composition of elementary level of the states undertaken.
A hierarchical State Box structure is developed using the interconnected state diagrams.
The sequence flows shown in the Flow Graph Matrix truly represent the state structure that indicates the internal
behavior of the embedded systems. Thus, the Flow Graph Matrix provides the fundamental basis of undertaking
the verification and validation of the state models.
5.0 FORMAL FRAMEWORK FOR VERIFICATION AND VALIDATION OF THE STATE MODELS
In embedded systems, End-to-End (E2E) processing is important as it refers to the minimal of the processing
required. For the TMCNRS system, 19 different process flows have been identified. Each process flow is called
as thin thread. The thin threads can be combined to form complex thin threads based on the commonality of
processing, thus providing the hierarchical structure to the process flow.
Embedded systems are event driven. The events are either system driven or initiated by an external environment
through sensing devices such as Temperature sensors. The sensed data is transmitted and captured by an
embedded system. The inputs are processed and the processed results are used to trigger signals that control the
physical environment. The entire processing can be represented in terms of a physical thread of execution. An
event process is a functional requirement, and the devices involved need that a function be executed as per
certain timing considerations and the timing is to be achieved by following a particular pattern.
Event processing within the embedded systems has been a challenge as several issues related to interaction
between the Hardware Components, Software Components and in between Hardware and Software Components
have to be considered.
E2E processing of an embedded system is more relevant as the entire processing can be recognized in terms of
event based processing starting from initiation of an interrupt by the hardware to the processing of emergent
requirements and passing the control to mundane tasks which can be executed in a predefined process flow
leading to control of physical parameters. This means that the E2E processing can be carried considering the
entire system as a whole and not as part of a system. Given a scenario of an embedded system, it is necessary
that the processing be completed rather quickly thereby reducing the time required for processing the event.
Raymond Paul [9] presented the concept of thin threads which are true representatives of the functional
requirements of a system from the end user point of view. This model typically suits to loaded systems and can
be used to present the processing requirements by using the hierarchical structures. The thin threads to be used
as processing structures can be presented as a Tree structure.
2011 - TECHNICALJOURNALS®, Peer Reviewed International Journals-IJCEA, IJESR, RJCSE, PAPER, ERL - PBPC, India;
Indexing in Process - Scopus, EMBASE, COMPENDEX, EmCARE, Electronics & Communication Abstracts, SCIRUS, SPARC, GOOGLE Database, EBSCO, NewJour, Worldcat,
DOAJ, and other major databases etc.,
78
Vol 02, Issue 02; June 2011
International Journal of Communication Engineering Applications-IJCEA
http://technicaljournals.org
ISSN: 2230-8520; e-ISSN-2230-8539
Unlike the loaded systems, the embedded systems are event driven and the events either occur randomly or in a
cooperated sequence. The occurrence of some of the events is conditional. The occurrence of the events can
also happen in terms of some patterns. Feng Zhu et al. [10] have presented event patterns which together form
the basis for processing occurrence of a set of events in a sequence.
About 80% of time is to be spent on integrated processing of the embedded systems as the integration of
Hardware devices, integration of Software components and the integration of software components with the
Hardware devices is the major effort to complete the entire processing. The integrated processing of the
embedded system must be conducted considering the entire system as a whole.
The functional requirements traced from the description of the embedded system shall be the basis of identifying
the thin threads. Table 5.1 shows the functional requirements of the TMCNRS. From the functional
requirements one can trace stimulus –responses and each stimulus-response shall represent a thin thread in the
system. The list of stimulus-response sequences for the TMCNRS is presented in Table 5.2. Fig 5.1 to 5.5
shows some samples of E2E flows of the TMCNRS.
Fig 5.1 Thin Thread for reading the Temperature-1 and writing to LCD
Fig 5.2 Thin Thread for reading the Temperature-1 and actuating the pump control
2011 - TECHNICALJOURNALS®, Peer Reviewed International Journals-IJCEA, IJESR, RJCSE, PAPER, ERL - PBPC, India;
Indexing in Process - Scopus, EMBASE, COMPENDEX, EmCARE, Electronics & Communication Abstracts, SCIRUS, SPARC, GOOGLE Database, EBSCO, NewJour, Worldcat,
DOAJ, and other major databases etc.,
79
Vol 02, Issue 02; June 2011
International Journal of Communication Engineering Applications-IJCEA
http://technicaljournals.org
ISSN: 2230-8520; e-ISSN-2230-8539
Fig 5.3 Thin Thread for comparing Temperature -1 and Temperature -2 and actuating the buzzer in case of
mismatch
Fig 5.3 Thin Thread for processing Reset Button
2011 - TECHNICALJOURNALS®, Peer Reviewed International Journals-IJCEA, IJESR, RJCSE, PAPER, ERL - PBPC, India;
Indexing in Process - Scopus, EMBASE, COMPENDEX, EmCARE, Electronics & Communication Abstracts, SCIRUS, SPARC, GOOGLE Database, EBSCO, NewJour, Worldcat,
DOAJ, and other major databases etc.,
80
Vol 02, Issue 02; June 2011
International Journal of Communication Engineering Applications-IJCEA
http://technicaljournals.org
ISSN: 2230-8520; e-ISSN-2230-8539
Fig 5.3 Thin Thread for password validation
All the thin threads have process components and the process components exist in a sequence. A repository of
relationships between the process components can be captured and maintained. The table showing the
relationships is shown in Table 5.3. Using the threads mentioned above, a Flow Graph Matrix is formed by
using the following Algorithm. For each of the thin threads, add a column to the Flow Graph Matrix and map
the process components to the respective rows by following the logic below:
{
For each of the Process components, identify its preceding components by referring to the Table 5.3
{
If any of the preceding components exists in any of the existing row, then create a row after the last
preceding component and map the component to the row-column
If the current component is preceding component to the existing component, then create a row before
the existing component and map the component to row-column
}
For each of the row pair related to two process components, check the precedence using the Table 5.3.
If the precedence fails, then interchange the rows
}
The Flow Graph Matrix thus prepared by executing the above mentioned algorithm is shown in the Table 5.4.
One can easily verify that the Flow Graph Matrix generated to develop the state model and the Flow Graph
Matrix generated through E2E are same and therefore the state model has been built correctly representing the
internal behavior of the system.
6.0 Conclusions
CRSE methodology has been recommended keeping in view of the formalism for presentation of accurate
specification, hierarchical structure for handling complexity, and gradual development through incremental and
iterative models. CRSE however have not recommended formal models for undertaking different phases of
development as recommended in the methodology. CRSE has not only recommended the formal models for the
design of internal behavioral models but also the formal models required for verification and validation of the
behavioral model. No formal models are in existence in the literature as today to conduct verification and
validation using the formal models.
UML has provided excellent platform to deliver different types of formal models. In this paper an approach is
recommended using UML artifacts for formalizing the verification and validation of internal behavior of
embedded systems through generation of sequence flows using class models and E2E processing models. The
verification and validation is presented through development of data repositories from two sources which
include classes and E2E processing and proving that the repositories are the same.
The models presented in this paper or formal and can be used to automate verification and validation of internal
behavior models represented as state charts. This paper has provided a verification framework for verifying and
validating the State models developed to exhibit the internal behavior of the embedded systems.
References
[1] Dr Sastry JKR, Prof. V. Chandra Prakash et al., “A Formal Framework for verification and validation of
external behavioral models of embedded systems represented through Black Box structures”, Proceedings
of IEEE sponsored 2nd International Advance Computing Conference (IACC), Feb.2010.
2011 - TECHNICALJOURNALS®, Peer Reviewed International Journals-IJCEA, IJESR, RJCSE, PAPER, ERL - PBPC, India;
Indexing in Process - Scopus, EMBASE, COMPENDEX, EmCARE, Electronics & Communication Abstracts, SCIRUS, SPARC, GOOGLE Database, EBSCO, NewJour, Worldcat,
DOAJ, and other major databases etc.,
81
Vol 02, Issue 02; June 2011
International Journal of Communication Engineering Applications-IJCEA
http://technicaljournals.org
ISSN: 2230-8520; e-ISSN-2230-8539
[2] Dr Sastry JKR, Prof. V Chandra Prakash et al., “A formal framework for presenting requirement
specifications of an embedded systems as a Black Box structure”, Proceedings of International Joint
Conference on Information and Communication Technology (IJCICT-2010) January, 2010
[3] Dr Sastry JKR, Prof. V Chandra Prakash et al., “A Formal Framework for Modeling External Behavior of an
embedded system as a Black Box structure”, Proceedings of IEEE sponsored 4th International Conference
on "Embedded and Multimedia Computing", EM-Com 2009 Dec. 2009.
[4] Dr Sastry JKR, Prof. V. Chandra Prakash et al., “A formal Framework for Verification and Validation of
External Behavior models of embedded systems through Use Case Models”, IEEE sponsored 4th
International Conference on "Embedded and Multimedia Computing", EM-Com 2009 Dec. 2009.
[5] Prof. V. Chandra Prakash, Dr. Sastry JKR, et al. “Internal Behavioral Modeling of Embedded Systems
through State Box Structures”, Paper communicated to “International Journal on Advanced Networks and
Applications” for publication.
[6] Harlan D. Mills, “Stepwise Refinement and Verification in Box-Structured Systems”, Journal IEEE
Computer, Jun-88, Volume 21 Issue 6, Page 23-36
[7] Michael Deck, “Data Abstraction in the Box structures Approach”, 3rd International conference on
Cleanroom Software Engineering practices, Oct 10-11, 1996, college park, MD
[8] Linger, R.C., “Clean room Software Engineering for Zero- Defect Software”, Proceedings of 15th
International Conference on Software Engineering, 1993.
[9] Mills, 13. D., R. C. Linger, and A. R. Hevner, “Principles of Information Systems Analysis and Design”,
Academic Press, San Diego, CA, 1986.
[10] Paul Raymond, “End-to-End Integration Testing ”, Ph.D. thesis, Dept. of Computer Science and
Engineering, University of Minnesota, Minneapolis, MN, 2001
[11] Feng Zhu, “A Requirement Verification Framework for Real-time Embedded Systems”, Ph.D. thesis, Dept.
of Computer Science and Engineering, University of Minnesota, Minneapolis, MN, 2002
2011 - TECHNICALJOURNALS®, Peer Reviewed International Journals-IJCEA, IJESR, RJCSE, PAPER, ERL - PBPC, India;
Indexing in Process - Scopus, EMBASE, COMPENDEX, EmCARE, Electronics & Communication Abstracts, SCIRUS, SPARC, GOOGLE Database, EBSCO, NewJour, Worldcat,
DOAJ, and other major databases etc.,
82
International Journal of Communication Engineering Applications-IJCEA
Vol 02, Issue 02; June 2011
http://technicaljournals.org
ISSN: 2230-8520; e-ISSN-2230-8539
Serial
Number
of
Compo
nent
Name of the
Component
0101
Reset Button
Type of
componen
t
(Hhardware,
SSoftware)
H
0102
0202
Wait-1
Key Board
H
0303
Temp1-Sensor
H
0404
Temp2-Sensor
H
0505
Operational
Amplifier-1
Operational
Amplifier-2
A/D Converter
HOST
H
0606
0707
0808
0909
1010
1111
1212
1313
1414
1515
1616
1717
1818
1919
2020
2112
2211
2309
2408
2525
2626
2727
2828
2929
3030
Communication with
HOST
Micro Controller
Initialization Process
Validate process
Process Key
Temp-1 Task
Temp2-Task
Compare Temp1 with
Ref1
Compare Temp2 with
Ref2
Process Temp1 and
Temp2
Process LCD
LCD
Validation process
Initialization Process
Communication with
HOST
HOST
Process Buzzer
Buzzer
Relay-1
Pump-1
Relay-2
Pump-2
Events
Push Reset
Button
ST1
Press Key1 to Key5
Validate
Password
Read Temp-1
and process
pump
Compare
temp-1 and
Temp2 and
assert
√
√
√
√
√
√
√
√
H
√
H
H
√
√
√
√
S
H
S
S
S
S
S
S
√
√
√
√
√
√
√
√
√
√
S
√
S
S
H
S
S
S
√
√
√
√
√
√
√
√
H
S
H
H
H
H
H
Table 4.1 Flow Graph Matrix for Sequence Flows
√
√
√
√
2011 - TECHNICALJOURNALS®, Peer Reviewed International Journals-IJCEA, IJESR, RJCSE, PAPER, ERL - PBPC, India;
Indexing in Process - Scopus, EMBASE, COMPENDEX, EmCARE, Electronics & Communication Abstracts, SCIRUS, SPARC, GOOGLE Database, EBSCO, NewJour, Worldcat,
DOAJ, and other major databases etc.,
83
International Journal of Communication Engineering Applications-IJCEA
Vol 02, Issue 02; June 2011
http://technicaljournals.org
ISSN: 2230-8520; e-ISSN-2230-8539
Serial
Number
REQ1
REQ 2
REQ 3
REQ 4
REQ 5
REQ 6
REQ 7
REQ 8
REQ 9
REQ10
REQ11
REQ12
REQ13
Thin
No
1
Functional requirements
On reset, TMCNRS must display Title of the Application on LCD
On Reset, Prompt for entering Password must be displayed on the LCD
On pressing 1st Key an * is displayed on the LCD retaining the Key value in the memory. The key pressed
should be one of A-F and 0-9
On pressing 2nd Key an * must be displayed on the LCD retaining the Key value in the memory. The key
pressed should be one of A-F and 0-9
On pressing 3rd Key an * must be displayed on the LCD retaining the Key value in the memory. The key
pressed should be one of A-F and 0-9
On pressing 4th Key an * must be displayed on the LCD retaining the Key value in the memory. The key
pressed should be one of A-F and 0-9
On pressing 5th Key an * must be displayed on the LCD retaining the Key value in the memory. The key
pressed should be one of A-F and 0-9. A display message must be made on the LCD if the entered password is
invalid and a prompt must be displayed to reenter the password once again
Display a message on the LCD prompting to input reference Temperatures
Read Reference Temperature-1 from the HOST and store the same in the memory
Read Reference temperature-2 from the HOST and store the same in the memory
Sense Temperature-1 once in 10 milli Seconds and display the same on LCD and send the Temperature-1 to
HOST
If the Temperature-1 sensed > reference Temperature-2 then the Relay connected to the Pump-1 must be
activated; else deactivated
After sensing the Temperature -1, sense Temperature-2 after 10 milli seconds and displays the same on LCD
and send the Temperature-2 to HOST. If the Temperature-2 sensed > reference Temperature-2 then the Relay
connected to the Pump-2 must be activated, else deactivated
If ABS (Temp-1 – Temp-2) > 2 Assert the Buzzer; else de-assert the Buzzer.
Table 5.1 Functional Specification of TMCNRS
Stimulus
Response
Read Temp-1
Send Temp-1 to HOST
7
8
9
10
11
12
13
14
15
Read Temp-1
Compare Temp-1 with
Ref-1 Temperature
Read Temp-2
Read Temp-2
Compare Temp-2 with
Ref-2 Temperature
If ABS (Temp-1 – Temp-2) > 2
If ABS (Temp-1 – Temp-2) > 2
Reset
Press Key-1
Press Key-2
Press Key-3
Press Key-4
Press Key-5
Send request to HOST
16
17
Read Ref-1 temperature from Host
Read Ref-2 temperature from Host
Write on LCD
if Temp-1 > Ref-1 start Pump-1 ;
else stop Pump-1
Send Temp-2 to HOST
Write on LCD
if Temp-2 > Ref-2 start Pump-2;
else stop Pump-2
Write mismatch on LCD
Assert Buzzer; else de-assert Buzzer
Display messages on LCD
Display Key-1
Display Key-2
Display Key-3
Display Key-4
Display Key-5
Display message on LCD requesting HOST to transmit Reference
Temperatures
Write Ref-1 on LCD
Write Ref-2 on LCD
2
3
4
5
6
Table 5.2 Stimulus-Response Sequence for TMCNRS
2011 - TECHNICALJOURNALS®, Peer Reviewed International Journals-IJCEA, IJESR, RJCSE, PAPER, ERL - PBPC, India;
Indexing in Process - Scopus, EMBASE, COMPENDEX, EmCARE, Electronics & Communication Abstracts, SCIRUS, SPARC, GOOGLE Database, EBSCO, NewJour, Worldcat,
DOAJ, and other major databases etc.,
84
International Journal of Communication Engineering Applications-IJCEA
Vol 02, Issue 02; June 2011
http://technicaljournals.org
ISSN: 2230-8520; e-ISSN-2230-8539
Serial
Number of
Component
1
2
Reset Button
Micro Controller
Type of Process
Component
(H- hardware,
S-Software)
H
H
3
HOST
H
4
LCD
H
5
A/D Converter
H
6
7
8
9
H
H
H
H
Temp1-Sensor
H
Temp2-Sensor
11
Key Board
Temp1-Sensor
Temp2-Sensor
Operational
Amplifier-1
Operational
Amplifier-2
Buzzer
H
12
13
14
Pump-1
Pump-2
Relay-1
H
H
H
15
Relay-2
H
16
17
18
Process Key
Validate Password
Process LCD
S
S
S
Process Buzzer
Micro Controller
Relay-1
Relay-2
Compare Temp1 with Ref1
Micro Controller
Compare Temp2 with Ref2
Micro Controller
Initialization Process
Initialization Process
Initialization Process
Name of the Process
Component
10
Preceding Components
Reset Button
A/D Converter
HOST
Communicate with Host
Micro Controller
Process LCD
Micro Controller
Process Key
TEMP 1 TASK
TEMP 2 TASK
KEY BOARD
Operational Amplifier-1
Operational Amplifier-2
19
20
Initialization Process
Communication with
HOST
S
S
21
Temp-1 Task
S
22
Temp2-Task
S
23
Compare Temp1 with
Ref1
Compare Temp2 with
Ref2
Process Temp1 and
S
Validate Password
Temp 1 Task
Temp 2 Task
Communicate with HOST
Process Temp-1 and Temp2 Task
Micro Controller
Initialization Process
Temp1-Task
Temp2-Task
HOST
Micro Controller
A/D Converter
Micro Controller
A/D Converter
Temp1 Task
S
Temp2 Task
S
Micro Controller
24
25
2011 - TECHNICALJOURNALS®, Peer Reviewed International Journals-IJCEA, IJESR, RJCSE, PAPER, ERL - PBPC, India;
Indexing in Process - Scopus, EMBASE, COMPENDEX, EmCARE, Electronics & Communication Abstracts, SCIRUS, SPARC, GOOGLE Database, EBSCO, NewJour, Worldcat,
DOAJ, and other major databases etc.,
85
International Journal of Communication Engineering Applications-IJCEA
Vol 02, Issue 02; June 2011
http://technicaljournals.org
ISSN: 2230-8520; e-ISSN-2230-8539
Temp2
26
Process Buzzer
Micro Controller
Process Temp1 and Temp2
S
Table 5.3 Relationships between the process components of the thin threads
Serial
Numb
er of
Comp
onent
Name of the process
Type of
Process
(Hhardware,
SSoftware)
0101
0102
Reset Button
Wait-1
H
0202
Key Board
H
0303
Temp1-Sensor
H
0404
Temp2-Sensor
H
0505
0606
Operational Amplifier-1
Operational Amplifier-2
H
H
0707
0808
A/D Converter
HOST
H
H
0909
Communication with
HOST
Micro Controller
Initialization Process
Validate process
Process Key
Temp-1 Task
Temp2-Task
Compare Temp1 with Ref1
Compare Temp2 with Ref2
Process Temp1 and Temp2
Process LCD
LCD
Validation process
Initialization Process
Communication with
HOST
HOST
Process Buzzer
Buzzer
Relay-1
Pump-1
Relay-2
Pump-2
S
1010
1111
1212
1313
1414
1515
1616
1717
1818
1919
2020
2112
2211
2309
2408
2525
2626
2727
2828
2929
3030
H
S
S
S
S
S
S
S
S
S
H
S
S
S
Thin
Thread-9
Push
Reset
Button
ST1
Thin
Thread-10 to
Thin
Thread-14
Press Key-1
to Key5
ThinThreda-15
Validate
Password
√
Thin
Thread-3
Thin
Thread-7
Read Temp1 and
process
pump
Compare
temp-1
and
Temp2
and
assert
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
H
S
H
H
H
H
H
√
√
√
√
Table 5.4 Flow Graph Matrix generated through thin threads
2011 - TECHNICALJOURNALS®, Peer Reviewed International Journals-IJCEA, IJESR, RJCSE, PAPER, ERL - PBPC, India;
Indexing in Process - Scopus, EMBASE, COMPENDEX, EmCARE, Electronics & Communication Abstracts, SCIRUS, SPARC, GOOGLE Database, EBSCO, NewJour, Worldcat,
DOAJ, and other major databases etc.,