嵌入式系统软件工程：方法与关键技术应用

5星 · 超过95%的资源需积分: 29 118 浏览量更新于2024-07-19 11 收藏 32.66MB PDF 举报

身份认证购VIP最低享 7 折!

30元优惠券

资源详情

资源推荐

A computing system being hard real-time says nothing about the magnitudes of the

deadlines. They may be microseconds or weeks. There is a bit of confusion with regard to

the usage of the term “hard real-time”. Some relate hard real-time to response time

magnitudes below some arbitrary threshold, such as 1 msec. This is not the case. Many of

these systems actually happen to be soft real-time. These systems would be more accurately

termed “real fast” or perhaps “real predictable”; but certainly not hard real-time.

The feasibility and costs (e.g., in terms of system resources) of hard real-time computing

depend on how well known a priori are the relevant future behavioral characteristics of the

tasks and execution environment. These task characteristics include:

• timeliness parameters, such as arrival periods or upper bounds

• deadlines

• worst case execution times

• ready and suspension times

• resource utilization profiles

• precedence and exclusion constraints

• relative importance, etc.

There are also important characteristics relating to the system itself, some of which include:

• system loading

• resource interactions

• queuing disciplines

• arbitration mechanisms

• service latencies

• interrupt priorities and timing

• caching.

Deterministic collective task timeliness in hard (and soft) real-time computing requires that

the future characteristics of the relevant tasks and execution environment be deterministic 

i.e., known absolutely in advance. The knowledge of these characteristics must then be used

to pre-allocate resources so that hard deadlines, such as motor control, will be met and soft

deadlines such as responding to a key press can be delayed.

A real-time syst em task and execution environ ment must be adjusted to enabl e a schedule

and resource alloca tion whi ch meets all dea dlines . Different al gorithms or sch edule s

which meet all deadlines are evaluated with respect to other factors. In many real-time

computing applications get ting the jo b done at the lowes t cost is usua lly more import ant

than si mply maximizing the processor utilization (if this was true, we would all still be

writing assembly language). Time to market, for example, may be more important than

maximizing utilizatio n due to the cos t of squeez ing the last 5% of e fficien cy out of a

processor.

16 Chapter 1

Allocation for hard real-time computing has been performed using various techniques. Some

of these techniques involve conducting an off-line enumerative search for a static schedule

which will deterministically always meet all deadlines. Scheduling algorithms include the use

of priorities that are assigned to the various system tasks. These priorities can be assigned

either off-line by application programmers, or on-line by the application or operating system

software. The task priority assignments may either be static (fixed), as with rate monotonic

algorithms, or dynamic (changeable), as with the earliest-deadline-first algorithm.

Real-time event characteristics

Real-time event categories

Real-time events fall into one of the three categories: asynchronous, synchronous, or

isochronous.

• Asynchronous events are entirely unpredictable. An example of this is a cell phone call

arriving at a cellular base station. As far as the base station is concerned, the action of

making a phone call cannot be predicted.

• Synchronous events are predictable events and occur with precise regularity. For

example, the audio and video in a camcorder take place in synchronous fashion.

• Isochronous events occur with regularity within a given window of time. For example,

audio data in a networked multimedia application must appear within a window of time

when the corresponding video stream arrives. Isochronous is a sub-class of

asynchronous.

In many real-time systems, task and execution environment characteristics may be hard to

predict. This makes true hard real-time scheduling infeasible. In hard real-time computing,

deterministic satisfaction of the collective timeliness criterion is the driving requirement.

The necessary approach to meeting that requirement is static (i.e., a priori) scheduling of

deterministic task and execution environment characteristic cases. The requirement for

advance knowledge about each of the system tasks and their future execution environment

to enable off-line scheduling and resource allocation significantly restricts the applicability

of hard real-time computing.

Efficient execution and the execution environment

Efficiency overview

Real-time systems are time-critical and the efficiency of their implementation is more

