嵌入式原理嵌入式系统设计

嵌入式原理嵌入式系统设计第1页，课件共55页，创作于2023年2月3-1设计方法论采用方法论有以下三个重要理由：1．确认所做的每一件事情都是必须要做的。2．根据设计方法论可以发展出计算机辅助工具或是累积设计经验。汲取每一次产品开发的经验，再经过量化之后，可以发展出一套工具或是方法，让往后的产品设计步入自动化。3．遵循同一套方法论，可以让团队成员更容易彼此沟通。每个人都能在短时间内了解整体过程中将经历哪些过程，需要何种支持与接收到何种结果。不要画蛇添足！也不要只扫门前雪！熟能生巧！项目经理总揽全局！第2页，课件共55页，创作于2023年2月3-1设计方法论设计方法论（DesignMethodology）

3-1-1设计过程3-1-2设计流程的方法第3页，课件共55页，创作于2023年2月3-1-1设计过程设计过程的目标是做出一个有用且具有卖点的产品。一个产品的典型规格包含功能性、制造成本、性能表现、省电考虑和其他特性。【例】一台个人数字助理PDA必需具有个人辅助信息的软件和有趣的应用程序（功能性）制造成本大概需要在3、4千元以下必需具备开机速度快，操作上不能有意外的延迟现象等性能（性能表现）电力要能够维持一个星期以上第4页，课件共55页，创作于2023年2月3-1-1设计过程一般产品的设计过程的目标至少必须符合三种需求上市时间顾客总是想要一些新的功能，如果能够抢先上市及时供应给顾客的话，销售数量自然会比其他同型产品来得高。引领时尚潮流！设计成本许多消费性产品对于价格非常敏感，所以产品厂商对于成本一般总是斤斤计较的。质量在设计之初，就必须考虑到可靠性和实用性。iPhone4的天线！第5页，课件共55页，创作于2023年2月3-1-1设计过程——设计过程中的几个重要步骤自上至下的设计需求和规格都对产品做比较详细的描述。规格只是描述产品的功能行为，并不说明如何建立系统。系统内部的建立方式是从架构设计开始建立，并且开始规划系统内应该有哪些组件。组件设计与实现包括软件模块与硬件模块。最后将这些组件加以集成，得到一个完整的系统。自下至上的设计在不清楚系统设计的情况下采用，特别是没有建立这类系统的经验。采用由下至上设计的方式来边做边学，最后再通过这些经验重新调整系统，完成目标。第6页，课件共55页，创作于2023年2月3-1-1设计过程——一些重要的问题制造成本、性能要求、省电因素与用户接口。在设计过程中，考虑如下问题：分析设计的每个步骤以决定应该符合哪些规格。加入更详细的内容来加强设计。确认设计符合整体系统的目标，如价格、速度等。一个好的设计方法论可以让一个系统更快完成，而不至于受到外部和内部因素影响。一个好的系统也不该有臭虫（bug）的存在。第7页，课件共55页，创作于2023年2月实例火星气象卫星的失事原因1999年，美国所发射的一台火星气象卫星，没有在正确的时间点燃维持轨道的引擎，导致与火星距离太近而失事。原因之一：美国JPL与LockheedMartin的工程师使用的计算单位不一样。JPL用的是牛顿，LockheedMartin用的是磅，双方都以为和对方用的是一样的单位。→计算出来的结果与真正的轨道差距4.45倍。第8页，课件共55页，创作于2023年2月3-1-2设计流程的方法设计流程（DeignFlow）指的是设计过程中所经历的过程步骤。常用的设计流程的方法瀑布模型（WaterfallModel）螺旋模型（SpiralModel）连续改进（SuccessiveRefinement）设计方法层次结构式设计流程第9页，课件共55页，创作于2023年2月瀑布模型（用户）需求通过分析确定产品的基本特性（技术）规格架构→系统组成将每个功能面细分成许多组件（软件）编程＋硬件制作把这些小单元实现出来并且集成测试找出臭虫维护产品发布、臭虫修正以及升级等一旦某个阶段出现问题，可能需要逐级向上寻找bug。第10页，课件共55页，创作于2023年2月螺旋模型在每一个设计层次，设计者都会经历需求分析、构建与测试阶段。在设计过程中，不断加进前一设计周期所得的经验，逐渐构建更完善的系统。特点多重反复的方式会在复杂系统里加入足够的细节花费太长的时间。在时间因素影响产品成败时，螺旋模型便不太适用。由点到面！由浅入深！逐步推进！第11页，课件共55页，创作于2023年2月连续改进设计方法连续改进设计方法论是假设系统会建立好几次，最初的系统会是一种粗略的雏形，经过连续的方式不断改进。通过反复建立好几个越来越复杂的系统，可以帮助设计者检验架构和技术，也可以帮助设计者避免错误。连续改进设计方式对于打算建立一种不熟悉的系统的设计者来说比较有意义。第12页，课件共55页，创作于2023年2月简易硬件与软件的同步设计流程初期阶段的需求与规格设计必须要同时考虑硬件与软件两方面。最后的阶段需要集成与测试整体系统。中间阶段采用独立分开方式设计。第13页，课件共55页，创作于2023年2月层次结构式设计流程第14页，课件共55页，创作于2023年2月同步工程（ConcurrentEngineering）问题：当越多人同时进行一个项目的时候，就越容易失去完整设计流程的轨迹。每个小型系统的设计者容易局限在自己的设计流程里。同步工程的目的采用一个较广泛的看法让整体流程最佳化。消除每个小型系统设计者之间的障碍，以免设计者局限在自己的看法而无法与其他设计者进行沟通，造成反复或冲突的情况不断发生。设计过程中整个设计团队交流与沟通至关重要！第15页，课件共55页，创作于2023年2月设计设计什么？如何设计？收集客户所描述的消息，整理成需求列表。把这些需求进一步萃取之后，形成系统架构设计的数据－技术规格。第16页，课件共55页，创作于2023年2月3-2需求分析需求与规格需求分析证实需求简易需求表第17页，课件共55页，创作于2023年2月需求与规格将客户的需求理念捕捉出来，并且以正规的方式描述（用户需求分析），同时将客户描述的方式转换成系统设计者的描述方式（技术规格）。需求与规格描述系统所呈现的行为，而不是内部结构。需求是顾客想要什么样产品的信息描述。规格是更详细、更精确的描述系统的功能。第18页，课件共55页，创作于2023年2月需求分析需求分析需要设计者与顾客详细沟通设计者需要了解顾客所预期的产品是什么顾客也必须了解他们到底可以得到什么样的产品需求的种类功能性需求是指系统必须要有哪些功能。非功能性需求实体大小与重量、价格、设计时间、电力消耗、…。想要什么？得到什么？第19页，课件共55页，创作于2023年2月证实需求确认列出来的需求是真的为客户所需要。怎样确认？仿真系统——用一些事先准备的数据来模拟一些功能，当作一个有功能限制的展示系统。给客户一个实际看得到的模型来说明实际做出来的系统将如何运行。样机、测试版、概念车第20页，课件共55页，创作于2023年2月简易需求表名称目的输入输出功能性能要求制造成本电源实体大小与重量第21页，课件共55页，创作于2023年2月需求分析——需求文件的特性正确性：既不可误解顾客所需，也不可描述不需要的需求。精确性：需求文件应该做清楚的描述，而不是笼统的说明。完整性：所有的需求都应该记录。可证明性：所有的需求都应该有方式可以证明是合理的。一致性：某项需求不应该和其他需求相互冲突。可修改性：既然可以建立需求，当然也可以修改需求，而且不会违反上述的特性。可追踪性：每份文件都应该可以追踪。包括为什么会有这样的需求，彼此需求间的相关性，这些需求是否可能实现，以及最后是否满足这些需求。第22页，课件共55页，创作于2023年2月如何决定需求呢?销售部门会帮忙反映市场的需要，或是去询问顾客，然后将这些意见汇总进行分析。如果是顾客直接找上门，就需要和顾客进行访谈，以了解他们的期望。如果顾客能够给设计者一个简单的样品，将可以帮助设计者更清楚应该要设计出什么样的产品。设计者先做出一个雏形，请销售部门进行展示或是意见调查，然后再将结果进行分析来决定需求的内容。第23页，课件共55页，创作于2023年2月3-3规格客户与架构设计团队之间的契约

