1.3k likes | 1.44k Views
大学计算机基础 —— 计算机科学概论. 设计的挑战. 嵌入式与网络计算实验室. 本讲义多有引用他人工作, 在此一并致谢!. 一、嵌入式系统的一些基本特征. cyber-physical systems. 1 、一类嵌入式系统硬件是一个闭环系统. 硬件体系结构 CPUs ,协同设计,多处理器,网络 软件体系结构 处理,调度,分配. 体系结构. 建模分析和仿真 性能,功率,成本 协同验证. 应用. 特点 规范 参考设计. 方法学. 2 、嵌入式系统中计算的基本问题. 问题 1 —— 体系结构 (architectures). 硬件体系结构
E N D
大学计算机基础 ——计算机科学概论
设计的挑战 嵌入式与网络计算实验室 本讲义多有引用他人工作, 在此一并致谢!
cyber-physical systems • 1、一类嵌入式系统硬件是一个闭环系统
硬件体系结构 • CPUs,协同设计,多处理器,网络 • 软件体系结构 • 处理,调度,分配 体系结构 • 建模分析和仿真 • 性能,功率,成本 • 协同验证 应用 特点 规范 参考设计 方法学 2、嵌入式系统中计算的基本问题
问题1——体系结构(architectures) 硬件体系结构 CPUs,协同设计,多处理器,网络 软件体系结构 处理,调度,分配 中间件 人机交互 硬件、软件及其二者之间的关系
问题2——方法学(methodologies) 建模分析,形式化 仿真 性能 功率,能耗 成本,价格 协同验证 方法学中的步骤靠工具来执行
问题3——应用(applications) 特点:规范、参考设计: 理解你的应用是获得嵌入式计算系统最大性能的关键。我们可以根据应用的特点去优化设计。这个优势可以使我们执行许多有效的优化,而这在通用系统中是不可能的。但是这也意味着我们必须对应用的特点有足够的认识,这样才能在利用特点的同时避免在系统实现过程中产生问题。 面向应用的计算( SmartApps: An Application Centric Approach to High Performance Computing)
Application Compiler OS HW Today: System Centric Computing Application (Algorithm) System-Centric Computing Classic Avenues to performance: • Parallel Algorithms • Static Compiler Optimization • OS support • Good Architecture What’s missing? • Compiler are conservative • OS offers generic services • Architecture is generic Development ent, Analysis & Optimization Compiler (static) Execution System (OS & Arch) Input Data No Global Optimization • No matching between Application/OS/HW • Intractable for the general case
HW OS Compiler Application SmartApp Compiler (run-time) OS (modular) Architecture (reconfigurable) SmartApps: Application Centric Computing Application (Algorithm) Application Control Instance-specific optimization Compiler + OS + Architecture + Data + Feedback Application-Centric Computing Development ent, Analysis & Optimization Compiler (static) + run-time techniques Run-time System: Execution, Analysis & Optimization Input Data
Static Compiler Augmented with runtime techniques Predictor & Optimizer partially compiled code with unknowns and runtime hooks Information for rapid simulation Compute Optimal Application and System Configuration Recompile Application and/or Reconfigure System Predictor & Evaluator Configurer Execute Application Continuous monitor performance and adapt as necessary Predictor & Evaluator Predictor & Optimizer Application SmartApps Architecture Smart Application Get Runtime Information (sample input, system information, etc.) Large adaptation (failure, phase change) Adaptive Software Runtime tuning (w/o recompile or reconfigure) Small adaptation (tuning)
3、Real-time 约束 许多ES必须满足实时约束 什么是实时系统 实时系统是将时间定量化的一个概念,实时系统是使用物理时钟来衡量的,当我们使用物理时钟来量化时间时,我们就会讨论到实时的概念。 与实时相反,逻辑时间(也称为虚拟时间)是对时间的一种定性的概念,通过使用事件顺序关系来表示,例如之前,之后,某个时候,最后,在…之前,接着,等等。 定义:一个系统称为实时系统,当我们需要用定量的时间表达式(也就是说实时)来描述这个系统的行为。在这个实时系统的定义中,隐含的表达了所有的定量的时间度量都是用一个物理时钟测量得到的。 任何一个行为可以完全不用任何定量时间表达来描述其行为的系统肯定不是实时系统。但一个系统的完整行为可以用它对各种外部刺激的响应列表来描述,也就是说,一个系统的行为大部分描述根本没有定量的时间表达式,仍然被认为是一个实时系统。
实时系统的类型 • 根据任务超过截止时间的后果,实时系统可以分为: • 硬实时、软实时、固实时。 • 1)硬实时:当系统执行任务时,被强制要求在某个时间范围内要产生结果,换句话说,任何时刻硬实时任务没有在制定的时间范围内产生要求的结果,那这个系统就被认为失败了。 • 2)固实时:当系统执行任务时,与某些预设的截止时间相关联,任务要求要在截止时间之前完成结果的计算。不同于硬实时任务,就算一个固实时任务没有在截止时间之前完成,系统也不会失败。迟来的结果仅仅是被丢弃了。 • 3)软实时:当系统执行任务时,也有与之相关联的时间界限。但是,不像硬实时和固实时任务,软实时任务的时间界限并不是以绝对数值来表示的。取而代之的是平均响应时间。
Real-Time 系统与嵌入式系统 • Embedded and Real-Time 往往同义: • Most embedded systems are real-time • Most real-time systems are embedded embedded embedded real-time real-time
4、反应系统 ES 是一个反应系统: 转换系统:输入(开始)->软件系统(经过一段时间后停止运行)->(然后)输出。即用户把数据输入给计算机,软件对这些数据经过一段时间的计算,最后给出输出结果。 输入数据经过特定的规则被转换,并且在结束计算过程以后给出结果。 而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)嵌入式计算机容易受许多新类型攻击。可靠计算机传统上是物理上不可访问的服务器或者机器——物理安全长期以来是计算机安全的安全策略。但是,嵌入式计算机通常在非保护环境下操作。这就允许新的故障和攻击,这些需要都新的保护措施。
2、可靠与可信 • ES必需是可靠的、可信的 • 如何评价与度量: • 可靠性(Reliability)R(t) • 可维护性(Maintainability)M(d) • 有效性(Availability )A(t) • 安全性(Safety) • 保密性( Security)
可靠性定义 • 可靠性R(t) : 产品在规定条件下和规定时间内,完成规定功能的能力。 产品可靠性定义的要素是三个“规定” 。 1)“规定条件”包括使用时的环境条件和工作条件。 2)“规定时间”是指产品规定了的任务时间。 3)“规定功能”是指产品规定了的必须具备的功能及其技术指标。
1)“规定条件”包括使用时的环境条件和工作条件;1)“规定条件”包括使用时的环境条件和工作条件; • 例如同一型号的汽车在高速公路和在崎岖的山路上行驶,其可靠性的表现就不大一样,要谈论产品的可靠性必须指明规定的条件是什么。 • 2)“规定时间”是指产品规定了的任务时间; • 随着产品任务时间的增加,产品出现故障的概率将增加,而产品的可靠性将是下降的。因此,谈论产品的可靠性离不开规定的任务时间。例如,一辆汽车在在刚刚开出厂子,和用了5年后相比,它出故障的概率显然大了很多。 • 3)“规定功能”是指产品规定了的必须具备的功能及其技术指标所要求产品功能的多少和其技术指标的高低,直接影响到产品可靠性指标的高低。 • 例如,电风扇的主要功能有转叶,摇头,定时,那么规定的功能是三者都要,还是仅需要转叶能转能够吹风,所得出的可靠性指标是大不一样的。
可维护性M(d) • 1)计算机系统的可维护性是指该系统失效后在规定时间内可修复到规定功能的能力, • 2)反映系统可维护性高低的参数是修复率秒平均修复时间 • 3)软件可维护性即维护人员对该软件进行维护的难易程度,具体包括理解、改正、改动和改进该软件的难易程度。 • 4)决定可维护性的因素:系统的大小系统的年龄结构合理性 • 5)可维护性的度量:可理解性可测试性可修改性可移植性
有效性A(t): • 设备的有效性的表式为: • 设备有效性=平均故障间隔期/(平均故障间隔期+平均修理时间) • 在逻辑中,如果一个论证不能从真前提中得出假结论,则论证的形式是完全有效的。 • 一个论证若被称为是有效的,则如果在其中所有前提都为真的每个模型中,结论也是真的。 • 例如:“所有A是B;有些A是C;所以有些B是C”是有效形式。 • 可用性, 实用性
3、可靠系统设计的基本原理 1)故障(faults)分析 2)可靠性分析 3)纠错技术 4)软件可靠性
1)故障(faults)分析 永久(permanent) 与暂时(transient)故障 故障来源: • 物理故障(Physical faults)由生产缺陷,辐射危害,等等引起。 • 设计故障(Design faults)是不合适设计的系统的结果。 • 操作故障(Operational faults)来自人为过失,安全破坏,劣质设计的人机接口,等等。
故障及其分类 • 产品的故障按其故障规律分为两大类: • 偶然故障 • 渐变故障 • 产品的故障按其故障后果分为两大类: • 致命性故障 • 非致命性故障 • 产品的故障按其统计特性分为两大类: • 独立故障 • 从属故障 可靠性设计
2)可靠性的分析——可靠度 • 可靠度 • 产品在规定的条件下和规定的时间内,完成规定功能的概率称为可靠度。依定义可知,系统的可靠度是时间的函数,表示为: 式中,R(t)——可靠度函数; ξ——产生故障前的工作时间; t ——规定的时间
可靠度函数 • 依定义可知,可靠度函数R(t)为: 式中, • N0 —— t = 0时,在规定条件下进行工作的产品数; • r(t) —— 在0到 t 时刻的工作时间内,产品的累计故障数。
累积故障分布函数 • 产品在规定的条件下和规定的时间内,丧失规定功能的概率称为累积故障概率(又叫不可靠度)。 • 依定义可知,产品的累积故障概率是时间的函数,即 • 显然,以下关系成立:
¥ ò = f ( t ) dt 1 0 ¥ t ò ò = - = - = ( ) 1 ( ) 1 ( ) ( ) R t F t f t dt f t dt 0 t 可靠度函数与累积故障分布函数的性质 由密度函数的性质 可知: 、 因此,R(t)、F(t) 与 f(t) 之间的关系如图所示。
故障率函数 • 故障率 • 工作到某时刻尚未发生故障的产品,在该时刻后单位时间内发生故障的概率,称之为产品的故障率。 • 用数学符号表示为: 式中, (t) —— 故障率; dr(t) —— t 时刻后,dt 时间内故障的产品数; Ns(t) —— 残存产品数,即到t 时刻尚未故障的产品数。
故障率函数 • 可按下式进行工程计算: 式中,Δr(t) —— t 时刻后,Δt时间内故障的产品数; Δt —— 所取时间间隔; Ns(t) —— 残存产品数。 对于低故障率的元部件常以 10-9/h为故障率的单位,称之为菲特(Fit)。
(t) 使用寿命 A B 规定的故障率 维修后故障率下降 t 早期故障 偶然故障 耗损故障 产品典型的故障率曲线 产品故障浴盆曲线 • 浴盆曲线 • 大多数产品的故障率随时间的变化曲线形似浴盆,称之为浴盆曲线。由于产品故障机理的不同,产品的故障率随时间的变化大致可以分为三个阶段:
3)纠错技术 (1)纠错码 在1950s就开始研究,最早的是可以检测和纠错的汉明码。它们通过数字系统广泛地用于识别和纠正短暂或者持久的错误。这些码引入冗余信息来确保一些类型的错误可以被检测和纠正。比如,一个单错校正/双错校正的码能用一个比特检测和纠正一个错误,但是不能用两个比特纠错。
(2)三模冗余(triple modular redundancy) 计算单元C有三个副本,C1,C2,和C3。三个单元接收同样的输入。一个独立单元比较每个输入的结果。如果至少两个结果一致,那么那个值被表决器选做正确结果。如果三个结果都不相同,那么就没有正确的结果。
(3)看门狗定时器(watchdog timer) 看门狗定时器(watchdog timer)被广泛地用于检测系统问题。如图,看门狗定时器连接到一个监视系统。如果这个看门狗定时器翻转,它产生一个完成信号,用于标注系统的错误中断。系统应该这样设计,当适当运行的时候,它一直在可能产生翻转信号之前复位定时器。因此,来自看门狗定时器的完成信号指示系统在一定程度上不合适地操作。看门狗定时器用于预防不同的故障。
(4)设计多样性(Design diversity) 一种用于减少一些系统错误进入设计的设计方法学。当一个设计需要给定模块的不同实例,应该采用模块的不同实现,而不是到处都用同一种模块。比如,一个有多个CPU的系统可能采用不同类型的CPU,而不是到处采用同一种类型的CPU。在一个三模冗余系统,产生表决结构的组件可能有不同的实现,这样可以减少产生同样设计错误的机会。
4)软件可靠性 “在规定的条件下,在规定的时间内,软件不引起失效的概率”。 • 规定的条件: • 软件运行的软、硬件环境 • 软件操作剖面:软件运行的输入空间及其概率分布 • 规定的时间: • 日历时间 • 时钟时间 • 执行时间
影响软件可靠性的因素 (1)运行环境(剖面) • 同一软件在不同运行剖面下,其可靠性行为可能极不相同。 • 软件故障是软件缺陷在一定输入情况下被激活的结果. • 假设软件输入域划分为两个部分:G和F:运行剖面不包含F中的输入,则软件不会出现故障,其可靠性恒为l。反之,如果运行剖面不包含G中的输入,则每一输入情况下均出现故障,如果没有容错措施,则R=0。 (2)软件规模 • 随着软件规模的增大,软件可靠性问题愈显突出。在我们考虑软件可靠性问题时,软件一般是指中型以上软件(4000-5000条以上语句),这时可靠性问题难以对付。 • 软件工程实践的一个侧面可以反映这一点,即单元测试一般由编程人员本人进行,而综合测试则需独立的测试人员。
影响软件可靠性的因素 (3)软件内部结构 • 结构越复杂,软件复杂度越高,内含缺陷数越大,因而软件可靠度越低。 (4)软件可靠性设计技术 • 一般是指软件设计阶段中采用的用以保证和提高软件可靠性为主要目标的软件技术。 (5)软件可靠性测试 • 研究表明,软件测试方法与资源投入对软件可靠性有不可忽视的影响。 (6)软件可靠性管理 • 软件可靠性管理旨在系统管理软件生存期各阶段的可靠性活动,使之系统化、规范化、一体化,这样就可以避免许多人为错误,以提高软件可靠性。
影响软件可靠性的因素 (7)软件开发人员能力和经验 • 软件开发人员(包括测试人员)的能力愈强,经验愈丰富,所犯错误便可能愈少,所得软件产品质量愈高,相应的可靠性也愈高。 (8)软件开发方法 • 软件工程表明,开发方法对软件可靠性有显著影响。 • 与非结构化方法比较,结构化方法可以明显减少软件缺陷数。 (9)软件开发环境 • 研究表明,程序语言、软件开发环境影响软件的可靠性,而软件测试工具的优劣则影响可靠性测试结果。
4、安全(Safety)&保密(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等人描述了可信性和保密性间的关系。可信性和保密性由几个特性所组成:Aizientis等人描述了可信性和保密性间的关系。可信性和保密性由几个特性所组成: • 服务的可用性(Availability) • 服务的连续性(Continuity) • 来自用户和所处环境的灾难性后果的安全性(Safety) • 来自不合适系统改变的完整性(Integrity) • 通过更改和修补的可维护性(Maintainability) • 信息的机密性(Confidentiality)