important than in other systems. Efficiency can be categorized in terms of processor cycles,

memory, or power. This constraint may drive everything from the choice of processor to the

choice of the programming language. One of the main benefits of using a higher-level

Software Engineering of Embedded and Real-Time Systems 17

language is to allow the programmer to abstract away implementation details and

concentrate on solving the problem. This is not always true in the embedded-system world.

Some higher-level languages have instructions that can be an order of magnitude slower

than assembly language. However, higher-level languages can be used in real-time systems

effectively using the right techniques. We will be discussing much more about this topic in

the chapter on optimizing source code for DSPs.

Resource management

A system operates in real time as long as it completes the time-critical processes with

acceptable timeliness. “Acceptable timeliness” is defined as part of the behavioral or

“non-functional” requirements for the system. These requirements must be objectively

quantifiable and measureable (stating that the system must be “fast”, for example, is not

quantifiable). A system is said to be real-time if it contains some model of real-time

resource management (these resources must be explicitly managed for the purpose of

operating in real time). As mentioned earlier, resource management may be performed

statically off-line or dynamically on-line.

Real-time resource management comes at a cost. The degree to which a system is required

to operate in real time cannot necessarily be attained solely by hardware over-capacity

(e.g., high processor performance using a faster CPU).

There must exist some form of real-time resource management to be cost-effective. Systems

which must operate in real time consist of both real-time resource management and

hardware resource capacity. Systems which have interactions with physical devices may

require higher degrees of real-time resource management. One resource management

approach that is used is static and requires analysis of the system prior to it executing in its

environment. In a real-time system, physical time (as opposed to logical time) is necessary

for real-time resource management in order to relate events to the precise moments of

occurrence. Physical time is also important for action time constraints as well as measuring

costs incurred as processes progress to completion. Physical time can also be used for

logging history data.

All real-time systems make trade-offs of scheduling costs vs. performance in order to reach

an appropriate balance for attaining acceptable timeliness between the real-time portion of

the scheduling optimization rules and the off-line scheduling performance evaluation and

analysis.

Challenges in real-time system design

Designing real-time systems poses significant challenges to the designer. One of the

significant challenges comes from the fact that real-time systems must interact with the

18 Chapter 1

environment. The environment is complex and changing and these interactions can become

very complex. Many real-time systems don’t just interact with one, but many different

entities in the environment, with different characteristics and rates of interaction. A cell-

phone base station, for example, must be able to handle calls from literally thousands of

cell-phone subscribers at the same time. Each call may have different requirements for

processing and in different sequences of processing. All of this complexity must be

managed and coordinated.

Response time

Real-time systems must respond to external interactions in the environment within a

predetermined a mount of time. Real-time s ystems must produce the correct result and

produce it in a timely way. Th e respons e time is a s important a s produc ing co rrect r esults .

Real-time systems must be engineered to meet these response times. Hardwar e and

software must be desig ned to suppo rt respon se time requ ireme nts for the se systems.

Optimal p artitioning of the system requirements into hardware and software is also

important.

Real-time systems must be architected to meet system response time requirements. Using

combinations of hardware and software components, engineering makes architecture

decisions such as interconnectivity of the system processors, system link speeds, processor

speeds, memory size, I/O bandwidth, etc. Key questions to be answered include:

• Is the architecture suitable? To meet the system response time requirements, the system

can be architected using one powerful processor or several smaller processors. Can the

application be partitioned among the several smaller processors without imposing large

communication bottlenecks throughout the system? If the designer decides to use one

powerful processor, will the system meet its power requirements? Sometimes a simpler

architecture may be the better approach  more complexity can lead to unnecessary

bottlenecks which cause response time issues.

• Are the processing elements powerful enough? A processing element with high

utilization (greater than 90%) will lead to unpredictable run-time behavior. At this

utilization level lower-priority tasks in the system may get starved. As a general rule,

real-time systems that are loaded at 90% take approximately twice as long to develop