统一建模语言SDL语言状态图AND/OR表第24页，课件共55页，创作于2023年2月统一建模语言UML是一种描述规格的语言，通过对系统正规化的表述，使所有看过规格的人，尤其是设计团队里的成员充分了解所描述的产品是什么。第25页，课件共55页，创作于2023年2月阅读资料：UML第26页，课件共55页，创作于2023年2月SDL语言SDL包含了状态、动作和每个状态之间的转换条件。SDL是一种以事件为对象的状态机器模型。内部或是外部事件的不同，使得状态之间相互转换。第27页，课件共55页，创作于2023年2月状态图（StateCharts）状态图用来消除以状态为基础的规格中杂乱的部分，澄清其中重要的结构。状态图使用在事件驱动模型中，让事件可以归类在一起并且显示共通的规格部分。两种归类方法：OR与AND。第28页，课件共55页，创作于2023年2月传统图解与OR状态图第29页，课件共55页，创作于2023年2月传统图解与AND状态图第30页，课件共55页，创作于2023年2月AND/OR表以AND/OR表来表示一个布尔表达式。每一列标记表达式里的基本变量，每一行则对应到每一表达式项目。第31页，课件共55页，创作于2023年2月3-4系统分析与架构设计规格只是对事项做了描述，并没有说明系统如何做到被要求的事项。当规格制订完成之后，接下来就是将规格转变为架构设计。架构是对整体系统结构的计划，说明利用哪些组件来构建系统。第32页，课件共55页，创作于2023年2月3-4系统分析与架构设计3-4-1方框图（BlockDiagram）3-4-2CRC卡片第33页，课件共55页，创作于2023年2月3-4-1方框图方框图描述系统架构，显示系统有哪些主要组件。方框图可能非常抽象，没办法使用这些方框来直接实现，不过这些方块可以告诉接下来的工作方向是什么。可以依据方框图所描述的工作项目进行分工，做出能够完成更详细的功能的、描述更多细节的方块图。GPS的地图显示功能第34页，课件共55页，创作于2023年2月方框图细化应用举例硬件与软件的架构方块图采用细化方框图的方式更精确的描述每一个方块该有的架构，最后经过几次的重新锤炼与整理，完成系统架构设计。软件方块图更清楚的描述每一个功能之间的相互关系。硬件方块图还描述了应该要搭配的某些外围设备。第35页，课件共55页，创作于2023年2月方框图架构设计必须同时满足功能性与非功能性的需求。不仅要符合所有需要的功能，也必须符合成本、速度、电力与其他非功能性需要，因此做架构设计的时候，除了注意功能单元之外，还要想到软件与硬件限制的部分。如何知道实际上软件与硬件的限制到什么程度呢?在设计系统架构的每一个方块时，大概就需要估计方块图里每一个组件的特性。例如：用户界面的显示速度或是数据库的查找速度。要估计这些组件的特性，必须依靠设计者的经验，这项工作考验设计者对于该系统的熟悉程度，如果不能做准确估计，产品的架构设计就不会理想。第36页，课件共55页，创作于2023年2月3-4-2CRC卡片CRC系统分析模型将相关信息写在一张包括了类、责任与合作对象等信息的索引卡片上，并且相互讨论与更新这些卡片数据，直到讨论出结果为止。类（Classes）：定义数据与功能的逻辑归类。责任（Responsibilities）：定义每个类该做些什么。合作对象（Collaborators）：定义其他类所做的工作。第37页，课件共55页，创作于2023年2月CRC卡片把某些功能封装起来便称为一个类。一个类可以描述一个真实对象或是一个系统的某个环节。一个类存在自己的内部状态与对外接口。对外的接口就是这个对象所表现出来的功能。责任就是类的接口。责任的作用在于描述类的功能接口，而不是内部的运行与实现方式。合作对象是指该类究竟和哪些类互相沟通，以及该类使用了其他类的哪些功能或是其他类交付了什么样的工作。第38页，课件共55页，创作于2023年2月3-5设计硬件与软件组件组件设计就是遵照架构与规格建立嵌入式系统第39页，课件共55页，创作于2023年2月3-5设计硬件与软件组件标准组件：已经制造好了的组件微处理器等几乎是一种标准的硬件，通过这些标准组件的组合，可以节省很多精力。选择标准组件（例如数据库功能），使用现成的函数库，节省设计与实现的时间。定制组件：设计者设计的属于自己的组件要设计出电路板来连接微处理器或存储器等标准组件，或是做很多客户特别要求的部分。将标准软件模块移植嵌入式系统上，使之在现有的硬件上实时运行。第40页，课件共55页，创作于2023年2月3-6系统集成把设计的组件组成一个完整的系统第41页，课件共55页，创作于2023年2月3-6系统集成通常会在系统集成阶段找到很多臭虫好的规划可以帮助很快找到臭虫比如，足够的测试案例或是进行集成的时候先将几个模块放在一起，确认臭虫是否存在。不要在组合到复杂系统后才开始确认臭虫，那时已经很难识别这些臭虫的来源了。在系统架构与组件设计时，需要考虑将来如何确认臭虫，是否可以将这些组件功能的关系互相独立，以方便确认。系统集成是非常困难的到这个阶段已经很难确认问题究竟是出在哪一个部分，而且嵌入式系统的调试工具与接口通常都很有限，比台式机更难找出问题所在。第42页，课件共55页，创作于2023年2月3-7质量保证质量保证的过程是维持一个高质量产品必需的过程

