嵌入式系统设计的验证与调试技术资源-CSDN文库

嵌入式系统设计的验证与调试技术

3星 · 超过75%的资源需积分: 10 62 浏览量 2011-03-28 22:25:12 上传评论收藏 2.22MB PDF 举报

资源推荐

资源详情

资源评论

“RoyChoudhury: 09-Ch05-P374230” — 2009/4/17 — 14:36 — page 181 — #1

CHAPTER

Functionality Validation

So far, we have discussed various aspects of validation, namely, (a) system modeling

from informal requirements and validating the model, (b) validating the communi-

cation across system components, and (c) validating timing properties of embedded

software. In this chapter, we discuss the functionality validation of embedded soft-

ware. Some of the techniques we discuss here are generic to software validation

and can be integrated with any software development life cycle. However, some

of the methods are speciﬁcally useful for classes of software. For example, the

software model checking method is particularly useful for control-intensive (and

less data operation–dominated) programs that are common in controllers or device

drivers.

In discussing software validation methods, we need to clarify what we precisely

mean by “validation” here. Aloose deﬁnition of validation will be checking whether

the software behaves as expected. However, such a deﬁnition also implies that the

“expectation” from the software is properly documented. So, the ﬁrst question we

face is how to document or describe the “expected” behavior of embedded soft-

ware. There are several ways to answer this question, and indeed the answer to the

question depends on what kind of validation methods we are resorting to. If our

validation method is software testing, the description of expected behavior consists

of the expected program output for selected test cases. If our validation method is

software model checking, the description of expected program behavior will consist

of the temporal properties being veriﬁed.

Having clariﬁed the issue of expected behavior, we ought to differentiate soft-

ware validation from model validation.After all, our discussion on model validation

(Chapter 2) covered how to check properties of the models via model checking. In

principle, one could validate the model and generate the implementation software

from the models, automatically or semiautomatically. However, in practice, this is

Embedded Systems and Software Validation

181

“RoyChoudhury: 09-Ch05-P374230” — 2009/4/17 — 14:36 — page 182 — #2

182 CHAPTER 5 Functionality Validation

rarely done. The modeling mostly serves the purpose of design documentation and

comprehension. The modeling activity gives the system designer a methodical way

of eliciting the requirements and putting them together in the form of an initial

design. Validating the model clariﬁes the designer’s understanding of what the sys-

tem ought to be. On the other hand, software validation is a much more downstream

activity where the actual implementation to be deployed is validated.

Depending on whether the software being validated is constructed from a design

model (or not), the ﬂow of software validation can be different. Figure 5.1 shows

the overall software validation ﬂow in the case where the software is written with a

design model as a guide. Here we could ﬁrst employ static checking on the design

model to ensure that it satisﬁes certain important properties. Subsequently, we write

code using the design model as a guidepost (certain parts of the code could even be

automatically generated). This code can be subjected to dynamic checking such as

testing/debugging for speciﬁc program inputs.

Figure 5.2 shows the overall software validation ﬂow, where the software is

written directly by the programmer. In this case, the software is hand-written and

not generated automatically or semiautomatically from a design model. This is often

the situation in industrial practice where the design model, even if one exists, is

primarily used for the purposes of documentation. We note that in this case, the code

is potentially subjected to three kinds of validation:

■

Dynamic checking,

■ Static checking, and

■ Static analysis.

Dynamic checking corresponds to software debugging via software testing —

we run test cases, check whether the observed behavior is the same as the expected

behavior, and if not, analyze the execution trace(s) for possible reasons. Static check-

ing corresponds to checking predeﬁned properties againsta given program — a prime

example of static checking methods being model checking (Section 2.8). Recall

that model checking veriﬁes a temporal property (a property about the sequence of

events in system execution) against a ﬁnite-state model of the implementation. In

this case, because we wrote the software without any model, the model needs to

be extracted from the software, as shown in Figure 5.2. The ﬁnal kind of validation

illustrated in Figure 5.2 is static analysis. Unlike static checking, here we do not have

a property to verify — instead we attempt to infer program properties by analyzing

it. Typically, we may use static analysis to infer invariants about speciﬁc program

locations; for example, whenever control ﬂow reaches line 70, the variable v must

be 0. These properties can then be exploited in static checking methods such as model

checking. In other words, the role of the static analysis methods here is primarily to

help methods such as model checking.

“RoyChoudhury: 09-Ch05-P374230” — 2009/4/17 — 14:36 — page 184 — #4

184 CHAPTER 5 Functionality Validation

5.1 DYNAMIC OR TRACE-BASED CHECKING

Dynamic checking of software corresponds to checking its behavior for speciﬁc

test cases. Dynamic checking goes by many other (similar-sounding) names such

as run-time monitoring, dynamic analysis, or software debugging. The basic idea in

these methods is to run the program against speciﬁc tests and compare the observed

program behavior against expected program behavior. The tests may have been

generated during model validation (Section 2.7), or they could be generated from

the program itself through some coverage criterion (such as covering all statements

in the program).

If the observed program behavior is different from the expected behavior, the

corresponding test case is considered as failed, and the execution trace for the test

case is examined automatically/manually to ﬁnd the cause of failure. It is important

to note here that the “observed” and “expected” behavior may not necessarily be

given by output variable values. For example, the observed behavior of a program

for a given test case may be that the program crashes, and the expected behavior

may be the absence of a crash.

Economic importance

Let us illustrate the economic issues that drive interest in software testing and debug-

ging. A report on the “Economic Impacts of Inadequate Infrastructure for Software