due to the cycles of optimization and integration issues with the system at these

utilization rates. At 95% utilization, systems can take three times longer to develop due

to these same issues. Using multiple processors will help but the inter-processor

communication must be managed.

• Are the communication speeds adequate? Communication and I/O is a common

bottleneck in real-time embedded systems. Many response time problems come not

from the processor being overloaded but in latencies in getting data into and out of the

Software Engineering of Embedded and Real-Time Systems 19

system. In other cases, overloading a communication port (greater than 75%) can cause

unnecessary queuing in different system nodes and this causes delays in message-

passing throughout the rest of the system.

• Is the right scheduling system available? In real-time systems tasks that are processing

real-time events must take higher priority. But how do you schedule multiple tasks that

are all processing real-time events? There are several scheduling approaches available

and the engineer must design the scheduling algorithm to accommodate the system

priorities in order to meet all real-time deadlines. Because external events may occur at

any time, the scheduling system must be able to preempt currently running tasks to

allow higher-priority tasks to run. The scheduling system (or real-time operating

system) must not introduce a significant amount of overhead into the real-time system.

Recovering from failures

Real-time systems interact with the environment, whic h is inhere ntly unre liable .

Therefore real-time systems must be able to detect and o vercome failures in the

environment. Also, since re al-time systems are also embedded into other systems and ma y

be hard to get at ( such as a space c raft or satelli te) these s ystems must also be able to

detect and overcome internal failures as wel l (there is no “reset” button in easy reach of

the user!). Also since events in the environment areunpredictable,itisalmostimpossible

to test for every possible combination and sequence of events in the environment. This is

a characteristic of real-time software that makes it somewhat non-deterministic in the

sense that it is almost imposs ible in some r eal-ti me systems t o predict the mu ltiple pat hs

of execution bas ed on the non-d etermini stic be ha vior of the en viron ment. Examples of

internal and exte rnal failu res tha t must be detected and managed by real-time systems

include:

• processor failures

• board failures

• link failures

• invalid behavior of external environment

• inter connectivity failure.

Many real-time systems are embedded systems with multiple inputs and outputs and

multiple events occurring independently. Separating these tasks simplifies programming,

but requires switching back and forth among the multiple tasks. This is referred to as multi-

tasking. Concurrency in embedded systems is the appearance of multiple tasks executing

simultaneously. For example, the three tasks listed in

Figure 1.13 will execute on a single

embedded processor and the scheduling algorithm is responsible for defining the priority of

execution of these three tasks.

20 Chapter 1

剩余1163页未读，继续阅读

Sliwell

粉丝: 1
资源: 1

嵌入式系统软件工程：方法与关键技术应用

嵌入式系统软件工程基础知识、方法和应用下

嵌入式系统软件设计.pdf

嵌入式系统工程师

嵌入式软件工程师中级考试教程pdf

嵌入式系统设计与应用 王剑 pdf

嵌入式系统原理及应用马维华pdf

嵌入式系统软硬件协同设计实战指南:基于xilinx zynq(第2版)陆佳

嵌入式系统固件揭密 pdf 中文版

嵌入式系统原理与设计pdf 陈文智

arm cortex-m3嵌入式系统原理及应用 电子书

嵌入式硬件系统jack ganssle中文版

嵌入式linux系统开发第二版

嵌入式linux应用程序开发详解pdf

专业嵌入式软件开发李云pdf

微处理器系统结构与嵌入式系统设计pdf

嵌入式系统软硬件协同设计实战指南 pdf

xilinx zynq-7000嵌入式系统设计与实现pdf

嵌入式linux基础教程 第2版

嵌入式linux应用开发完全手册(韦东山) pdf

嵌入式linux系统开发完全手册 v4.0

最新资源

嵌入式系统设计与应用王剑 pdf

arm cortex-m3嵌入式系统原理及应用电子书

嵌入式linux基础教程第2版