3-7-1质量保证技术3-7-2确认需求与规范3-7-3设计复审3-7-4衡量驱动质量保证第43页，课件共55页，创作于2023年2月3-7-1质量保证技术国际标准组织（InternationalStandardsOrganization，ISO）建立了一套知名的质量标准，称为ISO9000。人工执行确认系统设计以及保证质量——设计复审依靠工具的确认方式帮助管理较复杂的系统里所产生出的大量信息。测试产生程序可以自动地取代令人烦闷的测试问题追踪工具可以帮助人们找出每个步骤的进行方式设计流程工具则可以自动地处理设计运行数据不需要太高深的管理技巧与复杂的程序，源代码版本控制就可以达到很好的质量管理。第44页，课件共55页，创作于2023年2月质量保证技术——CMM能力成熟模型提供一个模型来判断一个组织的质量成熟程度1．初始（Initial）阶段：只有少量定义完备的程序，项目的成功依赖的是个人的努力，而不是组织的力量。2．可重复的（Repeatable）阶段：具有基本的追踪机制，可供管理成本、计划进度，可以让系统发展符合预期目标。3．己定义（Defined）阶段：所有管理与工程进行的过程都已经利用文件记录并且标准化，所有的项目也都使用文件建立，且符合标准方式。4．己管制（Managed）阶段：这个程度可以通过仔细衡量，完成开发程序与产品质量的保证。5．最佳化（Optimizing）阶段：在最高级阶段里，可以通过仔细的衡量取得改进建议，并且持续改善组织内的程序。第45页，课件共55页，创作于2023年2月3-7-2确认需求与规范如果不能找出需求与规范中的臭虫，对于未来系统的发展将会衍生出更多的错误，而且极可能无法修正。如果一开始就存在臭虫，时间愈往后，将会付出愈昂贵的代价。一个程序设计中所产生的臭虫，可能在产品卖出去之后，还需要付出不少费用回厂检修。如果一开始设计规范就出现错误，而且不能及时发现的话，整个产品或是项目就必须从头开始。早期发现需求或是规范里的臭虫，可以避免提供顾客有瑕疵的产品、降低设计成本以及缩短设计时间。存在越久的臭虫，修正成本越高第46页，课件共55页，创作于2023年2月需求确认雏形产品（Prototypes）：样机、测试版一个雏形产品可以帮助产品用户在功能面与非功能面给予意见。已有的系统以前已经做好的系统也可以用来帮助产品用户了解他们的需求，特别是用户不喜欢之前做好的系统。想要得到一些新的产品，可以从以前的经验里进行需求确认。有时需要在已有系统的基础上构建出一个新的雏形产品来进行需求确认。第47页，课件共55页，创作于2023年2月规范确认雏形产品（Prototypes）：样机、测试版案例情景（UsageScenarios）正规化技术（FormalTechniques）第48页，课件共55页，创作于2023年2月3-7-3设计复审（DesignReview）设计复审可以在设计过程中以最简单而且最经济的方式找出臭虫所在。设计复审通常是设计成员开一个会，重新审视系统设计的每一个组件。有些臭虫可以在准备开会前就被找出来。因为这样的方式会强迫设计者更仔细的思考所有的细节，否则开会的时候就会被钉在台上下不来。有些臭虫会在会议进行的时候被找出来。因为一个人的能力是有限的，通过集思广益的方式可以找出设计者的设计缺陷。越早找出臭虫，不让有问题的设计进入实现阶段，越能节省成本以及工作时间。第49页，课件共55页，创作于2023年2月设计复审一般可以自行建立一个能够清楚表达设计复审的重点的设计复审格式，帮助在会议中审视系统里特定的组件。一个设计复审团队的成员设计者（Designer）：设计者自己最清楚所设计的组件，在审视的过程中，报告与解释为什么需要这样的设计规格。包括需求、接口描述以及与系统的关系。复审主席（ReviewLeader）：协调会议之前的准备工作、会议进行以及会后的追踪工作，确保会议