Testing” published in 2002 by the Research Triangle Institute and the National Insti-

tute of Standards and Technology (USA) estimates that the annual cost incurred as

a result of an inadequate software testing infrastructure all over the United States

amounts to $59.5 billion — 0.6% of the $10 trillion U.S. GDP.

Industrial studies on quality control of software have indicated high defect den-

sities. Ebnau in an ACM Crosstalk article

reports case studies where on an average

13 major errors per 1000 lines of code were reported. These errors are observed via

slow code inspection (at 195 lines per hour) by humans. So, in reality, we can expect

many more major errors. Nevertheless, conservatively let us ﬁx the defect density at

13 major errors per 1000 lines of code. Now consider a software project with 5 mil-

lion lines of code (the Windows Vista operating system is 50 million lines of code, so

5 million lines of code is by no means an astronomical ﬁgure). Even assuming a linear

scaling up of defect counts, this amounts to at least (13 ⫻ 5000,000/1000) ⫽ 65,000

major errors. Even if we assume that the average time saved to ﬁx one error using

See http://www.stsc.hill.af.mil/crosstalk/1994/06/xt94d06e.asp.

“RoyChoudhury: 09-Ch05-P374230” — 2009/4/17 — 14:36 — page 185 — #5

5.1 Dynamic or Trace-Based Checking 185

an automated debugging tool as opposed to manual debugging is 1 hour (this is

a very modest estimate; often, ﬁxing a bug takes a day or two), the time saved is

65,000 man-hours ⫽ 65,000/44 ⫽ 1477 work weeks ⫽ 1477/50 ⫽ 30 man-years.

Clearly, this is a huge amount of time that a company can save, leading to more

productive usage of its manpower and saving of precious dollar value. Assuming an

employee salary of $ 40,000 per year, the foregoing translates to $ 1.2 million savings

in employee salary simply by using better debugging tools. A much bigger savings,

moreover, comes from customer satisfaction. By using automated debugging tools, a

software development team can ﬁnd more bugs than via manual debugging, leading

to increased customer conﬁdence and enhanced reputation of the company’s prod-

ucts. Finally, manual approaches are error-prone, and the chances of leaving bugs

can have catastrophic effects in safety-critical systems.

Related Terminology

To clarify the terminology related to dynamic checking methods, let us start with

the “folklore” deﬁnition of software bug in Wikipedia:

A software bug (or just “bug”) is an error, ﬂaw, mistake, “undocumented feature,”

failure, or fault in a computer program that prevents it from behaving as intended

(e.g., producing an incorrect result). Most bugs arise from mistakes and errors made

by people in either a program’s source code or its design, and a few are caused by

compilers producing incorrect code. A program that contains a large number of bugs,

and/or bugs that seriously interfere with its functionality, is said to be buggy. Reports

detailing bugs in a program are commonly known as bug reports, fault reports, problem

reports, trouble reports, change requests, and so forth.

The conventional notion of a software bug is an error in the program that gets

introduced during the software construction. It is worthwhile to note that the mani-

festation of a bug may be very different from the bug itself. Thus, the main task in

software debugging is to trace back to the software bug from the manifestation of it.

A good bug report will be able to take in a manifestation of a bug and locate the bug.

In case this sounds unclear, let us consider the following program fragment marked

with line numbers, written in Java style:

1. void setRunningVersion(boolean runningVersion)

2. if( runningVersion ) {

3. savedValue = value;

}

else{

4. savedValue = "";

}

剩余51页未读，继续阅读

评论收藏

内容反馈

xiayu98020214

2013-04-24

只有一章内容，太少了呵呵
shenxinshan621107

2013-01-22

不是全书，只有一章内容，可惜！
涨停板89

2013-09-26

东西少了。失望
joexulei

2014-05-05

不是原书，是另一本不知道什么书的其中一个关于functional verification的章节
he19862028di

2014-08-07

假的受不了哎

前往

页

yfw418

粉丝: 20
资源: 1

嵌入式系统设计的验证与调试技术

嵌入式系统的调试

嵌入式系统程序完整性验证技术研究与实现.pdf

嵌入式系统调试技术的分析与设计

嵌入式系统开发圣经

通用嵌入式系统测试平台集成开发环境.pptx

[嵌入式软件].拉伯罗斯.扫描版

嵌入式微处理器片上调试系统的设计和验证.pdf

通用嵌入式系统测试平台.pptx

针对嵌入式系统进行测试.docx

通用嵌入式系统自动化测试平台.docx

论文研究-嵌入式微处理器的系统验证平台设计.pdf

嵌入式系统/ARM技术中的嵌入式系统flash接口电路的实现

通用嵌入式系统测试平台（Embedded System Interface Test Studio

常用嵌入式系统软件仿真自动化黑盒测试平台.docx

Embedded Systems and Software Validation

基于ARM7的嵌入式系统虚拟实验平台的设计

基于AVR嵌入式系统的采煤机智能遥控器设计

操作系统学习与考试系统(XOSCATS)

SquareLine-Studio 1.3.0安装包

王道操作系统课件 2024

C语言规范标准-C99(中文版)

ELF解析工具 v1.7（elf格式解析工具)

计算机组成原理：最详细笔记 word格式下载

KeepOutlookRunning.7z

dell r730xd 调速工具

Sim-EKB-Install-2022-11-27.zip

贵州电信天邑TY1613-s905l3-b-rtl8822cs当贝固件刷机教程

22-003-T-九联UNT403A-UNT413A-M401A-M411A-S905L3A处理器线刷固件-当贝桌面纯净版

最新资源