129
fakultät für informatik informatik 12 technische universität dortmund 大大大大大大大 —— 大大大大大大大

大学计算机基础 —— 计算机科学概论

  • Upload
    kemp

  • View
    204

  • Download
    4

Embed Size (px)

DESCRIPTION

大学计算机基础 —— 计算机科学概论. 设计的挑战. 嵌入式与网络计算实验室. 本讲义多有引用他人工作, 在此一并致谢!. 一、嵌入式系统的一些基本特征.  cyber-physical systems. 1 、一类嵌入式系统硬件是一个闭环系统. 硬件体系结构 CPUs ,协同设计,多处理器,网络 软件体系结构 处理,调度,分配. 体系结构. 建模分析和仿真 性能,功率,成本 协同验证. 应用. 特点 规范 参考设计. 方法学. 2 、嵌入式系统中计算的基本问题. 问题 1 —— 体系结构 (architectures). 硬件体系结构 - PowerPoint PPT Presentation

Citation preview

Page 1: 大学计算机基础 —— 计算机科学概论

fakultaumlt fuumlr informatikinformatik 12

technische universitaumlt dortmund

大学计算机基础mdashmdash计算机科学概论

设计的挑战嵌入式与网络计算实验室

本讲义多有引用他人工作在此一并致谢

一嵌入式系统的一些基本特征

1 一类嵌入式系统硬件是一个闭环系统

cyber-physical systems

2 嵌入式系统中计算的基本问题

体系结构

方法学

应用特点规范参考设计

建模分析和仿真性 能 功 率 成本

协同验证

硬件体系结构CPUs 协同设计 多 处 理 器 网络

软件体系结构处 理 调 度 分配

问题 1mdashmdash体系结构(architectures)

硬件体系结构 CPUs协同设计多处理器网络软件体系结构 处理调度分配中间件人机交互 硬件软件及其二者之间的关系

问题 2mdashmdash方法学(methodologies)

建模分析形式化仿真性能功率能耗成本价格协同验证方法学中的步骤靠工具来执行

问题 3mdashmdash应用(applications)

特点规范参考设计 理解你的应用是获得嵌入式计算系统最大性能的关键我们可以根据应用的特点去优化设计这个优势可以使我们执行许多有效的优化而这在通用系统中是不可能的但是这也意味着我们必须对应用的特点有足够的认识这样才能在利用特点的同时避免在系统实现过程中产生问题

面向应用的计算( SmartApps An Application Centric Approach to High Performance Computing )

Today System Centric Computing

Application(Algorithm)

Compiler(static)

System(OS amp Arch)

HWOS

CompilerApplication

System-Centric Computing

Development entAnalysis amp

Optimization

Execution

Input Data

Classic Avenues toperformance

Parallel Algorithms Static Compiler Optimization OS support Good Architecture

Whatrsquos missing Compiler are conservative OS offers generic services Architecture is generic

No Global Optimization No matching between ApplicationOSHW Intractable for the general case

SmartApps Application Centric Computing

Application ControlInstance-specific optimization

Compiler + OS + Architecture + Data + Feedback

Application(Algorithm)

Development entAnalysis amp

Optimization

Compiler (static) +run-time techniques

Compiler(run-time)

OS(modular)

Architecture(reconfigurable)

SmartAppApplication

CompilerOS

HW

Run-time SystemExecution Analysis

amp Optimization

Application-Centric Computing

Input Data

Smart Application

SmartApps Architecture

Get Runtime Information(sample input system information etc)

Static CompilerAugmented withruntime techniques

Predictor ampOptimizer

partially compiledcode with unknownsand runtime hooks

Information forrapid simulation

Compute Optimal Applicationand System Configuration

Recompile Applicationandor Reconfigure System

Predictor ampEvaluator

Configurer

Application

Execute Application

Continuous monitorperformance and adaptas necessary

Predictor ampEvaluator

Predictor ampOptimizer

Adaptive Software

Runtime tuning (worecompile or reconfigure)

Small adaptation (tuning)

Large adaptation(failure phase change)

3 Real-time 约束许多 ES 必须满足实时约束什么是实时系统 实时系统是将时间定量化的一个概念实时系统是使用物理时钟来衡

量的当我们使用物理时钟来量化时间时我们就会讨论到实时的概念

与实时相反逻辑时间(也称为虚拟时间)是对时间的一种定性的概念通过使用事件顺序关系来表示例如之前之后某个时候最后在hellip之前接着等等

定义一个系统称为实时系统当我们需要用定量的时间表达式(也就是说实时)来描述这个系统的行为在这个实时系统的定义中隐含的表达了所有的定量的时间度量都是用一个物理时钟测量得到的

任何一个行为可以完全不用任何定量时间表达来描述其行为的系统肯定不是实时系统但一个系统的完整行为可以用它对各种外部刺激的响应列表来描述也就是说一个系统的行为大部分描述根本没有定量的时间表达式仍然被认为是一个实时系统

实时系统的类型根据任务超过截止时间的后果实时系统可以分为 硬实时软实时固实时1 )硬实时当系统执行任务时被强制要求在某个时间范围内要

产生结果换句话说任何时刻硬实时任务没有在制定的时间范围内产生要求的结果那这个系统就被认为失败了

2 )固实时当系统执行任务时与某些预设的截止时间相关联任务要求要在截止时间之前完成结果的计算不同于硬实时任务就算一个固实时任务没有在截止时间之前完成系统也不会失败迟来的结果仅仅是被丢弃了

3 )软实时当系统执行任务时也有与之相关联的时间界限但是不像硬实时和固实时任务软实时任务的时间界限并不是以绝对数值来表示的取而代之的是平均响应时间

Real-Time 系统与嵌入式系统

Embedded and Real-

Time 往往同义 Most embedded

systems are real-time

Most real-time systems are embedded

embeddedembedded

real-timereal-time

embedded embedded real-timereal-time

4 反应系统ES 是一个反应系统 转换系统输入(开始) -gt 软件系统(经过一段时间后停止运行) -gt (然后)输

出即用户把数据输入给计算机软件对这些数据经过一段时间的计算最后给出输出结果

输入数据经过特定的规则被转换并且在结束计算过程以后给出结果 而 reactive system 却与此相反在 reactive system 里往往没有明确的时序安排总体来讲

reactive system 表示的是不限制运行时间的系统这其中要和外部环境相互作用也就是在外部刺激上的反应 (reactive) 例如和不同使用者或者外部的硬件等但是也包括内部发生的交流行为因为 reactive system 是被集成在并行运行的分布式系统的规则中的例如一个计算机的操作系统是这样一个 reactive system 它不会停止运行 而总是反应用户给的输入 并且计算机中的各个组件之间要进行交流

在电信领域生产控制或者在硬件环境的构造(嵌入式系统)中还存在很多这样的例子在信息系统中也就是基于数据库的应用系统中也要用到 reactive system 在给一个典型的例子就是警报系统

5 混成系统Hybrid systems(analog + digital parts)混成系统一般由离散分立组件和连续组件并行或者串

行组成组件之间的行为由计算模型进行控制由于大多数复杂控制系统都包含了由连续变量所描述的物理层的动态演化过程和以符号操作与离散监控决策为特征的高层协调优化过程因此混成系统在工业控制和国防等领域大量存在混成系统定义凡是系统自身具有混合结构并且其

行为(输出和状态)取决于离散事件系统和连续动态系统相互作用的动态系统就称为混成系统

混成系统的典型特征( 1) 系统内存在着性质不同的连续和离散两类变量( 2) 时间和事件共同驱动系统的状态演化 ( 3)连续变量穿越阈值使状态使能或失能 ( 4)离散状态的变化改变连续变量遵循的变化速率 ( 5)离散事件发生在离散时刻 具有顺序选择并发等特色

( 6)状态呈阶段性间歇性切换变化 动态特征显著 ( 7) 对系统的控制表现为对连续状态和离散状态的集成控制 ( 8) 对系统的优化表现为在定性 定量双重指标下的集成优化

6 专用系统 Dedicated towards a certain

applicationKnowledge about behavior at design time can be used to minimize resources and to maximize robustness

Dedicated user interface(no mouse keyboard and screen)

二设计的挑战 实时可信可靠保密安全

1 为什么需要可靠的嵌入式系统1 )许多市场不需要高度可靠的嵌入式计算机但是许多嵌入式计算机必须

是高度可靠的2 )许多嵌入式计算机必须是高度可靠的汽车电子航空电子医疗设备

关键通信3 )可靠性的定义如电话交换机系统每年停机少于 30秒4 )关于可靠数字系统设计的研究几十年前就有不同的体系结构和方法学

被开发用于长周期低失误率的数字系统操作那么传统的可靠计算机和可靠的计算机系统有什么不同呢

5 )可靠嵌入式计算机通常是分布式系统如汽车电子航空电子和医疗设备都是必须高度可靠的分布式嵌入式系统

6 )嵌入式计算机容易受许多新类型攻击可靠计算机传统上是物理上不可访问的服务器或者机器mdashmdash物理安全长期以来是计算机安全的安全策略但是嵌入式计算机通常在非保护环境下操作这就允许新的故障和攻击这些需要都新的保护措施

2 可靠与可信ES 必需是可靠的可信的如何评价与度量

bull可靠性( Reliability) R(t)

bull可维护性( Maintainability) M(d)

bull有效性( Availability ) A(t)

bull安全性( Safety )bull保密性( Security )

可靠性定义可靠性 R(t) 产品在规定条件下和规定时间内完成规定

功能的能力产品可靠性定义的要素是三个ldquo规定rdquo 1 )ldquo规定条件rdquo包括使用时的环境条件

和工作条件2 )ldquo规定时间rdquo是指产品规定了的任务

时间3 )ldquo规定功能rdquo是指产品规定了的必须

具备的功能及其技术指标

1 )ldquo规定条件rdquo包括使用时的环境条件和工作条件 例如同一型号的汽车在高速公路和在崎岖的山路上行驶其可

靠性的表现就不大一样要谈论产品的可靠性必须指明规定的条件是什么2 )ldquo规定时间rdquo是指产品规定了的任务时间 随着产品任务时间的增加产品出现故障的概率将增加

而产品的可靠性将是下降的因此谈论产品的可靠性离不开规定的任务时间例如一辆汽车在在刚刚开出厂子和用了5 年后相比它出故障的概率显然大了很多

3 )ldquo规定功能rdquo是指产品规定了的必须具备的功能及其技术指标所要求产品功能的多少和其技术指标的高低直接影响到产品可靠性指标的高低

例如电风扇的主要功能有转叶摇头定时那么规定的功能是三者都要还是仅需要转叶能转能够吹风所得出的可靠性指标是大不一样的

可维护性 M(d)1 )计算机系统的可维护性是指该系统失效后在规定时间内可

修复到规定功能的能力2 )反映系统可维护性高低的参数是修复率秒平均修复时间3 )软件可维护性即维护人员对该软件进行维护的难易程度

具体包括理解改正改动和改进该软件的难易程度4 )决定可维护性的因素

系统的大小系统的年龄结构合理性

5 )可维护性的度量 可理解性可测试性可修改性可移植性

有效性 A(t)设备的有效性的表式为 设备有效性 = 平均故障间隔期 (平均故障间隔期+平均修理时间)

在逻辑中如果一个论证不能从真前提中得出假结论 则论证的形式是完全有效的

一个论证若被称为是有效的则如果在其中所有前提都为真的每个模型中结论也是真的

例如ldquo所有 A 是 B 有些 A 是 C 所以有些 B 是Crdquo 是有效形式

可用性 实用性

3 可靠系统设计的基本原理1 )故障 (faults) 分析2 )可靠性分析3 )纠错技术4 )软件可靠性

1 )故障 (faults) 分析永久 (permanent) 与暂时( transient )故障故障来源 物理故障 (Physical faults)由生产缺陷辐射危害等等引起

设计故障 (Design faults) 是不合适设计的系统的结果

操作故障 (Operational faults) 来自人为过失安全破坏劣质设计的人机接口等等

可靠性设计

故障及其分类 产品的故障按其故障规律分为两大类

偶然故障 渐变故障

产品的故障按其故障后果分为两大类 致命性故障 非致命性故障

产品的故障按其统计特性分为两大类 独立故障 从属故障

可靠度 产品在规定的条件下和规定的时间内完成规

定功能的概率称为可靠度依定义可知系统的可靠度是时间的函数表示为

式中 R(t)mdashmdash 可靠度函数 ξmdashmdash 产生故障前的工作时间 t mdashmdash 规定的时间

)()( tPtR

2 )可靠性的分析mdashmdash可靠度

可靠度函数

依定义可知可靠度函数 R(t) 为

式中 N0 mdashmdash t = 0 时在规定条件下进行工作的产品数

r(t) mdashmdash  在 0 到 t 时刻的工作时间内产品的累计

故障数

0

0 )()(

N

trNtR

累积故障分布函数 产品在规定的条件下和规定的时间内丧失

规定功能的概率称为累积故障概率(又叫不可靠度) 依定义可知产品的累积故障概率是时间的函

数即

显然以下关系成立

0

)()(

N

trtF

1)()( tFtR

可靠度函数与累积故障分布函数的性质

图 R(t)F(t)与f(t)的关系t

f(t)

f(t)

F(to)

R(to)

to

由密度函数的性质 1)(0

dttf 可知

t

tdttfdttftFtR )()(1)(1)(

0

因此 R(t) F(t) 与 f(t) 之间的关系如图所示

故障率函数 故障率

工作到某时刻尚未发生故障的产品在该时刻后单位时间内发生故障的概率称之为产品的故障率

用数学符号表示为

式中 (t) mdashmdash 故障率 dr(t) mdashmdash t 时刻后 dt 时间内故障的产品数 Ns(t) mdashmdash 残存产品数即到 t 时刻尚未故障的产品

dttN

tdrt

s )(

)()(

35

故障率函数

可按下式进行工程计算

式中 Δr(t) mdashmdash t 时刻后 Δt 时间内故障的产品数

Δt mdashmdash 所取时间间隔 Ns(t) mdashmdash 残存产品数

对于低故障率的元部件常以 10-9h 为故障率的单位称之为菲特( Fit )

ttN

trt

s

)(

)()(

产品故障浴盆曲线 浴盆曲线

大多数产品的故障率随时间的变化曲线形似浴盆称之为浴盆曲线由于产品故障机理的不同产品的故障率随时间的变化大致可以分为三个阶段

产品典型的故障率曲线

t

使用寿命

早期故障

偶然故障 耗损故障

A B规定的故障率 维修后故障率下降

(t)

3 )纠错技术( 1 )纠错码 在 1950s就开始研究最早的是可以检测和纠错的汉明码它们通过数字系统广泛地用于识别和纠正短暂或者持久的错误这些码引入冗余信息来确保一些类型的错误可以被检测和纠正比如一个单错校正 双错校正的码能用一个比特检测和纠正一个错误但是不能用两个比特纠错

( 2 )三模冗余 (triple modular

redundancy) 计算单元 C 有三个副本 C1C2和 C3三个单元接收同

样的输入一个独立单元比较每个输入的结果如果至少两个结果一致那么那个值被表决器选做正确结果如果三个结果都不相同那么就没有正确的结果

1C

2C

3C

表决错误

结果

输入

( 3 )看门狗定时器 (watchdog timer)

看门狗定时器 (watchdog timer)被广泛地用于检测系统问题如图 看门狗定时器连接到一个监视系统如果这个看门狗定时器翻转它产生一个完成信号用于标注系统的错误中断系统应该这样设计当适当运行的时候它一直在可能产生翻转信号之前复位定时器因此来自看门狗定时器的完成信号指示系统在一定程度上不合适地操作看门狗定时器用于预防不同的故障

系统看门狗定时器

完成

复位

( 4 )设计多样性 (Design diversity)

一种用于减少一些系统错误进入设计的设计方法学当一个设计需要给定模块的不同实例应该采用模块的不同实现而不是到处都用同一种模块比如一个有多个 CPU的系统可能采用不同类型的 CPU而不是到处采用同一种类型的 CPU在一个三模冗余系统产生表决结构的组件可能有不同的实现这样可以减少产生同样设计错误的机会

4 )软件可靠性ldquo在规定的条件下在规定的时间内软件不引起失效的概率rdquo

规定的条件 软件运行的软硬件环境 软件操作剖面软件运行的输入空间及其概率分布

规定的时间 日历时间 时钟时间 执行时间

激活软件 输入域 缺陷的数据

软件缺陷 软件

不可接受的结果 (软件故障) 输出域

软件故障的特点

软件与硬件可靠性的区别硬件 软件

故障机理 老化损耗 残留缺陷在一定环境下造成的软件错误

复杂性 内部逻辑较为简单 内部逻辑高度复杂这就在很大程度上决定了设计错误是导致软件故障的主要原因

唯一性 任何两个硬件不可能绝对相同

软件是唯一的软件拷贝不改变软件本身

可靠性的核心 内部元部件 设计者的思维和软件的复杂性纠错维护方法 修复或更换失效的元部件 重设计 可靠性检验标准化

已标准化且有一整套完整的理论

仍未建立更没有完整的理论体系

产品市场 已有成熟的产品市场 产品市场还很新 错误性质 一些瞬间的硬件错误可能

会被误认为是软件错误 软件错误是永恒的可重现的

影响软件可靠性的因素( 1 )运行环境 ( 剖面 )

同一软件在不同运行剖面下其可靠性行为可能极不相同 软件故障是软件缺陷在一定输入情况下被激活的结果 假设软件输入域划分为两个部分 G 和 F 运行剖面不包含 F 中

的输入则软件不会出现故障其可靠性恒为 l 反之如果运行剖面不包含 G 中的输入则每一输入情况下均出现故障如果没有容错措施则 R=0

( 2 )软件规模 随着软件规模的增大软件可靠性问题愈显突出在我们考虑软件

可靠性问题时软件一般是指中型以上软件 (4000-5000条以上语句 ) 这时可靠性问题难以对付

软件工程实践的一个侧面可以反映这一点即单元测试一般由编程人员本人进行而综合测试则需独立的测试人员

影响软件可靠性的因素( 3 )软件内部结构

结构越复杂软件复杂度越高内含缺陷数越大因而软件可靠度越低

( 4 )软件可靠性设计技术 一般是指软件设计阶段中采用的用以保证和提高软件可靠性为主要目标的软件技术

( 5 )软件可靠性测试 研究表明软件测试方法与资源投入对软件可靠性有不可忽视的影

响( 6 )软件可靠性管理

软件可靠性管理旨在系统管理软件生存期各阶段的可靠性活动使之系统化规范化一体化这样就可以避免许多人为错误以提高软件可靠性

影响软件可靠性的因素( 7 )软件开发人员能力和经验

软件开发人员 ( 包括测试人员 ) 的能力愈强经验愈丰富所犯错误便可能愈少所得软件产品质量愈高相应的可靠性也愈高

( 8 )软件开发方法 软件工程表明开发方法对软件可靠性有显著影响 与非结构化方法比较结构化方法可以明显减少软件缺陷数

( 9 )软件开发环境 研究表明程序语言软件开发环境影响软件的可靠性而软件测

试工具的优劣则影响可靠性测试结果

4 安全 (Safety)amp保密 (Security)

安全 (Safety) 是保证财产和人身受到损害可靠性是指在一定的环境条件下以及一定的时间内系统完成特定任务的可能性而有效性则是系统的长期的工作时间于其存在时间 ( 简单的定义为运行时间 +维护时间 ) 的 比例保密 (Security) 是针对危险破坏损失或非法活动而进行措施在一定层面上保密 (Security)要比安全 (Safety)宽广的多例如信息 Security家庭 Security 网络 Security 国家Security) 等

Security强调的是外在事物对特定目标的危害

Safety 是系统本身的潜在危害

四个概念的比较分析安全 (Safety)可靠性 (Reliability)有效性 (Availability)保密 (Security )安全 (Safety)高的系统 软件可靠性不

一定高可靠性和有效性并不是一码事保密 (Security )的系统 软件是安全

(Safety) 系统 软件的重要保障

可靠性安全性保密性 可靠(或可信)系统设计 (Reliable (or dependable) system design)是制造嵌入式系统所关注的甚至在面对内部或者外部问题时可靠系统设计经常假设问题是非恶意引起的

安全重要的系统设计 (Safety-critical system design)研究确保系统安全操作的方法独立于引起问题的原因

保密性 (Security)主要关注恶意攻击

Aizientis等人描述了可信性和保密性间的关系可信性和保密性由几个特性所组成

服务的可用性 (Availability) 服务的连续性 (Continuity) 来自用户和所处环境的灾难性后果的安全性 (Safety) 来自不合适系统改变的完整性 (Integrity) 通过更改和修补的可维护性 (Maintainability) 信息的机密性 (Confidentiality)

可用性完整性

可靠性安全性可维护性

机密性

可信性 保密性

5 新型攻击和对策1 )物理攻击嵌入式系统比通用计算机更容易受攻击 一个关键原因是许多嵌入式计算机对攻击者可物理访问

2 )互联网攻击一些嵌入式系统的攻击通过互联网访问变得更加容易今天许多嵌入式系统连接到互联网

3 )电池攻击 (battery attack)这种攻击试图通过耗尽电池来关闭节点

4 )服务拒绝攻击 (Denial-of-service attacks)

在通用系统中众所周知但是实时嵌入式系统可能更容易受服务质量 (quality-of-service (QoS))攻击如果网络发布实时数据那么发送过程中的一点延迟都能引起数据无效如果那些数据用来实时控制那么这些短暂延迟就能引起系统故障我们称这种危害为时间攻击因为它改变了系统的实时特性

QoS或者时间攻击之所以强大使因为它的影响不仅仅限于信息被控制系统的动态特性可决定系统的响应如果一个大型沉重快速运动的系统被控制那么时间上一个相对小的改变能引起大量的破坏

5 )网络(协议)攻击Wood和 Stankovic[Woo02]在传感器网络上确定了一些方式这些方式可在网络层次的不同层执行拒绝服务攻击如下所列

物理层 (Physical layer)mdashmdash拥塞破坏 链路层 (Link layer)mdashmdash碰撞耗尽非公平

网络和路由层 (Network and routing layer)mdashmdash丢弃和贪婪汇集方向误导黑洞认证监视冗余

传输层 (Transport layer)mdashmdash泛洪失步

6 )能量攻击Kocher等人 [Koc99]指出测量一个 CPU当前的能量供给能在很大程度上确定处理器的内部活动他们提出了两种能量攻击的方法简单能量分析 (simple power analysis)人工地跟踪检查和尝试确定程序作用的位置比如分支基于不同 CUP操作的能耗知识基于程序作用攻击者然后减少密钥的比特差分能量分析 (Differential power analysis)用相关性确定作用和密钥比特这种攻击最初目标是智能卡这种卡从外部读卡器获取能量但是这种攻击也能应用到许多嵌入式系统中

7 )反攻击 在一些时候有可能构造反破坏的嵌入式系统使电子设备难以发觉和分析延缓了攻击者芯片中有限的信息也有助阻止攻击者发现数据

6 Efficiency (效率)

ES must be efficient

bull Code-size efficient( 特别是片上系统 )

bull Run-time efficient

bull Weight efficient

bull Cost efficient

bull Energy efficient

能量有效性的重要意义

ldquoinherent power

efficiency of siliconldquo

59

低功耗设计问题 功耗问题是近几年来人们在嵌入式系统的设计中普遍关注的难点和热点它严重地制约着嵌入式系统的应用与发展

无论是在军事还是在商业贸易上的应用相当数量的嵌入式系统一般是由电池来供给电能的而且大多数嵌入式设备都有体积和质量的约束减少电能消耗不仅能延长电池的使用寿命延长用户更换电池的周期而且能带来提高系统性能与降低系统开销的好处甚至能起到保护环境的作用在便携式设备中 CPU消耗的电能越少电池的寿命就越长同时散发的热量少了所需的散热器就少了从而可减少该设备的花费和体积使产品尽快进入市场的目标

1 低功耗嵌入式应用系统是指以降低系统功耗为一个主要性能指标的嵌入式系统如计算机里的许多芯片过去用 5V供电现在用 33V 18V 并提出了绿色电器的概念

60

低功耗设备的要求1 )首先要求体积小重量轻便于携带2 )采用低功耗电路的设计方法以降低系统的功耗

它除了选用各种低功耗的器件和芯片外还在满足速度等性能指标的前提下进行降低功耗的硬件电路设计和软件设计

3 )有的系统应用在交流供电比较困难甚至无法用交流供电的场合因而各种电池(瓶)就成为其主要供电手段

4 )采用 LCD液晶显示器5 )采用 RS232C串行通信接口6 )采用微功耗高抗干扰的 CMOS集成电路

功耗产生的原因 P=UI

与功耗有关的因素

( 1 )电阻上消耗的功率( 2 )有源器件的开关转换阶段( 3 )集成电路内部和外部电容的充放电( 4 )系统的性能指标负载能力被处理信号的工作频率电路的工作频率电源的管理水平零部件的性能散热条件接口的物理性能等对系统功耗起着重要的作用

降低功耗的措施

功耗的组成动态 + 静态动态电源管理动态电压缩放低功耗硬件设计低功耗软件设计

二设计方法学概论

问题功 能 性能要求价 格 开发 周 期 等约束

设计 选择 折衷 分析比较 计算 评价

嵌入式系统

0嵌入式系统设计概述

方法 工具

设计方法论( design methodology )

设计方法论有以下三个重要理由1 )确认我们所做的每一件事情都是必须要作的

不会做无谓的白工也不会漏掉关键性的重要工作其中包含效率优化或是功能测试

2 )可以发展出计算机辅助工具或是设计经验累积汲取每一次产品发展的经验再经过量化之后可以发展出一套工具或是方法让往后的产品设计步入自动化

3 )开发团队遵循同一套方法论可以让团队成员更容易彼此沟通每个人都能在短时间内了解整体过程中将经历哪些过程需要何种支持与接收到何种结果此外也容易透过一套已经定义好的方法论彼此相互合作协调

设计目标 1 )上市时间

也就是 time-to-market 的观念2 )设计成本

许多消费性产品对于价格非常敏感所以产品厂商对于成本会斤斤计较是很合理的

3 )品质 顾客也许不需要最快最便宜的产品但是一定会要求功能质量保证不能只用一小段时间就坏掉了

传统的设计主要步骤

2 传统的设计流程方法1 )瀑布模型 (Waterfall)2 )螺旋模型 (Spiral)3 )连续改进 (Successive Refinement)4 )硬件与软件的同步设计 (SWHW Co-

deign)5 )阶层式 (Hierarchical) 设计6 )同步工程( concurrent

engineering )

瀑布模型 (Waterfall)

螺旋模型 (Spiral)

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 2: 大学计算机基础 —— 计算机科学概论

设计的挑战嵌入式与网络计算实验室

本讲义多有引用他人工作在此一并致谢

一嵌入式系统的一些基本特征

1 一类嵌入式系统硬件是一个闭环系统

cyber-physical systems

2 嵌入式系统中计算的基本问题

体系结构

方法学

应用特点规范参考设计

建模分析和仿真性 能 功 率 成本

协同验证

硬件体系结构CPUs 协同设计 多 处 理 器 网络

软件体系结构处 理 调 度 分配

问题 1mdashmdash体系结构(architectures)

硬件体系结构 CPUs协同设计多处理器网络软件体系结构 处理调度分配中间件人机交互 硬件软件及其二者之间的关系

问题 2mdashmdash方法学(methodologies)

建模分析形式化仿真性能功率能耗成本价格协同验证方法学中的步骤靠工具来执行

问题 3mdashmdash应用(applications)

特点规范参考设计 理解你的应用是获得嵌入式计算系统最大性能的关键我们可以根据应用的特点去优化设计这个优势可以使我们执行许多有效的优化而这在通用系统中是不可能的但是这也意味着我们必须对应用的特点有足够的认识这样才能在利用特点的同时避免在系统实现过程中产生问题

面向应用的计算( SmartApps An Application Centric Approach to High Performance Computing )

Today System Centric Computing

Application(Algorithm)

Compiler(static)

System(OS amp Arch)

HWOS

CompilerApplication

System-Centric Computing

Development entAnalysis amp

Optimization

Execution

Input Data

Classic Avenues toperformance

Parallel Algorithms Static Compiler Optimization OS support Good Architecture

Whatrsquos missing Compiler are conservative OS offers generic services Architecture is generic

No Global Optimization No matching between ApplicationOSHW Intractable for the general case

SmartApps Application Centric Computing

Application ControlInstance-specific optimization

Compiler + OS + Architecture + Data + Feedback

Application(Algorithm)

Development entAnalysis amp

Optimization

Compiler (static) +run-time techniques

Compiler(run-time)

OS(modular)

Architecture(reconfigurable)

SmartAppApplication

CompilerOS

HW

Run-time SystemExecution Analysis

amp Optimization

Application-Centric Computing

Input Data

Smart Application

SmartApps Architecture

Get Runtime Information(sample input system information etc)

Static CompilerAugmented withruntime techniques

Predictor ampOptimizer

partially compiledcode with unknownsand runtime hooks

Information forrapid simulation

Compute Optimal Applicationand System Configuration

Recompile Applicationandor Reconfigure System

Predictor ampEvaluator

Configurer

Application

Execute Application

Continuous monitorperformance and adaptas necessary

Predictor ampEvaluator

Predictor ampOptimizer

Adaptive Software

Runtime tuning (worecompile or reconfigure)

Small adaptation (tuning)

Large adaptation(failure phase change)

3 Real-time 约束许多 ES 必须满足实时约束什么是实时系统 实时系统是将时间定量化的一个概念实时系统是使用物理时钟来衡

量的当我们使用物理时钟来量化时间时我们就会讨论到实时的概念

与实时相反逻辑时间(也称为虚拟时间)是对时间的一种定性的概念通过使用事件顺序关系来表示例如之前之后某个时候最后在hellip之前接着等等

定义一个系统称为实时系统当我们需要用定量的时间表达式(也就是说实时)来描述这个系统的行为在这个实时系统的定义中隐含的表达了所有的定量的时间度量都是用一个物理时钟测量得到的

任何一个行为可以完全不用任何定量时间表达来描述其行为的系统肯定不是实时系统但一个系统的完整行为可以用它对各种外部刺激的响应列表来描述也就是说一个系统的行为大部分描述根本没有定量的时间表达式仍然被认为是一个实时系统

实时系统的类型根据任务超过截止时间的后果实时系统可以分为 硬实时软实时固实时1 )硬实时当系统执行任务时被强制要求在某个时间范围内要

产生结果换句话说任何时刻硬实时任务没有在制定的时间范围内产生要求的结果那这个系统就被认为失败了

2 )固实时当系统执行任务时与某些预设的截止时间相关联任务要求要在截止时间之前完成结果的计算不同于硬实时任务就算一个固实时任务没有在截止时间之前完成系统也不会失败迟来的结果仅仅是被丢弃了

3 )软实时当系统执行任务时也有与之相关联的时间界限但是不像硬实时和固实时任务软实时任务的时间界限并不是以绝对数值来表示的取而代之的是平均响应时间

Real-Time 系统与嵌入式系统

Embedded and Real-

Time 往往同义 Most embedded

systems are real-time

Most real-time systems are embedded

embeddedembedded

real-timereal-time

embedded embedded real-timereal-time

4 反应系统ES 是一个反应系统 转换系统输入(开始) -gt 软件系统(经过一段时间后停止运行) -gt (然后)输

出即用户把数据输入给计算机软件对这些数据经过一段时间的计算最后给出输出结果

输入数据经过特定的规则被转换并且在结束计算过程以后给出结果 而 reactive system 却与此相反在 reactive system 里往往没有明确的时序安排总体来讲

reactive system 表示的是不限制运行时间的系统这其中要和外部环境相互作用也就是在外部刺激上的反应 (reactive) 例如和不同使用者或者外部的硬件等但是也包括内部发生的交流行为因为 reactive system 是被集成在并行运行的分布式系统的规则中的例如一个计算机的操作系统是这样一个 reactive system 它不会停止运行 而总是反应用户给的输入 并且计算机中的各个组件之间要进行交流

在电信领域生产控制或者在硬件环境的构造(嵌入式系统)中还存在很多这样的例子在信息系统中也就是基于数据库的应用系统中也要用到 reactive system 在给一个典型的例子就是警报系统

5 混成系统Hybrid systems(analog + digital parts)混成系统一般由离散分立组件和连续组件并行或者串

行组成组件之间的行为由计算模型进行控制由于大多数复杂控制系统都包含了由连续变量所描述的物理层的动态演化过程和以符号操作与离散监控决策为特征的高层协调优化过程因此混成系统在工业控制和国防等领域大量存在混成系统定义凡是系统自身具有混合结构并且其

行为(输出和状态)取决于离散事件系统和连续动态系统相互作用的动态系统就称为混成系统

混成系统的典型特征( 1) 系统内存在着性质不同的连续和离散两类变量( 2) 时间和事件共同驱动系统的状态演化 ( 3)连续变量穿越阈值使状态使能或失能 ( 4)离散状态的变化改变连续变量遵循的变化速率 ( 5)离散事件发生在离散时刻 具有顺序选择并发等特色

( 6)状态呈阶段性间歇性切换变化 动态特征显著 ( 7) 对系统的控制表现为对连续状态和离散状态的集成控制 ( 8) 对系统的优化表现为在定性 定量双重指标下的集成优化

6 专用系统 Dedicated towards a certain

applicationKnowledge about behavior at design time can be used to minimize resources and to maximize robustness

Dedicated user interface(no mouse keyboard and screen)

二设计的挑战 实时可信可靠保密安全

1 为什么需要可靠的嵌入式系统1 )许多市场不需要高度可靠的嵌入式计算机但是许多嵌入式计算机必须

是高度可靠的2 )许多嵌入式计算机必须是高度可靠的汽车电子航空电子医疗设备

关键通信3 )可靠性的定义如电话交换机系统每年停机少于 30秒4 )关于可靠数字系统设计的研究几十年前就有不同的体系结构和方法学

被开发用于长周期低失误率的数字系统操作那么传统的可靠计算机和可靠的计算机系统有什么不同呢

5 )可靠嵌入式计算机通常是分布式系统如汽车电子航空电子和医疗设备都是必须高度可靠的分布式嵌入式系统

6 )嵌入式计算机容易受许多新类型攻击可靠计算机传统上是物理上不可访问的服务器或者机器mdashmdash物理安全长期以来是计算机安全的安全策略但是嵌入式计算机通常在非保护环境下操作这就允许新的故障和攻击这些需要都新的保护措施

2 可靠与可信ES 必需是可靠的可信的如何评价与度量

bull可靠性( Reliability) R(t)

bull可维护性( Maintainability) M(d)

bull有效性( Availability ) A(t)

bull安全性( Safety )bull保密性( Security )

可靠性定义可靠性 R(t) 产品在规定条件下和规定时间内完成规定

功能的能力产品可靠性定义的要素是三个ldquo规定rdquo 1 )ldquo规定条件rdquo包括使用时的环境条件

和工作条件2 )ldquo规定时间rdquo是指产品规定了的任务

时间3 )ldquo规定功能rdquo是指产品规定了的必须

具备的功能及其技术指标

1 )ldquo规定条件rdquo包括使用时的环境条件和工作条件 例如同一型号的汽车在高速公路和在崎岖的山路上行驶其可

靠性的表现就不大一样要谈论产品的可靠性必须指明规定的条件是什么2 )ldquo规定时间rdquo是指产品规定了的任务时间 随着产品任务时间的增加产品出现故障的概率将增加

而产品的可靠性将是下降的因此谈论产品的可靠性离不开规定的任务时间例如一辆汽车在在刚刚开出厂子和用了5 年后相比它出故障的概率显然大了很多

3 )ldquo规定功能rdquo是指产品规定了的必须具备的功能及其技术指标所要求产品功能的多少和其技术指标的高低直接影响到产品可靠性指标的高低

例如电风扇的主要功能有转叶摇头定时那么规定的功能是三者都要还是仅需要转叶能转能够吹风所得出的可靠性指标是大不一样的

可维护性 M(d)1 )计算机系统的可维护性是指该系统失效后在规定时间内可

修复到规定功能的能力2 )反映系统可维护性高低的参数是修复率秒平均修复时间3 )软件可维护性即维护人员对该软件进行维护的难易程度

具体包括理解改正改动和改进该软件的难易程度4 )决定可维护性的因素

系统的大小系统的年龄结构合理性

5 )可维护性的度量 可理解性可测试性可修改性可移植性

有效性 A(t)设备的有效性的表式为 设备有效性 = 平均故障间隔期 (平均故障间隔期+平均修理时间)

在逻辑中如果一个论证不能从真前提中得出假结论 则论证的形式是完全有效的

一个论证若被称为是有效的则如果在其中所有前提都为真的每个模型中结论也是真的

例如ldquo所有 A 是 B 有些 A 是 C 所以有些 B 是Crdquo 是有效形式

可用性 实用性

3 可靠系统设计的基本原理1 )故障 (faults) 分析2 )可靠性分析3 )纠错技术4 )软件可靠性

1 )故障 (faults) 分析永久 (permanent) 与暂时( transient )故障故障来源 物理故障 (Physical faults)由生产缺陷辐射危害等等引起

设计故障 (Design faults) 是不合适设计的系统的结果

操作故障 (Operational faults) 来自人为过失安全破坏劣质设计的人机接口等等

可靠性设计

故障及其分类 产品的故障按其故障规律分为两大类

偶然故障 渐变故障

产品的故障按其故障后果分为两大类 致命性故障 非致命性故障

产品的故障按其统计特性分为两大类 独立故障 从属故障

可靠度 产品在规定的条件下和规定的时间内完成规

定功能的概率称为可靠度依定义可知系统的可靠度是时间的函数表示为

式中 R(t)mdashmdash 可靠度函数 ξmdashmdash 产生故障前的工作时间 t mdashmdash 规定的时间

)()( tPtR

2 )可靠性的分析mdashmdash可靠度

可靠度函数

依定义可知可靠度函数 R(t) 为

式中 N0 mdashmdash t = 0 时在规定条件下进行工作的产品数

r(t) mdashmdash  在 0 到 t 时刻的工作时间内产品的累计

故障数

0

0 )()(

N

trNtR

累积故障分布函数 产品在规定的条件下和规定的时间内丧失

规定功能的概率称为累积故障概率(又叫不可靠度) 依定义可知产品的累积故障概率是时间的函

数即

显然以下关系成立

0

)()(

N

trtF

1)()( tFtR

可靠度函数与累积故障分布函数的性质

图 R(t)F(t)与f(t)的关系t

f(t)

f(t)

F(to)

R(to)

to

由密度函数的性质 1)(0

dttf 可知

t

tdttfdttftFtR )()(1)(1)(

0

因此 R(t) F(t) 与 f(t) 之间的关系如图所示

故障率函数 故障率

工作到某时刻尚未发生故障的产品在该时刻后单位时间内发生故障的概率称之为产品的故障率

用数学符号表示为

式中 (t) mdashmdash 故障率 dr(t) mdashmdash t 时刻后 dt 时间内故障的产品数 Ns(t) mdashmdash 残存产品数即到 t 时刻尚未故障的产品

dttN

tdrt

s )(

)()(

35

故障率函数

可按下式进行工程计算

式中 Δr(t) mdashmdash t 时刻后 Δt 时间内故障的产品数

Δt mdashmdash 所取时间间隔 Ns(t) mdashmdash 残存产品数

对于低故障率的元部件常以 10-9h 为故障率的单位称之为菲特( Fit )

ttN

trt

s

)(

)()(

产品故障浴盆曲线 浴盆曲线

大多数产品的故障率随时间的变化曲线形似浴盆称之为浴盆曲线由于产品故障机理的不同产品的故障率随时间的变化大致可以分为三个阶段

产品典型的故障率曲线

t

使用寿命

早期故障

偶然故障 耗损故障

A B规定的故障率 维修后故障率下降

(t)

3 )纠错技术( 1 )纠错码 在 1950s就开始研究最早的是可以检测和纠错的汉明码它们通过数字系统广泛地用于识别和纠正短暂或者持久的错误这些码引入冗余信息来确保一些类型的错误可以被检测和纠正比如一个单错校正 双错校正的码能用一个比特检测和纠正一个错误但是不能用两个比特纠错

( 2 )三模冗余 (triple modular

redundancy) 计算单元 C 有三个副本 C1C2和 C3三个单元接收同

样的输入一个独立单元比较每个输入的结果如果至少两个结果一致那么那个值被表决器选做正确结果如果三个结果都不相同那么就没有正确的结果

1C

2C

3C

表决错误

结果

输入

( 3 )看门狗定时器 (watchdog timer)

看门狗定时器 (watchdog timer)被广泛地用于检测系统问题如图 看门狗定时器连接到一个监视系统如果这个看门狗定时器翻转它产生一个完成信号用于标注系统的错误中断系统应该这样设计当适当运行的时候它一直在可能产生翻转信号之前复位定时器因此来自看门狗定时器的完成信号指示系统在一定程度上不合适地操作看门狗定时器用于预防不同的故障

系统看门狗定时器

完成

复位

( 4 )设计多样性 (Design diversity)

一种用于减少一些系统错误进入设计的设计方法学当一个设计需要给定模块的不同实例应该采用模块的不同实现而不是到处都用同一种模块比如一个有多个 CPU的系统可能采用不同类型的 CPU而不是到处采用同一种类型的 CPU在一个三模冗余系统产生表决结构的组件可能有不同的实现这样可以减少产生同样设计错误的机会

4 )软件可靠性ldquo在规定的条件下在规定的时间内软件不引起失效的概率rdquo

规定的条件 软件运行的软硬件环境 软件操作剖面软件运行的输入空间及其概率分布

规定的时间 日历时间 时钟时间 执行时间

激活软件 输入域 缺陷的数据

软件缺陷 软件

不可接受的结果 (软件故障) 输出域

软件故障的特点

软件与硬件可靠性的区别硬件 软件

故障机理 老化损耗 残留缺陷在一定环境下造成的软件错误

复杂性 内部逻辑较为简单 内部逻辑高度复杂这就在很大程度上决定了设计错误是导致软件故障的主要原因

唯一性 任何两个硬件不可能绝对相同

软件是唯一的软件拷贝不改变软件本身

可靠性的核心 内部元部件 设计者的思维和软件的复杂性纠错维护方法 修复或更换失效的元部件 重设计 可靠性检验标准化

已标准化且有一整套完整的理论

仍未建立更没有完整的理论体系

产品市场 已有成熟的产品市场 产品市场还很新 错误性质 一些瞬间的硬件错误可能

会被误认为是软件错误 软件错误是永恒的可重现的

影响软件可靠性的因素( 1 )运行环境 ( 剖面 )

同一软件在不同运行剖面下其可靠性行为可能极不相同 软件故障是软件缺陷在一定输入情况下被激活的结果 假设软件输入域划分为两个部分 G 和 F 运行剖面不包含 F 中

的输入则软件不会出现故障其可靠性恒为 l 反之如果运行剖面不包含 G 中的输入则每一输入情况下均出现故障如果没有容错措施则 R=0

( 2 )软件规模 随着软件规模的增大软件可靠性问题愈显突出在我们考虑软件

可靠性问题时软件一般是指中型以上软件 (4000-5000条以上语句 ) 这时可靠性问题难以对付

软件工程实践的一个侧面可以反映这一点即单元测试一般由编程人员本人进行而综合测试则需独立的测试人员

影响软件可靠性的因素( 3 )软件内部结构

结构越复杂软件复杂度越高内含缺陷数越大因而软件可靠度越低

( 4 )软件可靠性设计技术 一般是指软件设计阶段中采用的用以保证和提高软件可靠性为主要目标的软件技术

( 5 )软件可靠性测试 研究表明软件测试方法与资源投入对软件可靠性有不可忽视的影

响( 6 )软件可靠性管理

软件可靠性管理旨在系统管理软件生存期各阶段的可靠性活动使之系统化规范化一体化这样就可以避免许多人为错误以提高软件可靠性

影响软件可靠性的因素( 7 )软件开发人员能力和经验

软件开发人员 ( 包括测试人员 ) 的能力愈强经验愈丰富所犯错误便可能愈少所得软件产品质量愈高相应的可靠性也愈高

( 8 )软件开发方法 软件工程表明开发方法对软件可靠性有显著影响 与非结构化方法比较结构化方法可以明显减少软件缺陷数

( 9 )软件开发环境 研究表明程序语言软件开发环境影响软件的可靠性而软件测

试工具的优劣则影响可靠性测试结果

4 安全 (Safety)amp保密 (Security)

安全 (Safety) 是保证财产和人身受到损害可靠性是指在一定的环境条件下以及一定的时间内系统完成特定任务的可能性而有效性则是系统的长期的工作时间于其存在时间 ( 简单的定义为运行时间 +维护时间 ) 的 比例保密 (Security) 是针对危险破坏损失或非法活动而进行措施在一定层面上保密 (Security)要比安全 (Safety)宽广的多例如信息 Security家庭 Security 网络 Security 国家Security) 等

Security强调的是外在事物对特定目标的危害

Safety 是系统本身的潜在危害

四个概念的比较分析安全 (Safety)可靠性 (Reliability)有效性 (Availability)保密 (Security )安全 (Safety)高的系统 软件可靠性不

一定高可靠性和有效性并不是一码事保密 (Security )的系统 软件是安全

(Safety) 系统 软件的重要保障

可靠性安全性保密性 可靠(或可信)系统设计 (Reliable (or dependable) system design)是制造嵌入式系统所关注的甚至在面对内部或者外部问题时可靠系统设计经常假设问题是非恶意引起的

安全重要的系统设计 (Safety-critical system design)研究确保系统安全操作的方法独立于引起问题的原因

保密性 (Security)主要关注恶意攻击

Aizientis等人描述了可信性和保密性间的关系可信性和保密性由几个特性所组成

服务的可用性 (Availability) 服务的连续性 (Continuity) 来自用户和所处环境的灾难性后果的安全性 (Safety) 来自不合适系统改变的完整性 (Integrity) 通过更改和修补的可维护性 (Maintainability) 信息的机密性 (Confidentiality)

可用性完整性

可靠性安全性可维护性

机密性

可信性 保密性

5 新型攻击和对策1 )物理攻击嵌入式系统比通用计算机更容易受攻击 一个关键原因是许多嵌入式计算机对攻击者可物理访问

2 )互联网攻击一些嵌入式系统的攻击通过互联网访问变得更加容易今天许多嵌入式系统连接到互联网

3 )电池攻击 (battery attack)这种攻击试图通过耗尽电池来关闭节点

4 )服务拒绝攻击 (Denial-of-service attacks)

在通用系统中众所周知但是实时嵌入式系统可能更容易受服务质量 (quality-of-service (QoS))攻击如果网络发布实时数据那么发送过程中的一点延迟都能引起数据无效如果那些数据用来实时控制那么这些短暂延迟就能引起系统故障我们称这种危害为时间攻击因为它改变了系统的实时特性

QoS或者时间攻击之所以强大使因为它的影响不仅仅限于信息被控制系统的动态特性可决定系统的响应如果一个大型沉重快速运动的系统被控制那么时间上一个相对小的改变能引起大量的破坏

5 )网络(协议)攻击Wood和 Stankovic[Woo02]在传感器网络上确定了一些方式这些方式可在网络层次的不同层执行拒绝服务攻击如下所列

物理层 (Physical layer)mdashmdash拥塞破坏 链路层 (Link layer)mdashmdash碰撞耗尽非公平

网络和路由层 (Network and routing layer)mdashmdash丢弃和贪婪汇集方向误导黑洞认证监视冗余

传输层 (Transport layer)mdashmdash泛洪失步

6 )能量攻击Kocher等人 [Koc99]指出测量一个 CPU当前的能量供给能在很大程度上确定处理器的内部活动他们提出了两种能量攻击的方法简单能量分析 (simple power analysis)人工地跟踪检查和尝试确定程序作用的位置比如分支基于不同 CUP操作的能耗知识基于程序作用攻击者然后减少密钥的比特差分能量分析 (Differential power analysis)用相关性确定作用和密钥比特这种攻击最初目标是智能卡这种卡从外部读卡器获取能量但是这种攻击也能应用到许多嵌入式系统中

7 )反攻击 在一些时候有可能构造反破坏的嵌入式系统使电子设备难以发觉和分析延缓了攻击者芯片中有限的信息也有助阻止攻击者发现数据

6 Efficiency (效率)

ES must be efficient

bull Code-size efficient( 特别是片上系统 )

bull Run-time efficient

bull Weight efficient

bull Cost efficient

bull Energy efficient

能量有效性的重要意义

ldquoinherent power

efficiency of siliconldquo

59

低功耗设计问题 功耗问题是近几年来人们在嵌入式系统的设计中普遍关注的难点和热点它严重地制约着嵌入式系统的应用与发展

无论是在军事还是在商业贸易上的应用相当数量的嵌入式系统一般是由电池来供给电能的而且大多数嵌入式设备都有体积和质量的约束减少电能消耗不仅能延长电池的使用寿命延长用户更换电池的周期而且能带来提高系统性能与降低系统开销的好处甚至能起到保护环境的作用在便携式设备中 CPU消耗的电能越少电池的寿命就越长同时散发的热量少了所需的散热器就少了从而可减少该设备的花费和体积使产品尽快进入市场的目标

1 低功耗嵌入式应用系统是指以降低系统功耗为一个主要性能指标的嵌入式系统如计算机里的许多芯片过去用 5V供电现在用 33V 18V 并提出了绿色电器的概念

60

低功耗设备的要求1 )首先要求体积小重量轻便于携带2 )采用低功耗电路的设计方法以降低系统的功耗

它除了选用各种低功耗的器件和芯片外还在满足速度等性能指标的前提下进行降低功耗的硬件电路设计和软件设计

3 )有的系统应用在交流供电比较困难甚至无法用交流供电的场合因而各种电池(瓶)就成为其主要供电手段

4 )采用 LCD液晶显示器5 )采用 RS232C串行通信接口6 )采用微功耗高抗干扰的 CMOS集成电路

功耗产生的原因 P=UI

与功耗有关的因素

( 1 )电阻上消耗的功率( 2 )有源器件的开关转换阶段( 3 )集成电路内部和外部电容的充放电( 4 )系统的性能指标负载能力被处理信号的工作频率电路的工作频率电源的管理水平零部件的性能散热条件接口的物理性能等对系统功耗起着重要的作用

降低功耗的措施

功耗的组成动态 + 静态动态电源管理动态电压缩放低功耗硬件设计低功耗软件设计

二设计方法学概论

问题功 能 性能要求价 格 开发 周 期 等约束

设计 选择 折衷 分析比较 计算 评价

嵌入式系统

0嵌入式系统设计概述

方法 工具

设计方法论( design methodology )

设计方法论有以下三个重要理由1 )确认我们所做的每一件事情都是必须要作的

不会做无谓的白工也不会漏掉关键性的重要工作其中包含效率优化或是功能测试

2 )可以发展出计算机辅助工具或是设计经验累积汲取每一次产品发展的经验再经过量化之后可以发展出一套工具或是方法让往后的产品设计步入自动化

3 )开发团队遵循同一套方法论可以让团队成员更容易彼此沟通每个人都能在短时间内了解整体过程中将经历哪些过程需要何种支持与接收到何种结果此外也容易透过一套已经定义好的方法论彼此相互合作协调

设计目标 1 )上市时间

也就是 time-to-market 的观念2 )设计成本

许多消费性产品对于价格非常敏感所以产品厂商对于成本会斤斤计较是很合理的

3 )品质 顾客也许不需要最快最便宜的产品但是一定会要求功能质量保证不能只用一小段时间就坏掉了

传统的设计主要步骤

2 传统的设计流程方法1 )瀑布模型 (Waterfall)2 )螺旋模型 (Spiral)3 )连续改进 (Successive Refinement)4 )硬件与软件的同步设计 (SWHW Co-

deign)5 )阶层式 (Hierarchical) 设计6 )同步工程( concurrent

engineering )

瀑布模型 (Waterfall)

螺旋模型 (Spiral)

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 3: 大学计算机基础 —— 计算机科学概论

一嵌入式系统的一些基本特征

1 一类嵌入式系统硬件是一个闭环系统

cyber-physical systems

2 嵌入式系统中计算的基本问题

体系结构

方法学

应用特点规范参考设计

建模分析和仿真性 能 功 率 成本

协同验证

硬件体系结构CPUs 协同设计 多 处 理 器 网络

软件体系结构处 理 调 度 分配

问题 1mdashmdash体系结构(architectures)

硬件体系结构 CPUs协同设计多处理器网络软件体系结构 处理调度分配中间件人机交互 硬件软件及其二者之间的关系

问题 2mdashmdash方法学(methodologies)

建模分析形式化仿真性能功率能耗成本价格协同验证方法学中的步骤靠工具来执行

问题 3mdashmdash应用(applications)

特点规范参考设计 理解你的应用是获得嵌入式计算系统最大性能的关键我们可以根据应用的特点去优化设计这个优势可以使我们执行许多有效的优化而这在通用系统中是不可能的但是这也意味着我们必须对应用的特点有足够的认识这样才能在利用特点的同时避免在系统实现过程中产生问题

面向应用的计算( SmartApps An Application Centric Approach to High Performance Computing )

Today System Centric Computing

Application(Algorithm)

Compiler(static)

System(OS amp Arch)

HWOS

CompilerApplication

System-Centric Computing

Development entAnalysis amp

Optimization

Execution

Input Data

Classic Avenues toperformance

Parallel Algorithms Static Compiler Optimization OS support Good Architecture

Whatrsquos missing Compiler are conservative OS offers generic services Architecture is generic

No Global Optimization No matching between ApplicationOSHW Intractable for the general case

SmartApps Application Centric Computing

Application ControlInstance-specific optimization

Compiler + OS + Architecture + Data + Feedback

Application(Algorithm)

Development entAnalysis amp

Optimization

Compiler (static) +run-time techniques

Compiler(run-time)

OS(modular)

Architecture(reconfigurable)

SmartAppApplication

CompilerOS

HW

Run-time SystemExecution Analysis

amp Optimization

Application-Centric Computing

Input Data

Smart Application

SmartApps Architecture

Get Runtime Information(sample input system information etc)

Static CompilerAugmented withruntime techniques

Predictor ampOptimizer

partially compiledcode with unknownsand runtime hooks

Information forrapid simulation

Compute Optimal Applicationand System Configuration

Recompile Applicationandor Reconfigure System

Predictor ampEvaluator

Configurer

Application

Execute Application

Continuous monitorperformance and adaptas necessary

Predictor ampEvaluator

Predictor ampOptimizer

Adaptive Software

Runtime tuning (worecompile or reconfigure)

Small adaptation (tuning)

Large adaptation(failure phase change)

3 Real-time 约束许多 ES 必须满足实时约束什么是实时系统 实时系统是将时间定量化的一个概念实时系统是使用物理时钟来衡

量的当我们使用物理时钟来量化时间时我们就会讨论到实时的概念

与实时相反逻辑时间(也称为虚拟时间)是对时间的一种定性的概念通过使用事件顺序关系来表示例如之前之后某个时候最后在hellip之前接着等等

定义一个系统称为实时系统当我们需要用定量的时间表达式(也就是说实时)来描述这个系统的行为在这个实时系统的定义中隐含的表达了所有的定量的时间度量都是用一个物理时钟测量得到的

任何一个行为可以完全不用任何定量时间表达来描述其行为的系统肯定不是实时系统但一个系统的完整行为可以用它对各种外部刺激的响应列表来描述也就是说一个系统的行为大部分描述根本没有定量的时间表达式仍然被认为是一个实时系统

实时系统的类型根据任务超过截止时间的后果实时系统可以分为 硬实时软实时固实时1 )硬实时当系统执行任务时被强制要求在某个时间范围内要

产生结果换句话说任何时刻硬实时任务没有在制定的时间范围内产生要求的结果那这个系统就被认为失败了

2 )固实时当系统执行任务时与某些预设的截止时间相关联任务要求要在截止时间之前完成结果的计算不同于硬实时任务就算一个固实时任务没有在截止时间之前完成系统也不会失败迟来的结果仅仅是被丢弃了

3 )软实时当系统执行任务时也有与之相关联的时间界限但是不像硬实时和固实时任务软实时任务的时间界限并不是以绝对数值来表示的取而代之的是平均响应时间

Real-Time 系统与嵌入式系统

Embedded and Real-

Time 往往同义 Most embedded

systems are real-time

Most real-time systems are embedded

embeddedembedded

real-timereal-time

embedded embedded real-timereal-time

4 反应系统ES 是一个反应系统 转换系统输入(开始) -gt 软件系统(经过一段时间后停止运行) -gt (然后)输

出即用户把数据输入给计算机软件对这些数据经过一段时间的计算最后给出输出结果

输入数据经过特定的规则被转换并且在结束计算过程以后给出结果 而 reactive system 却与此相反在 reactive system 里往往没有明确的时序安排总体来讲

reactive system 表示的是不限制运行时间的系统这其中要和外部环境相互作用也就是在外部刺激上的反应 (reactive) 例如和不同使用者或者外部的硬件等但是也包括内部发生的交流行为因为 reactive system 是被集成在并行运行的分布式系统的规则中的例如一个计算机的操作系统是这样一个 reactive system 它不会停止运行 而总是反应用户给的输入 并且计算机中的各个组件之间要进行交流

在电信领域生产控制或者在硬件环境的构造(嵌入式系统)中还存在很多这样的例子在信息系统中也就是基于数据库的应用系统中也要用到 reactive system 在给一个典型的例子就是警报系统

5 混成系统Hybrid systems(analog + digital parts)混成系统一般由离散分立组件和连续组件并行或者串

行组成组件之间的行为由计算模型进行控制由于大多数复杂控制系统都包含了由连续变量所描述的物理层的动态演化过程和以符号操作与离散监控决策为特征的高层协调优化过程因此混成系统在工业控制和国防等领域大量存在混成系统定义凡是系统自身具有混合结构并且其

行为(输出和状态)取决于离散事件系统和连续动态系统相互作用的动态系统就称为混成系统

混成系统的典型特征( 1) 系统内存在着性质不同的连续和离散两类变量( 2) 时间和事件共同驱动系统的状态演化 ( 3)连续变量穿越阈值使状态使能或失能 ( 4)离散状态的变化改变连续变量遵循的变化速率 ( 5)离散事件发生在离散时刻 具有顺序选择并发等特色

( 6)状态呈阶段性间歇性切换变化 动态特征显著 ( 7) 对系统的控制表现为对连续状态和离散状态的集成控制 ( 8) 对系统的优化表现为在定性 定量双重指标下的集成优化

6 专用系统 Dedicated towards a certain

applicationKnowledge about behavior at design time can be used to minimize resources and to maximize robustness

Dedicated user interface(no mouse keyboard and screen)

二设计的挑战 实时可信可靠保密安全

1 为什么需要可靠的嵌入式系统1 )许多市场不需要高度可靠的嵌入式计算机但是许多嵌入式计算机必须

是高度可靠的2 )许多嵌入式计算机必须是高度可靠的汽车电子航空电子医疗设备

关键通信3 )可靠性的定义如电话交换机系统每年停机少于 30秒4 )关于可靠数字系统设计的研究几十年前就有不同的体系结构和方法学

被开发用于长周期低失误率的数字系统操作那么传统的可靠计算机和可靠的计算机系统有什么不同呢

5 )可靠嵌入式计算机通常是分布式系统如汽车电子航空电子和医疗设备都是必须高度可靠的分布式嵌入式系统

6 )嵌入式计算机容易受许多新类型攻击可靠计算机传统上是物理上不可访问的服务器或者机器mdashmdash物理安全长期以来是计算机安全的安全策略但是嵌入式计算机通常在非保护环境下操作这就允许新的故障和攻击这些需要都新的保护措施

2 可靠与可信ES 必需是可靠的可信的如何评价与度量

bull可靠性( Reliability) R(t)

bull可维护性( Maintainability) M(d)

bull有效性( Availability ) A(t)

bull安全性( Safety )bull保密性( Security )

可靠性定义可靠性 R(t) 产品在规定条件下和规定时间内完成规定

功能的能力产品可靠性定义的要素是三个ldquo规定rdquo 1 )ldquo规定条件rdquo包括使用时的环境条件

和工作条件2 )ldquo规定时间rdquo是指产品规定了的任务

时间3 )ldquo规定功能rdquo是指产品规定了的必须

具备的功能及其技术指标

1 )ldquo规定条件rdquo包括使用时的环境条件和工作条件 例如同一型号的汽车在高速公路和在崎岖的山路上行驶其可

靠性的表现就不大一样要谈论产品的可靠性必须指明规定的条件是什么2 )ldquo规定时间rdquo是指产品规定了的任务时间 随着产品任务时间的增加产品出现故障的概率将增加

而产品的可靠性将是下降的因此谈论产品的可靠性离不开规定的任务时间例如一辆汽车在在刚刚开出厂子和用了5 年后相比它出故障的概率显然大了很多

3 )ldquo规定功能rdquo是指产品规定了的必须具备的功能及其技术指标所要求产品功能的多少和其技术指标的高低直接影响到产品可靠性指标的高低

例如电风扇的主要功能有转叶摇头定时那么规定的功能是三者都要还是仅需要转叶能转能够吹风所得出的可靠性指标是大不一样的

可维护性 M(d)1 )计算机系统的可维护性是指该系统失效后在规定时间内可

修复到规定功能的能力2 )反映系统可维护性高低的参数是修复率秒平均修复时间3 )软件可维护性即维护人员对该软件进行维护的难易程度

具体包括理解改正改动和改进该软件的难易程度4 )决定可维护性的因素

系统的大小系统的年龄结构合理性

5 )可维护性的度量 可理解性可测试性可修改性可移植性

有效性 A(t)设备的有效性的表式为 设备有效性 = 平均故障间隔期 (平均故障间隔期+平均修理时间)

在逻辑中如果一个论证不能从真前提中得出假结论 则论证的形式是完全有效的

一个论证若被称为是有效的则如果在其中所有前提都为真的每个模型中结论也是真的

例如ldquo所有 A 是 B 有些 A 是 C 所以有些 B 是Crdquo 是有效形式

可用性 实用性

3 可靠系统设计的基本原理1 )故障 (faults) 分析2 )可靠性分析3 )纠错技术4 )软件可靠性

1 )故障 (faults) 分析永久 (permanent) 与暂时( transient )故障故障来源 物理故障 (Physical faults)由生产缺陷辐射危害等等引起

设计故障 (Design faults) 是不合适设计的系统的结果

操作故障 (Operational faults) 来自人为过失安全破坏劣质设计的人机接口等等

可靠性设计

故障及其分类 产品的故障按其故障规律分为两大类

偶然故障 渐变故障

产品的故障按其故障后果分为两大类 致命性故障 非致命性故障

产品的故障按其统计特性分为两大类 独立故障 从属故障

可靠度 产品在规定的条件下和规定的时间内完成规

定功能的概率称为可靠度依定义可知系统的可靠度是时间的函数表示为

式中 R(t)mdashmdash 可靠度函数 ξmdashmdash 产生故障前的工作时间 t mdashmdash 规定的时间

)()( tPtR

2 )可靠性的分析mdashmdash可靠度

可靠度函数

依定义可知可靠度函数 R(t) 为

式中 N0 mdashmdash t = 0 时在规定条件下进行工作的产品数

r(t) mdashmdash  在 0 到 t 时刻的工作时间内产品的累计

故障数

0

0 )()(

N

trNtR

累积故障分布函数 产品在规定的条件下和规定的时间内丧失

规定功能的概率称为累积故障概率(又叫不可靠度) 依定义可知产品的累积故障概率是时间的函

数即

显然以下关系成立

0

)()(

N

trtF

1)()( tFtR

可靠度函数与累积故障分布函数的性质

图 R(t)F(t)与f(t)的关系t

f(t)

f(t)

F(to)

R(to)

to

由密度函数的性质 1)(0

dttf 可知

t

tdttfdttftFtR )()(1)(1)(

0

因此 R(t) F(t) 与 f(t) 之间的关系如图所示

故障率函数 故障率

工作到某时刻尚未发生故障的产品在该时刻后单位时间内发生故障的概率称之为产品的故障率

用数学符号表示为

式中 (t) mdashmdash 故障率 dr(t) mdashmdash t 时刻后 dt 时间内故障的产品数 Ns(t) mdashmdash 残存产品数即到 t 时刻尚未故障的产品

dttN

tdrt

s )(

)()(

35

故障率函数

可按下式进行工程计算

式中 Δr(t) mdashmdash t 时刻后 Δt 时间内故障的产品数

Δt mdashmdash 所取时间间隔 Ns(t) mdashmdash 残存产品数

对于低故障率的元部件常以 10-9h 为故障率的单位称之为菲特( Fit )

ttN

trt

s

)(

)()(

产品故障浴盆曲线 浴盆曲线

大多数产品的故障率随时间的变化曲线形似浴盆称之为浴盆曲线由于产品故障机理的不同产品的故障率随时间的变化大致可以分为三个阶段

产品典型的故障率曲线

t

使用寿命

早期故障

偶然故障 耗损故障

A B规定的故障率 维修后故障率下降

(t)

3 )纠错技术( 1 )纠错码 在 1950s就开始研究最早的是可以检测和纠错的汉明码它们通过数字系统广泛地用于识别和纠正短暂或者持久的错误这些码引入冗余信息来确保一些类型的错误可以被检测和纠正比如一个单错校正 双错校正的码能用一个比特检测和纠正一个错误但是不能用两个比特纠错

( 2 )三模冗余 (triple modular

redundancy) 计算单元 C 有三个副本 C1C2和 C3三个单元接收同

样的输入一个独立单元比较每个输入的结果如果至少两个结果一致那么那个值被表决器选做正确结果如果三个结果都不相同那么就没有正确的结果

1C

2C

3C

表决错误

结果

输入

( 3 )看门狗定时器 (watchdog timer)

看门狗定时器 (watchdog timer)被广泛地用于检测系统问题如图 看门狗定时器连接到一个监视系统如果这个看门狗定时器翻转它产生一个完成信号用于标注系统的错误中断系统应该这样设计当适当运行的时候它一直在可能产生翻转信号之前复位定时器因此来自看门狗定时器的完成信号指示系统在一定程度上不合适地操作看门狗定时器用于预防不同的故障

系统看门狗定时器

完成

复位

( 4 )设计多样性 (Design diversity)

一种用于减少一些系统错误进入设计的设计方法学当一个设计需要给定模块的不同实例应该采用模块的不同实现而不是到处都用同一种模块比如一个有多个 CPU的系统可能采用不同类型的 CPU而不是到处采用同一种类型的 CPU在一个三模冗余系统产生表决结构的组件可能有不同的实现这样可以减少产生同样设计错误的机会

4 )软件可靠性ldquo在规定的条件下在规定的时间内软件不引起失效的概率rdquo

规定的条件 软件运行的软硬件环境 软件操作剖面软件运行的输入空间及其概率分布

规定的时间 日历时间 时钟时间 执行时间

激活软件 输入域 缺陷的数据

软件缺陷 软件

不可接受的结果 (软件故障) 输出域

软件故障的特点

软件与硬件可靠性的区别硬件 软件

故障机理 老化损耗 残留缺陷在一定环境下造成的软件错误

复杂性 内部逻辑较为简单 内部逻辑高度复杂这就在很大程度上决定了设计错误是导致软件故障的主要原因

唯一性 任何两个硬件不可能绝对相同

软件是唯一的软件拷贝不改变软件本身

可靠性的核心 内部元部件 设计者的思维和软件的复杂性纠错维护方法 修复或更换失效的元部件 重设计 可靠性检验标准化

已标准化且有一整套完整的理论

仍未建立更没有完整的理论体系

产品市场 已有成熟的产品市场 产品市场还很新 错误性质 一些瞬间的硬件错误可能

会被误认为是软件错误 软件错误是永恒的可重现的

影响软件可靠性的因素( 1 )运行环境 ( 剖面 )

同一软件在不同运行剖面下其可靠性行为可能极不相同 软件故障是软件缺陷在一定输入情况下被激活的结果 假设软件输入域划分为两个部分 G 和 F 运行剖面不包含 F 中

的输入则软件不会出现故障其可靠性恒为 l 反之如果运行剖面不包含 G 中的输入则每一输入情况下均出现故障如果没有容错措施则 R=0

( 2 )软件规模 随着软件规模的增大软件可靠性问题愈显突出在我们考虑软件

可靠性问题时软件一般是指中型以上软件 (4000-5000条以上语句 ) 这时可靠性问题难以对付

软件工程实践的一个侧面可以反映这一点即单元测试一般由编程人员本人进行而综合测试则需独立的测试人员

影响软件可靠性的因素( 3 )软件内部结构

结构越复杂软件复杂度越高内含缺陷数越大因而软件可靠度越低

( 4 )软件可靠性设计技术 一般是指软件设计阶段中采用的用以保证和提高软件可靠性为主要目标的软件技术

( 5 )软件可靠性测试 研究表明软件测试方法与资源投入对软件可靠性有不可忽视的影

响( 6 )软件可靠性管理

软件可靠性管理旨在系统管理软件生存期各阶段的可靠性活动使之系统化规范化一体化这样就可以避免许多人为错误以提高软件可靠性

影响软件可靠性的因素( 7 )软件开发人员能力和经验

软件开发人员 ( 包括测试人员 ) 的能力愈强经验愈丰富所犯错误便可能愈少所得软件产品质量愈高相应的可靠性也愈高

( 8 )软件开发方法 软件工程表明开发方法对软件可靠性有显著影响 与非结构化方法比较结构化方法可以明显减少软件缺陷数

( 9 )软件开发环境 研究表明程序语言软件开发环境影响软件的可靠性而软件测

试工具的优劣则影响可靠性测试结果

4 安全 (Safety)amp保密 (Security)

安全 (Safety) 是保证财产和人身受到损害可靠性是指在一定的环境条件下以及一定的时间内系统完成特定任务的可能性而有效性则是系统的长期的工作时间于其存在时间 ( 简单的定义为运行时间 +维护时间 ) 的 比例保密 (Security) 是针对危险破坏损失或非法活动而进行措施在一定层面上保密 (Security)要比安全 (Safety)宽广的多例如信息 Security家庭 Security 网络 Security 国家Security) 等

Security强调的是外在事物对特定目标的危害

Safety 是系统本身的潜在危害

四个概念的比较分析安全 (Safety)可靠性 (Reliability)有效性 (Availability)保密 (Security )安全 (Safety)高的系统 软件可靠性不

一定高可靠性和有效性并不是一码事保密 (Security )的系统 软件是安全

(Safety) 系统 软件的重要保障

可靠性安全性保密性 可靠(或可信)系统设计 (Reliable (or dependable) system design)是制造嵌入式系统所关注的甚至在面对内部或者外部问题时可靠系统设计经常假设问题是非恶意引起的

安全重要的系统设计 (Safety-critical system design)研究确保系统安全操作的方法独立于引起问题的原因

保密性 (Security)主要关注恶意攻击

Aizientis等人描述了可信性和保密性间的关系可信性和保密性由几个特性所组成

服务的可用性 (Availability) 服务的连续性 (Continuity) 来自用户和所处环境的灾难性后果的安全性 (Safety) 来自不合适系统改变的完整性 (Integrity) 通过更改和修补的可维护性 (Maintainability) 信息的机密性 (Confidentiality)

可用性完整性

可靠性安全性可维护性

机密性

可信性 保密性

5 新型攻击和对策1 )物理攻击嵌入式系统比通用计算机更容易受攻击 一个关键原因是许多嵌入式计算机对攻击者可物理访问

2 )互联网攻击一些嵌入式系统的攻击通过互联网访问变得更加容易今天许多嵌入式系统连接到互联网

3 )电池攻击 (battery attack)这种攻击试图通过耗尽电池来关闭节点

4 )服务拒绝攻击 (Denial-of-service attacks)

在通用系统中众所周知但是实时嵌入式系统可能更容易受服务质量 (quality-of-service (QoS))攻击如果网络发布实时数据那么发送过程中的一点延迟都能引起数据无效如果那些数据用来实时控制那么这些短暂延迟就能引起系统故障我们称这种危害为时间攻击因为它改变了系统的实时特性

QoS或者时间攻击之所以强大使因为它的影响不仅仅限于信息被控制系统的动态特性可决定系统的响应如果一个大型沉重快速运动的系统被控制那么时间上一个相对小的改变能引起大量的破坏

5 )网络(协议)攻击Wood和 Stankovic[Woo02]在传感器网络上确定了一些方式这些方式可在网络层次的不同层执行拒绝服务攻击如下所列

物理层 (Physical layer)mdashmdash拥塞破坏 链路层 (Link layer)mdashmdash碰撞耗尽非公平

网络和路由层 (Network and routing layer)mdashmdash丢弃和贪婪汇集方向误导黑洞认证监视冗余

传输层 (Transport layer)mdashmdash泛洪失步

6 )能量攻击Kocher等人 [Koc99]指出测量一个 CPU当前的能量供给能在很大程度上确定处理器的内部活动他们提出了两种能量攻击的方法简单能量分析 (simple power analysis)人工地跟踪检查和尝试确定程序作用的位置比如分支基于不同 CUP操作的能耗知识基于程序作用攻击者然后减少密钥的比特差分能量分析 (Differential power analysis)用相关性确定作用和密钥比特这种攻击最初目标是智能卡这种卡从外部读卡器获取能量但是这种攻击也能应用到许多嵌入式系统中

7 )反攻击 在一些时候有可能构造反破坏的嵌入式系统使电子设备难以发觉和分析延缓了攻击者芯片中有限的信息也有助阻止攻击者发现数据

6 Efficiency (效率)

ES must be efficient

bull Code-size efficient( 特别是片上系统 )

bull Run-time efficient

bull Weight efficient

bull Cost efficient

bull Energy efficient

能量有效性的重要意义

ldquoinherent power

efficiency of siliconldquo

59

低功耗设计问题 功耗问题是近几年来人们在嵌入式系统的设计中普遍关注的难点和热点它严重地制约着嵌入式系统的应用与发展

无论是在军事还是在商业贸易上的应用相当数量的嵌入式系统一般是由电池来供给电能的而且大多数嵌入式设备都有体积和质量的约束减少电能消耗不仅能延长电池的使用寿命延长用户更换电池的周期而且能带来提高系统性能与降低系统开销的好处甚至能起到保护环境的作用在便携式设备中 CPU消耗的电能越少电池的寿命就越长同时散发的热量少了所需的散热器就少了从而可减少该设备的花费和体积使产品尽快进入市场的目标

1 低功耗嵌入式应用系统是指以降低系统功耗为一个主要性能指标的嵌入式系统如计算机里的许多芯片过去用 5V供电现在用 33V 18V 并提出了绿色电器的概念

60

低功耗设备的要求1 )首先要求体积小重量轻便于携带2 )采用低功耗电路的设计方法以降低系统的功耗

它除了选用各种低功耗的器件和芯片外还在满足速度等性能指标的前提下进行降低功耗的硬件电路设计和软件设计

3 )有的系统应用在交流供电比较困难甚至无法用交流供电的场合因而各种电池(瓶)就成为其主要供电手段

4 )采用 LCD液晶显示器5 )采用 RS232C串行通信接口6 )采用微功耗高抗干扰的 CMOS集成电路

功耗产生的原因 P=UI

与功耗有关的因素

( 1 )电阻上消耗的功率( 2 )有源器件的开关转换阶段( 3 )集成电路内部和外部电容的充放电( 4 )系统的性能指标负载能力被处理信号的工作频率电路的工作频率电源的管理水平零部件的性能散热条件接口的物理性能等对系统功耗起着重要的作用

降低功耗的措施

功耗的组成动态 + 静态动态电源管理动态电压缩放低功耗硬件设计低功耗软件设计

二设计方法学概论

问题功 能 性能要求价 格 开发 周 期 等约束

设计 选择 折衷 分析比较 计算 评价

嵌入式系统

0嵌入式系统设计概述

方法 工具

设计方法论( design methodology )

设计方法论有以下三个重要理由1 )确认我们所做的每一件事情都是必须要作的

不会做无谓的白工也不会漏掉关键性的重要工作其中包含效率优化或是功能测试

2 )可以发展出计算机辅助工具或是设计经验累积汲取每一次产品发展的经验再经过量化之后可以发展出一套工具或是方法让往后的产品设计步入自动化

3 )开发团队遵循同一套方法论可以让团队成员更容易彼此沟通每个人都能在短时间内了解整体过程中将经历哪些过程需要何种支持与接收到何种结果此外也容易透过一套已经定义好的方法论彼此相互合作协调

设计目标 1 )上市时间

也就是 time-to-market 的观念2 )设计成本

许多消费性产品对于价格非常敏感所以产品厂商对于成本会斤斤计较是很合理的

3 )品质 顾客也许不需要最快最便宜的产品但是一定会要求功能质量保证不能只用一小段时间就坏掉了

传统的设计主要步骤

2 传统的设计流程方法1 )瀑布模型 (Waterfall)2 )螺旋模型 (Spiral)3 )连续改进 (Successive Refinement)4 )硬件与软件的同步设计 (SWHW Co-

deign)5 )阶层式 (Hierarchical) 设计6 )同步工程( concurrent

engineering )

瀑布模型 (Waterfall)

螺旋模型 (Spiral)

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 4: 大学计算机基础 —— 计算机科学概论

1 一类嵌入式系统硬件是一个闭环系统

cyber-physical systems

2 嵌入式系统中计算的基本问题

体系结构

方法学

应用特点规范参考设计

建模分析和仿真性 能 功 率 成本

协同验证

硬件体系结构CPUs 协同设计 多 处 理 器 网络

软件体系结构处 理 调 度 分配

问题 1mdashmdash体系结构(architectures)

硬件体系结构 CPUs协同设计多处理器网络软件体系结构 处理调度分配中间件人机交互 硬件软件及其二者之间的关系

问题 2mdashmdash方法学(methodologies)

建模分析形式化仿真性能功率能耗成本价格协同验证方法学中的步骤靠工具来执行

问题 3mdashmdash应用(applications)

特点规范参考设计 理解你的应用是获得嵌入式计算系统最大性能的关键我们可以根据应用的特点去优化设计这个优势可以使我们执行许多有效的优化而这在通用系统中是不可能的但是这也意味着我们必须对应用的特点有足够的认识这样才能在利用特点的同时避免在系统实现过程中产生问题

面向应用的计算( SmartApps An Application Centric Approach to High Performance Computing )

Today System Centric Computing

Application(Algorithm)

Compiler(static)

System(OS amp Arch)

HWOS

CompilerApplication

System-Centric Computing

Development entAnalysis amp

Optimization

Execution

Input Data

Classic Avenues toperformance

Parallel Algorithms Static Compiler Optimization OS support Good Architecture

Whatrsquos missing Compiler are conservative OS offers generic services Architecture is generic

No Global Optimization No matching between ApplicationOSHW Intractable for the general case

SmartApps Application Centric Computing

Application ControlInstance-specific optimization

Compiler + OS + Architecture + Data + Feedback

Application(Algorithm)

Development entAnalysis amp

Optimization

Compiler (static) +run-time techniques

Compiler(run-time)

OS(modular)

Architecture(reconfigurable)

SmartAppApplication

CompilerOS

HW

Run-time SystemExecution Analysis

amp Optimization

Application-Centric Computing

Input Data

Smart Application

SmartApps Architecture

Get Runtime Information(sample input system information etc)

Static CompilerAugmented withruntime techniques

Predictor ampOptimizer

partially compiledcode with unknownsand runtime hooks

Information forrapid simulation

Compute Optimal Applicationand System Configuration

Recompile Applicationandor Reconfigure System

Predictor ampEvaluator

Configurer

Application

Execute Application

Continuous monitorperformance and adaptas necessary

Predictor ampEvaluator

Predictor ampOptimizer

Adaptive Software

Runtime tuning (worecompile or reconfigure)

Small adaptation (tuning)

Large adaptation(failure phase change)

3 Real-time 约束许多 ES 必须满足实时约束什么是实时系统 实时系统是将时间定量化的一个概念实时系统是使用物理时钟来衡

量的当我们使用物理时钟来量化时间时我们就会讨论到实时的概念

与实时相反逻辑时间(也称为虚拟时间)是对时间的一种定性的概念通过使用事件顺序关系来表示例如之前之后某个时候最后在hellip之前接着等等

定义一个系统称为实时系统当我们需要用定量的时间表达式(也就是说实时)来描述这个系统的行为在这个实时系统的定义中隐含的表达了所有的定量的时间度量都是用一个物理时钟测量得到的

任何一个行为可以完全不用任何定量时间表达来描述其行为的系统肯定不是实时系统但一个系统的完整行为可以用它对各种外部刺激的响应列表来描述也就是说一个系统的行为大部分描述根本没有定量的时间表达式仍然被认为是一个实时系统

实时系统的类型根据任务超过截止时间的后果实时系统可以分为 硬实时软实时固实时1 )硬实时当系统执行任务时被强制要求在某个时间范围内要

产生结果换句话说任何时刻硬实时任务没有在制定的时间范围内产生要求的结果那这个系统就被认为失败了

2 )固实时当系统执行任务时与某些预设的截止时间相关联任务要求要在截止时间之前完成结果的计算不同于硬实时任务就算一个固实时任务没有在截止时间之前完成系统也不会失败迟来的结果仅仅是被丢弃了

3 )软实时当系统执行任务时也有与之相关联的时间界限但是不像硬实时和固实时任务软实时任务的时间界限并不是以绝对数值来表示的取而代之的是平均响应时间

Real-Time 系统与嵌入式系统

Embedded and Real-

Time 往往同义 Most embedded

systems are real-time

Most real-time systems are embedded

embeddedembedded

real-timereal-time

embedded embedded real-timereal-time

4 反应系统ES 是一个反应系统 转换系统输入(开始) -gt 软件系统(经过一段时间后停止运行) -gt (然后)输

出即用户把数据输入给计算机软件对这些数据经过一段时间的计算最后给出输出结果

输入数据经过特定的规则被转换并且在结束计算过程以后给出结果 而 reactive system 却与此相反在 reactive system 里往往没有明确的时序安排总体来讲

reactive system 表示的是不限制运行时间的系统这其中要和外部环境相互作用也就是在外部刺激上的反应 (reactive) 例如和不同使用者或者外部的硬件等但是也包括内部发生的交流行为因为 reactive system 是被集成在并行运行的分布式系统的规则中的例如一个计算机的操作系统是这样一个 reactive system 它不会停止运行 而总是反应用户给的输入 并且计算机中的各个组件之间要进行交流

在电信领域生产控制或者在硬件环境的构造(嵌入式系统)中还存在很多这样的例子在信息系统中也就是基于数据库的应用系统中也要用到 reactive system 在给一个典型的例子就是警报系统

5 混成系统Hybrid systems(analog + digital parts)混成系统一般由离散分立组件和连续组件并行或者串

行组成组件之间的行为由计算模型进行控制由于大多数复杂控制系统都包含了由连续变量所描述的物理层的动态演化过程和以符号操作与离散监控决策为特征的高层协调优化过程因此混成系统在工业控制和国防等领域大量存在混成系统定义凡是系统自身具有混合结构并且其

行为(输出和状态)取决于离散事件系统和连续动态系统相互作用的动态系统就称为混成系统

混成系统的典型特征( 1) 系统内存在着性质不同的连续和离散两类变量( 2) 时间和事件共同驱动系统的状态演化 ( 3)连续变量穿越阈值使状态使能或失能 ( 4)离散状态的变化改变连续变量遵循的变化速率 ( 5)离散事件发生在离散时刻 具有顺序选择并发等特色

( 6)状态呈阶段性间歇性切换变化 动态特征显著 ( 7) 对系统的控制表现为对连续状态和离散状态的集成控制 ( 8) 对系统的优化表现为在定性 定量双重指标下的集成优化

6 专用系统 Dedicated towards a certain

applicationKnowledge about behavior at design time can be used to minimize resources and to maximize robustness

Dedicated user interface(no mouse keyboard and screen)

二设计的挑战 实时可信可靠保密安全

1 为什么需要可靠的嵌入式系统1 )许多市场不需要高度可靠的嵌入式计算机但是许多嵌入式计算机必须

是高度可靠的2 )许多嵌入式计算机必须是高度可靠的汽车电子航空电子医疗设备

关键通信3 )可靠性的定义如电话交换机系统每年停机少于 30秒4 )关于可靠数字系统设计的研究几十年前就有不同的体系结构和方法学

被开发用于长周期低失误率的数字系统操作那么传统的可靠计算机和可靠的计算机系统有什么不同呢

5 )可靠嵌入式计算机通常是分布式系统如汽车电子航空电子和医疗设备都是必须高度可靠的分布式嵌入式系统

6 )嵌入式计算机容易受许多新类型攻击可靠计算机传统上是物理上不可访问的服务器或者机器mdashmdash物理安全长期以来是计算机安全的安全策略但是嵌入式计算机通常在非保护环境下操作这就允许新的故障和攻击这些需要都新的保护措施

2 可靠与可信ES 必需是可靠的可信的如何评价与度量

bull可靠性( Reliability) R(t)

bull可维护性( Maintainability) M(d)

bull有效性( Availability ) A(t)

bull安全性( Safety )bull保密性( Security )

可靠性定义可靠性 R(t) 产品在规定条件下和规定时间内完成规定

功能的能力产品可靠性定义的要素是三个ldquo规定rdquo 1 )ldquo规定条件rdquo包括使用时的环境条件

和工作条件2 )ldquo规定时间rdquo是指产品规定了的任务

时间3 )ldquo规定功能rdquo是指产品规定了的必须

具备的功能及其技术指标

1 )ldquo规定条件rdquo包括使用时的环境条件和工作条件 例如同一型号的汽车在高速公路和在崎岖的山路上行驶其可

靠性的表现就不大一样要谈论产品的可靠性必须指明规定的条件是什么2 )ldquo规定时间rdquo是指产品规定了的任务时间 随着产品任务时间的增加产品出现故障的概率将增加

而产品的可靠性将是下降的因此谈论产品的可靠性离不开规定的任务时间例如一辆汽车在在刚刚开出厂子和用了5 年后相比它出故障的概率显然大了很多

3 )ldquo规定功能rdquo是指产品规定了的必须具备的功能及其技术指标所要求产品功能的多少和其技术指标的高低直接影响到产品可靠性指标的高低

例如电风扇的主要功能有转叶摇头定时那么规定的功能是三者都要还是仅需要转叶能转能够吹风所得出的可靠性指标是大不一样的

可维护性 M(d)1 )计算机系统的可维护性是指该系统失效后在规定时间内可

修复到规定功能的能力2 )反映系统可维护性高低的参数是修复率秒平均修复时间3 )软件可维护性即维护人员对该软件进行维护的难易程度

具体包括理解改正改动和改进该软件的难易程度4 )决定可维护性的因素

系统的大小系统的年龄结构合理性

5 )可维护性的度量 可理解性可测试性可修改性可移植性

有效性 A(t)设备的有效性的表式为 设备有效性 = 平均故障间隔期 (平均故障间隔期+平均修理时间)

在逻辑中如果一个论证不能从真前提中得出假结论 则论证的形式是完全有效的

一个论证若被称为是有效的则如果在其中所有前提都为真的每个模型中结论也是真的

例如ldquo所有 A 是 B 有些 A 是 C 所以有些 B 是Crdquo 是有效形式

可用性 实用性

3 可靠系统设计的基本原理1 )故障 (faults) 分析2 )可靠性分析3 )纠错技术4 )软件可靠性

1 )故障 (faults) 分析永久 (permanent) 与暂时( transient )故障故障来源 物理故障 (Physical faults)由生产缺陷辐射危害等等引起

设计故障 (Design faults) 是不合适设计的系统的结果

操作故障 (Operational faults) 来自人为过失安全破坏劣质设计的人机接口等等

可靠性设计

故障及其分类 产品的故障按其故障规律分为两大类

偶然故障 渐变故障

产品的故障按其故障后果分为两大类 致命性故障 非致命性故障

产品的故障按其统计特性分为两大类 独立故障 从属故障

可靠度 产品在规定的条件下和规定的时间内完成规

定功能的概率称为可靠度依定义可知系统的可靠度是时间的函数表示为

式中 R(t)mdashmdash 可靠度函数 ξmdashmdash 产生故障前的工作时间 t mdashmdash 规定的时间

)()( tPtR

2 )可靠性的分析mdashmdash可靠度

可靠度函数

依定义可知可靠度函数 R(t) 为

式中 N0 mdashmdash t = 0 时在规定条件下进行工作的产品数

r(t) mdashmdash  在 0 到 t 时刻的工作时间内产品的累计

故障数

0

0 )()(

N

trNtR

累积故障分布函数 产品在规定的条件下和规定的时间内丧失

规定功能的概率称为累积故障概率(又叫不可靠度) 依定义可知产品的累积故障概率是时间的函

数即

显然以下关系成立

0

)()(

N

trtF

1)()( tFtR

可靠度函数与累积故障分布函数的性质

图 R(t)F(t)与f(t)的关系t

f(t)

f(t)

F(to)

R(to)

to

由密度函数的性质 1)(0

dttf 可知

t

tdttfdttftFtR )()(1)(1)(

0

因此 R(t) F(t) 与 f(t) 之间的关系如图所示

故障率函数 故障率

工作到某时刻尚未发生故障的产品在该时刻后单位时间内发生故障的概率称之为产品的故障率

用数学符号表示为

式中 (t) mdashmdash 故障率 dr(t) mdashmdash t 时刻后 dt 时间内故障的产品数 Ns(t) mdashmdash 残存产品数即到 t 时刻尚未故障的产品

dttN

tdrt

s )(

)()(

35

故障率函数

可按下式进行工程计算

式中 Δr(t) mdashmdash t 时刻后 Δt 时间内故障的产品数

Δt mdashmdash 所取时间间隔 Ns(t) mdashmdash 残存产品数

对于低故障率的元部件常以 10-9h 为故障率的单位称之为菲特( Fit )

ttN

trt

s

)(

)()(

产品故障浴盆曲线 浴盆曲线

大多数产品的故障率随时间的变化曲线形似浴盆称之为浴盆曲线由于产品故障机理的不同产品的故障率随时间的变化大致可以分为三个阶段

产品典型的故障率曲线

t

使用寿命

早期故障

偶然故障 耗损故障

A B规定的故障率 维修后故障率下降

(t)

3 )纠错技术( 1 )纠错码 在 1950s就开始研究最早的是可以检测和纠错的汉明码它们通过数字系统广泛地用于识别和纠正短暂或者持久的错误这些码引入冗余信息来确保一些类型的错误可以被检测和纠正比如一个单错校正 双错校正的码能用一个比特检测和纠正一个错误但是不能用两个比特纠错

( 2 )三模冗余 (triple modular

redundancy) 计算单元 C 有三个副本 C1C2和 C3三个单元接收同

样的输入一个独立单元比较每个输入的结果如果至少两个结果一致那么那个值被表决器选做正确结果如果三个结果都不相同那么就没有正确的结果

1C

2C

3C

表决错误

结果

输入

( 3 )看门狗定时器 (watchdog timer)

看门狗定时器 (watchdog timer)被广泛地用于检测系统问题如图 看门狗定时器连接到一个监视系统如果这个看门狗定时器翻转它产生一个完成信号用于标注系统的错误中断系统应该这样设计当适当运行的时候它一直在可能产生翻转信号之前复位定时器因此来自看门狗定时器的完成信号指示系统在一定程度上不合适地操作看门狗定时器用于预防不同的故障

系统看门狗定时器

完成

复位

( 4 )设计多样性 (Design diversity)

一种用于减少一些系统错误进入设计的设计方法学当一个设计需要给定模块的不同实例应该采用模块的不同实现而不是到处都用同一种模块比如一个有多个 CPU的系统可能采用不同类型的 CPU而不是到处采用同一种类型的 CPU在一个三模冗余系统产生表决结构的组件可能有不同的实现这样可以减少产生同样设计错误的机会

4 )软件可靠性ldquo在规定的条件下在规定的时间内软件不引起失效的概率rdquo

规定的条件 软件运行的软硬件环境 软件操作剖面软件运行的输入空间及其概率分布

规定的时间 日历时间 时钟时间 执行时间

激活软件 输入域 缺陷的数据

软件缺陷 软件

不可接受的结果 (软件故障) 输出域

软件故障的特点

软件与硬件可靠性的区别硬件 软件

故障机理 老化损耗 残留缺陷在一定环境下造成的软件错误

复杂性 内部逻辑较为简单 内部逻辑高度复杂这就在很大程度上决定了设计错误是导致软件故障的主要原因

唯一性 任何两个硬件不可能绝对相同

软件是唯一的软件拷贝不改变软件本身

可靠性的核心 内部元部件 设计者的思维和软件的复杂性纠错维护方法 修复或更换失效的元部件 重设计 可靠性检验标准化

已标准化且有一整套完整的理论

仍未建立更没有完整的理论体系

产品市场 已有成熟的产品市场 产品市场还很新 错误性质 一些瞬间的硬件错误可能

会被误认为是软件错误 软件错误是永恒的可重现的

影响软件可靠性的因素( 1 )运行环境 ( 剖面 )

同一软件在不同运行剖面下其可靠性行为可能极不相同 软件故障是软件缺陷在一定输入情况下被激活的结果 假设软件输入域划分为两个部分 G 和 F 运行剖面不包含 F 中

的输入则软件不会出现故障其可靠性恒为 l 反之如果运行剖面不包含 G 中的输入则每一输入情况下均出现故障如果没有容错措施则 R=0

( 2 )软件规模 随着软件规模的增大软件可靠性问题愈显突出在我们考虑软件

可靠性问题时软件一般是指中型以上软件 (4000-5000条以上语句 ) 这时可靠性问题难以对付

软件工程实践的一个侧面可以反映这一点即单元测试一般由编程人员本人进行而综合测试则需独立的测试人员

影响软件可靠性的因素( 3 )软件内部结构

结构越复杂软件复杂度越高内含缺陷数越大因而软件可靠度越低

( 4 )软件可靠性设计技术 一般是指软件设计阶段中采用的用以保证和提高软件可靠性为主要目标的软件技术

( 5 )软件可靠性测试 研究表明软件测试方法与资源投入对软件可靠性有不可忽视的影

响( 6 )软件可靠性管理

软件可靠性管理旨在系统管理软件生存期各阶段的可靠性活动使之系统化规范化一体化这样就可以避免许多人为错误以提高软件可靠性

影响软件可靠性的因素( 7 )软件开发人员能力和经验

软件开发人员 ( 包括测试人员 ) 的能力愈强经验愈丰富所犯错误便可能愈少所得软件产品质量愈高相应的可靠性也愈高

( 8 )软件开发方法 软件工程表明开发方法对软件可靠性有显著影响 与非结构化方法比较结构化方法可以明显减少软件缺陷数

( 9 )软件开发环境 研究表明程序语言软件开发环境影响软件的可靠性而软件测

试工具的优劣则影响可靠性测试结果

4 安全 (Safety)amp保密 (Security)

安全 (Safety) 是保证财产和人身受到损害可靠性是指在一定的环境条件下以及一定的时间内系统完成特定任务的可能性而有效性则是系统的长期的工作时间于其存在时间 ( 简单的定义为运行时间 +维护时间 ) 的 比例保密 (Security) 是针对危险破坏损失或非法活动而进行措施在一定层面上保密 (Security)要比安全 (Safety)宽广的多例如信息 Security家庭 Security 网络 Security 国家Security) 等

Security强调的是外在事物对特定目标的危害

Safety 是系统本身的潜在危害

四个概念的比较分析安全 (Safety)可靠性 (Reliability)有效性 (Availability)保密 (Security )安全 (Safety)高的系统 软件可靠性不

一定高可靠性和有效性并不是一码事保密 (Security )的系统 软件是安全

(Safety) 系统 软件的重要保障

可靠性安全性保密性 可靠(或可信)系统设计 (Reliable (or dependable) system design)是制造嵌入式系统所关注的甚至在面对内部或者外部问题时可靠系统设计经常假设问题是非恶意引起的

安全重要的系统设计 (Safety-critical system design)研究确保系统安全操作的方法独立于引起问题的原因

保密性 (Security)主要关注恶意攻击

Aizientis等人描述了可信性和保密性间的关系可信性和保密性由几个特性所组成

服务的可用性 (Availability) 服务的连续性 (Continuity) 来自用户和所处环境的灾难性后果的安全性 (Safety) 来自不合适系统改变的完整性 (Integrity) 通过更改和修补的可维护性 (Maintainability) 信息的机密性 (Confidentiality)

可用性完整性

可靠性安全性可维护性

机密性

可信性 保密性

5 新型攻击和对策1 )物理攻击嵌入式系统比通用计算机更容易受攻击 一个关键原因是许多嵌入式计算机对攻击者可物理访问

2 )互联网攻击一些嵌入式系统的攻击通过互联网访问变得更加容易今天许多嵌入式系统连接到互联网

3 )电池攻击 (battery attack)这种攻击试图通过耗尽电池来关闭节点

4 )服务拒绝攻击 (Denial-of-service attacks)

在通用系统中众所周知但是实时嵌入式系统可能更容易受服务质量 (quality-of-service (QoS))攻击如果网络发布实时数据那么发送过程中的一点延迟都能引起数据无效如果那些数据用来实时控制那么这些短暂延迟就能引起系统故障我们称这种危害为时间攻击因为它改变了系统的实时特性

QoS或者时间攻击之所以强大使因为它的影响不仅仅限于信息被控制系统的动态特性可决定系统的响应如果一个大型沉重快速运动的系统被控制那么时间上一个相对小的改变能引起大量的破坏

5 )网络(协议)攻击Wood和 Stankovic[Woo02]在传感器网络上确定了一些方式这些方式可在网络层次的不同层执行拒绝服务攻击如下所列

物理层 (Physical layer)mdashmdash拥塞破坏 链路层 (Link layer)mdashmdash碰撞耗尽非公平

网络和路由层 (Network and routing layer)mdashmdash丢弃和贪婪汇集方向误导黑洞认证监视冗余

传输层 (Transport layer)mdashmdash泛洪失步

6 )能量攻击Kocher等人 [Koc99]指出测量一个 CPU当前的能量供给能在很大程度上确定处理器的内部活动他们提出了两种能量攻击的方法简单能量分析 (simple power analysis)人工地跟踪检查和尝试确定程序作用的位置比如分支基于不同 CUP操作的能耗知识基于程序作用攻击者然后减少密钥的比特差分能量分析 (Differential power analysis)用相关性确定作用和密钥比特这种攻击最初目标是智能卡这种卡从外部读卡器获取能量但是这种攻击也能应用到许多嵌入式系统中

7 )反攻击 在一些时候有可能构造反破坏的嵌入式系统使电子设备难以发觉和分析延缓了攻击者芯片中有限的信息也有助阻止攻击者发现数据

6 Efficiency (效率)

ES must be efficient

bull Code-size efficient( 特别是片上系统 )

bull Run-time efficient

bull Weight efficient

bull Cost efficient

bull Energy efficient

能量有效性的重要意义

ldquoinherent power

efficiency of siliconldquo

59

低功耗设计问题 功耗问题是近几年来人们在嵌入式系统的设计中普遍关注的难点和热点它严重地制约着嵌入式系统的应用与发展

无论是在军事还是在商业贸易上的应用相当数量的嵌入式系统一般是由电池来供给电能的而且大多数嵌入式设备都有体积和质量的约束减少电能消耗不仅能延长电池的使用寿命延长用户更换电池的周期而且能带来提高系统性能与降低系统开销的好处甚至能起到保护环境的作用在便携式设备中 CPU消耗的电能越少电池的寿命就越长同时散发的热量少了所需的散热器就少了从而可减少该设备的花费和体积使产品尽快进入市场的目标

1 低功耗嵌入式应用系统是指以降低系统功耗为一个主要性能指标的嵌入式系统如计算机里的许多芯片过去用 5V供电现在用 33V 18V 并提出了绿色电器的概念

60

低功耗设备的要求1 )首先要求体积小重量轻便于携带2 )采用低功耗电路的设计方法以降低系统的功耗

它除了选用各种低功耗的器件和芯片外还在满足速度等性能指标的前提下进行降低功耗的硬件电路设计和软件设计

3 )有的系统应用在交流供电比较困难甚至无法用交流供电的场合因而各种电池(瓶)就成为其主要供电手段

4 )采用 LCD液晶显示器5 )采用 RS232C串行通信接口6 )采用微功耗高抗干扰的 CMOS集成电路

功耗产生的原因 P=UI

与功耗有关的因素

( 1 )电阻上消耗的功率( 2 )有源器件的开关转换阶段( 3 )集成电路内部和外部电容的充放电( 4 )系统的性能指标负载能力被处理信号的工作频率电路的工作频率电源的管理水平零部件的性能散热条件接口的物理性能等对系统功耗起着重要的作用

降低功耗的措施

功耗的组成动态 + 静态动态电源管理动态电压缩放低功耗硬件设计低功耗软件设计

二设计方法学概论

问题功 能 性能要求价 格 开发 周 期 等约束

设计 选择 折衷 分析比较 计算 评价

嵌入式系统

0嵌入式系统设计概述

方法 工具

设计方法论( design methodology )

设计方法论有以下三个重要理由1 )确认我们所做的每一件事情都是必须要作的

不会做无谓的白工也不会漏掉关键性的重要工作其中包含效率优化或是功能测试

2 )可以发展出计算机辅助工具或是设计经验累积汲取每一次产品发展的经验再经过量化之后可以发展出一套工具或是方法让往后的产品设计步入自动化

3 )开发团队遵循同一套方法论可以让团队成员更容易彼此沟通每个人都能在短时间内了解整体过程中将经历哪些过程需要何种支持与接收到何种结果此外也容易透过一套已经定义好的方法论彼此相互合作协调

设计目标 1 )上市时间

也就是 time-to-market 的观念2 )设计成本

许多消费性产品对于价格非常敏感所以产品厂商对于成本会斤斤计较是很合理的

3 )品质 顾客也许不需要最快最便宜的产品但是一定会要求功能质量保证不能只用一小段时间就坏掉了

传统的设计主要步骤

2 传统的设计流程方法1 )瀑布模型 (Waterfall)2 )螺旋模型 (Spiral)3 )连续改进 (Successive Refinement)4 )硬件与软件的同步设计 (SWHW Co-

deign)5 )阶层式 (Hierarchical) 设计6 )同步工程( concurrent

engineering )

瀑布模型 (Waterfall)

螺旋模型 (Spiral)

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 5: 大学计算机基础 —— 计算机科学概论

2 嵌入式系统中计算的基本问题

体系结构

方法学

应用特点规范参考设计

建模分析和仿真性 能 功 率 成本

协同验证

硬件体系结构CPUs 协同设计 多 处 理 器 网络

软件体系结构处 理 调 度 分配

问题 1mdashmdash体系结构(architectures)

硬件体系结构 CPUs协同设计多处理器网络软件体系结构 处理调度分配中间件人机交互 硬件软件及其二者之间的关系

问题 2mdashmdash方法学(methodologies)

建模分析形式化仿真性能功率能耗成本价格协同验证方法学中的步骤靠工具来执行

问题 3mdashmdash应用(applications)

特点规范参考设计 理解你的应用是获得嵌入式计算系统最大性能的关键我们可以根据应用的特点去优化设计这个优势可以使我们执行许多有效的优化而这在通用系统中是不可能的但是这也意味着我们必须对应用的特点有足够的认识这样才能在利用特点的同时避免在系统实现过程中产生问题

面向应用的计算( SmartApps An Application Centric Approach to High Performance Computing )

Today System Centric Computing

Application(Algorithm)

Compiler(static)

System(OS amp Arch)

HWOS

CompilerApplication

System-Centric Computing

Development entAnalysis amp

Optimization

Execution

Input Data

Classic Avenues toperformance

Parallel Algorithms Static Compiler Optimization OS support Good Architecture

Whatrsquos missing Compiler are conservative OS offers generic services Architecture is generic

No Global Optimization No matching between ApplicationOSHW Intractable for the general case

SmartApps Application Centric Computing

Application ControlInstance-specific optimization

Compiler + OS + Architecture + Data + Feedback

Application(Algorithm)

Development entAnalysis amp

Optimization

Compiler (static) +run-time techniques

Compiler(run-time)

OS(modular)

Architecture(reconfigurable)

SmartAppApplication

CompilerOS

HW

Run-time SystemExecution Analysis

amp Optimization

Application-Centric Computing

Input Data

Smart Application

SmartApps Architecture

Get Runtime Information(sample input system information etc)

Static CompilerAugmented withruntime techniques

Predictor ampOptimizer

partially compiledcode with unknownsand runtime hooks

Information forrapid simulation

Compute Optimal Applicationand System Configuration

Recompile Applicationandor Reconfigure System

Predictor ampEvaluator

Configurer

Application

Execute Application

Continuous monitorperformance and adaptas necessary

Predictor ampEvaluator

Predictor ampOptimizer

Adaptive Software

Runtime tuning (worecompile or reconfigure)

Small adaptation (tuning)

Large adaptation(failure phase change)

3 Real-time 约束许多 ES 必须满足实时约束什么是实时系统 实时系统是将时间定量化的一个概念实时系统是使用物理时钟来衡

量的当我们使用物理时钟来量化时间时我们就会讨论到实时的概念

与实时相反逻辑时间(也称为虚拟时间)是对时间的一种定性的概念通过使用事件顺序关系来表示例如之前之后某个时候最后在hellip之前接着等等

定义一个系统称为实时系统当我们需要用定量的时间表达式(也就是说实时)来描述这个系统的行为在这个实时系统的定义中隐含的表达了所有的定量的时间度量都是用一个物理时钟测量得到的

任何一个行为可以完全不用任何定量时间表达来描述其行为的系统肯定不是实时系统但一个系统的完整行为可以用它对各种外部刺激的响应列表来描述也就是说一个系统的行为大部分描述根本没有定量的时间表达式仍然被认为是一个实时系统

实时系统的类型根据任务超过截止时间的后果实时系统可以分为 硬实时软实时固实时1 )硬实时当系统执行任务时被强制要求在某个时间范围内要

产生结果换句话说任何时刻硬实时任务没有在制定的时间范围内产生要求的结果那这个系统就被认为失败了

2 )固实时当系统执行任务时与某些预设的截止时间相关联任务要求要在截止时间之前完成结果的计算不同于硬实时任务就算一个固实时任务没有在截止时间之前完成系统也不会失败迟来的结果仅仅是被丢弃了

3 )软实时当系统执行任务时也有与之相关联的时间界限但是不像硬实时和固实时任务软实时任务的时间界限并不是以绝对数值来表示的取而代之的是平均响应时间

Real-Time 系统与嵌入式系统

Embedded and Real-

Time 往往同义 Most embedded

systems are real-time

Most real-time systems are embedded

embeddedembedded

real-timereal-time

embedded embedded real-timereal-time

4 反应系统ES 是一个反应系统 转换系统输入(开始) -gt 软件系统(经过一段时间后停止运行) -gt (然后)输

出即用户把数据输入给计算机软件对这些数据经过一段时间的计算最后给出输出结果

输入数据经过特定的规则被转换并且在结束计算过程以后给出结果 而 reactive system 却与此相反在 reactive system 里往往没有明确的时序安排总体来讲

reactive system 表示的是不限制运行时间的系统这其中要和外部环境相互作用也就是在外部刺激上的反应 (reactive) 例如和不同使用者或者外部的硬件等但是也包括内部发生的交流行为因为 reactive system 是被集成在并行运行的分布式系统的规则中的例如一个计算机的操作系统是这样一个 reactive system 它不会停止运行 而总是反应用户给的输入 并且计算机中的各个组件之间要进行交流

在电信领域生产控制或者在硬件环境的构造(嵌入式系统)中还存在很多这样的例子在信息系统中也就是基于数据库的应用系统中也要用到 reactive system 在给一个典型的例子就是警报系统

5 混成系统Hybrid systems(analog + digital parts)混成系统一般由离散分立组件和连续组件并行或者串

行组成组件之间的行为由计算模型进行控制由于大多数复杂控制系统都包含了由连续变量所描述的物理层的动态演化过程和以符号操作与离散监控决策为特征的高层协调优化过程因此混成系统在工业控制和国防等领域大量存在混成系统定义凡是系统自身具有混合结构并且其

行为(输出和状态)取决于离散事件系统和连续动态系统相互作用的动态系统就称为混成系统

混成系统的典型特征( 1) 系统内存在着性质不同的连续和离散两类变量( 2) 时间和事件共同驱动系统的状态演化 ( 3)连续变量穿越阈值使状态使能或失能 ( 4)离散状态的变化改变连续变量遵循的变化速率 ( 5)离散事件发生在离散时刻 具有顺序选择并发等特色

( 6)状态呈阶段性间歇性切换变化 动态特征显著 ( 7) 对系统的控制表现为对连续状态和离散状态的集成控制 ( 8) 对系统的优化表现为在定性 定量双重指标下的集成优化

6 专用系统 Dedicated towards a certain

applicationKnowledge about behavior at design time can be used to minimize resources and to maximize robustness

Dedicated user interface(no mouse keyboard and screen)

二设计的挑战 实时可信可靠保密安全

1 为什么需要可靠的嵌入式系统1 )许多市场不需要高度可靠的嵌入式计算机但是许多嵌入式计算机必须

是高度可靠的2 )许多嵌入式计算机必须是高度可靠的汽车电子航空电子医疗设备

关键通信3 )可靠性的定义如电话交换机系统每年停机少于 30秒4 )关于可靠数字系统设计的研究几十年前就有不同的体系结构和方法学

被开发用于长周期低失误率的数字系统操作那么传统的可靠计算机和可靠的计算机系统有什么不同呢

5 )可靠嵌入式计算机通常是分布式系统如汽车电子航空电子和医疗设备都是必须高度可靠的分布式嵌入式系统

6 )嵌入式计算机容易受许多新类型攻击可靠计算机传统上是物理上不可访问的服务器或者机器mdashmdash物理安全长期以来是计算机安全的安全策略但是嵌入式计算机通常在非保护环境下操作这就允许新的故障和攻击这些需要都新的保护措施

2 可靠与可信ES 必需是可靠的可信的如何评价与度量

bull可靠性( Reliability) R(t)

bull可维护性( Maintainability) M(d)

bull有效性( Availability ) A(t)

bull安全性( Safety )bull保密性( Security )

可靠性定义可靠性 R(t) 产品在规定条件下和规定时间内完成规定

功能的能力产品可靠性定义的要素是三个ldquo规定rdquo 1 )ldquo规定条件rdquo包括使用时的环境条件

和工作条件2 )ldquo规定时间rdquo是指产品规定了的任务

时间3 )ldquo规定功能rdquo是指产品规定了的必须

具备的功能及其技术指标

1 )ldquo规定条件rdquo包括使用时的环境条件和工作条件 例如同一型号的汽车在高速公路和在崎岖的山路上行驶其可

靠性的表现就不大一样要谈论产品的可靠性必须指明规定的条件是什么2 )ldquo规定时间rdquo是指产品规定了的任务时间 随着产品任务时间的增加产品出现故障的概率将增加

而产品的可靠性将是下降的因此谈论产品的可靠性离不开规定的任务时间例如一辆汽车在在刚刚开出厂子和用了5 年后相比它出故障的概率显然大了很多

3 )ldquo规定功能rdquo是指产品规定了的必须具备的功能及其技术指标所要求产品功能的多少和其技术指标的高低直接影响到产品可靠性指标的高低

例如电风扇的主要功能有转叶摇头定时那么规定的功能是三者都要还是仅需要转叶能转能够吹风所得出的可靠性指标是大不一样的

可维护性 M(d)1 )计算机系统的可维护性是指该系统失效后在规定时间内可

修复到规定功能的能力2 )反映系统可维护性高低的参数是修复率秒平均修复时间3 )软件可维护性即维护人员对该软件进行维护的难易程度

具体包括理解改正改动和改进该软件的难易程度4 )决定可维护性的因素

系统的大小系统的年龄结构合理性

5 )可维护性的度量 可理解性可测试性可修改性可移植性

有效性 A(t)设备的有效性的表式为 设备有效性 = 平均故障间隔期 (平均故障间隔期+平均修理时间)

在逻辑中如果一个论证不能从真前提中得出假结论 则论证的形式是完全有效的

一个论证若被称为是有效的则如果在其中所有前提都为真的每个模型中结论也是真的

例如ldquo所有 A 是 B 有些 A 是 C 所以有些 B 是Crdquo 是有效形式

可用性 实用性

3 可靠系统设计的基本原理1 )故障 (faults) 分析2 )可靠性分析3 )纠错技术4 )软件可靠性

1 )故障 (faults) 分析永久 (permanent) 与暂时( transient )故障故障来源 物理故障 (Physical faults)由生产缺陷辐射危害等等引起

设计故障 (Design faults) 是不合适设计的系统的结果

操作故障 (Operational faults) 来自人为过失安全破坏劣质设计的人机接口等等

可靠性设计

故障及其分类 产品的故障按其故障规律分为两大类

偶然故障 渐变故障

产品的故障按其故障后果分为两大类 致命性故障 非致命性故障

产品的故障按其统计特性分为两大类 独立故障 从属故障

可靠度 产品在规定的条件下和规定的时间内完成规

定功能的概率称为可靠度依定义可知系统的可靠度是时间的函数表示为

式中 R(t)mdashmdash 可靠度函数 ξmdashmdash 产生故障前的工作时间 t mdashmdash 规定的时间

)()( tPtR

2 )可靠性的分析mdashmdash可靠度

可靠度函数

依定义可知可靠度函数 R(t) 为

式中 N0 mdashmdash t = 0 时在规定条件下进行工作的产品数

r(t) mdashmdash  在 0 到 t 时刻的工作时间内产品的累计

故障数

0

0 )()(

N

trNtR

累积故障分布函数 产品在规定的条件下和规定的时间内丧失

规定功能的概率称为累积故障概率(又叫不可靠度) 依定义可知产品的累积故障概率是时间的函

数即

显然以下关系成立

0

)()(

N

trtF

1)()( tFtR

可靠度函数与累积故障分布函数的性质

图 R(t)F(t)与f(t)的关系t

f(t)

f(t)

F(to)

R(to)

to

由密度函数的性质 1)(0

dttf 可知

t

tdttfdttftFtR )()(1)(1)(

0

因此 R(t) F(t) 与 f(t) 之间的关系如图所示

故障率函数 故障率

工作到某时刻尚未发生故障的产品在该时刻后单位时间内发生故障的概率称之为产品的故障率

用数学符号表示为

式中 (t) mdashmdash 故障率 dr(t) mdashmdash t 时刻后 dt 时间内故障的产品数 Ns(t) mdashmdash 残存产品数即到 t 时刻尚未故障的产品

dttN

tdrt

s )(

)()(

35

故障率函数

可按下式进行工程计算

式中 Δr(t) mdashmdash t 时刻后 Δt 时间内故障的产品数

Δt mdashmdash 所取时间间隔 Ns(t) mdashmdash 残存产品数

对于低故障率的元部件常以 10-9h 为故障率的单位称之为菲特( Fit )

ttN

trt

s

)(

)()(

产品故障浴盆曲线 浴盆曲线

大多数产品的故障率随时间的变化曲线形似浴盆称之为浴盆曲线由于产品故障机理的不同产品的故障率随时间的变化大致可以分为三个阶段

产品典型的故障率曲线

t

使用寿命

早期故障

偶然故障 耗损故障

A B规定的故障率 维修后故障率下降

(t)

3 )纠错技术( 1 )纠错码 在 1950s就开始研究最早的是可以检测和纠错的汉明码它们通过数字系统广泛地用于识别和纠正短暂或者持久的错误这些码引入冗余信息来确保一些类型的错误可以被检测和纠正比如一个单错校正 双错校正的码能用一个比特检测和纠正一个错误但是不能用两个比特纠错

( 2 )三模冗余 (triple modular

redundancy) 计算单元 C 有三个副本 C1C2和 C3三个单元接收同

样的输入一个独立单元比较每个输入的结果如果至少两个结果一致那么那个值被表决器选做正确结果如果三个结果都不相同那么就没有正确的结果

1C

2C

3C

表决错误

结果

输入

( 3 )看门狗定时器 (watchdog timer)

看门狗定时器 (watchdog timer)被广泛地用于检测系统问题如图 看门狗定时器连接到一个监视系统如果这个看门狗定时器翻转它产生一个完成信号用于标注系统的错误中断系统应该这样设计当适当运行的时候它一直在可能产生翻转信号之前复位定时器因此来自看门狗定时器的完成信号指示系统在一定程度上不合适地操作看门狗定时器用于预防不同的故障

系统看门狗定时器

完成

复位

( 4 )设计多样性 (Design diversity)

一种用于减少一些系统错误进入设计的设计方法学当一个设计需要给定模块的不同实例应该采用模块的不同实现而不是到处都用同一种模块比如一个有多个 CPU的系统可能采用不同类型的 CPU而不是到处采用同一种类型的 CPU在一个三模冗余系统产生表决结构的组件可能有不同的实现这样可以减少产生同样设计错误的机会

4 )软件可靠性ldquo在规定的条件下在规定的时间内软件不引起失效的概率rdquo

规定的条件 软件运行的软硬件环境 软件操作剖面软件运行的输入空间及其概率分布

规定的时间 日历时间 时钟时间 执行时间

激活软件 输入域 缺陷的数据

软件缺陷 软件

不可接受的结果 (软件故障) 输出域

软件故障的特点

软件与硬件可靠性的区别硬件 软件

故障机理 老化损耗 残留缺陷在一定环境下造成的软件错误

复杂性 内部逻辑较为简单 内部逻辑高度复杂这就在很大程度上决定了设计错误是导致软件故障的主要原因

唯一性 任何两个硬件不可能绝对相同

软件是唯一的软件拷贝不改变软件本身

可靠性的核心 内部元部件 设计者的思维和软件的复杂性纠错维护方法 修复或更换失效的元部件 重设计 可靠性检验标准化

已标准化且有一整套完整的理论

仍未建立更没有完整的理论体系

产品市场 已有成熟的产品市场 产品市场还很新 错误性质 一些瞬间的硬件错误可能

会被误认为是软件错误 软件错误是永恒的可重现的

影响软件可靠性的因素( 1 )运行环境 ( 剖面 )

同一软件在不同运行剖面下其可靠性行为可能极不相同 软件故障是软件缺陷在一定输入情况下被激活的结果 假设软件输入域划分为两个部分 G 和 F 运行剖面不包含 F 中

的输入则软件不会出现故障其可靠性恒为 l 反之如果运行剖面不包含 G 中的输入则每一输入情况下均出现故障如果没有容错措施则 R=0

( 2 )软件规模 随着软件规模的增大软件可靠性问题愈显突出在我们考虑软件

可靠性问题时软件一般是指中型以上软件 (4000-5000条以上语句 ) 这时可靠性问题难以对付

软件工程实践的一个侧面可以反映这一点即单元测试一般由编程人员本人进行而综合测试则需独立的测试人员

影响软件可靠性的因素( 3 )软件内部结构

结构越复杂软件复杂度越高内含缺陷数越大因而软件可靠度越低

( 4 )软件可靠性设计技术 一般是指软件设计阶段中采用的用以保证和提高软件可靠性为主要目标的软件技术

( 5 )软件可靠性测试 研究表明软件测试方法与资源投入对软件可靠性有不可忽视的影

响( 6 )软件可靠性管理

软件可靠性管理旨在系统管理软件生存期各阶段的可靠性活动使之系统化规范化一体化这样就可以避免许多人为错误以提高软件可靠性

影响软件可靠性的因素( 7 )软件开发人员能力和经验

软件开发人员 ( 包括测试人员 ) 的能力愈强经验愈丰富所犯错误便可能愈少所得软件产品质量愈高相应的可靠性也愈高

( 8 )软件开发方法 软件工程表明开发方法对软件可靠性有显著影响 与非结构化方法比较结构化方法可以明显减少软件缺陷数

( 9 )软件开发环境 研究表明程序语言软件开发环境影响软件的可靠性而软件测

试工具的优劣则影响可靠性测试结果

4 安全 (Safety)amp保密 (Security)

安全 (Safety) 是保证财产和人身受到损害可靠性是指在一定的环境条件下以及一定的时间内系统完成特定任务的可能性而有效性则是系统的长期的工作时间于其存在时间 ( 简单的定义为运行时间 +维护时间 ) 的 比例保密 (Security) 是针对危险破坏损失或非法活动而进行措施在一定层面上保密 (Security)要比安全 (Safety)宽广的多例如信息 Security家庭 Security 网络 Security 国家Security) 等

Security强调的是外在事物对特定目标的危害

Safety 是系统本身的潜在危害

四个概念的比较分析安全 (Safety)可靠性 (Reliability)有效性 (Availability)保密 (Security )安全 (Safety)高的系统 软件可靠性不

一定高可靠性和有效性并不是一码事保密 (Security )的系统 软件是安全

(Safety) 系统 软件的重要保障

可靠性安全性保密性 可靠(或可信)系统设计 (Reliable (or dependable) system design)是制造嵌入式系统所关注的甚至在面对内部或者外部问题时可靠系统设计经常假设问题是非恶意引起的

安全重要的系统设计 (Safety-critical system design)研究确保系统安全操作的方法独立于引起问题的原因

保密性 (Security)主要关注恶意攻击

Aizientis等人描述了可信性和保密性间的关系可信性和保密性由几个特性所组成

服务的可用性 (Availability) 服务的连续性 (Continuity) 来自用户和所处环境的灾难性后果的安全性 (Safety) 来自不合适系统改变的完整性 (Integrity) 通过更改和修补的可维护性 (Maintainability) 信息的机密性 (Confidentiality)

可用性完整性

可靠性安全性可维护性

机密性

可信性 保密性

5 新型攻击和对策1 )物理攻击嵌入式系统比通用计算机更容易受攻击 一个关键原因是许多嵌入式计算机对攻击者可物理访问

2 )互联网攻击一些嵌入式系统的攻击通过互联网访问变得更加容易今天许多嵌入式系统连接到互联网

3 )电池攻击 (battery attack)这种攻击试图通过耗尽电池来关闭节点

4 )服务拒绝攻击 (Denial-of-service attacks)

在通用系统中众所周知但是实时嵌入式系统可能更容易受服务质量 (quality-of-service (QoS))攻击如果网络发布实时数据那么发送过程中的一点延迟都能引起数据无效如果那些数据用来实时控制那么这些短暂延迟就能引起系统故障我们称这种危害为时间攻击因为它改变了系统的实时特性

QoS或者时间攻击之所以强大使因为它的影响不仅仅限于信息被控制系统的动态特性可决定系统的响应如果一个大型沉重快速运动的系统被控制那么时间上一个相对小的改变能引起大量的破坏

5 )网络(协议)攻击Wood和 Stankovic[Woo02]在传感器网络上确定了一些方式这些方式可在网络层次的不同层执行拒绝服务攻击如下所列

物理层 (Physical layer)mdashmdash拥塞破坏 链路层 (Link layer)mdashmdash碰撞耗尽非公平

网络和路由层 (Network and routing layer)mdashmdash丢弃和贪婪汇集方向误导黑洞认证监视冗余

传输层 (Transport layer)mdashmdash泛洪失步

6 )能量攻击Kocher等人 [Koc99]指出测量一个 CPU当前的能量供给能在很大程度上确定处理器的内部活动他们提出了两种能量攻击的方法简单能量分析 (simple power analysis)人工地跟踪检查和尝试确定程序作用的位置比如分支基于不同 CUP操作的能耗知识基于程序作用攻击者然后减少密钥的比特差分能量分析 (Differential power analysis)用相关性确定作用和密钥比特这种攻击最初目标是智能卡这种卡从外部读卡器获取能量但是这种攻击也能应用到许多嵌入式系统中

7 )反攻击 在一些时候有可能构造反破坏的嵌入式系统使电子设备难以发觉和分析延缓了攻击者芯片中有限的信息也有助阻止攻击者发现数据

6 Efficiency (效率)

ES must be efficient

bull Code-size efficient( 特别是片上系统 )

bull Run-time efficient

bull Weight efficient

bull Cost efficient

bull Energy efficient

能量有效性的重要意义

ldquoinherent power

efficiency of siliconldquo

59

低功耗设计问题 功耗问题是近几年来人们在嵌入式系统的设计中普遍关注的难点和热点它严重地制约着嵌入式系统的应用与发展

无论是在军事还是在商业贸易上的应用相当数量的嵌入式系统一般是由电池来供给电能的而且大多数嵌入式设备都有体积和质量的约束减少电能消耗不仅能延长电池的使用寿命延长用户更换电池的周期而且能带来提高系统性能与降低系统开销的好处甚至能起到保护环境的作用在便携式设备中 CPU消耗的电能越少电池的寿命就越长同时散发的热量少了所需的散热器就少了从而可减少该设备的花费和体积使产品尽快进入市场的目标

1 低功耗嵌入式应用系统是指以降低系统功耗为一个主要性能指标的嵌入式系统如计算机里的许多芯片过去用 5V供电现在用 33V 18V 并提出了绿色电器的概念

60

低功耗设备的要求1 )首先要求体积小重量轻便于携带2 )采用低功耗电路的设计方法以降低系统的功耗

它除了选用各种低功耗的器件和芯片外还在满足速度等性能指标的前提下进行降低功耗的硬件电路设计和软件设计

3 )有的系统应用在交流供电比较困难甚至无法用交流供电的场合因而各种电池(瓶)就成为其主要供电手段

4 )采用 LCD液晶显示器5 )采用 RS232C串行通信接口6 )采用微功耗高抗干扰的 CMOS集成电路

功耗产生的原因 P=UI

与功耗有关的因素

( 1 )电阻上消耗的功率( 2 )有源器件的开关转换阶段( 3 )集成电路内部和外部电容的充放电( 4 )系统的性能指标负载能力被处理信号的工作频率电路的工作频率电源的管理水平零部件的性能散热条件接口的物理性能等对系统功耗起着重要的作用

降低功耗的措施

功耗的组成动态 + 静态动态电源管理动态电压缩放低功耗硬件设计低功耗软件设计

二设计方法学概论

问题功 能 性能要求价 格 开发 周 期 等约束

设计 选择 折衷 分析比较 计算 评价

嵌入式系统

0嵌入式系统设计概述

方法 工具

设计方法论( design methodology )

设计方法论有以下三个重要理由1 )确认我们所做的每一件事情都是必须要作的

不会做无谓的白工也不会漏掉关键性的重要工作其中包含效率优化或是功能测试

2 )可以发展出计算机辅助工具或是设计经验累积汲取每一次产品发展的经验再经过量化之后可以发展出一套工具或是方法让往后的产品设计步入自动化

3 )开发团队遵循同一套方法论可以让团队成员更容易彼此沟通每个人都能在短时间内了解整体过程中将经历哪些过程需要何种支持与接收到何种结果此外也容易透过一套已经定义好的方法论彼此相互合作协调

设计目标 1 )上市时间

也就是 time-to-market 的观念2 )设计成本

许多消费性产品对于价格非常敏感所以产品厂商对于成本会斤斤计较是很合理的

3 )品质 顾客也许不需要最快最便宜的产品但是一定会要求功能质量保证不能只用一小段时间就坏掉了

传统的设计主要步骤

2 传统的设计流程方法1 )瀑布模型 (Waterfall)2 )螺旋模型 (Spiral)3 )连续改进 (Successive Refinement)4 )硬件与软件的同步设计 (SWHW Co-

deign)5 )阶层式 (Hierarchical) 设计6 )同步工程( concurrent

engineering )

瀑布模型 (Waterfall)

螺旋模型 (Spiral)

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 6: 大学计算机基础 —— 计算机科学概论

问题 1mdashmdash体系结构(architectures)

硬件体系结构 CPUs协同设计多处理器网络软件体系结构 处理调度分配中间件人机交互 硬件软件及其二者之间的关系

问题 2mdashmdash方法学(methodologies)

建模分析形式化仿真性能功率能耗成本价格协同验证方法学中的步骤靠工具来执行

问题 3mdashmdash应用(applications)

特点规范参考设计 理解你的应用是获得嵌入式计算系统最大性能的关键我们可以根据应用的特点去优化设计这个优势可以使我们执行许多有效的优化而这在通用系统中是不可能的但是这也意味着我们必须对应用的特点有足够的认识这样才能在利用特点的同时避免在系统实现过程中产生问题

面向应用的计算( SmartApps An Application Centric Approach to High Performance Computing )

Today System Centric Computing

Application(Algorithm)

Compiler(static)

System(OS amp Arch)

HWOS

CompilerApplication

System-Centric Computing

Development entAnalysis amp

Optimization

Execution

Input Data

Classic Avenues toperformance

Parallel Algorithms Static Compiler Optimization OS support Good Architecture

Whatrsquos missing Compiler are conservative OS offers generic services Architecture is generic

No Global Optimization No matching between ApplicationOSHW Intractable for the general case

SmartApps Application Centric Computing

Application ControlInstance-specific optimization

Compiler + OS + Architecture + Data + Feedback

Application(Algorithm)

Development entAnalysis amp

Optimization

Compiler (static) +run-time techniques

Compiler(run-time)

OS(modular)

Architecture(reconfigurable)

SmartAppApplication

CompilerOS

HW

Run-time SystemExecution Analysis

amp Optimization

Application-Centric Computing

Input Data

Smart Application

SmartApps Architecture

Get Runtime Information(sample input system information etc)

Static CompilerAugmented withruntime techniques

Predictor ampOptimizer

partially compiledcode with unknownsand runtime hooks

Information forrapid simulation

Compute Optimal Applicationand System Configuration

Recompile Applicationandor Reconfigure System

Predictor ampEvaluator

Configurer

Application

Execute Application

Continuous monitorperformance and adaptas necessary

Predictor ampEvaluator

Predictor ampOptimizer

Adaptive Software

Runtime tuning (worecompile or reconfigure)

Small adaptation (tuning)

Large adaptation(failure phase change)

3 Real-time 约束许多 ES 必须满足实时约束什么是实时系统 实时系统是将时间定量化的一个概念实时系统是使用物理时钟来衡

量的当我们使用物理时钟来量化时间时我们就会讨论到实时的概念

与实时相反逻辑时间(也称为虚拟时间)是对时间的一种定性的概念通过使用事件顺序关系来表示例如之前之后某个时候最后在hellip之前接着等等

定义一个系统称为实时系统当我们需要用定量的时间表达式(也就是说实时)来描述这个系统的行为在这个实时系统的定义中隐含的表达了所有的定量的时间度量都是用一个物理时钟测量得到的

任何一个行为可以完全不用任何定量时间表达来描述其行为的系统肯定不是实时系统但一个系统的完整行为可以用它对各种外部刺激的响应列表来描述也就是说一个系统的行为大部分描述根本没有定量的时间表达式仍然被认为是一个实时系统

实时系统的类型根据任务超过截止时间的后果实时系统可以分为 硬实时软实时固实时1 )硬实时当系统执行任务时被强制要求在某个时间范围内要

产生结果换句话说任何时刻硬实时任务没有在制定的时间范围内产生要求的结果那这个系统就被认为失败了

2 )固实时当系统执行任务时与某些预设的截止时间相关联任务要求要在截止时间之前完成结果的计算不同于硬实时任务就算一个固实时任务没有在截止时间之前完成系统也不会失败迟来的结果仅仅是被丢弃了

3 )软实时当系统执行任务时也有与之相关联的时间界限但是不像硬实时和固实时任务软实时任务的时间界限并不是以绝对数值来表示的取而代之的是平均响应时间

Real-Time 系统与嵌入式系统

Embedded and Real-

Time 往往同义 Most embedded

systems are real-time

Most real-time systems are embedded

embeddedembedded

real-timereal-time

embedded embedded real-timereal-time

4 反应系统ES 是一个反应系统 转换系统输入(开始) -gt 软件系统(经过一段时间后停止运行) -gt (然后)输

出即用户把数据输入给计算机软件对这些数据经过一段时间的计算最后给出输出结果

输入数据经过特定的规则被转换并且在结束计算过程以后给出结果 而 reactive system 却与此相反在 reactive system 里往往没有明确的时序安排总体来讲

reactive system 表示的是不限制运行时间的系统这其中要和外部环境相互作用也就是在外部刺激上的反应 (reactive) 例如和不同使用者或者外部的硬件等但是也包括内部发生的交流行为因为 reactive system 是被集成在并行运行的分布式系统的规则中的例如一个计算机的操作系统是这样一个 reactive system 它不会停止运行 而总是反应用户给的输入 并且计算机中的各个组件之间要进行交流

在电信领域生产控制或者在硬件环境的构造(嵌入式系统)中还存在很多这样的例子在信息系统中也就是基于数据库的应用系统中也要用到 reactive system 在给一个典型的例子就是警报系统

5 混成系统Hybrid systems(analog + digital parts)混成系统一般由离散分立组件和连续组件并行或者串

行组成组件之间的行为由计算模型进行控制由于大多数复杂控制系统都包含了由连续变量所描述的物理层的动态演化过程和以符号操作与离散监控决策为特征的高层协调优化过程因此混成系统在工业控制和国防等领域大量存在混成系统定义凡是系统自身具有混合结构并且其

行为(输出和状态)取决于离散事件系统和连续动态系统相互作用的动态系统就称为混成系统

混成系统的典型特征( 1) 系统内存在着性质不同的连续和离散两类变量( 2) 时间和事件共同驱动系统的状态演化 ( 3)连续变量穿越阈值使状态使能或失能 ( 4)离散状态的变化改变连续变量遵循的变化速率 ( 5)离散事件发生在离散时刻 具有顺序选择并发等特色

( 6)状态呈阶段性间歇性切换变化 动态特征显著 ( 7) 对系统的控制表现为对连续状态和离散状态的集成控制 ( 8) 对系统的优化表现为在定性 定量双重指标下的集成优化

6 专用系统 Dedicated towards a certain

applicationKnowledge about behavior at design time can be used to minimize resources and to maximize robustness

Dedicated user interface(no mouse keyboard and screen)

二设计的挑战 实时可信可靠保密安全

1 为什么需要可靠的嵌入式系统1 )许多市场不需要高度可靠的嵌入式计算机但是许多嵌入式计算机必须

是高度可靠的2 )许多嵌入式计算机必须是高度可靠的汽车电子航空电子医疗设备

关键通信3 )可靠性的定义如电话交换机系统每年停机少于 30秒4 )关于可靠数字系统设计的研究几十年前就有不同的体系结构和方法学

被开发用于长周期低失误率的数字系统操作那么传统的可靠计算机和可靠的计算机系统有什么不同呢

5 )可靠嵌入式计算机通常是分布式系统如汽车电子航空电子和医疗设备都是必须高度可靠的分布式嵌入式系统

6 )嵌入式计算机容易受许多新类型攻击可靠计算机传统上是物理上不可访问的服务器或者机器mdashmdash物理安全长期以来是计算机安全的安全策略但是嵌入式计算机通常在非保护环境下操作这就允许新的故障和攻击这些需要都新的保护措施

2 可靠与可信ES 必需是可靠的可信的如何评价与度量

bull可靠性( Reliability) R(t)

bull可维护性( Maintainability) M(d)

bull有效性( Availability ) A(t)

bull安全性( Safety )bull保密性( Security )

可靠性定义可靠性 R(t) 产品在规定条件下和规定时间内完成规定

功能的能力产品可靠性定义的要素是三个ldquo规定rdquo 1 )ldquo规定条件rdquo包括使用时的环境条件

和工作条件2 )ldquo规定时间rdquo是指产品规定了的任务

时间3 )ldquo规定功能rdquo是指产品规定了的必须

具备的功能及其技术指标

1 )ldquo规定条件rdquo包括使用时的环境条件和工作条件 例如同一型号的汽车在高速公路和在崎岖的山路上行驶其可

靠性的表现就不大一样要谈论产品的可靠性必须指明规定的条件是什么2 )ldquo规定时间rdquo是指产品规定了的任务时间 随着产品任务时间的增加产品出现故障的概率将增加

而产品的可靠性将是下降的因此谈论产品的可靠性离不开规定的任务时间例如一辆汽车在在刚刚开出厂子和用了5 年后相比它出故障的概率显然大了很多

3 )ldquo规定功能rdquo是指产品规定了的必须具备的功能及其技术指标所要求产品功能的多少和其技术指标的高低直接影响到产品可靠性指标的高低

例如电风扇的主要功能有转叶摇头定时那么规定的功能是三者都要还是仅需要转叶能转能够吹风所得出的可靠性指标是大不一样的

可维护性 M(d)1 )计算机系统的可维护性是指该系统失效后在规定时间内可

修复到规定功能的能力2 )反映系统可维护性高低的参数是修复率秒平均修复时间3 )软件可维护性即维护人员对该软件进行维护的难易程度

具体包括理解改正改动和改进该软件的难易程度4 )决定可维护性的因素

系统的大小系统的年龄结构合理性

5 )可维护性的度量 可理解性可测试性可修改性可移植性

有效性 A(t)设备的有效性的表式为 设备有效性 = 平均故障间隔期 (平均故障间隔期+平均修理时间)

在逻辑中如果一个论证不能从真前提中得出假结论 则论证的形式是完全有效的

一个论证若被称为是有效的则如果在其中所有前提都为真的每个模型中结论也是真的

例如ldquo所有 A 是 B 有些 A 是 C 所以有些 B 是Crdquo 是有效形式

可用性 实用性

3 可靠系统设计的基本原理1 )故障 (faults) 分析2 )可靠性分析3 )纠错技术4 )软件可靠性

1 )故障 (faults) 分析永久 (permanent) 与暂时( transient )故障故障来源 物理故障 (Physical faults)由生产缺陷辐射危害等等引起

设计故障 (Design faults) 是不合适设计的系统的结果

操作故障 (Operational faults) 来自人为过失安全破坏劣质设计的人机接口等等

可靠性设计

故障及其分类 产品的故障按其故障规律分为两大类

偶然故障 渐变故障

产品的故障按其故障后果分为两大类 致命性故障 非致命性故障

产品的故障按其统计特性分为两大类 独立故障 从属故障

可靠度 产品在规定的条件下和规定的时间内完成规

定功能的概率称为可靠度依定义可知系统的可靠度是时间的函数表示为

式中 R(t)mdashmdash 可靠度函数 ξmdashmdash 产生故障前的工作时间 t mdashmdash 规定的时间

)()( tPtR

2 )可靠性的分析mdashmdash可靠度

可靠度函数

依定义可知可靠度函数 R(t) 为

式中 N0 mdashmdash t = 0 时在规定条件下进行工作的产品数

r(t) mdashmdash  在 0 到 t 时刻的工作时间内产品的累计

故障数

0

0 )()(

N

trNtR

累积故障分布函数 产品在规定的条件下和规定的时间内丧失

规定功能的概率称为累积故障概率(又叫不可靠度) 依定义可知产品的累积故障概率是时间的函

数即

显然以下关系成立

0

)()(

N

trtF

1)()( tFtR

可靠度函数与累积故障分布函数的性质

图 R(t)F(t)与f(t)的关系t

f(t)

f(t)

F(to)

R(to)

to

由密度函数的性质 1)(0

dttf 可知

t

tdttfdttftFtR )()(1)(1)(

0

因此 R(t) F(t) 与 f(t) 之间的关系如图所示

故障率函数 故障率

工作到某时刻尚未发生故障的产品在该时刻后单位时间内发生故障的概率称之为产品的故障率

用数学符号表示为

式中 (t) mdashmdash 故障率 dr(t) mdashmdash t 时刻后 dt 时间内故障的产品数 Ns(t) mdashmdash 残存产品数即到 t 时刻尚未故障的产品

dttN

tdrt

s )(

)()(

35

故障率函数

可按下式进行工程计算

式中 Δr(t) mdashmdash t 时刻后 Δt 时间内故障的产品数

Δt mdashmdash 所取时间间隔 Ns(t) mdashmdash 残存产品数

对于低故障率的元部件常以 10-9h 为故障率的单位称之为菲特( Fit )

ttN

trt

s

)(

)()(

产品故障浴盆曲线 浴盆曲线

大多数产品的故障率随时间的变化曲线形似浴盆称之为浴盆曲线由于产品故障机理的不同产品的故障率随时间的变化大致可以分为三个阶段

产品典型的故障率曲线

t

使用寿命

早期故障

偶然故障 耗损故障

A B规定的故障率 维修后故障率下降

(t)

3 )纠错技术( 1 )纠错码 在 1950s就开始研究最早的是可以检测和纠错的汉明码它们通过数字系统广泛地用于识别和纠正短暂或者持久的错误这些码引入冗余信息来确保一些类型的错误可以被检测和纠正比如一个单错校正 双错校正的码能用一个比特检测和纠正一个错误但是不能用两个比特纠错

( 2 )三模冗余 (triple modular

redundancy) 计算单元 C 有三个副本 C1C2和 C3三个单元接收同

样的输入一个独立单元比较每个输入的结果如果至少两个结果一致那么那个值被表决器选做正确结果如果三个结果都不相同那么就没有正确的结果

1C

2C

3C

表决错误

结果

输入

( 3 )看门狗定时器 (watchdog timer)

看门狗定时器 (watchdog timer)被广泛地用于检测系统问题如图 看门狗定时器连接到一个监视系统如果这个看门狗定时器翻转它产生一个完成信号用于标注系统的错误中断系统应该这样设计当适当运行的时候它一直在可能产生翻转信号之前复位定时器因此来自看门狗定时器的完成信号指示系统在一定程度上不合适地操作看门狗定时器用于预防不同的故障

系统看门狗定时器

完成

复位

( 4 )设计多样性 (Design diversity)

一种用于减少一些系统错误进入设计的设计方法学当一个设计需要给定模块的不同实例应该采用模块的不同实现而不是到处都用同一种模块比如一个有多个 CPU的系统可能采用不同类型的 CPU而不是到处采用同一种类型的 CPU在一个三模冗余系统产生表决结构的组件可能有不同的实现这样可以减少产生同样设计错误的机会

4 )软件可靠性ldquo在规定的条件下在规定的时间内软件不引起失效的概率rdquo

规定的条件 软件运行的软硬件环境 软件操作剖面软件运行的输入空间及其概率分布

规定的时间 日历时间 时钟时间 执行时间

激活软件 输入域 缺陷的数据

软件缺陷 软件

不可接受的结果 (软件故障) 输出域

软件故障的特点

软件与硬件可靠性的区别硬件 软件

故障机理 老化损耗 残留缺陷在一定环境下造成的软件错误

复杂性 内部逻辑较为简单 内部逻辑高度复杂这就在很大程度上决定了设计错误是导致软件故障的主要原因

唯一性 任何两个硬件不可能绝对相同

软件是唯一的软件拷贝不改变软件本身

可靠性的核心 内部元部件 设计者的思维和软件的复杂性纠错维护方法 修复或更换失效的元部件 重设计 可靠性检验标准化

已标准化且有一整套完整的理论

仍未建立更没有完整的理论体系

产品市场 已有成熟的产品市场 产品市场还很新 错误性质 一些瞬间的硬件错误可能

会被误认为是软件错误 软件错误是永恒的可重现的

影响软件可靠性的因素( 1 )运行环境 ( 剖面 )

同一软件在不同运行剖面下其可靠性行为可能极不相同 软件故障是软件缺陷在一定输入情况下被激活的结果 假设软件输入域划分为两个部分 G 和 F 运行剖面不包含 F 中

的输入则软件不会出现故障其可靠性恒为 l 反之如果运行剖面不包含 G 中的输入则每一输入情况下均出现故障如果没有容错措施则 R=0

( 2 )软件规模 随着软件规模的增大软件可靠性问题愈显突出在我们考虑软件

可靠性问题时软件一般是指中型以上软件 (4000-5000条以上语句 ) 这时可靠性问题难以对付

软件工程实践的一个侧面可以反映这一点即单元测试一般由编程人员本人进行而综合测试则需独立的测试人员

影响软件可靠性的因素( 3 )软件内部结构

结构越复杂软件复杂度越高内含缺陷数越大因而软件可靠度越低

( 4 )软件可靠性设计技术 一般是指软件设计阶段中采用的用以保证和提高软件可靠性为主要目标的软件技术

( 5 )软件可靠性测试 研究表明软件测试方法与资源投入对软件可靠性有不可忽视的影

响( 6 )软件可靠性管理

软件可靠性管理旨在系统管理软件生存期各阶段的可靠性活动使之系统化规范化一体化这样就可以避免许多人为错误以提高软件可靠性

影响软件可靠性的因素( 7 )软件开发人员能力和经验

软件开发人员 ( 包括测试人员 ) 的能力愈强经验愈丰富所犯错误便可能愈少所得软件产品质量愈高相应的可靠性也愈高

( 8 )软件开发方法 软件工程表明开发方法对软件可靠性有显著影响 与非结构化方法比较结构化方法可以明显减少软件缺陷数

( 9 )软件开发环境 研究表明程序语言软件开发环境影响软件的可靠性而软件测

试工具的优劣则影响可靠性测试结果

4 安全 (Safety)amp保密 (Security)

安全 (Safety) 是保证财产和人身受到损害可靠性是指在一定的环境条件下以及一定的时间内系统完成特定任务的可能性而有效性则是系统的长期的工作时间于其存在时间 ( 简单的定义为运行时间 +维护时间 ) 的 比例保密 (Security) 是针对危险破坏损失或非法活动而进行措施在一定层面上保密 (Security)要比安全 (Safety)宽广的多例如信息 Security家庭 Security 网络 Security 国家Security) 等

Security强调的是外在事物对特定目标的危害

Safety 是系统本身的潜在危害

四个概念的比较分析安全 (Safety)可靠性 (Reliability)有效性 (Availability)保密 (Security )安全 (Safety)高的系统 软件可靠性不

一定高可靠性和有效性并不是一码事保密 (Security )的系统 软件是安全

(Safety) 系统 软件的重要保障

可靠性安全性保密性 可靠(或可信)系统设计 (Reliable (or dependable) system design)是制造嵌入式系统所关注的甚至在面对内部或者外部问题时可靠系统设计经常假设问题是非恶意引起的

安全重要的系统设计 (Safety-critical system design)研究确保系统安全操作的方法独立于引起问题的原因

保密性 (Security)主要关注恶意攻击

Aizientis等人描述了可信性和保密性间的关系可信性和保密性由几个特性所组成

服务的可用性 (Availability) 服务的连续性 (Continuity) 来自用户和所处环境的灾难性后果的安全性 (Safety) 来自不合适系统改变的完整性 (Integrity) 通过更改和修补的可维护性 (Maintainability) 信息的机密性 (Confidentiality)

可用性完整性

可靠性安全性可维护性

机密性

可信性 保密性

5 新型攻击和对策1 )物理攻击嵌入式系统比通用计算机更容易受攻击 一个关键原因是许多嵌入式计算机对攻击者可物理访问

2 )互联网攻击一些嵌入式系统的攻击通过互联网访问变得更加容易今天许多嵌入式系统连接到互联网

3 )电池攻击 (battery attack)这种攻击试图通过耗尽电池来关闭节点

4 )服务拒绝攻击 (Denial-of-service attacks)

在通用系统中众所周知但是实时嵌入式系统可能更容易受服务质量 (quality-of-service (QoS))攻击如果网络发布实时数据那么发送过程中的一点延迟都能引起数据无效如果那些数据用来实时控制那么这些短暂延迟就能引起系统故障我们称这种危害为时间攻击因为它改变了系统的实时特性

QoS或者时间攻击之所以强大使因为它的影响不仅仅限于信息被控制系统的动态特性可决定系统的响应如果一个大型沉重快速运动的系统被控制那么时间上一个相对小的改变能引起大量的破坏

5 )网络(协议)攻击Wood和 Stankovic[Woo02]在传感器网络上确定了一些方式这些方式可在网络层次的不同层执行拒绝服务攻击如下所列

物理层 (Physical layer)mdashmdash拥塞破坏 链路层 (Link layer)mdashmdash碰撞耗尽非公平

网络和路由层 (Network and routing layer)mdashmdash丢弃和贪婪汇集方向误导黑洞认证监视冗余

传输层 (Transport layer)mdashmdash泛洪失步

6 )能量攻击Kocher等人 [Koc99]指出测量一个 CPU当前的能量供给能在很大程度上确定处理器的内部活动他们提出了两种能量攻击的方法简单能量分析 (simple power analysis)人工地跟踪检查和尝试确定程序作用的位置比如分支基于不同 CUP操作的能耗知识基于程序作用攻击者然后减少密钥的比特差分能量分析 (Differential power analysis)用相关性确定作用和密钥比特这种攻击最初目标是智能卡这种卡从外部读卡器获取能量但是这种攻击也能应用到许多嵌入式系统中

7 )反攻击 在一些时候有可能构造反破坏的嵌入式系统使电子设备难以发觉和分析延缓了攻击者芯片中有限的信息也有助阻止攻击者发现数据

6 Efficiency (效率)

ES must be efficient

bull Code-size efficient( 特别是片上系统 )

bull Run-time efficient

bull Weight efficient

bull Cost efficient

bull Energy efficient

能量有效性的重要意义

ldquoinherent power

efficiency of siliconldquo

59

低功耗设计问题 功耗问题是近几年来人们在嵌入式系统的设计中普遍关注的难点和热点它严重地制约着嵌入式系统的应用与发展

无论是在军事还是在商业贸易上的应用相当数量的嵌入式系统一般是由电池来供给电能的而且大多数嵌入式设备都有体积和质量的约束减少电能消耗不仅能延长电池的使用寿命延长用户更换电池的周期而且能带来提高系统性能与降低系统开销的好处甚至能起到保护环境的作用在便携式设备中 CPU消耗的电能越少电池的寿命就越长同时散发的热量少了所需的散热器就少了从而可减少该设备的花费和体积使产品尽快进入市场的目标

1 低功耗嵌入式应用系统是指以降低系统功耗为一个主要性能指标的嵌入式系统如计算机里的许多芯片过去用 5V供电现在用 33V 18V 并提出了绿色电器的概念

60

低功耗设备的要求1 )首先要求体积小重量轻便于携带2 )采用低功耗电路的设计方法以降低系统的功耗

它除了选用各种低功耗的器件和芯片外还在满足速度等性能指标的前提下进行降低功耗的硬件电路设计和软件设计

3 )有的系统应用在交流供电比较困难甚至无法用交流供电的场合因而各种电池(瓶)就成为其主要供电手段

4 )采用 LCD液晶显示器5 )采用 RS232C串行通信接口6 )采用微功耗高抗干扰的 CMOS集成电路

功耗产生的原因 P=UI

与功耗有关的因素

( 1 )电阻上消耗的功率( 2 )有源器件的开关转换阶段( 3 )集成电路内部和外部电容的充放电( 4 )系统的性能指标负载能力被处理信号的工作频率电路的工作频率电源的管理水平零部件的性能散热条件接口的物理性能等对系统功耗起着重要的作用

降低功耗的措施

功耗的组成动态 + 静态动态电源管理动态电压缩放低功耗硬件设计低功耗软件设计

二设计方法学概论

问题功 能 性能要求价 格 开发 周 期 等约束

设计 选择 折衷 分析比较 计算 评价

嵌入式系统

0嵌入式系统设计概述

方法 工具

设计方法论( design methodology )

设计方法论有以下三个重要理由1 )确认我们所做的每一件事情都是必须要作的

不会做无谓的白工也不会漏掉关键性的重要工作其中包含效率优化或是功能测试

2 )可以发展出计算机辅助工具或是设计经验累积汲取每一次产品发展的经验再经过量化之后可以发展出一套工具或是方法让往后的产品设计步入自动化

3 )开发团队遵循同一套方法论可以让团队成员更容易彼此沟通每个人都能在短时间内了解整体过程中将经历哪些过程需要何种支持与接收到何种结果此外也容易透过一套已经定义好的方法论彼此相互合作协调

设计目标 1 )上市时间

也就是 time-to-market 的观念2 )设计成本

许多消费性产品对于价格非常敏感所以产品厂商对于成本会斤斤计较是很合理的

3 )品质 顾客也许不需要最快最便宜的产品但是一定会要求功能质量保证不能只用一小段时间就坏掉了

传统的设计主要步骤

2 传统的设计流程方法1 )瀑布模型 (Waterfall)2 )螺旋模型 (Spiral)3 )连续改进 (Successive Refinement)4 )硬件与软件的同步设计 (SWHW Co-

deign)5 )阶层式 (Hierarchical) 设计6 )同步工程( concurrent

engineering )

瀑布模型 (Waterfall)

螺旋模型 (Spiral)

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 7: 大学计算机基础 —— 计算机科学概论

问题 2mdashmdash方法学(methodologies)

建模分析形式化仿真性能功率能耗成本价格协同验证方法学中的步骤靠工具来执行

问题 3mdashmdash应用(applications)

特点规范参考设计 理解你的应用是获得嵌入式计算系统最大性能的关键我们可以根据应用的特点去优化设计这个优势可以使我们执行许多有效的优化而这在通用系统中是不可能的但是这也意味着我们必须对应用的特点有足够的认识这样才能在利用特点的同时避免在系统实现过程中产生问题

面向应用的计算( SmartApps An Application Centric Approach to High Performance Computing )

Today System Centric Computing

Application(Algorithm)

Compiler(static)

System(OS amp Arch)

HWOS

CompilerApplication

System-Centric Computing

Development entAnalysis amp

Optimization

Execution

Input Data

Classic Avenues toperformance

Parallel Algorithms Static Compiler Optimization OS support Good Architecture

Whatrsquos missing Compiler are conservative OS offers generic services Architecture is generic

No Global Optimization No matching between ApplicationOSHW Intractable for the general case

SmartApps Application Centric Computing

Application ControlInstance-specific optimization

Compiler + OS + Architecture + Data + Feedback

Application(Algorithm)

Development entAnalysis amp

Optimization

Compiler (static) +run-time techniques

Compiler(run-time)

OS(modular)

Architecture(reconfigurable)

SmartAppApplication

CompilerOS

HW

Run-time SystemExecution Analysis

amp Optimization

Application-Centric Computing

Input Data

Smart Application

SmartApps Architecture

Get Runtime Information(sample input system information etc)

Static CompilerAugmented withruntime techniques

Predictor ampOptimizer

partially compiledcode with unknownsand runtime hooks

Information forrapid simulation

Compute Optimal Applicationand System Configuration

Recompile Applicationandor Reconfigure System

Predictor ampEvaluator

Configurer

Application

Execute Application

Continuous monitorperformance and adaptas necessary

Predictor ampEvaluator

Predictor ampOptimizer

Adaptive Software

Runtime tuning (worecompile or reconfigure)

Small adaptation (tuning)

Large adaptation(failure phase change)

3 Real-time 约束许多 ES 必须满足实时约束什么是实时系统 实时系统是将时间定量化的一个概念实时系统是使用物理时钟来衡

量的当我们使用物理时钟来量化时间时我们就会讨论到实时的概念

与实时相反逻辑时间(也称为虚拟时间)是对时间的一种定性的概念通过使用事件顺序关系来表示例如之前之后某个时候最后在hellip之前接着等等

定义一个系统称为实时系统当我们需要用定量的时间表达式(也就是说实时)来描述这个系统的行为在这个实时系统的定义中隐含的表达了所有的定量的时间度量都是用一个物理时钟测量得到的

任何一个行为可以完全不用任何定量时间表达来描述其行为的系统肯定不是实时系统但一个系统的完整行为可以用它对各种外部刺激的响应列表来描述也就是说一个系统的行为大部分描述根本没有定量的时间表达式仍然被认为是一个实时系统

实时系统的类型根据任务超过截止时间的后果实时系统可以分为 硬实时软实时固实时1 )硬实时当系统执行任务时被强制要求在某个时间范围内要

产生结果换句话说任何时刻硬实时任务没有在制定的时间范围内产生要求的结果那这个系统就被认为失败了

2 )固实时当系统执行任务时与某些预设的截止时间相关联任务要求要在截止时间之前完成结果的计算不同于硬实时任务就算一个固实时任务没有在截止时间之前完成系统也不会失败迟来的结果仅仅是被丢弃了

3 )软实时当系统执行任务时也有与之相关联的时间界限但是不像硬实时和固实时任务软实时任务的时间界限并不是以绝对数值来表示的取而代之的是平均响应时间

Real-Time 系统与嵌入式系统

Embedded and Real-

Time 往往同义 Most embedded

systems are real-time

Most real-time systems are embedded

embeddedembedded

real-timereal-time

embedded embedded real-timereal-time

4 反应系统ES 是一个反应系统 转换系统输入(开始) -gt 软件系统(经过一段时间后停止运行) -gt (然后)输

出即用户把数据输入给计算机软件对这些数据经过一段时间的计算最后给出输出结果

输入数据经过特定的规则被转换并且在结束计算过程以后给出结果 而 reactive system 却与此相反在 reactive system 里往往没有明确的时序安排总体来讲

reactive system 表示的是不限制运行时间的系统这其中要和外部环境相互作用也就是在外部刺激上的反应 (reactive) 例如和不同使用者或者外部的硬件等但是也包括内部发生的交流行为因为 reactive system 是被集成在并行运行的分布式系统的规则中的例如一个计算机的操作系统是这样一个 reactive system 它不会停止运行 而总是反应用户给的输入 并且计算机中的各个组件之间要进行交流

在电信领域生产控制或者在硬件环境的构造(嵌入式系统)中还存在很多这样的例子在信息系统中也就是基于数据库的应用系统中也要用到 reactive system 在给一个典型的例子就是警报系统

5 混成系统Hybrid systems(analog + digital parts)混成系统一般由离散分立组件和连续组件并行或者串

行组成组件之间的行为由计算模型进行控制由于大多数复杂控制系统都包含了由连续变量所描述的物理层的动态演化过程和以符号操作与离散监控决策为特征的高层协调优化过程因此混成系统在工业控制和国防等领域大量存在混成系统定义凡是系统自身具有混合结构并且其

行为(输出和状态)取决于离散事件系统和连续动态系统相互作用的动态系统就称为混成系统

混成系统的典型特征( 1) 系统内存在着性质不同的连续和离散两类变量( 2) 时间和事件共同驱动系统的状态演化 ( 3)连续变量穿越阈值使状态使能或失能 ( 4)离散状态的变化改变连续变量遵循的变化速率 ( 5)离散事件发生在离散时刻 具有顺序选择并发等特色

( 6)状态呈阶段性间歇性切换变化 动态特征显著 ( 7) 对系统的控制表现为对连续状态和离散状态的集成控制 ( 8) 对系统的优化表现为在定性 定量双重指标下的集成优化

6 专用系统 Dedicated towards a certain

applicationKnowledge about behavior at design time can be used to minimize resources and to maximize robustness

Dedicated user interface(no mouse keyboard and screen)

二设计的挑战 实时可信可靠保密安全

1 为什么需要可靠的嵌入式系统1 )许多市场不需要高度可靠的嵌入式计算机但是许多嵌入式计算机必须

是高度可靠的2 )许多嵌入式计算机必须是高度可靠的汽车电子航空电子医疗设备

关键通信3 )可靠性的定义如电话交换机系统每年停机少于 30秒4 )关于可靠数字系统设计的研究几十年前就有不同的体系结构和方法学

被开发用于长周期低失误率的数字系统操作那么传统的可靠计算机和可靠的计算机系统有什么不同呢

5 )可靠嵌入式计算机通常是分布式系统如汽车电子航空电子和医疗设备都是必须高度可靠的分布式嵌入式系统

6 )嵌入式计算机容易受许多新类型攻击可靠计算机传统上是物理上不可访问的服务器或者机器mdashmdash物理安全长期以来是计算机安全的安全策略但是嵌入式计算机通常在非保护环境下操作这就允许新的故障和攻击这些需要都新的保护措施

2 可靠与可信ES 必需是可靠的可信的如何评价与度量

bull可靠性( Reliability) R(t)

bull可维护性( Maintainability) M(d)

bull有效性( Availability ) A(t)

bull安全性( Safety )bull保密性( Security )

可靠性定义可靠性 R(t) 产品在规定条件下和规定时间内完成规定

功能的能力产品可靠性定义的要素是三个ldquo规定rdquo 1 )ldquo规定条件rdquo包括使用时的环境条件

和工作条件2 )ldquo规定时间rdquo是指产品规定了的任务

时间3 )ldquo规定功能rdquo是指产品规定了的必须

具备的功能及其技术指标

1 )ldquo规定条件rdquo包括使用时的环境条件和工作条件 例如同一型号的汽车在高速公路和在崎岖的山路上行驶其可

靠性的表现就不大一样要谈论产品的可靠性必须指明规定的条件是什么2 )ldquo规定时间rdquo是指产品规定了的任务时间 随着产品任务时间的增加产品出现故障的概率将增加

而产品的可靠性将是下降的因此谈论产品的可靠性离不开规定的任务时间例如一辆汽车在在刚刚开出厂子和用了5 年后相比它出故障的概率显然大了很多

3 )ldquo规定功能rdquo是指产品规定了的必须具备的功能及其技术指标所要求产品功能的多少和其技术指标的高低直接影响到产品可靠性指标的高低

例如电风扇的主要功能有转叶摇头定时那么规定的功能是三者都要还是仅需要转叶能转能够吹风所得出的可靠性指标是大不一样的

可维护性 M(d)1 )计算机系统的可维护性是指该系统失效后在规定时间内可

修复到规定功能的能力2 )反映系统可维护性高低的参数是修复率秒平均修复时间3 )软件可维护性即维护人员对该软件进行维护的难易程度

具体包括理解改正改动和改进该软件的难易程度4 )决定可维护性的因素

系统的大小系统的年龄结构合理性

5 )可维护性的度量 可理解性可测试性可修改性可移植性

有效性 A(t)设备的有效性的表式为 设备有效性 = 平均故障间隔期 (平均故障间隔期+平均修理时间)

在逻辑中如果一个论证不能从真前提中得出假结论 则论证的形式是完全有效的

一个论证若被称为是有效的则如果在其中所有前提都为真的每个模型中结论也是真的

例如ldquo所有 A 是 B 有些 A 是 C 所以有些 B 是Crdquo 是有效形式

可用性 实用性

3 可靠系统设计的基本原理1 )故障 (faults) 分析2 )可靠性分析3 )纠错技术4 )软件可靠性

1 )故障 (faults) 分析永久 (permanent) 与暂时( transient )故障故障来源 物理故障 (Physical faults)由生产缺陷辐射危害等等引起

设计故障 (Design faults) 是不合适设计的系统的结果

操作故障 (Operational faults) 来自人为过失安全破坏劣质设计的人机接口等等

可靠性设计

故障及其分类 产品的故障按其故障规律分为两大类

偶然故障 渐变故障

产品的故障按其故障后果分为两大类 致命性故障 非致命性故障

产品的故障按其统计特性分为两大类 独立故障 从属故障

可靠度 产品在规定的条件下和规定的时间内完成规

定功能的概率称为可靠度依定义可知系统的可靠度是时间的函数表示为

式中 R(t)mdashmdash 可靠度函数 ξmdashmdash 产生故障前的工作时间 t mdashmdash 规定的时间

)()( tPtR

2 )可靠性的分析mdashmdash可靠度

可靠度函数

依定义可知可靠度函数 R(t) 为

式中 N0 mdashmdash t = 0 时在规定条件下进行工作的产品数

r(t) mdashmdash  在 0 到 t 时刻的工作时间内产品的累计

故障数

0

0 )()(

N

trNtR

累积故障分布函数 产品在规定的条件下和规定的时间内丧失

规定功能的概率称为累积故障概率(又叫不可靠度) 依定义可知产品的累积故障概率是时间的函

数即

显然以下关系成立

0

)()(

N

trtF

1)()( tFtR

可靠度函数与累积故障分布函数的性质

图 R(t)F(t)与f(t)的关系t

f(t)

f(t)

F(to)

R(to)

to

由密度函数的性质 1)(0

dttf 可知

t

tdttfdttftFtR )()(1)(1)(

0

因此 R(t) F(t) 与 f(t) 之间的关系如图所示

故障率函数 故障率

工作到某时刻尚未发生故障的产品在该时刻后单位时间内发生故障的概率称之为产品的故障率

用数学符号表示为

式中 (t) mdashmdash 故障率 dr(t) mdashmdash t 时刻后 dt 时间内故障的产品数 Ns(t) mdashmdash 残存产品数即到 t 时刻尚未故障的产品

dttN

tdrt

s )(

)()(

35

故障率函数

可按下式进行工程计算

式中 Δr(t) mdashmdash t 时刻后 Δt 时间内故障的产品数

Δt mdashmdash 所取时间间隔 Ns(t) mdashmdash 残存产品数

对于低故障率的元部件常以 10-9h 为故障率的单位称之为菲特( Fit )

ttN

trt

s

)(

)()(

产品故障浴盆曲线 浴盆曲线

大多数产品的故障率随时间的变化曲线形似浴盆称之为浴盆曲线由于产品故障机理的不同产品的故障率随时间的变化大致可以分为三个阶段

产品典型的故障率曲线

t

使用寿命

早期故障

偶然故障 耗损故障

A B规定的故障率 维修后故障率下降

(t)

3 )纠错技术( 1 )纠错码 在 1950s就开始研究最早的是可以检测和纠错的汉明码它们通过数字系统广泛地用于识别和纠正短暂或者持久的错误这些码引入冗余信息来确保一些类型的错误可以被检测和纠正比如一个单错校正 双错校正的码能用一个比特检测和纠正一个错误但是不能用两个比特纠错

( 2 )三模冗余 (triple modular

redundancy) 计算单元 C 有三个副本 C1C2和 C3三个单元接收同

样的输入一个独立单元比较每个输入的结果如果至少两个结果一致那么那个值被表决器选做正确结果如果三个结果都不相同那么就没有正确的结果

1C

2C

3C

表决错误

结果

输入

( 3 )看门狗定时器 (watchdog timer)

看门狗定时器 (watchdog timer)被广泛地用于检测系统问题如图 看门狗定时器连接到一个监视系统如果这个看门狗定时器翻转它产生一个完成信号用于标注系统的错误中断系统应该这样设计当适当运行的时候它一直在可能产生翻转信号之前复位定时器因此来自看门狗定时器的完成信号指示系统在一定程度上不合适地操作看门狗定时器用于预防不同的故障

系统看门狗定时器

完成

复位

( 4 )设计多样性 (Design diversity)

一种用于减少一些系统错误进入设计的设计方法学当一个设计需要给定模块的不同实例应该采用模块的不同实现而不是到处都用同一种模块比如一个有多个 CPU的系统可能采用不同类型的 CPU而不是到处采用同一种类型的 CPU在一个三模冗余系统产生表决结构的组件可能有不同的实现这样可以减少产生同样设计错误的机会

4 )软件可靠性ldquo在规定的条件下在规定的时间内软件不引起失效的概率rdquo

规定的条件 软件运行的软硬件环境 软件操作剖面软件运行的输入空间及其概率分布

规定的时间 日历时间 时钟时间 执行时间

激活软件 输入域 缺陷的数据

软件缺陷 软件

不可接受的结果 (软件故障) 输出域

软件故障的特点

软件与硬件可靠性的区别硬件 软件

故障机理 老化损耗 残留缺陷在一定环境下造成的软件错误

复杂性 内部逻辑较为简单 内部逻辑高度复杂这就在很大程度上决定了设计错误是导致软件故障的主要原因

唯一性 任何两个硬件不可能绝对相同

软件是唯一的软件拷贝不改变软件本身

可靠性的核心 内部元部件 设计者的思维和软件的复杂性纠错维护方法 修复或更换失效的元部件 重设计 可靠性检验标准化

已标准化且有一整套完整的理论

仍未建立更没有完整的理论体系

产品市场 已有成熟的产品市场 产品市场还很新 错误性质 一些瞬间的硬件错误可能

会被误认为是软件错误 软件错误是永恒的可重现的

影响软件可靠性的因素( 1 )运行环境 ( 剖面 )

同一软件在不同运行剖面下其可靠性行为可能极不相同 软件故障是软件缺陷在一定输入情况下被激活的结果 假设软件输入域划分为两个部分 G 和 F 运行剖面不包含 F 中

的输入则软件不会出现故障其可靠性恒为 l 反之如果运行剖面不包含 G 中的输入则每一输入情况下均出现故障如果没有容错措施则 R=0

( 2 )软件规模 随着软件规模的增大软件可靠性问题愈显突出在我们考虑软件

可靠性问题时软件一般是指中型以上软件 (4000-5000条以上语句 ) 这时可靠性问题难以对付

软件工程实践的一个侧面可以反映这一点即单元测试一般由编程人员本人进行而综合测试则需独立的测试人员

影响软件可靠性的因素( 3 )软件内部结构

结构越复杂软件复杂度越高内含缺陷数越大因而软件可靠度越低

( 4 )软件可靠性设计技术 一般是指软件设计阶段中采用的用以保证和提高软件可靠性为主要目标的软件技术

( 5 )软件可靠性测试 研究表明软件测试方法与资源投入对软件可靠性有不可忽视的影

响( 6 )软件可靠性管理

软件可靠性管理旨在系统管理软件生存期各阶段的可靠性活动使之系统化规范化一体化这样就可以避免许多人为错误以提高软件可靠性

影响软件可靠性的因素( 7 )软件开发人员能力和经验

软件开发人员 ( 包括测试人员 ) 的能力愈强经验愈丰富所犯错误便可能愈少所得软件产品质量愈高相应的可靠性也愈高

( 8 )软件开发方法 软件工程表明开发方法对软件可靠性有显著影响 与非结构化方法比较结构化方法可以明显减少软件缺陷数

( 9 )软件开发环境 研究表明程序语言软件开发环境影响软件的可靠性而软件测

试工具的优劣则影响可靠性测试结果

4 安全 (Safety)amp保密 (Security)

安全 (Safety) 是保证财产和人身受到损害可靠性是指在一定的环境条件下以及一定的时间内系统完成特定任务的可能性而有效性则是系统的长期的工作时间于其存在时间 ( 简单的定义为运行时间 +维护时间 ) 的 比例保密 (Security) 是针对危险破坏损失或非法活动而进行措施在一定层面上保密 (Security)要比安全 (Safety)宽广的多例如信息 Security家庭 Security 网络 Security 国家Security) 等

Security强调的是外在事物对特定目标的危害

Safety 是系统本身的潜在危害

四个概念的比较分析安全 (Safety)可靠性 (Reliability)有效性 (Availability)保密 (Security )安全 (Safety)高的系统 软件可靠性不

一定高可靠性和有效性并不是一码事保密 (Security )的系统 软件是安全

(Safety) 系统 软件的重要保障

可靠性安全性保密性 可靠(或可信)系统设计 (Reliable (or dependable) system design)是制造嵌入式系统所关注的甚至在面对内部或者外部问题时可靠系统设计经常假设问题是非恶意引起的

安全重要的系统设计 (Safety-critical system design)研究确保系统安全操作的方法独立于引起问题的原因

保密性 (Security)主要关注恶意攻击

Aizientis等人描述了可信性和保密性间的关系可信性和保密性由几个特性所组成

服务的可用性 (Availability) 服务的连续性 (Continuity) 来自用户和所处环境的灾难性后果的安全性 (Safety) 来自不合适系统改变的完整性 (Integrity) 通过更改和修补的可维护性 (Maintainability) 信息的机密性 (Confidentiality)

可用性完整性

可靠性安全性可维护性

机密性

可信性 保密性

5 新型攻击和对策1 )物理攻击嵌入式系统比通用计算机更容易受攻击 一个关键原因是许多嵌入式计算机对攻击者可物理访问

2 )互联网攻击一些嵌入式系统的攻击通过互联网访问变得更加容易今天许多嵌入式系统连接到互联网

3 )电池攻击 (battery attack)这种攻击试图通过耗尽电池来关闭节点

4 )服务拒绝攻击 (Denial-of-service attacks)

在通用系统中众所周知但是实时嵌入式系统可能更容易受服务质量 (quality-of-service (QoS))攻击如果网络发布实时数据那么发送过程中的一点延迟都能引起数据无效如果那些数据用来实时控制那么这些短暂延迟就能引起系统故障我们称这种危害为时间攻击因为它改变了系统的实时特性

QoS或者时间攻击之所以强大使因为它的影响不仅仅限于信息被控制系统的动态特性可决定系统的响应如果一个大型沉重快速运动的系统被控制那么时间上一个相对小的改变能引起大量的破坏

5 )网络(协议)攻击Wood和 Stankovic[Woo02]在传感器网络上确定了一些方式这些方式可在网络层次的不同层执行拒绝服务攻击如下所列

物理层 (Physical layer)mdashmdash拥塞破坏 链路层 (Link layer)mdashmdash碰撞耗尽非公平

网络和路由层 (Network and routing layer)mdashmdash丢弃和贪婪汇集方向误导黑洞认证监视冗余

传输层 (Transport layer)mdashmdash泛洪失步

6 )能量攻击Kocher等人 [Koc99]指出测量一个 CPU当前的能量供给能在很大程度上确定处理器的内部活动他们提出了两种能量攻击的方法简单能量分析 (simple power analysis)人工地跟踪检查和尝试确定程序作用的位置比如分支基于不同 CUP操作的能耗知识基于程序作用攻击者然后减少密钥的比特差分能量分析 (Differential power analysis)用相关性确定作用和密钥比特这种攻击最初目标是智能卡这种卡从外部读卡器获取能量但是这种攻击也能应用到许多嵌入式系统中

7 )反攻击 在一些时候有可能构造反破坏的嵌入式系统使电子设备难以发觉和分析延缓了攻击者芯片中有限的信息也有助阻止攻击者发现数据

6 Efficiency (效率)

ES must be efficient

bull Code-size efficient( 特别是片上系统 )

bull Run-time efficient

bull Weight efficient

bull Cost efficient

bull Energy efficient

能量有效性的重要意义

ldquoinherent power

efficiency of siliconldquo

59

低功耗设计问题 功耗问题是近几年来人们在嵌入式系统的设计中普遍关注的难点和热点它严重地制约着嵌入式系统的应用与发展

无论是在军事还是在商业贸易上的应用相当数量的嵌入式系统一般是由电池来供给电能的而且大多数嵌入式设备都有体积和质量的约束减少电能消耗不仅能延长电池的使用寿命延长用户更换电池的周期而且能带来提高系统性能与降低系统开销的好处甚至能起到保护环境的作用在便携式设备中 CPU消耗的电能越少电池的寿命就越长同时散发的热量少了所需的散热器就少了从而可减少该设备的花费和体积使产品尽快进入市场的目标

1 低功耗嵌入式应用系统是指以降低系统功耗为一个主要性能指标的嵌入式系统如计算机里的许多芯片过去用 5V供电现在用 33V 18V 并提出了绿色电器的概念

60

低功耗设备的要求1 )首先要求体积小重量轻便于携带2 )采用低功耗电路的设计方法以降低系统的功耗

它除了选用各种低功耗的器件和芯片外还在满足速度等性能指标的前提下进行降低功耗的硬件电路设计和软件设计

3 )有的系统应用在交流供电比较困难甚至无法用交流供电的场合因而各种电池(瓶)就成为其主要供电手段

4 )采用 LCD液晶显示器5 )采用 RS232C串行通信接口6 )采用微功耗高抗干扰的 CMOS集成电路

功耗产生的原因 P=UI

与功耗有关的因素

( 1 )电阻上消耗的功率( 2 )有源器件的开关转换阶段( 3 )集成电路内部和外部电容的充放电( 4 )系统的性能指标负载能力被处理信号的工作频率电路的工作频率电源的管理水平零部件的性能散热条件接口的物理性能等对系统功耗起着重要的作用

降低功耗的措施

功耗的组成动态 + 静态动态电源管理动态电压缩放低功耗硬件设计低功耗软件设计

二设计方法学概论

问题功 能 性能要求价 格 开发 周 期 等约束

设计 选择 折衷 分析比较 计算 评价

嵌入式系统

0嵌入式系统设计概述

方法 工具

设计方法论( design methodology )

设计方法论有以下三个重要理由1 )确认我们所做的每一件事情都是必须要作的

不会做无谓的白工也不会漏掉关键性的重要工作其中包含效率优化或是功能测试

2 )可以发展出计算机辅助工具或是设计经验累积汲取每一次产品发展的经验再经过量化之后可以发展出一套工具或是方法让往后的产品设计步入自动化

3 )开发团队遵循同一套方法论可以让团队成员更容易彼此沟通每个人都能在短时间内了解整体过程中将经历哪些过程需要何种支持与接收到何种结果此外也容易透过一套已经定义好的方法论彼此相互合作协调

设计目标 1 )上市时间

也就是 time-to-market 的观念2 )设计成本

许多消费性产品对于价格非常敏感所以产品厂商对于成本会斤斤计较是很合理的

3 )品质 顾客也许不需要最快最便宜的产品但是一定会要求功能质量保证不能只用一小段时间就坏掉了

传统的设计主要步骤

2 传统的设计流程方法1 )瀑布模型 (Waterfall)2 )螺旋模型 (Spiral)3 )连续改进 (Successive Refinement)4 )硬件与软件的同步设计 (SWHW Co-

deign)5 )阶层式 (Hierarchical) 设计6 )同步工程( concurrent

engineering )

瀑布模型 (Waterfall)

螺旋模型 (Spiral)

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 8: 大学计算机基础 —— 计算机科学概论

问题 3mdashmdash应用(applications)

特点规范参考设计 理解你的应用是获得嵌入式计算系统最大性能的关键我们可以根据应用的特点去优化设计这个优势可以使我们执行许多有效的优化而这在通用系统中是不可能的但是这也意味着我们必须对应用的特点有足够的认识这样才能在利用特点的同时避免在系统实现过程中产生问题

面向应用的计算( SmartApps An Application Centric Approach to High Performance Computing )

Today System Centric Computing

Application(Algorithm)

Compiler(static)

System(OS amp Arch)

HWOS

CompilerApplication

System-Centric Computing

Development entAnalysis amp

Optimization

Execution

Input Data

Classic Avenues toperformance

Parallel Algorithms Static Compiler Optimization OS support Good Architecture

Whatrsquos missing Compiler are conservative OS offers generic services Architecture is generic

No Global Optimization No matching between ApplicationOSHW Intractable for the general case

SmartApps Application Centric Computing

Application ControlInstance-specific optimization

Compiler + OS + Architecture + Data + Feedback

Application(Algorithm)

Development entAnalysis amp

Optimization

Compiler (static) +run-time techniques

Compiler(run-time)

OS(modular)

Architecture(reconfigurable)

SmartAppApplication

CompilerOS

HW

Run-time SystemExecution Analysis

amp Optimization

Application-Centric Computing

Input Data

Smart Application

SmartApps Architecture

Get Runtime Information(sample input system information etc)

Static CompilerAugmented withruntime techniques

Predictor ampOptimizer

partially compiledcode with unknownsand runtime hooks

Information forrapid simulation

Compute Optimal Applicationand System Configuration

Recompile Applicationandor Reconfigure System

Predictor ampEvaluator

Configurer

Application

Execute Application

Continuous monitorperformance and adaptas necessary

Predictor ampEvaluator

Predictor ampOptimizer

Adaptive Software

Runtime tuning (worecompile or reconfigure)

Small adaptation (tuning)

Large adaptation(failure phase change)

3 Real-time 约束许多 ES 必须满足实时约束什么是实时系统 实时系统是将时间定量化的一个概念实时系统是使用物理时钟来衡

量的当我们使用物理时钟来量化时间时我们就会讨论到实时的概念

与实时相反逻辑时间(也称为虚拟时间)是对时间的一种定性的概念通过使用事件顺序关系来表示例如之前之后某个时候最后在hellip之前接着等等

定义一个系统称为实时系统当我们需要用定量的时间表达式(也就是说实时)来描述这个系统的行为在这个实时系统的定义中隐含的表达了所有的定量的时间度量都是用一个物理时钟测量得到的

任何一个行为可以完全不用任何定量时间表达来描述其行为的系统肯定不是实时系统但一个系统的完整行为可以用它对各种外部刺激的响应列表来描述也就是说一个系统的行为大部分描述根本没有定量的时间表达式仍然被认为是一个实时系统

实时系统的类型根据任务超过截止时间的后果实时系统可以分为 硬实时软实时固实时1 )硬实时当系统执行任务时被强制要求在某个时间范围内要

产生结果换句话说任何时刻硬实时任务没有在制定的时间范围内产生要求的结果那这个系统就被认为失败了

2 )固实时当系统执行任务时与某些预设的截止时间相关联任务要求要在截止时间之前完成结果的计算不同于硬实时任务就算一个固实时任务没有在截止时间之前完成系统也不会失败迟来的结果仅仅是被丢弃了

3 )软实时当系统执行任务时也有与之相关联的时间界限但是不像硬实时和固实时任务软实时任务的时间界限并不是以绝对数值来表示的取而代之的是平均响应时间

Real-Time 系统与嵌入式系统

Embedded and Real-

Time 往往同义 Most embedded

systems are real-time

Most real-time systems are embedded

embeddedembedded

real-timereal-time

embedded embedded real-timereal-time

4 反应系统ES 是一个反应系统 转换系统输入(开始) -gt 软件系统(经过一段时间后停止运行) -gt (然后)输

出即用户把数据输入给计算机软件对这些数据经过一段时间的计算最后给出输出结果

输入数据经过特定的规则被转换并且在结束计算过程以后给出结果 而 reactive system 却与此相反在 reactive system 里往往没有明确的时序安排总体来讲

reactive system 表示的是不限制运行时间的系统这其中要和外部环境相互作用也就是在外部刺激上的反应 (reactive) 例如和不同使用者或者外部的硬件等但是也包括内部发生的交流行为因为 reactive system 是被集成在并行运行的分布式系统的规则中的例如一个计算机的操作系统是这样一个 reactive system 它不会停止运行 而总是反应用户给的输入 并且计算机中的各个组件之间要进行交流

在电信领域生产控制或者在硬件环境的构造(嵌入式系统)中还存在很多这样的例子在信息系统中也就是基于数据库的应用系统中也要用到 reactive system 在给一个典型的例子就是警报系统

5 混成系统Hybrid systems(analog + digital parts)混成系统一般由离散分立组件和连续组件并行或者串

行组成组件之间的行为由计算模型进行控制由于大多数复杂控制系统都包含了由连续变量所描述的物理层的动态演化过程和以符号操作与离散监控决策为特征的高层协调优化过程因此混成系统在工业控制和国防等领域大量存在混成系统定义凡是系统自身具有混合结构并且其

行为(输出和状态)取决于离散事件系统和连续动态系统相互作用的动态系统就称为混成系统

混成系统的典型特征( 1) 系统内存在着性质不同的连续和离散两类变量( 2) 时间和事件共同驱动系统的状态演化 ( 3)连续变量穿越阈值使状态使能或失能 ( 4)离散状态的变化改变连续变量遵循的变化速率 ( 5)离散事件发生在离散时刻 具有顺序选择并发等特色

( 6)状态呈阶段性间歇性切换变化 动态特征显著 ( 7) 对系统的控制表现为对连续状态和离散状态的集成控制 ( 8) 对系统的优化表现为在定性 定量双重指标下的集成优化

6 专用系统 Dedicated towards a certain

applicationKnowledge about behavior at design time can be used to minimize resources and to maximize robustness

Dedicated user interface(no mouse keyboard and screen)

二设计的挑战 实时可信可靠保密安全

1 为什么需要可靠的嵌入式系统1 )许多市场不需要高度可靠的嵌入式计算机但是许多嵌入式计算机必须

是高度可靠的2 )许多嵌入式计算机必须是高度可靠的汽车电子航空电子医疗设备

关键通信3 )可靠性的定义如电话交换机系统每年停机少于 30秒4 )关于可靠数字系统设计的研究几十年前就有不同的体系结构和方法学

被开发用于长周期低失误率的数字系统操作那么传统的可靠计算机和可靠的计算机系统有什么不同呢

5 )可靠嵌入式计算机通常是分布式系统如汽车电子航空电子和医疗设备都是必须高度可靠的分布式嵌入式系统

6 )嵌入式计算机容易受许多新类型攻击可靠计算机传统上是物理上不可访问的服务器或者机器mdashmdash物理安全长期以来是计算机安全的安全策略但是嵌入式计算机通常在非保护环境下操作这就允许新的故障和攻击这些需要都新的保护措施

2 可靠与可信ES 必需是可靠的可信的如何评价与度量

bull可靠性( Reliability) R(t)

bull可维护性( Maintainability) M(d)

bull有效性( Availability ) A(t)

bull安全性( Safety )bull保密性( Security )

可靠性定义可靠性 R(t) 产品在规定条件下和规定时间内完成规定

功能的能力产品可靠性定义的要素是三个ldquo规定rdquo 1 )ldquo规定条件rdquo包括使用时的环境条件

和工作条件2 )ldquo规定时间rdquo是指产品规定了的任务

时间3 )ldquo规定功能rdquo是指产品规定了的必须

具备的功能及其技术指标

1 )ldquo规定条件rdquo包括使用时的环境条件和工作条件 例如同一型号的汽车在高速公路和在崎岖的山路上行驶其可

靠性的表现就不大一样要谈论产品的可靠性必须指明规定的条件是什么2 )ldquo规定时间rdquo是指产品规定了的任务时间 随着产品任务时间的增加产品出现故障的概率将增加

而产品的可靠性将是下降的因此谈论产品的可靠性离不开规定的任务时间例如一辆汽车在在刚刚开出厂子和用了5 年后相比它出故障的概率显然大了很多

3 )ldquo规定功能rdquo是指产品规定了的必须具备的功能及其技术指标所要求产品功能的多少和其技术指标的高低直接影响到产品可靠性指标的高低

例如电风扇的主要功能有转叶摇头定时那么规定的功能是三者都要还是仅需要转叶能转能够吹风所得出的可靠性指标是大不一样的

可维护性 M(d)1 )计算机系统的可维护性是指该系统失效后在规定时间内可

修复到规定功能的能力2 )反映系统可维护性高低的参数是修复率秒平均修复时间3 )软件可维护性即维护人员对该软件进行维护的难易程度

具体包括理解改正改动和改进该软件的难易程度4 )决定可维护性的因素

系统的大小系统的年龄结构合理性

5 )可维护性的度量 可理解性可测试性可修改性可移植性

有效性 A(t)设备的有效性的表式为 设备有效性 = 平均故障间隔期 (平均故障间隔期+平均修理时间)

在逻辑中如果一个论证不能从真前提中得出假结论 则论证的形式是完全有效的

一个论证若被称为是有效的则如果在其中所有前提都为真的每个模型中结论也是真的

例如ldquo所有 A 是 B 有些 A 是 C 所以有些 B 是Crdquo 是有效形式

可用性 实用性

3 可靠系统设计的基本原理1 )故障 (faults) 分析2 )可靠性分析3 )纠错技术4 )软件可靠性

1 )故障 (faults) 分析永久 (permanent) 与暂时( transient )故障故障来源 物理故障 (Physical faults)由生产缺陷辐射危害等等引起

设计故障 (Design faults) 是不合适设计的系统的结果

操作故障 (Operational faults) 来自人为过失安全破坏劣质设计的人机接口等等

可靠性设计

故障及其分类 产品的故障按其故障规律分为两大类

偶然故障 渐变故障

产品的故障按其故障后果分为两大类 致命性故障 非致命性故障

产品的故障按其统计特性分为两大类 独立故障 从属故障

可靠度 产品在规定的条件下和规定的时间内完成规

定功能的概率称为可靠度依定义可知系统的可靠度是时间的函数表示为

式中 R(t)mdashmdash 可靠度函数 ξmdashmdash 产生故障前的工作时间 t mdashmdash 规定的时间

)()( tPtR

2 )可靠性的分析mdashmdash可靠度

可靠度函数

依定义可知可靠度函数 R(t) 为

式中 N0 mdashmdash t = 0 时在规定条件下进行工作的产品数

r(t) mdashmdash  在 0 到 t 时刻的工作时间内产品的累计

故障数

0

0 )()(

N

trNtR

累积故障分布函数 产品在规定的条件下和规定的时间内丧失

规定功能的概率称为累积故障概率(又叫不可靠度) 依定义可知产品的累积故障概率是时间的函

数即

显然以下关系成立

0

)()(

N

trtF

1)()( tFtR

可靠度函数与累积故障分布函数的性质

图 R(t)F(t)与f(t)的关系t

f(t)

f(t)

F(to)

R(to)

to

由密度函数的性质 1)(0

dttf 可知

t

tdttfdttftFtR )()(1)(1)(

0

因此 R(t) F(t) 与 f(t) 之间的关系如图所示

故障率函数 故障率

工作到某时刻尚未发生故障的产品在该时刻后单位时间内发生故障的概率称之为产品的故障率

用数学符号表示为

式中 (t) mdashmdash 故障率 dr(t) mdashmdash t 时刻后 dt 时间内故障的产品数 Ns(t) mdashmdash 残存产品数即到 t 时刻尚未故障的产品

dttN

tdrt

s )(

)()(

35

故障率函数

可按下式进行工程计算

式中 Δr(t) mdashmdash t 时刻后 Δt 时间内故障的产品数

Δt mdashmdash 所取时间间隔 Ns(t) mdashmdash 残存产品数

对于低故障率的元部件常以 10-9h 为故障率的单位称之为菲特( Fit )

ttN

trt

s

)(

)()(

产品故障浴盆曲线 浴盆曲线

大多数产品的故障率随时间的变化曲线形似浴盆称之为浴盆曲线由于产品故障机理的不同产品的故障率随时间的变化大致可以分为三个阶段

产品典型的故障率曲线

t

使用寿命

早期故障

偶然故障 耗损故障

A B规定的故障率 维修后故障率下降

(t)

3 )纠错技术( 1 )纠错码 在 1950s就开始研究最早的是可以检测和纠错的汉明码它们通过数字系统广泛地用于识别和纠正短暂或者持久的错误这些码引入冗余信息来确保一些类型的错误可以被检测和纠正比如一个单错校正 双错校正的码能用一个比特检测和纠正一个错误但是不能用两个比特纠错

( 2 )三模冗余 (triple modular

redundancy) 计算单元 C 有三个副本 C1C2和 C3三个单元接收同

样的输入一个独立单元比较每个输入的结果如果至少两个结果一致那么那个值被表决器选做正确结果如果三个结果都不相同那么就没有正确的结果

1C

2C

3C

表决错误

结果

输入

( 3 )看门狗定时器 (watchdog timer)

看门狗定时器 (watchdog timer)被广泛地用于检测系统问题如图 看门狗定时器连接到一个监视系统如果这个看门狗定时器翻转它产生一个完成信号用于标注系统的错误中断系统应该这样设计当适当运行的时候它一直在可能产生翻转信号之前复位定时器因此来自看门狗定时器的完成信号指示系统在一定程度上不合适地操作看门狗定时器用于预防不同的故障

系统看门狗定时器

完成

复位

( 4 )设计多样性 (Design diversity)

一种用于减少一些系统错误进入设计的设计方法学当一个设计需要给定模块的不同实例应该采用模块的不同实现而不是到处都用同一种模块比如一个有多个 CPU的系统可能采用不同类型的 CPU而不是到处采用同一种类型的 CPU在一个三模冗余系统产生表决结构的组件可能有不同的实现这样可以减少产生同样设计错误的机会

4 )软件可靠性ldquo在规定的条件下在规定的时间内软件不引起失效的概率rdquo

规定的条件 软件运行的软硬件环境 软件操作剖面软件运行的输入空间及其概率分布

规定的时间 日历时间 时钟时间 执行时间

激活软件 输入域 缺陷的数据

软件缺陷 软件

不可接受的结果 (软件故障) 输出域

软件故障的特点

软件与硬件可靠性的区别硬件 软件

故障机理 老化损耗 残留缺陷在一定环境下造成的软件错误

复杂性 内部逻辑较为简单 内部逻辑高度复杂这就在很大程度上决定了设计错误是导致软件故障的主要原因

唯一性 任何两个硬件不可能绝对相同

软件是唯一的软件拷贝不改变软件本身

可靠性的核心 内部元部件 设计者的思维和软件的复杂性纠错维护方法 修复或更换失效的元部件 重设计 可靠性检验标准化

已标准化且有一整套完整的理论

仍未建立更没有完整的理论体系

产品市场 已有成熟的产品市场 产品市场还很新 错误性质 一些瞬间的硬件错误可能

会被误认为是软件错误 软件错误是永恒的可重现的

影响软件可靠性的因素( 1 )运行环境 ( 剖面 )

同一软件在不同运行剖面下其可靠性行为可能极不相同 软件故障是软件缺陷在一定输入情况下被激活的结果 假设软件输入域划分为两个部分 G 和 F 运行剖面不包含 F 中

的输入则软件不会出现故障其可靠性恒为 l 反之如果运行剖面不包含 G 中的输入则每一输入情况下均出现故障如果没有容错措施则 R=0

( 2 )软件规模 随着软件规模的增大软件可靠性问题愈显突出在我们考虑软件

可靠性问题时软件一般是指中型以上软件 (4000-5000条以上语句 ) 这时可靠性问题难以对付

软件工程实践的一个侧面可以反映这一点即单元测试一般由编程人员本人进行而综合测试则需独立的测试人员

影响软件可靠性的因素( 3 )软件内部结构

结构越复杂软件复杂度越高内含缺陷数越大因而软件可靠度越低

( 4 )软件可靠性设计技术 一般是指软件设计阶段中采用的用以保证和提高软件可靠性为主要目标的软件技术

( 5 )软件可靠性测试 研究表明软件测试方法与资源投入对软件可靠性有不可忽视的影

响( 6 )软件可靠性管理

软件可靠性管理旨在系统管理软件生存期各阶段的可靠性活动使之系统化规范化一体化这样就可以避免许多人为错误以提高软件可靠性

影响软件可靠性的因素( 7 )软件开发人员能力和经验

软件开发人员 ( 包括测试人员 ) 的能力愈强经验愈丰富所犯错误便可能愈少所得软件产品质量愈高相应的可靠性也愈高

( 8 )软件开发方法 软件工程表明开发方法对软件可靠性有显著影响 与非结构化方法比较结构化方法可以明显减少软件缺陷数

( 9 )软件开发环境 研究表明程序语言软件开发环境影响软件的可靠性而软件测

试工具的优劣则影响可靠性测试结果

4 安全 (Safety)amp保密 (Security)

安全 (Safety) 是保证财产和人身受到损害可靠性是指在一定的环境条件下以及一定的时间内系统完成特定任务的可能性而有效性则是系统的长期的工作时间于其存在时间 ( 简单的定义为运行时间 +维护时间 ) 的 比例保密 (Security) 是针对危险破坏损失或非法活动而进行措施在一定层面上保密 (Security)要比安全 (Safety)宽广的多例如信息 Security家庭 Security 网络 Security 国家Security) 等

Security强调的是外在事物对特定目标的危害

Safety 是系统本身的潜在危害

四个概念的比较分析安全 (Safety)可靠性 (Reliability)有效性 (Availability)保密 (Security )安全 (Safety)高的系统 软件可靠性不

一定高可靠性和有效性并不是一码事保密 (Security )的系统 软件是安全

(Safety) 系统 软件的重要保障

可靠性安全性保密性 可靠(或可信)系统设计 (Reliable (or dependable) system design)是制造嵌入式系统所关注的甚至在面对内部或者外部问题时可靠系统设计经常假设问题是非恶意引起的

安全重要的系统设计 (Safety-critical system design)研究确保系统安全操作的方法独立于引起问题的原因

保密性 (Security)主要关注恶意攻击

Aizientis等人描述了可信性和保密性间的关系可信性和保密性由几个特性所组成

服务的可用性 (Availability) 服务的连续性 (Continuity) 来自用户和所处环境的灾难性后果的安全性 (Safety) 来自不合适系统改变的完整性 (Integrity) 通过更改和修补的可维护性 (Maintainability) 信息的机密性 (Confidentiality)

可用性完整性

可靠性安全性可维护性

机密性

可信性 保密性

5 新型攻击和对策1 )物理攻击嵌入式系统比通用计算机更容易受攻击 一个关键原因是许多嵌入式计算机对攻击者可物理访问

2 )互联网攻击一些嵌入式系统的攻击通过互联网访问变得更加容易今天许多嵌入式系统连接到互联网

3 )电池攻击 (battery attack)这种攻击试图通过耗尽电池来关闭节点

4 )服务拒绝攻击 (Denial-of-service attacks)

在通用系统中众所周知但是实时嵌入式系统可能更容易受服务质量 (quality-of-service (QoS))攻击如果网络发布实时数据那么发送过程中的一点延迟都能引起数据无效如果那些数据用来实时控制那么这些短暂延迟就能引起系统故障我们称这种危害为时间攻击因为它改变了系统的实时特性

QoS或者时间攻击之所以强大使因为它的影响不仅仅限于信息被控制系统的动态特性可决定系统的响应如果一个大型沉重快速运动的系统被控制那么时间上一个相对小的改变能引起大量的破坏

5 )网络(协议)攻击Wood和 Stankovic[Woo02]在传感器网络上确定了一些方式这些方式可在网络层次的不同层执行拒绝服务攻击如下所列

物理层 (Physical layer)mdashmdash拥塞破坏 链路层 (Link layer)mdashmdash碰撞耗尽非公平

网络和路由层 (Network and routing layer)mdashmdash丢弃和贪婪汇集方向误导黑洞认证监视冗余

传输层 (Transport layer)mdashmdash泛洪失步

6 )能量攻击Kocher等人 [Koc99]指出测量一个 CPU当前的能量供给能在很大程度上确定处理器的内部活动他们提出了两种能量攻击的方法简单能量分析 (simple power analysis)人工地跟踪检查和尝试确定程序作用的位置比如分支基于不同 CUP操作的能耗知识基于程序作用攻击者然后减少密钥的比特差分能量分析 (Differential power analysis)用相关性确定作用和密钥比特这种攻击最初目标是智能卡这种卡从外部读卡器获取能量但是这种攻击也能应用到许多嵌入式系统中

7 )反攻击 在一些时候有可能构造反破坏的嵌入式系统使电子设备难以发觉和分析延缓了攻击者芯片中有限的信息也有助阻止攻击者发现数据

6 Efficiency (效率)

ES must be efficient

bull Code-size efficient( 特别是片上系统 )

bull Run-time efficient

bull Weight efficient

bull Cost efficient

bull Energy efficient

能量有效性的重要意义

ldquoinherent power

efficiency of siliconldquo

59

低功耗设计问题 功耗问题是近几年来人们在嵌入式系统的设计中普遍关注的难点和热点它严重地制约着嵌入式系统的应用与发展

无论是在军事还是在商业贸易上的应用相当数量的嵌入式系统一般是由电池来供给电能的而且大多数嵌入式设备都有体积和质量的约束减少电能消耗不仅能延长电池的使用寿命延长用户更换电池的周期而且能带来提高系统性能与降低系统开销的好处甚至能起到保护环境的作用在便携式设备中 CPU消耗的电能越少电池的寿命就越长同时散发的热量少了所需的散热器就少了从而可减少该设备的花费和体积使产品尽快进入市场的目标

1 低功耗嵌入式应用系统是指以降低系统功耗为一个主要性能指标的嵌入式系统如计算机里的许多芯片过去用 5V供电现在用 33V 18V 并提出了绿色电器的概念

60

低功耗设备的要求1 )首先要求体积小重量轻便于携带2 )采用低功耗电路的设计方法以降低系统的功耗

它除了选用各种低功耗的器件和芯片外还在满足速度等性能指标的前提下进行降低功耗的硬件电路设计和软件设计

3 )有的系统应用在交流供电比较困难甚至无法用交流供电的场合因而各种电池(瓶)就成为其主要供电手段

4 )采用 LCD液晶显示器5 )采用 RS232C串行通信接口6 )采用微功耗高抗干扰的 CMOS集成电路

功耗产生的原因 P=UI

与功耗有关的因素

( 1 )电阻上消耗的功率( 2 )有源器件的开关转换阶段( 3 )集成电路内部和外部电容的充放电( 4 )系统的性能指标负载能力被处理信号的工作频率电路的工作频率电源的管理水平零部件的性能散热条件接口的物理性能等对系统功耗起着重要的作用

降低功耗的措施

功耗的组成动态 + 静态动态电源管理动态电压缩放低功耗硬件设计低功耗软件设计

二设计方法学概论

问题功 能 性能要求价 格 开发 周 期 等约束

设计 选择 折衷 分析比较 计算 评价

嵌入式系统

0嵌入式系统设计概述

方法 工具

设计方法论( design methodology )

设计方法论有以下三个重要理由1 )确认我们所做的每一件事情都是必须要作的

不会做无谓的白工也不会漏掉关键性的重要工作其中包含效率优化或是功能测试

2 )可以发展出计算机辅助工具或是设计经验累积汲取每一次产品发展的经验再经过量化之后可以发展出一套工具或是方法让往后的产品设计步入自动化

3 )开发团队遵循同一套方法论可以让团队成员更容易彼此沟通每个人都能在短时间内了解整体过程中将经历哪些过程需要何种支持与接收到何种结果此外也容易透过一套已经定义好的方法论彼此相互合作协调

设计目标 1 )上市时间

也就是 time-to-market 的观念2 )设计成本

许多消费性产品对于价格非常敏感所以产品厂商对于成本会斤斤计较是很合理的

3 )品质 顾客也许不需要最快最便宜的产品但是一定会要求功能质量保证不能只用一小段时间就坏掉了

传统的设计主要步骤

2 传统的设计流程方法1 )瀑布模型 (Waterfall)2 )螺旋模型 (Spiral)3 )连续改进 (Successive Refinement)4 )硬件与软件的同步设计 (SWHW Co-

deign)5 )阶层式 (Hierarchical) 设计6 )同步工程( concurrent

engineering )

瀑布模型 (Waterfall)

螺旋模型 (Spiral)

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 9: 大学计算机基础 —— 计算机科学概论

Today System Centric Computing

Application(Algorithm)

Compiler(static)

System(OS amp Arch)

HWOS

CompilerApplication

System-Centric Computing

Development entAnalysis amp

Optimization

Execution

Input Data

Classic Avenues toperformance

Parallel Algorithms Static Compiler Optimization OS support Good Architecture

Whatrsquos missing Compiler are conservative OS offers generic services Architecture is generic

No Global Optimization No matching between ApplicationOSHW Intractable for the general case

SmartApps Application Centric Computing

Application ControlInstance-specific optimization

Compiler + OS + Architecture + Data + Feedback

Application(Algorithm)

Development entAnalysis amp

Optimization

Compiler (static) +run-time techniques

Compiler(run-time)

OS(modular)

Architecture(reconfigurable)

SmartAppApplication

CompilerOS

HW

Run-time SystemExecution Analysis

amp Optimization

Application-Centric Computing

Input Data

Smart Application

SmartApps Architecture

Get Runtime Information(sample input system information etc)

Static CompilerAugmented withruntime techniques

Predictor ampOptimizer

partially compiledcode with unknownsand runtime hooks

Information forrapid simulation

Compute Optimal Applicationand System Configuration

Recompile Applicationandor Reconfigure System

Predictor ampEvaluator

Configurer

Application

Execute Application

Continuous monitorperformance and adaptas necessary

Predictor ampEvaluator

Predictor ampOptimizer

Adaptive Software

Runtime tuning (worecompile or reconfigure)

Small adaptation (tuning)

Large adaptation(failure phase change)

3 Real-time 约束许多 ES 必须满足实时约束什么是实时系统 实时系统是将时间定量化的一个概念实时系统是使用物理时钟来衡

量的当我们使用物理时钟来量化时间时我们就会讨论到实时的概念

与实时相反逻辑时间(也称为虚拟时间)是对时间的一种定性的概念通过使用事件顺序关系来表示例如之前之后某个时候最后在hellip之前接着等等

定义一个系统称为实时系统当我们需要用定量的时间表达式(也就是说实时)来描述这个系统的行为在这个实时系统的定义中隐含的表达了所有的定量的时间度量都是用一个物理时钟测量得到的

任何一个行为可以完全不用任何定量时间表达来描述其行为的系统肯定不是实时系统但一个系统的完整行为可以用它对各种外部刺激的响应列表来描述也就是说一个系统的行为大部分描述根本没有定量的时间表达式仍然被认为是一个实时系统

实时系统的类型根据任务超过截止时间的后果实时系统可以分为 硬实时软实时固实时1 )硬实时当系统执行任务时被强制要求在某个时间范围内要

产生结果换句话说任何时刻硬实时任务没有在制定的时间范围内产生要求的结果那这个系统就被认为失败了

2 )固实时当系统执行任务时与某些预设的截止时间相关联任务要求要在截止时间之前完成结果的计算不同于硬实时任务就算一个固实时任务没有在截止时间之前完成系统也不会失败迟来的结果仅仅是被丢弃了

3 )软实时当系统执行任务时也有与之相关联的时间界限但是不像硬实时和固实时任务软实时任务的时间界限并不是以绝对数值来表示的取而代之的是平均响应时间

Real-Time 系统与嵌入式系统

Embedded and Real-

Time 往往同义 Most embedded

systems are real-time

Most real-time systems are embedded

embeddedembedded

real-timereal-time

embedded embedded real-timereal-time

4 反应系统ES 是一个反应系统 转换系统输入(开始) -gt 软件系统(经过一段时间后停止运行) -gt (然后)输

出即用户把数据输入给计算机软件对这些数据经过一段时间的计算最后给出输出结果

输入数据经过特定的规则被转换并且在结束计算过程以后给出结果 而 reactive system 却与此相反在 reactive system 里往往没有明确的时序安排总体来讲

reactive system 表示的是不限制运行时间的系统这其中要和外部环境相互作用也就是在外部刺激上的反应 (reactive) 例如和不同使用者或者外部的硬件等但是也包括内部发生的交流行为因为 reactive system 是被集成在并行运行的分布式系统的规则中的例如一个计算机的操作系统是这样一个 reactive system 它不会停止运行 而总是反应用户给的输入 并且计算机中的各个组件之间要进行交流

在电信领域生产控制或者在硬件环境的构造(嵌入式系统)中还存在很多这样的例子在信息系统中也就是基于数据库的应用系统中也要用到 reactive system 在给一个典型的例子就是警报系统

5 混成系统Hybrid systems(analog + digital parts)混成系统一般由离散分立组件和连续组件并行或者串

行组成组件之间的行为由计算模型进行控制由于大多数复杂控制系统都包含了由连续变量所描述的物理层的动态演化过程和以符号操作与离散监控决策为特征的高层协调优化过程因此混成系统在工业控制和国防等领域大量存在混成系统定义凡是系统自身具有混合结构并且其

行为(输出和状态)取决于离散事件系统和连续动态系统相互作用的动态系统就称为混成系统

混成系统的典型特征( 1) 系统内存在着性质不同的连续和离散两类变量( 2) 时间和事件共同驱动系统的状态演化 ( 3)连续变量穿越阈值使状态使能或失能 ( 4)离散状态的变化改变连续变量遵循的变化速率 ( 5)离散事件发生在离散时刻 具有顺序选择并发等特色

( 6)状态呈阶段性间歇性切换变化 动态特征显著 ( 7) 对系统的控制表现为对连续状态和离散状态的集成控制 ( 8) 对系统的优化表现为在定性 定量双重指标下的集成优化

6 专用系统 Dedicated towards a certain

applicationKnowledge about behavior at design time can be used to minimize resources and to maximize robustness

Dedicated user interface(no mouse keyboard and screen)

二设计的挑战 实时可信可靠保密安全

1 为什么需要可靠的嵌入式系统1 )许多市场不需要高度可靠的嵌入式计算机但是许多嵌入式计算机必须

是高度可靠的2 )许多嵌入式计算机必须是高度可靠的汽车电子航空电子医疗设备

关键通信3 )可靠性的定义如电话交换机系统每年停机少于 30秒4 )关于可靠数字系统设计的研究几十年前就有不同的体系结构和方法学

被开发用于长周期低失误率的数字系统操作那么传统的可靠计算机和可靠的计算机系统有什么不同呢

5 )可靠嵌入式计算机通常是分布式系统如汽车电子航空电子和医疗设备都是必须高度可靠的分布式嵌入式系统

6 )嵌入式计算机容易受许多新类型攻击可靠计算机传统上是物理上不可访问的服务器或者机器mdashmdash物理安全长期以来是计算机安全的安全策略但是嵌入式计算机通常在非保护环境下操作这就允许新的故障和攻击这些需要都新的保护措施

2 可靠与可信ES 必需是可靠的可信的如何评价与度量

bull可靠性( Reliability) R(t)

bull可维护性( Maintainability) M(d)

bull有效性( Availability ) A(t)

bull安全性( Safety )bull保密性( Security )

可靠性定义可靠性 R(t) 产品在规定条件下和规定时间内完成规定

功能的能力产品可靠性定义的要素是三个ldquo规定rdquo 1 )ldquo规定条件rdquo包括使用时的环境条件

和工作条件2 )ldquo规定时间rdquo是指产品规定了的任务

时间3 )ldquo规定功能rdquo是指产品规定了的必须

具备的功能及其技术指标

1 )ldquo规定条件rdquo包括使用时的环境条件和工作条件 例如同一型号的汽车在高速公路和在崎岖的山路上行驶其可

靠性的表现就不大一样要谈论产品的可靠性必须指明规定的条件是什么2 )ldquo规定时间rdquo是指产品规定了的任务时间 随着产品任务时间的增加产品出现故障的概率将增加

而产品的可靠性将是下降的因此谈论产品的可靠性离不开规定的任务时间例如一辆汽车在在刚刚开出厂子和用了5 年后相比它出故障的概率显然大了很多

3 )ldquo规定功能rdquo是指产品规定了的必须具备的功能及其技术指标所要求产品功能的多少和其技术指标的高低直接影响到产品可靠性指标的高低

例如电风扇的主要功能有转叶摇头定时那么规定的功能是三者都要还是仅需要转叶能转能够吹风所得出的可靠性指标是大不一样的

可维护性 M(d)1 )计算机系统的可维护性是指该系统失效后在规定时间内可

修复到规定功能的能力2 )反映系统可维护性高低的参数是修复率秒平均修复时间3 )软件可维护性即维护人员对该软件进行维护的难易程度

具体包括理解改正改动和改进该软件的难易程度4 )决定可维护性的因素

系统的大小系统的年龄结构合理性

5 )可维护性的度量 可理解性可测试性可修改性可移植性

有效性 A(t)设备的有效性的表式为 设备有效性 = 平均故障间隔期 (平均故障间隔期+平均修理时间)

在逻辑中如果一个论证不能从真前提中得出假结论 则论证的形式是完全有效的

一个论证若被称为是有效的则如果在其中所有前提都为真的每个模型中结论也是真的

例如ldquo所有 A 是 B 有些 A 是 C 所以有些 B 是Crdquo 是有效形式

可用性 实用性

3 可靠系统设计的基本原理1 )故障 (faults) 分析2 )可靠性分析3 )纠错技术4 )软件可靠性

1 )故障 (faults) 分析永久 (permanent) 与暂时( transient )故障故障来源 物理故障 (Physical faults)由生产缺陷辐射危害等等引起

设计故障 (Design faults) 是不合适设计的系统的结果

操作故障 (Operational faults) 来自人为过失安全破坏劣质设计的人机接口等等

可靠性设计

故障及其分类 产品的故障按其故障规律分为两大类

偶然故障 渐变故障

产品的故障按其故障后果分为两大类 致命性故障 非致命性故障

产品的故障按其统计特性分为两大类 独立故障 从属故障

可靠度 产品在规定的条件下和规定的时间内完成规

定功能的概率称为可靠度依定义可知系统的可靠度是时间的函数表示为

式中 R(t)mdashmdash 可靠度函数 ξmdashmdash 产生故障前的工作时间 t mdashmdash 规定的时间

)()( tPtR

2 )可靠性的分析mdashmdash可靠度

可靠度函数

依定义可知可靠度函数 R(t) 为

式中 N0 mdashmdash t = 0 时在规定条件下进行工作的产品数

r(t) mdashmdash  在 0 到 t 时刻的工作时间内产品的累计

故障数

0

0 )()(

N

trNtR

累积故障分布函数 产品在规定的条件下和规定的时间内丧失

规定功能的概率称为累积故障概率(又叫不可靠度) 依定义可知产品的累积故障概率是时间的函

数即

显然以下关系成立

0

)()(

N

trtF

1)()( tFtR

可靠度函数与累积故障分布函数的性质

图 R(t)F(t)与f(t)的关系t

f(t)

f(t)

F(to)

R(to)

to

由密度函数的性质 1)(0

dttf 可知

t

tdttfdttftFtR )()(1)(1)(

0

因此 R(t) F(t) 与 f(t) 之间的关系如图所示

故障率函数 故障率

工作到某时刻尚未发生故障的产品在该时刻后单位时间内发生故障的概率称之为产品的故障率

用数学符号表示为

式中 (t) mdashmdash 故障率 dr(t) mdashmdash t 时刻后 dt 时间内故障的产品数 Ns(t) mdashmdash 残存产品数即到 t 时刻尚未故障的产品

dttN

tdrt

s )(

)()(

35

故障率函数

可按下式进行工程计算

式中 Δr(t) mdashmdash t 时刻后 Δt 时间内故障的产品数

Δt mdashmdash 所取时间间隔 Ns(t) mdashmdash 残存产品数

对于低故障率的元部件常以 10-9h 为故障率的单位称之为菲特( Fit )

ttN

trt

s

)(

)()(

产品故障浴盆曲线 浴盆曲线

大多数产品的故障率随时间的变化曲线形似浴盆称之为浴盆曲线由于产品故障机理的不同产品的故障率随时间的变化大致可以分为三个阶段

产品典型的故障率曲线

t

使用寿命

早期故障

偶然故障 耗损故障

A B规定的故障率 维修后故障率下降

(t)

3 )纠错技术( 1 )纠错码 在 1950s就开始研究最早的是可以检测和纠错的汉明码它们通过数字系统广泛地用于识别和纠正短暂或者持久的错误这些码引入冗余信息来确保一些类型的错误可以被检测和纠正比如一个单错校正 双错校正的码能用一个比特检测和纠正一个错误但是不能用两个比特纠错

( 2 )三模冗余 (triple modular

redundancy) 计算单元 C 有三个副本 C1C2和 C3三个单元接收同

样的输入一个独立单元比较每个输入的结果如果至少两个结果一致那么那个值被表决器选做正确结果如果三个结果都不相同那么就没有正确的结果

1C

2C

3C

表决错误

结果

输入

( 3 )看门狗定时器 (watchdog timer)

看门狗定时器 (watchdog timer)被广泛地用于检测系统问题如图 看门狗定时器连接到一个监视系统如果这个看门狗定时器翻转它产生一个完成信号用于标注系统的错误中断系统应该这样设计当适当运行的时候它一直在可能产生翻转信号之前复位定时器因此来自看门狗定时器的完成信号指示系统在一定程度上不合适地操作看门狗定时器用于预防不同的故障

系统看门狗定时器

完成

复位

( 4 )设计多样性 (Design diversity)

一种用于减少一些系统错误进入设计的设计方法学当一个设计需要给定模块的不同实例应该采用模块的不同实现而不是到处都用同一种模块比如一个有多个 CPU的系统可能采用不同类型的 CPU而不是到处采用同一种类型的 CPU在一个三模冗余系统产生表决结构的组件可能有不同的实现这样可以减少产生同样设计错误的机会

4 )软件可靠性ldquo在规定的条件下在规定的时间内软件不引起失效的概率rdquo

规定的条件 软件运行的软硬件环境 软件操作剖面软件运行的输入空间及其概率分布

规定的时间 日历时间 时钟时间 执行时间

激活软件 输入域 缺陷的数据

软件缺陷 软件

不可接受的结果 (软件故障) 输出域

软件故障的特点

软件与硬件可靠性的区别硬件 软件

故障机理 老化损耗 残留缺陷在一定环境下造成的软件错误

复杂性 内部逻辑较为简单 内部逻辑高度复杂这就在很大程度上决定了设计错误是导致软件故障的主要原因

唯一性 任何两个硬件不可能绝对相同

软件是唯一的软件拷贝不改变软件本身

可靠性的核心 内部元部件 设计者的思维和软件的复杂性纠错维护方法 修复或更换失效的元部件 重设计 可靠性检验标准化

已标准化且有一整套完整的理论

仍未建立更没有完整的理论体系

产品市场 已有成熟的产品市场 产品市场还很新 错误性质 一些瞬间的硬件错误可能

会被误认为是软件错误 软件错误是永恒的可重现的

影响软件可靠性的因素( 1 )运行环境 ( 剖面 )

同一软件在不同运行剖面下其可靠性行为可能极不相同 软件故障是软件缺陷在一定输入情况下被激活的结果 假设软件输入域划分为两个部分 G 和 F 运行剖面不包含 F 中

的输入则软件不会出现故障其可靠性恒为 l 反之如果运行剖面不包含 G 中的输入则每一输入情况下均出现故障如果没有容错措施则 R=0

( 2 )软件规模 随着软件规模的增大软件可靠性问题愈显突出在我们考虑软件

可靠性问题时软件一般是指中型以上软件 (4000-5000条以上语句 ) 这时可靠性问题难以对付

软件工程实践的一个侧面可以反映这一点即单元测试一般由编程人员本人进行而综合测试则需独立的测试人员

影响软件可靠性的因素( 3 )软件内部结构

结构越复杂软件复杂度越高内含缺陷数越大因而软件可靠度越低

( 4 )软件可靠性设计技术 一般是指软件设计阶段中采用的用以保证和提高软件可靠性为主要目标的软件技术

( 5 )软件可靠性测试 研究表明软件测试方法与资源投入对软件可靠性有不可忽视的影

响( 6 )软件可靠性管理

软件可靠性管理旨在系统管理软件生存期各阶段的可靠性活动使之系统化规范化一体化这样就可以避免许多人为错误以提高软件可靠性

影响软件可靠性的因素( 7 )软件开发人员能力和经验

软件开发人员 ( 包括测试人员 ) 的能力愈强经验愈丰富所犯错误便可能愈少所得软件产品质量愈高相应的可靠性也愈高

( 8 )软件开发方法 软件工程表明开发方法对软件可靠性有显著影响 与非结构化方法比较结构化方法可以明显减少软件缺陷数

( 9 )软件开发环境 研究表明程序语言软件开发环境影响软件的可靠性而软件测

试工具的优劣则影响可靠性测试结果

4 安全 (Safety)amp保密 (Security)

安全 (Safety) 是保证财产和人身受到损害可靠性是指在一定的环境条件下以及一定的时间内系统完成特定任务的可能性而有效性则是系统的长期的工作时间于其存在时间 ( 简单的定义为运行时间 +维护时间 ) 的 比例保密 (Security) 是针对危险破坏损失或非法活动而进行措施在一定层面上保密 (Security)要比安全 (Safety)宽广的多例如信息 Security家庭 Security 网络 Security 国家Security) 等

Security强调的是外在事物对特定目标的危害

Safety 是系统本身的潜在危害

四个概念的比较分析安全 (Safety)可靠性 (Reliability)有效性 (Availability)保密 (Security )安全 (Safety)高的系统 软件可靠性不

一定高可靠性和有效性并不是一码事保密 (Security )的系统 软件是安全

(Safety) 系统 软件的重要保障

可靠性安全性保密性 可靠(或可信)系统设计 (Reliable (or dependable) system design)是制造嵌入式系统所关注的甚至在面对内部或者外部问题时可靠系统设计经常假设问题是非恶意引起的

安全重要的系统设计 (Safety-critical system design)研究确保系统安全操作的方法独立于引起问题的原因

保密性 (Security)主要关注恶意攻击

Aizientis等人描述了可信性和保密性间的关系可信性和保密性由几个特性所组成

服务的可用性 (Availability) 服务的连续性 (Continuity) 来自用户和所处环境的灾难性后果的安全性 (Safety) 来自不合适系统改变的完整性 (Integrity) 通过更改和修补的可维护性 (Maintainability) 信息的机密性 (Confidentiality)

可用性完整性

可靠性安全性可维护性

机密性

可信性 保密性

5 新型攻击和对策1 )物理攻击嵌入式系统比通用计算机更容易受攻击 一个关键原因是许多嵌入式计算机对攻击者可物理访问

2 )互联网攻击一些嵌入式系统的攻击通过互联网访问变得更加容易今天许多嵌入式系统连接到互联网

3 )电池攻击 (battery attack)这种攻击试图通过耗尽电池来关闭节点

4 )服务拒绝攻击 (Denial-of-service attacks)

在通用系统中众所周知但是实时嵌入式系统可能更容易受服务质量 (quality-of-service (QoS))攻击如果网络发布实时数据那么发送过程中的一点延迟都能引起数据无效如果那些数据用来实时控制那么这些短暂延迟就能引起系统故障我们称这种危害为时间攻击因为它改变了系统的实时特性

QoS或者时间攻击之所以强大使因为它的影响不仅仅限于信息被控制系统的动态特性可决定系统的响应如果一个大型沉重快速运动的系统被控制那么时间上一个相对小的改变能引起大量的破坏

5 )网络(协议)攻击Wood和 Stankovic[Woo02]在传感器网络上确定了一些方式这些方式可在网络层次的不同层执行拒绝服务攻击如下所列

物理层 (Physical layer)mdashmdash拥塞破坏 链路层 (Link layer)mdashmdash碰撞耗尽非公平

网络和路由层 (Network and routing layer)mdashmdash丢弃和贪婪汇集方向误导黑洞认证监视冗余

传输层 (Transport layer)mdashmdash泛洪失步

6 )能量攻击Kocher等人 [Koc99]指出测量一个 CPU当前的能量供给能在很大程度上确定处理器的内部活动他们提出了两种能量攻击的方法简单能量分析 (simple power analysis)人工地跟踪检查和尝试确定程序作用的位置比如分支基于不同 CUP操作的能耗知识基于程序作用攻击者然后减少密钥的比特差分能量分析 (Differential power analysis)用相关性确定作用和密钥比特这种攻击最初目标是智能卡这种卡从外部读卡器获取能量但是这种攻击也能应用到许多嵌入式系统中

7 )反攻击 在一些时候有可能构造反破坏的嵌入式系统使电子设备难以发觉和分析延缓了攻击者芯片中有限的信息也有助阻止攻击者发现数据

6 Efficiency (效率)

ES must be efficient

bull Code-size efficient( 特别是片上系统 )

bull Run-time efficient

bull Weight efficient

bull Cost efficient

bull Energy efficient

能量有效性的重要意义

ldquoinherent power

efficiency of siliconldquo

59

低功耗设计问题 功耗问题是近几年来人们在嵌入式系统的设计中普遍关注的难点和热点它严重地制约着嵌入式系统的应用与发展

无论是在军事还是在商业贸易上的应用相当数量的嵌入式系统一般是由电池来供给电能的而且大多数嵌入式设备都有体积和质量的约束减少电能消耗不仅能延长电池的使用寿命延长用户更换电池的周期而且能带来提高系统性能与降低系统开销的好处甚至能起到保护环境的作用在便携式设备中 CPU消耗的电能越少电池的寿命就越长同时散发的热量少了所需的散热器就少了从而可减少该设备的花费和体积使产品尽快进入市场的目标

1 低功耗嵌入式应用系统是指以降低系统功耗为一个主要性能指标的嵌入式系统如计算机里的许多芯片过去用 5V供电现在用 33V 18V 并提出了绿色电器的概念

60

低功耗设备的要求1 )首先要求体积小重量轻便于携带2 )采用低功耗电路的设计方法以降低系统的功耗

它除了选用各种低功耗的器件和芯片外还在满足速度等性能指标的前提下进行降低功耗的硬件电路设计和软件设计

3 )有的系统应用在交流供电比较困难甚至无法用交流供电的场合因而各种电池(瓶)就成为其主要供电手段

4 )采用 LCD液晶显示器5 )采用 RS232C串行通信接口6 )采用微功耗高抗干扰的 CMOS集成电路

功耗产生的原因 P=UI

与功耗有关的因素

( 1 )电阻上消耗的功率( 2 )有源器件的开关转换阶段( 3 )集成电路内部和外部电容的充放电( 4 )系统的性能指标负载能力被处理信号的工作频率电路的工作频率电源的管理水平零部件的性能散热条件接口的物理性能等对系统功耗起着重要的作用

降低功耗的措施

功耗的组成动态 + 静态动态电源管理动态电压缩放低功耗硬件设计低功耗软件设计

二设计方法学概论

问题功 能 性能要求价 格 开发 周 期 等约束

设计 选择 折衷 分析比较 计算 评价

嵌入式系统

0嵌入式系统设计概述

方法 工具

设计方法论( design methodology )

设计方法论有以下三个重要理由1 )确认我们所做的每一件事情都是必须要作的

不会做无谓的白工也不会漏掉关键性的重要工作其中包含效率优化或是功能测试

2 )可以发展出计算机辅助工具或是设计经验累积汲取每一次产品发展的经验再经过量化之后可以发展出一套工具或是方法让往后的产品设计步入自动化

3 )开发团队遵循同一套方法论可以让团队成员更容易彼此沟通每个人都能在短时间内了解整体过程中将经历哪些过程需要何种支持与接收到何种结果此外也容易透过一套已经定义好的方法论彼此相互合作协调

设计目标 1 )上市时间

也就是 time-to-market 的观念2 )设计成本

许多消费性产品对于价格非常敏感所以产品厂商对于成本会斤斤计较是很合理的

3 )品质 顾客也许不需要最快最便宜的产品但是一定会要求功能质量保证不能只用一小段时间就坏掉了

传统的设计主要步骤

2 传统的设计流程方法1 )瀑布模型 (Waterfall)2 )螺旋模型 (Spiral)3 )连续改进 (Successive Refinement)4 )硬件与软件的同步设计 (SWHW Co-

deign)5 )阶层式 (Hierarchical) 设计6 )同步工程( concurrent

engineering )

瀑布模型 (Waterfall)

螺旋模型 (Spiral)

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 10: 大学计算机基础 —— 计算机科学概论

SmartApps Application Centric Computing

Application ControlInstance-specific optimization

Compiler + OS + Architecture + Data + Feedback

Application(Algorithm)

Development entAnalysis amp

Optimization

Compiler (static) +run-time techniques

Compiler(run-time)

OS(modular)

Architecture(reconfigurable)

SmartAppApplication

CompilerOS

HW

Run-time SystemExecution Analysis

amp Optimization

Application-Centric Computing

Input Data

Smart Application

SmartApps Architecture

Get Runtime Information(sample input system information etc)

Static CompilerAugmented withruntime techniques

Predictor ampOptimizer

partially compiledcode with unknownsand runtime hooks

Information forrapid simulation

Compute Optimal Applicationand System Configuration

Recompile Applicationandor Reconfigure System

Predictor ampEvaluator

Configurer

Application

Execute Application

Continuous monitorperformance and adaptas necessary

Predictor ampEvaluator

Predictor ampOptimizer

Adaptive Software

Runtime tuning (worecompile or reconfigure)

Small adaptation (tuning)

Large adaptation(failure phase change)

3 Real-time 约束许多 ES 必须满足实时约束什么是实时系统 实时系统是将时间定量化的一个概念实时系统是使用物理时钟来衡

量的当我们使用物理时钟来量化时间时我们就会讨论到实时的概念

与实时相反逻辑时间(也称为虚拟时间)是对时间的一种定性的概念通过使用事件顺序关系来表示例如之前之后某个时候最后在hellip之前接着等等

定义一个系统称为实时系统当我们需要用定量的时间表达式(也就是说实时)来描述这个系统的行为在这个实时系统的定义中隐含的表达了所有的定量的时间度量都是用一个物理时钟测量得到的

任何一个行为可以完全不用任何定量时间表达来描述其行为的系统肯定不是实时系统但一个系统的完整行为可以用它对各种外部刺激的响应列表来描述也就是说一个系统的行为大部分描述根本没有定量的时间表达式仍然被认为是一个实时系统

实时系统的类型根据任务超过截止时间的后果实时系统可以分为 硬实时软实时固实时1 )硬实时当系统执行任务时被强制要求在某个时间范围内要

产生结果换句话说任何时刻硬实时任务没有在制定的时间范围内产生要求的结果那这个系统就被认为失败了

2 )固实时当系统执行任务时与某些预设的截止时间相关联任务要求要在截止时间之前完成结果的计算不同于硬实时任务就算一个固实时任务没有在截止时间之前完成系统也不会失败迟来的结果仅仅是被丢弃了

3 )软实时当系统执行任务时也有与之相关联的时间界限但是不像硬实时和固实时任务软实时任务的时间界限并不是以绝对数值来表示的取而代之的是平均响应时间

Real-Time 系统与嵌入式系统

Embedded and Real-

Time 往往同义 Most embedded

systems are real-time

Most real-time systems are embedded

embeddedembedded

real-timereal-time

embedded embedded real-timereal-time

4 反应系统ES 是一个反应系统 转换系统输入(开始) -gt 软件系统(经过一段时间后停止运行) -gt (然后)输

出即用户把数据输入给计算机软件对这些数据经过一段时间的计算最后给出输出结果

输入数据经过特定的规则被转换并且在结束计算过程以后给出结果 而 reactive system 却与此相反在 reactive system 里往往没有明确的时序安排总体来讲

reactive system 表示的是不限制运行时间的系统这其中要和外部环境相互作用也就是在外部刺激上的反应 (reactive) 例如和不同使用者或者外部的硬件等但是也包括内部发生的交流行为因为 reactive system 是被集成在并行运行的分布式系统的规则中的例如一个计算机的操作系统是这样一个 reactive system 它不会停止运行 而总是反应用户给的输入 并且计算机中的各个组件之间要进行交流

在电信领域生产控制或者在硬件环境的构造(嵌入式系统)中还存在很多这样的例子在信息系统中也就是基于数据库的应用系统中也要用到 reactive system 在给一个典型的例子就是警报系统

5 混成系统Hybrid systems(analog + digital parts)混成系统一般由离散分立组件和连续组件并行或者串

行组成组件之间的行为由计算模型进行控制由于大多数复杂控制系统都包含了由连续变量所描述的物理层的动态演化过程和以符号操作与离散监控决策为特征的高层协调优化过程因此混成系统在工业控制和国防等领域大量存在混成系统定义凡是系统自身具有混合结构并且其

行为(输出和状态)取决于离散事件系统和连续动态系统相互作用的动态系统就称为混成系统

混成系统的典型特征( 1) 系统内存在着性质不同的连续和离散两类变量( 2) 时间和事件共同驱动系统的状态演化 ( 3)连续变量穿越阈值使状态使能或失能 ( 4)离散状态的变化改变连续变量遵循的变化速率 ( 5)离散事件发生在离散时刻 具有顺序选择并发等特色

( 6)状态呈阶段性间歇性切换变化 动态特征显著 ( 7) 对系统的控制表现为对连续状态和离散状态的集成控制 ( 8) 对系统的优化表现为在定性 定量双重指标下的集成优化

6 专用系统 Dedicated towards a certain

applicationKnowledge about behavior at design time can be used to minimize resources and to maximize robustness

Dedicated user interface(no mouse keyboard and screen)

二设计的挑战 实时可信可靠保密安全

1 为什么需要可靠的嵌入式系统1 )许多市场不需要高度可靠的嵌入式计算机但是许多嵌入式计算机必须

是高度可靠的2 )许多嵌入式计算机必须是高度可靠的汽车电子航空电子医疗设备

关键通信3 )可靠性的定义如电话交换机系统每年停机少于 30秒4 )关于可靠数字系统设计的研究几十年前就有不同的体系结构和方法学

被开发用于长周期低失误率的数字系统操作那么传统的可靠计算机和可靠的计算机系统有什么不同呢

5 )可靠嵌入式计算机通常是分布式系统如汽车电子航空电子和医疗设备都是必须高度可靠的分布式嵌入式系统

6 )嵌入式计算机容易受许多新类型攻击可靠计算机传统上是物理上不可访问的服务器或者机器mdashmdash物理安全长期以来是计算机安全的安全策略但是嵌入式计算机通常在非保护环境下操作这就允许新的故障和攻击这些需要都新的保护措施

2 可靠与可信ES 必需是可靠的可信的如何评价与度量

bull可靠性( Reliability) R(t)

bull可维护性( Maintainability) M(d)

bull有效性( Availability ) A(t)

bull安全性( Safety )bull保密性( Security )

可靠性定义可靠性 R(t) 产品在规定条件下和规定时间内完成规定

功能的能力产品可靠性定义的要素是三个ldquo规定rdquo 1 )ldquo规定条件rdquo包括使用时的环境条件

和工作条件2 )ldquo规定时间rdquo是指产品规定了的任务

时间3 )ldquo规定功能rdquo是指产品规定了的必须

具备的功能及其技术指标

1 )ldquo规定条件rdquo包括使用时的环境条件和工作条件 例如同一型号的汽车在高速公路和在崎岖的山路上行驶其可

靠性的表现就不大一样要谈论产品的可靠性必须指明规定的条件是什么2 )ldquo规定时间rdquo是指产品规定了的任务时间 随着产品任务时间的增加产品出现故障的概率将增加

而产品的可靠性将是下降的因此谈论产品的可靠性离不开规定的任务时间例如一辆汽车在在刚刚开出厂子和用了5 年后相比它出故障的概率显然大了很多

3 )ldquo规定功能rdquo是指产品规定了的必须具备的功能及其技术指标所要求产品功能的多少和其技术指标的高低直接影响到产品可靠性指标的高低

例如电风扇的主要功能有转叶摇头定时那么规定的功能是三者都要还是仅需要转叶能转能够吹风所得出的可靠性指标是大不一样的

可维护性 M(d)1 )计算机系统的可维护性是指该系统失效后在规定时间内可

修复到规定功能的能力2 )反映系统可维护性高低的参数是修复率秒平均修复时间3 )软件可维护性即维护人员对该软件进行维护的难易程度

具体包括理解改正改动和改进该软件的难易程度4 )决定可维护性的因素

系统的大小系统的年龄结构合理性

5 )可维护性的度量 可理解性可测试性可修改性可移植性

有效性 A(t)设备的有效性的表式为 设备有效性 = 平均故障间隔期 (平均故障间隔期+平均修理时间)

在逻辑中如果一个论证不能从真前提中得出假结论 则论证的形式是完全有效的

一个论证若被称为是有效的则如果在其中所有前提都为真的每个模型中结论也是真的

例如ldquo所有 A 是 B 有些 A 是 C 所以有些 B 是Crdquo 是有效形式

可用性 实用性

3 可靠系统设计的基本原理1 )故障 (faults) 分析2 )可靠性分析3 )纠错技术4 )软件可靠性

1 )故障 (faults) 分析永久 (permanent) 与暂时( transient )故障故障来源 物理故障 (Physical faults)由生产缺陷辐射危害等等引起

设计故障 (Design faults) 是不合适设计的系统的结果

操作故障 (Operational faults) 来自人为过失安全破坏劣质设计的人机接口等等

可靠性设计

故障及其分类 产品的故障按其故障规律分为两大类

偶然故障 渐变故障

产品的故障按其故障后果分为两大类 致命性故障 非致命性故障

产品的故障按其统计特性分为两大类 独立故障 从属故障

可靠度 产品在规定的条件下和规定的时间内完成规

定功能的概率称为可靠度依定义可知系统的可靠度是时间的函数表示为

式中 R(t)mdashmdash 可靠度函数 ξmdashmdash 产生故障前的工作时间 t mdashmdash 规定的时间

)()( tPtR

2 )可靠性的分析mdashmdash可靠度

可靠度函数

依定义可知可靠度函数 R(t) 为

式中 N0 mdashmdash t = 0 时在规定条件下进行工作的产品数

r(t) mdashmdash  在 0 到 t 时刻的工作时间内产品的累计

故障数

0

0 )()(

N

trNtR

累积故障分布函数 产品在规定的条件下和规定的时间内丧失

规定功能的概率称为累积故障概率(又叫不可靠度) 依定义可知产品的累积故障概率是时间的函

数即

显然以下关系成立

0

)()(

N

trtF

1)()( tFtR

可靠度函数与累积故障分布函数的性质

图 R(t)F(t)与f(t)的关系t

f(t)

f(t)

F(to)

R(to)

to

由密度函数的性质 1)(0

dttf 可知

t

tdttfdttftFtR )()(1)(1)(

0

因此 R(t) F(t) 与 f(t) 之间的关系如图所示

故障率函数 故障率

工作到某时刻尚未发生故障的产品在该时刻后单位时间内发生故障的概率称之为产品的故障率

用数学符号表示为

式中 (t) mdashmdash 故障率 dr(t) mdashmdash t 时刻后 dt 时间内故障的产品数 Ns(t) mdashmdash 残存产品数即到 t 时刻尚未故障的产品

dttN

tdrt

s )(

)()(

35

故障率函数

可按下式进行工程计算

式中 Δr(t) mdashmdash t 时刻后 Δt 时间内故障的产品数

Δt mdashmdash 所取时间间隔 Ns(t) mdashmdash 残存产品数

对于低故障率的元部件常以 10-9h 为故障率的单位称之为菲特( Fit )

ttN

trt

s

)(

)()(

产品故障浴盆曲线 浴盆曲线

大多数产品的故障率随时间的变化曲线形似浴盆称之为浴盆曲线由于产品故障机理的不同产品的故障率随时间的变化大致可以分为三个阶段

产品典型的故障率曲线

t

使用寿命

早期故障

偶然故障 耗损故障

A B规定的故障率 维修后故障率下降

(t)

3 )纠错技术( 1 )纠错码 在 1950s就开始研究最早的是可以检测和纠错的汉明码它们通过数字系统广泛地用于识别和纠正短暂或者持久的错误这些码引入冗余信息来确保一些类型的错误可以被检测和纠正比如一个单错校正 双错校正的码能用一个比特检测和纠正一个错误但是不能用两个比特纠错

( 2 )三模冗余 (triple modular

redundancy) 计算单元 C 有三个副本 C1C2和 C3三个单元接收同

样的输入一个独立单元比较每个输入的结果如果至少两个结果一致那么那个值被表决器选做正确结果如果三个结果都不相同那么就没有正确的结果

1C

2C

3C

表决错误

结果

输入

( 3 )看门狗定时器 (watchdog timer)

看门狗定时器 (watchdog timer)被广泛地用于检测系统问题如图 看门狗定时器连接到一个监视系统如果这个看门狗定时器翻转它产生一个完成信号用于标注系统的错误中断系统应该这样设计当适当运行的时候它一直在可能产生翻转信号之前复位定时器因此来自看门狗定时器的完成信号指示系统在一定程度上不合适地操作看门狗定时器用于预防不同的故障

系统看门狗定时器

完成

复位

( 4 )设计多样性 (Design diversity)

一种用于减少一些系统错误进入设计的设计方法学当一个设计需要给定模块的不同实例应该采用模块的不同实现而不是到处都用同一种模块比如一个有多个 CPU的系统可能采用不同类型的 CPU而不是到处采用同一种类型的 CPU在一个三模冗余系统产生表决结构的组件可能有不同的实现这样可以减少产生同样设计错误的机会

4 )软件可靠性ldquo在规定的条件下在规定的时间内软件不引起失效的概率rdquo

规定的条件 软件运行的软硬件环境 软件操作剖面软件运行的输入空间及其概率分布

规定的时间 日历时间 时钟时间 执行时间

激活软件 输入域 缺陷的数据

软件缺陷 软件

不可接受的结果 (软件故障) 输出域

软件故障的特点

软件与硬件可靠性的区别硬件 软件

故障机理 老化损耗 残留缺陷在一定环境下造成的软件错误

复杂性 内部逻辑较为简单 内部逻辑高度复杂这就在很大程度上决定了设计错误是导致软件故障的主要原因

唯一性 任何两个硬件不可能绝对相同

软件是唯一的软件拷贝不改变软件本身

可靠性的核心 内部元部件 设计者的思维和软件的复杂性纠错维护方法 修复或更换失效的元部件 重设计 可靠性检验标准化

已标准化且有一整套完整的理论

仍未建立更没有完整的理论体系

产品市场 已有成熟的产品市场 产品市场还很新 错误性质 一些瞬间的硬件错误可能

会被误认为是软件错误 软件错误是永恒的可重现的

影响软件可靠性的因素( 1 )运行环境 ( 剖面 )

同一软件在不同运行剖面下其可靠性行为可能极不相同 软件故障是软件缺陷在一定输入情况下被激活的结果 假设软件输入域划分为两个部分 G 和 F 运行剖面不包含 F 中

的输入则软件不会出现故障其可靠性恒为 l 反之如果运行剖面不包含 G 中的输入则每一输入情况下均出现故障如果没有容错措施则 R=0

( 2 )软件规模 随着软件规模的增大软件可靠性问题愈显突出在我们考虑软件

可靠性问题时软件一般是指中型以上软件 (4000-5000条以上语句 ) 这时可靠性问题难以对付

软件工程实践的一个侧面可以反映这一点即单元测试一般由编程人员本人进行而综合测试则需独立的测试人员

影响软件可靠性的因素( 3 )软件内部结构

结构越复杂软件复杂度越高内含缺陷数越大因而软件可靠度越低

( 4 )软件可靠性设计技术 一般是指软件设计阶段中采用的用以保证和提高软件可靠性为主要目标的软件技术

( 5 )软件可靠性测试 研究表明软件测试方法与资源投入对软件可靠性有不可忽视的影

响( 6 )软件可靠性管理

软件可靠性管理旨在系统管理软件生存期各阶段的可靠性活动使之系统化规范化一体化这样就可以避免许多人为错误以提高软件可靠性

影响软件可靠性的因素( 7 )软件开发人员能力和经验

软件开发人员 ( 包括测试人员 ) 的能力愈强经验愈丰富所犯错误便可能愈少所得软件产品质量愈高相应的可靠性也愈高

( 8 )软件开发方法 软件工程表明开发方法对软件可靠性有显著影响 与非结构化方法比较结构化方法可以明显减少软件缺陷数

( 9 )软件开发环境 研究表明程序语言软件开发环境影响软件的可靠性而软件测

试工具的优劣则影响可靠性测试结果

4 安全 (Safety)amp保密 (Security)

安全 (Safety) 是保证财产和人身受到损害可靠性是指在一定的环境条件下以及一定的时间内系统完成特定任务的可能性而有效性则是系统的长期的工作时间于其存在时间 ( 简单的定义为运行时间 +维护时间 ) 的 比例保密 (Security) 是针对危险破坏损失或非法活动而进行措施在一定层面上保密 (Security)要比安全 (Safety)宽广的多例如信息 Security家庭 Security 网络 Security 国家Security) 等

Security强调的是外在事物对特定目标的危害

Safety 是系统本身的潜在危害

四个概念的比较分析安全 (Safety)可靠性 (Reliability)有效性 (Availability)保密 (Security )安全 (Safety)高的系统 软件可靠性不

一定高可靠性和有效性并不是一码事保密 (Security )的系统 软件是安全

(Safety) 系统 软件的重要保障

可靠性安全性保密性 可靠(或可信)系统设计 (Reliable (or dependable) system design)是制造嵌入式系统所关注的甚至在面对内部或者外部问题时可靠系统设计经常假设问题是非恶意引起的

安全重要的系统设计 (Safety-critical system design)研究确保系统安全操作的方法独立于引起问题的原因

保密性 (Security)主要关注恶意攻击

Aizientis等人描述了可信性和保密性间的关系可信性和保密性由几个特性所组成

服务的可用性 (Availability) 服务的连续性 (Continuity) 来自用户和所处环境的灾难性后果的安全性 (Safety) 来自不合适系统改变的完整性 (Integrity) 通过更改和修补的可维护性 (Maintainability) 信息的机密性 (Confidentiality)

可用性完整性

可靠性安全性可维护性

机密性

可信性 保密性

5 新型攻击和对策1 )物理攻击嵌入式系统比通用计算机更容易受攻击 一个关键原因是许多嵌入式计算机对攻击者可物理访问

2 )互联网攻击一些嵌入式系统的攻击通过互联网访问变得更加容易今天许多嵌入式系统连接到互联网

3 )电池攻击 (battery attack)这种攻击试图通过耗尽电池来关闭节点

4 )服务拒绝攻击 (Denial-of-service attacks)

在通用系统中众所周知但是实时嵌入式系统可能更容易受服务质量 (quality-of-service (QoS))攻击如果网络发布实时数据那么发送过程中的一点延迟都能引起数据无效如果那些数据用来实时控制那么这些短暂延迟就能引起系统故障我们称这种危害为时间攻击因为它改变了系统的实时特性

QoS或者时间攻击之所以强大使因为它的影响不仅仅限于信息被控制系统的动态特性可决定系统的响应如果一个大型沉重快速运动的系统被控制那么时间上一个相对小的改变能引起大量的破坏

5 )网络(协议)攻击Wood和 Stankovic[Woo02]在传感器网络上确定了一些方式这些方式可在网络层次的不同层执行拒绝服务攻击如下所列

物理层 (Physical layer)mdashmdash拥塞破坏 链路层 (Link layer)mdashmdash碰撞耗尽非公平

网络和路由层 (Network and routing layer)mdashmdash丢弃和贪婪汇集方向误导黑洞认证监视冗余

传输层 (Transport layer)mdashmdash泛洪失步

6 )能量攻击Kocher等人 [Koc99]指出测量一个 CPU当前的能量供给能在很大程度上确定处理器的内部活动他们提出了两种能量攻击的方法简单能量分析 (simple power analysis)人工地跟踪检查和尝试确定程序作用的位置比如分支基于不同 CUP操作的能耗知识基于程序作用攻击者然后减少密钥的比特差分能量分析 (Differential power analysis)用相关性确定作用和密钥比特这种攻击最初目标是智能卡这种卡从外部读卡器获取能量但是这种攻击也能应用到许多嵌入式系统中

7 )反攻击 在一些时候有可能构造反破坏的嵌入式系统使电子设备难以发觉和分析延缓了攻击者芯片中有限的信息也有助阻止攻击者发现数据

6 Efficiency (效率)

ES must be efficient

bull Code-size efficient( 特别是片上系统 )

bull Run-time efficient

bull Weight efficient

bull Cost efficient

bull Energy efficient

能量有效性的重要意义

ldquoinherent power

efficiency of siliconldquo

59

低功耗设计问题 功耗问题是近几年来人们在嵌入式系统的设计中普遍关注的难点和热点它严重地制约着嵌入式系统的应用与发展

无论是在军事还是在商业贸易上的应用相当数量的嵌入式系统一般是由电池来供给电能的而且大多数嵌入式设备都有体积和质量的约束减少电能消耗不仅能延长电池的使用寿命延长用户更换电池的周期而且能带来提高系统性能与降低系统开销的好处甚至能起到保护环境的作用在便携式设备中 CPU消耗的电能越少电池的寿命就越长同时散发的热量少了所需的散热器就少了从而可减少该设备的花费和体积使产品尽快进入市场的目标

1 低功耗嵌入式应用系统是指以降低系统功耗为一个主要性能指标的嵌入式系统如计算机里的许多芯片过去用 5V供电现在用 33V 18V 并提出了绿色电器的概念

60

低功耗设备的要求1 )首先要求体积小重量轻便于携带2 )采用低功耗电路的设计方法以降低系统的功耗

它除了选用各种低功耗的器件和芯片外还在满足速度等性能指标的前提下进行降低功耗的硬件电路设计和软件设计

3 )有的系统应用在交流供电比较困难甚至无法用交流供电的场合因而各种电池(瓶)就成为其主要供电手段

4 )采用 LCD液晶显示器5 )采用 RS232C串行通信接口6 )采用微功耗高抗干扰的 CMOS集成电路

功耗产生的原因 P=UI

与功耗有关的因素

( 1 )电阻上消耗的功率( 2 )有源器件的开关转换阶段( 3 )集成电路内部和外部电容的充放电( 4 )系统的性能指标负载能力被处理信号的工作频率电路的工作频率电源的管理水平零部件的性能散热条件接口的物理性能等对系统功耗起着重要的作用

降低功耗的措施

功耗的组成动态 + 静态动态电源管理动态电压缩放低功耗硬件设计低功耗软件设计

二设计方法学概论

问题功 能 性能要求价 格 开发 周 期 等约束

设计 选择 折衷 分析比较 计算 评价

嵌入式系统

0嵌入式系统设计概述

方法 工具

设计方法论( design methodology )

设计方法论有以下三个重要理由1 )确认我们所做的每一件事情都是必须要作的

不会做无谓的白工也不会漏掉关键性的重要工作其中包含效率优化或是功能测试

2 )可以发展出计算机辅助工具或是设计经验累积汲取每一次产品发展的经验再经过量化之后可以发展出一套工具或是方法让往后的产品设计步入自动化

3 )开发团队遵循同一套方法论可以让团队成员更容易彼此沟通每个人都能在短时间内了解整体过程中将经历哪些过程需要何种支持与接收到何种结果此外也容易透过一套已经定义好的方法论彼此相互合作协调

设计目标 1 )上市时间

也就是 time-to-market 的观念2 )设计成本

许多消费性产品对于价格非常敏感所以产品厂商对于成本会斤斤计较是很合理的

3 )品质 顾客也许不需要最快最便宜的产品但是一定会要求功能质量保证不能只用一小段时间就坏掉了

传统的设计主要步骤

2 传统的设计流程方法1 )瀑布模型 (Waterfall)2 )螺旋模型 (Spiral)3 )连续改进 (Successive Refinement)4 )硬件与软件的同步设计 (SWHW Co-

deign)5 )阶层式 (Hierarchical) 设计6 )同步工程( concurrent

engineering )

瀑布模型 (Waterfall)

螺旋模型 (Spiral)

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 11: 大学计算机基础 —— 计算机科学概论

Smart Application

SmartApps Architecture

Get Runtime Information(sample input system information etc)

Static CompilerAugmented withruntime techniques

Predictor ampOptimizer

partially compiledcode with unknownsand runtime hooks

Information forrapid simulation

Compute Optimal Applicationand System Configuration

Recompile Applicationandor Reconfigure System

Predictor ampEvaluator

Configurer

Application

Execute Application

Continuous monitorperformance and adaptas necessary

Predictor ampEvaluator

Predictor ampOptimizer

Adaptive Software

Runtime tuning (worecompile or reconfigure)

Small adaptation (tuning)

Large adaptation(failure phase change)

3 Real-time 约束许多 ES 必须满足实时约束什么是实时系统 实时系统是将时间定量化的一个概念实时系统是使用物理时钟来衡

量的当我们使用物理时钟来量化时间时我们就会讨论到实时的概念

与实时相反逻辑时间(也称为虚拟时间)是对时间的一种定性的概念通过使用事件顺序关系来表示例如之前之后某个时候最后在hellip之前接着等等

定义一个系统称为实时系统当我们需要用定量的时间表达式(也就是说实时)来描述这个系统的行为在这个实时系统的定义中隐含的表达了所有的定量的时间度量都是用一个物理时钟测量得到的

任何一个行为可以完全不用任何定量时间表达来描述其行为的系统肯定不是实时系统但一个系统的完整行为可以用它对各种外部刺激的响应列表来描述也就是说一个系统的行为大部分描述根本没有定量的时间表达式仍然被认为是一个实时系统

实时系统的类型根据任务超过截止时间的后果实时系统可以分为 硬实时软实时固实时1 )硬实时当系统执行任务时被强制要求在某个时间范围内要

产生结果换句话说任何时刻硬实时任务没有在制定的时间范围内产生要求的结果那这个系统就被认为失败了

2 )固实时当系统执行任务时与某些预设的截止时间相关联任务要求要在截止时间之前完成结果的计算不同于硬实时任务就算一个固实时任务没有在截止时间之前完成系统也不会失败迟来的结果仅仅是被丢弃了

3 )软实时当系统执行任务时也有与之相关联的时间界限但是不像硬实时和固实时任务软实时任务的时间界限并不是以绝对数值来表示的取而代之的是平均响应时间

Real-Time 系统与嵌入式系统

Embedded and Real-

Time 往往同义 Most embedded

systems are real-time

Most real-time systems are embedded

embeddedembedded

real-timereal-time

embedded embedded real-timereal-time

4 反应系统ES 是一个反应系统 转换系统输入(开始) -gt 软件系统(经过一段时间后停止运行) -gt (然后)输

出即用户把数据输入给计算机软件对这些数据经过一段时间的计算最后给出输出结果

输入数据经过特定的规则被转换并且在结束计算过程以后给出结果 而 reactive system 却与此相反在 reactive system 里往往没有明确的时序安排总体来讲

reactive system 表示的是不限制运行时间的系统这其中要和外部环境相互作用也就是在外部刺激上的反应 (reactive) 例如和不同使用者或者外部的硬件等但是也包括内部发生的交流行为因为 reactive system 是被集成在并行运行的分布式系统的规则中的例如一个计算机的操作系统是这样一个 reactive system 它不会停止运行 而总是反应用户给的输入 并且计算机中的各个组件之间要进行交流

在电信领域生产控制或者在硬件环境的构造(嵌入式系统)中还存在很多这样的例子在信息系统中也就是基于数据库的应用系统中也要用到 reactive system 在给一个典型的例子就是警报系统

5 混成系统Hybrid systems(analog + digital parts)混成系统一般由离散分立组件和连续组件并行或者串

行组成组件之间的行为由计算模型进行控制由于大多数复杂控制系统都包含了由连续变量所描述的物理层的动态演化过程和以符号操作与离散监控决策为特征的高层协调优化过程因此混成系统在工业控制和国防等领域大量存在混成系统定义凡是系统自身具有混合结构并且其

行为(输出和状态)取决于离散事件系统和连续动态系统相互作用的动态系统就称为混成系统

混成系统的典型特征( 1) 系统内存在着性质不同的连续和离散两类变量( 2) 时间和事件共同驱动系统的状态演化 ( 3)连续变量穿越阈值使状态使能或失能 ( 4)离散状态的变化改变连续变量遵循的变化速率 ( 5)离散事件发生在离散时刻 具有顺序选择并发等特色

( 6)状态呈阶段性间歇性切换变化 动态特征显著 ( 7) 对系统的控制表现为对连续状态和离散状态的集成控制 ( 8) 对系统的优化表现为在定性 定量双重指标下的集成优化

6 专用系统 Dedicated towards a certain

applicationKnowledge about behavior at design time can be used to minimize resources and to maximize robustness

Dedicated user interface(no mouse keyboard and screen)

二设计的挑战 实时可信可靠保密安全

1 为什么需要可靠的嵌入式系统1 )许多市场不需要高度可靠的嵌入式计算机但是许多嵌入式计算机必须

是高度可靠的2 )许多嵌入式计算机必须是高度可靠的汽车电子航空电子医疗设备

关键通信3 )可靠性的定义如电话交换机系统每年停机少于 30秒4 )关于可靠数字系统设计的研究几十年前就有不同的体系结构和方法学

被开发用于长周期低失误率的数字系统操作那么传统的可靠计算机和可靠的计算机系统有什么不同呢

5 )可靠嵌入式计算机通常是分布式系统如汽车电子航空电子和医疗设备都是必须高度可靠的分布式嵌入式系统

6 )嵌入式计算机容易受许多新类型攻击可靠计算机传统上是物理上不可访问的服务器或者机器mdashmdash物理安全长期以来是计算机安全的安全策略但是嵌入式计算机通常在非保护环境下操作这就允许新的故障和攻击这些需要都新的保护措施

2 可靠与可信ES 必需是可靠的可信的如何评价与度量

bull可靠性( Reliability) R(t)

bull可维护性( Maintainability) M(d)

bull有效性( Availability ) A(t)

bull安全性( Safety )bull保密性( Security )

可靠性定义可靠性 R(t) 产品在规定条件下和规定时间内完成规定

功能的能力产品可靠性定义的要素是三个ldquo规定rdquo 1 )ldquo规定条件rdquo包括使用时的环境条件

和工作条件2 )ldquo规定时间rdquo是指产品规定了的任务

时间3 )ldquo规定功能rdquo是指产品规定了的必须

具备的功能及其技术指标

1 )ldquo规定条件rdquo包括使用时的环境条件和工作条件 例如同一型号的汽车在高速公路和在崎岖的山路上行驶其可

靠性的表现就不大一样要谈论产品的可靠性必须指明规定的条件是什么2 )ldquo规定时间rdquo是指产品规定了的任务时间 随着产品任务时间的增加产品出现故障的概率将增加

而产品的可靠性将是下降的因此谈论产品的可靠性离不开规定的任务时间例如一辆汽车在在刚刚开出厂子和用了5 年后相比它出故障的概率显然大了很多

3 )ldquo规定功能rdquo是指产品规定了的必须具备的功能及其技术指标所要求产品功能的多少和其技术指标的高低直接影响到产品可靠性指标的高低

例如电风扇的主要功能有转叶摇头定时那么规定的功能是三者都要还是仅需要转叶能转能够吹风所得出的可靠性指标是大不一样的

可维护性 M(d)1 )计算机系统的可维护性是指该系统失效后在规定时间内可

修复到规定功能的能力2 )反映系统可维护性高低的参数是修复率秒平均修复时间3 )软件可维护性即维护人员对该软件进行维护的难易程度

具体包括理解改正改动和改进该软件的难易程度4 )决定可维护性的因素

系统的大小系统的年龄结构合理性

5 )可维护性的度量 可理解性可测试性可修改性可移植性

有效性 A(t)设备的有效性的表式为 设备有效性 = 平均故障间隔期 (平均故障间隔期+平均修理时间)

在逻辑中如果一个论证不能从真前提中得出假结论 则论证的形式是完全有效的

一个论证若被称为是有效的则如果在其中所有前提都为真的每个模型中结论也是真的

例如ldquo所有 A 是 B 有些 A 是 C 所以有些 B 是Crdquo 是有效形式

可用性 实用性

3 可靠系统设计的基本原理1 )故障 (faults) 分析2 )可靠性分析3 )纠错技术4 )软件可靠性

1 )故障 (faults) 分析永久 (permanent) 与暂时( transient )故障故障来源 物理故障 (Physical faults)由生产缺陷辐射危害等等引起

设计故障 (Design faults) 是不合适设计的系统的结果

操作故障 (Operational faults) 来自人为过失安全破坏劣质设计的人机接口等等

可靠性设计

故障及其分类 产品的故障按其故障规律分为两大类

偶然故障 渐变故障

产品的故障按其故障后果分为两大类 致命性故障 非致命性故障

产品的故障按其统计特性分为两大类 独立故障 从属故障

可靠度 产品在规定的条件下和规定的时间内完成规

定功能的概率称为可靠度依定义可知系统的可靠度是时间的函数表示为

式中 R(t)mdashmdash 可靠度函数 ξmdashmdash 产生故障前的工作时间 t mdashmdash 规定的时间

)()( tPtR

2 )可靠性的分析mdashmdash可靠度

可靠度函数

依定义可知可靠度函数 R(t) 为

式中 N0 mdashmdash t = 0 时在规定条件下进行工作的产品数

r(t) mdashmdash  在 0 到 t 时刻的工作时间内产品的累计

故障数

0

0 )()(

N

trNtR

累积故障分布函数 产品在规定的条件下和规定的时间内丧失

规定功能的概率称为累积故障概率(又叫不可靠度) 依定义可知产品的累积故障概率是时间的函

数即

显然以下关系成立

0

)()(

N

trtF

1)()( tFtR

可靠度函数与累积故障分布函数的性质

图 R(t)F(t)与f(t)的关系t

f(t)

f(t)

F(to)

R(to)

to

由密度函数的性质 1)(0

dttf 可知

t

tdttfdttftFtR )()(1)(1)(

0

因此 R(t) F(t) 与 f(t) 之间的关系如图所示

故障率函数 故障率

工作到某时刻尚未发生故障的产品在该时刻后单位时间内发生故障的概率称之为产品的故障率

用数学符号表示为

式中 (t) mdashmdash 故障率 dr(t) mdashmdash t 时刻后 dt 时间内故障的产品数 Ns(t) mdashmdash 残存产品数即到 t 时刻尚未故障的产品

dttN

tdrt

s )(

)()(

35

故障率函数

可按下式进行工程计算

式中 Δr(t) mdashmdash t 时刻后 Δt 时间内故障的产品数

Δt mdashmdash 所取时间间隔 Ns(t) mdashmdash 残存产品数

对于低故障率的元部件常以 10-9h 为故障率的单位称之为菲特( Fit )

ttN

trt

s

)(

)()(

产品故障浴盆曲线 浴盆曲线

大多数产品的故障率随时间的变化曲线形似浴盆称之为浴盆曲线由于产品故障机理的不同产品的故障率随时间的变化大致可以分为三个阶段

产品典型的故障率曲线

t

使用寿命

早期故障

偶然故障 耗损故障

A B规定的故障率 维修后故障率下降

(t)

3 )纠错技术( 1 )纠错码 在 1950s就开始研究最早的是可以检测和纠错的汉明码它们通过数字系统广泛地用于识别和纠正短暂或者持久的错误这些码引入冗余信息来确保一些类型的错误可以被检测和纠正比如一个单错校正 双错校正的码能用一个比特检测和纠正一个错误但是不能用两个比特纠错

( 2 )三模冗余 (triple modular

redundancy) 计算单元 C 有三个副本 C1C2和 C3三个单元接收同

样的输入一个独立单元比较每个输入的结果如果至少两个结果一致那么那个值被表决器选做正确结果如果三个结果都不相同那么就没有正确的结果

1C

2C

3C

表决错误

结果

输入

( 3 )看门狗定时器 (watchdog timer)

看门狗定时器 (watchdog timer)被广泛地用于检测系统问题如图 看门狗定时器连接到一个监视系统如果这个看门狗定时器翻转它产生一个完成信号用于标注系统的错误中断系统应该这样设计当适当运行的时候它一直在可能产生翻转信号之前复位定时器因此来自看门狗定时器的完成信号指示系统在一定程度上不合适地操作看门狗定时器用于预防不同的故障

系统看门狗定时器

完成

复位

( 4 )设计多样性 (Design diversity)

一种用于减少一些系统错误进入设计的设计方法学当一个设计需要给定模块的不同实例应该采用模块的不同实现而不是到处都用同一种模块比如一个有多个 CPU的系统可能采用不同类型的 CPU而不是到处采用同一种类型的 CPU在一个三模冗余系统产生表决结构的组件可能有不同的实现这样可以减少产生同样设计错误的机会

4 )软件可靠性ldquo在规定的条件下在规定的时间内软件不引起失效的概率rdquo

规定的条件 软件运行的软硬件环境 软件操作剖面软件运行的输入空间及其概率分布

规定的时间 日历时间 时钟时间 执行时间

激活软件 输入域 缺陷的数据

软件缺陷 软件

不可接受的结果 (软件故障) 输出域

软件故障的特点

软件与硬件可靠性的区别硬件 软件

故障机理 老化损耗 残留缺陷在一定环境下造成的软件错误

复杂性 内部逻辑较为简单 内部逻辑高度复杂这就在很大程度上决定了设计错误是导致软件故障的主要原因

唯一性 任何两个硬件不可能绝对相同

软件是唯一的软件拷贝不改变软件本身

可靠性的核心 内部元部件 设计者的思维和软件的复杂性纠错维护方法 修复或更换失效的元部件 重设计 可靠性检验标准化

已标准化且有一整套完整的理论

仍未建立更没有完整的理论体系

产品市场 已有成熟的产品市场 产品市场还很新 错误性质 一些瞬间的硬件错误可能

会被误认为是软件错误 软件错误是永恒的可重现的

影响软件可靠性的因素( 1 )运行环境 ( 剖面 )

同一软件在不同运行剖面下其可靠性行为可能极不相同 软件故障是软件缺陷在一定输入情况下被激活的结果 假设软件输入域划分为两个部分 G 和 F 运行剖面不包含 F 中

的输入则软件不会出现故障其可靠性恒为 l 反之如果运行剖面不包含 G 中的输入则每一输入情况下均出现故障如果没有容错措施则 R=0

( 2 )软件规模 随着软件规模的增大软件可靠性问题愈显突出在我们考虑软件

可靠性问题时软件一般是指中型以上软件 (4000-5000条以上语句 ) 这时可靠性问题难以对付

软件工程实践的一个侧面可以反映这一点即单元测试一般由编程人员本人进行而综合测试则需独立的测试人员

影响软件可靠性的因素( 3 )软件内部结构

结构越复杂软件复杂度越高内含缺陷数越大因而软件可靠度越低

( 4 )软件可靠性设计技术 一般是指软件设计阶段中采用的用以保证和提高软件可靠性为主要目标的软件技术

( 5 )软件可靠性测试 研究表明软件测试方法与资源投入对软件可靠性有不可忽视的影

响( 6 )软件可靠性管理

软件可靠性管理旨在系统管理软件生存期各阶段的可靠性活动使之系统化规范化一体化这样就可以避免许多人为错误以提高软件可靠性

影响软件可靠性的因素( 7 )软件开发人员能力和经验

软件开发人员 ( 包括测试人员 ) 的能力愈强经验愈丰富所犯错误便可能愈少所得软件产品质量愈高相应的可靠性也愈高

( 8 )软件开发方法 软件工程表明开发方法对软件可靠性有显著影响 与非结构化方法比较结构化方法可以明显减少软件缺陷数

( 9 )软件开发环境 研究表明程序语言软件开发环境影响软件的可靠性而软件测

试工具的优劣则影响可靠性测试结果

4 安全 (Safety)amp保密 (Security)

安全 (Safety) 是保证财产和人身受到损害可靠性是指在一定的环境条件下以及一定的时间内系统完成特定任务的可能性而有效性则是系统的长期的工作时间于其存在时间 ( 简单的定义为运行时间 +维护时间 ) 的 比例保密 (Security) 是针对危险破坏损失或非法活动而进行措施在一定层面上保密 (Security)要比安全 (Safety)宽广的多例如信息 Security家庭 Security 网络 Security 国家Security) 等

Security强调的是外在事物对特定目标的危害

Safety 是系统本身的潜在危害

四个概念的比较分析安全 (Safety)可靠性 (Reliability)有效性 (Availability)保密 (Security )安全 (Safety)高的系统 软件可靠性不

一定高可靠性和有效性并不是一码事保密 (Security )的系统 软件是安全

(Safety) 系统 软件的重要保障

可靠性安全性保密性 可靠(或可信)系统设计 (Reliable (or dependable) system design)是制造嵌入式系统所关注的甚至在面对内部或者外部问题时可靠系统设计经常假设问题是非恶意引起的

安全重要的系统设计 (Safety-critical system design)研究确保系统安全操作的方法独立于引起问题的原因

保密性 (Security)主要关注恶意攻击

Aizientis等人描述了可信性和保密性间的关系可信性和保密性由几个特性所组成

服务的可用性 (Availability) 服务的连续性 (Continuity) 来自用户和所处环境的灾难性后果的安全性 (Safety) 来自不合适系统改变的完整性 (Integrity) 通过更改和修补的可维护性 (Maintainability) 信息的机密性 (Confidentiality)

可用性完整性

可靠性安全性可维护性

机密性

可信性 保密性

5 新型攻击和对策1 )物理攻击嵌入式系统比通用计算机更容易受攻击 一个关键原因是许多嵌入式计算机对攻击者可物理访问

2 )互联网攻击一些嵌入式系统的攻击通过互联网访问变得更加容易今天许多嵌入式系统连接到互联网

3 )电池攻击 (battery attack)这种攻击试图通过耗尽电池来关闭节点

4 )服务拒绝攻击 (Denial-of-service attacks)

在通用系统中众所周知但是实时嵌入式系统可能更容易受服务质量 (quality-of-service (QoS))攻击如果网络发布实时数据那么发送过程中的一点延迟都能引起数据无效如果那些数据用来实时控制那么这些短暂延迟就能引起系统故障我们称这种危害为时间攻击因为它改变了系统的实时特性

QoS或者时间攻击之所以强大使因为它的影响不仅仅限于信息被控制系统的动态特性可决定系统的响应如果一个大型沉重快速运动的系统被控制那么时间上一个相对小的改变能引起大量的破坏

5 )网络(协议)攻击Wood和 Stankovic[Woo02]在传感器网络上确定了一些方式这些方式可在网络层次的不同层执行拒绝服务攻击如下所列

物理层 (Physical layer)mdashmdash拥塞破坏 链路层 (Link layer)mdashmdash碰撞耗尽非公平

网络和路由层 (Network and routing layer)mdashmdash丢弃和贪婪汇集方向误导黑洞认证监视冗余

传输层 (Transport layer)mdashmdash泛洪失步

6 )能量攻击Kocher等人 [Koc99]指出测量一个 CPU当前的能量供给能在很大程度上确定处理器的内部活动他们提出了两种能量攻击的方法简单能量分析 (simple power analysis)人工地跟踪检查和尝试确定程序作用的位置比如分支基于不同 CUP操作的能耗知识基于程序作用攻击者然后减少密钥的比特差分能量分析 (Differential power analysis)用相关性确定作用和密钥比特这种攻击最初目标是智能卡这种卡从外部读卡器获取能量但是这种攻击也能应用到许多嵌入式系统中

7 )反攻击 在一些时候有可能构造反破坏的嵌入式系统使电子设备难以发觉和分析延缓了攻击者芯片中有限的信息也有助阻止攻击者发现数据

6 Efficiency (效率)

ES must be efficient

bull Code-size efficient( 特别是片上系统 )

bull Run-time efficient

bull Weight efficient

bull Cost efficient

bull Energy efficient

能量有效性的重要意义

ldquoinherent power

efficiency of siliconldquo

59

低功耗设计问题 功耗问题是近几年来人们在嵌入式系统的设计中普遍关注的难点和热点它严重地制约着嵌入式系统的应用与发展

无论是在军事还是在商业贸易上的应用相当数量的嵌入式系统一般是由电池来供给电能的而且大多数嵌入式设备都有体积和质量的约束减少电能消耗不仅能延长电池的使用寿命延长用户更换电池的周期而且能带来提高系统性能与降低系统开销的好处甚至能起到保护环境的作用在便携式设备中 CPU消耗的电能越少电池的寿命就越长同时散发的热量少了所需的散热器就少了从而可减少该设备的花费和体积使产品尽快进入市场的目标

1 低功耗嵌入式应用系统是指以降低系统功耗为一个主要性能指标的嵌入式系统如计算机里的许多芯片过去用 5V供电现在用 33V 18V 并提出了绿色电器的概念

60

低功耗设备的要求1 )首先要求体积小重量轻便于携带2 )采用低功耗电路的设计方法以降低系统的功耗

它除了选用各种低功耗的器件和芯片外还在满足速度等性能指标的前提下进行降低功耗的硬件电路设计和软件设计

3 )有的系统应用在交流供电比较困难甚至无法用交流供电的场合因而各种电池(瓶)就成为其主要供电手段

4 )采用 LCD液晶显示器5 )采用 RS232C串行通信接口6 )采用微功耗高抗干扰的 CMOS集成电路

功耗产生的原因 P=UI

与功耗有关的因素

( 1 )电阻上消耗的功率( 2 )有源器件的开关转换阶段( 3 )集成电路内部和外部电容的充放电( 4 )系统的性能指标负载能力被处理信号的工作频率电路的工作频率电源的管理水平零部件的性能散热条件接口的物理性能等对系统功耗起着重要的作用

降低功耗的措施

功耗的组成动态 + 静态动态电源管理动态电压缩放低功耗硬件设计低功耗软件设计

二设计方法学概论

问题功 能 性能要求价 格 开发 周 期 等约束

设计 选择 折衷 分析比较 计算 评价

嵌入式系统

0嵌入式系统设计概述

方法 工具

设计方法论( design methodology )

设计方法论有以下三个重要理由1 )确认我们所做的每一件事情都是必须要作的

不会做无谓的白工也不会漏掉关键性的重要工作其中包含效率优化或是功能测试

2 )可以发展出计算机辅助工具或是设计经验累积汲取每一次产品发展的经验再经过量化之后可以发展出一套工具或是方法让往后的产品设计步入自动化

3 )开发团队遵循同一套方法论可以让团队成员更容易彼此沟通每个人都能在短时间内了解整体过程中将经历哪些过程需要何种支持与接收到何种结果此外也容易透过一套已经定义好的方法论彼此相互合作协调

设计目标 1 )上市时间

也就是 time-to-market 的观念2 )设计成本

许多消费性产品对于价格非常敏感所以产品厂商对于成本会斤斤计较是很合理的

3 )品质 顾客也许不需要最快最便宜的产品但是一定会要求功能质量保证不能只用一小段时间就坏掉了

传统的设计主要步骤

2 传统的设计流程方法1 )瀑布模型 (Waterfall)2 )螺旋模型 (Spiral)3 )连续改进 (Successive Refinement)4 )硬件与软件的同步设计 (SWHW Co-

deign)5 )阶层式 (Hierarchical) 设计6 )同步工程( concurrent

engineering )

瀑布模型 (Waterfall)

螺旋模型 (Spiral)

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 12: 大学计算机基础 —— 计算机科学概论

3 Real-time 约束许多 ES 必须满足实时约束什么是实时系统 实时系统是将时间定量化的一个概念实时系统是使用物理时钟来衡

量的当我们使用物理时钟来量化时间时我们就会讨论到实时的概念

与实时相反逻辑时间(也称为虚拟时间)是对时间的一种定性的概念通过使用事件顺序关系来表示例如之前之后某个时候最后在hellip之前接着等等

定义一个系统称为实时系统当我们需要用定量的时间表达式(也就是说实时)来描述这个系统的行为在这个实时系统的定义中隐含的表达了所有的定量的时间度量都是用一个物理时钟测量得到的

任何一个行为可以完全不用任何定量时间表达来描述其行为的系统肯定不是实时系统但一个系统的完整行为可以用它对各种外部刺激的响应列表来描述也就是说一个系统的行为大部分描述根本没有定量的时间表达式仍然被认为是一个实时系统

实时系统的类型根据任务超过截止时间的后果实时系统可以分为 硬实时软实时固实时1 )硬实时当系统执行任务时被强制要求在某个时间范围内要

产生结果换句话说任何时刻硬实时任务没有在制定的时间范围内产生要求的结果那这个系统就被认为失败了

2 )固实时当系统执行任务时与某些预设的截止时间相关联任务要求要在截止时间之前完成结果的计算不同于硬实时任务就算一个固实时任务没有在截止时间之前完成系统也不会失败迟来的结果仅仅是被丢弃了

3 )软实时当系统执行任务时也有与之相关联的时间界限但是不像硬实时和固实时任务软实时任务的时间界限并不是以绝对数值来表示的取而代之的是平均响应时间

Real-Time 系统与嵌入式系统

Embedded and Real-

Time 往往同义 Most embedded

systems are real-time

Most real-time systems are embedded

embeddedembedded

real-timereal-time

embedded embedded real-timereal-time

4 反应系统ES 是一个反应系统 转换系统输入(开始) -gt 软件系统(经过一段时间后停止运行) -gt (然后)输

出即用户把数据输入给计算机软件对这些数据经过一段时间的计算最后给出输出结果

输入数据经过特定的规则被转换并且在结束计算过程以后给出结果 而 reactive system 却与此相反在 reactive system 里往往没有明确的时序安排总体来讲

reactive system 表示的是不限制运行时间的系统这其中要和外部环境相互作用也就是在外部刺激上的反应 (reactive) 例如和不同使用者或者外部的硬件等但是也包括内部发生的交流行为因为 reactive system 是被集成在并行运行的分布式系统的规则中的例如一个计算机的操作系统是这样一个 reactive system 它不会停止运行 而总是反应用户给的输入 并且计算机中的各个组件之间要进行交流

在电信领域生产控制或者在硬件环境的构造(嵌入式系统)中还存在很多这样的例子在信息系统中也就是基于数据库的应用系统中也要用到 reactive system 在给一个典型的例子就是警报系统

5 混成系统Hybrid systems(analog + digital parts)混成系统一般由离散分立组件和连续组件并行或者串

行组成组件之间的行为由计算模型进行控制由于大多数复杂控制系统都包含了由连续变量所描述的物理层的动态演化过程和以符号操作与离散监控决策为特征的高层协调优化过程因此混成系统在工业控制和国防等领域大量存在混成系统定义凡是系统自身具有混合结构并且其

行为(输出和状态)取决于离散事件系统和连续动态系统相互作用的动态系统就称为混成系统

混成系统的典型特征( 1) 系统内存在着性质不同的连续和离散两类变量( 2) 时间和事件共同驱动系统的状态演化 ( 3)连续变量穿越阈值使状态使能或失能 ( 4)离散状态的变化改变连续变量遵循的变化速率 ( 5)离散事件发生在离散时刻 具有顺序选择并发等特色

( 6)状态呈阶段性间歇性切换变化 动态特征显著 ( 7) 对系统的控制表现为对连续状态和离散状态的集成控制 ( 8) 对系统的优化表现为在定性 定量双重指标下的集成优化

6 专用系统 Dedicated towards a certain

applicationKnowledge about behavior at design time can be used to minimize resources and to maximize robustness

Dedicated user interface(no mouse keyboard and screen)

二设计的挑战 实时可信可靠保密安全

1 为什么需要可靠的嵌入式系统1 )许多市场不需要高度可靠的嵌入式计算机但是许多嵌入式计算机必须

是高度可靠的2 )许多嵌入式计算机必须是高度可靠的汽车电子航空电子医疗设备

关键通信3 )可靠性的定义如电话交换机系统每年停机少于 30秒4 )关于可靠数字系统设计的研究几十年前就有不同的体系结构和方法学

被开发用于长周期低失误率的数字系统操作那么传统的可靠计算机和可靠的计算机系统有什么不同呢

5 )可靠嵌入式计算机通常是分布式系统如汽车电子航空电子和医疗设备都是必须高度可靠的分布式嵌入式系统

6 )嵌入式计算机容易受许多新类型攻击可靠计算机传统上是物理上不可访问的服务器或者机器mdashmdash物理安全长期以来是计算机安全的安全策略但是嵌入式计算机通常在非保护环境下操作这就允许新的故障和攻击这些需要都新的保护措施

2 可靠与可信ES 必需是可靠的可信的如何评价与度量

bull可靠性( Reliability) R(t)

bull可维护性( Maintainability) M(d)

bull有效性( Availability ) A(t)

bull安全性( Safety )bull保密性( Security )

可靠性定义可靠性 R(t) 产品在规定条件下和规定时间内完成规定

功能的能力产品可靠性定义的要素是三个ldquo规定rdquo 1 )ldquo规定条件rdquo包括使用时的环境条件

和工作条件2 )ldquo规定时间rdquo是指产品规定了的任务

时间3 )ldquo规定功能rdquo是指产品规定了的必须

具备的功能及其技术指标

1 )ldquo规定条件rdquo包括使用时的环境条件和工作条件 例如同一型号的汽车在高速公路和在崎岖的山路上行驶其可

靠性的表现就不大一样要谈论产品的可靠性必须指明规定的条件是什么2 )ldquo规定时间rdquo是指产品规定了的任务时间 随着产品任务时间的增加产品出现故障的概率将增加

而产品的可靠性将是下降的因此谈论产品的可靠性离不开规定的任务时间例如一辆汽车在在刚刚开出厂子和用了5 年后相比它出故障的概率显然大了很多

3 )ldquo规定功能rdquo是指产品规定了的必须具备的功能及其技术指标所要求产品功能的多少和其技术指标的高低直接影响到产品可靠性指标的高低

例如电风扇的主要功能有转叶摇头定时那么规定的功能是三者都要还是仅需要转叶能转能够吹风所得出的可靠性指标是大不一样的

可维护性 M(d)1 )计算机系统的可维护性是指该系统失效后在规定时间内可

修复到规定功能的能力2 )反映系统可维护性高低的参数是修复率秒平均修复时间3 )软件可维护性即维护人员对该软件进行维护的难易程度

具体包括理解改正改动和改进该软件的难易程度4 )决定可维护性的因素

系统的大小系统的年龄结构合理性

5 )可维护性的度量 可理解性可测试性可修改性可移植性

有效性 A(t)设备的有效性的表式为 设备有效性 = 平均故障间隔期 (平均故障间隔期+平均修理时间)

在逻辑中如果一个论证不能从真前提中得出假结论 则论证的形式是完全有效的

一个论证若被称为是有效的则如果在其中所有前提都为真的每个模型中结论也是真的

例如ldquo所有 A 是 B 有些 A 是 C 所以有些 B 是Crdquo 是有效形式

可用性 实用性

3 可靠系统设计的基本原理1 )故障 (faults) 分析2 )可靠性分析3 )纠错技术4 )软件可靠性

1 )故障 (faults) 分析永久 (permanent) 与暂时( transient )故障故障来源 物理故障 (Physical faults)由生产缺陷辐射危害等等引起

设计故障 (Design faults) 是不合适设计的系统的结果

操作故障 (Operational faults) 来自人为过失安全破坏劣质设计的人机接口等等

可靠性设计

故障及其分类 产品的故障按其故障规律分为两大类

偶然故障 渐变故障

产品的故障按其故障后果分为两大类 致命性故障 非致命性故障

产品的故障按其统计特性分为两大类 独立故障 从属故障

可靠度 产品在规定的条件下和规定的时间内完成规

定功能的概率称为可靠度依定义可知系统的可靠度是时间的函数表示为

式中 R(t)mdashmdash 可靠度函数 ξmdashmdash 产生故障前的工作时间 t mdashmdash 规定的时间

)()( tPtR

2 )可靠性的分析mdashmdash可靠度

可靠度函数

依定义可知可靠度函数 R(t) 为

式中 N0 mdashmdash t = 0 时在规定条件下进行工作的产品数

r(t) mdashmdash  在 0 到 t 时刻的工作时间内产品的累计

故障数

0

0 )()(

N

trNtR

累积故障分布函数 产品在规定的条件下和规定的时间内丧失

规定功能的概率称为累积故障概率(又叫不可靠度) 依定义可知产品的累积故障概率是时间的函

数即

显然以下关系成立

0

)()(

N

trtF

1)()( tFtR

可靠度函数与累积故障分布函数的性质

图 R(t)F(t)与f(t)的关系t

f(t)

f(t)

F(to)

R(to)

to

由密度函数的性质 1)(0

dttf 可知

t

tdttfdttftFtR )()(1)(1)(

0

因此 R(t) F(t) 与 f(t) 之间的关系如图所示

故障率函数 故障率

工作到某时刻尚未发生故障的产品在该时刻后单位时间内发生故障的概率称之为产品的故障率

用数学符号表示为

式中 (t) mdashmdash 故障率 dr(t) mdashmdash t 时刻后 dt 时间内故障的产品数 Ns(t) mdashmdash 残存产品数即到 t 时刻尚未故障的产品

dttN

tdrt

s )(

)()(

35

故障率函数

可按下式进行工程计算

式中 Δr(t) mdashmdash t 时刻后 Δt 时间内故障的产品数

Δt mdashmdash 所取时间间隔 Ns(t) mdashmdash 残存产品数

对于低故障率的元部件常以 10-9h 为故障率的单位称之为菲特( Fit )

ttN

trt

s

)(

)()(

产品故障浴盆曲线 浴盆曲线

大多数产品的故障率随时间的变化曲线形似浴盆称之为浴盆曲线由于产品故障机理的不同产品的故障率随时间的变化大致可以分为三个阶段

产品典型的故障率曲线

t

使用寿命

早期故障

偶然故障 耗损故障

A B规定的故障率 维修后故障率下降

(t)

3 )纠错技术( 1 )纠错码 在 1950s就开始研究最早的是可以检测和纠错的汉明码它们通过数字系统广泛地用于识别和纠正短暂或者持久的错误这些码引入冗余信息来确保一些类型的错误可以被检测和纠正比如一个单错校正 双错校正的码能用一个比特检测和纠正一个错误但是不能用两个比特纠错

( 2 )三模冗余 (triple modular

redundancy) 计算单元 C 有三个副本 C1C2和 C3三个单元接收同

样的输入一个独立单元比较每个输入的结果如果至少两个结果一致那么那个值被表决器选做正确结果如果三个结果都不相同那么就没有正确的结果

1C

2C

3C

表决错误

结果

输入

( 3 )看门狗定时器 (watchdog timer)

看门狗定时器 (watchdog timer)被广泛地用于检测系统问题如图 看门狗定时器连接到一个监视系统如果这个看门狗定时器翻转它产生一个完成信号用于标注系统的错误中断系统应该这样设计当适当运行的时候它一直在可能产生翻转信号之前复位定时器因此来自看门狗定时器的完成信号指示系统在一定程度上不合适地操作看门狗定时器用于预防不同的故障

系统看门狗定时器

完成

复位

( 4 )设计多样性 (Design diversity)

一种用于减少一些系统错误进入设计的设计方法学当一个设计需要给定模块的不同实例应该采用模块的不同实现而不是到处都用同一种模块比如一个有多个 CPU的系统可能采用不同类型的 CPU而不是到处采用同一种类型的 CPU在一个三模冗余系统产生表决结构的组件可能有不同的实现这样可以减少产生同样设计错误的机会

4 )软件可靠性ldquo在规定的条件下在规定的时间内软件不引起失效的概率rdquo

规定的条件 软件运行的软硬件环境 软件操作剖面软件运行的输入空间及其概率分布

规定的时间 日历时间 时钟时间 执行时间

激活软件 输入域 缺陷的数据

软件缺陷 软件

不可接受的结果 (软件故障) 输出域

软件故障的特点

软件与硬件可靠性的区别硬件 软件

故障机理 老化损耗 残留缺陷在一定环境下造成的软件错误

复杂性 内部逻辑较为简单 内部逻辑高度复杂这就在很大程度上决定了设计错误是导致软件故障的主要原因

唯一性 任何两个硬件不可能绝对相同

软件是唯一的软件拷贝不改变软件本身

可靠性的核心 内部元部件 设计者的思维和软件的复杂性纠错维护方法 修复或更换失效的元部件 重设计 可靠性检验标准化

已标准化且有一整套完整的理论

仍未建立更没有完整的理论体系

产品市场 已有成熟的产品市场 产品市场还很新 错误性质 一些瞬间的硬件错误可能

会被误认为是软件错误 软件错误是永恒的可重现的

影响软件可靠性的因素( 1 )运行环境 ( 剖面 )

同一软件在不同运行剖面下其可靠性行为可能极不相同 软件故障是软件缺陷在一定输入情况下被激活的结果 假设软件输入域划分为两个部分 G 和 F 运行剖面不包含 F 中

的输入则软件不会出现故障其可靠性恒为 l 反之如果运行剖面不包含 G 中的输入则每一输入情况下均出现故障如果没有容错措施则 R=0

( 2 )软件规模 随着软件规模的增大软件可靠性问题愈显突出在我们考虑软件

可靠性问题时软件一般是指中型以上软件 (4000-5000条以上语句 ) 这时可靠性问题难以对付

软件工程实践的一个侧面可以反映这一点即单元测试一般由编程人员本人进行而综合测试则需独立的测试人员

影响软件可靠性的因素( 3 )软件内部结构

结构越复杂软件复杂度越高内含缺陷数越大因而软件可靠度越低

( 4 )软件可靠性设计技术 一般是指软件设计阶段中采用的用以保证和提高软件可靠性为主要目标的软件技术

( 5 )软件可靠性测试 研究表明软件测试方法与资源投入对软件可靠性有不可忽视的影

响( 6 )软件可靠性管理

软件可靠性管理旨在系统管理软件生存期各阶段的可靠性活动使之系统化规范化一体化这样就可以避免许多人为错误以提高软件可靠性

影响软件可靠性的因素( 7 )软件开发人员能力和经验

软件开发人员 ( 包括测试人员 ) 的能力愈强经验愈丰富所犯错误便可能愈少所得软件产品质量愈高相应的可靠性也愈高

( 8 )软件开发方法 软件工程表明开发方法对软件可靠性有显著影响 与非结构化方法比较结构化方法可以明显减少软件缺陷数

( 9 )软件开发环境 研究表明程序语言软件开发环境影响软件的可靠性而软件测

试工具的优劣则影响可靠性测试结果

4 安全 (Safety)amp保密 (Security)

安全 (Safety) 是保证财产和人身受到损害可靠性是指在一定的环境条件下以及一定的时间内系统完成特定任务的可能性而有效性则是系统的长期的工作时间于其存在时间 ( 简单的定义为运行时间 +维护时间 ) 的 比例保密 (Security) 是针对危险破坏损失或非法活动而进行措施在一定层面上保密 (Security)要比安全 (Safety)宽广的多例如信息 Security家庭 Security 网络 Security 国家Security) 等

Security强调的是外在事物对特定目标的危害

Safety 是系统本身的潜在危害

四个概念的比较分析安全 (Safety)可靠性 (Reliability)有效性 (Availability)保密 (Security )安全 (Safety)高的系统 软件可靠性不

一定高可靠性和有效性并不是一码事保密 (Security )的系统 软件是安全

(Safety) 系统 软件的重要保障

可靠性安全性保密性 可靠(或可信)系统设计 (Reliable (or dependable) system design)是制造嵌入式系统所关注的甚至在面对内部或者外部问题时可靠系统设计经常假设问题是非恶意引起的

安全重要的系统设计 (Safety-critical system design)研究确保系统安全操作的方法独立于引起问题的原因

保密性 (Security)主要关注恶意攻击

Aizientis等人描述了可信性和保密性间的关系可信性和保密性由几个特性所组成

服务的可用性 (Availability) 服务的连续性 (Continuity) 来自用户和所处环境的灾难性后果的安全性 (Safety) 来自不合适系统改变的完整性 (Integrity) 通过更改和修补的可维护性 (Maintainability) 信息的机密性 (Confidentiality)

可用性完整性

可靠性安全性可维护性

机密性

可信性 保密性

5 新型攻击和对策1 )物理攻击嵌入式系统比通用计算机更容易受攻击 一个关键原因是许多嵌入式计算机对攻击者可物理访问

2 )互联网攻击一些嵌入式系统的攻击通过互联网访问变得更加容易今天许多嵌入式系统连接到互联网

3 )电池攻击 (battery attack)这种攻击试图通过耗尽电池来关闭节点

4 )服务拒绝攻击 (Denial-of-service attacks)

在通用系统中众所周知但是实时嵌入式系统可能更容易受服务质量 (quality-of-service (QoS))攻击如果网络发布实时数据那么发送过程中的一点延迟都能引起数据无效如果那些数据用来实时控制那么这些短暂延迟就能引起系统故障我们称这种危害为时间攻击因为它改变了系统的实时特性

QoS或者时间攻击之所以强大使因为它的影响不仅仅限于信息被控制系统的动态特性可决定系统的响应如果一个大型沉重快速运动的系统被控制那么时间上一个相对小的改变能引起大量的破坏

5 )网络(协议)攻击Wood和 Stankovic[Woo02]在传感器网络上确定了一些方式这些方式可在网络层次的不同层执行拒绝服务攻击如下所列

物理层 (Physical layer)mdashmdash拥塞破坏 链路层 (Link layer)mdashmdash碰撞耗尽非公平

网络和路由层 (Network and routing layer)mdashmdash丢弃和贪婪汇集方向误导黑洞认证监视冗余

传输层 (Transport layer)mdashmdash泛洪失步

6 )能量攻击Kocher等人 [Koc99]指出测量一个 CPU当前的能量供给能在很大程度上确定处理器的内部活动他们提出了两种能量攻击的方法简单能量分析 (simple power analysis)人工地跟踪检查和尝试确定程序作用的位置比如分支基于不同 CUP操作的能耗知识基于程序作用攻击者然后减少密钥的比特差分能量分析 (Differential power analysis)用相关性确定作用和密钥比特这种攻击最初目标是智能卡这种卡从外部读卡器获取能量但是这种攻击也能应用到许多嵌入式系统中

7 )反攻击 在一些时候有可能构造反破坏的嵌入式系统使电子设备难以发觉和分析延缓了攻击者芯片中有限的信息也有助阻止攻击者发现数据

6 Efficiency (效率)

ES must be efficient

bull Code-size efficient( 特别是片上系统 )

bull Run-time efficient

bull Weight efficient

bull Cost efficient

bull Energy efficient

能量有效性的重要意义

ldquoinherent power

efficiency of siliconldquo

59

低功耗设计问题 功耗问题是近几年来人们在嵌入式系统的设计中普遍关注的难点和热点它严重地制约着嵌入式系统的应用与发展

无论是在军事还是在商业贸易上的应用相当数量的嵌入式系统一般是由电池来供给电能的而且大多数嵌入式设备都有体积和质量的约束减少电能消耗不仅能延长电池的使用寿命延长用户更换电池的周期而且能带来提高系统性能与降低系统开销的好处甚至能起到保护环境的作用在便携式设备中 CPU消耗的电能越少电池的寿命就越长同时散发的热量少了所需的散热器就少了从而可减少该设备的花费和体积使产品尽快进入市场的目标

1 低功耗嵌入式应用系统是指以降低系统功耗为一个主要性能指标的嵌入式系统如计算机里的许多芯片过去用 5V供电现在用 33V 18V 并提出了绿色电器的概念

60

低功耗设备的要求1 )首先要求体积小重量轻便于携带2 )采用低功耗电路的设计方法以降低系统的功耗

它除了选用各种低功耗的器件和芯片外还在满足速度等性能指标的前提下进行降低功耗的硬件电路设计和软件设计

3 )有的系统应用在交流供电比较困难甚至无法用交流供电的场合因而各种电池(瓶)就成为其主要供电手段

4 )采用 LCD液晶显示器5 )采用 RS232C串行通信接口6 )采用微功耗高抗干扰的 CMOS集成电路

功耗产生的原因 P=UI

与功耗有关的因素

( 1 )电阻上消耗的功率( 2 )有源器件的开关转换阶段( 3 )集成电路内部和外部电容的充放电( 4 )系统的性能指标负载能力被处理信号的工作频率电路的工作频率电源的管理水平零部件的性能散热条件接口的物理性能等对系统功耗起着重要的作用

降低功耗的措施

功耗的组成动态 + 静态动态电源管理动态电压缩放低功耗硬件设计低功耗软件设计

二设计方法学概论

问题功 能 性能要求价 格 开发 周 期 等约束

设计 选择 折衷 分析比较 计算 评价

嵌入式系统

0嵌入式系统设计概述

方法 工具

设计方法论( design methodology )

设计方法论有以下三个重要理由1 )确认我们所做的每一件事情都是必须要作的

不会做无谓的白工也不会漏掉关键性的重要工作其中包含效率优化或是功能测试

2 )可以发展出计算机辅助工具或是设计经验累积汲取每一次产品发展的经验再经过量化之后可以发展出一套工具或是方法让往后的产品设计步入自动化

3 )开发团队遵循同一套方法论可以让团队成员更容易彼此沟通每个人都能在短时间内了解整体过程中将经历哪些过程需要何种支持与接收到何种结果此外也容易透过一套已经定义好的方法论彼此相互合作协调

设计目标 1 )上市时间

也就是 time-to-market 的观念2 )设计成本

许多消费性产品对于价格非常敏感所以产品厂商对于成本会斤斤计较是很合理的

3 )品质 顾客也许不需要最快最便宜的产品但是一定会要求功能质量保证不能只用一小段时间就坏掉了

传统的设计主要步骤

2 传统的设计流程方法1 )瀑布模型 (Waterfall)2 )螺旋模型 (Spiral)3 )连续改进 (Successive Refinement)4 )硬件与软件的同步设计 (SWHW Co-

deign)5 )阶层式 (Hierarchical) 设计6 )同步工程( concurrent

engineering )

瀑布模型 (Waterfall)

螺旋模型 (Spiral)

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 13: 大学计算机基础 —— 计算机科学概论

实时系统的类型根据任务超过截止时间的后果实时系统可以分为 硬实时软实时固实时1 )硬实时当系统执行任务时被强制要求在某个时间范围内要

产生结果换句话说任何时刻硬实时任务没有在制定的时间范围内产生要求的结果那这个系统就被认为失败了

2 )固实时当系统执行任务时与某些预设的截止时间相关联任务要求要在截止时间之前完成结果的计算不同于硬实时任务就算一个固实时任务没有在截止时间之前完成系统也不会失败迟来的结果仅仅是被丢弃了

3 )软实时当系统执行任务时也有与之相关联的时间界限但是不像硬实时和固实时任务软实时任务的时间界限并不是以绝对数值来表示的取而代之的是平均响应时间

Real-Time 系统与嵌入式系统

Embedded and Real-

Time 往往同义 Most embedded

systems are real-time

Most real-time systems are embedded

embeddedembedded

real-timereal-time

embedded embedded real-timereal-time

4 反应系统ES 是一个反应系统 转换系统输入(开始) -gt 软件系统(经过一段时间后停止运行) -gt (然后)输

出即用户把数据输入给计算机软件对这些数据经过一段时间的计算最后给出输出结果

输入数据经过特定的规则被转换并且在结束计算过程以后给出结果 而 reactive system 却与此相反在 reactive system 里往往没有明确的时序安排总体来讲

reactive system 表示的是不限制运行时间的系统这其中要和外部环境相互作用也就是在外部刺激上的反应 (reactive) 例如和不同使用者或者外部的硬件等但是也包括内部发生的交流行为因为 reactive system 是被集成在并行运行的分布式系统的规则中的例如一个计算机的操作系统是这样一个 reactive system 它不会停止运行 而总是反应用户给的输入 并且计算机中的各个组件之间要进行交流

在电信领域生产控制或者在硬件环境的构造(嵌入式系统)中还存在很多这样的例子在信息系统中也就是基于数据库的应用系统中也要用到 reactive system 在给一个典型的例子就是警报系统

5 混成系统Hybrid systems(analog + digital parts)混成系统一般由离散分立组件和连续组件并行或者串

行组成组件之间的行为由计算模型进行控制由于大多数复杂控制系统都包含了由连续变量所描述的物理层的动态演化过程和以符号操作与离散监控决策为特征的高层协调优化过程因此混成系统在工业控制和国防等领域大量存在混成系统定义凡是系统自身具有混合结构并且其

行为(输出和状态)取决于离散事件系统和连续动态系统相互作用的动态系统就称为混成系统

混成系统的典型特征( 1) 系统内存在着性质不同的连续和离散两类变量( 2) 时间和事件共同驱动系统的状态演化 ( 3)连续变量穿越阈值使状态使能或失能 ( 4)离散状态的变化改变连续变量遵循的变化速率 ( 5)离散事件发生在离散时刻 具有顺序选择并发等特色

( 6)状态呈阶段性间歇性切换变化 动态特征显著 ( 7) 对系统的控制表现为对连续状态和离散状态的集成控制 ( 8) 对系统的优化表现为在定性 定量双重指标下的集成优化

6 专用系统 Dedicated towards a certain

applicationKnowledge about behavior at design time can be used to minimize resources and to maximize robustness

Dedicated user interface(no mouse keyboard and screen)

二设计的挑战 实时可信可靠保密安全

1 为什么需要可靠的嵌入式系统1 )许多市场不需要高度可靠的嵌入式计算机但是许多嵌入式计算机必须

是高度可靠的2 )许多嵌入式计算机必须是高度可靠的汽车电子航空电子医疗设备

关键通信3 )可靠性的定义如电话交换机系统每年停机少于 30秒4 )关于可靠数字系统设计的研究几十年前就有不同的体系结构和方法学

被开发用于长周期低失误率的数字系统操作那么传统的可靠计算机和可靠的计算机系统有什么不同呢

5 )可靠嵌入式计算机通常是分布式系统如汽车电子航空电子和医疗设备都是必须高度可靠的分布式嵌入式系统

6 )嵌入式计算机容易受许多新类型攻击可靠计算机传统上是物理上不可访问的服务器或者机器mdashmdash物理安全长期以来是计算机安全的安全策略但是嵌入式计算机通常在非保护环境下操作这就允许新的故障和攻击这些需要都新的保护措施

2 可靠与可信ES 必需是可靠的可信的如何评价与度量

bull可靠性( Reliability) R(t)

bull可维护性( Maintainability) M(d)

bull有效性( Availability ) A(t)

bull安全性( Safety )bull保密性( Security )

可靠性定义可靠性 R(t) 产品在规定条件下和规定时间内完成规定

功能的能力产品可靠性定义的要素是三个ldquo规定rdquo 1 )ldquo规定条件rdquo包括使用时的环境条件

和工作条件2 )ldquo规定时间rdquo是指产品规定了的任务

时间3 )ldquo规定功能rdquo是指产品规定了的必须

具备的功能及其技术指标

1 )ldquo规定条件rdquo包括使用时的环境条件和工作条件 例如同一型号的汽车在高速公路和在崎岖的山路上行驶其可

靠性的表现就不大一样要谈论产品的可靠性必须指明规定的条件是什么2 )ldquo规定时间rdquo是指产品规定了的任务时间 随着产品任务时间的增加产品出现故障的概率将增加

而产品的可靠性将是下降的因此谈论产品的可靠性离不开规定的任务时间例如一辆汽车在在刚刚开出厂子和用了5 年后相比它出故障的概率显然大了很多

3 )ldquo规定功能rdquo是指产品规定了的必须具备的功能及其技术指标所要求产品功能的多少和其技术指标的高低直接影响到产品可靠性指标的高低

例如电风扇的主要功能有转叶摇头定时那么规定的功能是三者都要还是仅需要转叶能转能够吹风所得出的可靠性指标是大不一样的

可维护性 M(d)1 )计算机系统的可维护性是指该系统失效后在规定时间内可

修复到规定功能的能力2 )反映系统可维护性高低的参数是修复率秒平均修复时间3 )软件可维护性即维护人员对该软件进行维护的难易程度

具体包括理解改正改动和改进该软件的难易程度4 )决定可维护性的因素

系统的大小系统的年龄结构合理性

5 )可维护性的度量 可理解性可测试性可修改性可移植性

有效性 A(t)设备的有效性的表式为 设备有效性 = 平均故障间隔期 (平均故障间隔期+平均修理时间)

在逻辑中如果一个论证不能从真前提中得出假结论 则论证的形式是完全有效的

一个论证若被称为是有效的则如果在其中所有前提都为真的每个模型中结论也是真的

例如ldquo所有 A 是 B 有些 A 是 C 所以有些 B 是Crdquo 是有效形式

可用性 实用性

3 可靠系统设计的基本原理1 )故障 (faults) 分析2 )可靠性分析3 )纠错技术4 )软件可靠性

1 )故障 (faults) 分析永久 (permanent) 与暂时( transient )故障故障来源 物理故障 (Physical faults)由生产缺陷辐射危害等等引起

设计故障 (Design faults) 是不合适设计的系统的结果

操作故障 (Operational faults) 来自人为过失安全破坏劣质设计的人机接口等等

可靠性设计

故障及其分类 产品的故障按其故障规律分为两大类

偶然故障 渐变故障

产品的故障按其故障后果分为两大类 致命性故障 非致命性故障

产品的故障按其统计特性分为两大类 独立故障 从属故障

可靠度 产品在规定的条件下和规定的时间内完成规

定功能的概率称为可靠度依定义可知系统的可靠度是时间的函数表示为

式中 R(t)mdashmdash 可靠度函数 ξmdashmdash 产生故障前的工作时间 t mdashmdash 规定的时间

)()( tPtR

2 )可靠性的分析mdashmdash可靠度

可靠度函数

依定义可知可靠度函数 R(t) 为

式中 N0 mdashmdash t = 0 时在规定条件下进行工作的产品数

r(t) mdashmdash  在 0 到 t 时刻的工作时间内产品的累计

故障数

0

0 )()(

N

trNtR

累积故障分布函数 产品在规定的条件下和规定的时间内丧失

规定功能的概率称为累积故障概率(又叫不可靠度) 依定义可知产品的累积故障概率是时间的函

数即

显然以下关系成立

0

)()(

N

trtF

1)()( tFtR

可靠度函数与累积故障分布函数的性质

图 R(t)F(t)与f(t)的关系t

f(t)

f(t)

F(to)

R(to)

to

由密度函数的性质 1)(0

dttf 可知

t

tdttfdttftFtR )()(1)(1)(

0

因此 R(t) F(t) 与 f(t) 之间的关系如图所示

故障率函数 故障率

工作到某时刻尚未发生故障的产品在该时刻后单位时间内发生故障的概率称之为产品的故障率

用数学符号表示为

式中 (t) mdashmdash 故障率 dr(t) mdashmdash t 时刻后 dt 时间内故障的产品数 Ns(t) mdashmdash 残存产品数即到 t 时刻尚未故障的产品

dttN

tdrt

s )(

)()(

35

故障率函数

可按下式进行工程计算

式中 Δr(t) mdashmdash t 时刻后 Δt 时间内故障的产品数

Δt mdashmdash 所取时间间隔 Ns(t) mdashmdash 残存产品数

对于低故障率的元部件常以 10-9h 为故障率的单位称之为菲特( Fit )

ttN

trt

s

)(

)()(

产品故障浴盆曲线 浴盆曲线

大多数产品的故障率随时间的变化曲线形似浴盆称之为浴盆曲线由于产品故障机理的不同产品的故障率随时间的变化大致可以分为三个阶段

产品典型的故障率曲线

t

使用寿命

早期故障

偶然故障 耗损故障

A B规定的故障率 维修后故障率下降

(t)

3 )纠错技术( 1 )纠错码 在 1950s就开始研究最早的是可以检测和纠错的汉明码它们通过数字系统广泛地用于识别和纠正短暂或者持久的错误这些码引入冗余信息来确保一些类型的错误可以被检测和纠正比如一个单错校正 双错校正的码能用一个比特检测和纠正一个错误但是不能用两个比特纠错

( 2 )三模冗余 (triple modular

redundancy) 计算单元 C 有三个副本 C1C2和 C3三个单元接收同

样的输入一个独立单元比较每个输入的结果如果至少两个结果一致那么那个值被表决器选做正确结果如果三个结果都不相同那么就没有正确的结果

1C

2C

3C

表决错误

结果

输入

( 3 )看门狗定时器 (watchdog timer)

看门狗定时器 (watchdog timer)被广泛地用于检测系统问题如图 看门狗定时器连接到一个监视系统如果这个看门狗定时器翻转它产生一个完成信号用于标注系统的错误中断系统应该这样设计当适当运行的时候它一直在可能产生翻转信号之前复位定时器因此来自看门狗定时器的完成信号指示系统在一定程度上不合适地操作看门狗定时器用于预防不同的故障

系统看门狗定时器

完成

复位

( 4 )设计多样性 (Design diversity)

一种用于减少一些系统错误进入设计的设计方法学当一个设计需要给定模块的不同实例应该采用模块的不同实现而不是到处都用同一种模块比如一个有多个 CPU的系统可能采用不同类型的 CPU而不是到处采用同一种类型的 CPU在一个三模冗余系统产生表决结构的组件可能有不同的实现这样可以减少产生同样设计错误的机会

4 )软件可靠性ldquo在规定的条件下在规定的时间内软件不引起失效的概率rdquo

规定的条件 软件运行的软硬件环境 软件操作剖面软件运行的输入空间及其概率分布

规定的时间 日历时间 时钟时间 执行时间

激活软件 输入域 缺陷的数据

软件缺陷 软件

不可接受的结果 (软件故障) 输出域

软件故障的特点

软件与硬件可靠性的区别硬件 软件

故障机理 老化损耗 残留缺陷在一定环境下造成的软件错误

复杂性 内部逻辑较为简单 内部逻辑高度复杂这就在很大程度上决定了设计错误是导致软件故障的主要原因

唯一性 任何两个硬件不可能绝对相同

软件是唯一的软件拷贝不改变软件本身

可靠性的核心 内部元部件 设计者的思维和软件的复杂性纠错维护方法 修复或更换失效的元部件 重设计 可靠性检验标准化

已标准化且有一整套完整的理论

仍未建立更没有完整的理论体系

产品市场 已有成熟的产品市场 产品市场还很新 错误性质 一些瞬间的硬件错误可能

会被误认为是软件错误 软件错误是永恒的可重现的

影响软件可靠性的因素( 1 )运行环境 ( 剖面 )

同一软件在不同运行剖面下其可靠性行为可能极不相同 软件故障是软件缺陷在一定输入情况下被激活的结果 假设软件输入域划分为两个部分 G 和 F 运行剖面不包含 F 中

的输入则软件不会出现故障其可靠性恒为 l 反之如果运行剖面不包含 G 中的输入则每一输入情况下均出现故障如果没有容错措施则 R=0

( 2 )软件规模 随着软件规模的增大软件可靠性问题愈显突出在我们考虑软件

可靠性问题时软件一般是指中型以上软件 (4000-5000条以上语句 ) 这时可靠性问题难以对付

软件工程实践的一个侧面可以反映这一点即单元测试一般由编程人员本人进行而综合测试则需独立的测试人员

影响软件可靠性的因素( 3 )软件内部结构

结构越复杂软件复杂度越高内含缺陷数越大因而软件可靠度越低

( 4 )软件可靠性设计技术 一般是指软件设计阶段中采用的用以保证和提高软件可靠性为主要目标的软件技术

( 5 )软件可靠性测试 研究表明软件测试方法与资源投入对软件可靠性有不可忽视的影

响( 6 )软件可靠性管理

软件可靠性管理旨在系统管理软件生存期各阶段的可靠性活动使之系统化规范化一体化这样就可以避免许多人为错误以提高软件可靠性

影响软件可靠性的因素( 7 )软件开发人员能力和经验

软件开发人员 ( 包括测试人员 ) 的能力愈强经验愈丰富所犯错误便可能愈少所得软件产品质量愈高相应的可靠性也愈高

( 8 )软件开发方法 软件工程表明开发方法对软件可靠性有显著影响 与非结构化方法比较结构化方法可以明显减少软件缺陷数

( 9 )软件开发环境 研究表明程序语言软件开发环境影响软件的可靠性而软件测

试工具的优劣则影响可靠性测试结果

4 安全 (Safety)amp保密 (Security)

安全 (Safety) 是保证财产和人身受到损害可靠性是指在一定的环境条件下以及一定的时间内系统完成特定任务的可能性而有效性则是系统的长期的工作时间于其存在时间 ( 简单的定义为运行时间 +维护时间 ) 的 比例保密 (Security) 是针对危险破坏损失或非法活动而进行措施在一定层面上保密 (Security)要比安全 (Safety)宽广的多例如信息 Security家庭 Security 网络 Security 国家Security) 等

Security强调的是外在事物对特定目标的危害

Safety 是系统本身的潜在危害

四个概念的比较分析安全 (Safety)可靠性 (Reliability)有效性 (Availability)保密 (Security )安全 (Safety)高的系统 软件可靠性不

一定高可靠性和有效性并不是一码事保密 (Security )的系统 软件是安全

(Safety) 系统 软件的重要保障

可靠性安全性保密性 可靠(或可信)系统设计 (Reliable (or dependable) system design)是制造嵌入式系统所关注的甚至在面对内部或者外部问题时可靠系统设计经常假设问题是非恶意引起的

安全重要的系统设计 (Safety-critical system design)研究确保系统安全操作的方法独立于引起问题的原因

保密性 (Security)主要关注恶意攻击

Aizientis等人描述了可信性和保密性间的关系可信性和保密性由几个特性所组成

服务的可用性 (Availability) 服务的连续性 (Continuity) 来自用户和所处环境的灾难性后果的安全性 (Safety) 来自不合适系统改变的完整性 (Integrity) 通过更改和修补的可维护性 (Maintainability) 信息的机密性 (Confidentiality)

可用性完整性

可靠性安全性可维护性

机密性

可信性 保密性

5 新型攻击和对策1 )物理攻击嵌入式系统比通用计算机更容易受攻击 一个关键原因是许多嵌入式计算机对攻击者可物理访问

2 )互联网攻击一些嵌入式系统的攻击通过互联网访问变得更加容易今天许多嵌入式系统连接到互联网

3 )电池攻击 (battery attack)这种攻击试图通过耗尽电池来关闭节点

4 )服务拒绝攻击 (Denial-of-service attacks)

在通用系统中众所周知但是实时嵌入式系统可能更容易受服务质量 (quality-of-service (QoS))攻击如果网络发布实时数据那么发送过程中的一点延迟都能引起数据无效如果那些数据用来实时控制那么这些短暂延迟就能引起系统故障我们称这种危害为时间攻击因为它改变了系统的实时特性

QoS或者时间攻击之所以强大使因为它的影响不仅仅限于信息被控制系统的动态特性可决定系统的响应如果一个大型沉重快速运动的系统被控制那么时间上一个相对小的改变能引起大量的破坏

5 )网络(协议)攻击Wood和 Stankovic[Woo02]在传感器网络上确定了一些方式这些方式可在网络层次的不同层执行拒绝服务攻击如下所列

物理层 (Physical layer)mdashmdash拥塞破坏 链路层 (Link layer)mdashmdash碰撞耗尽非公平

网络和路由层 (Network and routing layer)mdashmdash丢弃和贪婪汇集方向误导黑洞认证监视冗余

传输层 (Transport layer)mdashmdash泛洪失步

6 )能量攻击Kocher等人 [Koc99]指出测量一个 CPU当前的能量供给能在很大程度上确定处理器的内部活动他们提出了两种能量攻击的方法简单能量分析 (simple power analysis)人工地跟踪检查和尝试确定程序作用的位置比如分支基于不同 CUP操作的能耗知识基于程序作用攻击者然后减少密钥的比特差分能量分析 (Differential power analysis)用相关性确定作用和密钥比特这种攻击最初目标是智能卡这种卡从外部读卡器获取能量但是这种攻击也能应用到许多嵌入式系统中

7 )反攻击 在一些时候有可能构造反破坏的嵌入式系统使电子设备难以发觉和分析延缓了攻击者芯片中有限的信息也有助阻止攻击者发现数据

6 Efficiency (效率)

ES must be efficient

bull Code-size efficient( 特别是片上系统 )

bull Run-time efficient

bull Weight efficient

bull Cost efficient

bull Energy efficient

能量有效性的重要意义

ldquoinherent power

efficiency of siliconldquo

59

低功耗设计问题 功耗问题是近几年来人们在嵌入式系统的设计中普遍关注的难点和热点它严重地制约着嵌入式系统的应用与发展

无论是在军事还是在商业贸易上的应用相当数量的嵌入式系统一般是由电池来供给电能的而且大多数嵌入式设备都有体积和质量的约束减少电能消耗不仅能延长电池的使用寿命延长用户更换电池的周期而且能带来提高系统性能与降低系统开销的好处甚至能起到保护环境的作用在便携式设备中 CPU消耗的电能越少电池的寿命就越长同时散发的热量少了所需的散热器就少了从而可减少该设备的花费和体积使产品尽快进入市场的目标

1 低功耗嵌入式应用系统是指以降低系统功耗为一个主要性能指标的嵌入式系统如计算机里的许多芯片过去用 5V供电现在用 33V 18V 并提出了绿色电器的概念

60

低功耗设备的要求1 )首先要求体积小重量轻便于携带2 )采用低功耗电路的设计方法以降低系统的功耗

它除了选用各种低功耗的器件和芯片外还在满足速度等性能指标的前提下进行降低功耗的硬件电路设计和软件设计

3 )有的系统应用在交流供电比较困难甚至无法用交流供电的场合因而各种电池(瓶)就成为其主要供电手段

4 )采用 LCD液晶显示器5 )采用 RS232C串行通信接口6 )采用微功耗高抗干扰的 CMOS集成电路

功耗产生的原因 P=UI

与功耗有关的因素

( 1 )电阻上消耗的功率( 2 )有源器件的开关转换阶段( 3 )集成电路内部和外部电容的充放电( 4 )系统的性能指标负载能力被处理信号的工作频率电路的工作频率电源的管理水平零部件的性能散热条件接口的物理性能等对系统功耗起着重要的作用

降低功耗的措施

功耗的组成动态 + 静态动态电源管理动态电压缩放低功耗硬件设计低功耗软件设计

二设计方法学概论

问题功 能 性能要求价 格 开发 周 期 等约束

设计 选择 折衷 分析比较 计算 评价

嵌入式系统

0嵌入式系统设计概述

方法 工具

设计方法论( design methodology )

设计方法论有以下三个重要理由1 )确认我们所做的每一件事情都是必须要作的

不会做无谓的白工也不会漏掉关键性的重要工作其中包含效率优化或是功能测试

2 )可以发展出计算机辅助工具或是设计经验累积汲取每一次产品发展的经验再经过量化之后可以发展出一套工具或是方法让往后的产品设计步入自动化

3 )开发团队遵循同一套方法论可以让团队成员更容易彼此沟通每个人都能在短时间内了解整体过程中将经历哪些过程需要何种支持与接收到何种结果此外也容易透过一套已经定义好的方法论彼此相互合作协调

设计目标 1 )上市时间

也就是 time-to-market 的观念2 )设计成本

许多消费性产品对于价格非常敏感所以产品厂商对于成本会斤斤计较是很合理的

3 )品质 顾客也许不需要最快最便宜的产品但是一定会要求功能质量保证不能只用一小段时间就坏掉了

传统的设计主要步骤

2 传统的设计流程方法1 )瀑布模型 (Waterfall)2 )螺旋模型 (Spiral)3 )连续改进 (Successive Refinement)4 )硬件与软件的同步设计 (SWHW Co-

deign)5 )阶层式 (Hierarchical) 设计6 )同步工程( concurrent

engineering )

瀑布模型 (Waterfall)

螺旋模型 (Spiral)

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 14: 大学计算机基础 —— 计算机科学概论

Real-Time 系统与嵌入式系统

Embedded and Real-

Time 往往同义 Most embedded

systems are real-time

Most real-time systems are embedded

embeddedembedded

real-timereal-time

embedded embedded real-timereal-time

4 反应系统ES 是一个反应系统 转换系统输入(开始) -gt 软件系统(经过一段时间后停止运行) -gt (然后)输

出即用户把数据输入给计算机软件对这些数据经过一段时间的计算最后给出输出结果

输入数据经过特定的规则被转换并且在结束计算过程以后给出结果 而 reactive system 却与此相反在 reactive system 里往往没有明确的时序安排总体来讲

reactive system 表示的是不限制运行时间的系统这其中要和外部环境相互作用也就是在外部刺激上的反应 (reactive) 例如和不同使用者或者外部的硬件等但是也包括内部发生的交流行为因为 reactive system 是被集成在并行运行的分布式系统的规则中的例如一个计算机的操作系统是这样一个 reactive system 它不会停止运行 而总是反应用户给的输入 并且计算机中的各个组件之间要进行交流

在电信领域生产控制或者在硬件环境的构造(嵌入式系统)中还存在很多这样的例子在信息系统中也就是基于数据库的应用系统中也要用到 reactive system 在给一个典型的例子就是警报系统

5 混成系统Hybrid systems(analog + digital parts)混成系统一般由离散分立组件和连续组件并行或者串

行组成组件之间的行为由计算模型进行控制由于大多数复杂控制系统都包含了由连续变量所描述的物理层的动态演化过程和以符号操作与离散监控决策为特征的高层协调优化过程因此混成系统在工业控制和国防等领域大量存在混成系统定义凡是系统自身具有混合结构并且其

行为(输出和状态)取决于离散事件系统和连续动态系统相互作用的动态系统就称为混成系统

混成系统的典型特征( 1) 系统内存在着性质不同的连续和离散两类变量( 2) 时间和事件共同驱动系统的状态演化 ( 3)连续变量穿越阈值使状态使能或失能 ( 4)离散状态的变化改变连续变量遵循的变化速率 ( 5)离散事件发生在离散时刻 具有顺序选择并发等特色

( 6)状态呈阶段性间歇性切换变化 动态特征显著 ( 7) 对系统的控制表现为对连续状态和离散状态的集成控制 ( 8) 对系统的优化表现为在定性 定量双重指标下的集成优化

6 专用系统 Dedicated towards a certain

applicationKnowledge about behavior at design time can be used to minimize resources and to maximize robustness

Dedicated user interface(no mouse keyboard and screen)

二设计的挑战 实时可信可靠保密安全

1 为什么需要可靠的嵌入式系统1 )许多市场不需要高度可靠的嵌入式计算机但是许多嵌入式计算机必须

是高度可靠的2 )许多嵌入式计算机必须是高度可靠的汽车电子航空电子医疗设备

关键通信3 )可靠性的定义如电话交换机系统每年停机少于 30秒4 )关于可靠数字系统设计的研究几十年前就有不同的体系结构和方法学

被开发用于长周期低失误率的数字系统操作那么传统的可靠计算机和可靠的计算机系统有什么不同呢

5 )可靠嵌入式计算机通常是分布式系统如汽车电子航空电子和医疗设备都是必须高度可靠的分布式嵌入式系统

6 )嵌入式计算机容易受许多新类型攻击可靠计算机传统上是物理上不可访问的服务器或者机器mdashmdash物理安全长期以来是计算机安全的安全策略但是嵌入式计算机通常在非保护环境下操作这就允许新的故障和攻击这些需要都新的保护措施

2 可靠与可信ES 必需是可靠的可信的如何评价与度量

bull可靠性( Reliability) R(t)

bull可维护性( Maintainability) M(d)

bull有效性( Availability ) A(t)

bull安全性( Safety )bull保密性( Security )

可靠性定义可靠性 R(t) 产品在规定条件下和规定时间内完成规定

功能的能力产品可靠性定义的要素是三个ldquo规定rdquo 1 )ldquo规定条件rdquo包括使用时的环境条件

和工作条件2 )ldquo规定时间rdquo是指产品规定了的任务

时间3 )ldquo规定功能rdquo是指产品规定了的必须

具备的功能及其技术指标

1 )ldquo规定条件rdquo包括使用时的环境条件和工作条件 例如同一型号的汽车在高速公路和在崎岖的山路上行驶其可

靠性的表现就不大一样要谈论产品的可靠性必须指明规定的条件是什么2 )ldquo规定时间rdquo是指产品规定了的任务时间 随着产品任务时间的增加产品出现故障的概率将增加

而产品的可靠性将是下降的因此谈论产品的可靠性离不开规定的任务时间例如一辆汽车在在刚刚开出厂子和用了5 年后相比它出故障的概率显然大了很多

3 )ldquo规定功能rdquo是指产品规定了的必须具备的功能及其技术指标所要求产品功能的多少和其技术指标的高低直接影响到产品可靠性指标的高低

例如电风扇的主要功能有转叶摇头定时那么规定的功能是三者都要还是仅需要转叶能转能够吹风所得出的可靠性指标是大不一样的

可维护性 M(d)1 )计算机系统的可维护性是指该系统失效后在规定时间内可

修复到规定功能的能力2 )反映系统可维护性高低的参数是修复率秒平均修复时间3 )软件可维护性即维护人员对该软件进行维护的难易程度

具体包括理解改正改动和改进该软件的难易程度4 )决定可维护性的因素

系统的大小系统的年龄结构合理性

5 )可维护性的度量 可理解性可测试性可修改性可移植性

有效性 A(t)设备的有效性的表式为 设备有效性 = 平均故障间隔期 (平均故障间隔期+平均修理时间)

在逻辑中如果一个论证不能从真前提中得出假结论 则论证的形式是完全有效的

一个论证若被称为是有效的则如果在其中所有前提都为真的每个模型中结论也是真的

例如ldquo所有 A 是 B 有些 A 是 C 所以有些 B 是Crdquo 是有效形式

可用性 实用性

3 可靠系统设计的基本原理1 )故障 (faults) 分析2 )可靠性分析3 )纠错技术4 )软件可靠性

1 )故障 (faults) 分析永久 (permanent) 与暂时( transient )故障故障来源 物理故障 (Physical faults)由生产缺陷辐射危害等等引起

设计故障 (Design faults) 是不合适设计的系统的结果

操作故障 (Operational faults) 来自人为过失安全破坏劣质设计的人机接口等等

可靠性设计

故障及其分类 产品的故障按其故障规律分为两大类

偶然故障 渐变故障

产品的故障按其故障后果分为两大类 致命性故障 非致命性故障

产品的故障按其统计特性分为两大类 独立故障 从属故障

可靠度 产品在规定的条件下和规定的时间内完成规

定功能的概率称为可靠度依定义可知系统的可靠度是时间的函数表示为

式中 R(t)mdashmdash 可靠度函数 ξmdashmdash 产生故障前的工作时间 t mdashmdash 规定的时间

)()( tPtR

2 )可靠性的分析mdashmdash可靠度

可靠度函数

依定义可知可靠度函数 R(t) 为

式中 N0 mdashmdash t = 0 时在规定条件下进行工作的产品数

r(t) mdashmdash  在 0 到 t 时刻的工作时间内产品的累计

故障数

0

0 )()(

N

trNtR

累积故障分布函数 产品在规定的条件下和规定的时间内丧失

规定功能的概率称为累积故障概率(又叫不可靠度) 依定义可知产品的累积故障概率是时间的函

数即

显然以下关系成立

0

)()(

N

trtF

1)()( tFtR

可靠度函数与累积故障分布函数的性质

图 R(t)F(t)与f(t)的关系t

f(t)

f(t)

F(to)

R(to)

to

由密度函数的性质 1)(0

dttf 可知

t

tdttfdttftFtR )()(1)(1)(

0

因此 R(t) F(t) 与 f(t) 之间的关系如图所示

故障率函数 故障率

工作到某时刻尚未发生故障的产品在该时刻后单位时间内发生故障的概率称之为产品的故障率

用数学符号表示为

式中 (t) mdashmdash 故障率 dr(t) mdashmdash t 时刻后 dt 时间内故障的产品数 Ns(t) mdashmdash 残存产品数即到 t 时刻尚未故障的产品

dttN

tdrt

s )(

)()(

35

故障率函数

可按下式进行工程计算

式中 Δr(t) mdashmdash t 时刻后 Δt 时间内故障的产品数

Δt mdashmdash 所取时间间隔 Ns(t) mdashmdash 残存产品数

对于低故障率的元部件常以 10-9h 为故障率的单位称之为菲特( Fit )

ttN

trt

s

)(

)()(

产品故障浴盆曲线 浴盆曲线

大多数产品的故障率随时间的变化曲线形似浴盆称之为浴盆曲线由于产品故障机理的不同产品的故障率随时间的变化大致可以分为三个阶段

产品典型的故障率曲线

t

使用寿命

早期故障

偶然故障 耗损故障

A B规定的故障率 维修后故障率下降

(t)

3 )纠错技术( 1 )纠错码 在 1950s就开始研究最早的是可以检测和纠错的汉明码它们通过数字系统广泛地用于识别和纠正短暂或者持久的错误这些码引入冗余信息来确保一些类型的错误可以被检测和纠正比如一个单错校正 双错校正的码能用一个比特检测和纠正一个错误但是不能用两个比特纠错

( 2 )三模冗余 (triple modular

redundancy) 计算单元 C 有三个副本 C1C2和 C3三个单元接收同

样的输入一个独立单元比较每个输入的结果如果至少两个结果一致那么那个值被表决器选做正确结果如果三个结果都不相同那么就没有正确的结果

1C

2C

3C

表决错误

结果

输入

( 3 )看门狗定时器 (watchdog timer)

看门狗定时器 (watchdog timer)被广泛地用于检测系统问题如图 看门狗定时器连接到一个监视系统如果这个看门狗定时器翻转它产生一个完成信号用于标注系统的错误中断系统应该这样设计当适当运行的时候它一直在可能产生翻转信号之前复位定时器因此来自看门狗定时器的完成信号指示系统在一定程度上不合适地操作看门狗定时器用于预防不同的故障

系统看门狗定时器

完成

复位

( 4 )设计多样性 (Design diversity)

一种用于减少一些系统错误进入设计的设计方法学当一个设计需要给定模块的不同实例应该采用模块的不同实现而不是到处都用同一种模块比如一个有多个 CPU的系统可能采用不同类型的 CPU而不是到处采用同一种类型的 CPU在一个三模冗余系统产生表决结构的组件可能有不同的实现这样可以减少产生同样设计错误的机会

4 )软件可靠性ldquo在规定的条件下在规定的时间内软件不引起失效的概率rdquo

规定的条件 软件运行的软硬件环境 软件操作剖面软件运行的输入空间及其概率分布

规定的时间 日历时间 时钟时间 执行时间

激活软件 输入域 缺陷的数据

软件缺陷 软件

不可接受的结果 (软件故障) 输出域

软件故障的特点

软件与硬件可靠性的区别硬件 软件

故障机理 老化损耗 残留缺陷在一定环境下造成的软件错误

复杂性 内部逻辑较为简单 内部逻辑高度复杂这就在很大程度上决定了设计错误是导致软件故障的主要原因

唯一性 任何两个硬件不可能绝对相同

软件是唯一的软件拷贝不改变软件本身

可靠性的核心 内部元部件 设计者的思维和软件的复杂性纠错维护方法 修复或更换失效的元部件 重设计 可靠性检验标准化

已标准化且有一整套完整的理论

仍未建立更没有完整的理论体系

产品市场 已有成熟的产品市场 产品市场还很新 错误性质 一些瞬间的硬件错误可能

会被误认为是软件错误 软件错误是永恒的可重现的

影响软件可靠性的因素( 1 )运行环境 ( 剖面 )

同一软件在不同运行剖面下其可靠性行为可能极不相同 软件故障是软件缺陷在一定输入情况下被激活的结果 假设软件输入域划分为两个部分 G 和 F 运行剖面不包含 F 中

的输入则软件不会出现故障其可靠性恒为 l 反之如果运行剖面不包含 G 中的输入则每一输入情况下均出现故障如果没有容错措施则 R=0

( 2 )软件规模 随着软件规模的增大软件可靠性问题愈显突出在我们考虑软件

可靠性问题时软件一般是指中型以上软件 (4000-5000条以上语句 ) 这时可靠性问题难以对付

软件工程实践的一个侧面可以反映这一点即单元测试一般由编程人员本人进行而综合测试则需独立的测试人员

影响软件可靠性的因素( 3 )软件内部结构

结构越复杂软件复杂度越高内含缺陷数越大因而软件可靠度越低

( 4 )软件可靠性设计技术 一般是指软件设计阶段中采用的用以保证和提高软件可靠性为主要目标的软件技术

( 5 )软件可靠性测试 研究表明软件测试方法与资源投入对软件可靠性有不可忽视的影

响( 6 )软件可靠性管理

软件可靠性管理旨在系统管理软件生存期各阶段的可靠性活动使之系统化规范化一体化这样就可以避免许多人为错误以提高软件可靠性

影响软件可靠性的因素( 7 )软件开发人员能力和经验

软件开发人员 ( 包括测试人员 ) 的能力愈强经验愈丰富所犯错误便可能愈少所得软件产品质量愈高相应的可靠性也愈高

( 8 )软件开发方法 软件工程表明开发方法对软件可靠性有显著影响 与非结构化方法比较结构化方法可以明显减少软件缺陷数

( 9 )软件开发环境 研究表明程序语言软件开发环境影响软件的可靠性而软件测

试工具的优劣则影响可靠性测试结果

4 安全 (Safety)amp保密 (Security)

安全 (Safety) 是保证财产和人身受到损害可靠性是指在一定的环境条件下以及一定的时间内系统完成特定任务的可能性而有效性则是系统的长期的工作时间于其存在时间 ( 简单的定义为运行时间 +维护时间 ) 的 比例保密 (Security) 是针对危险破坏损失或非法活动而进行措施在一定层面上保密 (Security)要比安全 (Safety)宽广的多例如信息 Security家庭 Security 网络 Security 国家Security) 等

Security强调的是外在事物对特定目标的危害

Safety 是系统本身的潜在危害

四个概念的比较分析安全 (Safety)可靠性 (Reliability)有效性 (Availability)保密 (Security )安全 (Safety)高的系统 软件可靠性不

一定高可靠性和有效性并不是一码事保密 (Security )的系统 软件是安全

(Safety) 系统 软件的重要保障

可靠性安全性保密性 可靠(或可信)系统设计 (Reliable (or dependable) system design)是制造嵌入式系统所关注的甚至在面对内部或者外部问题时可靠系统设计经常假设问题是非恶意引起的

安全重要的系统设计 (Safety-critical system design)研究确保系统安全操作的方法独立于引起问题的原因

保密性 (Security)主要关注恶意攻击

Aizientis等人描述了可信性和保密性间的关系可信性和保密性由几个特性所组成

服务的可用性 (Availability) 服务的连续性 (Continuity) 来自用户和所处环境的灾难性后果的安全性 (Safety) 来自不合适系统改变的完整性 (Integrity) 通过更改和修补的可维护性 (Maintainability) 信息的机密性 (Confidentiality)

可用性完整性

可靠性安全性可维护性

机密性

可信性 保密性

5 新型攻击和对策1 )物理攻击嵌入式系统比通用计算机更容易受攻击 一个关键原因是许多嵌入式计算机对攻击者可物理访问

2 )互联网攻击一些嵌入式系统的攻击通过互联网访问变得更加容易今天许多嵌入式系统连接到互联网

3 )电池攻击 (battery attack)这种攻击试图通过耗尽电池来关闭节点

4 )服务拒绝攻击 (Denial-of-service attacks)

在通用系统中众所周知但是实时嵌入式系统可能更容易受服务质量 (quality-of-service (QoS))攻击如果网络发布实时数据那么发送过程中的一点延迟都能引起数据无效如果那些数据用来实时控制那么这些短暂延迟就能引起系统故障我们称这种危害为时间攻击因为它改变了系统的实时特性

QoS或者时间攻击之所以强大使因为它的影响不仅仅限于信息被控制系统的动态特性可决定系统的响应如果一个大型沉重快速运动的系统被控制那么时间上一个相对小的改变能引起大量的破坏

5 )网络(协议)攻击Wood和 Stankovic[Woo02]在传感器网络上确定了一些方式这些方式可在网络层次的不同层执行拒绝服务攻击如下所列

物理层 (Physical layer)mdashmdash拥塞破坏 链路层 (Link layer)mdashmdash碰撞耗尽非公平

网络和路由层 (Network and routing layer)mdashmdash丢弃和贪婪汇集方向误导黑洞认证监视冗余

传输层 (Transport layer)mdashmdash泛洪失步

6 )能量攻击Kocher等人 [Koc99]指出测量一个 CPU当前的能量供给能在很大程度上确定处理器的内部活动他们提出了两种能量攻击的方法简单能量分析 (simple power analysis)人工地跟踪检查和尝试确定程序作用的位置比如分支基于不同 CUP操作的能耗知识基于程序作用攻击者然后减少密钥的比特差分能量分析 (Differential power analysis)用相关性确定作用和密钥比特这种攻击最初目标是智能卡这种卡从外部读卡器获取能量但是这种攻击也能应用到许多嵌入式系统中

7 )反攻击 在一些时候有可能构造反破坏的嵌入式系统使电子设备难以发觉和分析延缓了攻击者芯片中有限的信息也有助阻止攻击者发现数据

6 Efficiency (效率)

ES must be efficient

bull Code-size efficient( 特别是片上系统 )

bull Run-time efficient

bull Weight efficient

bull Cost efficient

bull Energy efficient

能量有效性的重要意义

ldquoinherent power

efficiency of siliconldquo

59

低功耗设计问题 功耗问题是近几年来人们在嵌入式系统的设计中普遍关注的难点和热点它严重地制约着嵌入式系统的应用与发展

无论是在军事还是在商业贸易上的应用相当数量的嵌入式系统一般是由电池来供给电能的而且大多数嵌入式设备都有体积和质量的约束减少电能消耗不仅能延长电池的使用寿命延长用户更换电池的周期而且能带来提高系统性能与降低系统开销的好处甚至能起到保护环境的作用在便携式设备中 CPU消耗的电能越少电池的寿命就越长同时散发的热量少了所需的散热器就少了从而可减少该设备的花费和体积使产品尽快进入市场的目标

1 低功耗嵌入式应用系统是指以降低系统功耗为一个主要性能指标的嵌入式系统如计算机里的许多芯片过去用 5V供电现在用 33V 18V 并提出了绿色电器的概念

60

低功耗设备的要求1 )首先要求体积小重量轻便于携带2 )采用低功耗电路的设计方法以降低系统的功耗

它除了选用各种低功耗的器件和芯片外还在满足速度等性能指标的前提下进行降低功耗的硬件电路设计和软件设计

3 )有的系统应用在交流供电比较困难甚至无法用交流供电的场合因而各种电池(瓶)就成为其主要供电手段

4 )采用 LCD液晶显示器5 )采用 RS232C串行通信接口6 )采用微功耗高抗干扰的 CMOS集成电路

功耗产生的原因 P=UI

与功耗有关的因素

( 1 )电阻上消耗的功率( 2 )有源器件的开关转换阶段( 3 )集成电路内部和外部电容的充放电( 4 )系统的性能指标负载能力被处理信号的工作频率电路的工作频率电源的管理水平零部件的性能散热条件接口的物理性能等对系统功耗起着重要的作用

降低功耗的措施

功耗的组成动态 + 静态动态电源管理动态电压缩放低功耗硬件设计低功耗软件设计

二设计方法学概论

问题功 能 性能要求价 格 开发 周 期 等约束

设计 选择 折衷 分析比较 计算 评价

嵌入式系统

0嵌入式系统设计概述

方法 工具

设计方法论( design methodology )

设计方法论有以下三个重要理由1 )确认我们所做的每一件事情都是必须要作的

不会做无谓的白工也不会漏掉关键性的重要工作其中包含效率优化或是功能测试

2 )可以发展出计算机辅助工具或是设计经验累积汲取每一次产品发展的经验再经过量化之后可以发展出一套工具或是方法让往后的产品设计步入自动化

3 )开发团队遵循同一套方法论可以让团队成员更容易彼此沟通每个人都能在短时间内了解整体过程中将经历哪些过程需要何种支持与接收到何种结果此外也容易透过一套已经定义好的方法论彼此相互合作协调

设计目标 1 )上市时间

也就是 time-to-market 的观念2 )设计成本

许多消费性产品对于价格非常敏感所以产品厂商对于成本会斤斤计较是很合理的

3 )品质 顾客也许不需要最快最便宜的产品但是一定会要求功能质量保证不能只用一小段时间就坏掉了

传统的设计主要步骤

2 传统的设计流程方法1 )瀑布模型 (Waterfall)2 )螺旋模型 (Spiral)3 )连续改进 (Successive Refinement)4 )硬件与软件的同步设计 (SWHW Co-

deign)5 )阶层式 (Hierarchical) 设计6 )同步工程( concurrent

engineering )

瀑布模型 (Waterfall)

螺旋模型 (Spiral)

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 15: 大学计算机基础 —— 计算机科学概论

4 反应系统ES 是一个反应系统 转换系统输入(开始) -gt 软件系统(经过一段时间后停止运行) -gt (然后)输

出即用户把数据输入给计算机软件对这些数据经过一段时间的计算最后给出输出结果

输入数据经过特定的规则被转换并且在结束计算过程以后给出结果 而 reactive system 却与此相反在 reactive system 里往往没有明确的时序安排总体来讲

reactive system 表示的是不限制运行时间的系统这其中要和外部环境相互作用也就是在外部刺激上的反应 (reactive) 例如和不同使用者或者外部的硬件等但是也包括内部发生的交流行为因为 reactive system 是被集成在并行运行的分布式系统的规则中的例如一个计算机的操作系统是这样一个 reactive system 它不会停止运行 而总是反应用户给的输入 并且计算机中的各个组件之间要进行交流

在电信领域生产控制或者在硬件环境的构造(嵌入式系统)中还存在很多这样的例子在信息系统中也就是基于数据库的应用系统中也要用到 reactive system 在给一个典型的例子就是警报系统

5 混成系统Hybrid systems(analog + digital parts)混成系统一般由离散分立组件和连续组件并行或者串

行组成组件之间的行为由计算模型进行控制由于大多数复杂控制系统都包含了由连续变量所描述的物理层的动态演化过程和以符号操作与离散监控决策为特征的高层协调优化过程因此混成系统在工业控制和国防等领域大量存在混成系统定义凡是系统自身具有混合结构并且其

行为(输出和状态)取决于离散事件系统和连续动态系统相互作用的动态系统就称为混成系统

混成系统的典型特征( 1) 系统内存在着性质不同的连续和离散两类变量( 2) 时间和事件共同驱动系统的状态演化 ( 3)连续变量穿越阈值使状态使能或失能 ( 4)离散状态的变化改变连续变量遵循的变化速率 ( 5)离散事件发生在离散时刻 具有顺序选择并发等特色

( 6)状态呈阶段性间歇性切换变化 动态特征显著 ( 7) 对系统的控制表现为对连续状态和离散状态的集成控制 ( 8) 对系统的优化表现为在定性 定量双重指标下的集成优化

6 专用系统 Dedicated towards a certain

applicationKnowledge about behavior at design time can be used to minimize resources and to maximize robustness

Dedicated user interface(no mouse keyboard and screen)

二设计的挑战 实时可信可靠保密安全

1 为什么需要可靠的嵌入式系统1 )许多市场不需要高度可靠的嵌入式计算机但是许多嵌入式计算机必须

是高度可靠的2 )许多嵌入式计算机必须是高度可靠的汽车电子航空电子医疗设备

关键通信3 )可靠性的定义如电话交换机系统每年停机少于 30秒4 )关于可靠数字系统设计的研究几十年前就有不同的体系结构和方法学

被开发用于长周期低失误率的数字系统操作那么传统的可靠计算机和可靠的计算机系统有什么不同呢

5 )可靠嵌入式计算机通常是分布式系统如汽车电子航空电子和医疗设备都是必须高度可靠的分布式嵌入式系统

6 )嵌入式计算机容易受许多新类型攻击可靠计算机传统上是物理上不可访问的服务器或者机器mdashmdash物理安全长期以来是计算机安全的安全策略但是嵌入式计算机通常在非保护环境下操作这就允许新的故障和攻击这些需要都新的保护措施

2 可靠与可信ES 必需是可靠的可信的如何评价与度量

bull可靠性( Reliability) R(t)

bull可维护性( Maintainability) M(d)

bull有效性( Availability ) A(t)

bull安全性( Safety )bull保密性( Security )

可靠性定义可靠性 R(t) 产品在规定条件下和规定时间内完成规定

功能的能力产品可靠性定义的要素是三个ldquo规定rdquo 1 )ldquo规定条件rdquo包括使用时的环境条件

和工作条件2 )ldquo规定时间rdquo是指产品规定了的任务

时间3 )ldquo规定功能rdquo是指产品规定了的必须

具备的功能及其技术指标

1 )ldquo规定条件rdquo包括使用时的环境条件和工作条件 例如同一型号的汽车在高速公路和在崎岖的山路上行驶其可

靠性的表现就不大一样要谈论产品的可靠性必须指明规定的条件是什么2 )ldquo规定时间rdquo是指产品规定了的任务时间 随着产品任务时间的增加产品出现故障的概率将增加

而产品的可靠性将是下降的因此谈论产品的可靠性离不开规定的任务时间例如一辆汽车在在刚刚开出厂子和用了5 年后相比它出故障的概率显然大了很多

3 )ldquo规定功能rdquo是指产品规定了的必须具备的功能及其技术指标所要求产品功能的多少和其技术指标的高低直接影响到产品可靠性指标的高低

例如电风扇的主要功能有转叶摇头定时那么规定的功能是三者都要还是仅需要转叶能转能够吹风所得出的可靠性指标是大不一样的

可维护性 M(d)1 )计算机系统的可维护性是指该系统失效后在规定时间内可

修复到规定功能的能力2 )反映系统可维护性高低的参数是修复率秒平均修复时间3 )软件可维护性即维护人员对该软件进行维护的难易程度

具体包括理解改正改动和改进该软件的难易程度4 )决定可维护性的因素

系统的大小系统的年龄结构合理性

5 )可维护性的度量 可理解性可测试性可修改性可移植性

有效性 A(t)设备的有效性的表式为 设备有效性 = 平均故障间隔期 (平均故障间隔期+平均修理时间)

在逻辑中如果一个论证不能从真前提中得出假结论 则论证的形式是完全有效的

一个论证若被称为是有效的则如果在其中所有前提都为真的每个模型中结论也是真的

例如ldquo所有 A 是 B 有些 A 是 C 所以有些 B 是Crdquo 是有效形式

可用性 实用性

3 可靠系统设计的基本原理1 )故障 (faults) 分析2 )可靠性分析3 )纠错技术4 )软件可靠性

1 )故障 (faults) 分析永久 (permanent) 与暂时( transient )故障故障来源 物理故障 (Physical faults)由生产缺陷辐射危害等等引起

设计故障 (Design faults) 是不合适设计的系统的结果

操作故障 (Operational faults) 来自人为过失安全破坏劣质设计的人机接口等等

可靠性设计

故障及其分类 产品的故障按其故障规律分为两大类

偶然故障 渐变故障

产品的故障按其故障后果分为两大类 致命性故障 非致命性故障

产品的故障按其统计特性分为两大类 独立故障 从属故障

可靠度 产品在规定的条件下和规定的时间内完成规

定功能的概率称为可靠度依定义可知系统的可靠度是时间的函数表示为

式中 R(t)mdashmdash 可靠度函数 ξmdashmdash 产生故障前的工作时间 t mdashmdash 规定的时间

)()( tPtR

2 )可靠性的分析mdashmdash可靠度

可靠度函数

依定义可知可靠度函数 R(t) 为

式中 N0 mdashmdash t = 0 时在规定条件下进行工作的产品数

r(t) mdashmdash  在 0 到 t 时刻的工作时间内产品的累计

故障数

0

0 )()(

N

trNtR

累积故障分布函数 产品在规定的条件下和规定的时间内丧失

规定功能的概率称为累积故障概率(又叫不可靠度) 依定义可知产品的累积故障概率是时间的函

数即

显然以下关系成立

0

)()(

N

trtF

1)()( tFtR

可靠度函数与累积故障分布函数的性质

图 R(t)F(t)与f(t)的关系t

f(t)

f(t)

F(to)

R(to)

to

由密度函数的性质 1)(0

dttf 可知

t

tdttfdttftFtR )()(1)(1)(

0

因此 R(t) F(t) 与 f(t) 之间的关系如图所示

故障率函数 故障率

工作到某时刻尚未发生故障的产品在该时刻后单位时间内发生故障的概率称之为产品的故障率

用数学符号表示为

式中 (t) mdashmdash 故障率 dr(t) mdashmdash t 时刻后 dt 时间内故障的产品数 Ns(t) mdashmdash 残存产品数即到 t 时刻尚未故障的产品

dttN

tdrt

s )(

)()(

35

故障率函数

可按下式进行工程计算

式中 Δr(t) mdashmdash t 时刻后 Δt 时间内故障的产品数

Δt mdashmdash 所取时间间隔 Ns(t) mdashmdash 残存产品数

对于低故障率的元部件常以 10-9h 为故障率的单位称之为菲特( Fit )

ttN

trt

s

)(

)()(

产品故障浴盆曲线 浴盆曲线

大多数产品的故障率随时间的变化曲线形似浴盆称之为浴盆曲线由于产品故障机理的不同产品的故障率随时间的变化大致可以分为三个阶段

产品典型的故障率曲线

t

使用寿命

早期故障

偶然故障 耗损故障

A B规定的故障率 维修后故障率下降

(t)

3 )纠错技术( 1 )纠错码 在 1950s就开始研究最早的是可以检测和纠错的汉明码它们通过数字系统广泛地用于识别和纠正短暂或者持久的错误这些码引入冗余信息来确保一些类型的错误可以被检测和纠正比如一个单错校正 双错校正的码能用一个比特检测和纠正一个错误但是不能用两个比特纠错

( 2 )三模冗余 (triple modular

redundancy) 计算单元 C 有三个副本 C1C2和 C3三个单元接收同

样的输入一个独立单元比较每个输入的结果如果至少两个结果一致那么那个值被表决器选做正确结果如果三个结果都不相同那么就没有正确的结果

1C

2C

3C

表决错误

结果

输入

( 3 )看门狗定时器 (watchdog timer)

看门狗定时器 (watchdog timer)被广泛地用于检测系统问题如图 看门狗定时器连接到一个监视系统如果这个看门狗定时器翻转它产生一个完成信号用于标注系统的错误中断系统应该这样设计当适当运行的时候它一直在可能产生翻转信号之前复位定时器因此来自看门狗定时器的完成信号指示系统在一定程度上不合适地操作看门狗定时器用于预防不同的故障

系统看门狗定时器

完成

复位

( 4 )设计多样性 (Design diversity)

一种用于减少一些系统错误进入设计的设计方法学当一个设计需要给定模块的不同实例应该采用模块的不同实现而不是到处都用同一种模块比如一个有多个 CPU的系统可能采用不同类型的 CPU而不是到处采用同一种类型的 CPU在一个三模冗余系统产生表决结构的组件可能有不同的实现这样可以减少产生同样设计错误的机会

4 )软件可靠性ldquo在规定的条件下在规定的时间内软件不引起失效的概率rdquo

规定的条件 软件运行的软硬件环境 软件操作剖面软件运行的输入空间及其概率分布

规定的时间 日历时间 时钟时间 执行时间

激活软件 输入域 缺陷的数据

软件缺陷 软件

不可接受的结果 (软件故障) 输出域

软件故障的特点

软件与硬件可靠性的区别硬件 软件

故障机理 老化损耗 残留缺陷在一定环境下造成的软件错误

复杂性 内部逻辑较为简单 内部逻辑高度复杂这就在很大程度上决定了设计错误是导致软件故障的主要原因

唯一性 任何两个硬件不可能绝对相同

软件是唯一的软件拷贝不改变软件本身

可靠性的核心 内部元部件 设计者的思维和软件的复杂性纠错维护方法 修复或更换失效的元部件 重设计 可靠性检验标准化

已标准化且有一整套完整的理论

仍未建立更没有完整的理论体系

产品市场 已有成熟的产品市场 产品市场还很新 错误性质 一些瞬间的硬件错误可能

会被误认为是软件错误 软件错误是永恒的可重现的

影响软件可靠性的因素( 1 )运行环境 ( 剖面 )

同一软件在不同运行剖面下其可靠性行为可能极不相同 软件故障是软件缺陷在一定输入情况下被激活的结果 假设软件输入域划分为两个部分 G 和 F 运行剖面不包含 F 中

的输入则软件不会出现故障其可靠性恒为 l 反之如果运行剖面不包含 G 中的输入则每一输入情况下均出现故障如果没有容错措施则 R=0

( 2 )软件规模 随着软件规模的增大软件可靠性问题愈显突出在我们考虑软件

可靠性问题时软件一般是指中型以上软件 (4000-5000条以上语句 ) 这时可靠性问题难以对付

软件工程实践的一个侧面可以反映这一点即单元测试一般由编程人员本人进行而综合测试则需独立的测试人员

影响软件可靠性的因素( 3 )软件内部结构

结构越复杂软件复杂度越高内含缺陷数越大因而软件可靠度越低

( 4 )软件可靠性设计技术 一般是指软件设计阶段中采用的用以保证和提高软件可靠性为主要目标的软件技术

( 5 )软件可靠性测试 研究表明软件测试方法与资源投入对软件可靠性有不可忽视的影

响( 6 )软件可靠性管理

软件可靠性管理旨在系统管理软件生存期各阶段的可靠性活动使之系统化规范化一体化这样就可以避免许多人为错误以提高软件可靠性

影响软件可靠性的因素( 7 )软件开发人员能力和经验

软件开发人员 ( 包括测试人员 ) 的能力愈强经验愈丰富所犯错误便可能愈少所得软件产品质量愈高相应的可靠性也愈高

( 8 )软件开发方法 软件工程表明开发方法对软件可靠性有显著影响 与非结构化方法比较结构化方法可以明显减少软件缺陷数

( 9 )软件开发环境 研究表明程序语言软件开发环境影响软件的可靠性而软件测

试工具的优劣则影响可靠性测试结果

4 安全 (Safety)amp保密 (Security)

安全 (Safety) 是保证财产和人身受到损害可靠性是指在一定的环境条件下以及一定的时间内系统完成特定任务的可能性而有效性则是系统的长期的工作时间于其存在时间 ( 简单的定义为运行时间 +维护时间 ) 的 比例保密 (Security) 是针对危险破坏损失或非法活动而进行措施在一定层面上保密 (Security)要比安全 (Safety)宽广的多例如信息 Security家庭 Security 网络 Security 国家Security) 等

Security强调的是外在事物对特定目标的危害

Safety 是系统本身的潜在危害

四个概念的比较分析安全 (Safety)可靠性 (Reliability)有效性 (Availability)保密 (Security )安全 (Safety)高的系统 软件可靠性不

一定高可靠性和有效性并不是一码事保密 (Security )的系统 软件是安全

(Safety) 系统 软件的重要保障

可靠性安全性保密性 可靠(或可信)系统设计 (Reliable (or dependable) system design)是制造嵌入式系统所关注的甚至在面对内部或者外部问题时可靠系统设计经常假设问题是非恶意引起的

安全重要的系统设计 (Safety-critical system design)研究确保系统安全操作的方法独立于引起问题的原因

保密性 (Security)主要关注恶意攻击

Aizientis等人描述了可信性和保密性间的关系可信性和保密性由几个特性所组成

服务的可用性 (Availability) 服务的连续性 (Continuity) 来自用户和所处环境的灾难性后果的安全性 (Safety) 来自不合适系统改变的完整性 (Integrity) 通过更改和修补的可维护性 (Maintainability) 信息的机密性 (Confidentiality)

可用性完整性

可靠性安全性可维护性

机密性

可信性 保密性

5 新型攻击和对策1 )物理攻击嵌入式系统比通用计算机更容易受攻击 一个关键原因是许多嵌入式计算机对攻击者可物理访问

2 )互联网攻击一些嵌入式系统的攻击通过互联网访问变得更加容易今天许多嵌入式系统连接到互联网

3 )电池攻击 (battery attack)这种攻击试图通过耗尽电池来关闭节点

4 )服务拒绝攻击 (Denial-of-service attacks)

在通用系统中众所周知但是实时嵌入式系统可能更容易受服务质量 (quality-of-service (QoS))攻击如果网络发布实时数据那么发送过程中的一点延迟都能引起数据无效如果那些数据用来实时控制那么这些短暂延迟就能引起系统故障我们称这种危害为时间攻击因为它改变了系统的实时特性

QoS或者时间攻击之所以强大使因为它的影响不仅仅限于信息被控制系统的动态特性可决定系统的响应如果一个大型沉重快速运动的系统被控制那么时间上一个相对小的改变能引起大量的破坏

5 )网络(协议)攻击Wood和 Stankovic[Woo02]在传感器网络上确定了一些方式这些方式可在网络层次的不同层执行拒绝服务攻击如下所列

物理层 (Physical layer)mdashmdash拥塞破坏 链路层 (Link layer)mdashmdash碰撞耗尽非公平

网络和路由层 (Network and routing layer)mdashmdash丢弃和贪婪汇集方向误导黑洞认证监视冗余

传输层 (Transport layer)mdashmdash泛洪失步

6 )能量攻击Kocher等人 [Koc99]指出测量一个 CPU当前的能量供给能在很大程度上确定处理器的内部活动他们提出了两种能量攻击的方法简单能量分析 (simple power analysis)人工地跟踪检查和尝试确定程序作用的位置比如分支基于不同 CUP操作的能耗知识基于程序作用攻击者然后减少密钥的比特差分能量分析 (Differential power analysis)用相关性确定作用和密钥比特这种攻击最初目标是智能卡这种卡从外部读卡器获取能量但是这种攻击也能应用到许多嵌入式系统中

7 )反攻击 在一些时候有可能构造反破坏的嵌入式系统使电子设备难以发觉和分析延缓了攻击者芯片中有限的信息也有助阻止攻击者发现数据

6 Efficiency (效率)

ES must be efficient

bull Code-size efficient( 特别是片上系统 )

bull Run-time efficient

bull Weight efficient

bull Cost efficient

bull Energy efficient

能量有效性的重要意义

ldquoinherent power

efficiency of siliconldquo

59

低功耗设计问题 功耗问题是近几年来人们在嵌入式系统的设计中普遍关注的难点和热点它严重地制约着嵌入式系统的应用与发展

无论是在军事还是在商业贸易上的应用相当数量的嵌入式系统一般是由电池来供给电能的而且大多数嵌入式设备都有体积和质量的约束减少电能消耗不仅能延长电池的使用寿命延长用户更换电池的周期而且能带来提高系统性能与降低系统开销的好处甚至能起到保护环境的作用在便携式设备中 CPU消耗的电能越少电池的寿命就越长同时散发的热量少了所需的散热器就少了从而可减少该设备的花费和体积使产品尽快进入市场的目标

1 低功耗嵌入式应用系统是指以降低系统功耗为一个主要性能指标的嵌入式系统如计算机里的许多芯片过去用 5V供电现在用 33V 18V 并提出了绿色电器的概念

60

低功耗设备的要求1 )首先要求体积小重量轻便于携带2 )采用低功耗电路的设计方法以降低系统的功耗

它除了选用各种低功耗的器件和芯片外还在满足速度等性能指标的前提下进行降低功耗的硬件电路设计和软件设计

3 )有的系统应用在交流供电比较困难甚至无法用交流供电的场合因而各种电池(瓶)就成为其主要供电手段

4 )采用 LCD液晶显示器5 )采用 RS232C串行通信接口6 )采用微功耗高抗干扰的 CMOS集成电路

功耗产生的原因 P=UI

与功耗有关的因素

( 1 )电阻上消耗的功率( 2 )有源器件的开关转换阶段( 3 )集成电路内部和外部电容的充放电( 4 )系统的性能指标负载能力被处理信号的工作频率电路的工作频率电源的管理水平零部件的性能散热条件接口的物理性能等对系统功耗起着重要的作用

降低功耗的措施

功耗的组成动态 + 静态动态电源管理动态电压缩放低功耗硬件设计低功耗软件设计

二设计方法学概论

问题功 能 性能要求价 格 开发 周 期 等约束

设计 选择 折衷 分析比较 计算 评价

嵌入式系统

0嵌入式系统设计概述

方法 工具

设计方法论( design methodology )

设计方法论有以下三个重要理由1 )确认我们所做的每一件事情都是必须要作的

不会做无谓的白工也不会漏掉关键性的重要工作其中包含效率优化或是功能测试

2 )可以发展出计算机辅助工具或是设计经验累积汲取每一次产品发展的经验再经过量化之后可以发展出一套工具或是方法让往后的产品设计步入自动化

3 )开发团队遵循同一套方法论可以让团队成员更容易彼此沟通每个人都能在短时间内了解整体过程中将经历哪些过程需要何种支持与接收到何种结果此外也容易透过一套已经定义好的方法论彼此相互合作协调

设计目标 1 )上市时间

也就是 time-to-market 的观念2 )设计成本

许多消费性产品对于价格非常敏感所以产品厂商对于成本会斤斤计较是很合理的

3 )品质 顾客也许不需要最快最便宜的产品但是一定会要求功能质量保证不能只用一小段时间就坏掉了

传统的设计主要步骤

2 传统的设计流程方法1 )瀑布模型 (Waterfall)2 )螺旋模型 (Spiral)3 )连续改进 (Successive Refinement)4 )硬件与软件的同步设计 (SWHW Co-

deign)5 )阶层式 (Hierarchical) 设计6 )同步工程( concurrent

engineering )

瀑布模型 (Waterfall)

螺旋模型 (Spiral)

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 16: 大学计算机基础 —— 计算机科学概论

5 混成系统Hybrid systems(analog + digital parts)混成系统一般由离散分立组件和连续组件并行或者串

行组成组件之间的行为由计算模型进行控制由于大多数复杂控制系统都包含了由连续变量所描述的物理层的动态演化过程和以符号操作与离散监控决策为特征的高层协调优化过程因此混成系统在工业控制和国防等领域大量存在混成系统定义凡是系统自身具有混合结构并且其

行为(输出和状态)取决于离散事件系统和连续动态系统相互作用的动态系统就称为混成系统

混成系统的典型特征( 1) 系统内存在着性质不同的连续和离散两类变量( 2) 时间和事件共同驱动系统的状态演化 ( 3)连续变量穿越阈值使状态使能或失能 ( 4)离散状态的变化改变连续变量遵循的变化速率 ( 5)离散事件发生在离散时刻 具有顺序选择并发等特色

( 6)状态呈阶段性间歇性切换变化 动态特征显著 ( 7) 对系统的控制表现为对连续状态和离散状态的集成控制 ( 8) 对系统的优化表现为在定性 定量双重指标下的集成优化

6 专用系统 Dedicated towards a certain

applicationKnowledge about behavior at design time can be used to minimize resources and to maximize robustness

Dedicated user interface(no mouse keyboard and screen)

二设计的挑战 实时可信可靠保密安全

1 为什么需要可靠的嵌入式系统1 )许多市场不需要高度可靠的嵌入式计算机但是许多嵌入式计算机必须

是高度可靠的2 )许多嵌入式计算机必须是高度可靠的汽车电子航空电子医疗设备

关键通信3 )可靠性的定义如电话交换机系统每年停机少于 30秒4 )关于可靠数字系统设计的研究几十年前就有不同的体系结构和方法学

被开发用于长周期低失误率的数字系统操作那么传统的可靠计算机和可靠的计算机系统有什么不同呢

5 )可靠嵌入式计算机通常是分布式系统如汽车电子航空电子和医疗设备都是必须高度可靠的分布式嵌入式系统

6 )嵌入式计算机容易受许多新类型攻击可靠计算机传统上是物理上不可访问的服务器或者机器mdashmdash物理安全长期以来是计算机安全的安全策略但是嵌入式计算机通常在非保护环境下操作这就允许新的故障和攻击这些需要都新的保护措施

2 可靠与可信ES 必需是可靠的可信的如何评价与度量

bull可靠性( Reliability) R(t)

bull可维护性( Maintainability) M(d)

bull有效性( Availability ) A(t)

bull安全性( Safety )bull保密性( Security )

可靠性定义可靠性 R(t) 产品在规定条件下和规定时间内完成规定

功能的能力产品可靠性定义的要素是三个ldquo规定rdquo 1 )ldquo规定条件rdquo包括使用时的环境条件

和工作条件2 )ldquo规定时间rdquo是指产品规定了的任务

时间3 )ldquo规定功能rdquo是指产品规定了的必须

具备的功能及其技术指标

1 )ldquo规定条件rdquo包括使用时的环境条件和工作条件 例如同一型号的汽车在高速公路和在崎岖的山路上行驶其可

靠性的表现就不大一样要谈论产品的可靠性必须指明规定的条件是什么2 )ldquo规定时间rdquo是指产品规定了的任务时间 随着产品任务时间的增加产品出现故障的概率将增加

而产品的可靠性将是下降的因此谈论产品的可靠性离不开规定的任务时间例如一辆汽车在在刚刚开出厂子和用了5 年后相比它出故障的概率显然大了很多

3 )ldquo规定功能rdquo是指产品规定了的必须具备的功能及其技术指标所要求产品功能的多少和其技术指标的高低直接影响到产品可靠性指标的高低

例如电风扇的主要功能有转叶摇头定时那么规定的功能是三者都要还是仅需要转叶能转能够吹风所得出的可靠性指标是大不一样的

可维护性 M(d)1 )计算机系统的可维护性是指该系统失效后在规定时间内可

修复到规定功能的能力2 )反映系统可维护性高低的参数是修复率秒平均修复时间3 )软件可维护性即维护人员对该软件进行维护的难易程度

具体包括理解改正改动和改进该软件的难易程度4 )决定可维护性的因素

系统的大小系统的年龄结构合理性

5 )可维护性的度量 可理解性可测试性可修改性可移植性

有效性 A(t)设备的有效性的表式为 设备有效性 = 平均故障间隔期 (平均故障间隔期+平均修理时间)

在逻辑中如果一个论证不能从真前提中得出假结论 则论证的形式是完全有效的

一个论证若被称为是有效的则如果在其中所有前提都为真的每个模型中结论也是真的

例如ldquo所有 A 是 B 有些 A 是 C 所以有些 B 是Crdquo 是有效形式

可用性 实用性

3 可靠系统设计的基本原理1 )故障 (faults) 分析2 )可靠性分析3 )纠错技术4 )软件可靠性

1 )故障 (faults) 分析永久 (permanent) 与暂时( transient )故障故障来源 物理故障 (Physical faults)由生产缺陷辐射危害等等引起

设计故障 (Design faults) 是不合适设计的系统的结果

操作故障 (Operational faults) 来自人为过失安全破坏劣质设计的人机接口等等

可靠性设计

故障及其分类 产品的故障按其故障规律分为两大类

偶然故障 渐变故障

产品的故障按其故障后果分为两大类 致命性故障 非致命性故障

产品的故障按其统计特性分为两大类 独立故障 从属故障

可靠度 产品在规定的条件下和规定的时间内完成规

定功能的概率称为可靠度依定义可知系统的可靠度是时间的函数表示为

式中 R(t)mdashmdash 可靠度函数 ξmdashmdash 产生故障前的工作时间 t mdashmdash 规定的时间

)()( tPtR

2 )可靠性的分析mdashmdash可靠度

可靠度函数

依定义可知可靠度函数 R(t) 为

式中 N0 mdashmdash t = 0 时在规定条件下进行工作的产品数

r(t) mdashmdash  在 0 到 t 时刻的工作时间内产品的累计

故障数

0

0 )()(

N

trNtR

累积故障分布函数 产品在规定的条件下和规定的时间内丧失

规定功能的概率称为累积故障概率(又叫不可靠度) 依定义可知产品的累积故障概率是时间的函

数即

显然以下关系成立

0

)()(

N

trtF

1)()( tFtR

可靠度函数与累积故障分布函数的性质

图 R(t)F(t)与f(t)的关系t

f(t)

f(t)

F(to)

R(to)

to

由密度函数的性质 1)(0

dttf 可知

t

tdttfdttftFtR )()(1)(1)(

0

因此 R(t) F(t) 与 f(t) 之间的关系如图所示

故障率函数 故障率

工作到某时刻尚未发生故障的产品在该时刻后单位时间内发生故障的概率称之为产品的故障率

用数学符号表示为

式中 (t) mdashmdash 故障率 dr(t) mdashmdash t 时刻后 dt 时间内故障的产品数 Ns(t) mdashmdash 残存产品数即到 t 时刻尚未故障的产品

dttN

tdrt

s )(

)()(

35

故障率函数

可按下式进行工程计算

式中 Δr(t) mdashmdash t 时刻后 Δt 时间内故障的产品数

Δt mdashmdash 所取时间间隔 Ns(t) mdashmdash 残存产品数

对于低故障率的元部件常以 10-9h 为故障率的单位称之为菲特( Fit )

ttN

trt

s

)(

)()(

产品故障浴盆曲线 浴盆曲线

大多数产品的故障率随时间的变化曲线形似浴盆称之为浴盆曲线由于产品故障机理的不同产品的故障率随时间的变化大致可以分为三个阶段

产品典型的故障率曲线

t

使用寿命

早期故障

偶然故障 耗损故障

A B规定的故障率 维修后故障率下降

(t)

3 )纠错技术( 1 )纠错码 在 1950s就开始研究最早的是可以检测和纠错的汉明码它们通过数字系统广泛地用于识别和纠正短暂或者持久的错误这些码引入冗余信息来确保一些类型的错误可以被检测和纠正比如一个单错校正 双错校正的码能用一个比特检测和纠正一个错误但是不能用两个比特纠错

( 2 )三模冗余 (triple modular

redundancy) 计算单元 C 有三个副本 C1C2和 C3三个单元接收同

样的输入一个独立单元比较每个输入的结果如果至少两个结果一致那么那个值被表决器选做正确结果如果三个结果都不相同那么就没有正确的结果

1C

2C

3C

表决错误

结果

输入

( 3 )看门狗定时器 (watchdog timer)

看门狗定时器 (watchdog timer)被广泛地用于检测系统问题如图 看门狗定时器连接到一个监视系统如果这个看门狗定时器翻转它产生一个完成信号用于标注系统的错误中断系统应该这样设计当适当运行的时候它一直在可能产生翻转信号之前复位定时器因此来自看门狗定时器的完成信号指示系统在一定程度上不合适地操作看门狗定时器用于预防不同的故障

系统看门狗定时器

完成

复位

( 4 )设计多样性 (Design diversity)

一种用于减少一些系统错误进入设计的设计方法学当一个设计需要给定模块的不同实例应该采用模块的不同实现而不是到处都用同一种模块比如一个有多个 CPU的系统可能采用不同类型的 CPU而不是到处采用同一种类型的 CPU在一个三模冗余系统产生表决结构的组件可能有不同的实现这样可以减少产生同样设计错误的机会

4 )软件可靠性ldquo在规定的条件下在规定的时间内软件不引起失效的概率rdquo

规定的条件 软件运行的软硬件环境 软件操作剖面软件运行的输入空间及其概率分布

规定的时间 日历时间 时钟时间 执行时间

激活软件 输入域 缺陷的数据

软件缺陷 软件

不可接受的结果 (软件故障) 输出域

软件故障的特点

软件与硬件可靠性的区别硬件 软件

故障机理 老化损耗 残留缺陷在一定环境下造成的软件错误

复杂性 内部逻辑较为简单 内部逻辑高度复杂这就在很大程度上决定了设计错误是导致软件故障的主要原因

唯一性 任何两个硬件不可能绝对相同

软件是唯一的软件拷贝不改变软件本身

可靠性的核心 内部元部件 设计者的思维和软件的复杂性纠错维护方法 修复或更换失效的元部件 重设计 可靠性检验标准化

已标准化且有一整套完整的理论

仍未建立更没有完整的理论体系

产品市场 已有成熟的产品市场 产品市场还很新 错误性质 一些瞬间的硬件错误可能

会被误认为是软件错误 软件错误是永恒的可重现的

影响软件可靠性的因素( 1 )运行环境 ( 剖面 )

同一软件在不同运行剖面下其可靠性行为可能极不相同 软件故障是软件缺陷在一定输入情况下被激活的结果 假设软件输入域划分为两个部分 G 和 F 运行剖面不包含 F 中

的输入则软件不会出现故障其可靠性恒为 l 反之如果运行剖面不包含 G 中的输入则每一输入情况下均出现故障如果没有容错措施则 R=0

( 2 )软件规模 随着软件规模的增大软件可靠性问题愈显突出在我们考虑软件

可靠性问题时软件一般是指中型以上软件 (4000-5000条以上语句 ) 这时可靠性问题难以对付

软件工程实践的一个侧面可以反映这一点即单元测试一般由编程人员本人进行而综合测试则需独立的测试人员

影响软件可靠性的因素( 3 )软件内部结构

结构越复杂软件复杂度越高内含缺陷数越大因而软件可靠度越低

( 4 )软件可靠性设计技术 一般是指软件设计阶段中采用的用以保证和提高软件可靠性为主要目标的软件技术

( 5 )软件可靠性测试 研究表明软件测试方法与资源投入对软件可靠性有不可忽视的影

响( 6 )软件可靠性管理

软件可靠性管理旨在系统管理软件生存期各阶段的可靠性活动使之系统化规范化一体化这样就可以避免许多人为错误以提高软件可靠性

影响软件可靠性的因素( 7 )软件开发人员能力和经验

软件开发人员 ( 包括测试人员 ) 的能力愈强经验愈丰富所犯错误便可能愈少所得软件产品质量愈高相应的可靠性也愈高

( 8 )软件开发方法 软件工程表明开发方法对软件可靠性有显著影响 与非结构化方法比较结构化方法可以明显减少软件缺陷数

( 9 )软件开发环境 研究表明程序语言软件开发环境影响软件的可靠性而软件测

试工具的优劣则影响可靠性测试结果

4 安全 (Safety)amp保密 (Security)

安全 (Safety) 是保证财产和人身受到损害可靠性是指在一定的环境条件下以及一定的时间内系统完成特定任务的可能性而有效性则是系统的长期的工作时间于其存在时间 ( 简单的定义为运行时间 +维护时间 ) 的 比例保密 (Security) 是针对危险破坏损失或非法活动而进行措施在一定层面上保密 (Security)要比安全 (Safety)宽广的多例如信息 Security家庭 Security 网络 Security 国家Security) 等

Security强调的是外在事物对特定目标的危害

Safety 是系统本身的潜在危害

四个概念的比较分析安全 (Safety)可靠性 (Reliability)有效性 (Availability)保密 (Security )安全 (Safety)高的系统 软件可靠性不

一定高可靠性和有效性并不是一码事保密 (Security )的系统 软件是安全

(Safety) 系统 软件的重要保障

可靠性安全性保密性 可靠(或可信)系统设计 (Reliable (or dependable) system design)是制造嵌入式系统所关注的甚至在面对内部或者外部问题时可靠系统设计经常假设问题是非恶意引起的

安全重要的系统设计 (Safety-critical system design)研究确保系统安全操作的方法独立于引起问题的原因

保密性 (Security)主要关注恶意攻击

Aizientis等人描述了可信性和保密性间的关系可信性和保密性由几个特性所组成

服务的可用性 (Availability) 服务的连续性 (Continuity) 来自用户和所处环境的灾难性后果的安全性 (Safety) 来自不合适系统改变的完整性 (Integrity) 通过更改和修补的可维护性 (Maintainability) 信息的机密性 (Confidentiality)

可用性完整性

可靠性安全性可维护性

机密性

可信性 保密性

5 新型攻击和对策1 )物理攻击嵌入式系统比通用计算机更容易受攻击 一个关键原因是许多嵌入式计算机对攻击者可物理访问

2 )互联网攻击一些嵌入式系统的攻击通过互联网访问变得更加容易今天许多嵌入式系统连接到互联网

3 )电池攻击 (battery attack)这种攻击试图通过耗尽电池来关闭节点

4 )服务拒绝攻击 (Denial-of-service attacks)

在通用系统中众所周知但是实时嵌入式系统可能更容易受服务质量 (quality-of-service (QoS))攻击如果网络发布实时数据那么发送过程中的一点延迟都能引起数据无效如果那些数据用来实时控制那么这些短暂延迟就能引起系统故障我们称这种危害为时间攻击因为它改变了系统的实时特性

QoS或者时间攻击之所以强大使因为它的影响不仅仅限于信息被控制系统的动态特性可决定系统的响应如果一个大型沉重快速运动的系统被控制那么时间上一个相对小的改变能引起大量的破坏

5 )网络(协议)攻击Wood和 Stankovic[Woo02]在传感器网络上确定了一些方式这些方式可在网络层次的不同层执行拒绝服务攻击如下所列

物理层 (Physical layer)mdashmdash拥塞破坏 链路层 (Link layer)mdashmdash碰撞耗尽非公平

网络和路由层 (Network and routing layer)mdashmdash丢弃和贪婪汇集方向误导黑洞认证监视冗余

传输层 (Transport layer)mdashmdash泛洪失步

6 )能量攻击Kocher等人 [Koc99]指出测量一个 CPU当前的能量供给能在很大程度上确定处理器的内部活动他们提出了两种能量攻击的方法简单能量分析 (simple power analysis)人工地跟踪检查和尝试确定程序作用的位置比如分支基于不同 CUP操作的能耗知识基于程序作用攻击者然后减少密钥的比特差分能量分析 (Differential power analysis)用相关性确定作用和密钥比特这种攻击最初目标是智能卡这种卡从外部读卡器获取能量但是这种攻击也能应用到许多嵌入式系统中

7 )反攻击 在一些时候有可能构造反破坏的嵌入式系统使电子设备难以发觉和分析延缓了攻击者芯片中有限的信息也有助阻止攻击者发现数据

6 Efficiency (效率)

ES must be efficient

bull Code-size efficient( 特别是片上系统 )

bull Run-time efficient

bull Weight efficient

bull Cost efficient

bull Energy efficient

能量有效性的重要意义

ldquoinherent power

efficiency of siliconldquo

59

低功耗设计问题 功耗问题是近几年来人们在嵌入式系统的设计中普遍关注的难点和热点它严重地制约着嵌入式系统的应用与发展

无论是在军事还是在商业贸易上的应用相当数量的嵌入式系统一般是由电池来供给电能的而且大多数嵌入式设备都有体积和质量的约束减少电能消耗不仅能延长电池的使用寿命延长用户更换电池的周期而且能带来提高系统性能与降低系统开销的好处甚至能起到保护环境的作用在便携式设备中 CPU消耗的电能越少电池的寿命就越长同时散发的热量少了所需的散热器就少了从而可减少该设备的花费和体积使产品尽快进入市场的目标

1 低功耗嵌入式应用系统是指以降低系统功耗为一个主要性能指标的嵌入式系统如计算机里的许多芯片过去用 5V供电现在用 33V 18V 并提出了绿色电器的概念

60

低功耗设备的要求1 )首先要求体积小重量轻便于携带2 )采用低功耗电路的设计方法以降低系统的功耗

它除了选用各种低功耗的器件和芯片外还在满足速度等性能指标的前提下进行降低功耗的硬件电路设计和软件设计

3 )有的系统应用在交流供电比较困难甚至无法用交流供电的场合因而各种电池(瓶)就成为其主要供电手段

4 )采用 LCD液晶显示器5 )采用 RS232C串行通信接口6 )采用微功耗高抗干扰的 CMOS集成电路

功耗产生的原因 P=UI

与功耗有关的因素

( 1 )电阻上消耗的功率( 2 )有源器件的开关转换阶段( 3 )集成电路内部和外部电容的充放电( 4 )系统的性能指标负载能力被处理信号的工作频率电路的工作频率电源的管理水平零部件的性能散热条件接口的物理性能等对系统功耗起着重要的作用

降低功耗的措施

功耗的组成动态 + 静态动态电源管理动态电压缩放低功耗硬件设计低功耗软件设计

二设计方法学概论

问题功 能 性能要求价 格 开发 周 期 等约束

设计 选择 折衷 分析比较 计算 评价

嵌入式系统

0嵌入式系统设计概述

方法 工具

设计方法论( design methodology )

设计方法论有以下三个重要理由1 )确认我们所做的每一件事情都是必须要作的

不会做无谓的白工也不会漏掉关键性的重要工作其中包含效率优化或是功能测试

2 )可以发展出计算机辅助工具或是设计经验累积汲取每一次产品发展的经验再经过量化之后可以发展出一套工具或是方法让往后的产品设计步入自动化

3 )开发团队遵循同一套方法论可以让团队成员更容易彼此沟通每个人都能在短时间内了解整体过程中将经历哪些过程需要何种支持与接收到何种结果此外也容易透过一套已经定义好的方法论彼此相互合作协调

设计目标 1 )上市时间

也就是 time-to-market 的观念2 )设计成本

许多消费性产品对于价格非常敏感所以产品厂商对于成本会斤斤计较是很合理的

3 )品质 顾客也许不需要最快最便宜的产品但是一定会要求功能质量保证不能只用一小段时间就坏掉了

传统的设计主要步骤

2 传统的设计流程方法1 )瀑布模型 (Waterfall)2 )螺旋模型 (Spiral)3 )连续改进 (Successive Refinement)4 )硬件与软件的同步设计 (SWHW Co-

deign)5 )阶层式 (Hierarchical) 设计6 )同步工程( concurrent

engineering )

瀑布模型 (Waterfall)

螺旋模型 (Spiral)

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 17: 大学计算机基础 —— 计算机科学概论

混成系统的典型特征( 1) 系统内存在着性质不同的连续和离散两类变量( 2) 时间和事件共同驱动系统的状态演化 ( 3)连续变量穿越阈值使状态使能或失能 ( 4)离散状态的变化改变连续变量遵循的变化速率 ( 5)离散事件发生在离散时刻 具有顺序选择并发等特色

( 6)状态呈阶段性间歇性切换变化 动态特征显著 ( 7) 对系统的控制表现为对连续状态和离散状态的集成控制 ( 8) 对系统的优化表现为在定性 定量双重指标下的集成优化

6 专用系统 Dedicated towards a certain

applicationKnowledge about behavior at design time can be used to minimize resources and to maximize robustness

Dedicated user interface(no mouse keyboard and screen)

二设计的挑战 实时可信可靠保密安全

1 为什么需要可靠的嵌入式系统1 )许多市场不需要高度可靠的嵌入式计算机但是许多嵌入式计算机必须

是高度可靠的2 )许多嵌入式计算机必须是高度可靠的汽车电子航空电子医疗设备

关键通信3 )可靠性的定义如电话交换机系统每年停机少于 30秒4 )关于可靠数字系统设计的研究几十年前就有不同的体系结构和方法学

被开发用于长周期低失误率的数字系统操作那么传统的可靠计算机和可靠的计算机系统有什么不同呢

5 )可靠嵌入式计算机通常是分布式系统如汽车电子航空电子和医疗设备都是必须高度可靠的分布式嵌入式系统

6 )嵌入式计算机容易受许多新类型攻击可靠计算机传统上是物理上不可访问的服务器或者机器mdashmdash物理安全长期以来是计算机安全的安全策略但是嵌入式计算机通常在非保护环境下操作这就允许新的故障和攻击这些需要都新的保护措施

2 可靠与可信ES 必需是可靠的可信的如何评价与度量

bull可靠性( Reliability) R(t)

bull可维护性( Maintainability) M(d)

bull有效性( Availability ) A(t)

bull安全性( Safety )bull保密性( Security )

可靠性定义可靠性 R(t) 产品在规定条件下和规定时间内完成规定

功能的能力产品可靠性定义的要素是三个ldquo规定rdquo 1 )ldquo规定条件rdquo包括使用时的环境条件

和工作条件2 )ldquo规定时间rdquo是指产品规定了的任务

时间3 )ldquo规定功能rdquo是指产品规定了的必须

具备的功能及其技术指标

1 )ldquo规定条件rdquo包括使用时的环境条件和工作条件 例如同一型号的汽车在高速公路和在崎岖的山路上行驶其可

靠性的表现就不大一样要谈论产品的可靠性必须指明规定的条件是什么2 )ldquo规定时间rdquo是指产品规定了的任务时间 随着产品任务时间的增加产品出现故障的概率将增加

而产品的可靠性将是下降的因此谈论产品的可靠性离不开规定的任务时间例如一辆汽车在在刚刚开出厂子和用了5 年后相比它出故障的概率显然大了很多

3 )ldquo规定功能rdquo是指产品规定了的必须具备的功能及其技术指标所要求产品功能的多少和其技术指标的高低直接影响到产品可靠性指标的高低

例如电风扇的主要功能有转叶摇头定时那么规定的功能是三者都要还是仅需要转叶能转能够吹风所得出的可靠性指标是大不一样的

可维护性 M(d)1 )计算机系统的可维护性是指该系统失效后在规定时间内可

修复到规定功能的能力2 )反映系统可维护性高低的参数是修复率秒平均修复时间3 )软件可维护性即维护人员对该软件进行维护的难易程度

具体包括理解改正改动和改进该软件的难易程度4 )决定可维护性的因素

系统的大小系统的年龄结构合理性

5 )可维护性的度量 可理解性可测试性可修改性可移植性

有效性 A(t)设备的有效性的表式为 设备有效性 = 平均故障间隔期 (平均故障间隔期+平均修理时间)

在逻辑中如果一个论证不能从真前提中得出假结论 则论证的形式是完全有效的

一个论证若被称为是有效的则如果在其中所有前提都为真的每个模型中结论也是真的

例如ldquo所有 A 是 B 有些 A 是 C 所以有些 B 是Crdquo 是有效形式

可用性 实用性

3 可靠系统设计的基本原理1 )故障 (faults) 分析2 )可靠性分析3 )纠错技术4 )软件可靠性

1 )故障 (faults) 分析永久 (permanent) 与暂时( transient )故障故障来源 物理故障 (Physical faults)由生产缺陷辐射危害等等引起

设计故障 (Design faults) 是不合适设计的系统的结果

操作故障 (Operational faults) 来自人为过失安全破坏劣质设计的人机接口等等

可靠性设计

故障及其分类 产品的故障按其故障规律分为两大类

偶然故障 渐变故障

产品的故障按其故障后果分为两大类 致命性故障 非致命性故障

产品的故障按其统计特性分为两大类 独立故障 从属故障

可靠度 产品在规定的条件下和规定的时间内完成规

定功能的概率称为可靠度依定义可知系统的可靠度是时间的函数表示为

式中 R(t)mdashmdash 可靠度函数 ξmdashmdash 产生故障前的工作时间 t mdashmdash 规定的时间

)()( tPtR

2 )可靠性的分析mdashmdash可靠度

可靠度函数

依定义可知可靠度函数 R(t) 为

式中 N0 mdashmdash t = 0 时在规定条件下进行工作的产品数

r(t) mdashmdash  在 0 到 t 时刻的工作时间内产品的累计

故障数

0

0 )()(

N

trNtR

累积故障分布函数 产品在规定的条件下和规定的时间内丧失

规定功能的概率称为累积故障概率(又叫不可靠度) 依定义可知产品的累积故障概率是时间的函

数即

显然以下关系成立

0

)()(

N

trtF

1)()( tFtR

可靠度函数与累积故障分布函数的性质

图 R(t)F(t)与f(t)的关系t

f(t)

f(t)

F(to)

R(to)

to

由密度函数的性质 1)(0

dttf 可知

t

tdttfdttftFtR )()(1)(1)(

0

因此 R(t) F(t) 与 f(t) 之间的关系如图所示

故障率函数 故障率

工作到某时刻尚未发生故障的产品在该时刻后单位时间内发生故障的概率称之为产品的故障率

用数学符号表示为

式中 (t) mdashmdash 故障率 dr(t) mdashmdash t 时刻后 dt 时间内故障的产品数 Ns(t) mdashmdash 残存产品数即到 t 时刻尚未故障的产品

dttN

tdrt

s )(

)()(

35

故障率函数

可按下式进行工程计算

式中 Δr(t) mdashmdash t 时刻后 Δt 时间内故障的产品数

Δt mdashmdash 所取时间间隔 Ns(t) mdashmdash 残存产品数

对于低故障率的元部件常以 10-9h 为故障率的单位称之为菲特( Fit )

ttN

trt

s

)(

)()(

产品故障浴盆曲线 浴盆曲线

大多数产品的故障率随时间的变化曲线形似浴盆称之为浴盆曲线由于产品故障机理的不同产品的故障率随时间的变化大致可以分为三个阶段

产品典型的故障率曲线

t

使用寿命

早期故障

偶然故障 耗损故障

A B规定的故障率 维修后故障率下降

(t)

3 )纠错技术( 1 )纠错码 在 1950s就开始研究最早的是可以检测和纠错的汉明码它们通过数字系统广泛地用于识别和纠正短暂或者持久的错误这些码引入冗余信息来确保一些类型的错误可以被检测和纠正比如一个单错校正 双错校正的码能用一个比特检测和纠正一个错误但是不能用两个比特纠错

( 2 )三模冗余 (triple modular

redundancy) 计算单元 C 有三个副本 C1C2和 C3三个单元接收同

样的输入一个独立单元比较每个输入的结果如果至少两个结果一致那么那个值被表决器选做正确结果如果三个结果都不相同那么就没有正确的结果

1C

2C

3C

表决错误

结果

输入

( 3 )看门狗定时器 (watchdog timer)

看门狗定时器 (watchdog timer)被广泛地用于检测系统问题如图 看门狗定时器连接到一个监视系统如果这个看门狗定时器翻转它产生一个完成信号用于标注系统的错误中断系统应该这样设计当适当运行的时候它一直在可能产生翻转信号之前复位定时器因此来自看门狗定时器的完成信号指示系统在一定程度上不合适地操作看门狗定时器用于预防不同的故障

系统看门狗定时器

完成

复位

( 4 )设计多样性 (Design diversity)

一种用于减少一些系统错误进入设计的设计方法学当一个设计需要给定模块的不同实例应该采用模块的不同实现而不是到处都用同一种模块比如一个有多个 CPU的系统可能采用不同类型的 CPU而不是到处采用同一种类型的 CPU在一个三模冗余系统产生表决结构的组件可能有不同的实现这样可以减少产生同样设计错误的机会

4 )软件可靠性ldquo在规定的条件下在规定的时间内软件不引起失效的概率rdquo

规定的条件 软件运行的软硬件环境 软件操作剖面软件运行的输入空间及其概率分布

规定的时间 日历时间 时钟时间 执行时间

激活软件 输入域 缺陷的数据

软件缺陷 软件

不可接受的结果 (软件故障) 输出域

软件故障的特点

软件与硬件可靠性的区别硬件 软件

故障机理 老化损耗 残留缺陷在一定环境下造成的软件错误

复杂性 内部逻辑较为简单 内部逻辑高度复杂这就在很大程度上决定了设计错误是导致软件故障的主要原因

唯一性 任何两个硬件不可能绝对相同

软件是唯一的软件拷贝不改变软件本身

可靠性的核心 内部元部件 设计者的思维和软件的复杂性纠错维护方法 修复或更换失效的元部件 重设计 可靠性检验标准化

已标准化且有一整套完整的理论

仍未建立更没有完整的理论体系

产品市场 已有成熟的产品市场 产品市场还很新 错误性质 一些瞬间的硬件错误可能

会被误认为是软件错误 软件错误是永恒的可重现的

影响软件可靠性的因素( 1 )运行环境 ( 剖面 )

同一软件在不同运行剖面下其可靠性行为可能极不相同 软件故障是软件缺陷在一定输入情况下被激活的结果 假设软件输入域划分为两个部分 G 和 F 运行剖面不包含 F 中

的输入则软件不会出现故障其可靠性恒为 l 反之如果运行剖面不包含 G 中的输入则每一输入情况下均出现故障如果没有容错措施则 R=0

( 2 )软件规模 随着软件规模的增大软件可靠性问题愈显突出在我们考虑软件

可靠性问题时软件一般是指中型以上软件 (4000-5000条以上语句 ) 这时可靠性问题难以对付

软件工程实践的一个侧面可以反映这一点即单元测试一般由编程人员本人进行而综合测试则需独立的测试人员

影响软件可靠性的因素( 3 )软件内部结构

结构越复杂软件复杂度越高内含缺陷数越大因而软件可靠度越低

( 4 )软件可靠性设计技术 一般是指软件设计阶段中采用的用以保证和提高软件可靠性为主要目标的软件技术

( 5 )软件可靠性测试 研究表明软件测试方法与资源投入对软件可靠性有不可忽视的影

响( 6 )软件可靠性管理

软件可靠性管理旨在系统管理软件生存期各阶段的可靠性活动使之系统化规范化一体化这样就可以避免许多人为错误以提高软件可靠性

影响软件可靠性的因素( 7 )软件开发人员能力和经验

软件开发人员 ( 包括测试人员 ) 的能力愈强经验愈丰富所犯错误便可能愈少所得软件产品质量愈高相应的可靠性也愈高

( 8 )软件开发方法 软件工程表明开发方法对软件可靠性有显著影响 与非结构化方法比较结构化方法可以明显减少软件缺陷数

( 9 )软件开发环境 研究表明程序语言软件开发环境影响软件的可靠性而软件测

试工具的优劣则影响可靠性测试结果

4 安全 (Safety)amp保密 (Security)

安全 (Safety) 是保证财产和人身受到损害可靠性是指在一定的环境条件下以及一定的时间内系统完成特定任务的可能性而有效性则是系统的长期的工作时间于其存在时间 ( 简单的定义为运行时间 +维护时间 ) 的 比例保密 (Security) 是针对危险破坏损失或非法活动而进行措施在一定层面上保密 (Security)要比安全 (Safety)宽广的多例如信息 Security家庭 Security 网络 Security 国家Security) 等

Security强调的是外在事物对特定目标的危害

Safety 是系统本身的潜在危害

四个概念的比较分析安全 (Safety)可靠性 (Reliability)有效性 (Availability)保密 (Security )安全 (Safety)高的系统 软件可靠性不

一定高可靠性和有效性并不是一码事保密 (Security )的系统 软件是安全

(Safety) 系统 软件的重要保障

可靠性安全性保密性 可靠(或可信)系统设计 (Reliable (or dependable) system design)是制造嵌入式系统所关注的甚至在面对内部或者外部问题时可靠系统设计经常假设问题是非恶意引起的

安全重要的系统设计 (Safety-critical system design)研究确保系统安全操作的方法独立于引起问题的原因

保密性 (Security)主要关注恶意攻击

Aizientis等人描述了可信性和保密性间的关系可信性和保密性由几个特性所组成

服务的可用性 (Availability) 服务的连续性 (Continuity) 来自用户和所处环境的灾难性后果的安全性 (Safety) 来自不合适系统改变的完整性 (Integrity) 通过更改和修补的可维护性 (Maintainability) 信息的机密性 (Confidentiality)

可用性完整性

可靠性安全性可维护性

机密性

可信性 保密性

5 新型攻击和对策1 )物理攻击嵌入式系统比通用计算机更容易受攻击 一个关键原因是许多嵌入式计算机对攻击者可物理访问

2 )互联网攻击一些嵌入式系统的攻击通过互联网访问变得更加容易今天许多嵌入式系统连接到互联网

3 )电池攻击 (battery attack)这种攻击试图通过耗尽电池来关闭节点

4 )服务拒绝攻击 (Denial-of-service attacks)

在通用系统中众所周知但是实时嵌入式系统可能更容易受服务质量 (quality-of-service (QoS))攻击如果网络发布实时数据那么发送过程中的一点延迟都能引起数据无效如果那些数据用来实时控制那么这些短暂延迟就能引起系统故障我们称这种危害为时间攻击因为它改变了系统的实时特性

QoS或者时间攻击之所以强大使因为它的影响不仅仅限于信息被控制系统的动态特性可决定系统的响应如果一个大型沉重快速运动的系统被控制那么时间上一个相对小的改变能引起大量的破坏

5 )网络(协议)攻击Wood和 Stankovic[Woo02]在传感器网络上确定了一些方式这些方式可在网络层次的不同层执行拒绝服务攻击如下所列

物理层 (Physical layer)mdashmdash拥塞破坏 链路层 (Link layer)mdashmdash碰撞耗尽非公平

网络和路由层 (Network and routing layer)mdashmdash丢弃和贪婪汇集方向误导黑洞认证监视冗余

传输层 (Transport layer)mdashmdash泛洪失步

6 )能量攻击Kocher等人 [Koc99]指出测量一个 CPU当前的能量供给能在很大程度上确定处理器的内部活动他们提出了两种能量攻击的方法简单能量分析 (simple power analysis)人工地跟踪检查和尝试确定程序作用的位置比如分支基于不同 CUP操作的能耗知识基于程序作用攻击者然后减少密钥的比特差分能量分析 (Differential power analysis)用相关性确定作用和密钥比特这种攻击最初目标是智能卡这种卡从外部读卡器获取能量但是这种攻击也能应用到许多嵌入式系统中

7 )反攻击 在一些时候有可能构造反破坏的嵌入式系统使电子设备难以发觉和分析延缓了攻击者芯片中有限的信息也有助阻止攻击者发现数据

6 Efficiency (效率)

ES must be efficient

bull Code-size efficient( 特别是片上系统 )

bull Run-time efficient

bull Weight efficient

bull Cost efficient

bull Energy efficient

能量有效性的重要意义

ldquoinherent power

efficiency of siliconldquo

59

低功耗设计问题 功耗问题是近几年来人们在嵌入式系统的设计中普遍关注的难点和热点它严重地制约着嵌入式系统的应用与发展

无论是在军事还是在商业贸易上的应用相当数量的嵌入式系统一般是由电池来供给电能的而且大多数嵌入式设备都有体积和质量的约束减少电能消耗不仅能延长电池的使用寿命延长用户更换电池的周期而且能带来提高系统性能与降低系统开销的好处甚至能起到保护环境的作用在便携式设备中 CPU消耗的电能越少电池的寿命就越长同时散发的热量少了所需的散热器就少了从而可减少该设备的花费和体积使产品尽快进入市场的目标

1 低功耗嵌入式应用系统是指以降低系统功耗为一个主要性能指标的嵌入式系统如计算机里的许多芯片过去用 5V供电现在用 33V 18V 并提出了绿色电器的概念

60

低功耗设备的要求1 )首先要求体积小重量轻便于携带2 )采用低功耗电路的设计方法以降低系统的功耗

它除了选用各种低功耗的器件和芯片外还在满足速度等性能指标的前提下进行降低功耗的硬件电路设计和软件设计

3 )有的系统应用在交流供电比较困难甚至无法用交流供电的场合因而各种电池(瓶)就成为其主要供电手段

4 )采用 LCD液晶显示器5 )采用 RS232C串行通信接口6 )采用微功耗高抗干扰的 CMOS集成电路

功耗产生的原因 P=UI

与功耗有关的因素

( 1 )电阻上消耗的功率( 2 )有源器件的开关转换阶段( 3 )集成电路内部和外部电容的充放电( 4 )系统的性能指标负载能力被处理信号的工作频率电路的工作频率电源的管理水平零部件的性能散热条件接口的物理性能等对系统功耗起着重要的作用

降低功耗的措施

功耗的组成动态 + 静态动态电源管理动态电压缩放低功耗硬件设计低功耗软件设计

二设计方法学概论

问题功 能 性能要求价 格 开发 周 期 等约束

设计 选择 折衷 分析比较 计算 评价

嵌入式系统

0嵌入式系统设计概述

方法 工具

设计方法论( design methodology )

设计方法论有以下三个重要理由1 )确认我们所做的每一件事情都是必须要作的

不会做无谓的白工也不会漏掉关键性的重要工作其中包含效率优化或是功能测试

2 )可以发展出计算机辅助工具或是设计经验累积汲取每一次产品发展的经验再经过量化之后可以发展出一套工具或是方法让往后的产品设计步入自动化

3 )开发团队遵循同一套方法论可以让团队成员更容易彼此沟通每个人都能在短时间内了解整体过程中将经历哪些过程需要何种支持与接收到何种结果此外也容易透过一套已经定义好的方法论彼此相互合作协调

设计目标 1 )上市时间

也就是 time-to-market 的观念2 )设计成本

许多消费性产品对于价格非常敏感所以产品厂商对于成本会斤斤计较是很合理的

3 )品质 顾客也许不需要最快最便宜的产品但是一定会要求功能质量保证不能只用一小段时间就坏掉了

传统的设计主要步骤

2 传统的设计流程方法1 )瀑布模型 (Waterfall)2 )螺旋模型 (Spiral)3 )连续改进 (Successive Refinement)4 )硬件与软件的同步设计 (SWHW Co-

deign)5 )阶层式 (Hierarchical) 设计6 )同步工程( concurrent

engineering )

瀑布模型 (Waterfall)

螺旋模型 (Spiral)

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 18: 大学计算机基础 —— 计算机科学概论

6 专用系统 Dedicated towards a certain

applicationKnowledge about behavior at design time can be used to minimize resources and to maximize robustness

Dedicated user interface(no mouse keyboard and screen)

二设计的挑战 实时可信可靠保密安全

1 为什么需要可靠的嵌入式系统1 )许多市场不需要高度可靠的嵌入式计算机但是许多嵌入式计算机必须

是高度可靠的2 )许多嵌入式计算机必须是高度可靠的汽车电子航空电子医疗设备

关键通信3 )可靠性的定义如电话交换机系统每年停机少于 30秒4 )关于可靠数字系统设计的研究几十年前就有不同的体系结构和方法学

被开发用于长周期低失误率的数字系统操作那么传统的可靠计算机和可靠的计算机系统有什么不同呢

5 )可靠嵌入式计算机通常是分布式系统如汽车电子航空电子和医疗设备都是必须高度可靠的分布式嵌入式系统

6 )嵌入式计算机容易受许多新类型攻击可靠计算机传统上是物理上不可访问的服务器或者机器mdashmdash物理安全长期以来是计算机安全的安全策略但是嵌入式计算机通常在非保护环境下操作这就允许新的故障和攻击这些需要都新的保护措施

2 可靠与可信ES 必需是可靠的可信的如何评价与度量

bull可靠性( Reliability) R(t)

bull可维护性( Maintainability) M(d)

bull有效性( Availability ) A(t)

bull安全性( Safety )bull保密性( Security )

可靠性定义可靠性 R(t) 产品在规定条件下和规定时间内完成规定

功能的能力产品可靠性定义的要素是三个ldquo规定rdquo 1 )ldquo规定条件rdquo包括使用时的环境条件

和工作条件2 )ldquo规定时间rdquo是指产品规定了的任务

时间3 )ldquo规定功能rdquo是指产品规定了的必须

具备的功能及其技术指标

1 )ldquo规定条件rdquo包括使用时的环境条件和工作条件 例如同一型号的汽车在高速公路和在崎岖的山路上行驶其可

靠性的表现就不大一样要谈论产品的可靠性必须指明规定的条件是什么2 )ldquo规定时间rdquo是指产品规定了的任务时间 随着产品任务时间的增加产品出现故障的概率将增加

而产品的可靠性将是下降的因此谈论产品的可靠性离不开规定的任务时间例如一辆汽车在在刚刚开出厂子和用了5 年后相比它出故障的概率显然大了很多

3 )ldquo规定功能rdquo是指产品规定了的必须具备的功能及其技术指标所要求产品功能的多少和其技术指标的高低直接影响到产品可靠性指标的高低

例如电风扇的主要功能有转叶摇头定时那么规定的功能是三者都要还是仅需要转叶能转能够吹风所得出的可靠性指标是大不一样的

可维护性 M(d)1 )计算机系统的可维护性是指该系统失效后在规定时间内可

修复到规定功能的能力2 )反映系统可维护性高低的参数是修复率秒平均修复时间3 )软件可维护性即维护人员对该软件进行维护的难易程度

具体包括理解改正改动和改进该软件的难易程度4 )决定可维护性的因素

系统的大小系统的年龄结构合理性

5 )可维护性的度量 可理解性可测试性可修改性可移植性

有效性 A(t)设备的有效性的表式为 设备有效性 = 平均故障间隔期 (平均故障间隔期+平均修理时间)

在逻辑中如果一个论证不能从真前提中得出假结论 则论证的形式是完全有效的

一个论证若被称为是有效的则如果在其中所有前提都为真的每个模型中结论也是真的

例如ldquo所有 A 是 B 有些 A 是 C 所以有些 B 是Crdquo 是有效形式

可用性 实用性

3 可靠系统设计的基本原理1 )故障 (faults) 分析2 )可靠性分析3 )纠错技术4 )软件可靠性

1 )故障 (faults) 分析永久 (permanent) 与暂时( transient )故障故障来源 物理故障 (Physical faults)由生产缺陷辐射危害等等引起

设计故障 (Design faults) 是不合适设计的系统的结果

操作故障 (Operational faults) 来自人为过失安全破坏劣质设计的人机接口等等

可靠性设计

故障及其分类 产品的故障按其故障规律分为两大类

偶然故障 渐变故障

产品的故障按其故障后果分为两大类 致命性故障 非致命性故障

产品的故障按其统计特性分为两大类 独立故障 从属故障

可靠度 产品在规定的条件下和规定的时间内完成规

定功能的概率称为可靠度依定义可知系统的可靠度是时间的函数表示为

式中 R(t)mdashmdash 可靠度函数 ξmdashmdash 产生故障前的工作时间 t mdashmdash 规定的时间

)()( tPtR

2 )可靠性的分析mdashmdash可靠度

可靠度函数

依定义可知可靠度函数 R(t) 为

式中 N0 mdashmdash t = 0 时在规定条件下进行工作的产品数

r(t) mdashmdash  在 0 到 t 时刻的工作时间内产品的累计

故障数

0

0 )()(

N

trNtR

累积故障分布函数 产品在规定的条件下和规定的时间内丧失

规定功能的概率称为累积故障概率(又叫不可靠度) 依定义可知产品的累积故障概率是时间的函

数即

显然以下关系成立

0

)()(

N

trtF

1)()( tFtR

可靠度函数与累积故障分布函数的性质

图 R(t)F(t)与f(t)的关系t

f(t)

f(t)

F(to)

R(to)

to

由密度函数的性质 1)(0

dttf 可知

t

tdttfdttftFtR )()(1)(1)(

0

因此 R(t) F(t) 与 f(t) 之间的关系如图所示

故障率函数 故障率

工作到某时刻尚未发生故障的产品在该时刻后单位时间内发生故障的概率称之为产品的故障率

用数学符号表示为

式中 (t) mdashmdash 故障率 dr(t) mdashmdash t 时刻后 dt 时间内故障的产品数 Ns(t) mdashmdash 残存产品数即到 t 时刻尚未故障的产品

dttN

tdrt

s )(

)()(

35

故障率函数

可按下式进行工程计算

式中 Δr(t) mdashmdash t 时刻后 Δt 时间内故障的产品数

Δt mdashmdash 所取时间间隔 Ns(t) mdashmdash 残存产品数

对于低故障率的元部件常以 10-9h 为故障率的单位称之为菲特( Fit )

ttN

trt

s

)(

)()(

产品故障浴盆曲线 浴盆曲线

大多数产品的故障率随时间的变化曲线形似浴盆称之为浴盆曲线由于产品故障机理的不同产品的故障率随时间的变化大致可以分为三个阶段

产品典型的故障率曲线

t

使用寿命

早期故障

偶然故障 耗损故障

A B规定的故障率 维修后故障率下降

(t)

3 )纠错技术( 1 )纠错码 在 1950s就开始研究最早的是可以检测和纠错的汉明码它们通过数字系统广泛地用于识别和纠正短暂或者持久的错误这些码引入冗余信息来确保一些类型的错误可以被检测和纠正比如一个单错校正 双错校正的码能用一个比特检测和纠正一个错误但是不能用两个比特纠错

( 2 )三模冗余 (triple modular

redundancy) 计算单元 C 有三个副本 C1C2和 C3三个单元接收同

样的输入一个独立单元比较每个输入的结果如果至少两个结果一致那么那个值被表决器选做正确结果如果三个结果都不相同那么就没有正确的结果

1C

2C

3C

表决错误

结果

输入

( 3 )看门狗定时器 (watchdog timer)

看门狗定时器 (watchdog timer)被广泛地用于检测系统问题如图 看门狗定时器连接到一个监视系统如果这个看门狗定时器翻转它产生一个完成信号用于标注系统的错误中断系统应该这样设计当适当运行的时候它一直在可能产生翻转信号之前复位定时器因此来自看门狗定时器的完成信号指示系统在一定程度上不合适地操作看门狗定时器用于预防不同的故障

系统看门狗定时器

完成

复位

( 4 )设计多样性 (Design diversity)

一种用于减少一些系统错误进入设计的设计方法学当一个设计需要给定模块的不同实例应该采用模块的不同实现而不是到处都用同一种模块比如一个有多个 CPU的系统可能采用不同类型的 CPU而不是到处采用同一种类型的 CPU在一个三模冗余系统产生表决结构的组件可能有不同的实现这样可以减少产生同样设计错误的机会

4 )软件可靠性ldquo在规定的条件下在规定的时间内软件不引起失效的概率rdquo

规定的条件 软件运行的软硬件环境 软件操作剖面软件运行的输入空间及其概率分布

规定的时间 日历时间 时钟时间 执行时间

激活软件 输入域 缺陷的数据

软件缺陷 软件

不可接受的结果 (软件故障) 输出域

软件故障的特点

软件与硬件可靠性的区别硬件 软件

故障机理 老化损耗 残留缺陷在一定环境下造成的软件错误

复杂性 内部逻辑较为简单 内部逻辑高度复杂这就在很大程度上决定了设计错误是导致软件故障的主要原因

唯一性 任何两个硬件不可能绝对相同

软件是唯一的软件拷贝不改变软件本身

可靠性的核心 内部元部件 设计者的思维和软件的复杂性纠错维护方法 修复或更换失效的元部件 重设计 可靠性检验标准化

已标准化且有一整套完整的理论

仍未建立更没有完整的理论体系

产品市场 已有成熟的产品市场 产品市场还很新 错误性质 一些瞬间的硬件错误可能

会被误认为是软件错误 软件错误是永恒的可重现的

影响软件可靠性的因素( 1 )运行环境 ( 剖面 )

同一软件在不同运行剖面下其可靠性行为可能极不相同 软件故障是软件缺陷在一定输入情况下被激活的结果 假设软件输入域划分为两个部分 G 和 F 运行剖面不包含 F 中

的输入则软件不会出现故障其可靠性恒为 l 反之如果运行剖面不包含 G 中的输入则每一输入情况下均出现故障如果没有容错措施则 R=0

( 2 )软件规模 随着软件规模的增大软件可靠性问题愈显突出在我们考虑软件

可靠性问题时软件一般是指中型以上软件 (4000-5000条以上语句 ) 这时可靠性问题难以对付

软件工程实践的一个侧面可以反映这一点即单元测试一般由编程人员本人进行而综合测试则需独立的测试人员

影响软件可靠性的因素( 3 )软件内部结构

结构越复杂软件复杂度越高内含缺陷数越大因而软件可靠度越低

( 4 )软件可靠性设计技术 一般是指软件设计阶段中采用的用以保证和提高软件可靠性为主要目标的软件技术

( 5 )软件可靠性测试 研究表明软件测试方法与资源投入对软件可靠性有不可忽视的影

响( 6 )软件可靠性管理

软件可靠性管理旨在系统管理软件生存期各阶段的可靠性活动使之系统化规范化一体化这样就可以避免许多人为错误以提高软件可靠性

影响软件可靠性的因素( 7 )软件开发人员能力和经验

软件开发人员 ( 包括测试人员 ) 的能力愈强经验愈丰富所犯错误便可能愈少所得软件产品质量愈高相应的可靠性也愈高

( 8 )软件开发方法 软件工程表明开发方法对软件可靠性有显著影响 与非结构化方法比较结构化方法可以明显减少软件缺陷数

( 9 )软件开发环境 研究表明程序语言软件开发环境影响软件的可靠性而软件测

试工具的优劣则影响可靠性测试结果

4 安全 (Safety)amp保密 (Security)

安全 (Safety) 是保证财产和人身受到损害可靠性是指在一定的环境条件下以及一定的时间内系统完成特定任务的可能性而有效性则是系统的长期的工作时间于其存在时间 ( 简单的定义为运行时间 +维护时间 ) 的 比例保密 (Security) 是针对危险破坏损失或非法活动而进行措施在一定层面上保密 (Security)要比安全 (Safety)宽广的多例如信息 Security家庭 Security 网络 Security 国家Security) 等

Security强调的是外在事物对特定目标的危害

Safety 是系统本身的潜在危害

四个概念的比较分析安全 (Safety)可靠性 (Reliability)有效性 (Availability)保密 (Security )安全 (Safety)高的系统 软件可靠性不

一定高可靠性和有效性并不是一码事保密 (Security )的系统 软件是安全

(Safety) 系统 软件的重要保障

可靠性安全性保密性 可靠(或可信)系统设计 (Reliable (or dependable) system design)是制造嵌入式系统所关注的甚至在面对内部或者外部问题时可靠系统设计经常假设问题是非恶意引起的

安全重要的系统设计 (Safety-critical system design)研究确保系统安全操作的方法独立于引起问题的原因

保密性 (Security)主要关注恶意攻击

Aizientis等人描述了可信性和保密性间的关系可信性和保密性由几个特性所组成

服务的可用性 (Availability) 服务的连续性 (Continuity) 来自用户和所处环境的灾难性后果的安全性 (Safety) 来自不合适系统改变的完整性 (Integrity) 通过更改和修补的可维护性 (Maintainability) 信息的机密性 (Confidentiality)

可用性完整性

可靠性安全性可维护性

机密性

可信性 保密性

5 新型攻击和对策1 )物理攻击嵌入式系统比通用计算机更容易受攻击 一个关键原因是许多嵌入式计算机对攻击者可物理访问

2 )互联网攻击一些嵌入式系统的攻击通过互联网访问变得更加容易今天许多嵌入式系统连接到互联网

3 )电池攻击 (battery attack)这种攻击试图通过耗尽电池来关闭节点

4 )服务拒绝攻击 (Denial-of-service attacks)

在通用系统中众所周知但是实时嵌入式系统可能更容易受服务质量 (quality-of-service (QoS))攻击如果网络发布实时数据那么发送过程中的一点延迟都能引起数据无效如果那些数据用来实时控制那么这些短暂延迟就能引起系统故障我们称这种危害为时间攻击因为它改变了系统的实时特性

QoS或者时间攻击之所以强大使因为它的影响不仅仅限于信息被控制系统的动态特性可决定系统的响应如果一个大型沉重快速运动的系统被控制那么时间上一个相对小的改变能引起大量的破坏

5 )网络(协议)攻击Wood和 Stankovic[Woo02]在传感器网络上确定了一些方式这些方式可在网络层次的不同层执行拒绝服务攻击如下所列

物理层 (Physical layer)mdashmdash拥塞破坏 链路层 (Link layer)mdashmdash碰撞耗尽非公平

网络和路由层 (Network and routing layer)mdashmdash丢弃和贪婪汇集方向误导黑洞认证监视冗余

传输层 (Transport layer)mdashmdash泛洪失步

6 )能量攻击Kocher等人 [Koc99]指出测量一个 CPU当前的能量供给能在很大程度上确定处理器的内部活动他们提出了两种能量攻击的方法简单能量分析 (simple power analysis)人工地跟踪检查和尝试确定程序作用的位置比如分支基于不同 CUP操作的能耗知识基于程序作用攻击者然后减少密钥的比特差分能量分析 (Differential power analysis)用相关性确定作用和密钥比特这种攻击最初目标是智能卡这种卡从外部读卡器获取能量但是这种攻击也能应用到许多嵌入式系统中

7 )反攻击 在一些时候有可能构造反破坏的嵌入式系统使电子设备难以发觉和分析延缓了攻击者芯片中有限的信息也有助阻止攻击者发现数据

6 Efficiency (效率)

ES must be efficient

bull Code-size efficient( 特别是片上系统 )

bull Run-time efficient

bull Weight efficient

bull Cost efficient

bull Energy efficient

能量有效性的重要意义

ldquoinherent power

efficiency of siliconldquo

59

低功耗设计问题 功耗问题是近几年来人们在嵌入式系统的设计中普遍关注的难点和热点它严重地制约着嵌入式系统的应用与发展

无论是在军事还是在商业贸易上的应用相当数量的嵌入式系统一般是由电池来供给电能的而且大多数嵌入式设备都有体积和质量的约束减少电能消耗不仅能延长电池的使用寿命延长用户更换电池的周期而且能带来提高系统性能与降低系统开销的好处甚至能起到保护环境的作用在便携式设备中 CPU消耗的电能越少电池的寿命就越长同时散发的热量少了所需的散热器就少了从而可减少该设备的花费和体积使产品尽快进入市场的目标

1 低功耗嵌入式应用系统是指以降低系统功耗为一个主要性能指标的嵌入式系统如计算机里的许多芯片过去用 5V供电现在用 33V 18V 并提出了绿色电器的概念

60

低功耗设备的要求1 )首先要求体积小重量轻便于携带2 )采用低功耗电路的设计方法以降低系统的功耗

它除了选用各种低功耗的器件和芯片外还在满足速度等性能指标的前提下进行降低功耗的硬件电路设计和软件设计

3 )有的系统应用在交流供电比较困难甚至无法用交流供电的场合因而各种电池(瓶)就成为其主要供电手段

4 )采用 LCD液晶显示器5 )采用 RS232C串行通信接口6 )采用微功耗高抗干扰的 CMOS集成电路

功耗产生的原因 P=UI

与功耗有关的因素

( 1 )电阻上消耗的功率( 2 )有源器件的开关转换阶段( 3 )集成电路内部和外部电容的充放电( 4 )系统的性能指标负载能力被处理信号的工作频率电路的工作频率电源的管理水平零部件的性能散热条件接口的物理性能等对系统功耗起着重要的作用

降低功耗的措施

功耗的组成动态 + 静态动态电源管理动态电压缩放低功耗硬件设计低功耗软件设计

二设计方法学概论

问题功 能 性能要求价 格 开发 周 期 等约束

设计 选择 折衷 分析比较 计算 评价

嵌入式系统

0嵌入式系统设计概述

方法 工具

设计方法论( design methodology )

设计方法论有以下三个重要理由1 )确认我们所做的每一件事情都是必须要作的

不会做无谓的白工也不会漏掉关键性的重要工作其中包含效率优化或是功能测试

2 )可以发展出计算机辅助工具或是设计经验累积汲取每一次产品发展的经验再经过量化之后可以发展出一套工具或是方法让往后的产品设计步入自动化

3 )开发团队遵循同一套方法论可以让团队成员更容易彼此沟通每个人都能在短时间内了解整体过程中将经历哪些过程需要何种支持与接收到何种结果此外也容易透过一套已经定义好的方法论彼此相互合作协调

设计目标 1 )上市时间

也就是 time-to-market 的观念2 )设计成本

许多消费性产品对于价格非常敏感所以产品厂商对于成本会斤斤计较是很合理的

3 )品质 顾客也许不需要最快最便宜的产品但是一定会要求功能质量保证不能只用一小段时间就坏掉了

传统的设计主要步骤

2 传统的设计流程方法1 )瀑布模型 (Waterfall)2 )螺旋模型 (Spiral)3 )连续改进 (Successive Refinement)4 )硬件与软件的同步设计 (SWHW Co-

deign)5 )阶层式 (Hierarchical) 设计6 )同步工程( concurrent

engineering )

瀑布模型 (Waterfall)

螺旋模型 (Spiral)

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 19: 大学计算机基础 —— 计算机科学概论

二设计的挑战 实时可信可靠保密安全

1 为什么需要可靠的嵌入式系统1 )许多市场不需要高度可靠的嵌入式计算机但是许多嵌入式计算机必须

是高度可靠的2 )许多嵌入式计算机必须是高度可靠的汽车电子航空电子医疗设备

关键通信3 )可靠性的定义如电话交换机系统每年停机少于 30秒4 )关于可靠数字系统设计的研究几十年前就有不同的体系结构和方法学

被开发用于长周期低失误率的数字系统操作那么传统的可靠计算机和可靠的计算机系统有什么不同呢

5 )可靠嵌入式计算机通常是分布式系统如汽车电子航空电子和医疗设备都是必须高度可靠的分布式嵌入式系统

6 )嵌入式计算机容易受许多新类型攻击可靠计算机传统上是物理上不可访问的服务器或者机器mdashmdash物理安全长期以来是计算机安全的安全策略但是嵌入式计算机通常在非保护环境下操作这就允许新的故障和攻击这些需要都新的保护措施

2 可靠与可信ES 必需是可靠的可信的如何评价与度量

bull可靠性( Reliability) R(t)

bull可维护性( Maintainability) M(d)

bull有效性( Availability ) A(t)

bull安全性( Safety )bull保密性( Security )

可靠性定义可靠性 R(t) 产品在规定条件下和规定时间内完成规定

功能的能力产品可靠性定义的要素是三个ldquo规定rdquo 1 )ldquo规定条件rdquo包括使用时的环境条件

和工作条件2 )ldquo规定时间rdquo是指产品规定了的任务

时间3 )ldquo规定功能rdquo是指产品规定了的必须

具备的功能及其技术指标

1 )ldquo规定条件rdquo包括使用时的环境条件和工作条件 例如同一型号的汽车在高速公路和在崎岖的山路上行驶其可

靠性的表现就不大一样要谈论产品的可靠性必须指明规定的条件是什么2 )ldquo规定时间rdquo是指产品规定了的任务时间 随着产品任务时间的增加产品出现故障的概率将增加

而产品的可靠性将是下降的因此谈论产品的可靠性离不开规定的任务时间例如一辆汽车在在刚刚开出厂子和用了5 年后相比它出故障的概率显然大了很多

3 )ldquo规定功能rdquo是指产品规定了的必须具备的功能及其技术指标所要求产品功能的多少和其技术指标的高低直接影响到产品可靠性指标的高低

例如电风扇的主要功能有转叶摇头定时那么规定的功能是三者都要还是仅需要转叶能转能够吹风所得出的可靠性指标是大不一样的

可维护性 M(d)1 )计算机系统的可维护性是指该系统失效后在规定时间内可

修复到规定功能的能力2 )反映系统可维护性高低的参数是修复率秒平均修复时间3 )软件可维护性即维护人员对该软件进行维护的难易程度

具体包括理解改正改动和改进该软件的难易程度4 )决定可维护性的因素

系统的大小系统的年龄结构合理性

5 )可维护性的度量 可理解性可测试性可修改性可移植性

有效性 A(t)设备的有效性的表式为 设备有效性 = 平均故障间隔期 (平均故障间隔期+平均修理时间)

在逻辑中如果一个论证不能从真前提中得出假结论 则论证的形式是完全有效的

一个论证若被称为是有效的则如果在其中所有前提都为真的每个模型中结论也是真的

例如ldquo所有 A 是 B 有些 A 是 C 所以有些 B 是Crdquo 是有效形式

可用性 实用性

3 可靠系统设计的基本原理1 )故障 (faults) 分析2 )可靠性分析3 )纠错技术4 )软件可靠性

1 )故障 (faults) 分析永久 (permanent) 与暂时( transient )故障故障来源 物理故障 (Physical faults)由生产缺陷辐射危害等等引起

设计故障 (Design faults) 是不合适设计的系统的结果

操作故障 (Operational faults) 来自人为过失安全破坏劣质设计的人机接口等等

可靠性设计

故障及其分类 产品的故障按其故障规律分为两大类

偶然故障 渐变故障

产品的故障按其故障后果分为两大类 致命性故障 非致命性故障

产品的故障按其统计特性分为两大类 独立故障 从属故障

可靠度 产品在规定的条件下和规定的时间内完成规

定功能的概率称为可靠度依定义可知系统的可靠度是时间的函数表示为

式中 R(t)mdashmdash 可靠度函数 ξmdashmdash 产生故障前的工作时间 t mdashmdash 规定的时间

)()( tPtR

2 )可靠性的分析mdashmdash可靠度

可靠度函数

依定义可知可靠度函数 R(t) 为

式中 N0 mdashmdash t = 0 时在规定条件下进行工作的产品数

r(t) mdashmdash  在 0 到 t 时刻的工作时间内产品的累计

故障数

0

0 )()(

N

trNtR

累积故障分布函数 产品在规定的条件下和规定的时间内丧失

规定功能的概率称为累积故障概率(又叫不可靠度) 依定义可知产品的累积故障概率是时间的函

数即

显然以下关系成立

0

)()(

N

trtF

1)()( tFtR

可靠度函数与累积故障分布函数的性质

图 R(t)F(t)与f(t)的关系t

f(t)

f(t)

F(to)

R(to)

to

由密度函数的性质 1)(0

dttf 可知

t

tdttfdttftFtR )()(1)(1)(

0

因此 R(t) F(t) 与 f(t) 之间的关系如图所示

故障率函数 故障率

工作到某时刻尚未发生故障的产品在该时刻后单位时间内发生故障的概率称之为产品的故障率

用数学符号表示为

式中 (t) mdashmdash 故障率 dr(t) mdashmdash t 时刻后 dt 时间内故障的产品数 Ns(t) mdashmdash 残存产品数即到 t 时刻尚未故障的产品

dttN

tdrt

s )(

)()(

35

故障率函数

可按下式进行工程计算

式中 Δr(t) mdashmdash t 时刻后 Δt 时间内故障的产品数

Δt mdashmdash 所取时间间隔 Ns(t) mdashmdash 残存产品数

对于低故障率的元部件常以 10-9h 为故障率的单位称之为菲特( Fit )

ttN

trt

s

)(

)()(

产品故障浴盆曲线 浴盆曲线

大多数产品的故障率随时间的变化曲线形似浴盆称之为浴盆曲线由于产品故障机理的不同产品的故障率随时间的变化大致可以分为三个阶段

产品典型的故障率曲线

t

使用寿命

早期故障

偶然故障 耗损故障

A B规定的故障率 维修后故障率下降

(t)

3 )纠错技术( 1 )纠错码 在 1950s就开始研究最早的是可以检测和纠错的汉明码它们通过数字系统广泛地用于识别和纠正短暂或者持久的错误这些码引入冗余信息来确保一些类型的错误可以被检测和纠正比如一个单错校正 双错校正的码能用一个比特检测和纠正一个错误但是不能用两个比特纠错

( 2 )三模冗余 (triple modular

redundancy) 计算单元 C 有三个副本 C1C2和 C3三个单元接收同

样的输入一个独立单元比较每个输入的结果如果至少两个结果一致那么那个值被表决器选做正确结果如果三个结果都不相同那么就没有正确的结果

1C

2C

3C

表决错误

结果

输入

( 3 )看门狗定时器 (watchdog timer)

看门狗定时器 (watchdog timer)被广泛地用于检测系统问题如图 看门狗定时器连接到一个监视系统如果这个看门狗定时器翻转它产生一个完成信号用于标注系统的错误中断系统应该这样设计当适当运行的时候它一直在可能产生翻转信号之前复位定时器因此来自看门狗定时器的完成信号指示系统在一定程度上不合适地操作看门狗定时器用于预防不同的故障

系统看门狗定时器

完成

复位

( 4 )设计多样性 (Design diversity)

一种用于减少一些系统错误进入设计的设计方法学当一个设计需要给定模块的不同实例应该采用模块的不同实现而不是到处都用同一种模块比如一个有多个 CPU的系统可能采用不同类型的 CPU而不是到处采用同一种类型的 CPU在一个三模冗余系统产生表决结构的组件可能有不同的实现这样可以减少产生同样设计错误的机会

4 )软件可靠性ldquo在规定的条件下在规定的时间内软件不引起失效的概率rdquo

规定的条件 软件运行的软硬件环境 软件操作剖面软件运行的输入空间及其概率分布

规定的时间 日历时间 时钟时间 执行时间

激活软件 输入域 缺陷的数据

软件缺陷 软件

不可接受的结果 (软件故障) 输出域

软件故障的特点

软件与硬件可靠性的区别硬件 软件

故障机理 老化损耗 残留缺陷在一定环境下造成的软件错误

复杂性 内部逻辑较为简单 内部逻辑高度复杂这就在很大程度上决定了设计错误是导致软件故障的主要原因

唯一性 任何两个硬件不可能绝对相同

软件是唯一的软件拷贝不改变软件本身

可靠性的核心 内部元部件 设计者的思维和软件的复杂性纠错维护方法 修复或更换失效的元部件 重设计 可靠性检验标准化

已标准化且有一整套完整的理论

仍未建立更没有完整的理论体系

产品市场 已有成熟的产品市场 产品市场还很新 错误性质 一些瞬间的硬件错误可能

会被误认为是软件错误 软件错误是永恒的可重现的

影响软件可靠性的因素( 1 )运行环境 ( 剖面 )

同一软件在不同运行剖面下其可靠性行为可能极不相同 软件故障是软件缺陷在一定输入情况下被激活的结果 假设软件输入域划分为两个部分 G 和 F 运行剖面不包含 F 中

的输入则软件不会出现故障其可靠性恒为 l 反之如果运行剖面不包含 G 中的输入则每一输入情况下均出现故障如果没有容错措施则 R=0

( 2 )软件规模 随着软件规模的增大软件可靠性问题愈显突出在我们考虑软件

可靠性问题时软件一般是指中型以上软件 (4000-5000条以上语句 ) 这时可靠性问题难以对付

软件工程实践的一个侧面可以反映这一点即单元测试一般由编程人员本人进行而综合测试则需独立的测试人员

影响软件可靠性的因素( 3 )软件内部结构

结构越复杂软件复杂度越高内含缺陷数越大因而软件可靠度越低

( 4 )软件可靠性设计技术 一般是指软件设计阶段中采用的用以保证和提高软件可靠性为主要目标的软件技术

( 5 )软件可靠性测试 研究表明软件测试方法与资源投入对软件可靠性有不可忽视的影

响( 6 )软件可靠性管理

软件可靠性管理旨在系统管理软件生存期各阶段的可靠性活动使之系统化规范化一体化这样就可以避免许多人为错误以提高软件可靠性

影响软件可靠性的因素( 7 )软件开发人员能力和经验

软件开发人员 ( 包括测试人员 ) 的能力愈强经验愈丰富所犯错误便可能愈少所得软件产品质量愈高相应的可靠性也愈高

( 8 )软件开发方法 软件工程表明开发方法对软件可靠性有显著影响 与非结构化方法比较结构化方法可以明显减少软件缺陷数

( 9 )软件开发环境 研究表明程序语言软件开发环境影响软件的可靠性而软件测

试工具的优劣则影响可靠性测试结果

4 安全 (Safety)amp保密 (Security)

安全 (Safety) 是保证财产和人身受到损害可靠性是指在一定的环境条件下以及一定的时间内系统完成特定任务的可能性而有效性则是系统的长期的工作时间于其存在时间 ( 简单的定义为运行时间 +维护时间 ) 的 比例保密 (Security) 是针对危险破坏损失或非法活动而进行措施在一定层面上保密 (Security)要比安全 (Safety)宽广的多例如信息 Security家庭 Security 网络 Security 国家Security) 等

Security强调的是外在事物对特定目标的危害

Safety 是系统本身的潜在危害

四个概念的比较分析安全 (Safety)可靠性 (Reliability)有效性 (Availability)保密 (Security )安全 (Safety)高的系统 软件可靠性不

一定高可靠性和有效性并不是一码事保密 (Security )的系统 软件是安全

(Safety) 系统 软件的重要保障

可靠性安全性保密性 可靠(或可信)系统设计 (Reliable (or dependable) system design)是制造嵌入式系统所关注的甚至在面对内部或者外部问题时可靠系统设计经常假设问题是非恶意引起的

安全重要的系统设计 (Safety-critical system design)研究确保系统安全操作的方法独立于引起问题的原因

保密性 (Security)主要关注恶意攻击

Aizientis等人描述了可信性和保密性间的关系可信性和保密性由几个特性所组成

服务的可用性 (Availability) 服务的连续性 (Continuity) 来自用户和所处环境的灾难性后果的安全性 (Safety) 来自不合适系统改变的完整性 (Integrity) 通过更改和修补的可维护性 (Maintainability) 信息的机密性 (Confidentiality)

可用性完整性

可靠性安全性可维护性

机密性

可信性 保密性

5 新型攻击和对策1 )物理攻击嵌入式系统比通用计算机更容易受攻击 一个关键原因是许多嵌入式计算机对攻击者可物理访问

2 )互联网攻击一些嵌入式系统的攻击通过互联网访问变得更加容易今天许多嵌入式系统连接到互联网

3 )电池攻击 (battery attack)这种攻击试图通过耗尽电池来关闭节点

4 )服务拒绝攻击 (Denial-of-service attacks)

在通用系统中众所周知但是实时嵌入式系统可能更容易受服务质量 (quality-of-service (QoS))攻击如果网络发布实时数据那么发送过程中的一点延迟都能引起数据无效如果那些数据用来实时控制那么这些短暂延迟就能引起系统故障我们称这种危害为时间攻击因为它改变了系统的实时特性

QoS或者时间攻击之所以强大使因为它的影响不仅仅限于信息被控制系统的动态特性可决定系统的响应如果一个大型沉重快速运动的系统被控制那么时间上一个相对小的改变能引起大量的破坏

5 )网络(协议)攻击Wood和 Stankovic[Woo02]在传感器网络上确定了一些方式这些方式可在网络层次的不同层执行拒绝服务攻击如下所列

物理层 (Physical layer)mdashmdash拥塞破坏 链路层 (Link layer)mdashmdash碰撞耗尽非公平

网络和路由层 (Network and routing layer)mdashmdash丢弃和贪婪汇集方向误导黑洞认证监视冗余

传输层 (Transport layer)mdashmdash泛洪失步

6 )能量攻击Kocher等人 [Koc99]指出测量一个 CPU当前的能量供给能在很大程度上确定处理器的内部活动他们提出了两种能量攻击的方法简单能量分析 (simple power analysis)人工地跟踪检查和尝试确定程序作用的位置比如分支基于不同 CUP操作的能耗知识基于程序作用攻击者然后减少密钥的比特差分能量分析 (Differential power analysis)用相关性确定作用和密钥比特这种攻击最初目标是智能卡这种卡从外部读卡器获取能量但是这种攻击也能应用到许多嵌入式系统中

7 )反攻击 在一些时候有可能构造反破坏的嵌入式系统使电子设备难以发觉和分析延缓了攻击者芯片中有限的信息也有助阻止攻击者发现数据

6 Efficiency (效率)

ES must be efficient

bull Code-size efficient( 特别是片上系统 )

bull Run-time efficient

bull Weight efficient

bull Cost efficient

bull Energy efficient

能量有效性的重要意义

ldquoinherent power

efficiency of siliconldquo

59

低功耗设计问题 功耗问题是近几年来人们在嵌入式系统的设计中普遍关注的难点和热点它严重地制约着嵌入式系统的应用与发展

无论是在军事还是在商业贸易上的应用相当数量的嵌入式系统一般是由电池来供给电能的而且大多数嵌入式设备都有体积和质量的约束减少电能消耗不仅能延长电池的使用寿命延长用户更换电池的周期而且能带来提高系统性能与降低系统开销的好处甚至能起到保护环境的作用在便携式设备中 CPU消耗的电能越少电池的寿命就越长同时散发的热量少了所需的散热器就少了从而可减少该设备的花费和体积使产品尽快进入市场的目标

1 低功耗嵌入式应用系统是指以降低系统功耗为一个主要性能指标的嵌入式系统如计算机里的许多芯片过去用 5V供电现在用 33V 18V 并提出了绿色电器的概念

60

低功耗设备的要求1 )首先要求体积小重量轻便于携带2 )采用低功耗电路的设计方法以降低系统的功耗

它除了选用各种低功耗的器件和芯片外还在满足速度等性能指标的前提下进行降低功耗的硬件电路设计和软件设计

3 )有的系统应用在交流供电比较困难甚至无法用交流供电的场合因而各种电池(瓶)就成为其主要供电手段

4 )采用 LCD液晶显示器5 )采用 RS232C串行通信接口6 )采用微功耗高抗干扰的 CMOS集成电路

功耗产生的原因 P=UI

与功耗有关的因素

( 1 )电阻上消耗的功率( 2 )有源器件的开关转换阶段( 3 )集成电路内部和外部电容的充放电( 4 )系统的性能指标负载能力被处理信号的工作频率电路的工作频率电源的管理水平零部件的性能散热条件接口的物理性能等对系统功耗起着重要的作用

降低功耗的措施

功耗的组成动态 + 静态动态电源管理动态电压缩放低功耗硬件设计低功耗软件设计

二设计方法学概论

问题功 能 性能要求价 格 开发 周 期 等约束

设计 选择 折衷 分析比较 计算 评价

嵌入式系统

0嵌入式系统设计概述

方法 工具

设计方法论( design methodology )

设计方法论有以下三个重要理由1 )确认我们所做的每一件事情都是必须要作的

不会做无谓的白工也不会漏掉关键性的重要工作其中包含效率优化或是功能测试

2 )可以发展出计算机辅助工具或是设计经验累积汲取每一次产品发展的经验再经过量化之后可以发展出一套工具或是方法让往后的产品设计步入自动化

3 )开发团队遵循同一套方法论可以让团队成员更容易彼此沟通每个人都能在短时间内了解整体过程中将经历哪些过程需要何种支持与接收到何种结果此外也容易透过一套已经定义好的方法论彼此相互合作协调

设计目标 1 )上市时间

也就是 time-to-market 的观念2 )设计成本

许多消费性产品对于价格非常敏感所以产品厂商对于成本会斤斤计较是很合理的

3 )品质 顾客也许不需要最快最便宜的产品但是一定会要求功能质量保证不能只用一小段时间就坏掉了

传统的设计主要步骤

2 传统的设计流程方法1 )瀑布模型 (Waterfall)2 )螺旋模型 (Spiral)3 )连续改进 (Successive Refinement)4 )硬件与软件的同步设计 (SWHW Co-

deign)5 )阶层式 (Hierarchical) 设计6 )同步工程( concurrent

engineering )

瀑布模型 (Waterfall)

螺旋模型 (Spiral)

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 20: 大学计算机基础 —— 计算机科学概论

1 为什么需要可靠的嵌入式系统1 )许多市场不需要高度可靠的嵌入式计算机但是许多嵌入式计算机必须

是高度可靠的2 )许多嵌入式计算机必须是高度可靠的汽车电子航空电子医疗设备

关键通信3 )可靠性的定义如电话交换机系统每年停机少于 30秒4 )关于可靠数字系统设计的研究几十年前就有不同的体系结构和方法学

被开发用于长周期低失误率的数字系统操作那么传统的可靠计算机和可靠的计算机系统有什么不同呢

5 )可靠嵌入式计算机通常是分布式系统如汽车电子航空电子和医疗设备都是必须高度可靠的分布式嵌入式系统

6 )嵌入式计算机容易受许多新类型攻击可靠计算机传统上是物理上不可访问的服务器或者机器mdashmdash物理安全长期以来是计算机安全的安全策略但是嵌入式计算机通常在非保护环境下操作这就允许新的故障和攻击这些需要都新的保护措施

2 可靠与可信ES 必需是可靠的可信的如何评价与度量

bull可靠性( Reliability) R(t)

bull可维护性( Maintainability) M(d)

bull有效性( Availability ) A(t)

bull安全性( Safety )bull保密性( Security )

可靠性定义可靠性 R(t) 产品在规定条件下和规定时间内完成规定

功能的能力产品可靠性定义的要素是三个ldquo规定rdquo 1 )ldquo规定条件rdquo包括使用时的环境条件

和工作条件2 )ldquo规定时间rdquo是指产品规定了的任务

时间3 )ldquo规定功能rdquo是指产品规定了的必须

具备的功能及其技术指标

1 )ldquo规定条件rdquo包括使用时的环境条件和工作条件 例如同一型号的汽车在高速公路和在崎岖的山路上行驶其可

靠性的表现就不大一样要谈论产品的可靠性必须指明规定的条件是什么2 )ldquo规定时间rdquo是指产品规定了的任务时间 随着产品任务时间的增加产品出现故障的概率将增加

而产品的可靠性将是下降的因此谈论产品的可靠性离不开规定的任务时间例如一辆汽车在在刚刚开出厂子和用了5 年后相比它出故障的概率显然大了很多

3 )ldquo规定功能rdquo是指产品规定了的必须具备的功能及其技术指标所要求产品功能的多少和其技术指标的高低直接影响到产品可靠性指标的高低

例如电风扇的主要功能有转叶摇头定时那么规定的功能是三者都要还是仅需要转叶能转能够吹风所得出的可靠性指标是大不一样的

可维护性 M(d)1 )计算机系统的可维护性是指该系统失效后在规定时间内可

修复到规定功能的能力2 )反映系统可维护性高低的参数是修复率秒平均修复时间3 )软件可维护性即维护人员对该软件进行维护的难易程度

具体包括理解改正改动和改进该软件的难易程度4 )决定可维护性的因素

系统的大小系统的年龄结构合理性

5 )可维护性的度量 可理解性可测试性可修改性可移植性

有效性 A(t)设备的有效性的表式为 设备有效性 = 平均故障间隔期 (平均故障间隔期+平均修理时间)

在逻辑中如果一个论证不能从真前提中得出假结论 则论证的形式是完全有效的

一个论证若被称为是有效的则如果在其中所有前提都为真的每个模型中结论也是真的

例如ldquo所有 A 是 B 有些 A 是 C 所以有些 B 是Crdquo 是有效形式

可用性 实用性

3 可靠系统设计的基本原理1 )故障 (faults) 分析2 )可靠性分析3 )纠错技术4 )软件可靠性

1 )故障 (faults) 分析永久 (permanent) 与暂时( transient )故障故障来源 物理故障 (Physical faults)由生产缺陷辐射危害等等引起

设计故障 (Design faults) 是不合适设计的系统的结果

操作故障 (Operational faults) 来自人为过失安全破坏劣质设计的人机接口等等

可靠性设计

故障及其分类 产品的故障按其故障规律分为两大类

偶然故障 渐变故障

产品的故障按其故障后果分为两大类 致命性故障 非致命性故障

产品的故障按其统计特性分为两大类 独立故障 从属故障

可靠度 产品在规定的条件下和规定的时间内完成规

定功能的概率称为可靠度依定义可知系统的可靠度是时间的函数表示为

式中 R(t)mdashmdash 可靠度函数 ξmdashmdash 产生故障前的工作时间 t mdashmdash 规定的时间

)()( tPtR

2 )可靠性的分析mdashmdash可靠度

可靠度函数

依定义可知可靠度函数 R(t) 为

式中 N0 mdashmdash t = 0 时在规定条件下进行工作的产品数

r(t) mdashmdash  在 0 到 t 时刻的工作时间内产品的累计

故障数

0

0 )()(

N

trNtR

累积故障分布函数 产品在规定的条件下和规定的时间内丧失

规定功能的概率称为累积故障概率(又叫不可靠度) 依定义可知产品的累积故障概率是时间的函

数即

显然以下关系成立

0

)()(

N

trtF

1)()( tFtR

可靠度函数与累积故障分布函数的性质

图 R(t)F(t)与f(t)的关系t

f(t)

f(t)

F(to)

R(to)

to

由密度函数的性质 1)(0

dttf 可知

t

tdttfdttftFtR )()(1)(1)(

0

因此 R(t) F(t) 与 f(t) 之间的关系如图所示

故障率函数 故障率

工作到某时刻尚未发生故障的产品在该时刻后单位时间内发生故障的概率称之为产品的故障率

用数学符号表示为

式中 (t) mdashmdash 故障率 dr(t) mdashmdash t 时刻后 dt 时间内故障的产品数 Ns(t) mdashmdash 残存产品数即到 t 时刻尚未故障的产品

dttN

tdrt

s )(

)()(

35

故障率函数

可按下式进行工程计算

式中 Δr(t) mdashmdash t 时刻后 Δt 时间内故障的产品数

Δt mdashmdash 所取时间间隔 Ns(t) mdashmdash 残存产品数

对于低故障率的元部件常以 10-9h 为故障率的单位称之为菲特( Fit )

ttN

trt

s

)(

)()(

产品故障浴盆曲线 浴盆曲线

大多数产品的故障率随时间的变化曲线形似浴盆称之为浴盆曲线由于产品故障机理的不同产品的故障率随时间的变化大致可以分为三个阶段

产品典型的故障率曲线

t

使用寿命

早期故障

偶然故障 耗损故障

A B规定的故障率 维修后故障率下降

(t)

3 )纠错技术( 1 )纠错码 在 1950s就开始研究最早的是可以检测和纠错的汉明码它们通过数字系统广泛地用于识别和纠正短暂或者持久的错误这些码引入冗余信息来确保一些类型的错误可以被检测和纠正比如一个单错校正 双错校正的码能用一个比特检测和纠正一个错误但是不能用两个比特纠错

( 2 )三模冗余 (triple modular

redundancy) 计算单元 C 有三个副本 C1C2和 C3三个单元接收同

样的输入一个独立单元比较每个输入的结果如果至少两个结果一致那么那个值被表决器选做正确结果如果三个结果都不相同那么就没有正确的结果

1C

2C

3C

表决错误

结果

输入

( 3 )看门狗定时器 (watchdog timer)

看门狗定时器 (watchdog timer)被广泛地用于检测系统问题如图 看门狗定时器连接到一个监视系统如果这个看门狗定时器翻转它产生一个完成信号用于标注系统的错误中断系统应该这样设计当适当运行的时候它一直在可能产生翻转信号之前复位定时器因此来自看门狗定时器的完成信号指示系统在一定程度上不合适地操作看门狗定时器用于预防不同的故障

系统看门狗定时器

完成

复位

( 4 )设计多样性 (Design diversity)

一种用于减少一些系统错误进入设计的设计方法学当一个设计需要给定模块的不同实例应该采用模块的不同实现而不是到处都用同一种模块比如一个有多个 CPU的系统可能采用不同类型的 CPU而不是到处采用同一种类型的 CPU在一个三模冗余系统产生表决结构的组件可能有不同的实现这样可以减少产生同样设计错误的机会

4 )软件可靠性ldquo在规定的条件下在规定的时间内软件不引起失效的概率rdquo

规定的条件 软件运行的软硬件环境 软件操作剖面软件运行的输入空间及其概率分布

规定的时间 日历时间 时钟时间 执行时间

激活软件 输入域 缺陷的数据

软件缺陷 软件

不可接受的结果 (软件故障) 输出域

软件故障的特点

软件与硬件可靠性的区别硬件 软件

故障机理 老化损耗 残留缺陷在一定环境下造成的软件错误

复杂性 内部逻辑较为简单 内部逻辑高度复杂这就在很大程度上决定了设计错误是导致软件故障的主要原因

唯一性 任何两个硬件不可能绝对相同

软件是唯一的软件拷贝不改变软件本身

可靠性的核心 内部元部件 设计者的思维和软件的复杂性纠错维护方法 修复或更换失效的元部件 重设计 可靠性检验标准化

已标准化且有一整套完整的理论

仍未建立更没有完整的理论体系

产品市场 已有成熟的产品市场 产品市场还很新 错误性质 一些瞬间的硬件错误可能

会被误认为是软件错误 软件错误是永恒的可重现的

影响软件可靠性的因素( 1 )运行环境 ( 剖面 )

同一软件在不同运行剖面下其可靠性行为可能极不相同 软件故障是软件缺陷在一定输入情况下被激活的结果 假设软件输入域划分为两个部分 G 和 F 运行剖面不包含 F 中

的输入则软件不会出现故障其可靠性恒为 l 反之如果运行剖面不包含 G 中的输入则每一输入情况下均出现故障如果没有容错措施则 R=0

( 2 )软件规模 随着软件规模的增大软件可靠性问题愈显突出在我们考虑软件

可靠性问题时软件一般是指中型以上软件 (4000-5000条以上语句 ) 这时可靠性问题难以对付

软件工程实践的一个侧面可以反映这一点即单元测试一般由编程人员本人进行而综合测试则需独立的测试人员

影响软件可靠性的因素( 3 )软件内部结构

结构越复杂软件复杂度越高内含缺陷数越大因而软件可靠度越低

( 4 )软件可靠性设计技术 一般是指软件设计阶段中采用的用以保证和提高软件可靠性为主要目标的软件技术

( 5 )软件可靠性测试 研究表明软件测试方法与资源投入对软件可靠性有不可忽视的影

响( 6 )软件可靠性管理

软件可靠性管理旨在系统管理软件生存期各阶段的可靠性活动使之系统化规范化一体化这样就可以避免许多人为错误以提高软件可靠性

影响软件可靠性的因素( 7 )软件开发人员能力和经验

软件开发人员 ( 包括测试人员 ) 的能力愈强经验愈丰富所犯错误便可能愈少所得软件产品质量愈高相应的可靠性也愈高

( 8 )软件开发方法 软件工程表明开发方法对软件可靠性有显著影响 与非结构化方法比较结构化方法可以明显减少软件缺陷数

( 9 )软件开发环境 研究表明程序语言软件开发环境影响软件的可靠性而软件测

试工具的优劣则影响可靠性测试结果

4 安全 (Safety)amp保密 (Security)

安全 (Safety) 是保证财产和人身受到损害可靠性是指在一定的环境条件下以及一定的时间内系统完成特定任务的可能性而有效性则是系统的长期的工作时间于其存在时间 ( 简单的定义为运行时间 +维护时间 ) 的 比例保密 (Security) 是针对危险破坏损失或非法活动而进行措施在一定层面上保密 (Security)要比安全 (Safety)宽广的多例如信息 Security家庭 Security 网络 Security 国家Security) 等

Security强调的是外在事物对特定目标的危害

Safety 是系统本身的潜在危害

四个概念的比较分析安全 (Safety)可靠性 (Reliability)有效性 (Availability)保密 (Security )安全 (Safety)高的系统 软件可靠性不

一定高可靠性和有效性并不是一码事保密 (Security )的系统 软件是安全

(Safety) 系统 软件的重要保障

可靠性安全性保密性 可靠(或可信)系统设计 (Reliable (or dependable) system design)是制造嵌入式系统所关注的甚至在面对内部或者外部问题时可靠系统设计经常假设问题是非恶意引起的

安全重要的系统设计 (Safety-critical system design)研究确保系统安全操作的方法独立于引起问题的原因

保密性 (Security)主要关注恶意攻击

Aizientis等人描述了可信性和保密性间的关系可信性和保密性由几个特性所组成

服务的可用性 (Availability) 服务的连续性 (Continuity) 来自用户和所处环境的灾难性后果的安全性 (Safety) 来自不合适系统改变的完整性 (Integrity) 通过更改和修补的可维护性 (Maintainability) 信息的机密性 (Confidentiality)

可用性完整性

可靠性安全性可维护性

机密性

可信性 保密性

5 新型攻击和对策1 )物理攻击嵌入式系统比通用计算机更容易受攻击 一个关键原因是许多嵌入式计算机对攻击者可物理访问

2 )互联网攻击一些嵌入式系统的攻击通过互联网访问变得更加容易今天许多嵌入式系统连接到互联网

3 )电池攻击 (battery attack)这种攻击试图通过耗尽电池来关闭节点

4 )服务拒绝攻击 (Denial-of-service attacks)

在通用系统中众所周知但是实时嵌入式系统可能更容易受服务质量 (quality-of-service (QoS))攻击如果网络发布实时数据那么发送过程中的一点延迟都能引起数据无效如果那些数据用来实时控制那么这些短暂延迟就能引起系统故障我们称这种危害为时间攻击因为它改变了系统的实时特性

QoS或者时间攻击之所以强大使因为它的影响不仅仅限于信息被控制系统的动态特性可决定系统的响应如果一个大型沉重快速运动的系统被控制那么时间上一个相对小的改变能引起大量的破坏

5 )网络(协议)攻击Wood和 Stankovic[Woo02]在传感器网络上确定了一些方式这些方式可在网络层次的不同层执行拒绝服务攻击如下所列

物理层 (Physical layer)mdashmdash拥塞破坏 链路层 (Link layer)mdashmdash碰撞耗尽非公平

网络和路由层 (Network and routing layer)mdashmdash丢弃和贪婪汇集方向误导黑洞认证监视冗余

传输层 (Transport layer)mdashmdash泛洪失步

6 )能量攻击Kocher等人 [Koc99]指出测量一个 CPU当前的能量供给能在很大程度上确定处理器的内部活动他们提出了两种能量攻击的方法简单能量分析 (simple power analysis)人工地跟踪检查和尝试确定程序作用的位置比如分支基于不同 CUP操作的能耗知识基于程序作用攻击者然后减少密钥的比特差分能量分析 (Differential power analysis)用相关性确定作用和密钥比特这种攻击最初目标是智能卡这种卡从外部读卡器获取能量但是这种攻击也能应用到许多嵌入式系统中

7 )反攻击 在一些时候有可能构造反破坏的嵌入式系统使电子设备难以发觉和分析延缓了攻击者芯片中有限的信息也有助阻止攻击者发现数据

6 Efficiency (效率)

ES must be efficient

bull Code-size efficient( 特别是片上系统 )

bull Run-time efficient

bull Weight efficient

bull Cost efficient

bull Energy efficient

能量有效性的重要意义

ldquoinherent power

efficiency of siliconldquo

59

低功耗设计问题 功耗问题是近几年来人们在嵌入式系统的设计中普遍关注的难点和热点它严重地制约着嵌入式系统的应用与发展

无论是在军事还是在商业贸易上的应用相当数量的嵌入式系统一般是由电池来供给电能的而且大多数嵌入式设备都有体积和质量的约束减少电能消耗不仅能延长电池的使用寿命延长用户更换电池的周期而且能带来提高系统性能与降低系统开销的好处甚至能起到保护环境的作用在便携式设备中 CPU消耗的电能越少电池的寿命就越长同时散发的热量少了所需的散热器就少了从而可减少该设备的花费和体积使产品尽快进入市场的目标

1 低功耗嵌入式应用系统是指以降低系统功耗为一个主要性能指标的嵌入式系统如计算机里的许多芯片过去用 5V供电现在用 33V 18V 并提出了绿色电器的概念

60

低功耗设备的要求1 )首先要求体积小重量轻便于携带2 )采用低功耗电路的设计方法以降低系统的功耗

它除了选用各种低功耗的器件和芯片外还在满足速度等性能指标的前提下进行降低功耗的硬件电路设计和软件设计

3 )有的系统应用在交流供电比较困难甚至无法用交流供电的场合因而各种电池(瓶)就成为其主要供电手段

4 )采用 LCD液晶显示器5 )采用 RS232C串行通信接口6 )采用微功耗高抗干扰的 CMOS集成电路

功耗产生的原因 P=UI

与功耗有关的因素

( 1 )电阻上消耗的功率( 2 )有源器件的开关转换阶段( 3 )集成电路内部和外部电容的充放电( 4 )系统的性能指标负载能力被处理信号的工作频率电路的工作频率电源的管理水平零部件的性能散热条件接口的物理性能等对系统功耗起着重要的作用

降低功耗的措施

功耗的组成动态 + 静态动态电源管理动态电压缩放低功耗硬件设计低功耗软件设计

二设计方法学概论

问题功 能 性能要求价 格 开发 周 期 等约束

设计 选择 折衷 分析比较 计算 评价

嵌入式系统

0嵌入式系统设计概述

方法 工具

设计方法论( design methodology )

设计方法论有以下三个重要理由1 )确认我们所做的每一件事情都是必须要作的

不会做无谓的白工也不会漏掉关键性的重要工作其中包含效率优化或是功能测试

2 )可以发展出计算机辅助工具或是设计经验累积汲取每一次产品发展的经验再经过量化之后可以发展出一套工具或是方法让往后的产品设计步入自动化

3 )开发团队遵循同一套方法论可以让团队成员更容易彼此沟通每个人都能在短时间内了解整体过程中将经历哪些过程需要何种支持与接收到何种结果此外也容易透过一套已经定义好的方法论彼此相互合作协调

设计目标 1 )上市时间

也就是 time-to-market 的观念2 )设计成本

许多消费性产品对于价格非常敏感所以产品厂商对于成本会斤斤计较是很合理的

3 )品质 顾客也许不需要最快最便宜的产品但是一定会要求功能质量保证不能只用一小段时间就坏掉了

传统的设计主要步骤

2 传统的设计流程方法1 )瀑布模型 (Waterfall)2 )螺旋模型 (Spiral)3 )连续改进 (Successive Refinement)4 )硬件与软件的同步设计 (SWHW Co-

deign)5 )阶层式 (Hierarchical) 设计6 )同步工程( concurrent

engineering )

瀑布模型 (Waterfall)

螺旋模型 (Spiral)

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 21: 大学计算机基础 —— 计算机科学概论

2 可靠与可信ES 必需是可靠的可信的如何评价与度量

bull可靠性( Reliability) R(t)

bull可维护性( Maintainability) M(d)

bull有效性( Availability ) A(t)

bull安全性( Safety )bull保密性( Security )

可靠性定义可靠性 R(t) 产品在规定条件下和规定时间内完成规定

功能的能力产品可靠性定义的要素是三个ldquo规定rdquo 1 )ldquo规定条件rdquo包括使用时的环境条件

和工作条件2 )ldquo规定时间rdquo是指产品规定了的任务

时间3 )ldquo规定功能rdquo是指产品规定了的必须

具备的功能及其技术指标

1 )ldquo规定条件rdquo包括使用时的环境条件和工作条件 例如同一型号的汽车在高速公路和在崎岖的山路上行驶其可

靠性的表现就不大一样要谈论产品的可靠性必须指明规定的条件是什么2 )ldquo规定时间rdquo是指产品规定了的任务时间 随着产品任务时间的增加产品出现故障的概率将增加

而产品的可靠性将是下降的因此谈论产品的可靠性离不开规定的任务时间例如一辆汽车在在刚刚开出厂子和用了5 年后相比它出故障的概率显然大了很多

3 )ldquo规定功能rdquo是指产品规定了的必须具备的功能及其技术指标所要求产品功能的多少和其技术指标的高低直接影响到产品可靠性指标的高低

例如电风扇的主要功能有转叶摇头定时那么规定的功能是三者都要还是仅需要转叶能转能够吹风所得出的可靠性指标是大不一样的

可维护性 M(d)1 )计算机系统的可维护性是指该系统失效后在规定时间内可

修复到规定功能的能力2 )反映系统可维护性高低的参数是修复率秒平均修复时间3 )软件可维护性即维护人员对该软件进行维护的难易程度

具体包括理解改正改动和改进该软件的难易程度4 )决定可维护性的因素

系统的大小系统的年龄结构合理性

5 )可维护性的度量 可理解性可测试性可修改性可移植性

有效性 A(t)设备的有效性的表式为 设备有效性 = 平均故障间隔期 (平均故障间隔期+平均修理时间)

在逻辑中如果一个论证不能从真前提中得出假结论 则论证的形式是完全有效的

一个论证若被称为是有效的则如果在其中所有前提都为真的每个模型中结论也是真的

例如ldquo所有 A 是 B 有些 A 是 C 所以有些 B 是Crdquo 是有效形式

可用性 实用性

3 可靠系统设计的基本原理1 )故障 (faults) 分析2 )可靠性分析3 )纠错技术4 )软件可靠性

1 )故障 (faults) 分析永久 (permanent) 与暂时( transient )故障故障来源 物理故障 (Physical faults)由生产缺陷辐射危害等等引起

设计故障 (Design faults) 是不合适设计的系统的结果

操作故障 (Operational faults) 来自人为过失安全破坏劣质设计的人机接口等等

可靠性设计

故障及其分类 产品的故障按其故障规律分为两大类

偶然故障 渐变故障

产品的故障按其故障后果分为两大类 致命性故障 非致命性故障

产品的故障按其统计特性分为两大类 独立故障 从属故障

可靠度 产品在规定的条件下和规定的时间内完成规

定功能的概率称为可靠度依定义可知系统的可靠度是时间的函数表示为

式中 R(t)mdashmdash 可靠度函数 ξmdashmdash 产生故障前的工作时间 t mdashmdash 规定的时间

)()( tPtR

2 )可靠性的分析mdashmdash可靠度

可靠度函数

依定义可知可靠度函数 R(t) 为

式中 N0 mdashmdash t = 0 时在规定条件下进行工作的产品数

r(t) mdashmdash  在 0 到 t 时刻的工作时间内产品的累计

故障数

0

0 )()(

N

trNtR

累积故障分布函数 产品在规定的条件下和规定的时间内丧失

规定功能的概率称为累积故障概率(又叫不可靠度) 依定义可知产品的累积故障概率是时间的函

数即

显然以下关系成立

0

)()(

N

trtF

1)()( tFtR

可靠度函数与累积故障分布函数的性质

图 R(t)F(t)与f(t)的关系t

f(t)

f(t)

F(to)

R(to)

to

由密度函数的性质 1)(0

dttf 可知

t

tdttfdttftFtR )()(1)(1)(

0

因此 R(t) F(t) 与 f(t) 之间的关系如图所示

故障率函数 故障率

工作到某时刻尚未发生故障的产品在该时刻后单位时间内发生故障的概率称之为产品的故障率

用数学符号表示为

式中 (t) mdashmdash 故障率 dr(t) mdashmdash t 时刻后 dt 时间内故障的产品数 Ns(t) mdashmdash 残存产品数即到 t 时刻尚未故障的产品

dttN

tdrt

s )(

)()(

35

故障率函数

可按下式进行工程计算

式中 Δr(t) mdashmdash t 时刻后 Δt 时间内故障的产品数

Δt mdashmdash 所取时间间隔 Ns(t) mdashmdash 残存产品数

对于低故障率的元部件常以 10-9h 为故障率的单位称之为菲特( Fit )

ttN

trt

s

)(

)()(

产品故障浴盆曲线 浴盆曲线

大多数产品的故障率随时间的变化曲线形似浴盆称之为浴盆曲线由于产品故障机理的不同产品的故障率随时间的变化大致可以分为三个阶段

产品典型的故障率曲线

t

使用寿命

早期故障

偶然故障 耗损故障

A B规定的故障率 维修后故障率下降

(t)

3 )纠错技术( 1 )纠错码 在 1950s就开始研究最早的是可以检测和纠错的汉明码它们通过数字系统广泛地用于识别和纠正短暂或者持久的错误这些码引入冗余信息来确保一些类型的错误可以被检测和纠正比如一个单错校正 双错校正的码能用一个比特检测和纠正一个错误但是不能用两个比特纠错

( 2 )三模冗余 (triple modular

redundancy) 计算单元 C 有三个副本 C1C2和 C3三个单元接收同

样的输入一个独立单元比较每个输入的结果如果至少两个结果一致那么那个值被表决器选做正确结果如果三个结果都不相同那么就没有正确的结果

1C

2C

3C

表决错误

结果

输入

( 3 )看门狗定时器 (watchdog timer)

看门狗定时器 (watchdog timer)被广泛地用于检测系统问题如图 看门狗定时器连接到一个监视系统如果这个看门狗定时器翻转它产生一个完成信号用于标注系统的错误中断系统应该这样设计当适当运行的时候它一直在可能产生翻转信号之前复位定时器因此来自看门狗定时器的完成信号指示系统在一定程度上不合适地操作看门狗定时器用于预防不同的故障

系统看门狗定时器

完成

复位

( 4 )设计多样性 (Design diversity)

一种用于减少一些系统错误进入设计的设计方法学当一个设计需要给定模块的不同实例应该采用模块的不同实现而不是到处都用同一种模块比如一个有多个 CPU的系统可能采用不同类型的 CPU而不是到处采用同一种类型的 CPU在一个三模冗余系统产生表决结构的组件可能有不同的实现这样可以减少产生同样设计错误的机会

4 )软件可靠性ldquo在规定的条件下在规定的时间内软件不引起失效的概率rdquo

规定的条件 软件运行的软硬件环境 软件操作剖面软件运行的输入空间及其概率分布

规定的时间 日历时间 时钟时间 执行时间

激活软件 输入域 缺陷的数据

软件缺陷 软件

不可接受的结果 (软件故障) 输出域

软件故障的特点

软件与硬件可靠性的区别硬件 软件

故障机理 老化损耗 残留缺陷在一定环境下造成的软件错误

复杂性 内部逻辑较为简单 内部逻辑高度复杂这就在很大程度上决定了设计错误是导致软件故障的主要原因

唯一性 任何两个硬件不可能绝对相同

软件是唯一的软件拷贝不改变软件本身

可靠性的核心 内部元部件 设计者的思维和软件的复杂性纠错维护方法 修复或更换失效的元部件 重设计 可靠性检验标准化

已标准化且有一整套完整的理论

仍未建立更没有完整的理论体系

产品市场 已有成熟的产品市场 产品市场还很新 错误性质 一些瞬间的硬件错误可能

会被误认为是软件错误 软件错误是永恒的可重现的

影响软件可靠性的因素( 1 )运行环境 ( 剖面 )

同一软件在不同运行剖面下其可靠性行为可能极不相同 软件故障是软件缺陷在一定输入情况下被激活的结果 假设软件输入域划分为两个部分 G 和 F 运行剖面不包含 F 中

的输入则软件不会出现故障其可靠性恒为 l 反之如果运行剖面不包含 G 中的输入则每一输入情况下均出现故障如果没有容错措施则 R=0

( 2 )软件规模 随着软件规模的增大软件可靠性问题愈显突出在我们考虑软件

可靠性问题时软件一般是指中型以上软件 (4000-5000条以上语句 ) 这时可靠性问题难以对付

软件工程实践的一个侧面可以反映这一点即单元测试一般由编程人员本人进行而综合测试则需独立的测试人员

影响软件可靠性的因素( 3 )软件内部结构

结构越复杂软件复杂度越高内含缺陷数越大因而软件可靠度越低

( 4 )软件可靠性设计技术 一般是指软件设计阶段中采用的用以保证和提高软件可靠性为主要目标的软件技术

( 5 )软件可靠性测试 研究表明软件测试方法与资源投入对软件可靠性有不可忽视的影

响( 6 )软件可靠性管理

软件可靠性管理旨在系统管理软件生存期各阶段的可靠性活动使之系统化规范化一体化这样就可以避免许多人为错误以提高软件可靠性

影响软件可靠性的因素( 7 )软件开发人员能力和经验

软件开发人员 ( 包括测试人员 ) 的能力愈强经验愈丰富所犯错误便可能愈少所得软件产品质量愈高相应的可靠性也愈高

( 8 )软件开发方法 软件工程表明开发方法对软件可靠性有显著影响 与非结构化方法比较结构化方法可以明显减少软件缺陷数

( 9 )软件开发环境 研究表明程序语言软件开发环境影响软件的可靠性而软件测

试工具的优劣则影响可靠性测试结果

4 安全 (Safety)amp保密 (Security)

安全 (Safety) 是保证财产和人身受到损害可靠性是指在一定的环境条件下以及一定的时间内系统完成特定任务的可能性而有效性则是系统的长期的工作时间于其存在时间 ( 简单的定义为运行时间 +维护时间 ) 的 比例保密 (Security) 是针对危险破坏损失或非法活动而进行措施在一定层面上保密 (Security)要比安全 (Safety)宽广的多例如信息 Security家庭 Security 网络 Security 国家Security) 等

Security强调的是外在事物对特定目标的危害

Safety 是系统本身的潜在危害

四个概念的比较分析安全 (Safety)可靠性 (Reliability)有效性 (Availability)保密 (Security )安全 (Safety)高的系统 软件可靠性不

一定高可靠性和有效性并不是一码事保密 (Security )的系统 软件是安全

(Safety) 系统 软件的重要保障

可靠性安全性保密性 可靠(或可信)系统设计 (Reliable (or dependable) system design)是制造嵌入式系统所关注的甚至在面对内部或者外部问题时可靠系统设计经常假设问题是非恶意引起的

安全重要的系统设计 (Safety-critical system design)研究确保系统安全操作的方法独立于引起问题的原因

保密性 (Security)主要关注恶意攻击

Aizientis等人描述了可信性和保密性间的关系可信性和保密性由几个特性所组成

服务的可用性 (Availability) 服务的连续性 (Continuity) 来自用户和所处环境的灾难性后果的安全性 (Safety) 来自不合适系统改变的完整性 (Integrity) 通过更改和修补的可维护性 (Maintainability) 信息的机密性 (Confidentiality)

可用性完整性

可靠性安全性可维护性

机密性

可信性 保密性

5 新型攻击和对策1 )物理攻击嵌入式系统比通用计算机更容易受攻击 一个关键原因是许多嵌入式计算机对攻击者可物理访问

2 )互联网攻击一些嵌入式系统的攻击通过互联网访问变得更加容易今天许多嵌入式系统连接到互联网

3 )电池攻击 (battery attack)这种攻击试图通过耗尽电池来关闭节点

4 )服务拒绝攻击 (Denial-of-service attacks)

在通用系统中众所周知但是实时嵌入式系统可能更容易受服务质量 (quality-of-service (QoS))攻击如果网络发布实时数据那么发送过程中的一点延迟都能引起数据无效如果那些数据用来实时控制那么这些短暂延迟就能引起系统故障我们称这种危害为时间攻击因为它改变了系统的实时特性

QoS或者时间攻击之所以强大使因为它的影响不仅仅限于信息被控制系统的动态特性可决定系统的响应如果一个大型沉重快速运动的系统被控制那么时间上一个相对小的改变能引起大量的破坏

5 )网络(协议)攻击Wood和 Stankovic[Woo02]在传感器网络上确定了一些方式这些方式可在网络层次的不同层执行拒绝服务攻击如下所列

物理层 (Physical layer)mdashmdash拥塞破坏 链路层 (Link layer)mdashmdash碰撞耗尽非公平

网络和路由层 (Network and routing layer)mdashmdash丢弃和贪婪汇集方向误导黑洞认证监视冗余

传输层 (Transport layer)mdashmdash泛洪失步

6 )能量攻击Kocher等人 [Koc99]指出测量一个 CPU当前的能量供给能在很大程度上确定处理器的内部活动他们提出了两种能量攻击的方法简单能量分析 (simple power analysis)人工地跟踪检查和尝试确定程序作用的位置比如分支基于不同 CUP操作的能耗知识基于程序作用攻击者然后减少密钥的比特差分能量分析 (Differential power analysis)用相关性确定作用和密钥比特这种攻击最初目标是智能卡这种卡从外部读卡器获取能量但是这种攻击也能应用到许多嵌入式系统中

7 )反攻击 在一些时候有可能构造反破坏的嵌入式系统使电子设备难以发觉和分析延缓了攻击者芯片中有限的信息也有助阻止攻击者发现数据

6 Efficiency (效率)

ES must be efficient

bull Code-size efficient( 特别是片上系统 )

bull Run-time efficient

bull Weight efficient

bull Cost efficient

bull Energy efficient

能量有效性的重要意义

ldquoinherent power

efficiency of siliconldquo

59

低功耗设计问题 功耗问题是近几年来人们在嵌入式系统的设计中普遍关注的难点和热点它严重地制约着嵌入式系统的应用与发展

无论是在军事还是在商业贸易上的应用相当数量的嵌入式系统一般是由电池来供给电能的而且大多数嵌入式设备都有体积和质量的约束减少电能消耗不仅能延长电池的使用寿命延长用户更换电池的周期而且能带来提高系统性能与降低系统开销的好处甚至能起到保护环境的作用在便携式设备中 CPU消耗的电能越少电池的寿命就越长同时散发的热量少了所需的散热器就少了从而可减少该设备的花费和体积使产品尽快进入市场的目标

1 低功耗嵌入式应用系统是指以降低系统功耗为一个主要性能指标的嵌入式系统如计算机里的许多芯片过去用 5V供电现在用 33V 18V 并提出了绿色电器的概念

60

低功耗设备的要求1 )首先要求体积小重量轻便于携带2 )采用低功耗电路的设计方法以降低系统的功耗

它除了选用各种低功耗的器件和芯片外还在满足速度等性能指标的前提下进行降低功耗的硬件电路设计和软件设计

3 )有的系统应用在交流供电比较困难甚至无法用交流供电的场合因而各种电池(瓶)就成为其主要供电手段

4 )采用 LCD液晶显示器5 )采用 RS232C串行通信接口6 )采用微功耗高抗干扰的 CMOS集成电路

功耗产生的原因 P=UI

与功耗有关的因素

( 1 )电阻上消耗的功率( 2 )有源器件的开关转换阶段( 3 )集成电路内部和外部电容的充放电( 4 )系统的性能指标负载能力被处理信号的工作频率电路的工作频率电源的管理水平零部件的性能散热条件接口的物理性能等对系统功耗起着重要的作用

降低功耗的措施

功耗的组成动态 + 静态动态电源管理动态电压缩放低功耗硬件设计低功耗软件设计

二设计方法学概论

问题功 能 性能要求价 格 开发 周 期 等约束

设计 选择 折衷 分析比较 计算 评价

嵌入式系统

0嵌入式系统设计概述

方法 工具

设计方法论( design methodology )

设计方法论有以下三个重要理由1 )确认我们所做的每一件事情都是必须要作的

不会做无谓的白工也不会漏掉关键性的重要工作其中包含效率优化或是功能测试

2 )可以发展出计算机辅助工具或是设计经验累积汲取每一次产品发展的经验再经过量化之后可以发展出一套工具或是方法让往后的产品设计步入自动化

3 )开发团队遵循同一套方法论可以让团队成员更容易彼此沟通每个人都能在短时间内了解整体过程中将经历哪些过程需要何种支持与接收到何种结果此外也容易透过一套已经定义好的方法论彼此相互合作协调

设计目标 1 )上市时间

也就是 time-to-market 的观念2 )设计成本

许多消费性产品对于价格非常敏感所以产品厂商对于成本会斤斤计较是很合理的

3 )品质 顾客也许不需要最快最便宜的产品但是一定会要求功能质量保证不能只用一小段时间就坏掉了

传统的设计主要步骤

2 传统的设计流程方法1 )瀑布模型 (Waterfall)2 )螺旋模型 (Spiral)3 )连续改进 (Successive Refinement)4 )硬件与软件的同步设计 (SWHW Co-

deign)5 )阶层式 (Hierarchical) 设计6 )同步工程( concurrent

engineering )

瀑布模型 (Waterfall)

螺旋模型 (Spiral)

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 22: 大学计算机基础 —— 计算机科学概论

可靠性定义可靠性 R(t) 产品在规定条件下和规定时间内完成规定

功能的能力产品可靠性定义的要素是三个ldquo规定rdquo 1 )ldquo规定条件rdquo包括使用时的环境条件

和工作条件2 )ldquo规定时间rdquo是指产品规定了的任务

时间3 )ldquo规定功能rdquo是指产品规定了的必须

具备的功能及其技术指标

1 )ldquo规定条件rdquo包括使用时的环境条件和工作条件 例如同一型号的汽车在高速公路和在崎岖的山路上行驶其可

靠性的表现就不大一样要谈论产品的可靠性必须指明规定的条件是什么2 )ldquo规定时间rdquo是指产品规定了的任务时间 随着产品任务时间的增加产品出现故障的概率将增加

而产品的可靠性将是下降的因此谈论产品的可靠性离不开规定的任务时间例如一辆汽车在在刚刚开出厂子和用了5 年后相比它出故障的概率显然大了很多

3 )ldquo规定功能rdquo是指产品规定了的必须具备的功能及其技术指标所要求产品功能的多少和其技术指标的高低直接影响到产品可靠性指标的高低

例如电风扇的主要功能有转叶摇头定时那么规定的功能是三者都要还是仅需要转叶能转能够吹风所得出的可靠性指标是大不一样的

可维护性 M(d)1 )计算机系统的可维护性是指该系统失效后在规定时间内可

修复到规定功能的能力2 )反映系统可维护性高低的参数是修复率秒平均修复时间3 )软件可维护性即维护人员对该软件进行维护的难易程度

具体包括理解改正改动和改进该软件的难易程度4 )决定可维护性的因素

系统的大小系统的年龄结构合理性

5 )可维护性的度量 可理解性可测试性可修改性可移植性

有效性 A(t)设备的有效性的表式为 设备有效性 = 平均故障间隔期 (平均故障间隔期+平均修理时间)

在逻辑中如果一个论证不能从真前提中得出假结论 则论证的形式是完全有效的

一个论证若被称为是有效的则如果在其中所有前提都为真的每个模型中结论也是真的

例如ldquo所有 A 是 B 有些 A 是 C 所以有些 B 是Crdquo 是有效形式

可用性 实用性

3 可靠系统设计的基本原理1 )故障 (faults) 分析2 )可靠性分析3 )纠错技术4 )软件可靠性

1 )故障 (faults) 分析永久 (permanent) 与暂时( transient )故障故障来源 物理故障 (Physical faults)由生产缺陷辐射危害等等引起

设计故障 (Design faults) 是不合适设计的系统的结果

操作故障 (Operational faults) 来自人为过失安全破坏劣质设计的人机接口等等

可靠性设计

故障及其分类 产品的故障按其故障规律分为两大类

偶然故障 渐变故障

产品的故障按其故障后果分为两大类 致命性故障 非致命性故障

产品的故障按其统计特性分为两大类 独立故障 从属故障

可靠度 产品在规定的条件下和规定的时间内完成规

定功能的概率称为可靠度依定义可知系统的可靠度是时间的函数表示为

式中 R(t)mdashmdash 可靠度函数 ξmdashmdash 产生故障前的工作时间 t mdashmdash 规定的时间

)()( tPtR

2 )可靠性的分析mdashmdash可靠度

可靠度函数

依定义可知可靠度函数 R(t) 为

式中 N0 mdashmdash t = 0 时在规定条件下进行工作的产品数

r(t) mdashmdash  在 0 到 t 时刻的工作时间内产品的累计

故障数

0

0 )()(

N

trNtR

累积故障分布函数 产品在规定的条件下和规定的时间内丧失

规定功能的概率称为累积故障概率(又叫不可靠度) 依定义可知产品的累积故障概率是时间的函

数即

显然以下关系成立

0

)()(

N

trtF

1)()( tFtR

可靠度函数与累积故障分布函数的性质

图 R(t)F(t)与f(t)的关系t

f(t)

f(t)

F(to)

R(to)

to

由密度函数的性质 1)(0

dttf 可知

t

tdttfdttftFtR )()(1)(1)(

0

因此 R(t) F(t) 与 f(t) 之间的关系如图所示

故障率函数 故障率

工作到某时刻尚未发生故障的产品在该时刻后单位时间内发生故障的概率称之为产品的故障率

用数学符号表示为

式中 (t) mdashmdash 故障率 dr(t) mdashmdash t 时刻后 dt 时间内故障的产品数 Ns(t) mdashmdash 残存产品数即到 t 时刻尚未故障的产品

dttN

tdrt

s )(

)()(

35

故障率函数

可按下式进行工程计算

式中 Δr(t) mdashmdash t 时刻后 Δt 时间内故障的产品数

Δt mdashmdash 所取时间间隔 Ns(t) mdashmdash 残存产品数

对于低故障率的元部件常以 10-9h 为故障率的单位称之为菲特( Fit )

ttN

trt

s

)(

)()(

产品故障浴盆曲线 浴盆曲线

大多数产品的故障率随时间的变化曲线形似浴盆称之为浴盆曲线由于产品故障机理的不同产品的故障率随时间的变化大致可以分为三个阶段

产品典型的故障率曲线

t

使用寿命

早期故障

偶然故障 耗损故障

A B规定的故障率 维修后故障率下降

(t)

3 )纠错技术( 1 )纠错码 在 1950s就开始研究最早的是可以检测和纠错的汉明码它们通过数字系统广泛地用于识别和纠正短暂或者持久的错误这些码引入冗余信息来确保一些类型的错误可以被检测和纠正比如一个单错校正 双错校正的码能用一个比特检测和纠正一个错误但是不能用两个比特纠错

( 2 )三模冗余 (triple modular

redundancy) 计算单元 C 有三个副本 C1C2和 C3三个单元接收同

样的输入一个独立单元比较每个输入的结果如果至少两个结果一致那么那个值被表决器选做正确结果如果三个结果都不相同那么就没有正确的结果

1C

2C

3C

表决错误

结果

输入

( 3 )看门狗定时器 (watchdog timer)

看门狗定时器 (watchdog timer)被广泛地用于检测系统问题如图 看门狗定时器连接到一个监视系统如果这个看门狗定时器翻转它产生一个完成信号用于标注系统的错误中断系统应该这样设计当适当运行的时候它一直在可能产生翻转信号之前复位定时器因此来自看门狗定时器的完成信号指示系统在一定程度上不合适地操作看门狗定时器用于预防不同的故障

系统看门狗定时器

完成

复位

( 4 )设计多样性 (Design diversity)

一种用于减少一些系统错误进入设计的设计方法学当一个设计需要给定模块的不同实例应该采用模块的不同实现而不是到处都用同一种模块比如一个有多个 CPU的系统可能采用不同类型的 CPU而不是到处采用同一种类型的 CPU在一个三模冗余系统产生表决结构的组件可能有不同的实现这样可以减少产生同样设计错误的机会

4 )软件可靠性ldquo在规定的条件下在规定的时间内软件不引起失效的概率rdquo

规定的条件 软件运行的软硬件环境 软件操作剖面软件运行的输入空间及其概率分布

规定的时间 日历时间 时钟时间 执行时间

激活软件 输入域 缺陷的数据

软件缺陷 软件

不可接受的结果 (软件故障) 输出域

软件故障的特点

软件与硬件可靠性的区别硬件 软件

故障机理 老化损耗 残留缺陷在一定环境下造成的软件错误

复杂性 内部逻辑较为简单 内部逻辑高度复杂这就在很大程度上决定了设计错误是导致软件故障的主要原因

唯一性 任何两个硬件不可能绝对相同

软件是唯一的软件拷贝不改变软件本身

可靠性的核心 内部元部件 设计者的思维和软件的复杂性纠错维护方法 修复或更换失效的元部件 重设计 可靠性检验标准化

已标准化且有一整套完整的理论

仍未建立更没有完整的理论体系

产品市场 已有成熟的产品市场 产品市场还很新 错误性质 一些瞬间的硬件错误可能

会被误认为是软件错误 软件错误是永恒的可重现的

影响软件可靠性的因素( 1 )运行环境 ( 剖面 )

同一软件在不同运行剖面下其可靠性行为可能极不相同 软件故障是软件缺陷在一定输入情况下被激活的结果 假设软件输入域划分为两个部分 G 和 F 运行剖面不包含 F 中

的输入则软件不会出现故障其可靠性恒为 l 反之如果运行剖面不包含 G 中的输入则每一输入情况下均出现故障如果没有容错措施则 R=0

( 2 )软件规模 随着软件规模的增大软件可靠性问题愈显突出在我们考虑软件

可靠性问题时软件一般是指中型以上软件 (4000-5000条以上语句 ) 这时可靠性问题难以对付

软件工程实践的一个侧面可以反映这一点即单元测试一般由编程人员本人进行而综合测试则需独立的测试人员

影响软件可靠性的因素( 3 )软件内部结构

结构越复杂软件复杂度越高内含缺陷数越大因而软件可靠度越低

( 4 )软件可靠性设计技术 一般是指软件设计阶段中采用的用以保证和提高软件可靠性为主要目标的软件技术

( 5 )软件可靠性测试 研究表明软件测试方法与资源投入对软件可靠性有不可忽视的影

响( 6 )软件可靠性管理

软件可靠性管理旨在系统管理软件生存期各阶段的可靠性活动使之系统化规范化一体化这样就可以避免许多人为错误以提高软件可靠性

影响软件可靠性的因素( 7 )软件开发人员能力和经验

软件开发人员 ( 包括测试人员 ) 的能力愈强经验愈丰富所犯错误便可能愈少所得软件产品质量愈高相应的可靠性也愈高

( 8 )软件开发方法 软件工程表明开发方法对软件可靠性有显著影响 与非结构化方法比较结构化方法可以明显减少软件缺陷数

( 9 )软件开发环境 研究表明程序语言软件开发环境影响软件的可靠性而软件测

试工具的优劣则影响可靠性测试结果

4 安全 (Safety)amp保密 (Security)

安全 (Safety) 是保证财产和人身受到损害可靠性是指在一定的环境条件下以及一定的时间内系统完成特定任务的可能性而有效性则是系统的长期的工作时间于其存在时间 ( 简单的定义为运行时间 +维护时间 ) 的 比例保密 (Security) 是针对危险破坏损失或非法活动而进行措施在一定层面上保密 (Security)要比安全 (Safety)宽广的多例如信息 Security家庭 Security 网络 Security 国家Security) 等

Security强调的是外在事物对特定目标的危害

Safety 是系统本身的潜在危害

四个概念的比较分析安全 (Safety)可靠性 (Reliability)有效性 (Availability)保密 (Security )安全 (Safety)高的系统 软件可靠性不

一定高可靠性和有效性并不是一码事保密 (Security )的系统 软件是安全

(Safety) 系统 软件的重要保障

可靠性安全性保密性 可靠(或可信)系统设计 (Reliable (or dependable) system design)是制造嵌入式系统所关注的甚至在面对内部或者外部问题时可靠系统设计经常假设问题是非恶意引起的

安全重要的系统设计 (Safety-critical system design)研究确保系统安全操作的方法独立于引起问题的原因

保密性 (Security)主要关注恶意攻击

Aizientis等人描述了可信性和保密性间的关系可信性和保密性由几个特性所组成

服务的可用性 (Availability) 服务的连续性 (Continuity) 来自用户和所处环境的灾难性后果的安全性 (Safety) 来自不合适系统改变的完整性 (Integrity) 通过更改和修补的可维护性 (Maintainability) 信息的机密性 (Confidentiality)

可用性完整性

可靠性安全性可维护性

机密性

可信性 保密性

5 新型攻击和对策1 )物理攻击嵌入式系统比通用计算机更容易受攻击 一个关键原因是许多嵌入式计算机对攻击者可物理访问

2 )互联网攻击一些嵌入式系统的攻击通过互联网访问变得更加容易今天许多嵌入式系统连接到互联网

3 )电池攻击 (battery attack)这种攻击试图通过耗尽电池来关闭节点

4 )服务拒绝攻击 (Denial-of-service attacks)

在通用系统中众所周知但是实时嵌入式系统可能更容易受服务质量 (quality-of-service (QoS))攻击如果网络发布实时数据那么发送过程中的一点延迟都能引起数据无效如果那些数据用来实时控制那么这些短暂延迟就能引起系统故障我们称这种危害为时间攻击因为它改变了系统的实时特性

QoS或者时间攻击之所以强大使因为它的影响不仅仅限于信息被控制系统的动态特性可决定系统的响应如果一个大型沉重快速运动的系统被控制那么时间上一个相对小的改变能引起大量的破坏

5 )网络(协议)攻击Wood和 Stankovic[Woo02]在传感器网络上确定了一些方式这些方式可在网络层次的不同层执行拒绝服务攻击如下所列

物理层 (Physical layer)mdashmdash拥塞破坏 链路层 (Link layer)mdashmdash碰撞耗尽非公平

网络和路由层 (Network and routing layer)mdashmdash丢弃和贪婪汇集方向误导黑洞认证监视冗余

传输层 (Transport layer)mdashmdash泛洪失步

6 )能量攻击Kocher等人 [Koc99]指出测量一个 CPU当前的能量供给能在很大程度上确定处理器的内部活动他们提出了两种能量攻击的方法简单能量分析 (simple power analysis)人工地跟踪检查和尝试确定程序作用的位置比如分支基于不同 CUP操作的能耗知识基于程序作用攻击者然后减少密钥的比特差分能量分析 (Differential power analysis)用相关性确定作用和密钥比特这种攻击最初目标是智能卡这种卡从外部读卡器获取能量但是这种攻击也能应用到许多嵌入式系统中

7 )反攻击 在一些时候有可能构造反破坏的嵌入式系统使电子设备难以发觉和分析延缓了攻击者芯片中有限的信息也有助阻止攻击者发现数据

6 Efficiency (效率)

ES must be efficient

bull Code-size efficient( 特别是片上系统 )

bull Run-time efficient

bull Weight efficient

bull Cost efficient

bull Energy efficient

能量有效性的重要意义

ldquoinherent power

efficiency of siliconldquo

59

低功耗设计问题 功耗问题是近几年来人们在嵌入式系统的设计中普遍关注的难点和热点它严重地制约着嵌入式系统的应用与发展

无论是在军事还是在商业贸易上的应用相当数量的嵌入式系统一般是由电池来供给电能的而且大多数嵌入式设备都有体积和质量的约束减少电能消耗不仅能延长电池的使用寿命延长用户更换电池的周期而且能带来提高系统性能与降低系统开销的好处甚至能起到保护环境的作用在便携式设备中 CPU消耗的电能越少电池的寿命就越长同时散发的热量少了所需的散热器就少了从而可减少该设备的花费和体积使产品尽快进入市场的目标

1 低功耗嵌入式应用系统是指以降低系统功耗为一个主要性能指标的嵌入式系统如计算机里的许多芯片过去用 5V供电现在用 33V 18V 并提出了绿色电器的概念

60

低功耗设备的要求1 )首先要求体积小重量轻便于携带2 )采用低功耗电路的设计方法以降低系统的功耗

它除了选用各种低功耗的器件和芯片外还在满足速度等性能指标的前提下进行降低功耗的硬件电路设计和软件设计

3 )有的系统应用在交流供电比较困难甚至无法用交流供电的场合因而各种电池(瓶)就成为其主要供电手段

4 )采用 LCD液晶显示器5 )采用 RS232C串行通信接口6 )采用微功耗高抗干扰的 CMOS集成电路

功耗产生的原因 P=UI

与功耗有关的因素

( 1 )电阻上消耗的功率( 2 )有源器件的开关转换阶段( 3 )集成电路内部和外部电容的充放电( 4 )系统的性能指标负载能力被处理信号的工作频率电路的工作频率电源的管理水平零部件的性能散热条件接口的物理性能等对系统功耗起着重要的作用

降低功耗的措施

功耗的组成动态 + 静态动态电源管理动态电压缩放低功耗硬件设计低功耗软件设计

二设计方法学概论

问题功 能 性能要求价 格 开发 周 期 等约束

设计 选择 折衷 分析比较 计算 评价

嵌入式系统

0嵌入式系统设计概述

方法 工具

设计方法论( design methodology )

设计方法论有以下三个重要理由1 )确认我们所做的每一件事情都是必须要作的

不会做无谓的白工也不会漏掉关键性的重要工作其中包含效率优化或是功能测试

2 )可以发展出计算机辅助工具或是设计经验累积汲取每一次产品发展的经验再经过量化之后可以发展出一套工具或是方法让往后的产品设计步入自动化

3 )开发团队遵循同一套方法论可以让团队成员更容易彼此沟通每个人都能在短时间内了解整体过程中将经历哪些过程需要何种支持与接收到何种结果此外也容易透过一套已经定义好的方法论彼此相互合作协调

设计目标 1 )上市时间

也就是 time-to-market 的观念2 )设计成本

许多消费性产品对于价格非常敏感所以产品厂商对于成本会斤斤计较是很合理的

3 )品质 顾客也许不需要最快最便宜的产品但是一定会要求功能质量保证不能只用一小段时间就坏掉了

传统的设计主要步骤

2 传统的设计流程方法1 )瀑布模型 (Waterfall)2 )螺旋模型 (Spiral)3 )连续改进 (Successive Refinement)4 )硬件与软件的同步设计 (SWHW Co-

deign)5 )阶层式 (Hierarchical) 设计6 )同步工程( concurrent

engineering )

瀑布模型 (Waterfall)

螺旋模型 (Spiral)

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 23: 大学计算机基础 —— 计算机科学概论

1 )ldquo规定条件rdquo包括使用时的环境条件和工作条件 例如同一型号的汽车在高速公路和在崎岖的山路上行驶其可

靠性的表现就不大一样要谈论产品的可靠性必须指明规定的条件是什么2 )ldquo规定时间rdquo是指产品规定了的任务时间 随着产品任务时间的增加产品出现故障的概率将增加

而产品的可靠性将是下降的因此谈论产品的可靠性离不开规定的任务时间例如一辆汽车在在刚刚开出厂子和用了5 年后相比它出故障的概率显然大了很多

3 )ldquo规定功能rdquo是指产品规定了的必须具备的功能及其技术指标所要求产品功能的多少和其技术指标的高低直接影响到产品可靠性指标的高低

例如电风扇的主要功能有转叶摇头定时那么规定的功能是三者都要还是仅需要转叶能转能够吹风所得出的可靠性指标是大不一样的

可维护性 M(d)1 )计算机系统的可维护性是指该系统失效后在规定时间内可

修复到规定功能的能力2 )反映系统可维护性高低的参数是修复率秒平均修复时间3 )软件可维护性即维护人员对该软件进行维护的难易程度

具体包括理解改正改动和改进该软件的难易程度4 )决定可维护性的因素

系统的大小系统的年龄结构合理性

5 )可维护性的度量 可理解性可测试性可修改性可移植性

有效性 A(t)设备的有效性的表式为 设备有效性 = 平均故障间隔期 (平均故障间隔期+平均修理时间)

在逻辑中如果一个论证不能从真前提中得出假结论 则论证的形式是完全有效的

一个论证若被称为是有效的则如果在其中所有前提都为真的每个模型中结论也是真的

例如ldquo所有 A 是 B 有些 A 是 C 所以有些 B 是Crdquo 是有效形式

可用性 实用性

3 可靠系统设计的基本原理1 )故障 (faults) 分析2 )可靠性分析3 )纠错技术4 )软件可靠性

1 )故障 (faults) 分析永久 (permanent) 与暂时( transient )故障故障来源 物理故障 (Physical faults)由生产缺陷辐射危害等等引起

设计故障 (Design faults) 是不合适设计的系统的结果

操作故障 (Operational faults) 来自人为过失安全破坏劣质设计的人机接口等等

可靠性设计

故障及其分类 产品的故障按其故障规律分为两大类

偶然故障 渐变故障

产品的故障按其故障后果分为两大类 致命性故障 非致命性故障

产品的故障按其统计特性分为两大类 独立故障 从属故障

可靠度 产品在规定的条件下和规定的时间内完成规

定功能的概率称为可靠度依定义可知系统的可靠度是时间的函数表示为

式中 R(t)mdashmdash 可靠度函数 ξmdashmdash 产生故障前的工作时间 t mdashmdash 规定的时间

)()( tPtR

2 )可靠性的分析mdashmdash可靠度

可靠度函数

依定义可知可靠度函数 R(t) 为

式中 N0 mdashmdash t = 0 时在规定条件下进行工作的产品数

r(t) mdashmdash  在 0 到 t 时刻的工作时间内产品的累计

故障数

0

0 )()(

N

trNtR

累积故障分布函数 产品在规定的条件下和规定的时间内丧失

规定功能的概率称为累积故障概率(又叫不可靠度) 依定义可知产品的累积故障概率是时间的函

数即

显然以下关系成立

0

)()(

N

trtF

1)()( tFtR

可靠度函数与累积故障分布函数的性质

图 R(t)F(t)与f(t)的关系t

f(t)

f(t)

F(to)

R(to)

to

由密度函数的性质 1)(0

dttf 可知

t

tdttfdttftFtR )()(1)(1)(

0

因此 R(t) F(t) 与 f(t) 之间的关系如图所示

故障率函数 故障率

工作到某时刻尚未发生故障的产品在该时刻后单位时间内发生故障的概率称之为产品的故障率

用数学符号表示为

式中 (t) mdashmdash 故障率 dr(t) mdashmdash t 时刻后 dt 时间内故障的产品数 Ns(t) mdashmdash 残存产品数即到 t 时刻尚未故障的产品

dttN

tdrt

s )(

)()(

35

故障率函数

可按下式进行工程计算

式中 Δr(t) mdashmdash t 时刻后 Δt 时间内故障的产品数

Δt mdashmdash 所取时间间隔 Ns(t) mdashmdash 残存产品数

对于低故障率的元部件常以 10-9h 为故障率的单位称之为菲特( Fit )

ttN

trt

s

)(

)()(

产品故障浴盆曲线 浴盆曲线

大多数产品的故障率随时间的变化曲线形似浴盆称之为浴盆曲线由于产品故障机理的不同产品的故障率随时间的变化大致可以分为三个阶段

产品典型的故障率曲线

t

使用寿命

早期故障

偶然故障 耗损故障

A B规定的故障率 维修后故障率下降

(t)

3 )纠错技术( 1 )纠错码 在 1950s就开始研究最早的是可以检测和纠错的汉明码它们通过数字系统广泛地用于识别和纠正短暂或者持久的错误这些码引入冗余信息来确保一些类型的错误可以被检测和纠正比如一个单错校正 双错校正的码能用一个比特检测和纠正一个错误但是不能用两个比特纠错

( 2 )三模冗余 (triple modular

redundancy) 计算单元 C 有三个副本 C1C2和 C3三个单元接收同

样的输入一个独立单元比较每个输入的结果如果至少两个结果一致那么那个值被表决器选做正确结果如果三个结果都不相同那么就没有正确的结果

1C

2C

3C

表决错误

结果

输入

( 3 )看门狗定时器 (watchdog timer)

看门狗定时器 (watchdog timer)被广泛地用于检测系统问题如图 看门狗定时器连接到一个监视系统如果这个看门狗定时器翻转它产生一个完成信号用于标注系统的错误中断系统应该这样设计当适当运行的时候它一直在可能产生翻转信号之前复位定时器因此来自看门狗定时器的完成信号指示系统在一定程度上不合适地操作看门狗定时器用于预防不同的故障

系统看门狗定时器

完成

复位

( 4 )设计多样性 (Design diversity)

一种用于减少一些系统错误进入设计的设计方法学当一个设计需要给定模块的不同实例应该采用模块的不同实现而不是到处都用同一种模块比如一个有多个 CPU的系统可能采用不同类型的 CPU而不是到处采用同一种类型的 CPU在一个三模冗余系统产生表决结构的组件可能有不同的实现这样可以减少产生同样设计错误的机会

4 )软件可靠性ldquo在规定的条件下在规定的时间内软件不引起失效的概率rdquo

规定的条件 软件运行的软硬件环境 软件操作剖面软件运行的输入空间及其概率分布

规定的时间 日历时间 时钟时间 执行时间

激活软件 输入域 缺陷的数据

软件缺陷 软件

不可接受的结果 (软件故障) 输出域

软件故障的特点

软件与硬件可靠性的区别硬件 软件

故障机理 老化损耗 残留缺陷在一定环境下造成的软件错误

复杂性 内部逻辑较为简单 内部逻辑高度复杂这就在很大程度上决定了设计错误是导致软件故障的主要原因

唯一性 任何两个硬件不可能绝对相同

软件是唯一的软件拷贝不改变软件本身

可靠性的核心 内部元部件 设计者的思维和软件的复杂性纠错维护方法 修复或更换失效的元部件 重设计 可靠性检验标准化

已标准化且有一整套完整的理论

仍未建立更没有完整的理论体系

产品市场 已有成熟的产品市场 产品市场还很新 错误性质 一些瞬间的硬件错误可能

会被误认为是软件错误 软件错误是永恒的可重现的

影响软件可靠性的因素( 1 )运行环境 ( 剖面 )

同一软件在不同运行剖面下其可靠性行为可能极不相同 软件故障是软件缺陷在一定输入情况下被激活的结果 假设软件输入域划分为两个部分 G 和 F 运行剖面不包含 F 中

的输入则软件不会出现故障其可靠性恒为 l 反之如果运行剖面不包含 G 中的输入则每一输入情况下均出现故障如果没有容错措施则 R=0

( 2 )软件规模 随着软件规模的增大软件可靠性问题愈显突出在我们考虑软件

可靠性问题时软件一般是指中型以上软件 (4000-5000条以上语句 ) 这时可靠性问题难以对付

软件工程实践的一个侧面可以反映这一点即单元测试一般由编程人员本人进行而综合测试则需独立的测试人员

影响软件可靠性的因素( 3 )软件内部结构

结构越复杂软件复杂度越高内含缺陷数越大因而软件可靠度越低

( 4 )软件可靠性设计技术 一般是指软件设计阶段中采用的用以保证和提高软件可靠性为主要目标的软件技术

( 5 )软件可靠性测试 研究表明软件测试方法与资源投入对软件可靠性有不可忽视的影

响( 6 )软件可靠性管理

软件可靠性管理旨在系统管理软件生存期各阶段的可靠性活动使之系统化规范化一体化这样就可以避免许多人为错误以提高软件可靠性

影响软件可靠性的因素( 7 )软件开发人员能力和经验

软件开发人员 ( 包括测试人员 ) 的能力愈强经验愈丰富所犯错误便可能愈少所得软件产品质量愈高相应的可靠性也愈高

( 8 )软件开发方法 软件工程表明开发方法对软件可靠性有显著影响 与非结构化方法比较结构化方法可以明显减少软件缺陷数

( 9 )软件开发环境 研究表明程序语言软件开发环境影响软件的可靠性而软件测

试工具的优劣则影响可靠性测试结果

4 安全 (Safety)amp保密 (Security)

安全 (Safety) 是保证财产和人身受到损害可靠性是指在一定的环境条件下以及一定的时间内系统完成特定任务的可能性而有效性则是系统的长期的工作时间于其存在时间 ( 简单的定义为运行时间 +维护时间 ) 的 比例保密 (Security) 是针对危险破坏损失或非法活动而进行措施在一定层面上保密 (Security)要比安全 (Safety)宽广的多例如信息 Security家庭 Security 网络 Security 国家Security) 等

Security强调的是外在事物对特定目标的危害

Safety 是系统本身的潜在危害

四个概念的比较分析安全 (Safety)可靠性 (Reliability)有效性 (Availability)保密 (Security )安全 (Safety)高的系统 软件可靠性不

一定高可靠性和有效性并不是一码事保密 (Security )的系统 软件是安全

(Safety) 系统 软件的重要保障

可靠性安全性保密性 可靠(或可信)系统设计 (Reliable (or dependable) system design)是制造嵌入式系统所关注的甚至在面对内部或者外部问题时可靠系统设计经常假设问题是非恶意引起的

安全重要的系统设计 (Safety-critical system design)研究确保系统安全操作的方法独立于引起问题的原因

保密性 (Security)主要关注恶意攻击

Aizientis等人描述了可信性和保密性间的关系可信性和保密性由几个特性所组成

服务的可用性 (Availability) 服务的连续性 (Continuity) 来自用户和所处环境的灾难性后果的安全性 (Safety) 来自不合适系统改变的完整性 (Integrity) 通过更改和修补的可维护性 (Maintainability) 信息的机密性 (Confidentiality)

可用性完整性

可靠性安全性可维护性

机密性

可信性 保密性

5 新型攻击和对策1 )物理攻击嵌入式系统比通用计算机更容易受攻击 一个关键原因是许多嵌入式计算机对攻击者可物理访问

2 )互联网攻击一些嵌入式系统的攻击通过互联网访问变得更加容易今天许多嵌入式系统连接到互联网

3 )电池攻击 (battery attack)这种攻击试图通过耗尽电池来关闭节点

4 )服务拒绝攻击 (Denial-of-service attacks)

在通用系统中众所周知但是实时嵌入式系统可能更容易受服务质量 (quality-of-service (QoS))攻击如果网络发布实时数据那么发送过程中的一点延迟都能引起数据无效如果那些数据用来实时控制那么这些短暂延迟就能引起系统故障我们称这种危害为时间攻击因为它改变了系统的实时特性

QoS或者时间攻击之所以强大使因为它的影响不仅仅限于信息被控制系统的动态特性可决定系统的响应如果一个大型沉重快速运动的系统被控制那么时间上一个相对小的改变能引起大量的破坏

5 )网络(协议)攻击Wood和 Stankovic[Woo02]在传感器网络上确定了一些方式这些方式可在网络层次的不同层执行拒绝服务攻击如下所列

物理层 (Physical layer)mdashmdash拥塞破坏 链路层 (Link layer)mdashmdash碰撞耗尽非公平

网络和路由层 (Network and routing layer)mdashmdash丢弃和贪婪汇集方向误导黑洞认证监视冗余

传输层 (Transport layer)mdashmdash泛洪失步

6 )能量攻击Kocher等人 [Koc99]指出测量一个 CPU当前的能量供给能在很大程度上确定处理器的内部活动他们提出了两种能量攻击的方法简单能量分析 (simple power analysis)人工地跟踪检查和尝试确定程序作用的位置比如分支基于不同 CUP操作的能耗知识基于程序作用攻击者然后减少密钥的比特差分能量分析 (Differential power analysis)用相关性确定作用和密钥比特这种攻击最初目标是智能卡这种卡从外部读卡器获取能量但是这种攻击也能应用到许多嵌入式系统中

7 )反攻击 在一些时候有可能构造反破坏的嵌入式系统使电子设备难以发觉和分析延缓了攻击者芯片中有限的信息也有助阻止攻击者发现数据

6 Efficiency (效率)

ES must be efficient

bull Code-size efficient( 特别是片上系统 )

bull Run-time efficient

bull Weight efficient

bull Cost efficient

bull Energy efficient

能量有效性的重要意义

ldquoinherent power

efficiency of siliconldquo

59

低功耗设计问题 功耗问题是近几年来人们在嵌入式系统的设计中普遍关注的难点和热点它严重地制约着嵌入式系统的应用与发展

无论是在军事还是在商业贸易上的应用相当数量的嵌入式系统一般是由电池来供给电能的而且大多数嵌入式设备都有体积和质量的约束减少电能消耗不仅能延长电池的使用寿命延长用户更换电池的周期而且能带来提高系统性能与降低系统开销的好处甚至能起到保护环境的作用在便携式设备中 CPU消耗的电能越少电池的寿命就越长同时散发的热量少了所需的散热器就少了从而可减少该设备的花费和体积使产品尽快进入市场的目标

1 低功耗嵌入式应用系统是指以降低系统功耗为一个主要性能指标的嵌入式系统如计算机里的许多芯片过去用 5V供电现在用 33V 18V 并提出了绿色电器的概念

60

低功耗设备的要求1 )首先要求体积小重量轻便于携带2 )采用低功耗电路的设计方法以降低系统的功耗

它除了选用各种低功耗的器件和芯片外还在满足速度等性能指标的前提下进行降低功耗的硬件电路设计和软件设计

3 )有的系统应用在交流供电比较困难甚至无法用交流供电的场合因而各种电池(瓶)就成为其主要供电手段

4 )采用 LCD液晶显示器5 )采用 RS232C串行通信接口6 )采用微功耗高抗干扰的 CMOS集成电路

功耗产生的原因 P=UI

与功耗有关的因素

( 1 )电阻上消耗的功率( 2 )有源器件的开关转换阶段( 3 )集成电路内部和外部电容的充放电( 4 )系统的性能指标负载能力被处理信号的工作频率电路的工作频率电源的管理水平零部件的性能散热条件接口的物理性能等对系统功耗起着重要的作用

降低功耗的措施

功耗的组成动态 + 静态动态电源管理动态电压缩放低功耗硬件设计低功耗软件设计

二设计方法学概论

问题功 能 性能要求价 格 开发 周 期 等约束

设计 选择 折衷 分析比较 计算 评价

嵌入式系统

0嵌入式系统设计概述

方法 工具

设计方法论( design methodology )

设计方法论有以下三个重要理由1 )确认我们所做的每一件事情都是必须要作的

不会做无谓的白工也不会漏掉关键性的重要工作其中包含效率优化或是功能测试

2 )可以发展出计算机辅助工具或是设计经验累积汲取每一次产品发展的经验再经过量化之后可以发展出一套工具或是方法让往后的产品设计步入自动化

3 )开发团队遵循同一套方法论可以让团队成员更容易彼此沟通每个人都能在短时间内了解整体过程中将经历哪些过程需要何种支持与接收到何种结果此外也容易透过一套已经定义好的方法论彼此相互合作协调

设计目标 1 )上市时间

也就是 time-to-market 的观念2 )设计成本

许多消费性产品对于价格非常敏感所以产品厂商对于成本会斤斤计较是很合理的

3 )品质 顾客也许不需要最快最便宜的产品但是一定会要求功能质量保证不能只用一小段时间就坏掉了

传统的设计主要步骤

2 传统的设计流程方法1 )瀑布模型 (Waterfall)2 )螺旋模型 (Spiral)3 )连续改进 (Successive Refinement)4 )硬件与软件的同步设计 (SWHW Co-

deign)5 )阶层式 (Hierarchical) 设计6 )同步工程( concurrent

engineering )

瀑布模型 (Waterfall)

螺旋模型 (Spiral)

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 24: 大学计算机基础 —— 计算机科学概论

可维护性 M(d)1 )计算机系统的可维护性是指该系统失效后在规定时间内可

修复到规定功能的能力2 )反映系统可维护性高低的参数是修复率秒平均修复时间3 )软件可维护性即维护人员对该软件进行维护的难易程度

具体包括理解改正改动和改进该软件的难易程度4 )决定可维护性的因素

系统的大小系统的年龄结构合理性

5 )可维护性的度量 可理解性可测试性可修改性可移植性

有效性 A(t)设备的有效性的表式为 设备有效性 = 平均故障间隔期 (平均故障间隔期+平均修理时间)

在逻辑中如果一个论证不能从真前提中得出假结论 则论证的形式是完全有效的

一个论证若被称为是有效的则如果在其中所有前提都为真的每个模型中结论也是真的

例如ldquo所有 A 是 B 有些 A 是 C 所以有些 B 是Crdquo 是有效形式

可用性 实用性

3 可靠系统设计的基本原理1 )故障 (faults) 分析2 )可靠性分析3 )纠错技术4 )软件可靠性

1 )故障 (faults) 分析永久 (permanent) 与暂时( transient )故障故障来源 物理故障 (Physical faults)由生产缺陷辐射危害等等引起

设计故障 (Design faults) 是不合适设计的系统的结果

操作故障 (Operational faults) 来自人为过失安全破坏劣质设计的人机接口等等

可靠性设计

故障及其分类 产品的故障按其故障规律分为两大类

偶然故障 渐变故障

产品的故障按其故障后果分为两大类 致命性故障 非致命性故障

产品的故障按其统计特性分为两大类 独立故障 从属故障

可靠度 产品在规定的条件下和规定的时间内完成规

定功能的概率称为可靠度依定义可知系统的可靠度是时间的函数表示为

式中 R(t)mdashmdash 可靠度函数 ξmdashmdash 产生故障前的工作时间 t mdashmdash 规定的时间

)()( tPtR

2 )可靠性的分析mdashmdash可靠度

可靠度函数

依定义可知可靠度函数 R(t) 为

式中 N0 mdashmdash t = 0 时在规定条件下进行工作的产品数

r(t) mdashmdash  在 0 到 t 时刻的工作时间内产品的累计

故障数

0

0 )()(

N

trNtR

累积故障分布函数 产品在规定的条件下和规定的时间内丧失

规定功能的概率称为累积故障概率(又叫不可靠度) 依定义可知产品的累积故障概率是时间的函

数即

显然以下关系成立

0

)()(

N

trtF

1)()( tFtR

可靠度函数与累积故障分布函数的性质

图 R(t)F(t)与f(t)的关系t

f(t)

f(t)

F(to)

R(to)

to

由密度函数的性质 1)(0

dttf 可知

t

tdttfdttftFtR )()(1)(1)(

0

因此 R(t) F(t) 与 f(t) 之间的关系如图所示

故障率函数 故障率

工作到某时刻尚未发生故障的产品在该时刻后单位时间内发生故障的概率称之为产品的故障率

用数学符号表示为

式中 (t) mdashmdash 故障率 dr(t) mdashmdash t 时刻后 dt 时间内故障的产品数 Ns(t) mdashmdash 残存产品数即到 t 时刻尚未故障的产品

dttN

tdrt

s )(

)()(

35

故障率函数

可按下式进行工程计算

式中 Δr(t) mdashmdash t 时刻后 Δt 时间内故障的产品数

Δt mdashmdash 所取时间间隔 Ns(t) mdashmdash 残存产品数

对于低故障率的元部件常以 10-9h 为故障率的单位称之为菲特( Fit )

ttN

trt

s

)(

)()(

产品故障浴盆曲线 浴盆曲线

大多数产品的故障率随时间的变化曲线形似浴盆称之为浴盆曲线由于产品故障机理的不同产品的故障率随时间的变化大致可以分为三个阶段

产品典型的故障率曲线

t

使用寿命

早期故障

偶然故障 耗损故障

A B规定的故障率 维修后故障率下降

(t)

3 )纠错技术( 1 )纠错码 在 1950s就开始研究最早的是可以检测和纠错的汉明码它们通过数字系统广泛地用于识别和纠正短暂或者持久的错误这些码引入冗余信息来确保一些类型的错误可以被检测和纠正比如一个单错校正 双错校正的码能用一个比特检测和纠正一个错误但是不能用两个比特纠错

( 2 )三模冗余 (triple modular

redundancy) 计算单元 C 有三个副本 C1C2和 C3三个单元接收同

样的输入一个独立单元比较每个输入的结果如果至少两个结果一致那么那个值被表决器选做正确结果如果三个结果都不相同那么就没有正确的结果

1C

2C

3C

表决错误

结果

输入

( 3 )看门狗定时器 (watchdog timer)

看门狗定时器 (watchdog timer)被广泛地用于检测系统问题如图 看门狗定时器连接到一个监视系统如果这个看门狗定时器翻转它产生一个完成信号用于标注系统的错误中断系统应该这样设计当适当运行的时候它一直在可能产生翻转信号之前复位定时器因此来自看门狗定时器的完成信号指示系统在一定程度上不合适地操作看门狗定时器用于预防不同的故障

系统看门狗定时器

完成

复位

( 4 )设计多样性 (Design diversity)

一种用于减少一些系统错误进入设计的设计方法学当一个设计需要给定模块的不同实例应该采用模块的不同实现而不是到处都用同一种模块比如一个有多个 CPU的系统可能采用不同类型的 CPU而不是到处采用同一种类型的 CPU在一个三模冗余系统产生表决结构的组件可能有不同的实现这样可以减少产生同样设计错误的机会

4 )软件可靠性ldquo在规定的条件下在规定的时间内软件不引起失效的概率rdquo

规定的条件 软件运行的软硬件环境 软件操作剖面软件运行的输入空间及其概率分布

规定的时间 日历时间 时钟时间 执行时间

激活软件 输入域 缺陷的数据

软件缺陷 软件

不可接受的结果 (软件故障) 输出域

软件故障的特点

软件与硬件可靠性的区别硬件 软件

故障机理 老化损耗 残留缺陷在一定环境下造成的软件错误

复杂性 内部逻辑较为简单 内部逻辑高度复杂这就在很大程度上决定了设计错误是导致软件故障的主要原因

唯一性 任何两个硬件不可能绝对相同

软件是唯一的软件拷贝不改变软件本身

可靠性的核心 内部元部件 设计者的思维和软件的复杂性纠错维护方法 修复或更换失效的元部件 重设计 可靠性检验标准化

已标准化且有一整套完整的理论

仍未建立更没有完整的理论体系

产品市场 已有成熟的产品市场 产品市场还很新 错误性质 一些瞬间的硬件错误可能

会被误认为是软件错误 软件错误是永恒的可重现的

影响软件可靠性的因素( 1 )运行环境 ( 剖面 )

同一软件在不同运行剖面下其可靠性行为可能极不相同 软件故障是软件缺陷在一定输入情况下被激活的结果 假设软件输入域划分为两个部分 G 和 F 运行剖面不包含 F 中

的输入则软件不会出现故障其可靠性恒为 l 反之如果运行剖面不包含 G 中的输入则每一输入情况下均出现故障如果没有容错措施则 R=0

( 2 )软件规模 随着软件规模的增大软件可靠性问题愈显突出在我们考虑软件

可靠性问题时软件一般是指中型以上软件 (4000-5000条以上语句 ) 这时可靠性问题难以对付

软件工程实践的一个侧面可以反映这一点即单元测试一般由编程人员本人进行而综合测试则需独立的测试人员

影响软件可靠性的因素( 3 )软件内部结构

结构越复杂软件复杂度越高内含缺陷数越大因而软件可靠度越低

( 4 )软件可靠性设计技术 一般是指软件设计阶段中采用的用以保证和提高软件可靠性为主要目标的软件技术

( 5 )软件可靠性测试 研究表明软件测试方法与资源投入对软件可靠性有不可忽视的影

响( 6 )软件可靠性管理

软件可靠性管理旨在系统管理软件生存期各阶段的可靠性活动使之系统化规范化一体化这样就可以避免许多人为错误以提高软件可靠性

影响软件可靠性的因素( 7 )软件开发人员能力和经验

软件开发人员 ( 包括测试人员 ) 的能力愈强经验愈丰富所犯错误便可能愈少所得软件产品质量愈高相应的可靠性也愈高

( 8 )软件开发方法 软件工程表明开发方法对软件可靠性有显著影响 与非结构化方法比较结构化方法可以明显减少软件缺陷数

( 9 )软件开发环境 研究表明程序语言软件开发环境影响软件的可靠性而软件测

试工具的优劣则影响可靠性测试结果

4 安全 (Safety)amp保密 (Security)

安全 (Safety) 是保证财产和人身受到损害可靠性是指在一定的环境条件下以及一定的时间内系统完成特定任务的可能性而有效性则是系统的长期的工作时间于其存在时间 ( 简单的定义为运行时间 +维护时间 ) 的 比例保密 (Security) 是针对危险破坏损失或非法活动而进行措施在一定层面上保密 (Security)要比安全 (Safety)宽广的多例如信息 Security家庭 Security 网络 Security 国家Security) 等

Security强调的是外在事物对特定目标的危害

Safety 是系统本身的潜在危害

四个概念的比较分析安全 (Safety)可靠性 (Reliability)有效性 (Availability)保密 (Security )安全 (Safety)高的系统 软件可靠性不

一定高可靠性和有效性并不是一码事保密 (Security )的系统 软件是安全

(Safety) 系统 软件的重要保障

可靠性安全性保密性 可靠(或可信)系统设计 (Reliable (or dependable) system design)是制造嵌入式系统所关注的甚至在面对内部或者外部问题时可靠系统设计经常假设问题是非恶意引起的

安全重要的系统设计 (Safety-critical system design)研究确保系统安全操作的方法独立于引起问题的原因

保密性 (Security)主要关注恶意攻击

Aizientis等人描述了可信性和保密性间的关系可信性和保密性由几个特性所组成

服务的可用性 (Availability) 服务的连续性 (Continuity) 来自用户和所处环境的灾难性后果的安全性 (Safety) 来自不合适系统改变的完整性 (Integrity) 通过更改和修补的可维护性 (Maintainability) 信息的机密性 (Confidentiality)

可用性完整性

可靠性安全性可维护性

机密性

可信性 保密性

5 新型攻击和对策1 )物理攻击嵌入式系统比通用计算机更容易受攻击 一个关键原因是许多嵌入式计算机对攻击者可物理访问

2 )互联网攻击一些嵌入式系统的攻击通过互联网访问变得更加容易今天许多嵌入式系统连接到互联网

3 )电池攻击 (battery attack)这种攻击试图通过耗尽电池来关闭节点

4 )服务拒绝攻击 (Denial-of-service attacks)

在通用系统中众所周知但是实时嵌入式系统可能更容易受服务质量 (quality-of-service (QoS))攻击如果网络发布实时数据那么发送过程中的一点延迟都能引起数据无效如果那些数据用来实时控制那么这些短暂延迟就能引起系统故障我们称这种危害为时间攻击因为它改变了系统的实时特性

QoS或者时间攻击之所以强大使因为它的影响不仅仅限于信息被控制系统的动态特性可决定系统的响应如果一个大型沉重快速运动的系统被控制那么时间上一个相对小的改变能引起大量的破坏

5 )网络(协议)攻击Wood和 Stankovic[Woo02]在传感器网络上确定了一些方式这些方式可在网络层次的不同层执行拒绝服务攻击如下所列

物理层 (Physical layer)mdashmdash拥塞破坏 链路层 (Link layer)mdashmdash碰撞耗尽非公平

网络和路由层 (Network and routing layer)mdashmdash丢弃和贪婪汇集方向误导黑洞认证监视冗余

传输层 (Transport layer)mdashmdash泛洪失步

6 )能量攻击Kocher等人 [Koc99]指出测量一个 CPU当前的能量供给能在很大程度上确定处理器的内部活动他们提出了两种能量攻击的方法简单能量分析 (simple power analysis)人工地跟踪检查和尝试确定程序作用的位置比如分支基于不同 CUP操作的能耗知识基于程序作用攻击者然后减少密钥的比特差分能量分析 (Differential power analysis)用相关性确定作用和密钥比特这种攻击最初目标是智能卡这种卡从外部读卡器获取能量但是这种攻击也能应用到许多嵌入式系统中

7 )反攻击 在一些时候有可能构造反破坏的嵌入式系统使电子设备难以发觉和分析延缓了攻击者芯片中有限的信息也有助阻止攻击者发现数据

6 Efficiency (效率)

ES must be efficient

bull Code-size efficient( 特别是片上系统 )

bull Run-time efficient

bull Weight efficient

bull Cost efficient

bull Energy efficient

能量有效性的重要意义

ldquoinherent power

efficiency of siliconldquo

59

低功耗设计问题 功耗问题是近几年来人们在嵌入式系统的设计中普遍关注的难点和热点它严重地制约着嵌入式系统的应用与发展

无论是在军事还是在商业贸易上的应用相当数量的嵌入式系统一般是由电池来供给电能的而且大多数嵌入式设备都有体积和质量的约束减少电能消耗不仅能延长电池的使用寿命延长用户更换电池的周期而且能带来提高系统性能与降低系统开销的好处甚至能起到保护环境的作用在便携式设备中 CPU消耗的电能越少电池的寿命就越长同时散发的热量少了所需的散热器就少了从而可减少该设备的花费和体积使产品尽快进入市场的目标

1 低功耗嵌入式应用系统是指以降低系统功耗为一个主要性能指标的嵌入式系统如计算机里的许多芯片过去用 5V供电现在用 33V 18V 并提出了绿色电器的概念

60

低功耗设备的要求1 )首先要求体积小重量轻便于携带2 )采用低功耗电路的设计方法以降低系统的功耗

它除了选用各种低功耗的器件和芯片外还在满足速度等性能指标的前提下进行降低功耗的硬件电路设计和软件设计

3 )有的系统应用在交流供电比较困难甚至无法用交流供电的场合因而各种电池(瓶)就成为其主要供电手段

4 )采用 LCD液晶显示器5 )采用 RS232C串行通信接口6 )采用微功耗高抗干扰的 CMOS集成电路

功耗产生的原因 P=UI

与功耗有关的因素

( 1 )电阻上消耗的功率( 2 )有源器件的开关转换阶段( 3 )集成电路内部和外部电容的充放电( 4 )系统的性能指标负载能力被处理信号的工作频率电路的工作频率电源的管理水平零部件的性能散热条件接口的物理性能等对系统功耗起着重要的作用

降低功耗的措施

功耗的组成动态 + 静态动态电源管理动态电压缩放低功耗硬件设计低功耗软件设计

二设计方法学概论

问题功 能 性能要求价 格 开发 周 期 等约束

设计 选择 折衷 分析比较 计算 评价

嵌入式系统

0嵌入式系统设计概述

方法 工具

设计方法论( design methodology )

设计方法论有以下三个重要理由1 )确认我们所做的每一件事情都是必须要作的

不会做无谓的白工也不会漏掉关键性的重要工作其中包含效率优化或是功能测试

2 )可以发展出计算机辅助工具或是设计经验累积汲取每一次产品发展的经验再经过量化之后可以发展出一套工具或是方法让往后的产品设计步入自动化

3 )开发团队遵循同一套方法论可以让团队成员更容易彼此沟通每个人都能在短时间内了解整体过程中将经历哪些过程需要何种支持与接收到何种结果此外也容易透过一套已经定义好的方法论彼此相互合作协调

设计目标 1 )上市时间

也就是 time-to-market 的观念2 )设计成本

许多消费性产品对于价格非常敏感所以产品厂商对于成本会斤斤计较是很合理的

3 )品质 顾客也许不需要最快最便宜的产品但是一定会要求功能质量保证不能只用一小段时间就坏掉了

传统的设计主要步骤

2 传统的设计流程方法1 )瀑布模型 (Waterfall)2 )螺旋模型 (Spiral)3 )连续改进 (Successive Refinement)4 )硬件与软件的同步设计 (SWHW Co-

deign)5 )阶层式 (Hierarchical) 设计6 )同步工程( concurrent

engineering )

瀑布模型 (Waterfall)

螺旋模型 (Spiral)

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 25: 大学计算机基础 —— 计算机科学概论

有效性 A(t)设备的有效性的表式为 设备有效性 = 平均故障间隔期 (平均故障间隔期+平均修理时间)

在逻辑中如果一个论证不能从真前提中得出假结论 则论证的形式是完全有效的

一个论证若被称为是有效的则如果在其中所有前提都为真的每个模型中结论也是真的

例如ldquo所有 A 是 B 有些 A 是 C 所以有些 B 是Crdquo 是有效形式

可用性 实用性

3 可靠系统设计的基本原理1 )故障 (faults) 分析2 )可靠性分析3 )纠错技术4 )软件可靠性

1 )故障 (faults) 分析永久 (permanent) 与暂时( transient )故障故障来源 物理故障 (Physical faults)由生产缺陷辐射危害等等引起

设计故障 (Design faults) 是不合适设计的系统的结果

操作故障 (Operational faults) 来自人为过失安全破坏劣质设计的人机接口等等

可靠性设计

故障及其分类 产品的故障按其故障规律分为两大类

偶然故障 渐变故障

产品的故障按其故障后果分为两大类 致命性故障 非致命性故障

产品的故障按其统计特性分为两大类 独立故障 从属故障

可靠度 产品在规定的条件下和规定的时间内完成规

定功能的概率称为可靠度依定义可知系统的可靠度是时间的函数表示为

式中 R(t)mdashmdash 可靠度函数 ξmdashmdash 产生故障前的工作时间 t mdashmdash 规定的时间

)()( tPtR

2 )可靠性的分析mdashmdash可靠度

可靠度函数

依定义可知可靠度函数 R(t) 为

式中 N0 mdashmdash t = 0 时在规定条件下进行工作的产品数

r(t) mdashmdash  在 0 到 t 时刻的工作时间内产品的累计

故障数

0

0 )()(

N

trNtR

累积故障分布函数 产品在规定的条件下和规定的时间内丧失

规定功能的概率称为累积故障概率(又叫不可靠度) 依定义可知产品的累积故障概率是时间的函

数即

显然以下关系成立

0

)()(

N

trtF

1)()( tFtR

可靠度函数与累积故障分布函数的性质

图 R(t)F(t)与f(t)的关系t

f(t)

f(t)

F(to)

R(to)

to

由密度函数的性质 1)(0

dttf 可知

t

tdttfdttftFtR )()(1)(1)(

0

因此 R(t) F(t) 与 f(t) 之间的关系如图所示

故障率函数 故障率

工作到某时刻尚未发生故障的产品在该时刻后单位时间内发生故障的概率称之为产品的故障率

用数学符号表示为

式中 (t) mdashmdash 故障率 dr(t) mdashmdash t 时刻后 dt 时间内故障的产品数 Ns(t) mdashmdash 残存产品数即到 t 时刻尚未故障的产品

dttN

tdrt

s )(

)()(

35

故障率函数

可按下式进行工程计算

式中 Δr(t) mdashmdash t 时刻后 Δt 时间内故障的产品数

Δt mdashmdash 所取时间间隔 Ns(t) mdashmdash 残存产品数

对于低故障率的元部件常以 10-9h 为故障率的单位称之为菲特( Fit )

ttN

trt

s

)(

)()(

产品故障浴盆曲线 浴盆曲线

大多数产品的故障率随时间的变化曲线形似浴盆称之为浴盆曲线由于产品故障机理的不同产品的故障率随时间的变化大致可以分为三个阶段

产品典型的故障率曲线

t

使用寿命

早期故障

偶然故障 耗损故障

A B规定的故障率 维修后故障率下降

(t)

3 )纠错技术( 1 )纠错码 在 1950s就开始研究最早的是可以检测和纠错的汉明码它们通过数字系统广泛地用于识别和纠正短暂或者持久的错误这些码引入冗余信息来确保一些类型的错误可以被检测和纠正比如一个单错校正 双错校正的码能用一个比特检测和纠正一个错误但是不能用两个比特纠错

( 2 )三模冗余 (triple modular

redundancy) 计算单元 C 有三个副本 C1C2和 C3三个单元接收同

样的输入一个独立单元比较每个输入的结果如果至少两个结果一致那么那个值被表决器选做正确结果如果三个结果都不相同那么就没有正确的结果

1C

2C

3C

表决错误

结果

输入

( 3 )看门狗定时器 (watchdog timer)

看门狗定时器 (watchdog timer)被广泛地用于检测系统问题如图 看门狗定时器连接到一个监视系统如果这个看门狗定时器翻转它产生一个完成信号用于标注系统的错误中断系统应该这样设计当适当运行的时候它一直在可能产生翻转信号之前复位定时器因此来自看门狗定时器的完成信号指示系统在一定程度上不合适地操作看门狗定时器用于预防不同的故障

系统看门狗定时器

完成

复位

( 4 )设计多样性 (Design diversity)

一种用于减少一些系统错误进入设计的设计方法学当一个设计需要给定模块的不同实例应该采用模块的不同实现而不是到处都用同一种模块比如一个有多个 CPU的系统可能采用不同类型的 CPU而不是到处采用同一种类型的 CPU在一个三模冗余系统产生表决结构的组件可能有不同的实现这样可以减少产生同样设计错误的机会

4 )软件可靠性ldquo在规定的条件下在规定的时间内软件不引起失效的概率rdquo

规定的条件 软件运行的软硬件环境 软件操作剖面软件运行的输入空间及其概率分布

规定的时间 日历时间 时钟时间 执行时间

激活软件 输入域 缺陷的数据

软件缺陷 软件

不可接受的结果 (软件故障) 输出域

软件故障的特点

软件与硬件可靠性的区别硬件 软件

故障机理 老化损耗 残留缺陷在一定环境下造成的软件错误

复杂性 内部逻辑较为简单 内部逻辑高度复杂这就在很大程度上决定了设计错误是导致软件故障的主要原因

唯一性 任何两个硬件不可能绝对相同

软件是唯一的软件拷贝不改变软件本身

可靠性的核心 内部元部件 设计者的思维和软件的复杂性纠错维护方法 修复或更换失效的元部件 重设计 可靠性检验标准化

已标准化且有一整套完整的理论

仍未建立更没有完整的理论体系

产品市场 已有成熟的产品市场 产品市场还很新 错误性质 一些瞬间的硬件错误可能

会被误认为是软件错误 软件错误是永恒的可重现的

影响软件可靠性的因素( 1 )运行环境 ( 剖面 )

同一软件在不同运行剖面下其可靠性行为可能极不相同 软件故障是软件缺陷在一定输入情况下被激活的结果 假设软件输入域划分为两个部分 G 和 F 运行剖面不包含 F 中

的输入则软件不会出现故障其可靠性恒为 l 反之如果运行剖面不包含 G 中的输入则每一输入情况下均出现故障如果没有容错措施则 R=0

( 2 )软件规模 随着软件规模的增大软件可靠性问题愈显突出在我们考虑软件

可靠性问题时软件一般是指中型以上软件 (4000-5000条以上语句 ) 这时可靠性问题难以对付

软件工程实践的一个侧面可以反映这一点即单元测试一般由编程人员本人进行而综合测试则需独立的测试人员

影响软件可靠性的因素( 3 )软件内部结构

结构越复杂软件复杂度越高内含缺陷数越大因而软件可靠度越低

( 4 )软件可靠性设计技术 一般是指软件设计阶段中采用的用以保证和提高软件可靠性为主要目标的软件技术

( 5 )软件可靠性测试 研究表明软件测试方法与资源投入对软件可靠性有不可忽视的影

响( 6 )软件可靠性管理

软件可靠性管理旨在系统管理软件生存期各阶段的可靠性活动使之系统化规范化一体化这样就可以避免许多人为错误以提高软件可靠性

影响软件可靠性的因素( 7 )软件开发人员能力和经验

软件开发人员 ( 包括测试人员 ) 的能力愈强经验愈丰富所犯错误便可能愈少所得软件产品质量愈高相应的可靠性也愈高

( 8 )软件开发方法 软件工程表明开发方法对软件可靠性有显著影响 与非结构化方法比较结构化方法可以明显减少软件缺陷数

( 9 )软件开发环境 研究表明程序语言软件开发环境影响软件的可靠性而软件测

试工具的优劣则影响可靠性测试结果

4 安全 (Safety)amp保密 (Security)

安全 (Safety) 是保证财产和人身受到损害可靠性是指在一定的环境条件下以及一定的时间内系统完成特定任务的可能性而有效性则是系统的长期的工作时间于其存在时间 ( 简单的定义为运行时间 +维护时间 ) 的 比例保密 (Security) 是针对危险破坏损失或非法活动而进行措施在一定层面上保密 (Security)要比安全 (Safety)宽广的多例如信息 Security家庭 Security 网络 Security 国家Security) 等

Security强调的是外在事物对特定目标的危害

Safety 是系统本身的潜在危害

四个概念的比较分析安全 (Safety)可靠性 (Reliability)有效性 (Availability)保密 (Security )安全 (Safety)高的系统 软件可靠性不

一定高可靠性和有效性并不是一码事保密 (Security )的系统 软件是安全

(Safety) 系统 软件的重要保障

可靠性安全性保密性 可靠(或可信)系统设计 (Reliable (or dependable) system design)是制造嵌入式系统所关注的甚至在面对内部或者外部问题时可靠系统设计经常假设问题是非恶意引起的

安全重要的系统设计 (Safety-critical system design)研究确保系统安全操作的方法独立于引起问题的原因

保密性 (Security)主要关注恶意攻击

Aizientis等人描述了可信性和保密性间的关系可信性和保密性由几个特性所组成

服务的可用性 (Availability) 服务的连续性 (Continuity) 来自用户和所处环境的灾难性后果的安全性 (Safety) 来自不合适系统改变的完整性 (Integrity) 通过更改和修补的可维护性 (Maintainability) 信息的机密性 (Confidentiality)

可用性完整性

可靠性安全性可维护性

机密性

可信性 保密性

5 新型攻击和对策1 )物理攻击嵌入式系统比通用计算机更容易受攻击 一个关键原因是许多嵌入式计算机对攻击者可物理访问

2 )互联网攻击一些嵌入式系统的攻击通过互联网访问变得更加容易今天许多嵌入式系统连接到互联网

3 )电池攻击 (battery attack)这种攻击试图通过耗尽电池来关闭节点

4 )服务拒绝攻击 (Denial-of-service attacks)

在通用系统中众所周知但是实时嵌入式系统可能更容易受服务质量 (quality-of-service (QoS))攻击如果网络发布实时数据那么发送过程中的一点延迟都能引起数据无效如果那些数据用来实时控制那么这些短暂延迟就能引起系统故障我们称这种危害为时间攻击因为它改变了系统的实时特性

QoS或者时间攻击之所以强大使因为它的影响不仅仅限于信息被控制系统的动态特性可决定系统的响应如果一个大型沉重快速运动的系统被控制那么时间上一个相对小的改变能引起大量的破坏

5 )网络(协议)攻击Wood和 Stankovic[Woo02]在传感器网络上确定了一些方式这些方式可在网络层次的不同层执行拒绝服务攻击如下所列

物理层 (Physical layer)mdashmdash拥塞破坏 链路层 (Link layer)mdashmdash碰撞耗尽非公平

网络和路由层 (Network and routing layer)mdashmdash丢弃和贪婪汇集方向误导黑洞认证监视冗余

传输层 (Transport layer)mdashmdash泛洪失步

6 )能量攻击Kocher等人 [Koc99]指出测量一个 CPU当前的能量供给能在很大程度上确定处理器的内部活动他们提出了两种能量攻击的方法简单能量分析 (simple power analysis)人工地跟踪检查和尝试确定程序作用的位置比如分支基于不同 CUP操作的能耗知识基于程序作用攻击者然后减少密钥的比特差分能量分析 (Differential power analysis)用相关性确定作用和密钥比特这种攻击最初目标是智能卡这种卡从外部读卡器获取能量但是这种攻击也能应用到许多嵌入式系统中

7 )反攻击 在一些时候有可能构造反破坏的嵌入式系统使电子设备难以发觉和分析延缓了攻击者芯片中有限的信息也有助阻止攻击者发现数据

6 Efficiency (效率)

ES must be efficient

bull Code-size efficient( 特别是片上系统 )

bull Run-time efficient

bull Weight efficient

bull Cost efficient

bull Energy efficient

能量有效性的重要意义

ldquoinherent power

efficiency of siliconldquo

59

低功耗设计问题 功耗问题是近几年来人们在嵌入式系统的设计中普遍关注的难点和热点它严重地制约着嵌入式系统的应用与发展

无论是在军事还是在商业贸易上的应用相当数量的嵌入式系统一般是由电池来供给电能的而且大多数嵌入式设备都有体积和质量的约束减少电能消耗不仅能延长电池的使用寿命延长用户更换电池的周期而且能带来提高系统性能与降低系统开销的好处甚至能起到保护环境的作用在便携式设备中 CPU消耗的电能越少电池的寿命就越长同时散发的热量少了所需的散热器就少了从而可减少该设备的花费和体积使产品尽快进入市场的目标

1 低功耗嵌入式应用系统是指以降低系统功耗为一个主要性能指标的嵌入式系统如计算机里的许多芯片过去用 5V供电现在用 33V 18V 并提出了绿色电器的概念

60

低功耗设备的要求1 )首先要求体积小重量轻便于携带2 )采用低功耗电路的设计方法以降低系统的功耗

它除了选用各种低功耗的器件和芯片外还在满足速度等性能指标的前提下进行降低功耗的硬件电路设计和软件设计

3 )有的系统应用在交流供电比较困难甚至无法用交流供电的场合因而各种电池(瓶)就成为其主要供电手段

4 )采用 LCD液晶显示器5 )采用 RS232C串行通信接口6 )采用微功耗高抗干扰的 CMOS集成电路

功耗产生的原因 P=UI

与功耗有关的因素

( 1 )电阻上消耗的功率( 2 )有源器件的开关转换阶段( 3 )集成电路内部和外部电容的充放电( 4 )系统的性能指标负载能力被处理信号的工作频率电路的工作频率电源的管理水平零部件的性能散热条件接口的物理性能等对系统功耗起着重要的作用

降低功耗的措施

功耗的组成动态 + 静态动态电源管理动态电压缩放低功耗硬件设计低功耗软件设计

二设计方法学概论

问题功 能 性能要求价 格 开发 周 期 等约束

设计 选择 折衷 分析比较 计算 评价

嵌入式系统

0嵌入式系统设计概述

方法 工具

设计方法论( design methodology )

设计方法论有以下三个重要理由1 )确认我们所做的每一件事情都是必须要作的

不会做无谓的白工也不会漏掉关键性的重要工作其中包含效率优化或是功能测试

2 )可以发展出计算机辅助工具或是设计经验累积汲取每一次产品发展的经验再经过量化之后可以发展出一套工具或是方法让往后的产品设计步入自动化

3 )开发团队遵循同一套方法论可以让团队成员更容易彼此沟通每个人都能在短时间内了解整体过程中将经历哪些过程需要何种支持与接收到何种结果此外也容易透过一套已经定义好的方法论彼此相互合作协调

设计目标 1 )上市时间

也就是 time-to-market 的观念2 )设计成本

许多消费性产品对于价格非常敏感所以产品厂商对于成本会斤斤计较是很合理的

3 )品质 顾客也许不需要最快最便宜的产品但是一定会要求功能质量保证不能只用一小段时间就坏掉了

传统的设计主要步骤

2 传统的设计流程方法1 )瀑布模型 (Waterfall)2 )螺旋模型 (Spiral)3 )连续改进 (Successive Refinement)4 )硬件与软件的同步设计 (SWHW Co-

deign)5 )阶层式 (Hierarchical) 设计6 )同步工程( concurrent

engineering )

瀑布模型 (Waterfall)

螺旋模型 (Spiral)

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 26: 大学计算机基础 —— 计算机科学概论

3 可靠系统设计的基本原理1 )故障 (faults) 分析2 )可靠性分析3 )纠错技术4 )软件可靠性

1 )故障 (faults) 分析永久 (permanent) 与暂时( transient )故障故障来源 物理故障 (Physical faults)由生产缺陷辐射危害等等引起

设计故障 (Design faults) 是不合适设计的系统的结果

操作故障 (Operational faults) 来自人为过失安全破坏劣质设计的人机接口等等

可靠性设计

故障及其分类 产品的故障按其故障规律分为两大类

偶然故障 渐变故障

产品的故障按其故障后果分为两大类 致命性故障 非致命性故障

产品的故障按其统计特性分为两大类 独立故障 从属故障

可靠度 产品在规定的条件下和规定的时间内完成规

定功能的概率称为可靠度依定义可知系统的可靠度是时间的函数表示为

式中 R(t)mdashmdash 可靠度函数 ξmdashmdash 产生故障前的工作时间 t mdashmdash 规定的时间

)()( tPtR

2 )可靠性的分析mdashmdash可靠度

可靠度函数

依定义可知可靠度函数 R(t) 为

式中 N0 mdashmdash t = 0 时在规定条件下进行工作的产品数

r(t) mdashmdash  在 0 到 t 时刻的工作时间内产品的累计

故障数

0

0 )()(

N

trNtR

累积故障分布函数 产品在规定的条件下和规定的时间内丧失

规定功能的概率称为累积故障概率(又叫不可靠度) 依定义可知产品的累积故障概率是时间的函

数即

显然以下关系成立

0

)()(

N

trtF

1)()( tFtR

可靠度函数与累积故障分布函数的性质

图 R(t)F(t)与f(t)的关系t

f(t)

f(t)

F(to)

R(to)

to

由密度函数的性质 1)(0

dttf 可知

t

tdttfdttftFtR )()(1)(1)(

0

因此 R(t) F(t) 与 f(t) 之间的关系如图所示

故障率函数 故障率

工作到某时刻尚未发生故障的产品在该时刻后单位时间内发生故障的概率称之为产品的故障率

用数学符号表示为

式中 (t) mdashmdash 故障率 dr(t) mdashmdash t 时刻后 dt 时间内故障的产品数 Ns(t) mdashmdash 残存产品数即到 t 时刻尚未故障的产品

dttN

tdrt

s )(

)()(

35

故障率函数

可按下式进行工程计算

式中 Δr(t) mdashmdash t 时刻后 Δt 时间内故障的产品数

Δt mdashmdash 所取时间间隔 Ns(t) mdashmdash 残存产品数

对于低故障率的元部件常以 10-9h 为故障率的单位称之为菲特( Fit )

ttN

trt

s

)(

)()(

产品故障浴盆曲线 浴盆曲线

大多数产品的故障率随时间的变化曲线形似浴盆称之为浴盆曲线由于产品故障机理的不同产品的故障率随时间的变化大致可以分为三个阶段

产品典型的故障率曲线

t

使用寿命

早期故障

偶然故障 耗损故障

A B规定的故障率 维修后故障率下降

(t)

3 )纠错技术( 1 )纠错码 在 1950s就开始研究最早的是可以检测和纠错的汉明码它们通过数字系统广泛地用于识别和纠正短暂或者持久的错误这些码引入冗余信息来确保一些类型的错误可以被检测和纠正比如一个单错校正 双错校正的码能用一个比特检测和纠正一个错误但是不能用两个比特纠错

( 2 )三模冗余 (triple modular

redundancy) 计算单元 C 有三个副本 C1C2和 C3三个单元接收同

样的输入一个独立单元比较每个输入的结果如果至少两个结果一致那么那个值被表决器选做正确结果如果三个结果都不相同那么就没有正确的结果

1C

2C

3C

表决错误

结果

输入

( 3 )看门狗定时器 (watchdog timer)

看门狗定时器 (watchdog timer)被广泛地用于检测系统问题如图 看门狗定时器连接到一个监视系统如果这个看门狗定时器翻转它产生一个完成信号用于标注系统的错误中断系统应该这样设计当适当运行的时候它一直在可能产生翻转信号之前复位定时器因此来自看门狗定时器的完成信号指示系统在一定程度上不合适地操作看门狗定时器用于预防不同的故障

系统看门狗定时器

完成

复位

( 4 )设计多样性 (Design diversity)

一种用于减少一些系统错误进入设计的设计方法学当一个设计需要给定模块的不同实例应该采用模块的不同实现而不是到处都用同一种模块比如一个有多个 CPU的系统可能采用不同类型的 CPU而不是到处采用同一种类型的 CPU在一个三模冗余系统产生表决结构的组件可能有不同的实现这样可以减少产生同样设计错误的机会

4 )软件可靠性ldquo在规定的条件下在规定的时间内软件不引起失效的概率rdquo

规定的条件 软件运行的软硬件环境 软件操作剖面软件运行的输入空间及其概率分布

规定的时间 日历时间 时钟时间 执行时间

激活软件 输入域 缺陷的数据

软件缺陷 软件

不可接受的结果 (软件故障) 输出域

软件故障的特点

软件与硬件可靠性的区别硬件 软件

故障机理 老化损耗 残留缺陷在一定环境下造成的软件错误

复杂性 内部逻辑较为简单 内部逻辑高度复杂这就在很大程度上决定了设计错误是导致软件故障的主要原因

唯一性 任何两个硬件不可能绝对相同

软件是唯一的软件拷贝不改变软件本身

可靠性的核心 内部元部件 设计者的思维和软件的复杂性纠错维护方法 修复或更换失效的元部件 重设计 可靠性检验标准化

已标准化且有一整套完整的理论

仍未建立更没有完整的理论体系

产品市场 已有成熟的产品市场 产品市场还很新 错误性质 一些瞬间的硬件错误可能

会被误认为是软件错误 软件错误是永恒的可重现的

影响软件可靠性的因素( 1 )运行环境 ( 剖面 )

同一软件在不同运行剖面下其可靠性行为可能极不相同 软件故障是软件缺陷在一定输入情况下被激活的结果 假设软件输入域划分为两个部分 G 和 F 运行剖面不包含 F 中

的输入则软件不会出现故障其可靠性恒为 l 反之如果运行剖面不包含 G 中的输入则每一输入情况下均出现故障如果没有容错措施则 R=0

( 2 )软件规模 随着软件规模的增大软件可靠性问题愈显突出在我们考虑软件

可靠性问题时软件一般是指中型以上软件 (4000-5000条以上语句 ) 这时可靠性问题难以对付

软件工程实践的一个侧面可以反映这一点即单元测试一般由编程人员本人进行而综合测试则需独立的测试人员

影响软件可靠性的因素( 3 )软件内部结构

结构越复杂软件复杂度越高内含缺陷数越大因而软件可靠度越低

( 4 )软件可靠性设计技术 一般是指软件设计阶段中采用的用以保证和提高软件可靠性为主要目标的软件技术

( 5 )软件可靠性测试 研究表明软件测试方法与资源投入对软件可靠性有不可忽视的影

响( 6 )软件可靠性管理

软件可靠性管理旨在系统管理软件生存期各阶段的可靠性活动使之系统化规范化一体化这样就可以避免许多人为错误以提高软件可靠性

影响软件可靠性的因素( 7 )软件开发人员能力和经验

软件开发人员 ( 包括测试人员 ) 的能力愈强经验愈丰富所犯错误便可能愈少所得软件产品质量愈高相应的可靠性也愈高

( 8 )软件开发方法 软件工程表明开发方法对软件可靠性有显著影响 与非结构化方法比较结构化方法可以明显减少软件缺陷数

( 9 )软件开发环境 研究表明程序语言软件开发环境影响软件的可靠性而软件测

试工具的优劣则影响可靠性测试结果

4 安全 (Safety)amp保密 (Security)

安全 (Safety) 是保证财产和人身受到损害可靠性是指在一定的环境条件下以及一定的时间内系统完成特定任务的可能性而有效性则是系统的长期的工作时间于其存在时间 ( 简单的定义为运行时间 +维护时间 ) 的 比例保密 (Security) 是针对危险破坏损失或非法活动而进行措施在一定层面上保密 (Security)要比安全 (Safety)宽广的多例如信息 Security家庭 Security 网络 Security 国家Security) 等

Security强调的是外在事物对特定目标的危害

Safety 是系统本身的潜在危害

四个概念的比较分析安全 (Safety)可靠性 (Reliability)有效性 (Availability)保密 (Security )安全 (Safety)高的系统 软件可靠性不

一定高可靠性和有效性并不是一码事保密 (Security )的系统 软件是安全

(Safety) 系统 软件的重要保障

可靠性安全性保密性 可靠(或可信)系统设计 (Reliable (or dependable) system design)是制造嵌入式系统所关注的甚至在面对内部或者外部问题时可靠系统设计经常假设问题是非恶意引起的

安全重要的系统设计 (Safety-critical system design)研究确保系统安全操作的方法独立于引起问题的原因

保密性 (Security)主要关注恶意攻击

Aizientis等人描述了可信性和保密性间的关系可信性和保密性由几个特性所组成

服务的可用性 (Availability) 服务的连续性 (Continuity) 来自用户和所处环境的灾难性后果的安全性 (Safety) 来自不合适系统改变的完整性 (Integrity) 通过更改和修补的可维护性 (Maintainability) 信息的机密性 (Confidentiality)

可用性完整性

可靠性安全性可维护性

机密性

可信性 保密性

5 新型攻击和对策1 )物理攻击嵌入式系统比通用计算机更容易受攻击 一个关键原因是许多嵌入式计算机对攻击者可物理访问

2 )互联网攻击一些嵌入式系统的攻击通过互联网访问变得更加容易今天许多嵌入式系统连接到互联网

3 )电池攻击 (battery attack)这种攻击试图通过耗尽电池来关闭节点

4 )服务拒绝攻击 (Denial-of-service attacks)

在通用系统中众所周知但是实时嵌入式系统可能更容易受服务质量 (quality-of-service (QoS))攻击如果网络发布实时数据那么发送过程中的一点延迟都能引起数据无效如果那些数据用来实时控制那么这些短暂延迟就能引起系统故障我们称这种危害为时间攻击因为它改变了系统的实时特性

QoS或者时间攻击之所以强大使因为它的影响不仅仅限于信息被控制系统的动态特性可决定系统的响应如果一个大型沉重快速运动的系统被控制那么时间上一个相对小的改变能引起大量的破坏

5 )网络(协议)攻击Wood和 Stankovic[Woo02]在传感器网络上确定了一些方式这些方式可在网络层次的不同层执行拒绝服务攻击如下所列

物理层 (Physical layer)mdashmdash拥塞破坏 链路层 (Link layer)mdashmdash碰撞耗尽非公平

网络和路由层 (Network and routing layer)mdashmdash丢弃和贪婪汇集方向误导黑洞认证监视冗余

传输层 (Transport layer)mdashmdash泛洪失步

6 )能量攻击Kocher等人 [Koc99]指出测量一个 CPU当前的能量供给能在很大程度上确定处理器的内部活动他们提出了两种能量攻击的方法简单能量分析 (simple power analysis)人工地跟踪检查和尝试确定程序作用的位置比如分支基于不同 CUP操作的能耗知识基于程序作用攻击者然后减少密钥的比特差分能量分析 (Differential power analysis)用相关性确定作用和密钥比特这种攻击最初目标是智能卡这种卡从外部读卡器获取能量但是这种攻击也能应用到许多嵌入式系统中

7 )反攻击 在一些时候有可能构造反破坏的嵌入式系统使电子设备难以发觉和分析延缓了攻击者芯片中有限的信息也有助阻止攻击者发现数据

6 Efficiency (效率)

ES must be efficient

bull Code-size efficient( 特别是片上系统 )

bull Run-time efficient

bull Weight efficient

bull Cost efficient

bull Energy efficient

能量有效性的重要意义

ldquoinherent power

efficiency of siliconldquo

59

低功耗设计问题 功耗问题是近几年来人们在嵌入式系统的设计中普遍关注的难点和热点它严重地制约着嵌入式系统的应用与发展

无论是在军事还是在商业贸易上的应用相当数量的嵌入式系统一般是由电池来供给电能的而且大多数嵌入式设备都有体积和质量的约束减少电能消耗不仅能延长电池的使用寿命延长用户更换电池的周期而且能带来提高系统性能与降低系统开销的好处甚至能起到保护环境的作用在便携式设备中 CPU消耗的电能越少电池的寿命就越长同时散发的热量少了所需的散热器就少了从而可减少该设备的花费和体积使产品尽快进入市场的目标

1 低功耗嵌入式应用系统是指以降低系统功耗为一个主要性能指标的嵌入式系统如计算机里的许多芯片过去用 5V供电现在用 33V 18V 并提出了绿色电器的概念

60

低功耗设备的要求1 )首先要求体积小重量轻便于携带2 )采用低功耗电路的设计方法以降低系统的功耗

它除了选用各种低功耗的器件和芯片外还在满足速度等性能指标的前提下进行降低功耗的硬件电路设计和软件设计

3 )有的系统应用在交流供电比较困难甚至无法用交流供电的场合因而各种电池(瓶)就成为其主要供电手段

4 )采用 LCD液晶显示器5 )采用 RS232C串行通信接口6 )采用微功耗高抗干扰的 CMOS集成电路

功耗产生的原因 P=UI

与功耗有关的因素

( 1 )电阻上消耗的功率( 2 )有源器件的开关转换阶段( 3 )集成电路内部和外部电容的充放电( 4 )系统的性能指标负载能力被处理信号的工作频率电路的工作频率电源的管理水平零部件的性能散热条件接口的物理性能等对系统功耗起着重要的作用

降低功耗的措施

功耗的组成动态 + 静态动态电源管理动态电压缩放低功耗硬件设计低功耗软件设计

二设计方法学概论

问题功 能 性能要求价 格 开发 周 期 等约束

设计 选择 折衷 分析比较 计算 评价

嵌入式系统

0嵌入式系统设计概述

方法 工具

设计方法论( design methodology )

设计方法论有以下三个重要理由1 )确认我们所做的每一件事情都是必须要作的

不会做无谓的白工也不会漏掉关键性的重要工作其中包含效率优化或是功能测试

2 )可以发展出计算机辅助工具或是设计经验累积汲取每一次产品发展的经验再经过量化之后可以发展出一套工具或是方法让往后的产品设计步入自动化

3 )开发团队遵循同一套方法论可以让团队成员更容易彼此沟通每个人都能在短时间内了解整体过程中将经历哪些过程需要何种支持与接收到何种结果此外也容易透过一套已经定义好的方法论彼此相互合作协调

设计目标 1 )上市时间

也就是 time-to-market 的观念2 )设计成本

许多消费性产品对于价格非常敏感所以产品厂商对于成本会斤斤计较是很合理的

3 )品质 顾客也许不需要最快最便宜的产品但是一定会要求功能质量保证不能只用一小段时间就坏掉了

传统的设计主要步骤

2 传统的设计流程方法1 )瀑布模型 (Waterfall)2 )螺旋模型 (Spiral)3 )连续改进 (Successive Refinement)4 )硬件与软件的同步设计 (SWHW Co-

deign)5 )阶层式 (Hierarchical) 设计6 )同步工程( concurrent

engineering )

瀑布模型 (Waterfall)

螺旋模型 (Spiral)

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 27: 大学计算机基础 —— 计算机科学概论

1 )故障 (faults) 分析永久 (permanent) 与暂时( transient )故障故障来源 物理故障 (Physical faults)由生产缺陷辐射危害等等引起

设计故障 (Design faults) 是不合适设计的系统的结果

操作故障 (Operational faults) 来自人为过失安全破坏劣质设计的人机接口等等

可靠性设计

故障及其分类 产品的故障按其故障规律分为两大类

偶然故障 渐变故障

产品的故障按其故障后果分为两大类 致命性故障 非致命性故障

产品的故障按其统计特性分为两大类 独立故障 从属故障

可靠度 产品在规定的条件下和规定的时间内完成规

定功能的概率称为可靠度依定义可知系统的可靠度是时间的函数表示为

式中 R(t)mdashmdash 可靠度函数 ξmdashmdash 产生故障前的工作时间 t mdashmdash 规定的时间

)()( tPtR

2 )可靠性的分析mdashmdash可靠度

可靠度函数

依定义可知可靠度函数 R(t) 为

式中 N0 mdashmdash t = 0 时在规定条件下进行工作的产品数

r(t) mdashmdash  在 0 到 t 时刻的工作时间内产品的累计

故障数

0

0 )()(

N

trNtR

累积故障分布函数 产品在规定的条件下和规定的时间内丧失

规定功能的概率称为累积故障概率(又叫不可靠度) 依定义可知产品的累积故障概率是时间的函

数即

显然以下关系成立

0

)()(

N

trtF

1)()( tFtR

可靠度函数与累积故障分布函数的性质

图 R(t)F(t)与f(t)的关系t

f(t)

f(t)

F(to)

R(to)

to

由密度函数的性质 1)(0

dttf 可知

t

tdttfdttftFtR )()(1)(1)(

0

因此 R(t) F(t) 与 f(t) 之间的关系如图所示

故障率函数 故障率

工作到某时刻尚未发生故障的产品在该时刻后单位时间内发生故障的概率称之为产品的故障率

用数学符号表示为

式中 (t) mdashmdash 故障率 dr(t) mdashmdash t 时刻后 dt 时间内故障的产品数 Ns(t) mdashmdash 残存产品数即到 t 时刻尚未故障的产品

dttN

tdrt

s )(

)()(

35

故障率函数

可按下式进行工程计算

式中 Δr(t) mdashmdash t 时刻后 Δt 时间内故障的产品数

Δt mdashmdash 所取时间间隔 Ns(t) mdashmdash 残存产品数

对于低故障率的元部件常以 10-9h 为故障率的单位称之为菲特( Fit )

ttN

trt

s

)(

)()(

产品故障浴盆曲线 浴盆曲线

大多数产品的故障率随时间的变化曲线形似浴盆称之为浴盆曲线由于产品故障机理的不同产品的故障率随时间的变化大致可以分为三个阶段

产品典型的故障率曲线

t

使用寿命

早期故障

偶然故障 耗损故障

A B规定的故障率 维修后故障率下降

(t)

3 )纠错技术( 1 )纠错码 在 1950s就开始研究最早的是可以检测和纠错的汉明码它们通过数字系统广泛地用于识别和纠正短暂或者持久的错误这些码引入冗余信息来确保一些类型的错误可以被检测和纠正比如一个单错校正 双错校正的码能用一个比特检测和纠正一个错误但是不能用两个比特纠错

( 2 )三模冗余 (triple modular

redundancy) 计算单元 C 有三个副本 C1C2和 C3三个单元接收同

样的输入一个独立单元比较每个输入的结果如果至少两个结果一致那么那个值被表决器选做正确结果如果三个结果都不相同那么就没有正确的结果

1C

2C

3C

表决错误

结果

输入

( 3 )看门狗定时器 (watchdog timer)

看门狗定时器 (watchdog timer)被广泛地用于检测系统问题如图 看门狗定时器连接到一个监视系统如果这个看门狗定时器翻转它产生一个完成信号用于标注系统的错误中断系统应该这样设计当适当运行的时候它一直在可能产生翻转信号之前复位定时器因此来自看门狗定时器的完成信号指示系统在一定程度上不合适地操作看门狗定时器用于预防不同的故障

系统看门狗定时器

完成

复位

( 4 )设计多样性 (Design diversity)

一种用于减少一些系统错误进入设计的设计方法学当一个设计需要给定模块的不同实例应该采用模块的不同实现而不是到处都用同一种模块比如一个有多个 CPU的系统可能采用不同类型的 CPU而不是到处采用同一种类型的 CPU在一个三模冗余系统产生表决结构的组件可能有不同的实现这样可以减少产生同样设计错误的机会

4 )软件可靠性ldquo在规定的条件下在规定的时间内软件不引起失效的概率rdquo

规定的条件 软件运行的软硬件环境 软件操作剖面软件运行的输入空间及其概率分布

规定的时间 日历时间 时钟时间 执行时间

激活软件 输入域 缺陷的数据

软件缺陷 软件

不可接受的结果 (软件故障) 输出域

软件故障的特点

软件与硬件可靠性的区别硬件 软件

故障机理 老化损耗 残留缺陷在一定环境下造成的软件错误

复杂性 内部逻辑较为简单 内部逻辑高度复杂这就在很大程度上决定了设计错误是导致软件故障的主要原因

唯一性 任何两个硬件不可能绝对相同

软件是唯一的软件拷贝不改变软件本身

可靠性的核心 内部元部件 设计者的思维和软件的复杂性纠错维护方法 修复或更换失效的元部件 重设计 可靠性检验标准化

已标准化且有一整套完整的理论

仍未建立更没有完整的理论体系

产品市场 已有成熟的产品市场 产品市场还很新 错误性质 一些瞬间的硬件错误可能

会被误认为是软件错误 软件错误是永恒的可重现的

影响软件可靠性的因素( 1 )运行环境 ( 剖面 )

同一软件在不同运行剖面下其可靠性行为可能极不相同 软件故障是软件缺陷在一定输入情况下被激活的结果 假设软件输入域划分为两个部分 G 和 F 运行剖面不包含 F 中

的输入则软件不会出现故障其可靠性恒为 l 反之如果运行剖面不包含 G 中的输入则每一输入情况下均出现故障如果没有容错措施则 R=0

( 2 )软件规模 随着软件规模的增大软件可靠性问题愈显突出在我们考虑软件

可靠性问题时软件一般是指中型以上软件 (4000-5000条以上语句 ) 这时可靠性问题难以对付

软件工程实践的一个侧面可以反映这一点即单元测试一般由编程人员本人进行而综合测试则需独立的测试人员

影响软件可靠性的因素( 3 )软件内部结构

结构越复杂软件复杂度越高内含缺陷数越大因而软件可靠度越低

( 4 )软件可靠性设计技术 一般是指软件设计阶段中采用的用以保证和提高软件可靠性为主要目标的软件技术

( 5 )软件可靠性测试 研究表明软件测试方法与资源投入对软件可靠性有不可忽视的影

响( 6 )软件可靠性管理

软件可靠性管理旨在系统管理软件生存期各阶段的可靠性活动使之系统化规范化一体化这样就可以避免许多人为错误以提高软件可靠性

影响软件可靠性的因素( 7 )软件开发人员能力和经验

软件开发人员 ( 包括测试人员 ) 的能力愈强经验愈丰富所犯错误便可能愈少所得软件产品质量愈高相应的可靠性也愈高

( 8 )软件开发方法 软件工程表明开发方法对软件可靠性有显著影响 与非结构化方法比较结构化方法可以明显减少软件缺陷数

( 9 )软件开发环境 研究表明程序语言软件开发环境影响软件的可靠性而软件测

试工具的优劣则影响可靠性测试结果

4 安全 (Safety)amp保密 (Security)

安全 (Safety) 是保证财产和人身受到损害可靠性是指在一定的环境条件下以及一定的时间内系统完成特定任务的可能性而有效性则是系统的长期的工作时间于其存在时间 ( 简单的定义为运行时间 +维护时间 ) 的 比例保密 (Security) 是针对危险破坏损失或非法活动而进行措施在一定层面上保密 (Security)要比安全 (Safety)宽广的多例如信息 Security家庭 Security 网络 Security 国家Security) 等

Security强调的是外在事物对特定目标的危害

Safety 是系统本身的潜在危害

四个概念的比较分析安全 (Safety)可靠性 (Reliability)有效性 (Availability)保密 (Security )安全 (Safety)高的系统 软件可靠性不

一定高可靠性和有效性并不是一码事保密 (Security )的系统 软件是安全

(Safety) 系统 软件的重要保障

可靠性安全性保密性 可靠(或可信)系统设计 (Reliable (or dependable) system design)是制造嵌入式系统所关注的甚至在面对内部或者外部问题时可靠系统设计经常假设问题是非恶意引起的

安全重要的系统设计 (Safety-critical system design)研究确保系统安全操作的方法独立于引起问题的原因

保密性 (Security)主要关注恶意攻击

Aizientis等人描述了可信性和保密性间的关系可信性和保密性由几个特性所组成

服务的可用性 (Availability) 服务的连续性 (Continuity) 来自用户和所处环境的灾难性后果的安全性 (Safety) 来自不合适系统改变的完整性 (Integrity) 通过更改和修补的可维护性 (Maintainability) 信息的机密性 (Confidentiality)

可用性完整性

可靠性安全性可维护性

机密性

可信性 保密性

5 新型攻击和对策1 )物理攻击嵌入式系统比通用计算机更容易受攻击 一个关键原因是许多嵌入式计算机对攻击者可物理访问

2 )互联网攻击一些嵌入式系统的攻击通过互联网访问变得更加容易今天许多嵌入式系统连接到互联网

3 )电池攻击 (battery attack)这种攻击试图通过耗尽电池来关闭节点

4 )服务拒绝攻击 (Denial-of-service attacks)

在通用系统中众所周知但是实时嵌入式系统可能更容易受服务质量 (quality-of-service (QoS))攻击如果网络发布实时数据那么发送过程中的一点延迟都能引起数据无效如果那些数据用来实时控制那么这些短暂延迟就能引起系统故障我们称这种危害为时间攻击因为它改变了系统的实时特性

QoS或者时间攻击之所以强大使因为它的影响不仅仅限于信息被控制系统的动态特性可决定系统的响应如果一个大型沉重快速运动的系统被控制那么时间上一个相对小的改变能引起大量的破坏

5 )网络(协议)攻击Wood和 Stankovic[Woo02]在传感器网络上确定了一些方式这些方式可在网络层次的不同层执行拒绝服务攻击如下所列

物理层 (Physical layer)mdashmdash拥塞破坏 链路层 (Link layer)mdashmdash碰撞耗尽非公平

网络和路由层 (Network and routing layer)mdashmdash丢弃和贪婪汇集方向误导黑洞认证监视冗余

传输层 (Transport layer)mdashmdash泛洪失步

6 )能量攻击Kocher等人 [Koc99]指出测量一个 CPU当前的能量供给能在很大程度上确定处理器的内部活动他们提出了两种能量攻击的方法简单能量分析 (simple power analysis)人工地跟踪检查和尝试确定程序作用的位置比如分支基于不同 CUP操作的能耗知识基于程序作用攻击者然后减少密钥的比特差分能量分析 (Differential power analysis)用相关性确定作用和密钥比特这种攻击最初目标是智能卡这种卡从外部读卡器获取能量但是这种攻击也能应用到许多嵌入式系统中

7 )反攻击 在一些时候有可能构造反破坏的嵌入式系统使电子设备难以发觉和分析延缓了攻击者芯片中有限的信息也有助阻止攻击者发现数据

6 Efficiency (效率)

ES must be efficient

bull Code-size efficient( 特别是片上系统 )

bull Run-time efficient

bull Weight efficient

bull Cost efficient

bull Energy efficient

能量有效性的重要意义

ldquoinherent power

efficiency of siliconldquo

59

低功耗设计问题 功耗问题是近几年来人们在嵌入式系统的设计中普遍关注的难点和热点它严重地制约着嵌入式系统的应用与发展

无论是在军事还是在商业贸易上的应用相当数量的嵌入式系统一般是由电池来供给电能的而且大多数嵌入式设备都有体积和质量的约束减少电能消耗不仅能延长电池的使用寿命延长用户更换电池的周期而且能带来提高系统性能与降低系统开销的好处甚至能起到保护环境的作用在便携式设备中 CPU消耗的电能越少电池的寿命就越长同时散发的热量少了所需的散热器就少了从而可减少该设备的花费和体积使产品尽快进入市场的目标

1 低功耗嵌入式应用系统是指以降低系统功耗为一个主要性能指标的嵌入式系统如计算机里的许多芯片过去用 5V供电现在用 33V 18V 并提出了绿色电器的概念

60

低功耗设备的要求1 )首先要求体积小重量轻便于携带2 )采用低功耗电路的设计方法以降低系统的功耗

它除了选用各种低功耗的器件和芯片外还在满足速度等性能指标的前提下进行降低功耗的硬件电路设计和软件设计

3 )有的系统应用在交流供电比较困难甚至无法用交流供电的场合因而各种电池(瓶)就成为其主要供电手段

4 )采用 LCD液晶显示器5 )采用 RS232C串行通信接口6 )采用微功耗高抗干扰的 CMOS集成电路

功耗产生的原因 P=UI

与功耗有关的因素

( 1 )电阻上消耗的功率( 2 )有源器件的开关转换阶段( 3 )集成电路内部和外部电容的充放电( 4 )系统的性能指标负载能力被处理信号的工作频率电路的工作频率电源的管理水平零部件的性能散热条件接口的物理性能等对系统功耗起着重要的作用

降低功耗的措施

功耗的组成动态 + 静态动态电源管理动态电压缩放低功耗硬件设计低功耗软件设计

二设计方法学概论

问题功 能 性能要求价 格 开发 周 期 等约束

设计 选择 折衷 分析比较 计算 评价

嵌入式系统

0嵌入式系统设计概述

方法 工具

设计方法论( design methodology )

设计方法论有以下三个重要理由1 )确认我们所做的每一件事情都是必须要作的

不会做无谓的白工也不会漏掉关键性的重要工作其中包含效率优化或是功能测试

2 )可以发展出计算机辅助工具或是设计经验累积汲取每一次产品发展的经验再经过量化之后可以发展出一套工具或是方法让往后的产品设计步入自动化

3 )开发团队遵循同一套方法论可以让团队成员更容易彼此沟通每个人都能在短时间内了解整体过程中将经历哪些过程需要何种支持与接收到何种结果此外也容易透过一套已经定义好的方法论彼此相互合作协调

设计目标 1 )上市时间

也就是 time-to-market 的观念2 )设计成本

许多消费性产品对于价格非常敏感所以产品厂商对于成本会斤斤计较是很合理的

3 )品质 顾客也许不需要最快最便宜的产品但是一定会要求功能质量保证不能只用一小段时间就坏掉了

传统的设计主要步骤

2 传统的设计流程方法1 )瀑布模型 (Waterfall)2 )螺旋模型 (Spiral)3 )连续改进 (Successive Refinement)4 )硬件与软件的同步设计 (SWHW Co-

deign)5 )阶层式 (Hierarchical) 设计6 )同步工程( concurrent

engineering )

瀑布模型 (Waterfall)

螺旋模型 (Spiral)

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 28: 大学计算机基础 —— 计算机科学概论

可靠性设计

故障及其分类 产品的故障按其故障规律分为两大类

偶然故障 渐变故障

产品的故障按其故障后果分为两大类 致命性故障 非致命性故障

产品的故障按其统计特性分为两大类 独立故障 从属故障

可靠度 产品在规定的条件下和规定的时间内完成规

定功能的概率称为可靠度依定义可知系统的可靠度是时间的函数表示为

式中 R(t)mdashmdash 可靠度函数 ξmdashmdash 产生故障前的工作时间 t mdashmdash 规定的时间

)()( tPtR

2 )可靠性的分析mdashmdash可靠度

可靠度函数

依定义可知可靠度函数 R(t) 为

式中 N0 mdashmdash t = 0 时在规定条件下进行工作的产品数

r(t) mdashmdash  在 0 到 t 时刻的工作时间内产品的累计

故障数

0

0 )()(

N

trNtR

累积故障分布函数 产品在规定的条件下和规定的时间内丧失

规定功能的概率称为累积故障概率(又叫不可靠度) 依定义可知产品的累积故障概率是时间的函

数即

显然以下关系成立

0

)()(

N

trtF

1)()( tFtR

可靠度函数与累积故障分布函数的性质

图 R(t)F(t)与f(t)的关系t

f(t)

f(t)

F(to)

R(to)

to

由密度函数的性质 1)(0

dttf 可知

t

tdttfdttftFtR )()(1)(1)(

0

因此 R(t) F(t) 与 f(t) 之间的关系如图所示

故障率函数 故障率

工作到某时刻尚未发生故障的产品在该时刻后单位时间内发生故障的概率称之为产品的故障率

用数学符号表示为

式中 (t) mdashmdash 故障率 dr(t) mdashmdash t 时刻后 dt 时间内故障的产品数 Ns(t) mdashmdash 残存产品数即到 t 时刻尚未故障的产品

dttN

tdrt

s )(

)()(

35

故障率函数

可按下式进行工程计算

式中 Δr(t) mdashmdash t 时刻后 Δt 时间内故障的产品数

Δt mdashmdash 所取时间间隔 Ns(t) mdashmdash 残存产品数

对于低故障率的元部件常以 10-9h 为故障率的单位称之为菲特( Fit )

ttN

trt

s

)(

)()(

产品故障浴盆曲线 浴盆曲线

大多数产品的故障率随时间的变化曲线形似浴盆称之为浴盆曲线由于产品故障机理的不同产品的故障率随时间的变化大致可以分为三个阶段

产品典型的故障率曲线

t

使用寿命

早期故障

偶然故障 耗损故障

A B规定的故障率 维修后故障率下降

(t)

3 )纠错技术( 1 )纠错码 在 1950s就开始研究最早的是可以检测和纠错的汉明码它们通过数字系统广泛地用于识别和纠正短暂或者持久的错误这些码引入冗余信息来确保一些类型的错误可以被检测和纠正比如一个单错校正 双错校正的码能用一个比特检测和纠正一个错误但是不能用两个比特纠错

( 2 )三模冗余 (triple modular

redundancy) 计算单元 C 有三个副本 C1C2和 C3三个单元接收同

样的输入一个独立单元比较每个输入的结果如果至少两个结果一致那么那个值被表决器选做正确结果如果三个结果都不相同那么就没有正确的结果

1C

2C

3C

表决错误

结果

输入

( 3 )看门狗定时器 (watchdog timer)

看门狗定时器 (watchdog timer)被广泛地用于检测系统问题如图 看门狗定时器连接到一个监视系统如果这个看门狗定时器翻转它产生一个完成信号用于标注系统的错误中断系统应该这样设计当适当运行的时候它一直在可能产生翻转信号之前复位定时器因此来自看门狗定时器的完成信号指示系统在一定程度上不合适地操作看门狗定时器用于预防不同的故障

系统看门狗定时器

完成

复位

( 4 )设计多样性 (Design diversity)

一种用于减少一些系统错误进入设计的设计方法学当一个设计需要给定模块的不同实例应该采用模块的不同实现而不是到处都用同一种模块比如一个有多个 CPU的系统可能采用不同类型的 CPU而不是到处采用同一种类型的 CPU在一个三模冗余系统产生表决结构的组件可能有不同的实现这样可以减少产生同样设计错误的机会

4 )软件可靠性ldquo在规定的条件下在规定的时间内软件不引起失效的概率rdquo

规定的条件 软件运行的软硬件环境 软件操作剖面软件运行的输入空间及其概率分布

规定的时间 日历时间 时钟时间 执行时间

激活软件 输入域 缺陷的数据

软件缺陷 软件

不可接受的结果 (软件故障) 输出域

软件故障的特点

软件与硬件可靠性的区别硬件 软件

故障机理 老化损耗 残留缺陷在一定环境下造成的软件错误

复杂性 内部逻辑较为简单 内部逻辑高度复杂这就在很大程度上决定了设计错误是导致软件故障的主要原因

唯一性 任何两个硬件不可能绝对相同

软件是唯一的软件拷贝不改变软件本身

可靠性的核心 内部元部件 设计者的思维和软件的复杂性纠错维护方法 修复或更换失效的元部件 重设计 可靠性检验标准化

已标准化且有一整套完整的理论

仍未建立更没有完整的理论体系

产品市场 已有成熟的产品市场 产品市场还很新 错误性质 一些瞬间的硬件错误可能

会被误认为是软件错误 软件错误是永恒的可重现的

影响软件可靠性的因素( 1 )运行环境 ( 剖面 )

同一软件在不同运行剖面下其可靠性行为可能极不相同 软件故障是软件缺陷在一定输入情况下被激活的结果 假设软件输入域划分为两个部分 G 和 F 运行剖面不包含 F 中

的输入则软件不会出现故障其可靠性恒为 l 反之如果运行剖面不包含 G 中的输入则每一输入情况下均出现故障如果没有容错措施则 R=0

( 2 )软件规模 随着软件规模的增大软件可靠性问题愈显突出在我们考虑软件

可靠性问题时软件一般是指中型以上软件 (4000-5000条以上语句 ) 这时可靠性问题难以对付

软件工程实践的一个侧面可以反映这一点即单元测试一般由编程人员本人进行而综合测试则需独立的测试人员

影响软件可靠性的因素( 3 )软件内部结构

结构越复杂软件复杂度越高内含缺陷数越大因而软件可靠度越低

( 4 )软件可靠性设计技术 一般是指软件设计阶段中采用的用以保证和提高软件可靠性为主要目标的软件技术

( 5 )软件可靠性测试 研究表明软件测试方法与资源投入对软件可靠性有不可忽视的影

响( 6 )软件可靠性管理

软件可靠性管理旨在系统管理软件生存期各阶段的可靠性活动使之系统化规范化一体化这样就可以避免许多人为错误以提高软件可靠性

影响软件可靠性的因素( 7 )软件开发人员能力和经验

软件开发人员 ( 包括测试人员 ) 的能力愈强经验愈丰富所犯错误便可能愈少所得软件产品质量愈高相应的可靠性也愈高

( 8 )软件开发方法 软件工程表明开发方法对软件可靠性有显著影响 与非结构化方法比较结构化方法可以明显减少软件缺陷数

( 9 )软件开发环境 研究表明程序语言软件开发环境影响软件的可靠性而软件测

试工具的优劣则影响可靠性测试结果

4 安全 (Safety)amp保密 (Security)

安全 (Safety) 是保证财产和人身受到损害可靠性是指在一定的环境条件下以及一定的时间内系统完成特定任务的可能性而有效性则是系统的长期的工作时间于其存在时间 ( 简单的定义为运行时间 +维护时间 ) 的 比例保密 (Security) 是针对危险破坏损失或非法活动而进行措施在一定层面上保密 (Security)要比安全 (Safety)宽广的多例如信息 Security家庭 Security 网络 Security 国家Security) 等

Security强调的是外在事物对特定目标的危害

Safety 是系统本身的潜在危害

四个概念的比较分析安全 (Safety)可靠性 (Reliability)有效性 (Availability)保密 (Security )安全 (Safety)高的系统 软件可靠性不

一定高可靠性和有效性并不是一码事保密 (Security )的系统 软件是安全

(Safety) 系统 软件的重要保障

可靠性安全性保密性 可靠(或可信)系统设计 (Reliable (or dependable) system design)是制造嵌入式系统所关注的甚至在面对内部或者外部问题时可靠系统设计经常假设问题是非恶意引起的

安全重要的系统设计 (Safety-critical system design)研究确保系统安全操作的方法独立于引起问题的原因

保密性 (Security)主要关注恶意攻击

Aizientis等人描述了可信性和保密性间的关系可信性和保密性由几个特性所组成

服务的可用性 (Availability) 服务的连续性 (Continuity) 来自用户和所处环境的灾难性后果的安全性 (Safety) 来自不合适系统改变的完整性 (Integrity) 通过更改和修补的可维护性 (Maintainability) 信息的机密性 (Confidentiality)

可用性完整性

可靠性安全性可维护性

机密性

可信性 保密性

5 新型攻击和对策1 )物理攻击嵌入式系统比通用计算机更容易受攻击 一个关键原因是许多嵌入式计算机对攻击者可物理访问

2 )互联网攻击一些嵌入式系统的攻击通过互联网访问变得更加容易今天许多嵌入式系统连接到互联网

3 )电池攻击 (battery attack)这种攻击试图通过耗尽电池来关闭节点

4 )服务拒绝攻击 (Denial-of-service attacks)

在通用系统中众所周知但是实时嵌入式系统可能更容易受服务质量 (quality-of-service (QoS))攻击如果网络发布实时数据那么发送过程中的一点延迟都能引起数据无效如果那些数据用来实时控制那么这些短暂延迟就能引起系统故障我们称这种危害为时间攻击因为它改变了系统的实时特性

QoS或者时间攻击之所以强大使因为它的影响不仅仅限于信息被控制系统的动态特性可决定系统的响应如果一个大型沉重快速运动的系统被控制那么时间上一个相对小的改变能引起大量的破坏

5 )网络(协议)攻击Wood和 Stankovic[Woo02]在传感器网络上确定了一些方式这些方式可在网络层次的不同层执行拒绝服务攻击如下所列

物理层 (Physical layer)mdashmdash拥塞破坏 链路层 (Link layer)mdashmdash碰撞耗尽非公平

网络和路由层 (Network and routing layer)mdashmdash丢弃和贪婪汇集方向误导黑洞认证监视冗余

传输层 (Transport layer)mdashmdash泛洪失步

6 )能量攻击Kocher等人 [Koc99]指出测量一个 CPU当前的能量供给能在很大程度上确定处理器的内部活动他们提出了两种能量攻击的方法简单能量分析 (simple power analysis)人工地跟踪检查和尝试确定程序作用的位置比如分支基于不同 CUP操作的能耗知识基于程序作用攻击者然后减少密钥的比特差分能量分析 (Differential power analysis)用相关性确定作用和密钥比特这种攻击最初目标是智能卡这种卡从外部读卡器获取能量但是这种攻击也能应用到许多嵌入式系统中

7 )反攻击 在一些时候有可能构造反破坏的嵌入式系统使电子设备难以发觉和分析延缓了攻击者芯片中有限的信息也有助阻止攻击者发现数据

6 Efficiency (效率)

ES must be efficient

bull Code-size efficient( 特别是片上系统 )

bull Run-time efficient

bull Weight efficient

bull Cost efficient

bull Energy efficient

能量有效性的重要意义

ldquoinherent power

efficiency of siliconldquo

59

低功耗设计问题 功耗问题是近几年来人们在嵌入式系统的设计中普遍关注的难点和热点它严重地制约着嵌入式系统的应用与发展

无论是在军事还是在商业贸易上的应用相当数量的嵌入式系统一般是由电池来供给电能的而且大多数嵌入式设备都有体积和质量的约束减少电能消耗不仅能延长电池的使用寿命延长用户更换电池的周期而且能带来提高系统性能与降低系统开销的好处甚至能起到保护环境的作用在便携式设备中 CPU消耗的电能越少电池的寿命就越长同时散发的热量少了所需的散热器就少了从而可减少该设备的花费和体积使产品尽快进入市场的目标

1 低功耗嵌入式应用系统是指以降低系统功耗为一个主要性能指标的嵌入式系统如计算机里的许多芯片过去用 5V供电现在用 33V 18V 并提出了绿色电器的概念

60

低功耗设备的要求1 )首先要求体积小重量轻便于携带2 )采用低功耗电路的设计方法以降低系统的功耗

它除了选用各种低功耗的器件和芯片外还在满足速度等性能指标的前提下进行降低功耗的硬件电路设计和软件设计

3 )有的系统应用在交流供电比较困难甚至无法用交流供电的场合因而各种电池(瓶)就成为其主要供电手段

4 )采用 LCD液晶显示器5 )采用 RS232C串行通信接口6 )采用微功耗高抗干扰的 CMOS集成电路

功耗产生的原因 P=UI

与功耗有关的因素

( 1 )电阻上消耗的功率( 2 )有源器件的开关转换阶段( 3 )集成电路内部和外部电容的充放电( 4 )系统的性能指标负载能力被处理信号的工作频率电路的工作频率电源的管理水平零部件的性能散热条件接口的物理性能等对系统功耗起着重要的作用

降低功耗的措施

功耗的组成动态 + 静态动态电源管理动态电压缩放低功耗硬件设计低功耗软件设计

二设计方法学概论

问题功 能 性能要求价 格 开发 周 期 等约束

设计 选择 折衷 分析比较 计算 评价

嵌入式系统

0嵌入式系统设计概述

方法 工具

设计方法论( design methodology )

设计方法论有以下三个重要理由1 )确认我们所做的每一件事情都是必须要作的

不会做无谓的白工也不会漏掉关键性的重要工作其中包含效率优化或是功能测试

2 )可以发展出计算机辅助工具或是设计经验累积汲取每一次产品发展的经验再经过量化之后可以发展出一套工具或是方法让往后的产品设计步入自动化

3 )开发团队遵循同一套方法论可以让团队成员更容易彼此沟通每个人都能在短时间内了解整体过程中将经历哪些过程需要何种支持与接收到何种结果此外也容易透过一套已经定义好的方法论彼此相互合作协调

设计目标 1 )上市时间

也就是 time-to-market 的观念2 )设计成本

许多消费性产品对于价格非常敏感所以产品厂商对于成本会斤斤计较是很合理的

3 )品质 顾客也许不需要最快最便宜的产品但是一定会要求功能质量保证不能只用一小段时间就坏掉了

传统的设计主要步骤

2 传统的设计流程方法1 )瀑布模型 (Waterfall)2 )螺旋模型 (Spiral)3 )连续改进 (Successive Refinement)4 )硬件与软件的同步设计 (SWHW Co-

deign)5 )阶层式 (Hierarchical) 设计6 )同步工程( concurrent

engineering )

瀑布模型 (Waterfall)

螺旋模型 (Spiral)

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 29: 大学计算机基础 —— 计算机科学概论

可靠度 产品在规定的条件下和规定的时间内完成规

定功能的概率称为可靠度依定义可知系统的可靠度是时间的函数表示为

式中 R(t)mdashmdash 可靠度函数 ξmdashmdash 产生故障前的工作时间 t mdashmdash 规定的时间

)()( tPtR

2 )可靠性的分析mdashmdash可靠度

可靠度函数

依定义可知可靠度函数 R(t) 为

式中 N0 mdashmdash t = 0 时在规定条件下进行工作的产品数

r(t) mdashmdash  在 0 到 t 时刻的工作时间内产品的累计

故障数

0

0 )()(

N

trNtR

累积故障分布函数 产品在规定的条件下和规定的时间内丧失

规定功能的概率称为累积故障概率(又叫不可靠度) 依定义可知产品的累积故障概率是时间的函

数即

显然以下关系成立

0

)()(

N

trtF

1)()( tFtR

可靠度函数与累积故障分布函数的性质

图 R(t)F(t)与f(t)的关系t

f(t)

f(t)

F(to)

R(to)

to

由密度函数的性质 1)(0

dttf 可知

t

tdttfdttftFtR )()(1)(1)(

0

因此 R(t) F(t) 与 f(t) 之间的关系如图所示

故障率函数 故障率

工作到某时刻尚未发生故障的产品在该时刻后单位时间内发生故障的概率称之为产品的故障率

用数学符号表示为

式中 (t) mdashmdash 故障率 dr(t) mdashmdash t 时刻后 dt 时间内故障的产品数 Ns(t) mdashmdash 残存产品数即到 t 时刻尚未故障的产品

dttN

tdrt

s )(

)()(

35

故障率函数

可按下式进行工程计算

式中 Δr(t) mdashmdash t 时刻后 Δt 时间内故障的产品数

Δt mdashmdash 所取时间间隔 Ns(t) mdashmdash 残存产品数

对于低故障率的元部件常以 10-9h 为故障率的单位称之为菲特( Fit )

ttN

trt

s

)(

)()(

产品故障浴盆曲线 浴盆曲线

大多数产品的故障率随时间的变化曲线形似浴盆称之为浴盆曲线由于产品故障机理的不同产品的故障率随时间的变化大致可以分为三个阶段

产品典型的故障率曲线

t

使用寿命

早期故障

偶然故障 耗损故障

A B规定的故障率 维修后故障率下降

(t)

3 )纠错技术( 1 )纠错码 在 1950s就开始研究最早的是可以检测和纠错的汉明码它们通过数字系统广泛地用于识别和纠正短暂或者持久的错误这些码引入冗余信息来确保一些类型的错误可以被检测和纠正比如一个单错校正 双错校正的码能用一个比特检测和纠正一个错误但是不能用两个比特纠错

( 2 )三模冗余 (triple modular

redundancy) 计算单元 C 有三个副本 C1C2和 C3三个单元接收同

样的输入一个独立单元比较每个输入的结果如果至少两个结果一致那么那个值被表决器选做正确结果如果三个结果都不相同那么就没有正确的结果

1C

2C

3C

表决错误

结果

输入

( 3 )看门狗定时器 (watchdog timer)

看门狗定时器 (watchdog timer)被广泛地用于检测系统问题如图 看门狗定时器连接到一个监视系统如果这个看门狗定时器翻转它产生一个完成信号用于标注系统的错误中断系统应该这样设计当适当运行的时候它一直在可能产生翻转信号之前复位定时器因此来自看门狗定时器的完成信号指示系统在一定程度上不合适地操作看门狗定时器用于预防不同的故障

系统看门狗定时器

完成

复位

( 4 )设计多样性 (Design diversity)

一种用于减少一些系统错误进入设计的设计方法学当一个设计需要给定模块的不同实例应该采用模块的不同实现而不是到处都用同一种模块比如一个有多个 CPU的系统可能采用不同类型的 CPU而不是到处采用同一种类型的 CPU在一个三模冗余系统产生表决结构的组件可能有不同的实现这样可以减少产生同样设计错误的机会

4 )软件可靠性ldquo在规定的条件下在规定的时间内软件不引起失效的概率rdquo

规定的条件 软件运行的软硬件环境 软件操作剖面软件运行的输入空间及其概率分布

规定的时间 日历时间 时钟时间 执行时间

激活软件 输入域 缺陷的数据

软件缺陷 软件

不可接受的结果 (软件故障) 输出域

软件故障的特点

软件与硬件可靠性的区别硬件 软件

故障机理 老化损耗 残留缺陷在一定环境下造成的软件错误

复杂性 内部逻辑较为简单 内部逻辑高度复杂这就在很大程度上决定了设计错误是导致软件故障的主要原因

唯一性 任何两个硬件不可能绝对相同

软件是唯一的软件拷贝不改变软件本身

可靠性的核心 内部元部件 设计者的思维和软件的复杂性纠错维护方法 修复或更换失效的元部件 重设计 可靠性检验标准化

已标准化且有一整套完整的理论

仍未建立更没有完整的理论体系

产品市场 已有成熟的产品市场 产品市场还很新 错误性质 一些瞬间的硬件错误可能

会被误认为是软件错误 软件错误是永恒的可重现的

影响软件可靠性的因素( 1 )运行环境 ( 剖面 )

同一软件在不同运行剖面下其可靠性行为可能极不相同 软件故障是软件缺陷在一定输入情况下被激活的结果 假设软件输入域划分为两个部分 G 和 F 运行剖面不包含 F 中

的输入则软件不会出现故障其可靠性恒为 l 反之如果运行剖面不包含 G 中的输入则每一输入情况下均出现故障如果没有容错措施则 R=0

( 2 )软件规模 随着软件规模的增大软件可靠性问题愈显突出在我们考虑软件

可靠性问题时软件一般是指中型以上软件 (4000-5000条以上语句 ) 这时可靠性问题难以对付

软件工程实践的一个侧面可以反映这一点即单元测试一般由编程人员本人进行而综合测试则需独立的测试人员

影响软件可靠性的因素( 3 )软件内部结构

结构越复杂软件复杂度越高内含缺陷数越大因而软件可靠度越低

( 4 )软件可靠性设计技术 一般是指软件设计阶段中采用的用以保证和提高软件可靠性为主要目标的软件技术

( 5 )软件可靠性测试 研究表明软件测试方法与资源投入对软件可靠性有不可忽视的影

响( 6 )软件可靠性管理

软件可靠性管理旨在系统管理软件生存期各阶段的可靠性活动使之系统化规范化一体化这样就可以避免许多人为错误以提高软件可靠性

影响软件可靠性的因素( 7 )软件开发人员能力和经验

软件开发人员 ( 包括测试人员 ) 的能力愈强经验愈丰富所犯错误便可能愈少所得软件产品质量愈高相应的可靠性也愈高

( 8 )软件开发方法 软件工程表明开发方法对软件可靠性有显著影响 与非结构化方法比较结构化方法可以明显减少软件缺陷数

( 9 )软件开发环境 研究表明程序语言软件开发环境影响软件的可靠性而软件测

试工具的优劣则影响可靠性测试结果

4 安全 (Safety)amp保密 (Security)

安全 (Safety) 是保证财产和人身受到损害可靠性是指在一定的环境条件下以及一定的时间内系统完成特定任务的可能性而有效性则是系统的长期的工作时间于其存在时间 ( 简单的定义为运行时间 +维护时间 ) 的 比例保密 (Security) 是针对危险破坏损失或非法活动而进行措施在一定层面上保密 (Security)要比安全 (Safety)宽广的多例如信息 Security家庭 Security 网络 Security 国家Security) 等

Security强调的是外在事物对特定目标的危害

Safety 是系统本身的潜在危害

四个概念的比较分析安全 (Safety)可靠性 (Reliability)有效性 (Availability)保密 (Security )安全 (Safety)高的系统 软件可靠性不

一定高可靠性和有效性并不是一码事保密 (Security )的系统 软件是安全

(Safety) 系统 软件的重要保障

可靠性安全性保密性 可靠(或可信)系统设计 (Reliable (or dependable) system design)是制造嵌入式系统所关注的甚至在面对内部或者外部问题时可靠系统设计经常假设问题是非恶意引起的

安全重要的系统设计 (Safety-critical system design)研究确保系统安全操作的方法独立于引起问题的原因

保密性 (Security)主要关注恶意攻击

Aizientis等人描述了可信性和保密性间的关系可信性和保密性由几个特性所组成

服务的可用性 (Availability) 服务的连续性 (Continuity) 来自用户和所处环境的灾难性后果的安全性 (Safety) 来自不合适系统改变的完整性 (Integrity) 通过更改和修补的可维护性 (Maintainability) 信息的机密性 (Confidentiality)

可用性完整性

可靠性安全性可维护性

机密性

可信性 保密性

5 新型攻击和对策1 )物理攻击嵌入式系统比通用计算机更容易受攻击 一个关键原因是许多嵌入式计算机对攻击者可物理访问

2 )互联网攻击一些嵌入式系统的攻击通过互联网访问变得更加容易今天许多嵌入式系统连接到互联网

3 )电池攻击 (battery attack)这种攻击试图通过耗尽电池来关闭节点

4 )服务拒绝攻击 (Denial-of-service attacks)

在通用系统中众所周知但是实时嵌入式系统可能更容易受服务质量 (quality-of-service (QoS))攻击如果网络发布实时数据那么发送过程中的一点延迟都能引起数据无效如果那些数据用来实时控制那么这些短暂延迟就能引起系统故障我们称这种危害为时间攻击因为它改变了系统的实时特性

QoS或者时间攻击之所以强大使因为它的影响不仅仅限于信息被控制系统的动态特性可决定系统的响应如果一个大型沉重快速运动的系统被控制那么时间上一个相对小的改变能引起大量的破坏

5 )网络(协议)攻击Wood和 Stankovic[Woo02]在传感器网络上确定了一些方式这些方式可在网络层次的不同层执行拒绝服务攻击如下所列

物理层 (Physical layer)mdashmdash拥塞破坏 链路层 (Link layer)mdashmdash碰撞耗尽非公平

网络和路由层 (Network and routing layer)mdashmdash丢弃和贪婪汇集方向误导黑洞认证监视冗余

传输层 (Transport layer)mdashmdash泛洪失步

6 )能量攻击Kocher等人 [Koc99]指出测量一个 CPU当前的能量供给能在很大程度上确定处理器的内部活动他们提出了两种能量攻击的方法简单能量分析 (simple power analysis)人工地跟踪检查和尝试确定程序作用的位置比如分支基于不同 CUP操作的能耗知识基于程序作用攻击者然后减少密钥的比特差分能量分析 (Differential power analysis)用相关性确定作用和密钥比特这种攻击最初目标是智能卡这种卡从外部读卡器获取能量但是这种攻击也能应用到许多嵌入式系统中

7 )反攻击 在一些时候有可能构造反破坏的嵌入式系统使电子设备难以发觉和分析延缓了攻击者芯片中有限的信息也有助阻止攻击者发现数据

6 Efficiency (效率)

ES must be efficient

bull Code-size efficient( 特别是片上系统 )

bull Run-time efficient

bull Weight efficient

bull Cost efficient

bull Energy efficient

能量有效性的重要意义

ldquoinherent power

efficiency of siliconldquo

59

低功耗设计问题 功耗问题是近几年来人们在嵌入式系统的设计中普遍关注的难点和热点它严重地制约着嵌入式系统的应用与发展

无论是在军事还是在商业贸易上的应用相当数量的嵌入式系统一般是由电池来供给电能的而且大多数嵌入式设备都有体积和质量的约束减少电能消耗不仅能延长电池的使用寿命延长用户更换电池的周期而且能带来提高系统性能与降低系统开销的好处甚至能起到保护环境的作用在便携式设备中 CPU消耗的电能越少电池的寿命就越长同时散发的热量少了所需的散热器就少了从而可减少该设备的花费和体积使产品尽快进入市场的目标

1 低功耗嵌入式应用系统是指以降低系统功耗为一个主要性能指标的嵌入式系统如计算机里的许多芯片过去用 5V供电现在用 33V 18V 并提出了绿色电器的概念

60

低功耗设备的要求1 )首先要求体积小重量轻便于携带2 )采用低功耗电路的设计方法以降低系统的功耗

它除了选用各种低功耗的器件和芯片外还在满足速度等性能指标的前提下进行降低功耗的硬件电路设计和软件设计

3 )有的系统应用在交流供电比较困难甚至无法用交流供电的场合因而各种电池(瓶)就成为其主要供电手段

4 )采用 LCD液晶显示器5 )采用 RS232C串行通信接口6 )采用微功耗高抗干扰的 CMOS集成电路

功耗产生的原因 P=UI

与功耗有关的因素

( 1 )电阻上消耗的功率( 2 )有源器件的开关转换阶段( 3 )集成电路内部和外部电容的充放电( 4 )系统的性能指标负载能力被处理信号的工作频率电路的工作频率电源的管理水平零部件的性能散热条件接口的物理性能等对系统功耗起着重要的作用

降低功耗的措施

功耗的组成动态 + 静态动态电源管理动态电压缩放低功耗硬件设计低功耗软件设计

二设计方法学概论

问题功 能 性能要求价 格 开发 周 期 等约束

设计 选择 折衷 分析比较 计算 评价

嵌入式系统

0嵌入式系统设计概述

方法 工具

设计方法论( design methodology )

设计方法论有以下三个重要理由1 )确认我们所做的每一件事情都是必须要作的

不会做无谓的白工也不会漏掉关键性的重要工作其中包含效率优化或是功能测试

2 )可以发展出计算机辅助工具或是设计经验累积汲取每一次产品发展的经验再经过量化之后可以发展出一套工具或是方法让往后的产品设计步入自动化

3 )开发团队遵循同一套方法论可以让团队成员更容易彼此沟通每个人都能在短时间内了解整体过程中将经历哪些过程需要何种支持与接收到何种结果此外也容易透过一套已经定义好的方法论彼此相互合作协调

设计目标 1 )上市时间

也就是 time-to-market 的观念2 )设计成本

许多消费性产品对于价格非常敏感所以产品厂商对于成本会斤斤计较是很合理的

3 )品质 顾客也许不需要最快最便宜的产品但是一定会要求功能质量保证不能只用一小段时间就坏掉了

传统的设计主要步骤

2 传统的设计流程方法1 )瀑布模型 (Waterfall)2 )螺旋模型 (Spiral)3 )连续改进 (Successive Refinement)4 )硬件与软件的同步设计 (SWHW Co-

deign)5 )阶层式 (Hierarchical) 设计6 )同步工程( concurrent

engineering )

瀑布模型 (Waterfall)

螺旋模型 (Spiral)

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 30: 大学计算机基础 —— 计算机科学概论

可靠度函数

依定义可知可靠度函数 R(t) 为

式中 N0 mdashmdash t = 0 时在规定条件下进行工作的产品数

r(t) mdashmdash  在 0 到 t 时刻的工作时间内产品的累计

故障数

0

0 )()(

N

trNtR

累积故障分布函数 产品在规定的条件下和规定的时间内丧失

规定功能的概率称为累积故障概率(又叫不可靠度) 依定义可知产品的累积故障概率是时间的函

数即

显然以下关系成立

0

)()(

N

trtF

1)()( tFtR

可靠度函数与累积故障分布函数的性质

图 R(t)F(t)与f(t)的关系t

f(t)

f(t)

F(to)

R(to)

to

由密度函数的性质 1)(0

dttf 可知

t

tdttfdttftFtR )()(1)(1)(

0

因此 R(t) F(t) 与 f(t) 之间的关系如图所示

故障率函数 故障率

工作到某时刻尚未发生故障的产品在该时刻后单位时间内发生故障的概率称之为产品的故障率

用数学符号表示为

式中 (t) mdashmdash 故障率 dr(t) mdashmdash t 时刻后 dt 时间内故障的产品数 Ns(t) mdashmdash 残存产品数即到 t 时刻尚未故障的产品

dttN

tdrt

s )(

)()(

35

故障率函数

可按下式进行工程计算

式中 Δr(t) mdashmdash t 时刻后 Δt 时间内故障的产品数

Δt mdashmdash 所取时间间隔 Ns(t) mdashmdash 残存产品数

对于低故障率的元部件常以 10-9h 为故障率的单位称之为菲特( Fit )

ttN

trt

s

)(

)()(

产品故障浴盆曲线 浴盆曲线

大多数产品的故障率随时间的变化曲线形似浴盆称之为浴盆曲线由于产品故障机理的不同产品的故障率随时间的变化大致可以分为三个阶段

产品典型的故障率曲线

t

使用寿命

早期故障

偶然故障 耗损故障

A B规定的故障率 维修后故障率下降

(t)

3 )纠错技术( 1 )纠错码 在 1950s就开始研究最早的是可以检测和纠错的汉明码它们通过数字系统广泛地用于识别和纠正短暂或者持久的错误这些码引入冗余信息来确保一些类型的错误可以被检测和纠正比如一个单错校正 双错校正的码能用一个比特检测和纠正一个错误但是不能用两个比特纠错

( 2 )三模冗余 (triple modular

redundancy) 计算单元 C 有三个副本 C1C2和 C3三个单元接收同

样的输入一个独立单元比较每个输入的结果如果至少两个结果一致那么那个值被表决器选做正确结果如果三个结果都不相同那么就没有正确的结果

1C

2C

3C

表决错误

结果

输入

( 3 )看门狗定时器 (watchdog timer)

看门狗定时器 (watchdog timer)被广泛地用于检测系统问题如图 看门狗定时器连接到一个监视系统如果这个看门狗定时器翻转它产生一个完成信号用于标注系统的错误中断系统应该这样设计当适当运行的时候它一直在可能产生翻转信号之前复位定时器因此来自看门狗定时器的完成信号指示系统在一定程度上不合适地操作看门狗定时器用于预防不同的故障

系统看门狗定时器

完成

复位

( 4 )设计多样性 (Design diversity)

一种用于减少一些系统错误进入设计的设计方法学当一个设计需要给定模块的不同实例应该采用模块的不同实现而不是到处都用同一种模块比如一个有多个 CPU的系统可能采用不同类型的 CPU而不是到处采用同一种类型的 CPU在一个三模冗余系统产生表决结构的组件可能有不同的实现这样可以减少产生同样设计错误的机会

4 )软件可靠性ldquo在规定的条件下在规定的时间内软件不引起失效的概率rdquo

规定的条件 软件运行的软硬件环境 软件操作剖面软件运行的输入空间及其概率分布

规定的时间 日历时间 时钟时间 执行时间

激活软件 输入域 缺陷的数据

软件缺陷 软件

不可接受的结果 (软件故障) 输出域

软件故障的特点

软件与硬件可靠性的区别硬件 软件

故障机理 老化损耗 残留缺陷在一定环境下造成的软件错误

复杂性 内部逻辑较为简单 内部逻辑高度复杂这就在很大程度上决定了设计错误是导致软件故障的主要原因

唯一性 任何两个硬件不可能绝对相同

软件是唯一的软件拷贝不改变软件本身

可靠性的核心 内部元部件 设计者的思维和软件的复杂性纠错维护方法 修复或更换失效的元部件 重设计 可靠性检验标准化

已标准化且有一整套完整的理论

仍未建立更没有完整的理论体系

产品市场 已有成熟的产品市场 产品市场还很新 错误性质 一些瞬间的硬件错误可能

会被误认为是软件错误 软件错误是永恒的可重现的

影响软件可靠性的因素( 1 )运行环境 ( 剖面 )

同一软件在不同运行剖面下其可靠性行为可能极不相同 软件故障是软件缺陷在一定输入情况下被激活的结果 假设软件输入域划分为两个部分 G 和 F 运行剖面不包含 F 中

的输入则软件不会出现故障其可靠性恒为 l 反之如果运行剖面不包含 G 中的输入则每一输入情况下均出现故障如果没有容错措施则 R=0

( 2 )软件规模 随着软件规模的增大软件可靠性问题愈显突出在我们考虑软件

可靠性问题时软件一般是指中型以上软件 (4000-5000条以上语句 ) 这时可靠性问题难以对付

软件工程实践的一个侧面可以反映这一点即单元测试一般由编程人员本人进行而综合测试则需独立的测试人员

影响软件可靠性的因素( 3 )软件内部结构

结构越复杂软件复杂度越高内含缺陷数越大因而软件可靠度越低

( 4 )软件可靠性设计技术 一般是指软件设计阶段中采用的用以保证和提高软件可靠性为主要目标的软件技术

( 5 )软件可靠性测试 研究表明软件测试方法与资源投入对软件可靠性有不可忽视的影

响( 6 )软件可靠性管理

软件可靠性管理旨在系统管理软件生存期各阶段的可靠性活动使之系统化规范化一体化这样就可以避免许多人为错误以提高软件可靠性

影响软件可靠性的因素( 7 )软件开发人员能力和经验

软件开发人员 ( 包括测试人员 ) 的能力愈强经验愈丰富所犯错误便可能愈少所得软件产品质量愈高相应的可靠性也愈高

( 8 )软件开发方法 软件工程表明开发方法对软件可靠性有显著影响 与非结构化方法比较结构化方法可以明显减少软件缺陷数

( 9 )软件开发环境 研究表明程序语言软件开发环境影响软件的可靠性而软件测

试工具的优劣则影响可靠性测试结果

4 安全 (Safety)amp保密 (Security)

安全 (Safety) 是保证财产和人身受到损害可靠性是指在一定的环境条件下以及一定的时间内系统完成特定任务的可能性而有效性则是系统的长期的工作时间于其存在时间 ( 简单的定义为运行时间 +维护时间 ) 的 比例保密 (Security) 是针对危险破坏损失或非法活动而进行措施在一定层面上保密 (Security)要比安全 (Safety)宽广的多例如信息 Security家庭 Security 网络 Security 国家Security) 等

Security强调的是外在事物对特定目标的危害

Safety 是系统本身的潜在危害

四个概念的比较分析安全 (Safety)可靠性 (Reliability)有效性 (Availability)保密 (Security )安全 (Safety)高的系统 软件可靠性不

一定高可靠性和有效性并不是一码事保密 (Security )的系统 软件是安全

(Safety) 系统 软件的重要保障

可靠性安全性保密性 可靠(或可信)系统设计 (Reliable (or dependable) system design)是制造嵌入式系统所关注的甚至在面对内部或者外部问题时可靠系统设计经常假设问题是非恶意引起的

安全重要的系统设计 (Safety-critical system design)研究确保系统安全操作的方法独立于引起问题的原因

保密性 (Security)主要关注恶意攻击

Aizientis等人描述了可信性和保密性间的关系可信性和保密性由几个特性所组成

服务的可用性 (Availability) 服务的连续性 (Continuity) 来自用户和所处环境的灾难性后果的安全性 (Safety) 来自不合适系统改变的完整性 (Integrity) 通过更改和修补的可维护性 (Maintainability) 信息的机密性 (Confidentiality)

可用性完整性

可靠性安全性可维护性

机密性

可信性 保密性

5 新型攻击和对策1 )物理攻击嵌入式系统比通用计算机更容易受攻击 一个关键原因是许多嵌入式计算机对攻击者可物理访问

2 )互联网攻击一些嵌入式系统的攻击通过互联网访问变得更加容易今天许多嵌入式系统连接到互联网

3 )电池攻击 (battery attack)这种攻击试图通过耗尽电池来关闭节点

4 )服务拒绝攻击 (Denial-of-service attacks)

在通用系统中众所周知但是实时嵌入式系统可能更容易受服务质量 (quality-of-service (QoS))攻击如果网络发布实时数据那么发送过程中的一点延迟都能引起数据无效如果那些数据用来实时控制那么这些短暂延迟就能引起系统故障我们称这种危害为时间攻击因为它改变了系统的实时特性

QoS或者时间攻击之所以强大使因为它的影响不仅仅限于信息被控制系统的动态特性可决定系统的响应如果一个大型沉重快速运动的系统被控制那么时间上一个相对小的改变能引起大量的破坏

5 )网络(协议)攻击Wood和 Stankovic[Woo02]在传感器网络上确定了一些方式这些方式可在网络层次的不同层执行拒绝服务攻击如下所列

物理层 (Physical layer)mdashmdash拥塞破坏 链路层 (Link layer)mdashmdash碰撞耗尽非公平

网络和路由层 (Network and routing layer)mdashmdash丢弃和贪婪汇集方向误导黑洞认证监视冗余

传输层 (Transport layer)mdashmdash泛洪失步

6 )能量攻击Kocher等人 [Koc99]指出测量一个 CPU当前的能量供给能在很大程度上确定处理器的内部活动他们提出了两种能量攻击的方法简单能量分析 (simple power analysis)人工地跟踪检查和尝试确定程序作用的位置比如分支基于不同 CUP操作的能耗知识基于程序作用攻击者然后减少密钥的比特差分能量分析 (Differential power analysis)用相关性确定作用和密钥比特这种攻击最初目标是智能卡这种卡从外部读卡器获取能量但是这种攻击也能应用到许多嵌入式系统中

7 )反攻击 在一些时候有可能构造反破坏的嵌入式系统使电子设备难以发觉和分析延缓了攻击者芯片中有限的信息也有助阻止攻击者发现数据

6 Efficiency (效率)

ES must be efficient

bull Code-size efficient( 特别是片上系统 )

bull Run-time efficient

bull Weight efficient

bull Cost efficient

bull Energy efficient

能量有效性的重要意义

ldquoinherent power

efficiency of siliconldquo

59

低功耗设计问题 功耗问题是近几年来人们在嵌入式系统的设计中普遍关注的难点和热点它严重地制约着嵌入式系统的应用与发展

无论是在军事还是在商业贸易上的应用相当数量的嵌入式系统一般是由电池来供给电能的而且大多数嵌入式设备都有体积和质量的约束减少电能消耗不仅能延长电池的使用寿命延长用户更换电池的周期而且能带来提高系统性能与降低系统开销的好处甚至能起到保护环境的作用在便携式设备中 CPU消耗的电能越少电池的寿命就越长同时散发的热量少了所需的散热器就少了从而可减少该设备的花费和体积使产品尽快进入市场的目标

1 低功耗嵌入式应用系统是指以降低系统功耗为一个主要性能指标的嵌入式系统如计算机里的许多芯片过去用 5V供电现在用 33V 18V 并提出了绿色电器的概念

60

低功耗设备的要求1 )首先要求体积小重量轻便于携带2 )采用低功耗电路的设计方法以降低系统的功耗

它除了选用各种低功耗的器件和芯片外还在满足速度等性能指标的前提下进行降低功耗的硬件电路设计和软件设计

3 )有的系统应用在交流供电比较困难甚至无法用交流供电的场合因而各种电池(瓶)就成为其主要供电手段

4 )采用 LCD液晶显示器5 )采用 RS232C串行通信接口6 )采用微功耗高抗干扰的 CMOS集成电路

功耗产生的原因 P=UI

与功耗有关的因素

( 1 )电阻上消耗的功率( 2 )有源器件的开关转换阶段( 3 )集成电路内部和外部电容的充放电( 4 )系统的性能指标负载能力被处理信号的工作频率电路的工作频率电源的管理水平零部件的性能散热条件接口的物理性能等对系统功耗起着重要的作用

降低功耗的措施

功耗的组成动态 + 静态动态电源管理动态电压缩放低功耗硬件设计低功耗软件设计

二设计方法学概论

问题功 能 性能要求价 格 开发 周 期 等约束

设计 选择 折衷 分析比较 计算 评价

嵌入式系统

0嵌入式系统设计概述

方法 工具

设计方法论( design methodology )

设计方法论有以下三个重要理由1 )确认我们所做的每一件事情都是必须要作的

不会做无谓的白工也不会漏掉关键性的重要工作其中包含效率优化或是功能测试

2 )可以发展出计算机辅助工具或是设计经验累积汲取每一次产品发展的经验再经过量化之后可以发展出一套工具或是方法让往后的产品设计步入自动化

3 )开发团队遵循同一套方法论可以让团队成员更容易彼此沟通每个人都能在短时间内了解整体过程中将经历哪些过程需要何种支持与接收到何种结果此外也容易透过一套已经定义好的方法论彼此相互合作协调

设计目标 1 )上市时间

也就是 time-to-market 的观念2 )设计成本

许多消费性产品对于价格非常敏感所以产品厂商对于成本会斤斤计较是很合理的

3 )品质 顾客也许不需要最快最便宜的产品但是一定会要求功能质量保证不能只用一小段时间就坏掉了

传统的设计主要步骤

2 传统的设计流程方法1 )瀑布模型 (Waterfall)2 )螺旋模型 (Spiral)3 )连续改进 (Successive Refinement)4 )硬件与软件的同步设计 (SWHW Co-

deign)5 )阶层式 (Hierarchical) 设计6 )同步工程( concurrent

engineering )

瀑布模型 (Waterfall)

螺旋模型 (Spiral)

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 31: 大学计算机基础 —— 计算机科学概论

累积故障分布函数 产品在规定的条件下和规定的时间内丧失

规定功能的概率称为累积故障概率(又叫不可靠度) 依定义可知产品的累积故障概率是时间的函

数即

显然以下关系成立

0

)()(

N

trtF

1)()( tFtR

可靠度函数与累积故障分布函数的性质

图 R(t)F(t)与f(t)的关系t

f(t)

f(t)

F(to)

R(to)

to

由密度函数的性质 1)(0

dttf 可知

t

tdttfdttftFtR )()(1)(1)(

0

因此 R(t) F(t) 与 f(t) 之间的关系如图所示

故障率函数 故障率

工作到某时刻尚未发生故障的产品在该时刻后单位时间内发生故障的概率称之为产品的故障率

用数学符号表示为

式中 (t) mdashmdash 故障率 dr(t) mdashmdash t 时刻后 dt 时间内故障的产品数 Ns(t) mdashmdash 残存产品数即到 t 时刻尚未故障的产品

dttN

tdrt

s )(

)()(

35

故障率函数

可按下式进行工程计算

式中 Δr(t) mdashmdash t 时刻后 Δt 时间内故障的产品数

Δt mdashmdash 所取时间间隔 Ns(t) mdashmdash 残存产品数

对于低故障率的元部件常以 10-9h 为故障率的单位称之为菲特( Fit )

ttN

trt

s

)(

)()(

产品故障浴盆曲线 浴盆曲线

大多数产品的故障率随时间的变化曲线形似浴盆称之为浴盆曲线由于产品故障机理的不同产品的故障率随时间的变化大致可以分为三个阶段

产品典型的故障率曲线

t

使用寿命

早期故障

偶然故障 耗损故障

A B规定的故障率 维修后故障率下降

(t)

3 )纠错技术( 1 )纠错码 在 1950s就开始研究最早的是可以检测和纠错的汉明码它们通过数字系统广泛地用于识别和纠正短暂或者持久的错误这些码引入冗余信息来确保一些类型的错误可以被检测和纠正比如一个单错校正 双错校正的码能用一个比特检测和纠正一个错误但是不能用两个比特纠错

( 2 )三模冗余 (triple modular

redundancy) 计算单元 C 有三个副本 C1C2和 C3三个单元接收同

样的输入一个独立单元比较每个输入的结果如果至少两个结果一致那么那个值被表决器选做正确结果如果三个结果都不相同那么就没有正确的结果

1C

2C

3C

表决错误

结果

输入

( 3 )看门狗定时器 (watchdog timer)

看门狗定时器 (watchdog timer)被广泛地用于检测系统问题如图 看门狗定时器连接到一个监视系统如果这个看门狗定时器翻转它产生一个完成信号用于标注系统的错误中断系统应该这样设计当适当运行的时候它一直在可能产生翻转信号之前复位定时器因此来自看门狗定时器的完成信号指示系统在一定程度上不合适地操作看门狗定时器用于预防不同的故障

系统看门狗定时器

完成

复位

( 4 )设计多样性 (Design diversity)

一种用于减少一些系统错误进入设计的设计方法学当一个设计需要给定模块的不同实例应该采用模块的不同实现而不是到处都用同一种模块比如一个有多个 CPU的系统可能采用不同类型的 CPU而不是到处采用同一种类型的 CPU在一个三模冗余系统产生表决结构的组件可能有不同的实现这样可以减少产生同样设计错误的机会

4 )软件可靠性ldquo在规定的条件下在规定的时间内软件不引起失效的概率rdquo

规定的条件 软件运行的软硬件环境 软件操作剖面软件运行的输入空间及其概率分布

规定的时间 日历时间 时钟时间 执行时间

激活软件 输入域 缺陷的数据

软件缺陷 软件

不可接受的结果 (软件故障) 输出域

软件故障的特点

软件与硬件可靠性的区别硬件 软件

故障机理 老化损耗 残留缺陷在一定环境下造成的软件错误

复杂性 内部逻辑较为简单 内部逻辑高度复杂这就在很大程度上决定了设计错误是导致软件故障的主要原因

唯一性 任何两个硬件不可能绝对相同

软件是唯一的软件拷贝不改变软件本身

可靠性的核心 内部元部件 设计者的思维和软件的复杂性纠错维护方法 修复或更换失效的元部件 重设计 可靠性检验标准化

已标准化且有一整套完整的理论

仍未建立更没有完整的理论体系

产品市场 已有成熟的产品市场 产品市场还很新 错误性质 一些瞬间的硬件错误可能

会被误认为是软件错误 软件错误是永恒的可重现的

影响软件可靠性的因素( 1 )运行环境 ( 剖面 )

同一软件在不同运行剖面下其可靠性行为可能极不相同 软件故障是软件缺陷在一定输入情况下被激活的结果 假设软件输入域划分为两个部分 G 和 F 运行剖面不包含 F 中

的输入则软件不会出现故障其可靠性恒为 l 反之如果运行剖面不包含 G 中的输入则每一输入情况下均出现故障如果没有容错措施则 R=0

( 2 )软件规模 随着软件规模的增大软件可靠性问题愈显突出在我们考虑软件

可靠性问题时软件一般是指中型以上软件 (4000-5000条以上语句 ) 这时可靠性问题难以对付

软件工程实践的一个侧面可以反映这一点即单元测试一般由编程人员本人进行而综合测试则需独立的测试人员

影响软件可靠性的因素( 3 )软件内部结构

结构越复杂软件复杂度越高内含缺陷数越大因而软件可靠度越低

( 4 )软件可靠性设计技术 一般是指软件设计阶段中采用的用以保证和提高软件可靠性为主要目标的软件技术

( 5 )软件可靠性测试 研究表明软件测试方法与资源投入对软件可靠性有不可忽视的影

响( 6 )软件可靠性管理

软件可靠性管理旨在系统管理软件生存期各阶段的可靠性活动使之系统化规范化一体化这样就可以避免许多人为错误以提高软件可靠性

影响软件可靠性的因素( 7 )软件开发人员能力和经验

软件开发人员 ( 包括测试人员 ) 的能力愈强经验愈丰富所犯错误便可能愈少所得软件产品质量愈高相应的可靠性也愈高

( 8 )软件开发方法 软件工程表明开发方法对软件可靠性有显著影响 与非结构化方法比较结构化方法可以明显减少软件缺陷数

( 9 )软件开发环境 研究表明程序语言软件开发环境影响软件的可靠性而软件测

试工具的优劣则影响可靠性测试结果

4 安全 (Safety)amp保密 (Security)

安全 (Safety) 是保证财产和人身受到损害可靠性是指在一定的环境条件下以及一定的时间内系统完成特定任务的可能性而有效性则是系统的长期的工作时间于其存在时间 ( 简单的定义为运行时间 +维护时间 ) 的 比例保密 (Security) 是针对危险破坏损失或非法活动而进行措施在一定层面上保密 (Security)要比安全 (Safety)宽广的多例如信息 Security家庭 Security 网络 Security 国家Security) 等

Security强调的是外在事物对特定目标的危害

Safety 是系统本身的潜在危害

四个概念的比较分析安全 (Safety)可靠性 (Reliability)有效性 (Availability)保密 (Security )安全 (Safety)高的系统 软件可靠性不

一定高可靠性和有效性并不是一码事保密 (Security )的系统 软件是安全

(Safety) 系统 软件的重要保障

可靠性安全性保密性 可靠(或可信)系统设计 (Reliable (or dependable) system design)是制造嵌入式系统所关注的甚至在面对内部或者外部问题时可靠系统设计经常假设问题是非恶意引起的

安全重要的系统设计 (Safety-critical system design)研究确保系统安全操作的方法独立于引起问题的原因

保密性 (Security)主要关注恶意攻击

Aizientis等人描述了可信性和保密性间的关系可信性和保密性由几个特性所组成

服务的可用性 (Availability) 服务的连续性 (Continuity) 来自用户和所处环境的灾难性后果的安全性 (Safety) 来自不合适系统改变的完整性 (Integrity) 通过更改和修补的可维护性 (Maintainability) 信息的机密性 (Confidentiality)

可用性完整性

可靠性安全性可维护性

机密性

可信性 保密性

5 新型攻击和对策1 )物理攻击嵌入式系统比通用计算机更容易受攻击 一个关键原因是许多嵌入式计算机对攻击者可物理访问

2 )互联网攻击一些嵌入式系统的攻击通过互联网访问变得更加容易今天许多嵌入式系统连接到互联网

3 )电池攻击 (battery attack)这种攻击试图通过耗尽电池来关闭节点

4 )服务拒绝攻击 (Denial-of-service attacks)

在通用系统中众所周知但是实时嵌入式系统可能更容易受服务质量 (quality-of-service (QoS))攻击如果网络发布实时数据那么发送过程中的一点延迟都能引起数据无效如果那些数据用来实时控制那么这些短暂延迟就能引起系统故障我们称这种危害为时间攻击因为它改变了系统的实时特性

QoS或者时间攻击之所以强大使因为它的影响不仅仅限于信息被控制系统的动态特性可决定系统的响应如果一个大型沉重快速运动的系统被控制那么时间上一个相对小的改变能引起大量的破坏

5 )网络(协议)攻击Wood和 Stankovic[Woo02]在传感器网络上确定了一些方式这些方式可在网络层次的不同层执行拒绝服务攻击如下所列

物理层 (Physical layer)mdashmdash拥塞破坏 链路层 (Link layer)mdashmdash碰撞耗尽非公平

网络和路由层 (Network and routing layer)mdashmdash丢弃和贪婪汇集方向误导黑洞认证监视冗余

传输层 (Transport layer)mdashmdash泛洪失步

6 )能量攻击Kocher等人 [Koc99]指出测量一个 CPU当前的能量供给能在很大程度上确定处理器的内部活动他们提出了两种能量攻击的方法简单能量分析 (simple power analysis)人工地跟踪检查和尝试确定程序作用的位置比如分支基于不同 CUP操作的能耗知识基于程序作用攻击者然后减少密钥的比特差分能量分析 (Differential power analysis)用相关性确定作用和密钥比特这种攻击最初目标是智能卡这种卡从外部读卡器获取能量但是这种攻击也能应用到许多嵌入式系统中

7 )反攻击 在一些时候有可能构造反破坏的嵌入式系统使电子设备难以发觉和分析延缓了攻击者芯片中有限的信息也有助阻止攻击者发现数据

6 Efficiency (效率)

ES must be efficient

bull Code-size efficient( 特别是片上系统 )

bull Run-time efficient

bull Weight efficient

bull Cost efficient

bull Energy efficient

能量有效性的重要意义

ldquoinherent power

efficiency of siliconldquo

59

低功耗设计问题 功耗问题是近几年来人们在嵌入式系统的设计中普遍关注的难点和热点它严重地制约着嵌入式系统的应用与发展

无论是在军事还是在商业贸易上的应用相当数量的嵌入式系统一般是由电池来供给电能的而且大多数嵌入式设备都有体积和质量的约束减少电能消耗不仅能延长电池的使用寿命延长用户更换电池的周期而且能带来提高系统性能与降低系统开销的好处甚至能起到保护环境的作用在便携式设备中 CPU消耗的电能越少电池的寿命就越长同时散发的热量少了所需的散热器就少了从而可减少该设备的花费和体积使产品尽快进入市场的目标

1 低功耗嵌入式应用系统是指以降低系统功耗为一个主要性能指标的嵌入式系统如计算机里的许多芯片过去用 5V供电现在用 33V 18V 并提出了绿色电器的概念

60

低功耗设备的要求1 )首先要求体积小重量轻便于携带2 )采用低功耗电路的设计方法以降低系统的功耗

它除了选用各种低功耗的器件和芯片外还在满足速度等性能指标的前提下进行降低功耗的硬件电路设计和软件设计

3 )有的系统应用在交流供电比较困难甚至无法用交流供电的场合因而各种电池(瓶)就成为其主要供电手段

4 )采用 LCD液晶显示器5 )采用 RS232C串行通信接口6 )采用微功耗高抗干扰的 CMOS集成电路

功耗产生的原因 P=UI

与功耗有关的因素

( 1 )电阻上消耗的功率( 2 )有源器件的开关转换阶段( 3 )集成电路内部和外部电容的充放电( 4 )系统的性能指标负载能力被处理信号的工作频率电路的工作频率电源的管理水平零部件的性能散热条件接口的物理性能等对系统功耗起着重要的作用

降低功耗的措施

功耗的组成动态 + 静态动态电源管理动态电压缩放低功耗硬件设计低功耗软件设计

二设计方法学概论

问题功 能 性能要求价 格 开发 周 期 等约束

设计 选择 折衷 分析比较 计算 评价

嵌入式系统

0嵌入式系统设计概述

方法 工具

设计方法论( design methodology )

设计方法论有以下三个重要理由1 )确认我们所做的每一件事情都是必须要作的

不会做无谓的白工也不会漏掉关键性的重要工作其中包含效率优化或是功能测试

2 )可以发展出计算机辅助工具或是设计经验累积汲取每一次产品发展的经验再经过量化之后可以发展出一套工具或是方法让往后的产品设计步入自动化

3 )开发团队遵循同一套方法论可以让团队成员更容易彼此沟通每个人都能在短时间内了解整体过程中将经历哪些过程需要何种支持与接收到何种结果此外也容易透过一套已经定义好的方法论彼此相互合作协调

设计目标 1 )上市时间

也就是 time-to-market 的观念2 )设计成本

许多消费性产品对于价格非常敏感所以产品厂商对于成本会斤斤计较是很合理的

3 )品质 顾客也许不需要最快最便宜的产品但是一定会要求功能质量保证不能只用一小段时间就坏掉了

传统的设计主要步骤

2 传统的设计流程方法1 )瀑布模型 (Waterfall)2 )螺旋模型 (Spiral)3 )连续改进 (Successive Refinement)4 )硬件与软件的同步设计 (SWHW Co-

deign)5 )阶层式 (Hierarchical) 设计6 )同步工程( concurrent

engineering )

瀑布模型 (Waterfall)

螺旋模型 (Spiral)

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 32: 大学计算机基础 —— 计算机科学概论

可靠度函数与累积故障分布函数的性质

图 R(t)F(t)与f(t)的关系t

f(t)

f(t)

F(to)

R(to)

to

由密度函数的性质 1)(0

dttf 可知

t

tdttfdttftFtR )()(1)(1)(

0

因此 R(t) F(t) 与 f(t) 之间的关系如图所示

故障率函数 故障率

工作到某时刻尚未发生故障的产品在该时刻后单位时间内发生故障的概率称之为产品的故障率

用数学符号表示为

式中 (t) mdashmdash 故障率 dr(t) mdashmdash t 时刻后 dt 时间内故障的产品数 Ns(t) mdashmdash 残存产品数即到 t 时刻尚未故障的产品

dttN

tdrt

s )(

)()(

35

故障率函数

可按下式进行工程计算

式中 Δr(t) mdashmdash t 时刻后 Δt 时间内故障的产品数

Δt mdashmdash 所取时间间隔 Ns(t) mdashmdash 残存产品数

对于低故障率的元部件常以 10-9h 为故障率的单位称之为菲特( Fit )

ttN

trt

s

)(

)()(

产品故障浴盆曲线 浴盆曲线

大多数产品的故障率随时间的变化曲线形似浴盆称之为浴盆曲线由于产品故障机理的不同产品的故障率随时间的变化大致可以分为三个阶段

产品典型的故障率曲线

t

使用寿命

早期故障

偶然故障 耗损故障

A B规定的故障率 维修后故障率下降

(t)

3 )纠错技术( 1 )纠错码 在 1950s就开始研究最早的是可以检测和纠错的汉明码它们通过数字系统广泛地用于识别和纠正短暂或者持久的错误这些码引入冗余信息来确保一些类型的错误可以被检测和纠正比如一个单错校正 双错校正的码能用一个比特检测和纠正一个错误但是不能用两个比特纠错

( 2 )三模冗余 (triple modular

redundancy) 计算单元 C 有三个副本 C1C2和 C3三个单元接收同

样的输入一个独立单元比较每个输入的结果如果至少两个结果一致那么那个值被表决器选做正确结果如果三个结果都不相同那么就没有正确的结果

1C

2C

3C

表决错误

结果

输入

( 3 )看门狗定时器 (watchdog timer)

看门狗定时器 (watchdog timer)被广泛地用于检测系统问题如图 看门狗定时器连接到一个监视系统如果这个看门狗定时器翻转它产生一个完成信号用于标注系统的错误中断系统应该这样设计当适当运行的时候它一直在可能产生翻转信号之前复位定时器因此来自看门狗定时器的完成信号指示系统在一定程度上不合适地操作看门狗定时器用于预防不同的故障

系统看门狗定时器

完成

复位

( 4 )设计多样性 (Design diversity)

一种用于减少一些系统错误进入设计的设计方法学当一个设计需要给定模块的不同实例应该采用模块的不同实现而不是到处都用同一种模块比如一个有多个 CPU的系统可能采用不同类型的 CPU而不是到处采用同一种类型的 CPU在一个三模冗余系统产生表决结构的组件可能有不同的实现这样可以减少产生同样设计错误的机会

4 )软件可靠性ldquo在规定的条件下在规定的时间内软件不引起失效的概率rdquo

规定的条件 软件运行的软硬件环境 软件操作剖面软件运行的输入空间及其概率分布

规定的时间 日历时间 时钟时间 执行时间

激活软件 输入域 缺陷的数据

软件缺陷 软件

不可接受的结果 (软件故障) 输出域

软件故障的特点

软件与硬件可靠性的区别硬件 软件

故障机理 老化损耗 残留缺陷在一定环境下造成的软件错误

复杂性 内部逻辑较为简单 内部逻辑高度复杂这就在很大程度上决定了设计错误是导致软件故障的主要原因

唯一性 任何两个硬件不可能绝对相同

软件是唯一的软件拷贝不改变软件本身

可靠性的核心 内部元部件 设计者的思维和软件的复杂性纠错维护方法 修复或更换失效的元部件 重设计 可靠性检验标准化

已标准化且有一整套完整的理论

仍未建立更没有完整的理论体系

产品市场 已有成熟的产品市场 产品市场还很新 错误性质 一些瞬间的硬件错误可能

会被误认为是软件错误 软件错误是永恒的可重现的

影响软件可靠性的因素( 1 )运行环境 ( 剖面 )

同一软件在不同运行剖面下其可靠性行为可能极不相同 软件故障是软件缺陷在一定输入情况下被激活的结果 假设软件输入域划分为两个部分 G 和 F 运行剖面不包含 F 中

的输入则软件不会出现故障其可靠性恒为 l 反之如果运行剖面不包含 G 中的输入则每一输入情况下均出现故障如果没有容错措施则 R=0

( 2 )软件规模 随着软件规模的增大软件可靠性问题愈显突出在我们考虑软件

可靠性问题时软件一般是指中型以上软件 (4000-5000条以上语句 ) 这时可靠性问题难以对付

软件工程实践的一个侧面可以反映这一点即单元测试一般由编程人员本人进行而综合测试则需独立的测试人员

影响软件可靠性的因素( 3 )软件内部结构

结构越复杂软件复杂度越高内含缺陷数越大因而软件可靠度越低

( 4 )软件可靠性设计技术 一般是指软件设计阶段中采用的用以保证和提高软件可靠性为主要目标的软件技术

( 5 )软件可靠性测试 研究表明软件测试方法与资源投入对软件可靠性有不可忽视的影

响( 6 )软件可靠性管理

软件可靠性管理旨在系统管理软件生存期各阶段的可靠性活动使之系统化规范化一体化这样就可以避免许多人为错误以提高软件可靠性

影响软件可靠性的因素( 7 )软件开发人员能力和经验

软件开发人员 ( 包括测试人员 ) 的能力愈强经验愈丰富所犯错误便可能愈少所得软件产品质量愈高相应的可靠性也愈高

( 8 )软件开发方法 软件工程表明开发方法对软件可靠性有显著影响 与非结构化方法比较结构化方法可以明显减少软件缺陷数

( 9 )软件开发环境 研究表明程序语言软件开发环境影响软件的可靠性而软件测

试工具的优劣则影响可靠性测试结果

4 安全 (Safety)amp保密 (Security)

安全 (Safety) 是保证财产和人身受到损害可靠性是指在一定的环境条件下以及一定的时间内系统完成特定任务的可能性而有效性则是系统的长期的工作时间于其存在时间 ( 简单的定义为运行时间 +维护时间 ) 的 比例保密 (Security) 是针对危险破坏损失或非法活动而进行措施在一定层面上保密 (Security)要比安全 (Safety)宽广的多例如信息 Security家庭 Security 网络 Security 国家Security) 等

Security强调的是外在事物对特定目标的危害

Safety 是系统本身的潜在危害

四个概念的比较分析安全 (Safety)可靠性 (Reliability)有效性 (Availability)保密 (Security )安全 (Safety)高的系统 软件可靠性不

一定高可靠性和有效性并不是一码事保密 (Security )的系统 软件是安全

(Safety) 系统 软件的重要保障

可靠性安全性保密性 可靠(或可信)系统设计 (Reliable (or dependable) system design)是制造嵌入式系统所关注的甚至在面对内部或者外部问题时可靠系统设计经常假设问题是非恶意引起的

安全重要的系统设计 (Safety-critical system design)研究确保系统安全操作的方法独立于引起问题的原因

保密性 (Security)主要关注恶意攻击

Aizientis等人描述了可信性和保密性间的关系可信性和保密性由几个特性所组成

服务的可用性 (Availability) 服务的连续性 (Continuity) 来自用户和所处环境的灾难性后果的安全性 (Safety) 来自不合适系统改变的完整性 (Integrity) 通过更改和修补的可维护性 (Maintainability) 信息的机密性 (Confidentiality)

可用性完整性

可靠性安全性可维护性

机密性

可信性 保密性

5 新型攻击和对策1 )物理攻击嵌入式系统比通用计算机更容易受攻击 一个关键原因是许多嵌入式计算机对攻击者可物理访问

2 )互联网攻击一些嵌入式系统的攻击通过互联网访问变得更加容易今天许多嵌入式系统连接到互联网

3 )电池攻击 (battery attack)这种攻击试图通过耗尽电池来关闭节点

4 )服务拒绝攻击 (Denial-of-service attacks)

在通用系统中众所周知但是实时嵌入式系统可能更容易受服务质量 (quality-of-service (QoS))攻击如果网络发布实时数据那么发送过程中的一点延迟都能引起数据无效如果那些数据用来实时控制那么这些短暂延迟就能引起系统故障我们称这种危害为时间攻击因为它改变了系统的实时特性

QoS或者时间攻击之所以强大使因为它的影响不仅仅限于信息被控制系统的动态特性可决定系统的响应如果一个大型沉重快速运动的系统被控制那么时间上一个相对小的改变能引起大量的破坏

5 )网络(协议)攻击Wood和 Stankovic[Woo02]在传感器网络上确定了一些方式这些方式可在网络层次的不同层执行拒绝服务攻击如下所列

物理层 (Physical layer)mdashmdash拥塞破坏 链路层 (Link layer)mdashmdash碰撞耗尽非公平

网络和路由层 (Network and routing layer)mdashmdash丢弃和贪婪汇集方向误导黑洞认证监视冗余

传输层 (Transport layer)mdashmdash泛洪失步

6 )能量攻击Kocher等人 [Koc99]指出测量一个 CPU当前的能量供给能在很大程度上确定处理器的内部活动他们提出了两种能量攻击的方法简单能量分析 (simple power analysis)人工地跟踪检查和尝试确定程序作用的位置比如分支基于不同 CUP操作的能耗知识基于程序作用攻击者然后减少密钥的比特差分能量分析 (Differential power analysis)用相关性确定作用和密钥比特这种攻击最初目标是智能卡这种卡从外部读卡器获取能量但是这种攻击也能应用到许多嵌入式系统中

7 )反攻击 在一些时候有可能构造反破坏的嵌入式系统使电子设备难以发觉和分析延缓了攻击者芯片中有限的信息也有助阻止攻击者发现数据

6 Efficiency (效率)

ES must be efficient

bull Code-size efficient( 特别是片上系统 )

bull Run-time efficient

bull Weight efficient

bull Cost efficient

bull Energy efficient

能量有效性的重要意义

ldquoinherent power

efficiency of siliconldquo

59

低功耗设计问题 功耗问题是近几年来人们在嵌入式系统的设计中普遍关注的难点和热点它严重地制约着嵌入式系统的应用与发展

无论是在军事还是在商业贸易上的应用相当数量的嵌入式系统一般是由电池来供给电能的而且大多数嵌入式设备都有体积和质量的约束减少电能消耗不仅能延长电池的使用寿命延长用户更换电池的周期而且能带来提高系统性能与降低系统开销的好处甚至能起到保护环境的作用在便携式设备中 CPU消耗的电能越少电池的寿命就越长同时散发的热量少了所需的散热器就少了从而可减少该设备的花费和体积使产品尽快进入市场的目标

1 低功耗嵌入式应用系统是指以降低系统功耗为一个主要性能指标的嵌入式系统如计算机里的许多芯片过去用 5V供电现在用 33V 18V 并提出了绿色电器的概念

60

低功耗设备的要求1 )首先要求体积小重量轻便于携带2 )采用低功耗电路的设计方法以降低系统的功耗

它除了选用各种低功耗的器件和芯片外还在满足速度等性能指标的前提下进行降低功耗的硬件电路设计和软件设计

3 )有的系统应用在交流供电比较困难甚至无法用交流供电的场合因而各种电池(瓶)就成为其主要供电手段

4 )采用 LCD液晶显示器5 )采用 RS232C串行通信接口6 )采用微功耗高抗干扰的 CMOS集成电路

功耗产生的原因 P=UI

与功耗有关的因素

( 1 )电阻上消耗的功率( 2 )有源器件的开关转换阶段( 3 )集成电路内部和外部电容的充放电( 4 )系统的性能指标负载能力被处理信号的工作频率电路的工作频率电源的管理水平零部件的性能散热条件接口的物理性能等对系统功耗起着重要的作用

降低功耗的措施

功耗的组成动态 + 静态动态电源管理动态电压缩放低功耗硬件设计低功耗软件设计

二设计方法学概论

问题功 能 性能要求价 格 开发 周 期 等约束

设计 选择 折衷 分析比较 计算 评价

嵌入式系统

0嵌入式系统设计概述

方法 工具

设计方法论( design methodology )

设计方法论有以下三个重要理由1 )确认我们所做的每一件事情都是必须要作的

不会做无谓的白工也不会漏掉关键性的重要工作其中包含效率优化或是功能测试

2 )可以发展出计算机辅助工具或是设计经验累积汲取每一次产品发展的经验再经过量化之后可以发展出一套工具或是方法让往后的产品设计步入自动化

3 )开发团队遵循同一套方法论可以让团队成员更容易彼此沟通每个人都能在短时间内了解整体过程中将经历哪些过程需要何种支持与接收到何种结果此外也容易透过一套已经定义好的方法论彼此相互合作协调

设计目标 1 )上市时间

也就是 time-to-market 的观念2 )设计成本

许多消费性产品对于价格非常敏感所以产品厂商对于成本会斤斤计较是很合理的

3 )品质 顾客也许不需要最快最便宜的产品但是一定会要求功能质量保证不能只用一小段时间就坏掉了

传统的设计主要步骤

2 传统的设计流程方法1 )瀑布模型 (Waterfall)2 )螺旋模型 (Spiral)3 )连续改进 (Successive Refinement)4 )硬件与软件的同步设计 (SWHW Co-

deign)5 )阶层式 (Hierarchical) 设计6 )同步工程( concurrent

engineering )

瀑布模型 (Waterfall)

螺旋模型 (Spiral)

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 33: 大学计算机基础 —— 计算机科学概论

故障率函数 故障率

工作到某时刻尚未发生故障的产品在该时刻后单位时间内发生故障的概率称之为产品的故障率

用数学符号表示为

式中 (t) mdashmdash 故障率 dr(t) mdashmdash t 时刻后 dt 时间内故障的产品数 Ns(t) mdashmdash 残存产品数即到 t 时刻尚未故障的产品

dttN

tdrt

s )(

)()(

35

故障率函数

可按下式进行工程计算

式中 Δr(t) mdashmdash t 时刻后 Δt 时间内故障的产品数

Δt mdashmdash 所取时间间隔 Ns(t) mdashmdash 残存产品数

对于低故障率的元部件常以 10-9h 为故障率的单位称之为菲特( Fit )

ttN

trt

s

)(

)()(

产品故障浴盆曲线 浴盆曲线

大多数产品的故障率随时间的变化曲线形似浴盆称之为浴盆曲线由于产品故障机理的不同产品的故障率随时间的变化大致可以分为三个阶段

产品典型的故障率曲线

t

使用寿命

早期故障

偶然故障 耗损故障

A B规定的故障率 维修后故障率下降

(t)

3 )纠错技术( 1 )纠错码 在 1950s就开始研究最早的是可以检测和纠错的汉明码它们通过数字系统广泛地用于识别和纠正短暂或者持久的错误这些码引入冗余信息来确保一些类型的错误可以被检测和纠正比如一个单错校正 双错校正的码能用一个比特检测和纠正一个错误但是不能用两个比特纠错

( 2 )三模冗余 (triple modular

redundancy) 计算单元 C 有三个副本 C1C2和 C3三个单元接收同

样的输入一个独立单元比较每个输入的结果如果至少两个结果一致那么那个值被表决器选做正确结果如果三个结果都不相同那么就没有正确的结果

1C

2C

3C

表决错误

结果

输入

( 3 )看门狗定时器 (watchdog timer)

看门狗定时器 (watchdog timer)被广泛地用于检测系统问题如图 看门狗定时器连接到一个监视系统如果这个看门狗定时器翻转它产生一个完成信号用于标注系统的错误中断系统应该这样设计当适当运行的时候它一直在可能产生翻转信号之前复位定时器因此来自看门狗定时器的完成信号指示系统在一定程度上不合适地操作看门狗定时器用于预防不同的故障

系统看门狗定时器

完成

复位

( 4 )设计多样性 (Design diversity)

一种用于减少一些系统错误进入设计的设计方法学当一个设计需要给定模块的不同实例应该采用模块的不同实现而不是到处都用同一种模块比如一个有多个 CPU的系统可能采用不同类型的 CPU而不是到处采用同一种类型的 CPU在一个三模冗余系统产生表决结构的组件可能有不同的实现这样可以减少产生同样设计错误的机会

4 )软件可靠性ldquo在规定的条件下在规定的时间内软件不引起失效的概率rdquo

规定的条件 软件运行的软硬件环境 软件操作剖面软件运行的输入空间及其概率分布

规定的时间 日历时间 时钟时间 执行时间

激活软件 输入域 缺陷的数据

软件缺陷 软件

不可接受的结果 (软件故障) 输出域

软件故障的特点

软件与硬件可靠性的区别硬件 软件

故障机理 老化损耗 残留缺陷在一定环境下造成的软件错误

复杂性 内部逻辑较为简单 内部逻辑高度复杂这就在很大程度上决定了设计错误是导致软件故障的主要原因

唯一性 任何两个硬件不可能绝对相同

软件是唯一的软件拷贝不改变软件本身

可靠性的核心 内部元部件 设计者的思维和软件的复杂性纠错维护方法 修复或更换失效的元部件 重设计 可靠性检验标准化

已标准化且有一整套完整的理论

仍未建立更没有完整的理论体系

产品市场 已有成熟的产品市场 产品市场还很新 错误性质 一些瞬间的硬件错误可能

会被误认为是软件错误 软件错误是永恒的可重现的

影响软件可靠性的因素( 1 )运行环境 ( 剖面 )

同一软件在不同运行剖面下其可靠性行为可能极不相同 软件故障是软件缺陷在一定输入情况下被激活的结果 假设软件输入域划分为两个部分 G 和 F 运行剖面不包含 F 中

的输入则软件不会出现故障其可靠性恒为 l 反之如果运行剖面不包含 G 中的输入则每一输入情况下均出现故障如果没有容错措施则 R=0

( 2 )软件规模 随着软件规模的增大软件可靠性问题愈显突出在我们考虑软件

可靠性问题时软件一般是指中型以上软件 (4000-5000条以上语句 ) 这时可靠性问题难以对付

软件工程实践的一个侧面可以反映这一点即单元测试一般由编程人员本人进行而综合测试则需独立的测试人员

影响软件可靠性的因素( 3 )软件内部结构

结构越复杂软件复杂度越高内含缺陷数越大因而软件可靠度越低

( 4 )软件可靠性设计技术 一般是指软件设计阶段中采用的用以保证和提高软件可靠性为主要目标的软件技术

( 5 )软件可靠性测试 研究表明软件测试方法与资源投入对软件可靠性有不可忽视的影

响( 6 )软件可靠性管理

软件可靠性管理旨在系统管理软件生存期各阶段的可靠性活动使之系统化规范化一体化这样就可以避免许多人为错误以提高软件可靠性

影响软件可靠性的因素( 7 )软件开发人员能力和经验

软件开发人员 ( 包括测试人员 ) 的能力愈强经验愈丰富所犯错误便可能愈少所得软件产品质量愈高相应的可靠性也愈高

( 8 )软件开发方法 软件工程表明开发方法对软件可靠性有显著影响 与非结构化方法比较结构化方法可以明显减少软件缺陷数

( 9 )软件开发环境 研究表明程序语言软件开发环境影响软件的可靠性而软件测

试工具的优劣则影响可靠性测试结果

4 安全 (Safety)amp保密 (Security)

安全 (Safety) 是保证财产和人身受到损害可靠性是指在一定的环境条件下以及一定的时间内系统完成特定任务的可能性而有效性则是系统的长期的工作时间于其存在时间 ( 简单的定义为运行时间 +维护时间 ) 的 比例保密 (Security) 是针对危险破坏损失或非法活动而进行措施在一定层面上保密 (Security)要比安全 (Safety)宽广的多例如信息 Security家庭 Security 网络 Security 国家Security) 等

Security强调的是外在事物对特定目标的危害

Safety 是系统本身的潜在危害

四个概念的比较分析安全 (Safety)可靠性 (Reliability)有效性 (Availability)保密 (Security )安全 (Safety)高的系统 软件可靠性不

一定高可靠性和有效性并不是一码事保密 (Security )的系统 软件是安全

(Safety) 系统 软件的重要保障

可靠性安全性保密性 可靠(或可信)系统设计 (Reliable (or dependable) system design)是制造嵌入式系统所关注的甚至在面对内部或者外部问题时可靠系统设计经常假设问题是非恶意引起的

安全重要的系统设计 (Safety-critical system design)研究确保系统安全操作的方法独立于引起问题的原因

保密性 (Security)主要关注恶意攻击

Aizientis等人描述了可信性和保密性间的关系可信性和保密性由几个特性所组成

服务的可用性 (Availability) 服务的连续性 (Continuity) 来自用户和所处环境的灾难性后果的安全性 (Safety) 来自不合适系统改变的完整性 (Integrity) 通过更改和修补的可维护性 (Maintainability) 信息的机密性 (Confidentiality)

可用性完整性

可靠性安全性可维护性

机密性

可信性 保密性

5 新型攻击和对策1 )物理攻击嵌入式系统比通用计算机更容易受攻击 一个关键原因是许多嵌入式计算机对攻击者可物理访问

2 )互联网攻击一些嵌入式系统的攻击通过互联网访问变得更加容易今天许多嵌入式系统连接到互联网

3 )电池攻击 (battery attack)这种攻击试图通过耗尽电池来关闭节点

4 )服务拒绝攻击 (Denial-of-service attacks)

在通用系统中众所周知但是实时嵌入式系统可能更容易受服务质量 (quality-of-service (QoS))攻击如果网络发布实时数据那么发送过程中的一点延迟都能引起数据无效如果那些数据用来实时控制那么这些短暂延迟就能引起系统故障我们称这种危害为时间攻击因为它改变了系统的实时特性

QoS或者时间攻击之所以强大使因为它的影响不仅仅限于信息被控制系统的动态特性可决定系统的响应如果一个大型沉重快速运动的系统被控制那么时间上一个相对小的改变能引起大量的破坏

5 )网络(协议)攻击Wood和 Stankovic[Woo02]在传感器网络上确定了一些方式这些方式可在网络层次的不同层执行拒绝服务攻击如下所列

物理层 (Physical layer)mdashmdash拥塞破坏 链路层 (Link layer)mdashmdash碰撞耗尽非公平

网络和路由层 (Network and routing layer)mdashmdash丢弃和贪婪汇集方向误导黑洞认证监视冗余

传输层 (Transport layer)mdashmdash泛洪失步

6 )能量攻击Kocher等人 [Koc99]指出测量一个 CPU当前的能量供给能在很大程度上确定处理器的内部活动他们提出了两种能量攻击的方法简单能量分析 (simple power analysis)人工地跟踪检查和尝试确定程序作用的位置比如分支基于不同 CUP操作的能耗知识基于程序作用攻击者然后减少密钥的比特差分能量分析 (Differential power analysis)用相关性确定作用和密钥比特这种攻击最初目标是智能卡这种卡从外部读卡器获取能量但是这种攻击也能应用到许多嵌入式系统中

7 )反攻击 在一些时候有可能构造反破坏的嵌入式系统使电子设备难以发觉和分析延缓了攻击者芯片中有限的信息也有助阻止攻击者发现数据

6 Efficiency (效率)

ES must be efficient

bull Code-size efficient( 特别是片上系统 )

bull Run-time efficient

bull Weight efficient

bull Cost efficient

bull Energy efficient

能量有效性的重要意义

ldquoinherent power

efficiency of siliconldquo

59

低功耗设计问题 功耗问题是近几年来人们在嵌入式系统的设计中普遍关注的难点和热点它严重地制约着嵌入式系统的应用与发展

无论是在军事还是在商业贸易上的应用相当数量的嵌入式系统一般是由电池来供给电能的而且大多数嵌入式设备都有体积和质量的约束减少电能消耗不仅能延长电池的使用寿命延长用户更换电池的周期而且能带来提高系统性能与降低系统开销的好处甚至能起到保护环境的作用在便携式设备中 CPU消耗的电能越少电池的寿命就越长同时散发的热量少了所需的散热器就少了从而可减少该设备的花费和体积使产品尽快进入市场的目标

1 低功耗嵌入式应用系统是指以降低系统功耗为一个主要性能指标的嵌入式系统如计算机里的许多芯片过去用 5V供电现在用 33V 18V 并提出了绿色电器的概念

60

低功耗设备的要求1 )首先要求体积小重量轻便于携带2 )采用低功耗电路的设计方法以降低系统的功耗

它除了选用各种低功耗的器件和芯片外还在满足速度等性能指标的前提下进行降低功耗的硬件电路设计和软件设计

3 )有的系统应用在交流供电比较困难甚至无法用交流供电的场合因而各种电池(瓶)就成为其主要供电手段

4 )采用 LCD液晶显示器5 )采用 RS232C串行通信接口6 )采用微功耗高抗干扰的 CMOS集成电路

功耗产生的原因 P=UI

与功耗有关的因素

( 1 )电阻上消耗的功率( 2 )有源器件的开关转换阶段( 3 )集成电路内部和外部电容的充放电( 4 )系统的性能指标负载能力被处理信号的工作频率电路的工作频率电源的管理水平零部件的性能散热条件接口的物理性能等对系统功耗起着重要的作用

降低功耗的措施

功耗的组成动态 + 静态动态电源管理动态电压缩放低功耗硬件设计低功耗软件设计

二设计方法学概论

问题功 能 性能要求价 格 开发 周 期 等约束

设计 选择 折衷 分析比较 计算 评价

嵌入式系统

0嵌入式系统设计概述

方法 工具

设计方法论( design methodology )

设计方法论有以下三个重要理由1 )确认我们所做的每一件事情都是必须要作的

不会做无谓的白工也不会漏掉关键性的重要工作其中包含效率优化或是功能测试

2 )可以发展出计算机辅助工具或是设计经验累积汲取每一次产品发展的经验再经过量化之后可以发展出一套工具或是方法让往后的产品设计步入自动化

3 )开发团队遵循同一套方法论可以让团队成员更容易彼此沟通每个人都能在短时间内了解整体过程中将经历哪些过程需要何种支持与接收到何种结果此外也容易透过一套已经定义好的方法论彼此相互合作协调

设计目标 1 )上市时间

也就是 time-to-market 的观念2 )设计成本

许多消费性产品对于价格非常敏感所以产品厂商对于成本会斤斤计较是很合理的

3 )品质 顾客也许不需要最快最便宜的产品但是一定会要求功能质量保证不能只用一小段时间就坏掉了

传统的设计主要步骤

2 传统的设计流程方法1 )瀑布模型 (Waterfall)2 )螺旋模型 (Spiral)3 )连续改进 (Successive Refinement)4 )硬件与软件的同步设计 (SWHW Co-

deign)5 )阶层式 (Hierarchical) 设计6 )同步工程( concurrent

engineering )

瀑布模型 (Waterfall)

螺旋模型 (Spiral)

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 34: 大学计算机基础 —— 计算机科学概论

35

故障率函数

可按下式进行工程计算

式中 Δr(t) mdashmdash t 时刻后 Δt 时间内故障的产品数

Δt mdashmdash 所取时间间隔 Ns(t) mdashmdash 残存产品数

对于低故障率的元部件常以 10-9h 为故障率的单位称之为菲特( Fit )

ttN

trt

s

)(

)()(

产品故障浴盆曲线 浴盆曲线

大多数产品的故障率随时间的变化曲线形似浴盆称之为浴盆曲线由于产品故障机理的不同产品的故障率随时间的变化大致可以分为三个阶段

产品典型的故障率曲线

t

使用寿命

早期故障

偶然故障 耗损故障

A B规定的故障率 维修后故障率下降

(t)

3 )纠错技术( 1 )纠错码 在 1950s就开始研究最早的是可以检测和纠错的汉明码它们通过数字系统广泛地用于识别和纠正短暂或者持久的错误这些码引入冗余信息来确保一些类型的错误可以被检测和纠正比如一个单错校正 双错校正的码能用一个比特检测和纠正一个错误但是不能用两个比特纠错

( 2 )三模冗余 (triple modular

redundancy) 计算单元 C 有三个副本 C1C2和 C3三个单元接收同

样的输入一个独立单元比较每个输入的结果如果至少两个结果一致那么那个值被表决器选做正确结果如果三个结果都不相同那么就没有正确的结果

1C

2C

3C

表决错误

结果

输入

( 3 )看门狗定时器 (watchdog timer)

看门狗定时器 (watchdog timer)被广泛地用于检测系统问题如图 看门狗定时器连接到一个监视系统如果这个看门狗定时器翻转它产生一个完成信号用于标注系统的错误中断系统应该这样设计当适当运行的时候它一直在可能产生翻转信号之前复位定时器因此来自看门狗定时器的完成信号指示系统在一定程度上不合适地操作看门狗定时器用于预防不同的故障

系统看门狗定时器

完成

复位

( 4 )设计多样性 (Design diversity)

一种用于减少一些系统错误进入设计的设计方法学当一个设计需要给定模块的不同实例应该采用模块的不同实现而不是到处都用同一种模块比如一个有多个 CPU的系统可能采用不同类型的 CPU而不是到处采用同一种类型的 CPU在一个三模冗余系统产生表决结构的组件可能有不同的实现这样可以减少产生同样设计错误的机会

4 )软件可靠性ldquo在规定的条件下在规定的时间内软件不引起失效的概率rdquo

规定的条件 软件运行的软硬件环境 软件操作剖面软件运行的输入空间及其概率分布

规定的时间 日历时间 时钟时间 执行时间

激活软件 输入域 缺陷的数据

软件缺陷 软件

不可接受的结果 (软件故障) 输出域

软件故障的特点

软件与硬件可靠性的区别硬件 软件

故障机理 老化损耗 残留缺陷在一定环境下造成的软件错误

复杂性 内部逻辑较为简单 内部逻辑高度复杂这就在很大程度上决定了设计错误是导致软件故障的主要原因

唯一性 任何两个硬件不可能绝对相同

软件是唯一的软件拷贝不改变软件本身

可靠性的核心 内部元部件 设计者的思维和软件的复杂性纠错维护方法 修复或更换失效的元部件 重设计 可靠性检验标准化

已标准化且有一整套完整的理论

仍未建立更没有完整的理论体系

产品市场 已有成熟的产品市场 产品市场还很新 错误性质 一些瞬间的硬件错误可能

会被误认为是软件错误 软件错误是永恒的可重现的

影响软件可靠性的因素( 1 )运行环境 ( 剖面 )

同一软件在不同运行剖面下其可靠性行为可能极不相同 软件故障是软件缺陷在一定输入情况下被激活的结果 假设软件输入域划分为两个部分 G 和 F 运行剖面不包含 F 中

的输入则软件不会出现故障其可靠性恒为 l 反之如果运行剖面不包含 G 中的输入则每一输入情况下均出现故障如果没有容错措施则 R=0

( 2 )软件规模 随着软件规模的增大软件可靠性问题愈显突出在我们考虑软件

可靠性问题时软件一般是指中型以上软件 (4000-5000条以上语句 ) 这时可靠性问题难以对付

软件工程实践的一个侧面可以反映这一点即单元测试一般由编程人员本人进行而综合测试则需独立的测试人员

影响软件可靠性的因素( 3 )软件内部结构

结构越复杂软件复杂度越高内含缺陷数越大因而软件可靠度越低

( 4 )软件可靠性设计技术 一般是指软件设计阶段中采用的用以保证和提高软件可靠性为主要目标的软件技术

( 5 )软件可靠性测试 研究表明软件测试方法与资源投入对软件可靠性有不可忽视的影

响( 6 )软件可靠性管理

软件可靠性管理旨在系统管理软件生存期各阶段的可靠性活动使之系统化规范化一体化这样就可以避免许多人为错误以提高软件可靠性

影响软件可靠性的因素( 7 )软件开发人员能力和经验

软件开发人员 ( 包括测试人员 ) 的能力愈强经验愈丰富所犯错误便可能愈少所得软件产品质量愈高相应的可靠性也愈高

( 8 )软件开发方法 软件工程表明开发方法对软件可靠性有显著影响 与非结构化方法比较结构化方法可以明显减少软件缺陷数

( 9 )软件开发环境 研究表明程序语言软件开发环境影响软件的可靠性而软件测

试工具的优劣则影响可靠性测试结果

4 安全 (Safety)amp保密 (Security)

安全 (Safety) 是保证财产和人身受到损害可靠性是指在一定的环境条件下以及一定的时间内系统完成特定任务的可能性而有效性则是系统的长期的工作时间于其存在时间 ( 简单的定义为运行时间 +维护时间 ) 的 比例保密 (Security) 是针对危险破坏损失或非法活动而进行措施在一定层面上保密 (Security)要比安全 (Safety)宽广的多例如信息 Security家庭 Security 网络 Security 国家Security) 等

Security强调的是外在事物对特定目标的危害

Safety 是系统本身的潜在危害

四个概念的比较分析安全 (Safety)可靠性 (Reliability)有效性 (Availability)保密 (Security )安全 (Safety)高的系统 软件可靠性不

一定高可靠性和有效性并不是一码事保密 (Security )的系统 软件是安全

(Safety) 系统 软件的重要保障

可靠性安全性保密性 可靠(或可信)系统设计 (Reliable (or dependable) system design)是制造嵌入式系统所关注的甚至在面对内部或者外部问题时可靠系统设计经常假设问题是非恶意引起的

安全重要的系统设计 (Safety-critical system design)研究确保系统安全操作的方法独立于引起问题的原因

保密性 (Security)主要关注恶意攻击

Aizientis等人描述了可信性和保密性间的关系可信性和保密性由几个特性所组成

服务的可用性 (Availability) 服务的连续性 (Continuity) 来自用户和所处环境的灾难性后果的安全性 (Safety) 来自不合适系统改变的完整性 (Integrity) 通过更改和修补的可维护性 (Maintainability) 信息的机密性 (Confidentiality)

可用性完整性

可靠性安全性可维护性

机密性

可信性 保密性

5 新型攻击和对策1 )物理攻击嵌入式系统比通用计算机更容易受攻击 一个关键原因是许多嵌入式计算机对攻击者可物理访问

2 )互联网攻击一些嵌入式系统的攻击通过互联网访问变得更加容易今天许多嵌入式系统连接到互联网

3 )电池攻击 (battery attack)这种攻击试图通过耗尽电池来关闭节点

4 )服务拒绝攻击 (Denial-of-service attacks)

在通用系统中众所周知但是实时嵌入式系统可能更容易受服务质量 (quality-of-service (QoS))攻击如果网络发布实时数据那么发送过程中的一点延迟都能引起数据无效如果那些数据用来实时控制那么这些短暂延迟就能引起系统故障我们称这种危害为时间攻击因为它改变了系统的实时特性

QoS或者时间攻击之所以强大使因为它的影响不仅仅限于信息被控制系统的动态特性可决定系统的响应如果一个大型沉重快速运动的系统被控制那么时间上一个相对小的改变能引起大量的破坏

5 )网络(协议)攻击Wood和 Stankovic[Woo02]在传感器网络上确定了一些方式这些方式可在网络层次的不同层执行拒绝服务攻击如下所列

物理层 (Physical layer)mdashmdash拥塞破坏 链路层 (Link layer)mdashmdash碰撞耗尽非公平

网络和路由层 (Network and routing layer)mdashmdash丢弃和贪婪汇集方向误导黑洞认证监视冗余

传输层 (Transport layer)mdashmdash泛洪失步

6 )能量攻击Kocher等人 [Koc99]指出测量一个 CPU当前的能量供给能在很大程度上确定处理器的内部活动他们提出了两种能量攻击的方法简单能量分析 (simple power analysis)人工地跟踪检查和尝试确定程序作用的位置比如分支基于不同 CUP操作的能耗知识基于程序作用攻击者然后减少密钥的比特差分能量分析 (Differential power analysis)用相关性确定作用和密钥比特这种攻击最初目标是智能卡这种卡从外部读卡器获取能量但是这种攻击也能应用到许多嵌入式系统中

7 )反攻击 在一些时候有可能构造反破坏的嵌入式系统使电子设备难以发觉和分析延缓了攻击者芯片中有限的信息也有助阻止攻击者发现数据

6 Efficiency (效率)

ES must be efficient

bull Code-size efficient( 特别是片上系统 )

bull Run-time efficient

bull Weight efficient

bull Cost efficient

bull Energy efficient

能量有效性的重要意义

ldquoinherent power

efficiency of siliconldquo

59

低功耗设计问题 功耗问题是近几年来人们在嵌入式系统的设计中普遍关注的难点和热点它严重地制约着嵌入式系统的应用与发展

无论是在军事还是在商业贸易上的应用相当数量的嵌入式系统一般是由电池来供给电能的而且大多数嵌入式设备都有体积和质量的约束减少电能消耗不仅能延长电池的使用寿命延长用户更换电池的周期而且能带来提高系统性能与降低系统开销的好处甚至能起到保护环境的作用在便携式设备中 CPU消耗的电能越少电池的寿命就越长同时散发的热量少了所需的散热器就少了从而可减少该设备的花费和体积使产品尽快进入市场的目标

1 低功耗嵌入式应用系统是指以降低系统功耗为一个主要性能指标的嵌入式系统如计算机里的许多芯片过去用 5V供电现在用 33V 18V 并提出了绿色电器的概念

60

低功耗设备的要求1 )首先要求体积小重量轻便于携带2 )采用低功耗电路的设计方法以降低系统的功耗

它除了选用各种低功耗的器件和芯片外还在满足速度等性能指标的前提下进行降低功耗的硬件电路设计和软件设计

3 )有的系统应用在交流供电比较困难甚至无法用交流供电的场合因而各种电池(瓶)就成为其主要供电手段

4 )采用 LCD液晶显示器5 )采用 RS232C串行通信接口6 )采用微功耗高抗干扰的 CMOS集成电路

功耗产生的原因 P=UI

与功耗有关的因素

( 1 )电阻上消耗的功率( 2 )有源器件的开关转换阶段( 3 )集成电路内部和外部电容的充放电( 4 )系统的性能指标负载能力被处理信号的工作频率电路的工作频率电源的管理水平零部件的性能散热条件接口的物理性能等对系统功耗起着重要的作用

降低功耗的措施

功耗的组成动态 + 静态动态电源管理动态电压缩放低功耗硬件设计低功耗软件设计

二设计方法学概论

问题功 能 性能要求价 格 开发 周 期 等约束

设计 选择 折衷 分析比较 计算 评价

嵌入式系统

0嵌入式系统设计概述

方法 工具

设计方法论( design methodology )

设计方法论有以下三个重要理由1 )确认我们所做的每一件事情都是必须要作的

不会做无谓的白工也不会漏掉关键性的重要工作其中包含效率优化或是功能测试

2 )可以发展出计算机辅助工具或是设计经验累积汲取每一次产品发展的经验再经过量化之后可以发展出一套工具或是方法让往后的产品设计步入自动化

3 )开发团队遵循同一套方法论可以让团队成员更容易彼此沟通每个人都能在短时间内了解整体过程中将经历哪些过程需要何种支持与接收到何种结果此外也容易透过一套已经定义好的方法论彼此相互合作协调

设计目标 1 )上市时间

也就是 time-to-market 的观念2 )设计成本

许多消费性产品对于价格非常敏感所以产品厂商对于成本会斤斤计较是很合理的

3 )品质 顾客也许不需要最快最便宜的产品但是一定会要求功能质量保证不能只用一小段时间就坏掉了

传统的设计主要步骤

2 传统的设计流程方法1 )瀑布模型 (Waterfall)2 )螺旋模型 (Spiral)3 )连续改进 (Successive Refinement)4 )硬件与软件的同步设计 (SWHW Co-

deign)5 )阶层式 (Hierarchical) 设计6 )同步工程( concurrent

engineering )

瀑布模型 (Waterfall)

螺旋模型 (Spiral)

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 35: 大学计算机基础 —— 计算机科学概论

产品故障浴盆曲线 浴盆曲线

大多数产品的故障率随时间的变化曲线形似浴盆称之为浴盆曲线由于产品故障机理的不同产品的故障率随时间的变化大致可以分为三个阶段

产品典型的故障率曲线

t

使用寿命

早期故障

偶然故障 耗损故障

A B规定的故障率 维修后故障率下降

(t)

3 )纠错技术( 1 )纠错码 在 1950s就开始研究最早的是可以检测和纠错的汉明码它们通过数字系统广泛地用于识别和纠正短暂或者持久的错误这些码引入冗余信息来确保一些类型的错误可以被检测和纠正比如一个单错校正 双错校正的码能用一个比特检测和纠正一个错误但是不能用两个比特纠错

( 2 )三模冗余 (triple modular

redundancy) 计算单元 C 有三个副本 C1C2和 C3三个单元接收同

样的输入一个独立单元比较每个输入的结果如果至少两个结果一致那么那个值被表决器选做正确结果如果三个结果都不相同那么就没有正确的结果

1C

2C

3C

表决错误

结果

输入

( 3 )看门狗定时器 (watchdog timer)

看门狗定时器 (watchdog timer)被广泛地用于检测系统问题如图 看门狗定时器连接到一个监视系统如果这个看门狗定时器翻转它产生一个完成信号用于标注系统的错误中断系统应该这样设计当适当运行的时候它一直在可能产生翻转信号之前复位定时器因此来自看门狗定时器的完成信号指示系统在一定程度上不合适地操作看门狗定时器用于预防不同的故障

系统看门狗定时器

完成

复位

( 4 )设计多样性 (Design diversity)

一种用于减少一些系统错误进入设计的设计方法学当一个设计需要给定模块的不同实例应该采用模块的不同实现而不是到处都用同一种模块比如一个有多个 CPU的系统可能采用不同类型的 CPU而不是到处采用同一种类型的 CPU在一个三模冗余系统产生表决结构的组件可能有不同的实现这样可以减少产生同样设计错误的机会

4 )软件可靠性ldquo在规定的条件下在规定的时间内软件不引起失效的概率rdquo

规定的条件 软件运行的软硬件环境 软件操作剖面软件运行的输入空间及其概率分布

规定的时间 日历时间 时钟时间 执行时间

激活软件 输入域 缺陷的数据

软件缺陷 软件

不可接受的结果 (软件故障) 输出域

软件故障的特点

软件与硬件可靠性的区别硬件 软件

故障机理 老化损耗 残留缺陷在一定环境下造成的软件错误

复杂性 内部逻辑较为简单 内部逻辑高度复杂这就在很大程度上决定了设计错误是导致软件故障的主要原因

唯一性 任何两个硬件不可能绝对相同

软件是唯一的软件拷贝不改变软件本身

可靠性的核心 内部元部件 设计者的思维和软件的复杂性纠错维护方法 修复或更换失效的元部件 重设计 可靠性检验标准化

已标准化且有一整套完整的理论

仍未建立更没有完整的理论体系

产品市场 已有成熟的产品市场 产品市场还很新 错误性质 一些瞬间的硬件错误可能

会被误认为是软件错误 软件错误是永恒的可重现的

影响软件可靠性的因素( 1 )运行环境 ( 剖面 )

同一软件在不同运行剖面下其可靠性行为可能极不相同 软件故障是软件缺陷在一定输入情况下被激活的结果 假设软件输入域划分为两个部分 G 和 F 运行剖面不包含 F 中

的输入则软件不会出现故障其可靠性恒为 l 反之如果运行剖面不包含 G 中的输入则每一输入情况下均出现故障如果没有容错措施则 R=0

( 2 )软件规模 随着软件规模的增大软件可靠性问题愈显突出在我们考虑软件

可靠性问题时软件一般是指中型以上软件 (4000-5000条以上语句 ) 这时可靠性问题难以对付

软件工程实践的一个侧面可以反映这一点即单元测试一般由编程人员本人进行而综合测试则需独立的测试人员

影响软件可靠性的因素( 3 )软件内部结构

结构越复杂软件复杂度越高内含缺陷数越大因而软件可靠度越低

( 4 )软件可靠性设计技术 一般是指软件设计阶段中采用的用以保证和提高软件可靠性为主要目标的软件技术

( 5 )软件可靠性测试 研究表明软件测试方法与资源投入对软件可靠性有不可忽视的影

响( 6 )软件可靠性管理

软件可靠性管理旨在系统管理软件生存期各阶段的可靠性活动使之系统化规范化一体化这样就可以避免许多人为错误以提高软件可靠性

影响软件可靠性的因素( 7 )软件开发人员能力和经验

软件开发人员 ( 包括测试人员 ) 的能力愈强经验愈丰富所犯错误便可能愈少所得软件产品质量愈高相应的可靠性也愈高

( 8 )软件开发方法 软件工程表明开发方法对软件可靠性有显著影响 与非结构化方法比较结构化方法可以明显减少软件缺陷数

( 9 )软件开发环境 研究表明程序语言软件开发环境影响软件的可靠性而软件测

试工具的优劣则影响可靠性测试结果

4 安全 (Safety)amp保密 (Security)

安全 (Safety) 是保证财产和人身受到损害可靠性是指在一定的环境条件下以及一定的时间内系统完成特定任务的可能性而有效性则是系统的长期的工作时间于其存在时间 ( 简单的定义为运行时间 +维护时间 ) 的 比例保密 (Security) 是针对危险破坏损失或非法活动而进行措施在一定层面上保密 (Security)要比安全 (Safety)宽广的多例如信息 Security家庭 Security 网络 Security 国家Security) 等

Security强调的是外在事物对特定目标的危害

Safety 是系统本身的潜在危害

四个概念的比较分析安全 (Safety)可靠性 (Reliability)有效性 (Availability)保密 (Security )安全 (Safety)高的系统 软件可靠性不

一定高可靠性和有效性并不是一码事保密 (Security )的系统 软件是安全

(Safety) 系统 软件的重要保障

可靠性安全性保密性 可靠(或可信)系统设计 (Reliable (or dependable) system design)是制造嵌入式系统所关注的甚至在面对内部或者外部问题时可靠系统设计经常假设问题是非恶意引起的

安全重要的系统设计 (Safety-critical system design)研究确保系统安全操作的方法独立于引起问题的原因

保密性 (Security)主要关注恶意攻击

Aizientis等人描述了可信性和保密性间的关系可信性和保密性由几个特性所组成

服务的可用性 (Availability) 服务的连续性 (Continuity) 来自用户和所处环境的灾难性后果的安全性 (Safety) 来自不合适系统改变的完整性 (Integrity) 通过更改和修补的可维护性 (Maintainability) 信息的机密性 (Confidentiality)

可用性完整性

可靠性安全性可维护性

机密性

可信性 保密性

5 新型攻击和对策1 )物理攻击嵌入式系统比通用计算机更容易受攻击 一个关键原因是许多嵌入式计算机对攻击者可物理访问

2 )互联网攻击一些嵌入式系统的攻击通过互联网访问变得更加容易今天许多嵌入式系统连接到互联网

3 )电池攻击 (battery attack)这种攻击试图通过耗尽电池来关闭节点

4 )服务拒绝攻击 (Denial-of-service attacks)

在通用系统中众所周知但是实时嵌入式系统可能更容易受服务质量 (quality-of-service (QoS))攻击如果网络发布实时数据那么发送过程中的一点延迟都能引起数据无效如果那些数据用来实时控制那么这些短暂延迟就能引起系统故障我们称这种危害为时间攻击因为它改变了系统的实时特性

QoS或者时间攻击之所以强大使因为它的影响不仅仅限于信息被控制系统的动态特性可决定系统的响应如果一个大型沉重快速运动的系统被控制那么时间上一个相对小的改变能引起大量的破坏

5 )网络(协议)攻击Wood和 Stankovic[Woo02]在传感器网络上确定了一些方式这些方式可在网络层次的不同层执行拒绝服务攻击如下所列

物理层 (Physical layer)mdashmdash拥塞破坏 链路层 (Link layer)mdashmdash碰撞耗尽非公平

网络和路由层 (Network and routing layer)mdashmdash丢弃和贪婪汇集方向误导黑洞认证监视冗余

传输层 (Transport layer)mdashmdash泛洪失步

6 )能量攻击Kocher等人 [Koc99]指出测量一个 CPU当前的能量供给能在很大程度上确定处理器的内部活动他们提出了两种能量攻击的方法简单能量分析 (simple power analysis)人工地跟踪检查和尝试确定程序作用的位置比如分支基于不同 CUP操作的能耗知识基于程序作用攻击者然后减少密钥的比特差分能量分析 (Differential power analysis)用相关性确定作用和密钥比特这种攻击最初目标是智能卡这种卡从外部读卡器获取能量但是这种攻击也能应用到许多嵌入式系统中

7 )反攻击 在一些时候有可能构造反破坏的嵌入式系统使电子设备难以发觉和分析延缓了攻击者芯片中有限的信息也有助阻止攻击者发现数据

6 Efficiency (效率)

ES must be efficient

bull Code-size efficient( 特别是片上系统 )

bull Run-time efficient

bull Weight efficient

bull Cost efficient

bull Energy efficient

能量有效性的重要意义

ldquoinherent power

efficiency of siliconldquo

59

低功耗设计问题 功耗问题是近几年来人们在嵌入式系统的设计中普遍关注的难点和热点它严重地制约着嵌入式系统的应用与发展

无论是在军事还是在商业贸易上的应用相当数量的嵌入式系统一般是由电池来供给电能的而且大多数嵌入式设备都有体积和质量的约束减少电能消耗不仅能延长电池的使用寿命延长用户更换电池的周期而且能带来提高系统性能与降低系统开销的好处甚至能起到保护环境的作用在便携式设备中 CPU消耗的电能越少电池的寿命就越长同时散发的热量少了所需的散热器就少了从而可减少该设备的花费和体积使产品尽快进入市场的目标

1 低功耗嵌入式应用系统是指以降低系统功耗为一个主要性能指标的嵌入式系统如计算机里的许多芯片过去用 5V供电现在用 33V 18V 并提出了绿色电器的概念

60

低功耗设备的要求1 )首先要求体积小重量轻便于携带2 )采用低功耗电路的设计方法以降低系统的功耗

它除了选用各种低功耗的器件和芯片外还在满足速度等性能指标的前提下进行降低功耗的硬件电路设计和软件设计

3 )有的系统应用在交流供电比较困难甚至无法用交流供电的场合因而各种电池(瓶)就成为其主要供电手段

4 )采用 LCD液晶显示器5 )采用 RS232C串行通信接口6 )采用微功耗高抗干扰的 CMOS集成电路

功耗产生的原因 P=UI

与功耗有关的因素

( 1 )电阻上消耗的功率( 2 )有源器件的开关转换阶段( 3 )集成电路内部和外部电容的充放电( 4 )系统的性能指标负载能力被处理信号的工作频率电路的工作频率电源的管理水平零部件的性能散热条件接口的物理性能等对系统功耗起着重要的作用

降低功耗的措施

功耗的组成动态 + 静态动态电源管理动态电压缩放低功耗硬件设计低功耗软件设计

二设计方法学概论

问题功 能 性能要求价 格 开发 周 期 等约束

设计 选择 折衷 分析比较 计算 评价

嵌入式系统

0嵌入式系统设计概述

方法 工具

设计方法论( design methodology )

设计方法论有以下三个重要理由1 )确认我们所做的每一件事情都是必须要作的

不会做无谓的白工也不会漏掉关键性的重要工作其中包含效率优化或是功能测试

2 )可以发展出计算机辅助工具或是设计经验累积汲取每一次产品发展的经验再经过量化之后可以发展出一套工具或是方法让往后的产品设计步入自动化

3 )开发团队遵循同一套方法论可以让团队成员更容易彼此沟通每个人都能在短时间内了解整体过程中将经历哪些过程需要何种支持与接收到何种结果此外也容易透过一套已经定义好的方法论彼此相互合作协调

设计目标 1 )上市时间

也就是 time-to-market 的观念2 )设计成本

许多消费性产品对于价格非常敏感所以产品厂商对于成本会斤斤计较是很合理的

3 )品质 顾客也许不需要最快最便宜的产品但是一定会要求功能质量保证不能只用一小段时间就坏掉了

传统的设计主要步骤

2 传统的设计流程方法1 )瀑布模型 (Waterfall)2 )螺旋模型 (Spiral)3 )连续改进 (Successive Refinement)4 )硬件与软件的同步设计 (SWHW Co-

deign)5 )阶层式 (Hierarchical) 设计6 )同步工程( concurrent

engineering )

瀑布模型 (Waterfall)

螺旋模型 (Spiral)

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 36: 大学计算机基础 —— 计算机科学概论

3 )纠错技术( 1 )纠错码 在 1950s就开始研究最早的是可以检测和纠错的汉明码它们通过数字系统广泛地用于识别和纠正短暂或者持久的错误这些码引入冗余信息来确保一些类型的错误可以被检测和纠正比如一个单错校正 双错校正的码能用一个比特检测和纠正一个错误但是不能用两个比特纠错

( 2 )三模冗余 (triple modular

redundancy) 计算单元 C 有三个副本 C1C2和 C3三个单元接收同

样的输入一个独立单元比较每个输入的结果如果至少两个结果一致那么那个值被表决器选做正确结果如果三个结果都不相同那么就没有正确的结果

1C

2C

3C

表决错误

结果

输入

( 3 )看门狗定时器 (watchdog timer)

看门狗定时器 (watchdog timer)被广泛地用于检测系统问题如图 看门狗定时器连接到一个监视系统如果这个看门狗定时器翻转它产生一个完成信号用于标注系统的错误中断系统应该这样设计当适当运行的时候它一直在可能产生翻转信号之前复位定时器因此来自看门狗定时器的完成信号指示系统在一定程度上不合适地操作看门狗定时器用于预防不同的故障

系统看门狗定时器

完成

复位

( 4 )设计多样性 (Design diversity)

一种用于减少一些系统错误进入设计的设计方法学当一个设计需要给定模块的不同实例应该采用模块的不同实现而不是到处都用同一种模块比如一个有多个 CPU的系统可能采用不同类型的 CPU而不是到处采用同一种类型的 CPU在一个三模冗余系统产生表决结构的组件可能有不同的实现这样可以减少产生同样设计错误的机会

4 )软件可靠性ldquo在规定的条件下在规定的时间内软件不引起失效的概率rdquo

规定的条件 软件运行的软硬件环境 软件操作剖面软件运行的输入空间及其概率分布

规定的时间 日历时间 时钟时间 执行时间

激活软件 输入域 缺陷的数据

软件缺陷 软件

不可接受的结果 (软件故障) 输出域

软件故障的特点

软件与硬件可靠性的区别硬件 软件

故障机理 老化损耗 残留缺陷在一定环境下造成的软件错误

复杂性 内部逻辑较为简单 内部逻辑高度复杂这就在很大程度上决定了设计错误是导致软件故障的主要原因

唯一性 任何两个硬件不可能绝对相同

软件是唯一的软件拷贝不改变软件本身

可靠性的核心 内部元部件 设计者的思维和软件的复杂性纠错维护方法 修复或更换失效的元部件 重设计 可靠性检验标准化

已标准化且有一整套完整的理论

仍未建立更没有完整的理论体系

产品市场 已有成熟的产品市场 产品市场还很新 错误性质 一些瞬间的硬件错误可能

会被误认为是软件错误 软件错误是永恒的可重现的

影响软件可靠性的因素( 1 )运行环境 ( 剖面 )

同一软件在不同运行剖面下其可靠性行为可能极不相同 软件故障是软件缺陷在一定输入情况下被激活的结果 假设软件输入域划分为两个部分 G 和 F 运行剖面不包含 F 中

的输入则软件不会出现故障其可靠性恒为 l 反之如果运行剖面不包含 G 中的输入则每一输入情况下均出现故障如果没有容错措施则 R=0

( 2 )软件规模 随着软件规模的增大软件可靠性问题愈显突出在我们考虑软件

可靠性问题时软件一般是指中型以上软件 (4000-5000条以上语句 ) 这时可靠性问题难以对付

软件工程实践的一个侧面可以反映这一点即单元测试一般由编程人员本人进行而综合测试则需独立的测试人员

影响软件可靠性的因素( 3 )软件内部结构

结构越复杂软件复杂度越高内含缺陷数越大因而软件可靠度越低

( 4 )软件可靠性设计技术 一般是指软件设计阶段中采用的用以保证和提高软件可靠性为主要目标的软件技术

( 5 )软件可靠性测试 研究表明软件测试方法与资源投入对软件可靠性有不可忽视的影

响( 6 )软件可靠性管理

软件可靠性管理旨在系统管理软件生存期各阶段的可靠性活动使之系统化规范化一体化这样就可以避免许多人为错误以提高软件可靠性

影响软件可靠性的因素( 7 )软件开发人员能力和经验

软件开发人员 ( 包括测试人员 ) 的能力愈强经验愈丰富所犯错误便可能愈少所得软件产品质量愈高相应的可靠性也愈高

( 8 )软件开发方法 软件工程表明开发方法对软件可靠性有显著影响 与非结构化方法比较结构化方法可以明显减少软件缺陷数

( 9 )软件开发环境 研究表明程序语言软件开发环境影响软件的可靠性而软件测

试工具的优劣则影响可靠性测试结果

4 安全 (Safety)amp保密 (Security)

安全 (Safety) 是保证财产和人身受到损害可靠性是指在一定的环境条件下以及一定的时间内系统完成特定任务的可能性而有效性则是系统的长期的工作时间于其存在时间 ( 简单的定义为运行时间 +维护时间 ) 的 比例保密 (Security) 是针对危险破坏损失或非法活动而进行措施在一定层面上保密 (Security)要比安全 (Safety)宽广的多例如信息 Security家庭 Security 网络 Security 国家Security) 等

Security强调的是外在事物对特定目标的危害

Safety 是系统本身的潜在危害

四个概念的比较分析安全 (Safety)可靠性 (Reliability)有效性 (Availability)保密 (Security )安全 (Safety)高的系统 软件可靠性不

一定高可靠性和有效性并不是一码事保密 (Security )的系统 软件是安全

(Safety) 系统 软件的重要保障

可靠性安全性保密性 可靠(或可信)系统设计 (Reliable (or dependable) system design)是制造嵌入式系统所关注的甚至在面对内部或者外部问题时可靠系统设计经常假设问题是非恶意引起的

安全重要的系统设计 (Safety-critical system design)研究确保系统安全操作的方法独立于引起问题的原因

保密性 (Security)主要关注恶意攻击

Aizientis等人描述了可信性和保密性间的关系可信性和保密性由几个特性所组成

服务的可用性 (Availability) 服务的连续性 (Continuity) 来自用户和所处环境的灾难性后果的安全性 (Safety) 来自不合适系统改变的完整性 (Integrity) 通过更改和修补的可维护性 (Maintainability) 信息的机密性 (Confidentiality)

可用性完整性

可靠性安全性可维护性

机密性

可信性 保密性

5 新型攻击和对策1 )物理攻击嵌入式系统比通用计算机更容易受攻击 一个关键原因是许多嵌入式计算机对攻击者可物理访问

2 )互联网攻击一些嵌入式系统的攻击通过互联网访问变得更加容易今天许多嵌入式系统连接到互联网

3 )电池攻击 (battery attack)这种攻击试图通过耗尽电池来关闭节点

4 )服务拒绝攻击 (Denial-of-service attacks)

在通用系统中众所周知但是实时嵌入式系统可能更容易受服务质量 (quality-of-service (QoS))攻击如果网络发布实时数据那么发送过程中的一点延迟都能引起数据无效如果那些数据用来实时控制那么这些短暂延迟就能引起系统故障我们称这种危害为时间攻击因为它改变了系统的实时特性

QoS或者时间攻击之所以强大使因为它的影响不仅仅限于信息被控制系统的动态特性可决定系统的响应如果一个大型沉重快速运动的系统被控制那么时间上一个相对小的改变能引起大量的破坏

5 )网络(协议)攻击Wood和 Stankovic[Woo02]在传感器网络上确定了一些方式这些方式可在网络层次的不同层执行拒绝服务攻击如下所列

物理层 (Physical layer)mdashmdash拥塞破坏 链路层 (Link layer)mdashmdash碰撞耗尽非公平

网络和路由层 (Network and routing layer)mdashmdash丢弃和贪婪汇集方向误导黑洞认证监视冗余

传输层 (Transport layer)mdashmdash泛洪失步

6 )能量攻击Kocher等人 [Koc99]指出测量一个 CPU当前的能量供给能在很大程度上确定处理器的内部活动他们提出了两种能量攻击的方法简单能量分析 (simple power analysis)人工地跟踪检查和尝试确定程序作用的位置比如分支基于不同 CUP操作的能耗知识基于程序作用攻击者然后减少密钥的比特差分能量分析 (Differential power analysis)用相关性确定作用和密钥比特这种攻击最初目标是智能卡这种卡从外部读卡器获取能量但是这种攻击也能应用到许多嵌入式系统中

7 )反攻击 在一些时候有可能构造反破坏的嵌入式系统使电子设备难以发觉和分析延缓了攻击者芯片中有限的信息也有助阻止攻击者发现数据

6 Efficiency (效率)

ES must be efficient

bull Code-size efficient( 特别是片上系统 )

bull Run-time efficient

bull Weight efficient

bull Cost efficient

bull Energy efficient

能量有效性的重要意义

ldquoinherent power

efficiency of siliconldquo

59

低功耗设计问题 功耗问题是近几年来人们在嵌入式系统的设计中普遍关注的难点和热点它严重地制约着嵌入式系统的应用与发展

无论是在军事还是在商业贸易上的应用相当数量的嵌入式系统一般是由电池来供给电能的而且大多数嵌入式设备都有体积和质量的约束减少电能消耗不仅能延长电池的使用寿命延长用户更换电池的周期而且能带来提高系统性能与降低系统开销的好处甚至能起到保护环境的作用在便携式设备中 CPU消耗的电能越少电池的寿命就越长同时散发的热量少了所需的散热器就少了从而可减少该设备的花费和体积使产品尽快进入市场的目标

1 低功耗嵌入式应用系统是指以降低系统功耗为一个主要性能指标的嵌入式系统如计算机里的许多芯片过去用 5V供电现在用 33V 18V 并提出了绿色电器的概念

60

低功耗设备的要求1 )首先要求体积小重量轻便于携带2 )采用低功耗电路的设计方法以降低系统的功耗

它除了选用各种低功耗的器件和芯片外还在满足速度等性能指标的前提下进行降低功耗的硬件电路设计和软件设计

3 )有的系统应用在交流供电比较困难甚至无法用交流供电的场合因而各种电池(瓶)就成为其主要供电手段

4 )采用 LCD液晶显示器5 )采用 RS232C串行通信接口6 )采用微功耗高抗干扰的 CMOS集成电路

功耗产生的原因 P=UI

与功耗有关的因素

( 1 )电阻上消耗的功率( 2 )有源器件的开关转换阶段( 3 )集成电路内部和外部电容的充放电( 4 )系统的性能指标负载能力被处理信号的工作频率电路的工作频率电源的管理水平零部件的性能散热条件接口的物理性能等对系统功耗起着重要的作用

降低功耗的措施

功耗的组成动态 + 静态动态电源管理动态电压缩放低功耗硬件设计低功耗软件设计

二设计方法学概论

问题功 能 性能要求价 格 开发 周 期 等约束

设计 选择 折衷 分析比较 计算 评价

嵌入式系统

0嵌入式系统设计概述

方法 工具

设计方法论( design methodology )

设计方法论有以下三个重要理由1 )确认我们所做的每一件事情都是必须要作的

不会做无谓的白工也不会漏掉关键性的重要工作其中包含效率优化或是功能测试

2 )可以发展出计算机辅助工具或是设计经验累积汲取每一次产品发展的经验再经过量化之后可以发展出一套工具或是方法让往后的产品设计步入自动化

3 )开发团队遵循同一套方法论可以让团队成员更容易彼此沟通每个人都能在短时间内了解整体过程中将经历哪些过程需要何种支持与接收到何种结果此外也容易透过一套已经定义好的方法论彼此相互合作协调

设计目标 1 )上市时间

也就是 time-to-market 的观念2 )设计成本

许多消费性产品对于价格非常敏感所以产品厂商对于成本会斤斤计较是很合理的

3 )品质 顾客也许不需要最快最便宜的产品但是一定会要求功能质量保证不能只用一小段时间就坏掉了

传统的设计主要步骤

2 传统的设计流程方法1 )瀑布模型 (Waterfall)2 )螺旋模型 (Spiral)3 )连续改进 (Successive Refinement)4 )硬件与软件的同步设计 (SWHW Co-

deign)5 )阶层式 (Hierarchical) 设计6 )同步工程( concurrent

engineering )

瀑布模型 (Waterfall)

螺旋模型 (Spiral)

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 37: 大学计算机基础 —— 计算机科学概论

( 2 )三模冗余 (triple modular

redundancy) 计算单元 C 有三个副本 C1C2和 C3三个单元接收同

样的输入一个独立单元比较每个输入的结果如果至少两个结果一致那么那个值被表决器选做正确结果如果三个结果都不相同那么就没有正确的结果

1C

2C

3C

表决错误

结果

输入

( 3 )看门狗定时器 (watchdog timer)

看门狗定时器 (watchdog timer)被广泛地用于检测系统问题如图 看门狗定时器连接到一个监视系统如果这个看门狗定时器翻转它产生一个完成信号用于标注系统的错误中断系统应该这样设计当适当运行的时候它一直在可能产生翻转信号之前复位定时器因此来自看门狗定时器的完成信号指示系统在一定程度上不合适地操作看门狗定时器用于预防不同的故障

系统看门狗定时器

完成

复位

( 4 )设计多样性 (Design diversity)

一种用于减少一些系统错误进入设计的设计方法学当一个设计需要给定模块的不同实例应该采用模块的不同实现而不是到处都用同一种模块比如一个有多个 CPU的系统可能采用不同类型的 CPU而不是到处采用同一种类型的 CPU在一个三模冗余系统产生表决结构的组件可能有不同的实现这样可以减少产生同样设计错误的机会

4 )软件可靠性ldquo在规定的条件下在规定的时间内软件不引起失效的概率rdquo

规定的条件 软件运行的软硬件环境 软件操作剖面软件运行的输入空间及其概率分布

规定的时间 日历时间 时钟时间 执行时间

激活软件 输入域 缺陷的数据

软件缺陷 软件

不可接受的结果 (软件故障) 输出域

软件故障的特点

软件与硬件可靠性的区别硬件 软件

故障机理 老化损耗 残留缺陷在一定环境下造成的软件错误

复杂性 内部逻辑较为简单 内部逻辑高度复杂这就在很大程度上决定了设计错误是导致软件故障的主要原因

唯一性 任何两个硬件不可能绝对相同

软件是唯一的软件拷贝不改变软件本身

可靠性的核心 内部元部件 设计者的思维和软件的复杂性纠错维护方法 修复或更换失效的元部件 重设计 可靠性检验标准化

已标准化且有一整套完整的理论

仍未建立更没有完整的理论体系

产品市场 已有成熟的产品市场 产品市场还很新 错误性质 一些瞬间的硬件错误可能

会被误认为是软件错误 软件错误是永恒的可重现的

影响软件可靠性的因素( 1 )运行环境 ( 剖面 )

同一软件在不同运行剖面下其可靠性行为可能极不相同 软件故障是软件缺陷在一定输入情况下被激活的结果 假设软件输入域划分为两个部分 G 和 F 运行剖面不包含 F 中

的输入则软件不会出现故障其可靠性恒为 l 反之如果运行剖面不包含 G 中的输入则每一输入情况下均出现故障如果没有容错措施则 R=0

( 2 )软件规模 随着软件规模的增大软件可靠性问题愈显突出在我们考虑软件

可靠性问题时软件一般是指中型以上软件 (4000-5000条以上语句 ) 这时可靠性问题难以对付

软件工程实践的一个侧面可以反映这一点即单元测试一般由编程人员本人进行而综合测试则需独立的测试人员

影响软件可靠性的因素( 3 )软件内部结构

结构越复杂软件复杂度越高内含缺陷数越大因而软件可靠度越低

( 4 )软件可靠性设计技术 一般是指软件设计阶段中采用的用以保证和提高软件可靠性为主要目标的软件技术

( 5 )软件可靠性测试 研究表明软件测试方法与资源投入对软件可靠性有不可忽视的影

响( 6 )软件可靠性管理

软件可靠性管理旨在系统管理软件生存期各阶段的可靠性活动使之系统化规范化一体化这样就可以避免许多人为错误以提高软件可靠性

影响软件可靠性的因素( 7 )软件开发人员能力和经验

软件开发人员 ( 包括测试人员 ) 的能力愈强经验愈丰富所犯错误便可能愈少所得软件产品质量愈高相应的可靠性也愈高

( 8 )软件开发方法 软件工程表明开发方法对软件可靠性有显著影响 与非结构化方法比较结构化方法可以明显减少软件缺陷数

( 9 )软件开发环境 研究表明程序语言软件开发环境影响软件的可靠性而软件测

试工具的优劣则影响可靠性测试结果

4 安全 (Safety)amp保密 (Security)

安全 (Safety) 是保证财产和人身受到损害可靠性是指在一定的环境条件下以及一定的时间内系统完成特定任务的可能性而有效性则是系统的长期的工作时间于其存在时间 ( 简单的定义为运行时间 +维护时间 ) 的 比例保密 (Security) 是针对危险破坏损失或非法活动而进行措施在一定层面上保密 (Security)要比安全 (Safety)宽广的多例如信息 Security家庭 Security 网络 Security 国家Security) 等

Security强调的是外在事物对特定目标的危害

Safety 是系统本身的潜在危害

四个概念的比较分析安全 (Safety)可靠性 (Reliability)有效性 (Availability)保密 (Security )安全 (Safety)高的系统 软件可靠性不

一定高可靠性和有效性并不是一码事保密 (Security )的系统 软件是安全

(Safety) 系统 软件的重要保障

可靠性安全性保密性 可靠(或可信)系统设计 (Reliable (or dependable) system design)是制造嵌入式系统所关注的甚至在面对内部或者外部问题时可靠系统设计经常假设问题是非恶意引起的

安全重要的系统设计 (Safety-critical system design)研究确保系统安全操作的方法独立于引起问题的原因

保密性 (Security)主要关注恶意攻击

Aizientis等人描述了可信性和保密性间的关系可信性和保密性由几个特性所组成

服务的可用性 (Availability) 服务的连续性 (Continuity) 来自用户和所处环境的灾难性后果的安全性 (Safety) 来自不合适系统改变的完整性 (Integrity) 通过更改和修补的可维护性 (Maintainability) 信息的机密性 (Confidentiality)

可用性完整性

可靠性安全性可维护性

机密性

可信性 保密性

5 新型攻击和对策1 )物理攻击嵌入式系统比通用计算机更容易受攻击 一个关键原因是许多嵌入式计算机对攻击者可物理访问

2 )互联网攻击一些嵌入式系统的攻击通过互联网访问变得更加容易今天许多嵌入式系统连接到互联网

3 )电池攻击 (battery attack)这种攻击试图通过耗尽电池来关闭节点

4 )服务拒绝攻击 (Denial-of-service attacks)

在通用系统中众所周知但是实时嵌入式系统可能更容易受服务质量 (quality-of-service (QoS))攻击如果网络发布实时数据那么发送过程中的一点延迟都能引起数据无效如果那些数据用来实时控制那么这些短暂延迟就能引起系统故障我们称这种危害为时间攻击因为它改变了系统的实时特性

QoS或者时间攻击之所以强大使因为它的影响不仅仅限于信息被控制系统的动态特性可决定系统的响应如果一个大型沉重快速运动的系统被控制那么时间上一个相对小的改变能引起大量的破坏

5 )网络(协议)攻击Wood和 Stankovic[Woo02]在传感器网络上确定了一些方式这些方式可在网络层次的不同层执行拒绝服务攻击如下所列

物理层 (Physical layer)mdashmdash拥塞破坏 链路层 (Link layer)mdashmdash碰撞耗尽非公平

网络和路由层 (Network and routing layer)mdashmdash丢弃和贪婪汇集方向误导黑洞认证监视冗余

传输层 (Transport layer)mdashmdash泛洪失步

6 )能量攻击Kocher等人 [Koc99]指出测量一个 CPU当前的能量供给能在很大程度上确定处理器的内部活动他们提出了两种能量攻击的方法简单能量分析 (simple power analysis)人工地跟踪检查和尝试确定程序作用的位置比如分支基于不同 CUP操作的能耗知识基于程序作用攻击者然后减少密钥的比特差分能量分析 (Differential power analysis)用相关性确定作用和密钥比特这种攻击最初目标是智能卡这种卡从外部读卡器获取能量但是这种攻击也能应用到许多嵌入式系统中

7 )反攻击 在一些时候有可能构造反破坏的嵌入式系统使电子设备难以发觉和分析延缓了攻击者芯片中有限的信息也有助阻止攻击者发现数据

6 Efficiency (效率)

ES must be efficient

bull Code-size efficient( 特别是片上系统 )

bull Run-time efficient

bull Weight efficient

bull Cost efficient

bull Energy efficient

能量有效性的重要意义

ldquoinherent power

efficiency of siliconldquo

59

低功耗设计问题 功耗问题是近几年来人们在嵌入式系统的设计中普遍关注的难点和热点它严重地制约着嵌入式系统的应用与发展

无论是在军事还是在商业贸易上的应用相当数量的嵌入式系统一般是由电池来供给电能的而且大多数嵌入式设备都有体积和质量的约束减少电能消耗不仅能延长电池的使用寿命延长用户更换电池的周期而且能带来提高系统性能与降低系统开销的好处甚至能起到保护环境的作用在便携式设备中 CPU消耗的电能越少电池的寿命就越长同时散发的热量少了所需的散热器就少了从而可减少该设备的花费和体积使产品尽快进入市场的目标

1 低功耗嵌入式应用系统是指以降低系统功耗为一个主要性能指标的嵌入式系统如计算机里的许多芯片过去用 5V供电现在用 33V 18V 并提出了绿色电器的概念

60

低功耗设备的要求1 )首先要求体积小重量轻便于携带2 )采用低功耗电路的设计方法以降低系统的功耗

它除了选用各种低功耗的器件和芯片外还在满足速度等性能指标的前提下进行降低功耗的硬件电路设计和软件设计

3 )有的系统应用在交流供电比较困难甚至无法用交流供电的场合因而各种电池(瓶)就成为其主要供电手段

4 )采用 LCD液晶显示器5 )采用 RS232C串行通信接口6 )采用微功耗高抗干扰的 CMOS集成电路

功耗产生的原因 P=UI

与功耗有关的因素

( 1 )电阻上消耗的功率( 2 )有源器件的开关转换阶段( 3 )集成电路内部和外部电容的充放电( 4 )系统的性能指标负载能力被处理信号的工作频率电路的工作频率电源的管理水平零部件的性能散热条件接口的物理性能等对系统功耗起着重要的作用

降低功耗的措施

功耗的组成动态 + 静态动态电源管理动态电压缩放低功耗硬件设计低功耗软件设计

二设计方法学概论

问题功 能 性能要求价 格 开发 周 期 等约束

设计 选择 折衷 分析比较 计算 评价

嵌入式系统

0嵌入式系统设计概述

方法 工具

设计方法论( design methodology )

设计方法论有以下三个重要理由1 )确认我们所做的每一件事情都是必须要作的

不会做无谓的白工也不会漏掉关键性的重要工作其中包含效率优化或是功能测试

2 )可以发展出计算机辅助工具或是设计经验累积汲取每一次产品发展的经验再经过量化之后可以发展出一套工具或是方法让往后的产品设计步入自动化

3 )开发团队遵循同一套方法论可以让团队成员更容易彼此沟通每个人都能在短时间内了解整体过程中将经历哪些过程需要何种支持与接收到何种结果此外也容易透过一套已经定义好的方法论彼此相互合作协调

设计目标 1 )上市时间

也就是 time-to-market 的观念2 )设计成本

许多消费性产品对于价格非常敏感所以产品厂商对于成本会斤斤计较是很合理的

3 )品质 顾客也许不需要最快最便宜的产品但是一定会要求功能质量保证不能只用一小段时间就坏掉了

传统的设计主要步骤

2 传统的设计流程方法1 )瀑布模型 (Waterfall)2 )螺旋模型 (Spiral)3 )连续改进 (Successive Refinement)4 )硬件与软件的同步设计 (SWHW Co-

deign)5 )阶层式 (Hierarchical) 设计6 )同步工程( concurrent

engineering )

瀑布模型 (Waterfall)

螺旋模型 (Spiral)

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 38: 大学计算机基础 —— 计算机科学概论

( 3 )看门狗定时器 (watchdog timer)

看门狗定时器 (watchdog timer)被广泛地用于检测系统问题如图 看门狗定时器连接到一个监视系统如果这个看门狗定时器翻转它产生一个完成信号用于标注系统的错误中断系统应该这样设计当适当运行的时候它一直在可能产生翻转信号之前复位定时器因此来自看门狗定时器的完成信号指示系统在一定程度上不合适地操作看门狗定时器用于预防不同的故障

系统看门狗定时器

完成

复位

( 4 )设计多样性 (Design diversity)

一种用于减少一些系统错误进入设计的设计方法学当一个设计需要给定模块的不同实例应该采用模块的不同实现而不是到处都用同一种模块比如一个有多个 CPU的系统可能采用不同类型的 CPU而不是到处采用同一种类型的 CPU在一个三模冗余系统产生表决结构的组件可能有不同的实现这样可以减少产生同样设计错误的机会

4 )软件可靠性ldquo在规定的条件下在规定的时间内软件不引起失效的概率rdquo

规定的条件 软件运行的软硬件环境 软件操作剖面软件运行的输入空间及其概率分布

规定的时间 日历时间 时钟时间 执行时间

激活软件 输入域 缺陷的数据

软件缺陷 软件

不可接受的结果 (软件故障) 输出域

软件故障的特点

软件与硬件可靠性的区别硬件 软件

故障机理 老化损耗 残留缺陷在一定环境下造成的软件错误

复杂性 内部逻辑较为简单 内部逻辑高度复杂这就在很大程度上决定了设计错误是导致软件故障的主要原因

唯一性 任何两个硬件不可能绝对相同

软件是唯一的软件拷贝不改变软件本身

可靠性的核心 内部元部件 设计者的思维和软件的复杂性纠错维护方法 修复或更换失效的元部件 重设计 可靠性检验标准化

已标准化且有一整套完整的理论

仍未建立更没有完整的理论体系

产品市场 已有成熟的产品市场 产品市场还很新 错误性质 一些瞬间的硬件错误可能

会被误认为是软件错误 软件错误是永恒的可重现的

影响软件可靠性的因素( 1 )运行环境 ( 剖面 )

同一软件在不同运行剖面下其可靠性行为可能极不相同 软件故障是软件缺陷在一定输入情况下被激活的结果 假设软件输入域划分为两个部分 G 和 F 运行剖面不包含 F 中

的输入则软件不会出现故障其可靠性恒为 l 反之如果运行剖面不包含 G 中的输入则每一输入情况下均出现故障如果没有容错措施则 R=0

( 2 )软件规模 随着软件规模的增大软件可靠性问题愈显突出在我们考虑软件

可靠性问题时软件一般是指中型以上软件 (4000-5000条以上语句 ) 这时可靠性问题难以对付

软件工程实践的一个侧面可以反映这一点即单元测试一般由编程人员本人进行而综合测试则需独立的测试人员

影响软件可靠性的因素( 3 )软件内部结构

结构越复杂软件复杂度越高内含缺陷数越大因而软件可靠度越低

( 4 )软件可靠性设计技术 一般是指软件设计阶段中采用的用以保证和提高软件可靠性为主要目标的软件技术

( 5 )软件可靠性测试 研究表明软件测试方法与资源投入对软件可靠性有不可忽视的影

响( 6 )软件可靠性管理

软件可靠性管理旨在系统管理软件生存期各阶段的可靠性活动使之系统化规范化一体化这样就可以避免许多人为错误以提高软件可靠性

影响软件可靠性的因素( 7 )软件开发人员能力和经验

软件开发人员 ( 包括测试人员 ) 的能力愈强经验愈丰富所犯错误便可能愈少所得软件产品质量愈高相应的可靠性也愈高

( 8 )软件开发方法 软件工程表明开发方法对软件可靠性有显著影响 与非结构化方法比较结构化方法可以明显减少软件缺陷数

( 9 )软件开发环境 研究表明程序语言软件开发环境影响软件的可靠性而软件测

试工具的优劣则影响可靠性测试结果

4 安全 (Safety)amp保密 (Security)

安全 (Safety) 是保证财产和人身受到损害可靠性是指在一定的环境条件下以及一定的时间内系统完成特定任务的可能性而有效性则是系统的长期的工作时间于其存在时间 ( 简单的定义为运行时间 +维护时间 ) 的 比例保密 (Security) 是针对危险破坏损失或非法活动而进行措施在一定层面上保密 (Security)要比安全 (Safety)宽广的多例如信息 Security家庭 Security 网络 Security 国家Security) 等

Security强调的是外在事物对特定目标的危害

Safety 是系统本身的潜在危害

四个概念的比较分析安全 (Safety)可靠性 (Reliability)有效性 (Availability)保密 (Security )安全 (Safety)高的系统 软件可靠性不

一定高可靠性和有效性并不是一码事保密 (Security )的系统 软件是安全

(Safety) 系统 软件的重要保障

可靠性安全性保密性 可靠(或可信)系统设计 (Reliable (or dependable) system design)是制造嵌入式系统所关注的甚至在面对内部或者外部问题时可靠系统设计经常假设问题是非恶意引起的

安全重要的系统设计 (Safety-critical system design)研究确保系统安全操作的方法独立于引起问题的原因

保密性 (Security)主要关注恶意攻击

Aizientis等人描述了可信性和保密性间的关系可信性和保密性由几个特性所组成

服务的可用性 (Availability) 服务的连续性 (Continuity) 来自用户和所处环境的灾难性后果的安全性 (Safety) 来自不合适系统改变的完整性 (Integrity) 通过更改和修补的可维护性 (Maintainability) 信息的机密性 (Confidentiality)

可用性完整性

可靠性安全性可维护性

机密性

可信性 保密性

5 新型攻击和对策1 )物理攻击嵌入式系统比通用计算机更容易受攻击 一个关键原因是许多嵌入式计算机对攻击者可物理访问

2 )互联网攻击一些嵌入式系统的攻击通过互联网访问变得更加容易今天许多嵌入式系统连接到互联网

3 )电池攻击 (battery attack)这种攻击试图通过耗尽电池来关闭节点

4 )服务拒绝攻击 (Denial-of-service attacks)

在通用系统中众所周知但是实时嵌入式系统可能更容易受服务质量 (quality-of-service (QoS))攻击如果网络发布实时数据那么发送过程中的一点延迟都能引起数据无效如果那些数据用来实时控制那么这些短暂延迟就能引起系统故障我们称这种危害为时间攻击因为它改变了系统的实时特性

QoS或者时间攻击之所以强大使因为它的影响不仅仅限于信息被控制系统的动态特性可决定系统的响应如果一个大型沉重快速运动的系统被控制那么时间上一个相对小的改变能引起大量的破坏

5 )网络(协议)攻击Wood和 Stankovic[Woo02]在传感器网络上确定了一些方式这些方式可在网络层次的不同层执行拒绝服务攻击如下所列

物理层 (Physical layer)mdashmdash拥塞破坏 链路层 (Link layer)mdashmdash碰撞耗尽非公平

网络和路由层 (Network and routing layer)mdashmdash丢弃和贪婪汇集方向误导黑洞认证监视冗余

传输层 (Transport layer)mdashmdash泛洪失步

6 )能量攻击Kocher等人 [Koc99]指出测量一个 CPU当前的能量供给能在很大程度上确定处理器的内部活动他们提出了两种能量攻击的方法简单能量分析 (simple power analysis)人工地跟踪检查和尝试确定程序作用的位置比如分支基于不同 CUP操作的能耗知识基于程序作用攻击者然后减少密钥的比特差分能量分析 (Differential power analysis)用相关性确定作用和密钥比特这种攻击最初目标是智能卡这种卡从外部读卡器获取能量但是这种攻击也能应用到许多嵌入式系统中

7 )反攻击 在一些时候有可能构造反破坏的嵌入式系统使电子设备难以发觉和分析延缓了攻击者芯片中有限的信息也有助阻止攻击者发现数据

6 Efficiency (效率)

ES must be efficient

bull Code-size efficient( 特别是片上系统 )

bull Run-time efficient

bull Weight efficient

bull Cost efficient

bull Energy efficient

能量有效性的重要意义

ldquoinherent power

efficiency of siliconldquo

59

低功耗设计问题 功耗问题是近几年来人们在嵌入式系统的设计中普遍关注的难点和热点它严重地制约着嵌入式系统的应用与发展

无论是在军事还是在商业贸易上的应用相当数量的嵌入式系统一般是由电池来供给电能的而且大多数嵌入式设备都有体积和质量的约束减少电能消耗不仅能延长电池的使用寿命延长用户更换电池的周期而且能带来提高系统性能与降低系统开销的好处甚至能起到保护环境的作用在便携式设备中 CPU消耗的电能越少电池的寿命就越长同时散发的热量少了所需的散热器就少了从而可减少该设备的花费和体积使产品尽快进入市场的目标

1 低功耗嵌入式应用系统是指以降低系统功耗为一个主要性能指标的嵌入式系统如计算机里的许多芯片过去用 5V供电现在用 33V 18V 并提出了绿色电器的概念

60

低功耗设备的要求1 )首先要求体积小重量轻便于携带2 )采用低功耗电路的设计方法以降低系统的功耗

它除了选用各种低功耗的器件和芯片外还在满足速度等性能指标的前提下进行降低功耗的硬件电路设计和软件设计

3 )有的系统应用在交流供电比较困难甚至无法用交流供电的场合因而各种电池(瓶)就成为其主要供电手段

4 )采用 LCD液晶显示器5 )采用 RS232C串行通信接口6 )采用微功耗高抗干扰的 CMOS集成电路

功耗产生的原因 P=UI

与功耗有关的因素

( 1 )电阻上消耗的功率( 2 )有源器件的开关转换阶段( 3 )集成电路内部和外部电容的充放电( 4 )系统的性能指标负载能力被处理信号的工作频率电路的工作频率电源的管理水平零部件的性能散热条件接口的物理性能等对系统功耗起着重要的作用

降低功耗的措施

功耗的组成动态 + 静态动态电源管理动态电压缩放低功耗硬件设计低功耗软件设计

二设计方法学概论

问题功 能 性能要求价 格 开发 周 期 等约束

设计 选择 折衷 分析比较 计算 评价

嵌入式系统

0嵌入式系统设计概述

方法 工具

设计方法论( design methodology )

设计方法论有以下三个重要理由1 )确认我们所做的每一件事情都是必须要作的

不会做无谓的白工也不会漏掉关键性的重要工作其中包含效率优化或是功能测试

2 )可以发展出计算机辅助工具或是设计经验累积汲取每一次产品发展的经验再经过量化之后可以发展出一套工具或是方法让往后的产品设计步入自动化

3 )开发团队遵循同一套方法论可以让团队成员更容易彼此沟通每个人都能在短时间内了解整体过程中将经历哪些过程需要何种支持与接收到何种结果此外也容易透过一套已经定义好的方法论彼此相互合作协调

设计目标 1 )上市时间

也就是 time-to-market 的观念2 )设计成本

许多消费性产品对于价格非常敏感所以产品厂商对于成本会斤斤计较是很合理的

3 )品质 顾客也许不需要最快最便宜的产品但是一定会要求功能质量保证不能只用一小段时间就坏掉了

传统的设计主要步骤

2 传统的设计流程方法1 )瀑布模型 (Waterfall)2 )螺旋模型 (Spiral)3 )连续改进 (Successive Refinement)4 )硬件与软件的同步设计 (SWHW Co-

deign)5 )阶层式 (Hierarchical) 设计6 )同步工程( concurrent

engineering )

瀑布模型 (Waterfall)

螺旋模型 (Spiral)

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 39: 大学计算机基础 —— 计算机科学概论

( 4 )设计多样性 (Design diversity)

一种用于减少一些系统错误进入设计的设计方法学当一个设计需要给定模块的不同实例应该采用模块的不同实现而不是到处都用同一种模块比如一个有多个 CPU的系统可能采用不同类型的 CPU而不是到处采用同一种类型的 CPU在一个三模冗余系统产生表决结构的组件可能有不同的实现这样可以减少产生同样设计错误的机会

4 )软件可靠性ldquo在规定的条件下在规定的时间内软件不引起失效的概率rdquo

规定的条件 软件运行的软硬件环境 软件操作剖面软件运行的输入空间及其概率分布

规定的时间 日历时间 时钟时间 执行时间

激活软件 输入域 缺陷的数据

软件缺陷 软件

不可接受的结果 (软件故障) 输出域

软件故障的特点

软件与硬件可靠性的区别硬件 软件

故障机理 老化损耗 残留缺陷在一定环境下造成的软件错误

复杂性 内部逻辑较为简单 内部逻辑高度复杂这就在很大程度上决定了设计错误是导致软件故障的主要原因

唯一性 任何两个硬件不可能绝对相同

软件是唯一的软件拷贝不改变软件本身

可靠性的核心 内部元部件 设计者的思维和软件的复杂性纠错维护方法 修复或更换失效的元部件 重设计 可靠性检验标准化

已标准化且有一整套完整的理论

仍未建立更没有完整的理论体系

产品市场 已有成熟的产品市场 产品市场还很新 错误性质 一些瞬间的硬件错误可能

会被误认为是软件错误 软件错误是永恒的可重现的

影响软件可靠性的因素( 1 )运行环境 ( 剖面 )

同一软件在不同运行剖面下其可靠性行为可能极不相同 软件故障是软件缺陷在一定输入情况下被激活的结果 假设软件输入域划分为两个部分 G 和 F 运行剖面不包含 F 中

的输入则软件不会出现故障其可靠性恒为 l 反之如果运行剖面不包含 G 中的输入则每一输入情况下均出现故障如果没有容错措施则 R=0

( 2 )软件规模 随着软件规模的增大软件可靠性问题愈显突出在我们考虑软件

可靠性问题时软件一般是指中型以上软件 (4000-5000条以上语句 ) 这时可靠性问题难以对付

软件工程实践的一个侧面可以反映这一点即单元测试一般由编程人员本人进行而综合测试则需独立的测试人员

影响软件可靠性的因素( 3 )软件内部结构

结构越复杂软件复杂度越高内含缺陷数越大因而软件可靠度越低

( 4 )软件可靠性设计技术 一般是指软件设计阶段中采用的用以保证和提高软件可靠性为主要目标的软件技术

( 5 )软件可靠性测试 研究表明软件测试方法与资源投入对软件可靠性有不可忽视的影

响( 6 )软件可靠性管理

软件可靠性管理旨在系统管理软件生存期各阶段的可靠性活动使之系统化规范化一体化这样就可以避免许多人为错误以提高软件可靠性

影响软件可靠性的因素( 7 )软件开发人员能力和经验

软件开发人员 ( 包括测试人员 ) 的能力愈强经验愈丰富所犯错误便可能愈少所得软件产品质量愈高相应的可靠性也愈高

( 8 )软件开发方法 软件工程表明开发方法对软件可靠性有显著影响 与非结构化方法比较结构化方法可以明显减少软件缺陷数

( 9 )软件开发环境 研究表明程序语言软件开发环境影响软件的可靠性而软件测

试工具的优劣则影响可靠性测试结果

4 安全 (Safety)amp保密 (Security)

安全 (Safety) 是保证财产和人身受到损害可靠性是指在一定的环境条件下以及一定的时间内系统完成特定任务的可能性而有效性则是系统的长期的工作时间于其存在时间 ( 简单的定义为运行时间 +维护时间 ) 的 比例保密 (Security) 是针对危险破坏损失或非法活动而进行措施在一定层面上保密 (Security)要比安全 (Safety)宽广的多例如信息 Security家庭 Security 网络 Security 国家Security) 等

Security强调的是外在事物对特定目标的危害

Safety 是系统本身的潜在危害

四个概念的比较分析安全 (Safety)可靠性 (Reliability)有效性 (Availability)保密 (Security )安全 (Safety)高的系统 软件可靠性不

一定高可靠性和有效性并不是一码事保密 (Security )的系统 软件是安全

(Safety) 系统 软件的重要保障

可靠性安全性保密性 可靠(或可信)系统设计 (Reliable (or dependable) system design)是制造嵌入式系统所关注的甚至在面对内部或者外部问题时可靠系统设计经常假设问题是非恶意引起的

安全重要的系统设计 (Safety-critical system design)研究确保系统安全操作的方法独立于引起问题的原因

保密性 (Security)主要关注恶意攻击

Aizientis等人描述了可信性和保密性间的关系可信性和保密性由几个特性所组成

服务的可用性 (Availability) 服务的连续性 (Continuity) 来自用户和所处环境的灾难性后果的安全性 (Safety) 来自不合适系统改变的完整性 (Integrity) 通过更改和修补的可维护性 (Maintainability) 信息的机密性 (Confidentiality)

可用性完整性

可靠性安全性可维护性

机密性

可信性 保密性

5 新型攻击和对策1 )物理攻击嵌入式系统比通用计算机更容易受攻击 一个关键原因是许多嵌入式计算机对攻击者可物理访问

2 )互联网攻击一些嵌入式系统的攻击通过互联网访问变得更加容易今天许多嵌入式系统连接到互联网

3 )电池攻击 (battery attack)这种攻击试图通过耗尽电池来关闭节点

4 )服务拒绝攻击 (Denial-of-service attacks)

在通用系统中众所周知但是实时嵌入式系统可能更容易受服务质量 (quality-of-service (QoS))攻击如果网络发布实时数据那么发送过程中的一点延迟都能引起数据无效如果那些数据用来实时控制那么这些短暂延迟就能引起系统故障我们称这种危害为时间攻击因为它改变了系统的实时特性

QoS或者时间攻击之所以强大使因为它的影响不仅仅限于信息被控制系统的动态特性可决定系统的响应如果一个大型沉重快速运动的系统被控制那么时间上一个相对小的改变能引起大量的破坏

5 )网络(协议)攻击Wood和 Stankovic[Woo02]在传感器网络上确定了一些方式这些方式可在网络层次的不同层执行拒绝服务攻击如下所列

物理层 (Physical layer)mdashmdash拥塞破坏 链路层 (Link layer)mdashmdash碰撞耗尽非公平

网络和路由层 (Network and routing layer)mdashmdash丢弃和贪婪汇集方向误导黑洞认证监视冗余

传输层 (Transport layer)mdashmdash泛洪失步

6 )能量攻击Kocher等人 [Koc99]指出测量一个 CPU当前的能量供给能在很大程度上确定处理器的内部活动他们提出了两种能量攻击的方法简单能量分析 (simple power analysis)人工地跟踪检查和尝试确定程序作用的位置比如分支基于不同 CUP操作的能耗知识基于程序作用攻击者然后减少密钥的比特差分能量分析 (Differential power analysis)用相关性确定作用和密钥比特这种攻击最初目标是智能卡这种卡从外部读卡器获取能量但是这种攻击也能应用到许多嵌入式系统中

7 )反攻击 在一些时候有可能构造反破坏的嵌入式系统使电子设备难以发觉和分析延缓了攻击者芯片中有限的信息也有助阻止攻击者发现数据

6 Efficiency (效率)

ES must be efficient

bull Code-size efficient( 特别是片上系统 )

bull Run-time efficient

bull Weight efficient

bull Cost efficient

bull Energy efficient

能量有效性的重要意义

ldquoinherent power

efficiency of siliconldquo

59

低功耗设计问题 功耗问题是近几年来人们在嵌入式系统的设计中普遍关注的难点和热点它严重地制约着嵌入式系统的应用与发展

无论是在军事还是在商业贸易上的应用相当数量的嵌入式系统一般是由电池来供给电能的而且大多数嵌入式设备都有体积和质量的约束减少电能消耗不仅能延长电池的使用寿命延长用户更换电池的周期而且能带来提高系统性能与降低系统开销的好处甚至能起到保护环境的作用在便携式设备中 CPU消耗的电能越少电池的寿命就越长同时散发的热量少了所需的散热器就少了从而可减少该设备的花费和体积使产品尽快进入市场的目标

1 低功耗嵌入式应用系统是指以降低系统功耗为一个主要性能指标的嵌入式系统如计算机里的许多芯片过去用 5V供电现在用 33V 18V 并提出了绿色电器的概念

60

低功耗设备的要求1 )首先要求体积小重量轻便于携带2 )采用低功耗电路的设计方法以降低系统的功耗

它除了选用各种低功耗的器件和芯片外还在满足速度等性能指标的前提下进行降低功耗的硬件电路设计和软件设计

3 )有的系统应用在交流供电比较困难甚至无法用交流供电的场合因而各种电池(瓶)就成为其主要供电手段

4 )采用 LCD液晶显示器5 )采用 RS232C串行通信接口6 )采用微功耗高抗干扰的 CMOS集成电路

功耗产生的原因 P=UI

与功耗有关的因素

( 1 )电阻上消耗的功率( 2 )有源器件的开关转换阶段( 3 )集成电路内部和外部电容的充放电( 4 )系统的性能指标负载能力被处理信号的工作频率电路的工作频率电源的管理水平零部件的性能散热条件接口的物理性能等对系统功耗起着重要的作用

降低功耗的措施

功耗的组成动态 + 静态动态电源管理动态电压缩放低功耗硬件设计低功耗软件设计

二设计方法学概论

问题功 能 性能要求价 格 开发 周 期 等约束

设计 选择 折衷 分析比较 计算 评价

嵌入式系统

0嵌入式系统设计概述

方法 工具

设计方法论( design methodology )

设计方法论有以下三个重要理由1 )确认我们所做的每一件事情都是必须要作的

不会做无谓的白工也不会漏掉关键性的重要工作其中包含效率优化或是功能测试

2 )可以发展出计算机辅助工具或是设计经验累积汲取每一次产品发展的经验再经过量化之后可以发展出一套工具或是方法让往后的产品设计步入自动化

3 )开发团队遵循同一套方法论可以让团队成员更容易彼此沟通每个人都能在短时间内了解整体过程中将经历哪些过程需要何种支持与接收到何种结果此外也容易透过一套已经定义好的方法论彼此相互合作协调

设计目标 1 )上市时间

也就是 time-to-market 的观念2 )设计成本

许多消费性产品对于价格非常敏感所以产品厂商对于成本会斤斤计较是很合理的

3 )品质 顾客也许不需要最快最便宜的产品但是一定会要求功能质量保证不能只用一小段时间就坏掉了

传统的设计主要步骤

2 传统的设计流程方法1 )瀑布模型 (Waterfall)2 )螺旋模型 (Spiral)3 )连续改进 (Successive Refinement)4 )硬件与软件的同步设计 (SWHW Co-

deign)5 )阶层式 (Hierarchical) 设计6 )同步工程( concurrent

engineering )

瀑布模型 (Waterfall)

螺旋模型 (Spiral)

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 40: 大学计算机基础 —— 计算机科学概论

4 )软件可靠性ldquo在规定的条件下在规定的时间内软件不引起失效的概率rdquo

规定的条件 软件运行的软硬件环境 软件操作剖面软件运行的输入空间及其概率分布

规定的时间 日历时间 时钟时间 执行时间

激活软件 输入域 缺陷的数据

软件缺陷 软件

不可接受的结果 (软件故障) 输出域

软件故障的特点

软件与硬件可靠性的区别硬件 软件

故障机理 老化损耗 残留缺陷在一定环境下造成的软件错误

复杂性 内部逻辑较为简单 内部逻辑高度复杂这就在很大程度上决定了设计错误是导致软件故障的主要原因

唯一性 任何两个硬件不可能绝对相同

软件是唯一的软件拷贝不改变软件本身

可靠性的核心 内部元部件 设计者的思维和软件的复杂性纠错维护方法 修复或更换失效的元部件 重设计 可靠性检验标准化

已标准化且有一整套完整的理论

仍未建立更没有完整的理论体系

产品市场 已有成熟的产品市场 产品市场还很新 错误性质 一些瞬间的硬件错误可能

会被误认为是软件错误 软件错误是永恒的可重现的

影响软件可靠性的因素( 1 )运行环境 ( 剖面 )

同一软件在不同运行剖面下其可靠性行为可能极不相同 软件故障是软件缺陷在一定输入情况下被激活的结果 假设软件输入域划分为两个部分 G 和 F 运行剖面不包含 F 中

的输入则软件不会出现故障其可靠性恒为 l 反之如果运行剖面不包含 G 中的输入则每一输入情况下均出现故障如果没有容错措施则 R=0

( 2 )软件规模 随着软件规模的增大软件可靠性问题愈显突出在我们考虑软件

可靠性问题时软件一般是指中型以上软件 (4000-5000条以上语句 ) 这时可靠性问题难以对付

软件工程实践的一个侧面可以反映这一点即单元测试一般由编程人员本人进行而综合测试则需独立的测试人员

影响软件可靠性的因素( 3 )软件内部结构

结构越复杂软件复杂度越高内含缺陷数越大因而软件可靠度越低

( 4 )软件可靠性设计技术 一般是指软件设计阶段中采用的用以保证和提高软件可靠性为主要目标的软件技术

( 5 )软件可靠性测试 研究表明软件测试方法与资源投入对软件可靠性有不可忽视的影

响( 6 )软件可靠性管理

软件可靠性管理旨在系统管理软件生存期各阶段的可靠性活动使之系统化规范化一体化这样就可以避免许多人为错误以提高软件可靠性

影响软件可靠性的因素( 7 )软件开发人员能力和经验

软件开发人员 ( 包括测试人员 ) 的能力愈强经验愈丰富所犯错误便可能愈少所得软件产品质量愈高相应的可靠性也愈高

( 8 )软件开发方法 软件工程表明开发方法对软件可靠性有显著影响 与非结构化方法比较结构化方法可以明显减少软件缺陷数

( 9 )软件开发环境 研究表明程序语言软件开发环境影响软件的可靠性而软件测

试工具的优劣则影响可靠性测试结果

4 安全 (Safety)amp保密 (Security)

安全 (Safety) 是保证财产和人身受到损害可靠性是指在一定的环境条件下以及一定的时间内系统完成特定任务的可能性而有效性则是系统的长期的工作时间于其存在时间 ( 简单的定义为运行时间 +维护时间 ) 的 比例保密 (Security) 是针对危险破坏损失或非法活动而进行措施在一定层面上保密 (Security)要比安全 (Safety)宽广的多例如信息 Security家庭 Security 网络 Security 国家Security) 等

Security强调的是外在事物对特定目标的危害

Safety 是系统本身的潜在危害

四个概念的比较分析安全 (Safety)可靠性 (Reliability)有效性 (Availability)保密 (Security )安全 (Safety)高的系统 软件可靠性不

一定高可靠性和有效性并不是一码事保密 (Security )的系统 软件是安全

(Safety) 系统 软件的重要保障

可靠性安全性保密性 可靠(或可信)系统设计 (Reliable (or dependable) system design)是制造嵌入式系统所关注的甚至在面对内部或者外部问题时可靠系统设计经常假设问题是非恶意引起的

安全重要的系统设计 (Safety-critical system design)研究确保系统安全操作的方法独立于引起问题的原因

保密性 (Security)主要关注恶意攻击

Aizientis等人描述了可信性和保密性间的关系可信性和保密性由几个特性所组成

服务的可用性 (Availability) 服务的连续性 (Continuity) 来自用户和所处环境的灾难性后果的安全性 (Safety) 来自不合适系统改变的完整性 (Integrity) 通过更改和修补的可维护性 (Maintainability) 信息的机密性 (Confidentiality)

可用性完整性

可靠性安全性可维护性

机密性

可信性 保密性

5 新型攻击和对策1 )物理攻击嵌入式系统比通用计算机更容易受攻击 一个关键原因是许多嵌入式计算机对攻击者可物理访问

2 )互联网攻击一些嵌入式系统的攻击通过互联网访问变得更加容易今天许多嵌入式系统连接到互联网

3 )电池攻击 (battery attack)这种攻击试图通过耗尽电池来关闭节点

4 )服务拒绝攻击 (Denial-of-service attacks)

在通用系统中众所周知但是实时嵌入式系统可能更容易受服务质量 (quality-of-service (QoS))攻击如果网络发布实时数据那么发送过程中的一点延迟都能引起数据无效如果那些数据用来实时控制那么这些短暂延迟就能引起系统故障我们称这种危害为时间攻击因为它改变了系统的实时特性

QoS或者时间攻击之所以强大使因为它的影响不仅仅限于信息被控制系统的动态特性可决定系统的响应如果一个大型沉重快速运动的系统被控制那么时间上一个相对小的改变能引起大量的破坏

5 )网络(协议)攻击Wood和 Stankovic[Woo02]在传感器网络上确定了一些方式这些方式可在网络层次的不同层执行拒绝服务攻击如下所列

物理层 (Physical layer)mdashmdash拥塞破坏 链路层 (Link layer)mdashmdash碰撞耗尽非公平

网络和路由层 (Network and routing layer)mdashmdash丢弃和贪婪汇集方向误导黑洞认证监视冗余

传输层 (Transport layer)mdashmdash泛洪失步

6 )能量攻击Kocher等人 [Koc99]指出测量一个 CPU当前的能量供给能在很大程度上确定处理器的内部活动他们提出了两种能量攻击的方法简单能量分析 (simple power analysis)人工地跟踪检查和尝试确定程序作用的位置比如分支基于不同 CUP操作的能耗知识基于程序作用攻击者然后减少密钥的比特差分能量分析 (Differential power analysis)用相关性确定作用和密钥比特这种攻击最初目标是智能卡这种卡从外部读卡器获取能量但是这种攻击也能应用到许多嵌入式系统中

7 )反攻击 在一些时候有可能构造反破坏的嵌入式系统使电子设备难以发觉和分析延缓了攻击者芯片中有限的信息也有助阻止攻击者发现数据

6 Efficiency (效率)

ES must be efficient

bull Code-size efficient( 特别是片上系统 )

bull Run-time efficient

bull Weight efficient

bull Cost efficient

bull Energy efficient

能量有效性的重要意义

ldquoinherent power

efficiency of siliconldquo

59

低功耗设计问题 功耗问题是近几年来人们在嵌入式系统的设计中普遍关注的难点和热点它严重地制约着嵌入式系统的应用与发展

无论是在军事还是在商业贸易上的应用相当数量的嵌入式系统一般是由电池来供给电能的而且大多数嵌入式设备都有体积和质量的约束减少电能消耗不仅能延长电池的使用寿命延长用户更换电池的周期而且能带来提高系统性能与降低系统开销的好处甚至能起到保护环境的作用在便携式设备中 CPU消耗的电能越少电池的寿命就越长同时散发的热量少了所需的散热器就少了从而可减少该设备的花费和体积使产品尽快进入市场的目标

1 低功耗嵌入式应用系统是指以降低系统功耗为一个主要性能指标的嵌入式系统如计算机里的许多芯片过去用 5V供电现在用 33V 18V 并提出了绿色电器的概念

60

低功耗设备的要求1 )首先要求体积小重量轻便于携带2 )采用低功耗电路的设计方法以降低系统的功耗

它除了选用各种低功耗的器件和芯片外还在满足速度等性能指标的前提下进行降低功耗的硬件电路设计和软件设计

3 )有的系统应用在交流供电比较困难甚至无法用交流供电的场合因而各种电池(瓶)就成为其主要供电手段

4 )采用 LCD液晶显示器5 )采用 RS232C串行通信接口6 )采用微功耗高抗干扰的 CMOS集成电路

功耗产生的原因 P=UI

与功耗有关的因素

( 1 )电阻上消耗的功率( 2 )有源器件的开关转换阶段( 3 )集成电路内部和外部电容的充放电( 4 )系统的性能指标负载能力被处理信号的工作频率电路的工作频率电源的管理水平零部件的性能散热条件接口的物理性能等对系统功耗起着重要的作用

降低功耗的措施

功耗的组成动态 + 静态动态电源管理动态电压缩放低功耗硬件设计低功耗软件设计

二设计方法学概论

问题功 能 性能要求价 格 开发 周 期 等约束

设计 选择 折衷 分析比较 计算 评价

嵌入式系统

0嵌入式系统设计概述

方法 工具

设计方法论( design methodology )

设计方法论有以下三个重要理由1 )确认我们所做的每一件事情都是必须要作的

不会做无谓的白工也不会漏掉关键性的重要工作其中包含效率优化或是功能测试

2 )可以发展出计算机辅助工具或是设计经验累积汲取每一次产品发展的经验再经过量化之后可以发展出一套工具或是方法让往后的产品设计步入自动化

3 )开发团队遵循同一套方法论可以让团队成员更容易彼此沟通每个人都能在短时间内了解整体过程中将经历哪些过程需要何种支持与接收到何种结果此外也容易透过一套已经定义好的方法论彼此相互合作协调

设计目标 1 )上市时间

也就是 time-to-market 的观念2 )设计成本

许多消费性产品对于价格非常敏感所以产品厂商对于成本会斤斤计较是很合理的

3 )品质 顾客也许不需要最快最便宜的产品但是一定会要求功能质量保证不能只用一小段时间就坏掉了

传统的设计主要步骤

2 传统的设计流程方法1 )瀑布模型 (Waterfall)2 )螺旋模型 (Spiral)3 )连续改进 (Successive Refinement)4 )硬件与软件的同步设计 (SWHW Co-

deign)5 )阶层式 (Hierarchical) 设计6 )同步工程( concurrent

engineering )

瀑布模型 (Waterfall)

螺旋模型 (Spiral)

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 41: 大学计算机基础 —— 计算机科学概论

激活软件 输入域 缺陷的数据

软件缺陷 软件

不可接受的结果 (软件故障) 输出域

软件故障的特点

软件与硬件可靠性的区别硬件 软件

故障机理 老化损耗 残留缺陷在一定环境下造成的软件错误

复杂性 内部逻辑较为简单 内部逻辑高度复杂这就在很大程度上决定了设计错误是导致软件故障的主要原因

唯一性 任何两个硬件不可能绝对相同

软件是唯一的软件拷贝不改变软件本身

可靠性的核心 内部元部件 设计者的思维和软件的复杂性纠错维护方法 修复或更换失效的元部件 重设计 可靠性检验标准化

已标准化且有一整套完整的理论

仍未建立更没有完整的理论体系

产品市场 已有成熟的产品市场 产品市场还很新 错误性质 一些瞬间的硬件错误可能

会被误认为是软件错误 软件错误是永恒的可重现的

影响软件可靠性的因素( 1 )运行环境 ( 剖面 )

同一软件在不同运行剖面下其可靠性行为可能极不相同 软件故障是软件缺陷在一定输入情况下被激活的结果 假设软件输入域划分为两个部分 G 和 F 运行剖面不包含 F 中

的输入则软件不会出现故障其可靠性恒为 l 反之如果运行剖面不包含 G 中的输入则每一输入情况下均出现故障如果没有容错措施则 R=0

( 2 )软件规模 随着软件规模的增大软件可靠性问题愈显突出在我们考虑软件

可靠性问题时软件一般是指中型以上软件 (4000-5000条以上语句 ) 这时可靠性问题难以对付

软件工程实践的一个侧面可以反映这一点即单元测试一般由编程人员本人进行而综合测试则需独立的测试人员

影响软件可靠性的因素( 3 )软件内部结构

结构越复杂软件复杂度越高内含缺陷数越大因而软件可靠度越低

( 4 )软件可靠性设计技术 一般是指软件设计阶段中采用的用以保证和提高软件可靠性为主要目标的软件技术

( 5 )软件可靠性测试 研究表明软件测试方法与资源投入对软件可靠性有不可忽视的影

响( 6 )软件可靠性管理

软件可靠性管理旨在系统管理软件生存期各阶段的可靠性活动使之系统化规范化一体化这样就可以避免许多人为错误以提高软件可靠性

影响软件可靠性的因素( 7 )软件开发人员能力和经验

软件开发人员 ( 包括测试人员 ) 的能力愈强经验愈丰富所犯错误便可能愈少所得软件产品质量愈高相应的可靠性也愈高

( 8 )软件开发方法 软件工程表明开发方法对软件可靠性有显著影响 与非结构化方法比较结构化方法可以明显减少软件缺陷数

( 9 )软件开发环境 研究表明程序语言软件开发环境影响软件的可靠性而软件测

试工具的优劣则影响可靠性测试结果

4 安全 (Safety)amp保密 (Security)

安全 (Safety) 是保证财产和人身受到损害可靠性是指在一定的环境条件下以及一定的时间内系统完成特定任务的可能性而有效性则是系统的长期的工作时间于其存在时间 ( 简单的定义为运行时间 +维护时间 ) 的 比例保密 (Security) 是针对危险破坏损失或非法活动而进行措施在一定层面上保密 (Security)要比安全 (Safety)宽广的多例如信息 Security家庭 Security 网络 Security 国家Security) 等

Security强调的是外在事物对特定目标的危害

Safety 是系统本身的潜在危害

四个概念的比较分析安全 (Safety)可靠性 (Reliability)有效性 (Availability)保密 (Security )安全 (Safety)高的系统 软件可靠性不

一定高可靠性和有效性并不是一码事保密 (Security )的系统 软件是安全

(Safety) 系统 软件的重要保障

可靠性安全性保密性 可靠(或可信)系统设计 (Reliable (or dependable) system design)是制造嵌入式系统所关注的甚至在面对内部或者外部问题时可靠系统设计经常假设问题是非恶意引起的

安全重要的系统设计 (Safety-critical system design)研究确保系统安全操作的方法独立于引起问题的原因

保密性 (Security)主要关注恶意攻击

Aizientis等人描述了可信性和保密性间的关系可信性和保密性由几个特性所组成

服务的可用性 (Availability) 服务的连续性 (Continuity) 来自用户和所处环境的灾难性后果的安全性 (Safety) 来自不合适系统改变的完整性 (Integrity) 通过更改和修补的可维护性 (Maintainability) 信息的机密性 (Confidentiality)

可用性完整性

可靠性安全性可维护性

机密性

可信性 保密性

5 新型攻击和对策1 )物理攻击嵌入式系统比通用计算机更容易受攻击 一个关键原因是许多嵌入式计算机对攻击者可物理访问

2 )互联网攻击一些嵌入式系统的攻击通过互联网访问变得更加容易今天许多嵌入式系统连接到互联网

3 )电池攻击 (battery attack)这种攻击试图通过耗尽电池来关闭节点

4 )服务拒绝攻击 (Denial-of-service attacks)

在通用系统中众所周知但是实时嵌入式系统可能更容易受服务质量 (quality-of-service (QoS))攻击如果网络发布实时数据那么发送过程中的一点延迟都能引起数据无效如果那些数据用来实时控制那么这些短暂延迟就能引起系统故障我们称这种危害为时间攻击因为它改变了系统的实时特性

QoS或者时间攻击之所以强大使因为它的影响不仅仅限于信息被控制系统的动态特性可决定系统的响应如果一个大型沉重快速运动的系统被控制那么时间上一个相对小的改变能引起大量的破坏

5 )网络(协议)攻击Wood和 Stankovic[Woo02]在传感器网络上确定了一些方式这些方式可在网络层次的不同层执行拒绝服务攻击如下所列

物理层 (Physical layer)mdashmdash拥塞破坏 链路层 (Link layer)mdashmdash碰撞耗尽非公平

网络和路由层 (Network and routing layer)mdashmdash丢弃和贪婪汇集方向误导黑洞认证监视冗余

传输层 (Transport layer)mdashmdash泛洪失步

6 )能量攻击Kocher等人 [Koc99]指出测量一个 CPU当前的能量供给能在很大程度上确定处理器的内部活动他们提出了两种能量攻击的方法简单能量分析 (simple power analysis)人工地跟踪检查和尝试确定程序作用的位置比如分支基于不同 CUP操作的能耗知识基于程序作用攻击者然后减少密钥的比特差分能量分析 (Differential power analysis)用相关性确定作用和密钥比特这种攻击最初目标是智能卡这种卡从外部读卡器获取能量但是这种攻击也能应用到许多嵌入式系统中

7 )反攻击 在一些时候有可能构造反破坏的嵌入式系统使电子设备难以发觉和分析延缓了攻击者芯片中有限的信息也有助阻止攻击者发现数据

6 Efficiency (效率)

ES must be efficient

bull Code-size efficient( 特别是片上系统 )

bull Run-time efficient

bull Weight efficient

bull Cost efficient

bull Energy efficient

能量有效性的重要意义

ldquoinherent power

efficiency of siliconldquo

59

低功耗设计问题 功耗问题是近几年来人们在嵌入式系统的设计中普遍关注的难点和热点它严重地制约着嵌入式系统的应用与发展

无论是在军事还是在商业贸易上的应用相当数量的嵌入式系统一般是由电池来供给电能的而且大多数嵌入式设备都有体积和质量的约束减少电能消耗不仅能延长电池的使用寿命延长用户更换电池的周期而且能带来提高系统性能与降低系统开销的好处甚至能起到保护环境的作用在便携式设备中 CPU消耗的电能越少电池的寿命就越长同时散发的热量少了所需的散热器就少了从而可减少该设备的花费和体积使产品尽快进入市场的目标

1 低功耗嵌入式应用系统是指以降低系统功耗为一个主要性能指标的嵌入式系统如计算机里的许多芯片过去用 5V供电现在用 33V 18V 并提出了绿色电器的概念

60

低功耗设备的要求1 )首先要求体积小重量轻便于携带2 )采用低功耗电路的设计方法以降低系统的功耗

它除了选用各种低功耗的器件和芯片外还在满足速度等性能指标的前提下进行降低功耗的硬件电路设计和软件设计

3 )有的系统应用在交流供电比较困难甚至无法用交流供电的场合因而各种电池(瓶)就成为其主要供电手段

4 )采用 LCD液晶显示器5 )采用 RS232C串行通信接口6 )采用微功耗高抗干扰的 CMOS集成电路

功耗产生的原因 P=UI

与功耗有关的因素

( 1 )电阻上消耗的功率( 2 )有源器件的开关转换阶段( 3 )集成电路内部和外部电容的充放电( 4 )系统的性能指标负载能力被处理信号的工作频率电路的工作频率电源的管理水平零部件的性能散热条件接口的物理性能等对系统功耗起着重要的作用

降低功耗的措施

功耗的组成动态 + 静态动态电源管理动态电压缩放低功耗硬件设计低功耗软件设计

二设计方法学概论

问题功 能 性能要求价 格 开发 周 期 等约束

设计 选择 折衷 分析比较 计算 评价

嵌入式系统

0嵌入式系统设计概述

方法 工具

设计方法论( design methodology )

设计方法论有以下三个重要理由1 )确认我们所做的每一件事情都是必须要作的

不会做无谓的白工也不会漏掉关键性的重要工作其中包含效率优化或是功能测试

2 )可以发展出计算机辅助工具或是设计经验累积汲取每一次产品发展的经验再经过量化之后可以发展出一套工具或是方法让往后的产品设计步入自动化

3 )开发团队遵循同一套方法论可以让团队成员更容易彼此沟通每个人都能在短时间内了解整体过程中将经历哪些过程需要何种支持与接收到何种结果此外也容易透过一套已经定义好的方法论彼此相互合作协调

设计目标 1 )上市时间

也就是 time-to-market 的观念2 )设计成本

许多消费性产品对于价格非常敏感所以产品厂商对于成本会斤斤计较是很合理的

3 )品质 顾客也许不需要最快最便宜的产品但是一定会要求功能质量保证不能只用一小段时间就坏掉了

传统的设计主要步骤

2 传统的设计流程方法1 )瀑布模型 (Waterfall)2 )螺旋模型 (Spiral)3 )连续改进 (Successive Refinement)4 )硬件与软件的同步设计 (SWHW Co-

deign)5 )阶层式 (Hierarchical) 设计6 )同步工程( concurrent

engineering )

瀑布模型 (Waterfall)

螺旋模型 (Spiral)

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 42: 大学计算机基础 —— 计算机科学概论

软件与硬件可靠性的区别硬件 软件

故障机理 老化损耗 残留缺陷在一定环境下造成的软件错误

复杂性 内部逻辑较为简单 内部逻辑高度复杂这就在很大程度上决定了设计错误是导致软件故障的主要原因

唯一性 任何两个硬件不可能绝对相同

软件是唯一的软件拷贝不改变软件本身

可靠性的核心 内部元部件 设计者的思维和软件的复杂性纠错维护方法 修复或更换失效的元部件 重设计 可靠性检验标准化

已标准化且有一整套完整的理论

仍未建立更没有完整的理论体系

产品市场 已有成熟的产品市场 产品市场还很新 错误性质 一些瞬间的硬件错误可能

会被误认为是软件错误 软件错误是永恒的可重现的

影响软件可靠性的因素( 1 )运行环境 ( 剖面 )

同一软件在不同运行剖面下其可靠性行为可能极不相同 软件故障是软件缺陷在一定输入情况下被激活的结果 假设软件输入域划分为两个部分 G 和 F 运行剖面不包含 F 中

的输入则软件不会出现故障其可靠性恒为 l 反之如果运行剖面不包含 G 中的输入则每一输入情况下均出现故障如果没有容错措施则 R=0

( 2 )软件规模 随着软件规模的增大软件可靠性问题愈显突出在我们考虑软件

可靠性问题时软件一般是指中型以上软件 (4000-5000条以上语句 ) 这时可靠性问题难以对付

软件工程实践的一个侧面可以反映这一点即单元测试一般由编程人员本人进行而综合测试则需独立的测试人员

影响软件可靠性的因素( 3 )软件内部结构

结构越复杂软件复杂度越高内含缺陷数越大因而软件可靠度越低

( 4 )软件可靠性设计技术 一般是指软件设计阶段中采用的用以保证和提高软件可靠性为主要目标的软件技术

( 5 )软件可靠性测试 研究表明软件测试方法与资源投入对软件可靠性有不可忽视的影

响( 6 )软件可靠性管理

软件可靠性管理旨在系统管理软件生存期各阶段的可靠性活动使之系统化规范化一体化这样就可以避免许多人为错误以提高软件可靠性

影响软件可靠性的因素( 7 )软件开发人员能力和经验

软件开发人员 ( 包括测试人员 ) 的能力愈强经验愈丰富所犯错误便可能愈少所得软件产品质量愈高相应的可靠性也愈高

( 8 )软件开发方法 软件工程表明开发方法对软件可靠性有显著影响 与非结构化方法比较结构化方法可以明显减少软件缺陷数

( 9 )软件开发环境 研究表明程序语言软件开发环境影响软件的可靠性而软件测

试工具的优劣则影响可靠性测试结果

4 安全 (Safety)amp保密 (Security)

安全 (Safety) 是保证财产和人身受到损害可靠性是指在一定的环境条件下以及一定的时间内系统完成特定任务的可能性而有效性则是系统的长期的工作时间于其存在时间 ( 简单的定义为运行时间 +维护时间 ) 的 比例保密 (Security) 是针对危险破坏损失或非法活动而进行措施在一定层面上保密 (Security)要比安全 (Safety)宽广的多例如信息 Security家庭 Security 网络 Security 国家Security) 等

Security强调的是外在事物对特定目标的危害

Safety 是系统本身的潜在危害

四个概念的比较分析安全 (Safety)可靠性 (Reliability)有效性 (Availability)保密 (Security )安全 (Safety)高的系统 软件可靠性不

一定高可靠性和有效性并不是一码事保密 (Security )的系统 软件是安全

(Safety) 系统 软件的重要保障

可靠性安全性保密性 可靠(或可信)系统设计 (Reliable (or dependable) system design)是制造嵌入式系统所关注的甚至在面对内部或者外部问题时可靠系统设计经常假设问题是非恶意引起的

安全重要的系统设计 (Safety-critical system design)研究确保系统安全操作的方法独立于引起问题的原因

保密性 (Security)主要关注恶意攻击

Aizientis等人描述了可信性和保密性间的关系可信性和保密性由几个特性所组成

服务的可用性 (Availability) 服务的连续性 (Continuity) 来自用户和所处环境的灾难性后果的安全性 (Safety) 来自不合适系统改变的完整性 (Integrity) 通过更改和修补的可维护性 (Maintainability) 信息的机密性 (Confidentiality)

可用性完整性

可靠性安全性可维护性

机密性

可信性 保密性

5 新型攻击和对策1 )物理攻击嵌入式系统比通用计算机更容易受攻击 一个关键原因是许多嵌入式计算机对攻击者可物理访问

2 )互联网攻击一些嵌入式系统的攻击通过互联网访问变得更加容易今天许多嵌入式系统连接到互联网

3 )电池攻击 (battery attack)这种攻击试图通过耗尽电池来关闭节点

4 )服务拒绝攻击 (Denial-of-service attacks)

在通用系统中众所周知但是实时嵌入式系统可能更容易受服务质量 (quality-of-service (QoS))攻击如果网络发布实时数据那么发送过程中的一点延迟都能引起数据无效如果那些数据用来实时控制那么这些短暂延迟就能引起系统故障我们称这种危害为时间攻击因为它改变了系统的实时特性

QoS或者时间攻击之所以强大使因为它的影响不仅仅限于信息被控制系统的动态特性可决定系统的响应如果一个大型沉重快速运动的系统被控制那么时间上一个相对小的改变能引起大量的破坏

5 )网络(协议)攻击Wood和 Stankovic[Woo02]在传感器网络上确定了一些方式这些方式可在网络层次的不同层执行拒绝服务攻击如下所列

物理层 (Physical layer)mdashmdash拥塞破坏 链路层 (Link layer)mdashmdash碰撞耗尽非公平

网络和路由层 (Network and routing layer)mdashmdash丢弃和贪婪汇集方向误导黑洞认证监视冗余

传输层 (Transport layer)mdashmdash泛洪失步

6 )能量攻击Kocher等人 [Koc99]指出测量一个 CPU当前的能量供给能在很大程度上确定处理器的内部活动他们提出了两种能量攻击的方法简单能量分析 (simple power analysis)人工地跟踪检查和尝试确定程序作用的位置比如分支基于不同 CUP操作的能耗知识基于程序作用攻击者然后减少密钥的比特差分能量分析 (Differential power analysis)用相关性确定作用和密钥比特这种攻击最初目标是智能卡这种卡从外部读卡器获取能量但是这种攻击也能应用到许多嵌入式系统中

7 )反攻击 在一些时候有可能构造反破坏的嵌入式系统使电子设备难以发觉和分析延缓了攻击者芯片中有限的信息也有助阻止攻击者发现数据

6 Efficiency (效率)

ES must be efficient

bull Code-size efficient( 特别是片上系统 )

bull Run-time efficient

bull Weight efficient

bull Cost efficient

bull Energy efficient

能量有效性的重要意义

ldquoinherent power

efficiency of siliconldquo

59

低功耗设计问题 功耗问题是近几年来人们在嵌入式系统的设计中普遍关注的难点和热点它严重地制约着嵌入式系统的应用与发展

无论是在军事还是在商业贸易上的应用相当数量的嵌入式系统一般是由电池来供给电能的而且大多数嵌入式设备都有体积和质量的约束减少电能消耗不仅能延长电池的使用寿命延长用户更换电池的周期而且能带来提高系统性能与降低系统开销的好处甚至能起到保护环境的作用在便携式设备中 CPU消耗的电能越少电池的寿命就越长同时散发的热量少了所需的散热器就少了从而可减少该设备的花费和体积使产品尽快进入市场的目标

1 低功耗嵌入式应用系统是指以降低系统功耗为一个主要性能指标的嵌入式系统如计算机里的许多芯片过去用 5V供电现在用 33V 18V 并提出了绿色电器的概念

60

低功耗设备的要求1 )首先要求体积小重量轻便于携带2 )采用低功耗电路的设计方法以降低系统的功耗

它除了选用各种低功耗的器件和芯片外还在满足速度等性能指标的前提下进行降低功耗的硬件电路设计和软件设计

3 )有的系统应用在交流供电比较困难甚至无法用交流供电的场合因而各种电池(瓶)就成为其主要供电手段

4 )采用 LCD液晶显示器5 )采用 RS232C串行通信接口6 )采用微功耗高抗干扰的 CMOS集成电路

功耗产生的原因 P=UI

与功耗有关的因素

( 1 )电阻上消耗的功率( 2 )有源器件的开关转换阶段( 3 )集成电路内部和外部电容的充放电( 4 )系统的性能指标负载能力被处理信号的工作频率电路的工作频率电源的管理水平零部件的性能散热条件接口的物理性能等对系统功耗起着重要的作用

降低功耗的措施

功耗的组成动态 + 静态动态电源管理动态电压缩放低功耗硬件设计低功耗软件设计

二设计方法学概论

问题功 能 性能要求价 格 开发 周 期 等约束

设计 选择 折衷 分析比较 计算 评价

嵌入式系统

0嵌入式系统设计概述

方法 工具

设计方法论( design methodology )

设计方法论有以下三个重要理由1 )确认我们所做的每一件事情都是必须要作的

不会做无谓的白工也不会漏掉关键性的重要工作其中包含效率优化或是功能测试

2 )可以发展出计算机辅助工具或是设计经验累积汲取每一次产品发展的经验再经过量化之后可以发展出一套工具或是方法让往后的产品设计步入自动化

3 )开发团队遵循同一套方法论可以让团队成员更容易彼此沟通每个人都能在短时间内了解整体过程中将经历哪些过程需要何种支持与接收到何种结果此外也容易透过一套已经定义好的方法论彼此相互合作协调

设计目标 1 )上市时间

也就是 time-to-market 的观念2 )设计成本

许多消费性产品对于价格非常敏感所以产品厂商对于成本会斤斤计较是很合理的

3 )品质 顾客也许不需要最快最便宜的产品但是一定会要求功能质量保证不能只用一小段时间就坏掉了

传统的设计主要步骤

2 传统的设计流程方法1 )瀑布模型 (Waterfall)2 )螺旋模型 (Spiral)3 )连续改进 (Successive Refinement)4 )硬件与软件的同步设计 (SWHW Co-

deign)5 )阶层式 (Hierarchical) 设计6 )同步工程( concurrent

engineering )

瀑布模型 (Waterfall)

螺旋模型 (Spiral)

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 43: 大学计算机基础 —— 计算机科学概论

影响软件可靠性的因素( 1 )运行环境 ( 剖面 )

同一软件在不同运行剖面下其可靠性行为可能极不相同 软件故障是软件缺陷在一定输入情况下被激活的结果 假设软件输入域划分为两个部分 G 和 F 运行剖面不包含 F 中

的输入则软件不会出现故障其可靠性恒为 l 反之如果运行剖面不包含 G 中的输入则每一输入情况下均出现故障如果没有容错措施则 R=0

( 2 )软件规模 随着软件规模的增大软件可靠性问题愈显突出在我们考虑软件

可靠性问题时软件一般是指中型以上软件 (4000-5000条以上语句 ) 这时可靠性问题难以对付

软件工程实践的一个侧面可以反映这一点即单元测试一般由编程人员本人进行而综合测试则需独立的测试人员

影响软件可靠性的因素( 3 )软件内部结构

结构越复杂软件复杂度越高内含缺陷数越大因而软件可靠度越低

( 4 )软件可靠性设计技术 一般是指软件设计阶段中采用的用以保证和提高软件可靠性为主要目标的软件技术

( 5 )软件可靠性测试 研究表明软件测试方法与资源投入对软件可靠性有不可忽视的影

响( 6 )软件可靠性管理

软件可靠性管理旨在系统管理软件生存期各阶段的可靠性活动使之系统化规范化一体化这样就可以避免许多人为错误以提高软件可靠性

影响软件可靠性的因素( 7 )软件开发人员能力和经验

软件开发人员 ( 包括测试人员 ) 的能力愈强经验愈丰富所犯错误便可能愈少所得软件产品质量愈高相应的可靠性也愈高

( 8 )软件开发方法 软件工程表明开发方法对软件可靠性有显著影响 与非结构化方法比较结构化方法可以明显减少软件缺陷数

( 9 )软件开发环境 研究表明程序语言软件开发环境影响软件的可靠性而软件测

试工具的优劣则影响可靠性测试结果

4 安全 (Safety)amp保密 (Security)

安全 (Safety) 是保证财产和人身受到损害可靠性是指在一定的环境条件下以及一定的时间内系统完成特定任务的可能性而有效性则是系统的长期的工作时间于其存在时间 ( 简单的定义为运行时间 +维护时间 ) 的 比例保密 (Security) 是针对危险破坏损失或非法活动而进行措施在一定层面上保密 (Security)要比安全 (Safety)宽广的多例如信息 Security家庭 Security 网络 Security 国家Security) 等

Security强调的是外在事物对特定目标的危害

Safety 是系统本身的潜在危害

四个概念的比较分析安全 (Safety)可靠性 (Reliability)有效性 (Availability)保密 (Security )安全 (Safety)高的系统 软件可靠性不

一定高可靠性和有效性并不是一码事保密 (Security )的系统 软件是安全

(Safety) 系统 软件的重要保障

可靠性安全性保密性 可靠(或可信)系统设计 (Reliable (or dependable) system design)是制造嵌入式系统所关注的甚至在面对内部或者外部问题时可靠系统设计经常假设问题是非恶意引起的

安全重要的系统设计 (Safety-critical system design)研究确保系统安全操作的方法独立于引起问题的原因

保密性 (Security)主要关注恶意攻击

Aizientis等人描述了可信性和保密性间的关系可信性和保密性由几个特性所组成

服务的可用性 (Availability) 服务的连续性 (Continuity) 来自用户和所处环境的灾难性后果的安全性 (Safety) 来自不合适系统改变的完整性 (Integrity) 通过更改和修补的可维护性 (Maintainability) 信息的机密性 (Confidentiality)

可用性完整性

可靠性安全性可维护性

机密性

可信性 保密性

5 新型攻击和对策1 )物理攻击嵌入式系统比通用计算机更容易受攻击 一个关键原因是许多嵌入式计算机对攻击者可物理访问

2 )互联网攻击一些嵌入式系统的攻击通过互联网访问变得更加容易今天许多嵌入式系统连接到互联网

3 )电池攻击 (battery attack)这种攻击试图通过耗尽电池来关闭节点

4 )服务拒绝攻击 (Denial-of-service attacks)

在通用系统中众所周知但是实时嵌入式系统可能更容易受服务质量 (quality-of-service (QoS))攻击如果网络发布实时数据那么发送过程中的一点延迟都能引起数据无效如果那些数据用来实时控制那么这些短暂延迟就能引起系统故障我们称这种危害为时间攻击因为它改变了系统的实时特性

QoS或者时间攻击之所以强大使因为它的影响不仅仅限于信息被控制系统的动态特性可决定系统的响应如果一个大型沉重快速运动的系统被控制那么时间上一个相对小的改变能引起大量的破坏

5 )网络(协议)攻击Wood和 Stankovic[Woo02]在传感器网络上确定了一些方式这些方式可在网络层次的不同层执行拒绝服务攻击如下所列

物理层 (Physical layer)mdashmdash拥塞破坏 链路层 (Link layer)mdashmdash碰撞耗尽非公平

网络和路由层 (Network and routing layer)mdashmdash丢弃和贪婪汇集方向误导黑洞认证监视冗余

传输层 (Transport layer)mdashmdash泛洪失步

6 )能量攻击Kocher等人 [Koc99]指出测量一个 CPU当前的能量供给能在很大程度上确定处理器的内部活动他们提出了两种能量攻击的方法简单能量分析 (simple power analysis)人工地跟踪检查和尝试确定程序作用的位置比如分支基于不同 CUP操作的能耗知识基于程序作用攻击者然后减少密钥的比特差分能量分析 (Differential power analysis)用相关性确定作用和密钥比特这种攻击最初目标是智能卡这种卡从外部读卡器获取能量但是这种攻击也能应用到许多嵌入式系统中

7 )反攻击 在一些时候有可能构造反破坏的嵌入式系统使电子设备难以发觉和分析延缓了攻击者芯片中有限的信息也有助阻止攻击者发现数据

6 Efficiency (效率)

ES must be efficient

bull Code-size efficient( 特别是片上系统 )

bull Run-time efficient

bull Weight efficient

bull Cost efficient

bull Energy efficient

能量有效性的重要意义

ldquoinherent power

efficiency of siliconldquo

59

低功耗设计问题 功耗问题是近几年来人们在嵌入式系统的设计中普遍关注的难点和热点它严重地制约着嵌入式系统的应用与发展

无论是在军事还是在商业贸易上的应用相当数量的嵌入式系统一般是由电池来供给电能的而且大多数嵌入式设备都有体积和质量的约束减少电能消耗不仅能延长电池的使用寿命延长用户更换电池的周期而且能带来提高系统性能与降低系统开销的好处甚至能起到保护环境的作用在便携式设备中 CPU消耗的电能越少电池的寿命就越长同时散发的热量少了所需的散热器就少了从而可减少该设备的花费和体积使产品尽快进入市场的目标

1 低功耗嵌入式应用系统是指以降低系统功耗为一个主要性能指标的嵌入式系统如计算机里的许多芯片过去用 5V供电现在用 33V 18V 并提出了绿色电器的概念

60

低功耗设备的要求1 )首先要求体积小重量轻便于携带2 )采用低功耗电路的设计方法以降低系统的功耗

它除了选用各种低功耗的器件和芯片外还在满足速度等性能指标的前提下进行降低功耗的硬件电路设计和软件设计

3 )有的系统应用在交流供电比较困难甚至无法用交流供电的场合因而各种电池(瓶)就成为其主要供电手段

4 )采用 LCD液晶显示器5 )采用 RS232C串行通信接口6 )采用微功耗高抗干扰的 CMOS集成电路

功耗产生的原因 P=UI

与功耗有关的因素

( 1 )电阻上消耗的功率( 2 )有源器件的开关转换阶段( 3 )集成电路内部和外部电容的充放电( 4 )系统的性能指标负载能力被处理信号的工作频率电路的工作频率电源的管理水平零部件的性能散热条件接口的物理性能等对系统功耗起着重要的作用

降低功耗的措施

功耗的组成动态 + 静态动态电源管理动态电压缩放低功耗硬件设计低功耗软件设计

二设计方法学概论

问题功 能 性能要求价 格 开发 周 期 等约束

设计 选择 折衷 分析比较 计算 评价

嵌入式系统

0嵌入式系统设计概述

方法 工具

设计方法论( design methodology )

设计方法论有以下三个重要理由1 )确认我们所做的每一件事情都是必须要作的

不会做无谓的白工也不会漏掉关键性的重要工作其中包含效率优化或是功能测试

2 )可以发展出计算机辅助工具或是设计经验累积汲取每一次产品发展的经验再经过量化之后可以发展出一套工具或是方法让往后的产品设计步入自动化

3 )开发团队遵循同一套方法论可以让团队成员更容易彼此沟通每个人都能在短时间内了解整体过程中将经历哪些过程需要何种支持与接收到何种结果此外也容易透过一套已经定义好的方法论彼此相互合作协调

设计目标 1 )上市时间

也就是 time-to-market 的观念2 )设计成本

许多消费性产品对于价格非常敏感所以产品厂商对于成本会斤斤计较是很合理的

3 )品质 顾客也许不需要最快最便宜的产品但是一定会要求功能质量保证不能只用一小段时间就坏掉了

传统的设计主要步骤

2 传统的设计流程方法1 )瀑布模型 (Waterfall)2 )螺旋模型 (Spiral)3 )连续改进 (Successive Refinement)4 )硬件与软件的同步设计 (SWHW Co-

deign)5 )阶层式 (Hierarchical) 设计6 )同步工程( concurrent

engineering )

瀑布模型 (Waterfall)

螺旋模型 (Spiral)

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 44: 大学计算机基础 —— 计算机科学概论

影响软件可靠性的因素( 3 )软件内部结构

结构越复杂软件复杂度越高内含缺陷数越大因而软件可靠度越低

( 4 )软件可靠性设计技术 一般是指软件设计阶段中采用的用以保证和提高软件可靠性为主要目标的软件技术

( 5 )软件可靠性测试 研究表明软件测试方法与资源投入对软件可靠性有不可忽视的影

响( 6 )软件可靠性管理

软件可靠性管理旨在系统管理软件生存期各阶段的可靠性活动使之系统化规范化一体化这样就可以避免许多人为错误以提高软件可靠性

影响软件可靠性的因素( 7 )软件开发人员能力和经验

软件开发人员 ( 包括测试人员 ) 的能力愈强经验愈丰富所犯错误便可能愈少所得软件产品质量愈高相应的可靠性也愈高

( 8 )软件开发方法 软件工程表明开发方法对软件可靠性有显著影响 与非结构化方法比较结构化方法可以明显减少软件缺陷数

( 9 )软件开发环境 研究表明程序语言软件开发环境影响软件的可靠性而软件测

试工具的优劣则影响可靠性测试结果

4 安全 (Safety)amp保密 (Security)

安全 (Safety) 是保证财产和人身受到损害可靠性是指在一定的环境条件下以及一定的时间内系统完成特定任务的可能性而有效性则是系统的长期的工作时间于其存在时间 ( 简单的定义为运行时间 +维护时间 ) 的 比例保密 (Security) 是针对危险破坏损失或非法活动而进行措施在一定层面上保密 (Security)要比安全 (Safety)宽广的多例如信息 Security家庭 Security 网络 Security 国家Security) 等

Security强调的是外在事物对特定目标的危害

Safety 是系统本身的潜在危害

四个概念的比较分析安全 (Safety)可靠性 (Reliability)有效性 (Availability)保密 (Security )安全 (Safety)高的系统 软件可靠性不

一定高可靠性和有效性并不是一码事保密 (Security )的系统 软件是安全

(Safety) 系统 软件的重要保障

可靠性安全性保密性 可靠(或可信)系统设计 (Reliable (or dependable) system design)是制造嵌入式系统所关注的甚至在面对内部或者外部问题时可靠系统设计经常假设问题是非恶意引起的

安全重要的系统设计 (Safety-critical system design)研究确保系统安全操作的方法独立于引起问题的原因

保密性 (Security)主要关注恶意攻击

Aizientis等人描述了可信性和保密性间的关系可信性和保密性由几个特性所组成

服务的可用性 (Availability) 服务的连续性 (Continuity) 来自用户和所处环境的灾难性后果的安全性 (Safety) 来自不合适系统改变的完整性 (Integrity) 通过更改和修补的可维护性 (Maintainability) 信息的机密性 (Confidentiality)

可用性完整性

可靠性安全性可维护性

机密性

可信性 保密性

5 新型攻击和对策1 )物理攻击嵌入式系统比通用计算机更容易受攻击 一个关键原因是许多嵌入式计算机对攻击者可物理访问

2 )互联网攻击一些嵌入式系统的攻击通过互联网访问变得更加容易今天许多嵌入式系统连接到互联网

3 )电池攻击 (battery attack)这种攻击试图通过耗尽电池来关闭节点

4 )服务拒绝攻击 (Denial-of-service attacks)

在通用系统中众所周知但是实时嵌入式系统可能更容易受服务质量 (quality-of-service (QoS))攻击如果网络发布实时数据那么发送过程中的一点延迟都能引起数据无效如果那些数据用来实时控制那么这些短暂延迟就能引起系统故障我们称这种危害为时间攻击因为它改变了系统的实时特性

QoS或者时间攻击之所以强大使因为它的影响不仅仅限于信息被控制系统的动态特性可决定系统的响应如果一个大型沉重快速运动的系统被控制那么时间上一个相对小的改变能引起大量的破坏

5 )网络(协议)攻击Wood和 Stankovic[Woo02]在传感器网络上确定了一些方式这些方式可在网络层次的不同层执行拒绝服务攻击如下所列

物理层 (Physical layer)mdashmdash拥塞破坏 链路层 (Link layer)mdashmdash碰撞耗尽非公平

网络和路由层 (Network and routing layer)mdashmdash丢弃和贪婪汇集方向误导黑洞认证监视冗余

传输层 (Transport layer)mdashmdash泛洪失步

6 )能量攻击Kocher等人 [Koc99]指出测量一个 CPU当前的能量供给能在很大程度上确定处理器的内部活动他们提出了两种能量攻击的方法简单能量分析 (simple power analysis)人工地跟踪检查和尝试确定程序作用的位置比如分支基于不同 CUP操作的能耗知识基于程序作用攻击者然后减少密钥的比特差分能量分析 (Differential power analysis)用相关性确定作用和密钥比特这种攻击最初目标是智能卡这种卡从外部读卡器获取能量但是这种攻击也能应用到许多嵌入式系统中

7 )反攻击 在一些时候有可能构造反破坏的嵌入式系统使电子设备难以发觉和分析延缓了攻击者芯片中有限的信息也有助阻止攻击者发现数据

6 Efficiency (效率)

ES must be efficient

bull Code-size efficient( 特别是片上系统 )

bull Run-time efficient

bull Weight efficient

bull Cost efficient

bull Energy efficient

能量有效性的重要意义

ldquoinherent power

efficiency of siliconldquo

59

低功耗设计问题 功耗问题是近几年来人们在嵌入式系统的设计中普遍关注的难点和热点它严重地制约着嵌入式系统的应用与发展

无论是在军事还是在商业贸易上的应用相当数量的嵌入式系统一般是由电池来供给电能的而且大多数嵌入式设备都有体积和质量的约束减少电能消耗不仅能延长电池的使用寿命延长用户更换电池的周期而且能带来提高系统性能与降低系统开销的好处甚至能起到保护环境的作用在便携式设备中 CPU消耗的电能越少电池的寿命就越长同时散发的热量少了所需的散热器就少了从而可减少该设备的花费和体积使产品尽快进入市场的目标

1 低功耗嵌入式应用系统是指以降低系统功耗为一个主要性能指标的嵌入式系统如计算机里的许多芯片过去用 5V供电现在用 33V 18V 并提出了绿色电器的概念

60

低功耗设备的要求1 )首先要求体积小重量轻便于携带2 )采用低功耗电路的设计方法以降低系统的功耗

它除了选用各种低功耗的器件和芯片外还在满足速度等性能指标的前提下进行降低功耗的硬件电路设计和软件设计

3 )有的系统应用在交流供电比较困难甚至无法用交流供电的场合因而各种电池(瓶)就成为其主要供电手段

4 )采用 LCD液晶显示器5 )采用 RS232C串行通信接口6 )采用微功耗高抗干扰的 CMOS集成电路

功耗产生的原因 P=UI

与功耗有关的因素

( 1 )电阻上消耗的功率( 2 )有源器件的开关转换阶段( 3 )集成电路内部和外部电容的充放电( 4 )系统的性能指标负载能力被处理信号的工作频率电路的工作频率电源的管理水平零部件的性能散热条件接口的物理性能等对系统功耗起着重要的作用

降低功耗的措施

功耗的组成动态 + 静态动态电源管理动态电压缩放低功耗硬件设计低功耗软件设计

二设计方法学概论

问题功 能 性能要求价 格 开发 周 期 等约束

设计 选择 折衷 分析比较 计算 评价

嵌入式系统

0嵌入式系统设计概述

方法 工具

设计方法论( design methodology )

设计方法论有以下三个重要理由1 )确认我们所做的每一件事情都是必须要作的

不会做无谓的白工也不会漏掉关键性的重要工作其中包含效率优化或是功能测试

2 )可以发展出计算机辅助工具或是设计经验累积汲取每一次产品发展的经验再经过量化之后可以发展出一套工具或是方法让往后的产品设计步入自动化

3 )开发团队遵循同一套方法论可以让团队成员更容易彼此沟通每个人都能在短时间内了解整体过程中将经历哪些过程需要何种支持与接收到何种结果此外也容易透过一套已经定义好的方法论彼此相互合作协调

设计目标 1 )上市时间

也就是 time-to-market 的观念2 )设计成本

许多消费性产品对于价格非常敏感所以产品厂商对于成本会斤斤计较是很合理的

3 )品质 顾客也许不需要最快最便宜的产品但是一定会要求功能质量保证不能只用一小段时间就坏掉了

传统的设计主要步骤

2 传统的设计流程方法1 )瀑布模型 (Waterfall)2 )螺旋模型 (Spiral)3 )连续改进 (Successive Refinement)4 )硬件与软件的同步设计 (SWHW Co-

deign)5 )阶层式 (Hierarchical) 设计6 )同步工程( concurrent

engineering )

瀑布模型 (Waterfall)

螺旋模型 (Spiral)

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 45: 大学计算机基础 —— 计算机科学概论

影响软件可靠性的因素( 7 )软件开发人员能力和经验

软件开发人员 ( 包括测试人员 ) 的能力愈强经验愈丰富所犯错误便可能愈少所得软件产品质量愈高相应的可靠性也愈高

( 8 )软件开发方法 软件工程表明开发方法对软件可靠性有显著影响 与非结构化方法比较结构化方法可以明显减少软件缺陷数

( 9 )软件开发环境 研究表明程序语言软件开发环境影响软件的可靠性而软件测

试工具的优劣则影响可靠性测试结果

4 安全 (Safety)amp保密 (Security)

安全 (Safety) 是保证财产和人身受到损害可靠性是指在一定的环境条件下以及一定的时间内系统完成特定任务的可能性而有效性则是系统的长期的工作时间于其存在时间 ( 简单的定义为运行时间 +维护时间 ) 的 比例保密 (Security) 是针对危险破坏损失或非法活动而进行措施在一定层面上保密 (Security)要比安全 (Safety)宽广的多例如信息 Security家庭 Security 网络 Security 国家Security) 等

Security强调的是外在事物对特定目标的危害

Safety 是系统本身的潜在危害

四个概念的比较分析安全 (Safety)可靠性 (Reliability)有效性 (Availability)保密 (Security )安全 (Safety)高的系统 软件可靠性不

一定高可靠性和有效性并不是一码事保密 (Security )的系统 软件是安全

(Safety) 系统 软件的重要保障

可靠性安全性保密性 可靠(或可信)系统设计 (Reliable (or dependable) system design)是制造嵌入式系统所关注的甚至在面对内部或者外部问题时可靠系统设计经常假设问题是非恶意引起的

安全重要的系统设计 (Safety-critical system design)研究确保系统安全操作的方法独立于引起问题的原因

保密性 (Security)主要关注恶意攻击

Aizientis等人描述了可信性和保密性间的关系可信性和保密性由几个特性所组成

服务的可用性 (Availability) 服务的连续性 (Continuity) 来自用户和所处环境的灾难性后果的安全性 (Safety) 来自不合适系统改变的完整性 (Integrity) 通过更改和修补的可维护性 (Maintainability) 信息的机密性 (Confidentiality)

可用性完整性

可靠性安全性可维护性

机密性

可信性 保密性

5 新型攻击和对策1 )物理攻击嵌入式系统比通用计算机更容易受攻击 一个关键原因是许多嵌入式计算机对攻击者可物理访问

2 )互联网攻击一些嵌入式系统的攻击通过互联网访问变得更加容易今天许多嵌入式系统连接到互联网

3 )电池攻击 (battery attack)这种攻击试图通过耗尽电池来关闭节点

4 )服务拒绝攻击 (Denial-of-service attacks)

在通用系统中众所周知但是实时嵌入式系统可能更容易受服务质量 (quality-of-service (QoS))攻击如果网络发布实时数据那么发送过程中的一点延迟都能引起数据无效如果那些数据用来实时控制那么这些短暂延迟就能引起系统故障我们称这种危害为时间攻击因为它改变了系统的实时特性

QoS或者时间攻击之所以强大使因为它的影响不仅仅限于信息被控制系统的动态特性可决定系统的响应如果一个大型沉重快速运动的系统被控制那么时间上一个相对小的改变能引起大量的破坏

5 )网络(协议)攻击Wood和 Stankovic[Woo02]在传感器网络上确定了一些方式这些方式可在网络层次的不同层执行拒绝服务攻击如下所列

物理层 (Physical layer)mdashmdash拥塞破坏 链路层 (Link layer)mdashmdash碰撞耗尽非公平

网络和路由层 (Network and routing layer)mdashmdash丢弃和贪婪汇集方向误导黑洞认证监视冗余

传输层 (Transport layer)mdashmdash泛洪失步

6 )能量攻击Kocher等人 [Koc99]指出测量一个 CPU当前的能量供给能在很大程度上确定处理器的内部活动他们提出了两种能量攻击的方法简单能量分析 (simple power analysis)人工地跟踪检查和尝试确定程序作用的位置比如分支基于不同 CUP操作的能耗知识基于程序作用攻击者然后减少密钥的比特差分能量分析 (Differential power analysis)用相关性确定作用和密钥比特这种攻击最初目标是智能卡这种卡从外部读卡器获取能量但是这种攻击也能应用到许多嵌入式系统中

7 )反攻击 在一些时候有可能构造反破坏的嵌入式系统使电子设备难以发觉和分析延缓了攻击者芯片中有限的信息也有助阻止攻击者发现数据

6 Efficiency (效率)

ES must be efficient

bull Code-size efficient( 特别是片上系统 )

bull Run-time efficient

bull Weight efficient

bull Cost efficient

bull Energy efficient

能量有效性的重要意义

ldquoinherent power

efficiency of siliconldquo

59

低功耗设计问题 功耗问题是近几年来人们在嵌入式系统的设计中普遍关注的难点和热点它严重地制约着嵌入式系统的应用与发展

无论是在军事还是在商业贸易上的应用相当数量的嵌入式系统一般是由电池来供给电能的而且大多数嵌入式设备都有体积和质量的约束减少电能消耗不仅能延长电池的使用寿命延长用户更换电池的周期而且能带来提高系统性能与降低系统开销的好处甚至能起到保护环境的作用在便携式设备中 CPU消耗的电能越少电池的寿命就越长同时散发的热量少了所需的散热器就少了从而可减少该设备的花费和体积使产品尽快进入市场的目标

1 低功耗嵌入式应用系统是指以降低系统功耗为一个主要性能指标的嵌入式系统如计算机里的许多芯片过去用 5V供电现在用 33V 18V 并提出了绿色电器的概念

60

低功耗设备的要求1 )首先要求体积小重量轻便于携带2 )采用低功耗电路的设计方法以降低系统的功耗

它除了选用各种低功耗的器件和芯片外还在满足速度等性能指标的前提下进行降低功耗的硬件电路设计和软件设计

3 )有的系统应用在交流供电比较困难甚至无法用交流供电的场合因而各种电池(瓶)就成为其主要供电手段

4 )采用 LCD液晶显示器5 )采用 RS232C串行通信接口6 )采用微功耗高抗干扰的 CMOS集成电路

功耗产生的原因 P=UI

与功耗有关的因素

( 1 )电阻上消耗的功率( 2 )有源器件的开关转换阶段( 3 )集成电路内部和外部电容的充放电( 4 )系统的性能指标负载能力被处理信号的工作频率电路的工作频率电源的管理水平零部件的性能散热条件接口的物理性能等对系统功耗起着重要的作用

降低功耗的措施

功耗的组成动态 + 静态动态电源管理动态电压缩放低功耗硬件设计低功耗软件设计

二设计方法学概论

问题功 能 性能要求价 格 开发 周 期 等约束

设计 选择 折衷 分析比较 计算 评价

嵌入式系统

0嵌入式系统设计概述

方法 工具

设计方法论( design methodology )

设计方法论有以下三个重要理由1 )确认我们所做的每一件事情都是必须要作的

不会做无谓的白工也不会漏掉关键性的重要工作其中包含效率优化或是功能测试

2 )可以发展出计算机辅助工具或是设计经验累积汲取每一次产品发展的经验再经过量化之后可以发展出一套工具或是方法让往后的产品设计步入自动化

3 )开发团队遵循同一套方法论可以让团队成员更容易彼此沟通每个人都能在短时间内了解整体过程中将经历哪些过程需要何种支持与接收到何种结果此外也容易透过一套已经定义好的方法论彼此相互合作协调

设计目标 1 )上市时间

也就是 time-to-market 的观念2 )设计成本

许多消费性产品对于价格非常敏感所以产品厂商对于成本会斤斤计较是很合理的

3 )品质 顾客也许不需要最快最便宜的产品但是一定会要求功能质量保证不能只用一小段时间就坏掉了

传统的设计主要步骤

2 传统的设计流程方法1 )瀑布模型 (Waterfall)2 )螺旋模型 (Spiral)3 )连续改进 (Successive Refinement)4 )硬件与软件的同步设计 (SWHW Co-

deign)5 )阶层式 (Hierarchical) 设计6 )同步工程( concurrent

engineering )

瀑布模型 (Waterfall)

螺旋模型 (Spiral)

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 46: 大学计算机基础 —— 计算机科学概论

4 安全 (Safety)amp保密 (Security)

安全 (Safety) 是保证财产和人身受到损害可靠性是指在一定的环境条件下以及一定的时间内系统完成特定任务的可能性而有效性则是系统的长期的工作时间于其存在时间 ( 简单的定义为运行时间 +维护时间 ) 的 比例保密 (Security) 是针对危险破坏损失或非法活动而进行措施在一定层面上保密 (Security)要比安全 (Safety)宽广的多例如信息 Security家庭 Security 网络 Security 国家Security) 等

Security强调的是外在事物对特定目标的危害

Safety 是系统本身的潜在危害

四个概念的比较分析安全 (Safety)可靠性 (Reliability)有效性 (Availability)保密 (Security )安全 (Safety)高的系统 软件可靠性不

一定高可靠性和有效性并不是一码事保密 (Security )的系统 软件是安全

(Safety) 系统 软件的重要保障

可靠性安全性保密性 可靠(或可信)系统设计 (Reliable (or dependable) system design)是制造嵌入式系统所关注的甚至在面对内部或者外部问题时可靠系统设计经常假设问题是非恶意引起的

安全重要的系统设计 (Safety-critical system design)研究确保系统安全操作的方法独立于引起问题的原因

保密性 (Security)主要关注恶意攻击

Aizientis等人描述了可信性和保密性间的关系可信性和保密性由几个特性所组成

服务的可用性 (Availability) 服务的连续性 (Continuity) 来自用户和所处环境的灾难性后果的安全性 (Safety) 来自不合适系统改变的完整性 (Integrity) 通过更改和修补的可维护性 (Maintainability) 信息的机密性 (Confidentiality)

可用性完整性

可靠性安全性可维护性

机密性

可信性 保密性

5 新型攻击和对策1 )物理攻击嵌入式系统比通用计算机更容易受攻击 一个关键原因是许多嵌入式计算机对攻击者可物理访问

2 )互联网攻击一些嵌入式系统的攻击通过互联网访问变得更加容易今天许多嵌入式系统连接到互联网

3 )电池攻击 (battery attack)这种攻击试图通过耗尽电池来关闭节点

4 )服务拒绝攻击 (Denial-of-service attacks)

在通用系统中众所周知但是实时嵌入式系统可能更容易受服务质量 (quality-of-service (QoS))攻击如果网络发布实时数据那么发送过程中的一点延迟都能引起数据无效如果那些数据用来实时控制那么这些短暂延迟就能引起系统故障我们称这种危害为时间攻击因为它改变了系统的实时特性

QoS或者时间攻击之所以强大使因为它的影响不仅仅限于信息被控制系统的动态特性可决定系统的响应如果一个大型沉重快速运动的系统被控制那么时间上一个相对小的改变能引起大量的破坏

5 )网络(协议)攻击Wood和 Stankovic[Woo02]在传感器网络上确定了一些方式这些方式可在网络层次的不同层执行拒绝服务攻击如下所列

物理层 (Physical layer)mdashmdash拥塞破坏 链路层 (Link layer)mdashmdash碰撞耗尽非公平

网络和路由层 (Network and routing layer)mdashmdash丢弃和贪婪汇集方向误导黑洞认证监视冗余

传输层 (Transport layer)mdashmdash泛洪失步

6 )能量攻击Kocher等人 [Koc99]指出测量一个 CPU当前的能量供给能在很大程度上确定处理器的内部活动他们提出了两种能量攻击的方法简单能量分析 (simple power analysis)人工地跟踪检查和尝试确定程序作用的位置比如分支基于不同 CUP操作的能耗知识基于程序作用攻击者然后减少密钥的比特差分能量分析 (Differential power analysis)用相关性确定作用和密钥比特这种攻击最初目标是智能卡这种卡从外部读卡器获取能量但是这种攻击也能应用到许多嵌入式系统中

7 )反攻击 在一些时候有可能构造反破坏的嵌入式系统使电子设备难以发觉和分析延缓了攻击者芯片中有限的信息也有助阻止攻击者发现数据

6 Efficiency (效率)

ES must be efficient

bull Code-size efficient( 特别是片上系统 )

bull Run-time efficient

bull Weight efficient

bull Cost efficient

bull Energy efficient

能量有效性的重要意义

ldquoinherent power

efficiency of siliconldquo

59

低功耗设计问题 功耗问题是近几年来人们在嵌入式系统的设计中普遍关注的难点和热点它严重地制约着嵌入式系统的应用与发展

无论是在军事还是在商业贸易上的应用相当数量的嵌入式系统一般是由电池来供给电能的而且大多数嵌入式设备都有体积和质量的约束减少电能消耗不仅能延长电池的使用寿命延长用户更换电池的周期而且能带来提高系统性能与降低系统开销的好处甚至能起到保护环境的作用在便携式设备中 CPU消耗的电能越少电池的寿命就越长同时散发的热量少了所需的散热器就少了从而可减少该设备的花费和体积使产品尽快进入市场的目标

1 低功耗嵌入式应用系统是指以降低系统功耗为一个主要性能指标的嵌入式系统如计算机里的许多芯片过去用 5V供电现在用 33V 18V 并提出了绿色电器的概念

60

低功耗设备的要求1 )首先要求体积小重量轻便于携带2 )采用低功耗电路的设计方法以降低系统的功耗

它除了选用各种低功耗的器件和芯片外还在满足速度等性能指标的前提下进行降低功耗的硬件电路设计和软件设计

3 )有的系统应用在交流供电比较困难甚至无法用交流供电的场合因而各种电池(瓶)就成为其主要供电手段

4 )采用 LCD液晶显示器5 )采用 RS232C串行通信接口6 )采用微功耗高抗干扰的 CMOS集成电路

功耗产生的原因 P=UI

与功耗有关的因素

( 1 )电阻上消耗的功率( 2 )有源器件的开关转换阶段( 3 )集成电路内部和外部电容的充放电( 4 )系统的性能指标负载能力被处理信号的工作频率电路的工作频率电源的管理水平零部件的性能散热条件接口的物理性能等对系统功耗起着重要的作用

降低功耗的措施

功耗的组成动态 + 静态动态电源管理动态电压缩放低功耗硬件设计低功耗软件设计

二设计方法学概论

问题功 能 性能要求价 格 开发 周 期 等约束

设计 选择 折衷 分析比较 计算 评价

嵌入式系统

0嵌入式系统设计概述

方法 工具

设计方法论( design methodology )

设计方法论有以下三个重要理由1 )确认我们所做的每一件事情都是必须要作的

不会做无谓的白工也不会漏掉关键性的重要工作其中包含效率优化或是功能测试

2 )可以发展出计算机辅助工具或是设计经验累积汲取每一次产品发展的经验再经过量化之后可以发展出一套工具或是方法让往后的产品设计步入自动化

3 )开发团队遵循同一套方法论可以让团队成员更容易彼此沟通每个人都能在短时间内了解整体过程中将经历哪些过程需要何种支持与接收到何种结果此外也容易透过一套已经定义好的方法论彼此相互合作协调

设计目标 1 )上市时间

也就是 time-to-market 的观念2 )设计成本

许多消费性产品对于价格非常敏感所以产品厂商对于成本会斤斤计较是很合理的

3 )品质 顾客也许不需要最快最便宜的产品但是一定会要求功能质量保证不能只用一小段时间就坏掉了

传统的设计主要步骤

2 传统的设计流程方法1 )瀑布模型 (Waterfall)2 )螺旋模型 (Spiral)3 )连续改进 (Successive Refinement)4 )硬件与软件的同步设计 (SWHW Co-

deign)5 )阶层式 (Hierarchical) 设计6 )同步工程( concurrent

engineering )

瀑布模型 (Waterfall)

螺旋模型 (Spiral)

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 47: 大学计算机基础 —— 计算机科学概论

四个概念的比较分析安全 (Safety)可靠性 (Reliability)有效性 (Availability)保密 (Security )安全 (Safety)高的系统 软件可靠性不

一定高可靠性和有效性并不是一码事保密 (Security )的系统 软件是安全

(Safety) 系统 软件的重要保障

可靠性安全性保密性 可靠(或可信)系统设计 (Reliable (or dependable) system design)是制造嵌入式系统所关注的甚至在面对内部或者外部问题时可靠系统设计经常假设问题是非恶意引起的

安全重要的系统设计 (Safety-critical system design)研究确保系统安全操作的方法独立于引起问题的原因

保密性 (Security)主要关注恶意攻击

Aizientis等人描述了可信性和保密性间的关系可信性和保密性由几个特性所组成

服务的可用性 (Availability) 服务的连续性 (Continuity) 来自用户和所处环境的灾难性后果的安全性 (Safety) 来自不合适系统改变的完整性 (Integrity) 通过更改和修补的可维护性 (Maintainability) 信息的机密性 (Confidentiality)

可用性完整性

可靠性安全性可维护性

机密性

可信性 保密性

5 新型攻击和对策1 )物理攻击嵌入式系统比通用计算机更容易受攻击 一个关键原因是许多嵌入式计算机对攻击者可物理访问

2 )互联网攻击一些嵌入式系统的攻击通过互联网访问变得更加容易今天许多嵌入式系统连接到互联网

3 )电池攻击 (battery attack)这种攻击试图通过耗尽电池来关闭节点

4 )服务拒绝攻击 (Denial-of-service attacks)

在通用系统中众所周知但是实时嵌入式系统可能更容易受服务质量 (quality-of-service (QoS))攻击如果网络发布实时数据那么发送过程中的一点延迟都能引起数据无效如果那些数据用来实时控制那么这些短暂延迟就能引起系统故障我们称这种危害为时间攻击因为它改变了系统的实时特性

QoS或者时间攻击之所以强大使因为它的影响不仅仅限于信息被控制系统的动态特性可决定系统的响应如果一个大型沉重快速运动的系统被控制那么时间上一个相对小的改变能引起大量的破坏

5 )网络(协议)攻击Wood和 Stankovic[Woo02]在传感器网络上确定了一些方式这些方式可在网络层次的不同层执行拒绝服务攻击如下所列

物理层 (Physical layer)mdashmdash拥塞破坏 链路层 (Link layer)mdashmdash碰撞耗尽非公平

网络和路由层 (Network and routing layer)mdashmdash丢弃和贪婪汇集方向误导黑洞认证监视冗余

传输层 (Transport layer)mdashmdash泛洪失步

6 )能量攻击Kocher等人 [Koc99]指出测量一个 CPU当前的能量供给能在很大程度上确定处理器的内部活动他们提出了两种能量攻击的方法简单能量分析 (simple power analysis)人工地跟踪检查和尝试确定程序作用的位置比如分支基于不同 CUP操作的能耗知识基于程序作用攻击者然后减少密钥的比特差分能量分析 (Differential power analysis)用相关性确定作用和密钥比特这种攻击最初目标是智能卡这种卡从外部读卡器获取能量但是这种攻击也能应用到许多嵌入式系统中

7 )反攻击 在一些时候有可能构造反破坏的嵌入式系统使电子设备难以发觉和分析延缓了攻击者芯片中有限的信息也有助阻止攻击者发现数据

6 Efficiency (效率)

ES must be efficient

bull Code-size efficient( 特别是片上系统 )

bull Run-time efficient

bull Weight efficient

bull Cost efficient

bull Energy efficient

能量有效性的重要意义

ldquoinherent power

efficiency of siliconldquo

59

低功耗设计问题 功耗问题是近几年来人们在嵌入式系统的设计中普遍关注的难点和热点它严重地制约着嵌入式系统的应用与发展

无论是在军事还是在商业贸易上的应用相当数量的嵌入式系统一般是由电池来供给电能的而且大多数嵌入式设备都有体积和质量的约束减少电能消耗不仅能延长电池的使用寿命延长用户更换电池的周期而且能带来提高系统性能与降低系统开销的好处甚至能起到保护环境的作用在便携式设备中 CPU消耗的电能越少电池的寿命就越长同时散发的热量少了所需的散热器就少了从而可减少该设备的花费和体积使产品尽快进入市场的目标

1 低功耗嵌入式应用系统是指以降低系统功耗为一个主要性能指标的嵌入式系统如计算机里的许多芯片过去用 5V供电现在用 33V 18V 并提出了绿色电器的概念

60

低功耗设备的要求1 )首先要求体积小重量轻便于携带2 )采用低功耗电路的设计方法以降低系统的功耗

它除了选用各种低功耗的器件和芯片外还在满足速度等性能指标的前提下进行降低功耗的硬件电路设计和软件设计

3 )有的系统应用在交流供电比较困难甚至无法用交流供电的场合因而各种电池(瓶)就成为其主要供电手段

4 )采用 LCD液晶显示器5 )采用 RS232C串行通信接口6 )采用微功耗高抗干扰的 CMOS集成电路

功耗产生的原因 P=UI

与功耗有关的因素

( 1 )电阻上消耗的功率( 2 )有源器件的开关转换阶段( 3 )集成电路内部和外部电容的充放电( 4 )系统的性能指标负载能力被处理信号的工作频率电路的工作频率电源的管理水平零部件的性能散热条件接口的物理性能等对系统功耗起着重要的作用

降低功耗的措施

功耗的组成动态 + 静态动态电源管理动态电压缩放低功耗硬件设计低功耗软件设计

二设计方法学概论

问题功 能 性能要求价 格 开发 周 期 等约束

设计 选择 折衷 分析比较 计算 评价

嵌入式系统

0嵌入式系统设计概述

方法 工具

设计方法论( design methodology )

设计方法论有以下三个重要理由1 )确认我们所做的每一件事情都是必须要作的

不会做无谓的白工也不会漏掉关键性的重要工作其中包含效率优化或是功能测试

2 )可以发展出计算机辅助工具或是设计经验累积汲取每一次产品发展的经验再经过量化之后可以发展出一套工具或是方法让往后的产品设计步入自动化

3 )开发团队遵循同一套方法论可以让团队成员更容易彼此沟通每个人都能在短时间内了解整体过程中将经历哪些过程需要何种支持与接收到何种结果此外也容易透过一套已经定义好的方法论彼此相互合作协调

设计目标 1 )上市时间

也就是 time-to-market 的观念2 )设计成本

许多消费性产品对于价格非常敏感所以产品厂商对于成本会斤斤计较是很合理的

3 )品质 顾客也许不需要最快最便宜的产品但是一定会要求功能质量保证不能只用一小段时间就坏掉了

传统的设计主要步骤

2 传统的设计流程方法1 )瀑布模型 (Waterfall)2 )螺旋模型 (Spiral)3 )连续改进 (Successive Refinement)4 )硬件与软件的同步设计 (SWHW Co-

deign)5 )阶层式 (Hierarchical) 设计6 )同步工程( concurrent

engineering )

瀑布模型 (Waterfall)

螺旋模型 (Spiral)

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 48: 大学计算机基础 —— 计算机科学概论

可靠性安全性保密性 可靠(或可信)系统设计 (Reliable (or dependable) system design)是制造嵌入式系统所关注的甚至在面对内部或者外部问题时可靠系统设计经常假设问题是非恶意引起的

安全重要的系统设计 (Safety-critical system design)研究确保系统安全操作的方法独立于引起问题的原因

保密性 (Security)主要关注恶意攻击

Aizientis等人描述了可信性和保密性间的关系可信性和保密性由几个特性所组成

服务的可用性 (Availability) 服务的连续性 (Continuity) 来自用户和所处环境的灾难性后果的安全性 (Safety) 来自不合适系统改变的完整性 (Integrity) 通过更改和修补的可维护性 (Maintainability) 信息的机密性 (Confidentiality)

可用性完整性

可靠性安全性可维护性

机密性

可信性 保密性

5 新型攻击和对策1 )物理攻击嵌入式系统比通用计算机更容易受攻击 一个关键原因是许多嵌入式计算机对攻击者可物理访问

2 )互联网攻击一些嵌入式系统的攻击通过互联网访问变得更加容易今天许多嵌入式系统连接到互联网

3 )电池攻击 (battery attack)这种攻击试图通过耗尽电池来关闭节点

4 )服务拒绝攻击 (Denial-of-service attacks)

在通用系统中众所周知但是实时嵌入式系统可能更容易受服务质量 (quality-of-service (QoS))攻击如果网络发布实时数据那么发送过程中的一点延迟都能引起数据无效如果那些数据用来实时控制那么这些短暂延迟就能引起系统故障我们称这种危害为时间攻击因为它改变了系统的实时特性

QoS或者时间攻击之所以强大使因为它的影响不仅仅限于信息被控制系统的动态特性可决定系统的响应如果一个大型沉重快速运动的系统被控制那么时间上一个相对小的改变能引起大量的破坏

5 )网络(协议)攻击Wood和 Stankovic[Woo02]在传感器网络上确定了一些方式这些方式可在网络层次的不同层执行拒绝服务攻击如下所列

物理层 (Physical layer)mdashmdash拥塞破坏 链路层 (Link layer)mdashmdash碰撞耗尽非公平

网络和路由层 (Network and routing layer)mdashmdash丢弃和贪婪汇集方向误导黑洞认证监视冗余

传输层 (Transport layer)mdashmdash泛洪失步

6 )能量攻击Kocher等人 [Koc99]指出测量一个 CPU当前的能量供给能在很大程度上确定处理器的内部活动他们提出了两种能量攻击的方法简单能量分析 (simple power analysis)人工地跟踪检查和尝试确定程序作用的位置比如分支基于不同 CUP操作的能耗知识基于程序作用攻击者然后减少密钥的比特差分能量分析 (Differential power analysis)用相关性确定作用和密钥比特这种攻击最初目标是智能卡这种卡从外部读卡器获取能量但是这种攻击也能应用到许多嵌入式系统中

7 )反攻击 在一些时候有可能构造反破坏的嵌入式系统使电子设备难以发觉和分析延缓了攻击者芯片中有限的信息也有助阻止攻击者发现数据

6 Efficiency (效率)

ES must be efficient

bull Code-size efficient( 特别是片上系统 )

bull Run-time efficient

bull Weight efficient

bull Cost efficient

bull Energy efficient

能量有效性的重要意义

ldquoinherent power

efficiency of siliconldquo

59

低功耗设计问题 功耗问题是近几年来人们在嵌入式系统的设计中普遍关注的难点和热点它严重地制约着嵌入式系统的应用与发展

无论是在军事还是在商业贸易上的应用相当数量的嵌入式系统一般是由电池来供给电能的而且大多数嵌入式设备都有体积和质量的约束减少电能消耗不仅能延长电池的使用寿命延长用户更换电池的周期而且能带来提高系统性能与降低系统开销的好处甚至能起到保护环境的作用在便携式设备中 CPU消耗的电能越少电池的寿命就越长同时散发的热量少了所需的散热器就少了从而可减少该设备的花费和体积使产品尽快进入市场的目标

1 低功耗嵌入式应用系统是指以降低系统功耗为一个主要性能指标的嵌入式系统如计算机里的许多芯片过去用 5V供电现在用 33V 18V 并提出了绿色电器的概念

60

低功耗设备的要求1 )首先要求体积小重量轻便于携带2 )采用低功耗电路的设计方法以降低系统的功耗

它除了选用各种低功耗的器件和芯片外还在满足速度等性能指标的前提下进行降低功耗的硬件电路设计和软件设计

3 )有的系统应用在交流供电比较困难甚至无法用交流供电的场合因而各种电池(瓶)就成为其主要供电手段

4 )采用 LCD液晶显示器5 )采用 RS232C串行通信接口6 )采用微功耗高抗干扰的 CMOS集成电路

功耗产生的原因 P=UI

与功耗有关的因素

( 1 )电阻上消耗的功率( 2 )有源器件的开关转换阶段( 3 )集成电路内部和外部电容的充放电( 4 )系统的性能指标负载能力被处理信号的工作频率电路的工作频率电源的管理水平零部件的性能散热条件接口的物理性能等对系统功耗起着重要的作用

降低功耗的措施

功耗的组成动态 + 静态动态电源管理动态电压缩放低功耗硬件设计低功耗软件设计

二设计方法学概论

问题功 能 性能要求价 格 开发 周 期 等约束

设计 选择 折衷 分析比较 计算 评价

嵌入式系统

0嵌入式系统设计概述

方法 工具

设计方法论( design methodology )

设计方法论有以下三个重要理由1 )确认我们所做的每一件事情都是必须要作的

不会做无谓的白工也不会漏掉关键性的重要工作其中包含效率优化或是功能测试

2 )可以发展出计算机辅助工具或是设计经验累积汲取每一次产品发展的经验再经过量化之后可以发展出一套工具或是方法让往后的产品设计步入自动化

3 )开发团队遵循同一套方法论可以让团队成员更容易彼此沟通每个人都能在短时间内了解整体过程中将经历哪些过程需要何种支持与接收到何种结果此外也容易透过一套已经定义好的方法论彼此相互合作协调

设计目标 1 )上市时间

也就是 time-to-market 的观念2 )设计成本

许多消费性产品对于价格非常敏感所以产品厂商对于成本会斤斤计较是很合理的

3 )品质 顾客也许不需要最快最便宜的产品但是一定会要求功能质量保证不能只用一小段时间就坏掉了

传统的设计主要步骤

2 传统的设计流程方法1 )瀑布模型 (Waterfall)2 )螺旋模型 (Spiral)3 )连续改进 (Successive Refinement)4 )硬件与软件的同步设计 (SWHW Co-

deign)5 )阶层式 (Hierarchical) 设计6 )同步工程( concurrent

engineering )

瀑布模型 (Waterfall)

螺旋模型 (Spiral)

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 49: 大学计算机基础 —— 计算机科学概论

Aizientis等人描述了可信性和保密性间的关系可信性和保密性由几个特性所组成

服务的可用性 (Availability) 服务的连续性 (Continuity) 来自用户和所处环境的灾难性后果的安全性 (Safety) 来自不合适系统改变的完整性 (Integrity) 通过更改和修补的可维护性 (Maintainability) 信息的机密性 (Confidentiality)

可用性完整性

可靠性安全性可维护性

机密性

可信性 保密性

5 新型攻击和对策1 )物理攻击嵌入式系统比通用计算机更容易受攻击 一个关键原因是许多嵌入式计算机对攻击者可物理访问

2 )互联网攻击一些嵌入式系统的攻击通过互联网访问变得更加容易今天许多嵌入式系统连接到互联网

3 )电池攻击 (battery attack)这种攻击试图通过耗尽电池来关闭节点

4 )服务拒绝攻击 (Denial-of-service attacks)

在通用系统中众所周知但是实时嵌入式系统可能更容易受服务质量 (quality-of-service (QoS))攻击如果网络发布实时数据那么发送过程中的一点延迟都能引起数据无效如果那些数据用来实时控制那么这些短暂延迟就能引起系统故障我们称这种危害为时间攻击因为它改变了系统的实时特性

QoS或者时间攻击之所以强大使因为它的影响不仅仅限于信息被控制系统的动态特性可决定系统的响应如果一个大型沉重快速运动的系统被控制那么时间上一个相对小的改变能引起大量的破坏

5 )网络(协议)攻击Wood和 Stankovic[Woo02]在传感器网络上确定了一些方式这些方式可在网络层次的不同层执行拒绝服务攻击如下所列

物理层 (Physical layer)mdashmdash拥塞破坏 链路层 (Link layer)mdashmdash碰撞耗尽非公平

网络和路由层 (Network and routing layer)mdashmdash丢弃和贪婪汇集方向误导黑洞认证监视冗余

传输层 (Transport layer)mdashmdash泛洪失步

6 )能量攻击Kocher等人 [Koc99]指出测量一个 CPU当前的能量供给能在很大程度上确定处理器的内部活动他们提出了两种能量攻击的方法简单能量分析 (simple power analysis)人工地跟踪检查和尝试确定程序作用的位置比如分支基于不同 CUP操作的能耗知识基于程序作用攻击者然后减少密钥的比特差分能量分析 (Differential power analysis)用相关性确定作用和密钥比特这种攻击最初目标是智能卡这种卡从外部读卡器获取能量但是这种攻击也能应用到许多嵌入式系统中

7 )反攻击 在一些时候有可能构造反破坏的嵌入式系统使电子设备难以发觉和分析延缓了攻击者芯片中有限的信息也有助阻止攻击者发现数据

6 Efficiency (效率)

ES must be efficient

bull Code-size efficient( 特别是片上系统 )

bull Run-time efficient

bull Weight efficient

bull Cost efficient

bull Energy efficient

能量有效性的重要意义

ldquoinherent power

efficiency of siliconldquo

59

低功耗设计问题 功耗问题是近几年来人们在嵌入式系统的设计中普遍关注的难点和热点它严重地制约着嵌入式系统的应用与发展

无论是在军事还是在商业贸易上的应用相当数量的嵌入式系统一般是由电池来供给电能的而且大多数嵌入式设备都有体积和质量的约束减少电能消耗不仅能延长电池的使用寿命延长用户更换电池的周期而且能带来提高系统性能与降低系统开销的好处甚至能起到保护环境的作用在便携式设备中 CPU消耗的电能越少电池的寿命就越长同时散发的热量少了所需的散热器就少了从而可减少该设备的花费和体积使产品尽快进入市场的目标

1 低功耗嵌入式应用系统是指以降低系统功耗为一个主要性能指标的嵌入式系统如计算机里的许多芯片过去用 5V供电现在用 33V 18V 并提出了绿色电器的概念

60

低功耗设备的要求1 )首先要求体积小重量轻便于携带2 )采用低功耗电路的设计方法以降低系统的功耗

它除了选用各种低功耗的器件和芯片外还在满足速度等性能指标的前提下进行降低功耗的硬件电路设计和软件设计

3 )有的系统应用在交流供电比较困难甚至无法用交流供电的场合因而各种电池(瓶)就成为其主要供电手段

4 )采用 LCD液晶显示器5 )采用 RS232C串行通信接口6 )采用微功耗高抗干扰的 CMOS集成电路

功耗产生的原因 P=UI

与功耗有关的因素

( 1 )电阻上消耗的功率( 2 )有源器件的开关转换阶段( 3 )集成电路内部和外部电容的充放电( 4 )系统的性能指标负载能力被处理信号的工作频率电路的工作频率电源的管理水平零部件的性能散热条件接口的物理性能等对系统功耗起着重要的作用

降低功耗的措施

功耗的组成动态 + 静态动态电源管理动态电压缩放低功耗硬件设计低功耗软件设计

二设计方法学概论

问题功 能 性能要求价 格 开发 周 期 等约束

设计 选择 折衷 分析比较 计算 评价

嵌入式系统

0嵌入式系统设计概述

方法 工具

设计方法论( design methodology )

设计方法论有以下三个重要理由1 )确认我们所做的每一件事情都是必须要作的

不会做无谓的白工也不会漏掉关键性的重要工作其中包含效率优化或是功能测试

2 )可以发展出计算机辅助工具或是设计经验累积汲取每一次产品发展的经验再经过量化之后可以发展出一套工具或是方法让往后的产品设计步入自动化

3 )开发团队遵循同一套方法论可以让团队成员更容易彼此沟通每个人都能在短时间内了解整体过程中将经历哪些过程需要何种支持与接收到何种结果此外也容易透过一套已经定义好的方法论彼此相互合作协调

设计目标 1 )上市时间

也就是 time-to-market 的观念2 )设计成本

许多消费性产品对于价格非常敏感所以产品厂商对于成本会斤斤计较是很合理的

3 )品质 顾客也许不需要最快最便宜的产品但是一定会要求功能质量保证不能只用一小段时间就坏掉了

传统的设计主要步骤

2 传统的设计流程方法1 )瀑布模型 (Waterfall)2 )螺旋模型 (Spiral)3 )连续改进 (Successive Refinement)4 )硬件与软件的同步设计 (SWHW Co-

deign)5 )阶层式 (Hierarchical) 设计6 )同步工程( concurrent

engineering )

瀑布模型 (Waterfall)

螺旋模型 (Spiral)

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 50: 大学计算机基础 —— 计算机科学概论

5 新型攻击和对策1 )物理攻击嵌入式系统比通用计算机更容易受攻击 一个关键原因是许多嵌入式计算机对攻击者可物理访问

2 )互联网攻击一些嵌入式系统的攻击通过互联网访问变得更加容易今天许多嵌入式系统连接到互联网

3 )电池攻击 (battery attack)这种攻击试图通过耗尽电池来关闭节点

4 )服务拒绝攻击 (Denial-of-service attacks)

在通用系统中众所周知但是实时嵌入式系统可能更容易受服务质量 (quality-of-service (QoS))攻击如果网络发布实时数据那么发送过程中的一点延迟都能引起数据无效如果那些数据用来实时控制那么这些短暂延迟就能引起系统故障我们称这种危害为时间攻击因为它改变了系统的实时特性

QoS或者时间攻击之所以强大使因为它的影响不仅仅限于信息被控制系统的动态特性可决定系统的响应如果一个大型沉重快速运动的系统被控制那么时间上一个相对小的改变能引起大量的破坏

5 )网络(协议)攻击Wood和 Stankovic[Woo02]在传感器网络上确定了一些方式这些方式可在网络层次的不同层执行拒绝服务攻击如下所列

物理层 (Physical layer)mdashmdash拥塞破坏 链路层 (Link layer)mdashmdash碰撞耗尽非公平

网络和路由层 (Network and routing layer)mdashmdash丢弃和贪婪汇集方向误导黑洞认证监视冗余

传输层 (Transport layer)mdashmdash泛洪失步

6 )能量攻击Kocher等人 [Koc99]指出测量一个 CPU当前的能量供给能在很大程度上确定处理器的内部活动他们提出了两种能量攻击的方法简单能量分析 (simple power analysis)人工地跟踪检查和尝试确定程序作用的位置比如分支基于不同 CUP操作的能耗知识基于程序作用攻击者然后减少密钥的比特差分能量分析 (Differential power analysis)用相关性确定作用和密钥比特这种攻击最初目标是智能卡这种卡从外部读卡器获取能量但是这种攻击也能应用到许多嵌入式系统中

7 )反攻击 在一些时候有可能构造反破坏的嵌入式系统使电子设备难以发觉和分析延缓了攻击者芯片中有限的信息也有助阻止攻击者发现数据

6 Efficiency (效率)

ES must be efficient

bull Code-size efficient( 特别是片上系统 )

bull Run-time efficient

bull Weight efficient

bull Cost efficient

bull Energy efficient

能量有效性的重要意义

ldquoinherent power

efficiency of siliconldquo

59

低功耗设计问题 功耗问题是近几年来人们在嵌入式系统的设计中普遍关注的难点和热点它严重地制约着嵌入式系统的应用与发展

无论是在军事还是在商业贸易上的应用相当数量的嵌入式系统一般是由电池来供给电能的而且大多数嵌入式设备都有体积和质量的约束减少电能消耗不仅能延长电池的使用寿命延长用户更换电池的周期而且能带来提高系统性能与降低系统开销的好处甚至能起到保护环境的作用在便携式设备中 CPU消耗的电能越少电池的寿命就越长同时散发的热量少了所需的散热器就少了从而可减少该设备的花费和体积使产品尽快进入市场的目标

1 低功耗嵌入式应用系统是指以降低系统功耗为一个主要性能指标的嵌入式系统如计算机里的许多芯片过去用 5V供电现在用 33V 18V 并提出了绿色电器的概念

60

低功耗设备的要求1 )首先要求体积小重量轻便于携带2 )采用低功耗电路的设计方法以降低系统的功耗

它除了选用各种低功耗的器件和芯片外还在满足速度等性能指标的前提下进行降低功耗的硬件电路设计和软件设计

3 )有的系统应用在交流供电比较困难甚至无法用交流供电的场合因而各种电池(瓶)就成为其主要供电手段

4 )采用 LCD液晶显示器5 )采用 RS232C串行通信接口6 )采用微功耗高抗干扰的 CMOS集成电路

功耗产生的原因 P=UI

与功耗有关的因素

( 1 )电阻上消耗的功率( 2 )有源器件的开关转换阶段( 3 )集成电路内部和外部电容的充放电( 4 )系统的性能指标负载能力被处理信号的工作频率电路的工作频率电源的管理水平零部件的性能散热条件接口的物理性能等对系统功耗起着重要的作用

降低功耗的措施

功耗的组成动态 + 静态动态电源管理动态电压缩放低功耗硬件设计低功耗软件设计

二设计方法学概论

问题功 能 性能要求价 格 开发 周 期 等约束

设计 选择 折衷 分析比较 计算 评价

嵌入式系统

0嵌入式系统设计概述

方法 工具

设计方法论( design methodology )

设计方法论有以下三个重要理由1 )确认我们所做的每一件事情都是必须要作的

不会做无谓的白工也不会漏掉关键性的重要工作其中包含效率优化或是功能测试

2 )可以发展出计算机辅助工具或是设计经验累积汲取每一次产品发展的经验再经过量化之后可以发展出一套工具或是方法让往后的产品设计步入自动化

3 )开发团队遵循同一套方法论可以让团队成员更容易彼此沟通每个人都能在短时间内了解整体过程中将经历哪些过程需要何种支持与接收到何种结果此外也容易透过一套已经定义好的方法论彼此相互合作协调

设计目标 1 )上市时间

也就是 time-to-market 的观念2 )设计成本

许多消费性产品对于价格非常敏感所以产品厂商对于成本会斤斤计较是很合理的

3 )品质 顾客也许不需要最快最便宜的产品但是一定会要求功能质量保证不能只用一小段时间就坏掉了

传统的设计主要步骤

2 传统的设计流程方法1 )瀑布模型 (Waterfall)2 )螺旋模型 (Spiral)3 )连续改进 (Successive Refinement)4 )硬件与软件的同步设计 (SWHW Co-

deign)5 )阶层式 (Hierarchical) 设计6 )同步工程( concurrent

engineering )

瀑布模型 (Waterfall)

螺旋模型 (Spiral)

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 51: 大学计算机基础 —— 计算机科学概论

4 )服务拒绝攻击 (Denial-of-service attacks)

在通用系统中众所周知但是实时嵌入式系统可能更容易受服务质量 (quality-of-service (QoS))攻击如果网络发布实时数据那么发送过程中的一点延迟都能引起数据无效如果那些数据用来实时控制那么这些短暂延迟就能引起系统故障我们称这种危害为时间攻击因为它改变了系统的实时特性

QoS或者时间攻击之所以强大使因为它的影响不仅仅限于信息被控制系统的动态特性可决定系统的响应如果一个大型沉重快速运动的系统被控制那么时间上一个相对小的改变能引起大量的破坏

5 )网络(协议)攻击Wood和 Stankovic[Woo02]在传感器网络上确定了一些方式这些方式可在网络层次的不同层执行拒绝服务攻击如下所列

物理层 (Physical layer)mdashmdash拥塞破坏 链路层 (Link layer)mdashmdash碰撞耗尽非公平

网络和路由层 (Network and routing layer)mdashmdash丢弃和贪婪汇集方向误导黑洞认证监视冗余

传输层 (Transport layer)mdashmdash泛洪失步

6 )能量攻击Kocher等人 [Koc99]指出测量一个 CPU当前的能量供给能在很大程度上确定处理器的内部活动他们提出了两种能量攻击的方法简单能量分析 (simple power analysis)人工地跟踪检查和尝试确定程序作用的位置比如分支基于不同 CUP操作的能耗知识基于程序作用攻击者然后减少密钥的比特差分能量分析 (Differential power analysis)用相关性确定作用和密钥比特这种攻击最初目标是智能卡这种卡从外部读卡器获取能量但是这种攻击也能应用到许多嵌入式系统中

7 )反攻击 在一些时候有可能构造反破坏的嵌入式系统使电子设备难以发觉和分析延缓了攻击者芯片中有限的信息也有助阻止攻击者发现数据

6 Efficiency (效率)

ES must be efficient

bull Code-size efficient( 特别是片上系统 )

bull Run-time efficient

bull Weight efficient

bull Cost efficient

bull Energy efficient

能量有效性的重要意义

ldquoinherent power

efficiency of siliconldquo

59

低功耗设计问题 功耗问题是近几年来人们在嵌入式系统的设计中普遍关注的难点和热点它严重地制约着嵌入式系统的应用与发展

无论是在军事还是在商业贸易上的应用相当数量的嵌入式系统一般是由电池来供给电能的而且大多数嵌入式设备都有体积和质量的约束减少电能消耗不仅能延长电池的使用寿命延长用户更换电池的周期而且能带来提高系统性能与降低系统开销的好处甚至能起到保护环境的作用在便携式设备中 CPU消耗的电能越少电池的寿命就越长同时散发的热量少了所需的散热器就少了从而可减少该设备的花费和体积使产品尽快进入市场的目标

1 低功耗嵌入式应用系统是指以降低系统功耗为一个主要性能指标的嵌入式系统如计算机里的许多芯片过去用 5V供电现在用 33V 18V 并提出了绿色电器的概念

60

低功耗设备的要求1 )首先要求体积小重量轻便于携带2 )采用低功耗电路的设计方法以降低系统的功耗

它除了选用各种低功耗的器件和芯片外还在满足速度等性能指标的前提下进行降低功耗的硬件电路设计和软件设计

3 )有的系统应用在交流供电比较困难甚至无法用交流供电的场合因而各种电池(瓶)就成为其主要供电手段

4 )采用 LCD液晶显示器5 )采用 RS232C串行通信接口6 )采用微功耗高抗干扰的 CMOS集成电路

功耗产生的原因 P=UI

与功耗有关的因素

( 1 )电阻上消耗的功率( 2 )有源器件的开关转换阶段( 3 )集成电路内部和外部电容的充放电( 4 )系统的性能指标负载能力被处理信号的工作频率电路的工作频率电源的管理水平零部件的性能散热条件接口的物理性能等对系统功耗起着重要的作用

降低功耗的措施

功耗的组成动态 + 静态动态电源管理动态电压缩放低功耗硬件设计低功耗软件设计

二设计方法学概论

问题功 能 性能要求价 格 开发 周 期 等约束

设计 选择 折衷 分析比较 计算 评价

嵌入式系统

0嵌入式系统设计概述

方法 工具

设计方法论( design methodology )

设计方法论有以下三个重要理由1 )确认我们所做的每一件事情都是必须要作的

不会做无谓的白工也不会漏掉关键性的重要工作其中包含效率优化或是功能测试

2 )可以发展出计算机辅助工具或是设计经验累积汲取每一次产品发展的经验再经过量化之后可以发展出一套工具或是方法让往后的产品设计步入自动化

3 )开发团队遵循同一套方法论可以让团队成员更容易彼此沟通每个人都能在短时间内了解整体过程中将经历哪些过程需要何种支持与接收到何种结果此外也容易透过一套已经定义好的方法论彼此相互合作协调

设计目标 1 )上市时间

也就是 time-to-market 的观念2 )设计成本

许多消费性产品对于价格非常敏感所以产品厂商对于成本会斤斤计较是很合理的

3 )品质 顾客也许不需要最快最便宜的产品但是一定会要求功能质量保证不能只用一小段时间就坏掉了

传统的设计主要步骤

2 传统的设计流程方法1 )瀑布模型 (Waterfall)2 )螺旋模型 (Spiral)3 )连续改进 (Successive Refinement)4 )硬件与软件的同步设计 (SWHW Co-

deign)5 )阶层式 (Hierarchical) 设计6 )同步工程( concurrent

engineering )

瀑布模型 (Waterfall)

螺旋模型 (Spiral)

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 52: 大学计算机基础 —— 计算机科学概论

5 )网络(协议)攻击Wood和 Stankovic[Woo02]在传感器网络上确定了一些方式这些方式可在网络层次的不同层执行拒绝服务攻击如下所列

物理层 (Physical layer)mdashmdash拥塞破坏 链路层 (Link layer)mdashmdash碰撞耗尽非公平

网络和路由层 (Network and routing layer)mdashmdash丢弃和贪婪汇集方向误导黑洞认证监视冗余

传输层 (Transport layer)mdashmdash泛洪失步

6 )能量攻击Kocher等人 [Koc99]指出测量一个 CPU当前的能量供给能在很大程度上确定处理器的内部活动他们提出了两种能量攻击的方法简单能量分析 (simple power analysis)人工地跟踪检查和尝试确定程序作用的位置比如分支基于不同 CUP操作的能耗知识基于程序作用攻击者然后减少密钥的比特差分能量分析 (Differential power analysis)用相关性确定作用和密钥比特这种攻击最初目标是智能卡这种卡从外部读卡器获取能量但是这种攻击也能应用到许多嵌入式系统中

7 )反攻击 在一些时候有可能构造反破坏的嵌入式系统使电子设备难以发觉和分析延缓了攻击者芯片中有限的信息也有助阻止攻击者发现数据

6 Efficiency (效率)

ES must be efficient

bull Code-size efficient( 特别是片上系统 )

bull Run-time efficient

bull Weight efficient

bull Cost efficient

bull Energy efficient

能量有效性的重要意义

ldquoinherent power

efficiency of siliconldquo

59

低功耗设计问题 功耗问题是近几年来人们在嵌入式系统的设计中普遍关注的难点和热点它严重地制约着嵌入式系统的应用与发展

无论是在军事还是在商业贸易上的应用相当数量的嵌入式系统一般是由电池来供给电能的而且大多数嵌入式设备都有体积和质量的约束减少电能消耗不仅能延长电池的使用寿命延长用户更换电池的周期而且能带来提高系统性能与降低系统开销的好处甚至能起到保护环境的作用在便携式设备中 CPU消耗的电能越少电池的寿命就越长同时散发的热量少了所需的散热器就少了从而可减少该设备的花费和体积使产品尽快进入市场的目标

1 低功耗嵌入式应用系统是指以降低系统功耗为一个主要性能指标的嵌入式系统如计算机里的许多芯片过去用 5V供电现在用 33V 18V 并提出了绿色电器的概念

60

低功耗设备的要求1 )首先要求体积小重量轻便于携带2 )采用低功耗电路的设计方法以降低系统的功耗

它除了选用各种低功耗的器件和芯片外还在满足速度等性能指标的前提下进行降低功耗的硬件电路设计和软件设计

3 )有的系统应用在交流供电比较困难甚至无法用交流供电的场合因而各种电池(瓶)就成为其主要供电手段

4 )采用 LCD液晶显示器5 )采用 RS232C串行通信接口6 )采用微功耗高抗干扰的 CMOS集成电路

功耗产生的原因 P=UI

与功耗有关的因素

( 1 )电阻上消耗的功率( 2 )有源器件的开关转换阶段( 3 )集成电路内部和外部电容的充放电( 4 )系统的性能指标负载能力被处理信号的工作频率电路的工作频率电源的管理水平零部件的性能散热条件接口的物理性能等对系统功耗起着重要的作用

降低功耗的措施

功耗的组成动态 + 静态动态电源管理动态电压缩放低功耗硬件设计低功耗软件设计

二设计方法学概论

问题功 能 性能要求价 格 开发 周 期 等约束

设计 选择 折衷 分析比较 计算 评价

嵌入式系统

0嵌入式系统设计概述

方法 工具

设计方法论( design methodology )

设计方法论有以下三个重要理由1 )确认我们所做的每一件事情都是必须要作的

不会做无谓的白工也不会漏掉关键性的重要工作其中包含效率优化或是功能测试

2 )可以发展出计算机辅助工具或是设计经验累积汲取每一次产品发展的经验再经过量化之后可以发展出一套工具或是方法让往后的产品设计步入自动化

3 )开发团队遵循同一套方法论可以让团队成员更容易彼此沟通每个人都能在短时间内了解整体过程中将经历哪些过程需要何种支持与接收到何种结果此外也容易透过一套已经定义好的方法论彼此相互合作协调

设计目标 1 )上市时间

也就是 time-to-market 的观念2 )设计成本

许多消费性产品对于价格非常敏感所以产品厂商对于成本会斤斤计较是很合理的

3 )品质 顾客也许不需要最快最便宜的产品但是一定会要求功能质量保证不能只用一小段时间就坏掉了

传统的设计主要步骤

2 传统的设计流程方法1 )瀑布模型 (Waterfall)2 )螺旋模型 (Spiral)3 )连续改进 (Successive Refinement)4 )硬件与软件的同步设计 (SWHW Co-

deign)5 )阶层式 (Hierarchical) 设计6 )同步工程( concurrent

engineering )

瀑布模型 (Waterfall)

螺旋模型 (Spiral)

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 53: 大学计算机基础 —— 计算机科学概论

6 )能量攻击Kocher等人 [Koc99]指出测量一个 CPU当前的能量供给能在很大程度上确定处理器的内部活动他们提出了两种能量攻击的方法简单能量分析 (simple power analysis)人工地跟踪检查和尝试确定程序作用的位置比如分支基于不同 CUP操作的能耗知识基于程序作用攻击者然后减少密钥的比特差分能量分析 (Differential power analysis)用相关性确定作用和密钥比特这种攻击最初目标是智能卡这种卡从外部读卡器获取能量但是这种攻击也能应用到许多嵌入式系统中

7 )反攻击 在一些时候有可能构造反破坏的嵌入式系统使电子设备难以发觉和分析延缓了攻击者芯片中有限的信息也有助阻止攻击者发现数据

6 Efficiency (效率)

ES must be efficient

bull Code-size efficient( 特别是片上系统 )

bull Run-time efficient

bull Weight efficient

bull Cost efficient

bull Energy efficient

能量有效性的重要意义

ldquoinherent power

efficiency of siliconldquo

59

低功耗设计问题 功耗问题是近几年来人们在嵌入式系统的设计中普遍关注的难点和热点它严重地制约着嵌入式系统的应用与发展

无论是在军事还是在商业贸易上的应用相当数量的嵌入式系统一般是由电池来供给电能的而且大多数嵌入式设备都有体积和质量的约束减少电能消耗不仅能延长电池的使用寿命延长用户更换电池的周期而且能带来提高系统性能与降低系统开销的好处甚至能起到保护环境的作用在便携式设备中 CPU消耗的电能越少电池的寿命就越长同时散发的热量少了所需的散热器就少了从而可减少该设备的花费和体积使产品尽快进入市场的目标

1 低功耗嵌入式应用系统是指以降低系统功耗为一个主要性能指标的嵌入式系统如计算机里的许多芯片过去用 5V供电现在用 33V 18V 并提出了绿色电器的概念

60

低功耗设备的要求1 )首先要求体积小重量轻便于携带2 )采用低功耗电路的设计方法以降低系统的功耗

它除了选用各种低功耗的器件和芯片外还在满足速度等性能指标的前提下进行降低功耗的硬件电路设计和软件设计

3 )有的系统应用在交流供电比较困难甚至无法用交流供电的场合因而各种电池(瓶)就成为其主要供电手段

4 )采用 LCD液晶显示器5 )采用 RS232C串行通信接口6 )采用微功耗高抗干扰的 CMOS集成电路

功耗产生的原因 P=UI

与功耗有关的因素

( 1 )电阻上消耗的功率( 2 )有源器件的开关转换阶段( 3 )集成电路内部和外部电容的充放电( 4 )系统的性能指标负载能力被处理信号的工作频率电路的工作频率电源的管理水平零部件的性能散热条件接口的物理性能等对系统功耗起着重要的作用

降低功耗的措施

功耗的组成动态 + 静态动态电源管理动态电压缩放低功耗硬件设计低功耗软件设计

二设计方法学概论

问题功 能 性能要求价 格 开发 周 期 等约束

设计 选择 折衷 分析比较 计算 评价

嵌入式系统

0嵌入式系统设计概述

方法 工具

设计方法论( design methodology )

设计方法论有以下三个重要理由1 )确认我们所做的每一件事情都是必须要作的

不会做无谓的白工也不会漏掉关键性的重要工作其中包含效率优化或是功能测试

2 )可以发展出计算机辅助工具或是设计经验累积汲取每一次产品发展的经验再经过量化之后可以发展出一套工具或是方法让往后的产品设计步入自动化

3 )开发团队遵循同一套方法论可以让团队成员更容易彼此沟通每个人都能在短时间内了解整体过程中将经历哪些过程需要何种支持与接收到何种结果此外也容易透过一套已经定义好的方法论彼此相互合作协调

设计目标 1 )上市时间

也就是 time-to-market 的观念2 )设计成本

许多消费性产品对于价格非常敏感所以产品厂商对于成本会斤斤计较是很合理的

3 )品质 顾客也许不需要最快最便宜的产品但是一定会要求功能质量保证不能只用一小段时间就坏掉了

传统的设计主要步骤

2 传统的设计流程方法1 )瀑布模型 (Waterfall)2 )螺旋模型 (Spiral)3 )连续改进 (Successive Refinement)4 )硬件与软件的同步设计 (SWHW Co-

deign)5 )阶层式 (Hierarchical) 设计6 )同步工程( concurrent

engineering )

瀑布模型 (Waterfall)

螺旋模型 (Spiral)

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 54: 大学计算机基础 —— 计算机科学概论

7 )反攻击 在一些时候有可能构造反破坏的嵌入式系统使电子设备难以发觉和分析延缓了攻击者芯片中有限的信息也有助阻止攻击者发现数据

6 Efficiency (效率)

ES must be efficient

bull Code-size efficient( 特别是片上系统 )

bull Run-time efficient

bull Weight efficient

bull Cost efficient

bull Energy efficient

能量有效性的重要意义

ldquoinherent power

efficiency of siliconldquo

59

低功耗设计问题 功耗问题是近几年来人们在嵌入式系统的设计中普遍关注的难点和热点它严重地制约着嵌入式系统的应用与发展

无论是在军事还是在商业贸易上的应用相当数量的嵌入式系统一般是由电池来供给电能的而且大多数嵌入式设备都有体积和质量的约束减少电能消耗不仅能延长电池的使用寿命延长用户更换电池的周期而且能带来提高系统性能与降低系统开销的好处甚至能起到保护环境的作用在便携式设备中 CPU消耗的电能越少电池的寿命就越长同时散发的热量少了所需的散热器就少了从而可减少该设备的花费和体积使产品尽快进入市场的目标

1 低功耗嵌入式应用系统是指以降低系统功耗为一个主要性能指标的嵌入式系统如计算机里的许多芯片过去用 5V供电现在用 33V 18V 并提出了绿色电器的概念

60

低功耗设备的要求1 )首先要求体积小重量轻便于携带2 )采用低功耗电路的设计方法以降低系统的功耗

它除了选用各种低功耗的器件和芯片外还在满足速度等性能指标的前提下进行降低功耗的硬件电路设计和软件设计

3 )有的系统应用在交流供电比较困难甚至无法用交流供电的场合因而各种电池(瓶)就成为其主要供电手段

4 )采用 LCD液晶显示器5 )采用 RS232C串行通信接口6 )采用微功耗高抗干扰的 CMOS集成电路

功耗产生的原因 P=UI

与功耗有关的因素

( 1 )电阻上消耗的功率( 2 )有源器件的开关转换阶段( 3 )集成电路内部和外部电容的充放电( 4 )系统的性能指标负载能力被处理信号的工作频率电路的工作频率电源的管理水平零部件的性能散热条件接口的物理性能等对系统功耗起着重要的作用

降低功耗的措施

功耗的组成动态 + 静态动态电源管理动态电压缩放低功耗硬件设计低功耗软件设计

二设计方法学概论

问题功 能 性能要求价 格 开发 周 期 等约束

设计 选择 折衷 分析比较 计算 评价

嵌入式系统

0嵌入式系统设计概述

方法 工具

设计方法论( design methodology )

设计方法论有以下三个重要理由1 )确认我们所做的每一件事情都是必须要作的

不会做无谓的白工也不会漏掉关键性的重要工作其中包含效率优化或是功能测试

2 )可以发展出计算机辅助工具或是设计经验累积汲取每一次产品发展的经验再经过量化之后可以发展出一套工具或是方法让往后的产品设计步入自动化

3 )开发团队遵循同一套方法论可以让团队成员更容易彼此沟通每个人都能在短时间内了解整体过程中将经历哪些过程需要何种支持与接收到何种结果此外也容易透过一套已经定义好的方法论彼此相互合作协调

设计目标 1 )上市时间

也就是 time-to-market 的观念2 )设计成本

许多消费性产品对于价格非常敏感所以产品厂商对于成本会斤斤计较是很合理的

3 )品质 顾客也许不需要最快最便宜的产品但是一定会要求功能质量保证不能只用一小段时间就坏掉了

传统的设计主要步骤

2 传统的设计流程方法1 )瀑布模型 (Waterfall)2 )螺旋模型 (Spiral)3 )连续改进 (Successive Refinement)4 )硬件与软件的同步设计 (SWHW Co-

deign)5 )阶层式 (Hierarchical) 设计6 )同步工程( concurrent

engineering )

瀑布模型 (Waterfall)

螺旋模型 (Spiral)

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 55: 大学计算机基础 —— 计算机科学概论

6 Efficiency (效率)

ES must be efficient

bull Code-size efficient( 特别是片上系统 )

bull Run-time efficient

bull Weight efficient

bull Cost efficient

bull Energy efficient

能量有效性的重要意义

ldquoinherent power

efficiency of siliconldquo

59

低功耗设计问题 功耗问题是近几年来人们在嵌入式系统的设计中普遍关注的难点和热点它严重地制约着嵌入式系统的应用与发展

无论是在军事还是在商业贸易上的应用相当数量的嵌入式系统一般是由电池来供给电能的而且大多数嵌入式设备都有体积和质量的约束减少电能消耗不仅能延长电池的使用寿命延长用户更换电池的周期而且能带来提高系统性能与降低系统开销的好处甚至能起到保护环境的作用在便携式设备中 CPU消耗的电能越少电池的寿命就越长同时散发的热量少了所需的散热器就少了从而可减少该设备的花费和体积使产品尽快进入市场的目标

1 低功耗嵌入式应用系统是指以降低系统功耗为一个主要性能指标的嵌入式系统如计算机里的许多芯片过去用 5V供电现在用 33V 18V 并提出了绿色电器的概念

60

低功耗设备的要求1 )首先要求体积小重量轻便于携带2 )采用低功耗电路的设计方法以降低系统的功耗

它除了选用各种低功耗的器件和芯片外还在满足速度等性能指标的前提下进行降低功耗的硬件电路设计和软件设计

3 )有的系统应用在交流供电比较困难甚至无法用交流供电的场合因而各种电池(瓶)就成为其主要供电手段

4 )采用 LCD液晶显示器5 )采用 RS232C串行通信接口6 )采用微功耗高抗干扰的 CMOS集成电路

功耗产生的原因 P=UI

与功耗有关的因素

( 1 )电阻上消耗的功率( 2 )有源器件的开关转换阶段( 3 )集成电路内部和外部电容的充放电( 4 )系统的性能指标负载能力被处理信号的工作频率电路的工作频率电源的管理水平零部件的性能散热条件接口的物理性能等对系统功耗起着重要的作用

降低功耗的措施

功耗的组成动态 + 静态动态电源管理动态电压缩放低功耗硬件设计低功耗软件设计

二设计方法学概论

问题功 能 性能要求价 格 开发 周 期 等约束

设计 选择 折衷 分析比较 计算 评价

嵌入式系统

0嵌入式系统设计概述

方法 工具

设计方法论( design methodology )

设计方法论有以下三个重要理由1 )确认我们所做的每一件事情都是必须要作的

不会做无谓的白工也不会漏掉关键性的重要工作其中包含效率优化或是功能测试

2 )可以发展出计算机辅助工具或是设计经验累积汲取每一次产品发展的经验再经过量化之后可以发展出一套工具或是方法让往后的产品设计步入自动化

3 )开发团队遵循同一套方法论可以让团队成员更容易彼此沟通每个人都能在短时间内了解整体过程中将经历哪些过程需要何种支持与接收到何种结果此外也容易透过一套已经定义好的方法论彼此相互合作协调

设计目标 1 )上市时间

也就是 time-to-market 的观念2 )设计成本

许多消费性产品对于价格非常敏感所以产品厂商对于成本会斤斤计较是很合理的

3 )品质 顾客也许不需要最快最便宜的产品但是一定会要求功能质量保证不能只用一小段时间就坏掉了

传统的设计主要步骤

2 传统的设计流程方法1 )瀑布模型 (Waterfall)2 )螺旋模型 (Spiral)3 )连续改进 (Successive Refinement)4 )硬件与软件的同步设计 (SWHW Co-

deign)5 )阶层式 (Hierarchical) 设计6 )同步工程( concurrent

engineering )

瀑布模型 (Waterfall)

螺旋模型 (Spiral)

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 56: 大学计算机基础 —— 计算机科学概论

能量有效性的重要意义

ldquoinherent power

efficiency of siliconldquo

59

低功耗设计问题 功耗问题是近几年来人们在嵌入式系统的设计中普遍关注的难点和热点它严重地制约着嵌入式系统的应用与发展

无论是在军事还是在商业贸易上的应用相当数量的嵌入式系统一般是由电池来供给电能的而且大多数嵌入式设备都有体积和质量的约束减少电能消耗不仅能延长电池的使用寿命延长用户更换电池的周期而且能带来提高系统性能与降低系统开销的好处甚至能起到保护环境的作用在便携式设备中 CPU消耗的电能越少电池的寿命就越长同时散发的热量少了所需的散热器就少了从而可减少该设备的花费和体积使产品尽快进入市场的目标

1 低功耗嵌入式应用系统是指以降低系统功耗为一个主要性能指标的嵌入式系统如计算机里的许多芯片过去用 5V供电现在用 33V 18V 并提出了绿色电器的概念

60

低功耗设备的要求1 )首先要求体积小重量轻便于携带2 )采用低功耗电路的设计方法以降低系统的功耗

它除了选用各种低功耗的器件和芯片外还在满足速度等性能指标的前提下进行降低功耗的硬件电路设计和软件设计

3 )有的系统应用在交流供电比较困难甚至无法用交流供电的场合因而各种电池(瓶)就成为其主要供电手段

4 )采用 LCD液晶显示器5 )采用 RS232C串行通信接口6 )采用微功耗高抗干扰的 CMOS集成电路

功耗产生的原因 P=UI

与功耗有关的因素

( 1 )电阻上消耗的功率( 2 )有源器件的开关转换阶段( 3 )集成电路内部和外部电容的充放电( 4 )系统的性能指标负载能力被处理信号的工作频率电路的工作频率电源的管理水平零部件的性能散热条件接口的物理性能等对系统功耗起着重要的作用

降低功耗的措施

功耗的组成动态 + 静态动态电源管理动态电压缩放低功耗硬件设计低功耗软件设计

二设计方法学概论

问题功 能 性能要求价 格 开发 周 期 等约束

设计 选择 折衷 分析比较 计算 评价

嵌入式系统

0嵌入式系统设计概述

方法 工具

设计方法论( design methodology )

设计方法论有以下三个重要理由1 )确认我们所做的每一件事情都是必须要作的

不会做无谓的白工也不会漏掉关键性的重要工作其中包含效率优化或是功能测试

2 )可以发展出计算机辅助工具或是设计经验累积汲取每一次产品发展的经验再经过量化之后可以发展出一套工具或是方法让往后的产品设计步入自动化

3 )开发团队遵循同一套方法论可以让团队成员更容易彼此沟通每个人都能在短时间内了解整体过程中将经历哪些过程需要何种支持与接收到何种结果此外也容易透过一套已经定义好的方法论彼此相互合作协调

设计目标 1 )上市时间

也就是 time-to-market 的观念2 )设计成本

许多消费性产品对于价格非常敏感所以产品厂商对于成本会斤斤计较是很合理的

3 )品质 顾客也许不需要最快最便宜的产品但是一定会要求功能质量保证不能只用一小段时间就坏掉了

传统的设计主要步骤

2 传统的设计流程方法1 )瀑布模型 (Waterfall)2 )螺旋模型 (Spiral)3 )连续改进 (Successive Refinement)4 )硬件与软件的同步设计 (SWHW Co-

deign)5 )阶层式 (Hierarchical) 设计6 )同步工程( concurrent

engineering )

瀑布模型 (Waterfall)

螺旋模型 (Spiral)

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 57: 大学计算机基础 —— 计算机科学概论

59

低功耗设计问题 功耗问题是近几年来人们在嵌入式系统的设计中普遍关注的难点和热点它严重地制约着嵌入式系统的应用与发展

无论是在军事还是在商业贸易上的应用相当数量的嵌入式系统一般是由电池来供给电能的而且大多数嵌入式设备都有体积和质量的约束减少电能消耗不仅能延长电池的使用寿命延长用户更换电池的周期而且能带来提高系统性能与降低系统开销的好处甚至能起到保护环境的作用在便携式设备中 CPU消耗的电能越少电池的寿命就越长同时散发的热量少了所需的散热器就少了从而可减少该设备的花费和体积使产品尽快进入市场的目标

1 低功耗嵌入式应用系统是指以降低系统功耗为一个主要性能指标的嵌入式系统如计算机里的许多芯片过去用 5V供电现在用 33V 18V 并提出了绿色电器的概念

60

低功耗设备的要求1 )首先要求体积小重量轻便于携带2 )采用低功耗电路的设计方法以降低系统的功耗

它除了选用各种低功耗的器件和芯片外还在满足速度等性能指标的前提下进行降低功耗的硬件电路设计和软件设计

3 )有的系统应用在交流供电比较困难甚至无法用交流供电的场合因而各种电池(瓶)就成为其主要供电手段

4 )采用 LCD液晶显示器5 )采用 RS232C串行通信接口6 )采用微功耗高抗干扰的 CMOS集成电路

功耗产生的原因 P=UI

与功耗有关的因素

( 1 )电阻上消耗的功率( 2 )有源器件的开关转换阶段( 3 )集成电路内部和外部电容的充放电( 4 )系统的性能指标负载能力被处理信号的工作频率电路的工作频率电源的管理水平零部件的性能散热条件接口的物理性能等对系统功耗起着重要的作用

降低功耗的措施

功耗的组成动态 + 静态动态电源管理动态电压缩放低功耗硬件设计低功耗软件设计

二设计方法学概论

问题功 能 性能要求价 格 开发 周 期 等约束

设计 选择 折衷 分析比较 计算 评价

嵌入式系统

0嵌入式系统设计概述

方法 工具

设计方法论( design methodology )

设计方法论有以下三个重要理由1 )确认我们所做的每一件事情都是必须要作的

不会做无谓的白工也不会漏掉关键性的重要工作其中包含效率优化或是功能测试

2 )可以发展出计算机辅助工具或是设计经验累积汲取每一次产品发展的经验再经过量化之后可以发展出一套工具或是方法让往后的产品设计步入自动化

3 )开发团队遵循同一套方法论可以让团队成员更容易彼此沟通每个人都能在短时间内了解整体过程中将经历哪些过程需要何种支持与接收到何种结果此外也容易透过一套已经定义好的方法论彼此相互合作协调

设计目标 1 )上市时间

也就是 time-to-market 的观念2 )设计成本

许多消费性产品对于价格非常敏感所以产品厂商对于成本会斤斤计较是很合理的

3 )品质 顾客也许不需要最快最便宜的产品但是一定会要求功能质量保证不能只用一小段时间就坏掉了

传统的设计主要步骤

2 传统的设计流程方法1 )瀑布模型 (Waterfall)2 )螺旋模型 (Spiral)3 )连续改进 (Successive Refinement)4 )硬件与软件的同步设计 (SWHW Co-

deign)5 )阶层式 (Hierarchical) 设计6 )同步工程( concurrent

engineering )

瀑布模型 (Waterfall)

螺旋模型 (Spiral)

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 58: 大学计算机基础 —— 计算机科学概论

60

低功耗设备的要求1 )首先要求体积小重量轻便于携带2 )采用低功耗电路的设计方法以降低系统的功耗

它除了选用各种低功耗的器件和芯片外还在满足速度等性能指标的前提下进行降低功耗的硬件电路设计和软件设计

3 )有的系统应用在交流供电比较困难甚至无法用交流供电的场合因而各种电池(瓶)就成为其主要供电手段

4 )采用 LCD液晶显示器5 )采用 RS232C串行通信接口6 )采用微功耗高抗干扰的 CMOS集成电路

功耗产生的原因 P=UI

与功耗有关的因素

( 1 )电阻上消耗的功率( 2 )有源器件的开关转换阶段( 3 )集成电路内部和外部电容的充放电( 4 )系统的性能指标负载能力被处理信号的工作频率电路的工作频率电源的管理水平零部件的性能散热条件接口的物理性能等对系统功耗起着重要的作用

降低功耗的措施

功耗的组成动态 + 静态动态电源管理动态电压缩放低功耗硬件设计低功耗软件设计

二设计方法学概论

问题功 能 性能要求价 格 开发 周 期 等约束

设计 选择 折衷 分析比较 计算 评价

嵌入式系统

0嵌入式系统设计概述

方法 工具

设计方法论( design methodology )

设计方法论有以下三个重要理由1 )确认我们所做的每一件事情都是必须要作的

不会做无谓的白工也不会漏掉关键性的重要工作其中包含效率优化或是功能测试

2 )可以发展出计算机辅助工具或是设计经验累积汲取每一次产品发展的经验再经过量化之后可以发展出一套工具或是方法让往后的产品设计步入自动化

3 )开发团队遵循同一套方法论可以让团队成员更容易彼此沟通每个人都能在短时间内了解整体过程中将经历哪些过程需要何种支持与接收到何种结果此外也容易透过一套已经定义好的方法论彼此相互合作协调

设计目标 1 )上市时间

也就是 time-to-market 的观念2 )设计成本

许多消费性产品对于价格非常敏感所以产品厂商对于成本会斤斤计较是很合理的

3 )品质 顾客也许不需要最快最便宜的产品但是一定会要求功能质量保证不能只用一小段时间就坏掉了

传统的设计主要步骤

2 传统的设计流程方法1 )瀑布模型 (Waterfall)2 )螺旋模型 (Spiral)3 )连续改进 (Successive Refinement)4 )硬件与软件的同步设计 (SWHW Co-

deign)5 )阶层式 (Hierarchical) 设计6 )同步工程( concurrent

engineering )

瀑布模型 (Waterfall)

螺旋模型 (Spiral)

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 59: 大学计算机基础 —— 计算机科学概论

功耗产生的原因 P=UI

与功耗有关的因素

( 1 )电阻上消耗的功率( 2 )有源器件的开关转换阶段( 3 )集成电路内部和外部电容的充放电( 4 )系统的性能指标负载能力被处理信号的工作频率电路的工作频率电源的管理水平零部件的性能散热条件接口的物理性能等对系统功耗起着重要的作用

降低功耗的措施

功耗的组成动态 + 静态动态电源管理动态电压缩放低功耗硬件设计低功耗软件设计

二设计方法学概论

问题功 能 性能要求价 格 开发 周 期 等约束

设计 选择 折衷 分析比较 计算 评价

嵌入式系统

0嵌入式系统设计概述

方法 工具

设计方法论( design methodology )

设计方法论有以下三个重要理由1 )确认我们所做的每一件事情都是必须要作的

不会做无谓的白工也不会漏掉关键性的重要工作其中包含效率优化或是功能测试

2 )可以发展出计算机辅助工具或是设计经验累积汲取每一次产品发展的经验再经过量化之后可以发展出一套工具或是方法让往后的产品设计步入自动化

3 )开发团队遵循同一套方法论可以让团队成员更容易彼此沟通每个人都能在短时间内了解整体过程中将经历哪些过程需要何种支持与接收到何种结果此外也容易透过一套已经定义好的方法论彼此相互合作协调

设计目标 1 )上市时间

也就是 time-to-market 的观念2 )设计成本

许多消费性产品对于价格非常敏感所以产品厂商对于成本会斤斤计较是很合理的

3 )品质 顾客也许不需要最快最便宜的产品但是一定会要求功能质量保证不能只用一小段时间就坏掉了

传统的设计主要步骤

2 传统的设计流程方法1 )瀑布模型 (Waterfall)2 )螺旋模型 (Spiral)3 )连续改进 (Successive Refinement)4 )硬件与软件的同步设计 (SWHW Co-

deign)5 )阶层式 (Hierarchical) 设计6 )同步工程( concurrent

engineering )

瀑布模型 (Waterfall)

螺旋模型 (Spiral)

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 60: 大学计算机基础 —— 计算机科学概论

与功耗有关的因素

( 1 )电阻上消耗的功率( 2 )有源器件的开关转换阶段( 3 )集成电路内部和外部电容的充放电( 4 )系统的性能指标负载能力被处理信号的工作频率电路的工作频率电源的管理水平零部件的性能散热条件接口的物理性能等对系统功耗起着重要的作用

降低功耗的措施

功耗的组成动态 + 静态动态电源管理动态电压缩放低功耗硬件设计低功耗软件设计

二设计方法学概论

问题功 能 性能要求价 格 开发 周 期 等约束

设计 选择 折衷 分析比较 计算 评价

嵌入式系统

0嵌入式系统设计概述

方法 工具

设计方法论( design methodology )

设计方法论有以下三个重要理由1 )确认我们所做的每一件事情都是必须要作的

不会做无谓的白工也不会漏掉关键性的重要工作其中包含效率优化或是功能测试

2 )可以发展出计算机辅助工具或是设计经验累积汲取每一次产品发展的经验再经过量化之后可以发展出一套工具或是方法让往后的产品设计步入自动化

3 )开发团队遵循同一套方法论可以让团队成员更容易彼此沟通每个人都能在短时间内了解整体过程中将经历哪些过程需要何种支持与接收到何种结果此外也容易透过一套已经定义好的方法论彼此相互合作协调

设计目标 1 )上市时间

也就是 time-to-market 的观念2 )设计成本

许多消费性产品对于价格非常敏感所以产品厂商对于成本会斤斤计较是很合理的

3 )品质 顾客也许不需要最快最便宜的产品但是一定会要求功能质量保证不能只用一小段时间就坏掉了

传统的设计主要步骤

2 传统的设计流程方法1 )瀑布模型 (Waterfall)2 )螺旋模型 (Spiral)3 )连续改进 (Successive Refinement)4 )硬件与软件的同步设计 (SWHW Co-

deign)5 )阶层式 (Hierarchical) 设计6 )同步工程( concurrent

engineering )

瀑布模型 (Waterfall)

螺旋模型 (Spiral)

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 61: 大学计算机基础 —— 计算机科学概论

降低功耗的措施

功耗的组成动态 + 静态动态电源管理动态电压缩放低功耗硬件设计低功耗软件设计

二设计方法学概论

问题功 能 性能要求价 格 开发 周 期 等约束

设计 选择 折衷 分析比较 计算 评价

嵌入式系统

0嵌入式系统设计概述

方法 工具

设计方法论( design methodology )

设计方法论有以下三个重要理由1 )确认我们所做的每一件事情都是必须要作的

不会做无谓的白工也不会漏掉关键性的重要工作其中包含效率优化或是功能测试

2 )可以发展出计算机辅助工具或是设计经验累积汲取每一次产品发展的经验再经过量化之后可以发展出一套工具或是方法让往后的产品设计步入自动化

3 )开发团队遵循同一套方法论可以让团队成员更容易彼此沟通每个人都能在短时间内了解整体过程中将经历哪些过程需要何种支持与接收到何种结果此外也容易透过一套已经定义好的方法论彼此相互合作协调

设计目标 1 )上市时间

也就是 time-to-market 的观念2 )设计成本

许多消费性产品对于价格非常敏感所以产品厂商对于成本会斤斤计较是很合理的

3 )品质 顾客也许不需要最快最便宜的产品但是一定会要求功能质量保证不能只用一小段时间就坏掉了

传统的设计主要步骤

2 传统的设计流程方法1 )瀑布模型 (Waterfall)2 )螺旋模型 (Spiral)3 )连续改进 (Successive Refinement)4 )硬件与软件的同步设计 (SWHW Co-

deign)5 )阶层式 (Hierarchical) 设计6 )同步工程( concurrent

engineering )

瀑布模型 (Waterfall)

螺旋模型 (Spiral)

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 62: 大学计算机基础 —— 计算机科学概论

二设计方法学概论

问题功 能 性能要求价 格 开发 周 期 等约束

设计 选择 折衷 分析比较 计算 评价

嵌入式系统

0嵌入式系统设计概述

方法 工具

设计方法论( design methodology )

设计方法论有以下三个重要理由1 )确认我们所做的每一件事情都是必须要作的

不会做无谓的白工也不会漏掉关键性的重要工作其中包含效率优化或是功能测试

2 )可以发展出计算机辅助工具或是设计经验累积汲取每一次产品发展的经验再经过量化之后可以发展出一套工具或是方法让往后的产品设计步入自动化

3 )开发团队遵循同一套方法论可以让团队成员更容易彼此沟通每个人都能在短时间内了解整体过程中将经历哪些过程需要何种支持与接收到何种结果此外也容易透过一套已经定义好的方法论彼此相互合作协调

设计目标 1 )上市时间

也就是 time-to-market 的观念2 )设计成本

许多消费性产品对于价格非常敏感所以产品厂商对于成本会斤斤计较是很合理的

3 )品质 顾客也许不需要最快最便宜的产品但是一定会要求功能质量保证不能只用一小段时间就坏掉了

传统的设计主要步骤

2 传统的设计流程方法1 )瀑布模型 (Waterfall)2 )螺旋模型 (Spiral)3 )连续改进 (Successive Refinement)4 )硬件与软件的同步设计 (SWHW Co-

deign)5 )阶层式 (Hierarchical) 设计6 )同步工程( concurrent

engineering )

瀑布模型 (Waterfall)

螺旋模型 (Spiral)

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 63: 大学计算机基础 —— 计算机科学概论

问题功 能 性能要求价 格 开发 周 期 等约束

设计 选择 折衷 分析比较 计算 评价

嵌入式系统

0嵌入式系统设计概述

方法 工具

设计方法论( design methodology )

设计方法论有以下三个重要理由1 )确认我们所做的每一件事情都是必须要作的

不会做无谓的白工也不会漏掉关键性的重要工作其中包含效率优化或是功能测试

2 )可以发展出计算机辅助工具或是设计经验累积汲取每一次产品发展的经验再经过量化之后可以发展出一套工具或是方法让往后的产品设计步入自动化

3 )开发团队遵循同一套方法论可以让团队成员更容易彼此沟通每个人都能在短时间内了解整体过程中将经历哪些过程需要何种支持与接收到何种结果此外也容易透过一套已经定义好的方法论彼此相互合作协调

设计目标 1 )上市时间

也就是 time-to-market 的观念2 )设计成本

许多消费性产品对于价格非常敏感所以产品厂商对于成本会斤斤计较是很合理的

3 )品质 顾客也许不需要最快最便宜的产品但是一定会要求功能质量保证不能只用一小段时间就坏掉了

传统的设计主要步骤

2 传统的设计流程方法1 )瀑布模型 (Waterfall)2 )螺旋模型 (Spiral)3 )连续改进 (Successive Refinement)4 )硬件与软件的同步设计 (SWHW Co-

deign)5 )阶层式 (Hierarchical) 设计6 )同步工程( concurrent

engineering )

瀑布模型 (Waterfall)

螺旋模型 (Spiral)

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 64: 大学计算机基础 —— 计算机科学概论

设计方法论( design methodology )

设计方法论有以下三个重要理由1 )确认我们所做的每一件事情都是必须要作的

不会做无谓的白工也不会漏掉关键性的重要工作其中包含效率优化或是功能测试

2 )可以发展出计算机辅助工具或是设计经验累积汲取每一次产品发展的经验再经过量化之后可以发展出一套工具或是方法让往后的产品设计步入自动化

3 )开发团队遵循同一套方法论可以让团队成员更容易彼此沟通每个人都能在短时间内了解整体过程中将经历哪些过程需要何种支持与接收到何种结果此外也容易透过一套已经定义好的方法论彼此相互合作协调

设计目标 1 )上市时间

也就是 time-to-market 的观念2 )设计成本

许多消费性产品对于价格非常敏感所以产品厂商对于成本会斤斤计较是很合理的

3 )品质 顾客也许不需要最快最便宜的产品但是一定会要求功能质量保证不能只用一小段时间就坏掉了

传统的设计主要步骤

2 传统的设计流程方法1 )瀑布模型 (Waterfall)2 )螺旋模型 (Spiral)3 )连续改进 (Successive Refinement)4 )硬件与软件的同步设计 (SWHW Co-

deign)5 )阶层式 (Hierarchical) 设计6 )同步工程( concurrent

engineering )

瀑布模型 (Waterfall)

螺旋模型 (Spiral)

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 65: 大学计算机基础 —— 计算机科学概论

设计目标 1 )上市时间

也就是 time-to-market 的观念2 )设计成本

许多消费性产品对于价格非常敏感所以产品厂商对于成本会斤斤计较是很合理的

3 )品质 顾客也许不需要最快最便宜的产品但是一定会要求功能质量保证不能只用一小段时间就坏掉了

传统的设计主要步骤

2 传统的设计流程方法1 )瀑布模型 (Waterfall)2 )螺旋模型 (Spiral)3 )连续改进 (Successive Refinement)4 )硬件与软件的同步设计 (SWHW Co-

deign)5 )阶层式 (Hierarchical) 设计6 )同步工程( concurrent

engineering )

瀑布模型 (Waterfall)

螺旋模型 (Spiral)

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 66: 大学计算机基础 —— 计算机科学概论

传统的设计主要步骤

2 传统的设计流程方法1 )瀑布模型 (Waterfall)2 )螺旋模型 (Spiral)3 )连续改进 (Successive Refinement)4 )硬件与软件的同步设计 (SWHW Co-

deign)5 )阶层式 (Hierarchical) 设计6 )同步工程( concurrent

engineering )

瀑布模型 (Waterfall)

螺旋模型 (Spiral)

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 67: 大学计算机基础 —— 计算机科学概论

2 传统的设计流程方法1 )瀑布模型 (Waterfall)2 )螺旋模型 (Spiral)3 )连续改进 (Successive Refinement)4 )硬件与软件的同步设计 (SWHW Co-

deign)5 )阶层式 (Hierarchical) 设计6 )同步工程( concurrent

engineering )

瀑布模型 (Waterfall)

螺旋模型 (Spiral)

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 68: 大学计算机基础 —— 计算机科学概论

瀑布模型 (Waterfall)

螺旋模型 (Spiral)

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 69: 大学计算机基础 —— 计算机科学概论

螺旋模型 (Spiral)

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 70: 大学计算机基础 —— 计算机科学概论

连续改进 (Successive Refinement)

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 71: 大学计算机基础 —— 计算机科学概论

硬件与软件协同 (SWHW Co-deign) 设计流程

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 72: 大学计算机基础 —— 计算机科学概论

分层式 (Hierarchical) 设计流程

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 73: 大学计算机基础 —— 计算机科学概论

同步工程( concurrent engineering )

1 )企图采用一个较广泛的看法让整体流程优化2 )这种方式的目的是要消除每个小型系

统设计者之间的藩篱以免设计者局限在自己的看法而无法与其他设计者进行沟通造成反复或冲突的情况不断发生

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 74: 大学计算机基础 —— 计算机科学概论

3 需求分析与规格 1 )第一阶段

收集客户所描述的讯息整理成需求列表2 )第二阶段

把这些需求进一步萃取之后定成规格( specifications )

这些规格就是系统架构设计的数据

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 75: 大学计算机基础 —— 计算机科学概论

需求的种类1 )功能性需求是指系统必须要有哪些功能2 )非功能性需求则是指其他因素像是大小

价格设计时间等3 )常见的非功能性需求

效能 成本 实体大小与重量 电力消耗

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 76: 大学计算机基础 —— 计算机科学概论

证实需求1 )确认列出来的需求是真的为客户所需要2 )透过仿真系统来证实需求

这个仿真系统将一些事先准备的数据来仿真一些功能当作一个有功能限制的展示系统

说明实际作出来的系统将如何运作可以增进客户与设计者之间的认知

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 77: 大学计算机基础 —— 计算机科学概论

建议需求表格(华为)简介

目的范围

总体概述软件概述软件功能用户特征假设和依赖关系

需求建模建模工具

具体需求功能需求性能需求外部接口需求

总体设计约束标准符合性硬件约束技术限制

软件质量属性可维护性可靠性helliphellip

依赖关系其他需求需求分级附录

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 78: 大学计算机基础 —— 计算机科学概论

好的需求文件 1 )正确性一个需求描述不可以误解顾客所需也不该过份描

述不需要的需求2 )精准性需求文件应该做清楚的描述而不是笼统的说明3 )完整性所有的需求都应该纪录4 )可证明性所有的需求都应该有方式去证明这项需求是合理

的像是文件里就不应该出现「亲和的接口」这类字眼因为无法定义什么叫做亲和的接口

5 )一致性某项需求不应该和其他需求相互冲突6 )可修改性既然可以建立需求当然也可以修改需求而且

不会违反上述的特性7 )可追踪性每份文件都应该可以追踪包括为什么会有这样

的需求开出来彼此需求间的相关性这些需求是否可能实现以及最后是否满足这些需求

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 79: 大学计算机基础 —— 计算机科学概论

什么是好的需求(华为)

什么样的需求是好的需求

完整性

清晰性

可行性一致性

可验证性

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 80: 大学计算机基础 —— 计算机科学概论

規格 1 )规格比需求更精确许多这是当作客户与架构设计团队之间的契约所以在撰写时需更加小心才能够正确的反应客户的需求并且在接下来的设计期间了解每一步设计过程2 )规格一定要让人一目了然符合系统的需求也能让客户很清楚的了解他会得到什么样的产品设计者常常会因为不清楚规格而产生一些问题例如误解规格里某些功能结果做出错误的功能或是规格里某些地方不完整导致最后忽略了许多必要的功能

3 )透过规格制订语言使大家清楚规格描述

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 81: 大学计算机基础 —— 计算机科学概论

规格与架构描述方法1 )统一建模语言 (Unified Modeling

Language)2 ) SDL 语言 ( Specification

Description language)3 )ORAND 状态图 表 (State-based

DiagramTable)4 )方块图( block diagram )

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 82: 大学计算机基础 —— 计算机科学概论

统一建模语言 (Unified Modeling Language)

1 )UML 是一种描述规格的语言藉由这套语言的表达达到系统正规化的表述使所有看过规格的人都了解所描述的产品是什么2 )一种面向对象( object-oriented )的

建模语言 鼓励将设计分成好几个互动对象的方式取代单

一方块的设计 这些对象可以代表真实世界的软件与硬件利用

UML 的方式来对应到使用者与外部其他机器

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 83: 大学计算机基础 —— 计算机科学概论

SDL ( Specification Description language) 语言为了通讯工业所设计的包含了状态动作和每个状态之间的转换条件

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 84: 大学计算机基础 —— 计算机科学概论

OR 状态图 (State-based Diagram)

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 85: 大学计算机基础 —— 计算机科学概论

AND 状态图

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 86: 大学计算机基础 —— 计算机科学概论

ANDOR 表

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 87: 大学计算机基础 —— 计算机科学概论

方块图( block diagram )1 )显示这个系统有哪些主要组件这个方块图还是非常抽象没办法

使用这些方块来直接实作不过这些方块可以告诉我们接下来的工作方向为何

2 )我们可以依据这里所描述的工作项目分工并进做出进一步的功能

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 88: 大学计算机基础 —— 计算机科学概论

硬件方块图

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 89: 大学计算机基础 —— 计算机科学概论

软件方块图

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 90: 大学计算机基础 —— 计算机科学概论

4 整合设计及测试问题

1 )硬件与软件组件设计2 )系统整合3 )质量保证技术4 )除错成本5 )衡量驱动质量保证

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 91: 大学计算机基础 —— 计算机科学概论

设计硬件与软件组件1 )组件设计就是遵照架构与规格来建立系统2 )一般包含了硬件模块例如

FPGA( field-programmable gate arrays )设计电路板等以及软件模块部分

3 )采用了标准组件可以加快开发速度4 )设计者仍必须设计一些属于自己的组件

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 92: 大学计算机基础 —— 计算机科学概论

系统整合1 )把所有设计好的组件放在一起2 )通常我们会在系统整合阶段找到很多臭虫3 )避免冗长的除错策略

有好的规划 足够的测试案例 先将几个模块放在一起确认臭虫是否存在 是否可以将这些组件功能的关系互相独立以方便确认

4 )至今系统整合还是一项困难的挑战

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 93: 大学计算机基础 —— 计算机科学概论

5 质量保证技术 1 )质量保证( quality assuranceQA )的过程是维持一个高质量产品必须的过程

2 )质量保证技术 ISO

国际标准化组织( The International Standards Organization ISO )建立了一套「 ISO 9000 质量标准」

CMM 卡内基美隆大学( Carnegie Mellon University CMU )的软

件工程师协会所发展的「能力成熟模型( Capability Maturity Model CMM ) 」

并且推出整合式能力成熟度模式 CMMI( Capability Maturity Model Integration )评鉴制度

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 94: 大学计算机基础 —— 计算机科学概论

范例 火星探测船的失事原因1999年美国所发射的一台火星探测船在

接近火星的时候失事原因是登陆火星的引擎在点燃时已经与火星距离太近最后的调查报告出来其中一个很重要的原因是美国喷射推进实验室( Jet Propulsion

Laboratory JPL )与合作厂商Lockheed Martin公司两个单位工程师ldquo所使用的计算单位不一样rdquo

JPL 用的是牛顿( newton )而另外一家却是用磅来当作计算单位可是双方却都以为对方和自己用的是一样的单位导致计算出来的结果与真正的轨道差距 445倍

也因为这个原因使得这艘火星探测船并没有在正确的时间点燃引擎而失事

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 95: 大学计算机基础 —— 计算机科学概论

ISO 9000质量管理系统的国际标准ISO 9000公布有三套评鉴标准

ISO 9001适用于组织具有设计开发生产安装及服务

ISO 9002 可用于没有设计活动的组织亦即依据既存设计去生产或提供服务而不包括设计功能者

ISO 9003适用于制造简单产品的组织其产品的质量可藉最终检验与测试来确保而无需在制造阶段实施任何特定的质量管理

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 96: 大学计算机基础 —— 计算机科学概论

ISO 9000 的品質保證1 )质量保证的基本哲学就是提升所谓预防的文化而使问题

可被预期进而在其恶化前就加以截阻2 )拥有一套工作的方法使其能确保在各阶段中作业的有效管

制与不符合事项的消除 程序是重要的杂乱的开发程序只会做出杂乱的产品质

量必然不佳所以了解每个程序步骤才能够做出高质量的产品

文件是重要的文件扮演几个角色文件的建立可以帮助了解程序文件也同时帮助内部品管小组确保开出来的需求确实是被执行的而且也帮助外面的人例如顾客或是稽核员了解程序以及程序如何被实现

沟通是重要的质量最后还是依赖在人的身上好的文件确实能够帮助人们了解整个质量程序不过还是需要组织内的所有人不只是了解自己本身所指派的工作也需要了解自己的工作对于整个系统所可能产生的影响

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 97: 大学计算机基础 —— 计算机科学概论

CMM CMM适用软件工程系统工程集成产品发展及采购等软件工业之工作领域

初始( initial )阶段这是最差的组织程序只有少量定义完备的程序项目的成功依赖的是个人的努力而不是组织的力量

可重复的( repeatable )阶段这个层级具有基本的追踪机制可供管理成本计划进度并且可以让系统发展符合预期目标

已定义( defined )阶段所有管理与工程进行的过程都已经利用文件记录并且标准化所有的项目也都使用文件建置且符合标准方式

已管制( managed )阶段这个程度可以透过仔细衡量达成发展程序与产品质量的保证

优化( optimizing )阶段在最高级阶段里可以透过仔细的衡量取得改进建议并且不断持续改善组织内的程序

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 98: 大学计算机基础 —— 计算机科学概论

除错成本

存在越久的臭虫修正成本越高

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 99: 大学计算机基础 —— 计算机科学概论

设计重审( Design Review)

1 )通常是设计成员开一个会 重新审视系统设计的每一个组件

2 )越早找出臭虫 不要让有问题的设计进入实作阶段越能节省许

多成本以及工作时间3 )在重新设计之后

可能会和其他组件有新的接口这时候就必须要重新召开重审会议

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 100: 大学计算机基础 —— 计算机科学概论

衡量驱动质量保证 1 )衡量驱动质量保证( measurement-driven quality

assurance )方法论 利用衡量的方式找出臭虫比率就可以藉这些统计数据来帮助我们控

制质量 而且有了这些统计数据不只可以决定最后系统进行测试所需要的大

约数量也可以在往后产品开发的时候作为参考了解大概会有那些臭虫出现

日立公司( Hitachi )的软件质量评估( Software Quality Evaluation SQE )系统

2 )衡量驱动质量保证方式 并不能帮助减少臭虫 用意在于持续改进设计过程当我们不能够做出完美系统至少要知道从哪些方面来进行改善

3 )采用衡量设计过程的方式并且用这些结果来找出我们将来在其他项目应该要注意的地方

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 101: 大学计算机基础 —— 计算机科学概论

小结采用方法论的方式将会提升设计过程的质量

从需求分析规格分析架构设计到软件与硬件的实现系统整合以及最后我们如何进行质量保证

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 102: 大学计算机基础 —— 计算机科学概论

三高性能嵌入式系统设计方法

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 103: 大学计算机基础 —— 计算机科学概论

1 设计的目标

1 )需求分析 具体的目标和确定它们的可行性 功能需求 (functional requirements) 非功能需求 (nonfunctional requirements) 其他相对不可测的目标2 )性能评价 如平均性能对比最差情况或者最好情况 吞吐量对比延迟 峰值对比稳定 能量 (Energy)和 或者功耗 (power consumption) 生产成本 设计成本 使用期成本 (Lifetime cost) 设计一个系统的时间 可靠性的要求 质量的定义和测量

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 104: 大学计算机基础 —— 计算机科学概论

需求工程的问题十分严重 复杂问题的需求 说不清楚 无法理解需求模糊二

义性 问题的边界变化 用户需求发生变化

传统软件工程方法 软件维护版本更新打补钉

软件二次开发重构重用bull 问题时间长成本高 所要时间长 成本更高 无法及时满足用户应用的要

求 网络时代问题更加严重 bull 结果软件难产失败

失效过时废弃

ldquo没有编不出的软件只有说不清楚的需求rdquo

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 105: 大学计算机基础 —— 计算机科学概论

2 设计方法学1 )设计空间很大而且不规则在设计过程中许多重要步骤我们

没有合适的综合工具这样设计者必须在许多设计阶段依赖分析和模拟

2 )我们不能很细微地模拟任何事情模拟不仅仅花费时间为运行大规模的模拟所需的服务器群成本也是整个设计成本中重要的成分特别是当需要大量数据来验证大型应用我们不能对整个设计进行周期精确的模拟

3 )我们需要能够快速开发模拟器模拟器必须反应具体应用设计的结构系统构架师需要工具来帮助他们构造具体应用的模拟器

4 )片上系统的软件开发者在硬件完成以前需要能够评估软件他们不仅需要评估功能还包括性能和功率

5 )复杂性设计复杂性基本上通过莫尔定律估计莫尔定律预测每个芯片上的晶体管数目每年增加 58 Sematech估计设计者生产力过去和以后每年都只增加 21

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 106: 大学计算机基础 —— 计算机科学概论

3 硬件的设计一个简化的硬件设计流程图应用于许多 VLSI设计

单元库

技术数据库

独立技术的逻辑合成

状态分配最小化等等

依靠技术的逻辑合成

位置和路线

布局

寄存器传送规范

路线模型

时间分析

配线模型

时间分析

时间分析

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 107: 大学计算机基础 —— 计算机科学概论

一般的协同设计方法学 给定一个执行的规范大部分方法学运行一些初始的系统分析来决定并行时机和可能把规范分为过程软 硬件划分选择一种体系结构一些操作被硬件直接执行其他操作被运行在可编程平台上的软件执行软 硬件划分产生可被分开实现的模块设计这些模块然后被联合被测试性能和功耗和被调试来生成最终的系统

软硬件划分

系统分析

整合和调试

布局

规范

体系结构

软件实现

硬件实现

硬件模块

软件模块

布局布局

性能功率分析

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 108: 大学计算机基础 —— 计算机科学概论

4 基于平台的设计方法学基于平台的设计 (PBD) 方法由 A Ferrari 与 A Sangiovanni Vincentelli 于 1999 年首次提出后来又经过详细定义与发展 [3] VSI 联盟为 PBD 给出了较权威的定义 [4]

基于平台的设计是一种面向集成强调系统级重用的设计方法此方法在平台的基础上开发复杂的产品目标是降低开发风险代价与上市时间 该方法在无线通信汽车电子与多媒体应用中获得了较大的成功例如 TI公司推出的 TI OMAP 为无线视频流应用进行了优化 Philips公司的 Nexperia 则适合多媒体应用与发

平台是关于虚部件与某个体系结构框架的库在这个体系结构框架中包含一些集成的并且预先验证的软件 IP与硬件 IP块模型 EDA与软件工具库以及通过体系结构探索集成和验证来支持快速产品开发的方法学

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 109: 大学计算机基础 —— 计算机科学概论

三个主要特性l )平台设计有很强的可配置性但是却不能改变如果设计

中包含一个不用的模块可以通过设置使这个模块不工作而不是将它从设计中拿走改变一个设计需要的费用比起在非必需逻辑门总数目方面接受很少的一笔费用来成本要高的多

2 )平台设计使用的是标准的 SoC接口这样就使得采用相同标准接口的辅助 IP模块的集成变得很简单了很多硬件设计者都知道实际总线接口(如 AMBA或 OCP)正在被越来越多地使用到很多不同的 IP中依赖于硬件的软件接口标准依然会出现

3 ) 现在平台设计越来越多地将专用模块集成到设计中可以特别优化设计以实现该项功能设计者会评估他们的特殊要求然后选择那些能最大限度满足他们要求的ldquo内核rdquo平台

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 110: 大学计算机基础 —— 计算机科学概论

平台划分在很多文献中分为硬件平台软件平台和系统平台其中硬件平台是支持软件重用的微体系结构系列软件平台通过 API 使用硬件平台的资源硬件平台与软件平台共同组成系统平台在软件平台中实时操作系统 (RTOS) 封装了可编程 IP 核与存储子系统 设备驱动程序封装了 IO子系统网络通信子系统封装了网络连接

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 111: 大学计算机基础 —— 计算机科学概论

基于平台的设计是采用片上系统的通用方法平台允许几个用户用相同的基本平台定制不同的产品平台在基于标准的市场中特别有用一些基本的特性必须被支持其他的特性必须被定制用于区分产品 如图 1-16所示基于平台的设计是一个两阶段的过程首先平台必须基于整个系统需求(比如标准)和如何可定制来设计一旦平台被设计它就能用来设计一个产品产品利用平台的特性和添加它自己的特性

布局 布局

产品

平台

平台利用

平台设计

布局

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 112: 大学计算机基础 —— 计算机科学概论

平台设计需要的几个设计阶段 a )剖析和分析将系统需求和软件模型转变为更具体的平台硬件体系结构需求b )设计空间开发评估硬件方案c )体系结构模拟帮助评价和优化体系结构的细节d )基本软件mdashmdash硬件抽象层操作系统端口通信应用库

e )调试mdashmdash必须为平台开发

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 113: 大学计算机基础 —— 计算机科学概论

平台使用的挑战性 由于平台需要一种自定义编程环境程序员习惯于标准平台丰富的开发环境这些环境提供大量的工具mdashmdash编译器编辑器调试器仿真器mdashmdash以一种单一图形用户接口但是丰富的编程环境一般用于单一处理器多处理器更难编程而且异构多处理器比同构多处理器更难编程平台开发者必须提供让软件开发者使用平台的工具一些这样的工具来自组件 CPU但是其他工具必须临时开发调试特别重要而且困难因为调试访问是由硬件决定的进程间通信也是具有挑战性的而且对应用开发者来说是一个关键的工具

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 114: 大学计算机基础 —— 计算机科学概论

5 基于标准的设计方法学1 )标准问题( pros and cons of standards) 许多高性能的嵌入式计算系统实现标准多媒体通信和网络 都

为各种应用提供标准一个产品甚至实现几个不同的标准 一方面标准支持产品而且特别是片上系统标准为特殊功能创造

了广大的市场它们允许设备互操作和让客户确信设备提供了所需的功能

另一方面标准存在的事实意味着芯片设计者不必考虑他们设计的规范标准定义了所需的复杂行为结果是体系结构的一些特性将被标准规定

大部分标准支持改进许多标准定义了一些必须被执行的操作但是它们没有具体陈述这些操作如何执行实现者可以基于性能功率成本质量或者实现的方便选择一种方法

标准通常是复杂的而且给定领域的标准随着时间的推移会变得更复杂

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 115: 大学计算机基础 —— 计算机科学概论

2 )参考实现 (reference

implementation) 标准体系通常提供一种参考实现 (reference

implementation) 这是一种遵循标准的执行程序它通常用 C 编写但是也可能

用 Java或者其他语言参考实现开始用来辅助标准开发者它然后分发给规范的研发人员(参考实现可能是免费获得的但是在许多情况下为了构造一个遵守规范的系统研发人员必须付一定的许可费给标准体系许可费主要是给专利持有者这些人的发明被标准所采用)如果多个组织实验标准并且每个组织都发布结果可能会有几种参考实现

参考实现在一定程度上对系统设计者好坏参半 一方面参考实现为设计者节省了大量时间另一方面它伴随

着一些责任当然学会一些人的代码通常是耗时的而且代码一般不能原方不动地利用参考实现通常被编写运行在很大的存储有限的工作站它们一般不是实时操作代码必须在许多方面被调整去除不会执行的特性用自定义存储管理替换堆栈分配和改进高速缓冲存储器利用函数内联和许多其他任务

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 116: 大学计算机基础 —— 计算机科学概论

3 )设计任务 实现的非具体部分必须设计 标准没有指定的系统部分(比如用户接口)必须设计 一次平台独立的初始优化必须用来提高选择的参考实

现 参考实现和其他代码必须被剖析和分析 硬件平台必须基于初始特征设计 为更好地匹配平台系统软件必须进一步优化 平台本身必须基于深度剖析进一步优化 为了遵循标准和性能和能耗之类的非函数参数平台

和软件必须被验证例子高性能视频编码标准 mdashmdash AVCH264

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 117: 大学计算机基础 —— 计算机科学概论

6 基于组件的设计方法( IP-Based Embedded System Design )

组件原本是一个软件工程中的概念嵌入式的设计也受益于组件的思想组件方法的目标是单独开发和组件集成组件通过接口和外界交互当组件改变时用户也不需要知道它是如何改变而只需要了解新接口的用法就可以了基于组件的嵌入式系统设计方法提出将系统分解为一些组件这些组件封装了一些特定的功能如计算或通信并且定义了良好的接口和外界进行交互我们期望组件方法的设计优势如组件重用快速原型可配置和修改以及组件分配能在嵌入式系统设计得到体现并且这样的设计方法有利于将复杂的嵌入式系统设计问题分解为各个子问题再逐个解决降低了设计难度保证了设计正确性加快了嵌入式产品进入市场的时间

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 118: 大学计算机基础 —— 计算机科学概论

基于组件的设计 通过组装异构组件构建节约成本的复杂系统我们需要相应的理论模型和工具的支持利用构件组装的众多优点比如生产力和正确性来构建复杂的系统组件的组装需要精心策划部件的交互这是并行计算的核心

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 119: 大学计算机基础 —— 计算机科学概论

组件的设计问题 1mdashmdash异构性(静态) 系统设计者处理大量的组件它们具有不同的特性不同角度和系统不同的维度导致异构性原因在于使用了语义无关的形式例如为了程序硬件描述和模拟语言破坏了设计流的一致性以及它们的相关性还有系统开发是与验证和评价解耦的组件的异构性分为执行的异步性和交互的异构性

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 120: 大学计算机基础 —— 计算机科学概论

组件的设计问题 3mdashmdash 交互的异构性(通信)

a) 会合 b)广播

语义模型应使能各种自然的和直接的机制以协调各种执行组件如信号灯广播方法调用等两个基本协议会合和广播

会合是指原子对称同步广播是指由发生者引发的不对称同步尽管任何交互机制都可以表示为有层次结构的会合和广播的组合但是存在的形式体系和理论都不足以表达各种低层协调机制(包括信号监控器信息传递函数调用) 通常使用会合或者广播进行点对点的交互关系

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 121: 大学计算机基础 —— 计算机科学概论

组件的设计问题 4mdashmdash粘合(概念) 粘合(见图)是指构建一个满足给定性能 P的组件 C

C0 是一组由自己行为描述的原子组件集合 GL 是一组由组件粘合操作组成的集合 GL=gl1 hellip gli hellip 粘合操作是指协调机制比如协议调度总线 我们需要一个统一的组合范例来描述分析各组件之间的协调

粘合的概念图

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 122: 大学计算机基础 —— 计算机科学概论

组件的设计问题 5mdashmdash粘合(规则要求)

由正确的组件建立正确的系统的规则

我们需要组合结果去保留进度属性比如死锁 -自由和活性以及额外的功能属性

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 123: 大学计算机基础 —— 计算机科学概论

组件的设计问题 6mdashmdash粘合(属性保持鲁棒性)

当组件整合的时候保留基本属性

性能稳定现象尚不清楚 我们需要可组合结果例如非相互作用的特点在中间件调度算法的可组合性 web服务的方面

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 124: 大学计算机基础 —— 计算机科学概论

典型系统mdashmdash eBlocks Embedded Systems Building Blocks ( httpwwwcsucredu~ eblock)

The goal of the eBlocks project is to empower regular people having no programming or electronics experience to build basic useful electronic systems around the home office store etc To achieve this goal we are creating a set of embedded system building blocks - eBlocks - that are easily connect together to build a huge variety of basic but useful monitorcontroller systems The key to our approach is to add compute intelligence to components that previously had none - to sensors switches light-emitting diodes (LEDs) speakers etc Adding compute intelligence to those items was previously cost and power prohibitive but extremely small cheap and low power processing devices now make such addition possible Ideally people could simply connect such eBlocks together to build basic systems

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 125: 大学计算机基础 —— 计算机科学概论

基于模型的设计

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 126: 大学计算机基础 —— 计算机科学概论

基于模型的嵌入式系统开发一般过程

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 127: 大学计算机基础 —— 计算机科学概论

需求

设计说明

体系结构

构件设计

系统集成

方法的比较

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129
Page 128: 大学计算机基础 —— 计算机科学概论

基于模型的设计实例

左图显示了基于模型的设计的各个组成部分该设计方法的中心是模型 它的四个主要组成部分分别是 1048697 可执行的规范 1048697 设计仿真 1048697 代码生成 1048697 连续的测试和验证

  • Slide 2
  • Slide 4
  • Slide 5
  • Slide 10
  • Slide 11
  • Slide 12
  • Slide 13
  • Slide 14
  • Slide 15
  • Slide 16
  • Slide 17
  • Slide 19
  • Slide 22
  • Slide 23
  • Slide 24
  • Slide 25
  • Slide 26
  • Slide 30
  • Slide 33
  • Slide 38
  • Slide 39
  • Slide 40
  • Slide 41
  • Slide 44
  • Slide 45
  • Slide 46
  • Slide 47
  • Slide 48
  • Slide 49
  • Slide 51
  • Slide 57
  • Slide 58
  • Slide 59
  • Slide 60
  • Slide 61
  • Slide 62
  • Slide 63
  • Slide 66
  • Slide 67
  • Slide 68
  • Slide 69
  • Slide 70
  • Slide 71
  • Slide 72
  • Slide 73
  • Slide 74
  • Slide 75
  • Slide 76
  • Slide 77
  • Slide 78
  • Slide 79
  • Slide 80
  • Slide 81
  • Slide 82
  • Slide 83
  • Slide 84
  • Slide 85
  • Slide 86
  • Slide 87
  • Slide 88
  • Slide 89
  • Slide 90
  • Slide 91
  • Slide 92
  • Slide 93
  • Slide 94
  • Slide 95
  • Slide 96
  • Slide 97
  • Slide 98
  • Slide 99
  • Slide 100
  • Slide 101
  • Slide 102
  • Slide 103
  • Slide 106
  • Slide 108
  • Slide 109
  • Slide 110
  • Slide 111
  • Slide 112
  • Slide 113
  • Slide 114
  • Slide 115
  • Slide 117
  • Slide 118
  • Slide 128
  • Slide 129