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

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

"《嵌入式系统软件工程：方法、实用技术及应用【英文版】》深入探讨了软件工程在嵌入式和实时系统中的应用。第一章首先介绍了软件工程的基本概念，包括嵌入式系统的定义，强调它们是反应式的，特别是实时系统的重要性。实时系统被分为硬实时和软实时，前者对响应时间和恢复能力有严格要求，如基于信号处理的系统，其执行需在下一次样本到达前完成。硬实时系统的特点是事件具有时间敏感性，根据特定的时间特性进行操作。这类系统的设计挑战主要围绕如何保证在有限资源下实现高效执行，包括响应时间管理以及在面临故障时的快速恢复策略。本书还讨论了嵌入式系统的软件构建过程，特别关注分布式和多处理器架构的应用，例如超级循环（Superloop）架构和电源优化的超级循环，以及窗口生命周期嵌入式设计方法。硬件抽象层（HAL）对于嵌入式系统软件开发至关重要，它提供了一层接口，将底层硬件与上层软件隔离开来，简化了开发过程。作者通过实际案例展示了软件工程在嵌入式系统中的实用性，指出随着计算技术的发展，从大型桌面计算机到小型移动设备的转变，软件工程在这些微型化、便携设备上的应用变得更为关键。总结来说，本章详尽地涵盖了嵌入式系统软件工程的基础理论、设计原则、关键技术和实施策略，为读者提供了在嵌入式和实时系统领域进行软件开发的全面指导。无论是初学者还是经验丰富的工程师，都能从中找到有价值的知识和实践技巧。"

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

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

基于WoodandBerry1和非耦合控制WoodandBerry2来实现控制木材和浆果蒸馏柱控制Simulink仿真.rar

(源码)基于Spring Boot框架的用户管理系统.zip

基于springboot企业员工薪酬管理系统源码数据库文档.zip

Linux 操作系统3D显示性能测试工具 Glmark2

(源码)基于物联网的地震预警系统.zip

keil5.26开发编译环境

(源码)基于TensorFlow的中文文本分类系统.zip

基于springboot的智慧医疗采购系统源码数据库文档.zip

【重磅，更新！】上市公司绿色专利等绿色发展数据合集（1991-2022年）

基于SpringBoot+Vue的志愿者招募管理系统源码数据库文档.zip

最新资源