要点
　　* 嵌入系统的工程不仅是要使它们实现某些性能，而且还要防止它们表示出不需要的性能。
　　* 设计者可能会用调试工具作为设计辅助方法，因为没有更好的方式完成任务。
　　* 嵌入系统的调试是一个跨学科的活动，跨越了硬件、软件和领域知识的界限。

　　《嵌入系统设计》每年都有针对嵌入系统开发人员的年度市场调查，其中对设计活动的改进要求最多的一个领域就是调试工具（参考文献1）。在为期三年的调查中，有这种要求的受访者百分比一直稳定在大约32%。与之相比，寻求改进编程工具的受访者比例则从高达25%下降到10%。为什么现代调试工具未能像软件编程工具一样做得那么好，这是值得探讨的问题，尤其是每年的调查亦证实，测试与调试阶段仍是项目计划中耗时最多的部分，达24%。在全部三年的调查中，居第三位的改进要求是进度安排的项目管理功能（见附文“COCOMO与基于事实的进度安排”）。

　　工程的一个明确方向是针对某个问题，建立能完成和提交一个实用方案的系统。软件编程工具注重于软件工程的创建方面。调查结果表明，在提高创建能解决问题代码的生产率方面，编程工具走对了路。而调试工具的百分比没有随编程工具呈下降趋势成为一个主要的问题，这表明软件调试工具不只是编程工具的扩展，不只是用于帮助工程师改正错误或不正确的编码。

　　关于工程有一种不太清晰，几乎是隐含的问题，即设计者不仅要设计出能完成所需功能的系统，而且还要消除或减轻环境不确定性和可变性可能带来的不良状态，因此系统要在各种工作条件下保持一致的性能。工程的这个隐秘一面可能揭示了软件调试工具所面临的挑战，尤其是对嵌入系统设计者。除了要应对处理器架构对性能、功能、通信、延迟和功耗的实际约束以外，嵌入系统一般还要处理与真实世界的接口，这些接口展现的行为更难以对整个使用场景作出预测或特性描述。

　　如果调试只涉及寻找和改正软件的逻辑错误，那么一个指令集仿真器与周期精确的仿真器相结合，就能为嵌入系统行为提供足够的可见度，支持调试工作。很多处理器架构和软件开发工具套件都已有了这类仿真器。仿真器还可以使系统停止运行，以便检查仿真系统的任何部分。遗憾的是，这些类型仿真器一般不能对内存、总线架构、外设、传感器和促动器之间的精确交互与延迟提供完整的可见性，并会使仿真器运行得更慢。

　　系统级仿真器有能力超越软件执行引擎，仿真系统其它部分的相互作用，如Vast公司的虚拟系统原型工具和Virtutech公司的Simics虚拟平台。这些类型的开发工具使软件开发人员能够在物理硬件可用以前就在目标产品上工作；它们还通过系统级故障注入以及与其它开发活动的并行增量整合，帮助开发人员完成系统集成和测试工作。对于复杂的高端系统，这些类型的系统可以用作先期工具，或支持硬件在环仿真。这些工具支持预建的系统，并将预建的部件或块装配成一个系统。通过附加工具，它们还提供建立新部件并集成到系统中的能力。

　　系统级仿真要面临的一个障碍是成本，它的价格可能会比现有针对处理器的仿真器高出数千美元。在调查中，调试工具没有跟随编程工具的下降趋势，可能并非因为它们不能满足嵌入系统设计者的功能需求，而是因为具备所需功能支持的高端调试工具价格仍然超出了某些关键性的门限。有意思的是，这个价格门限低于硬件设计工具，尽管多数软件开发工具似乎支持在新系统中增加更多的复杂内容。

　　过去十年来，基于专利金的操作系统与开发工具许可模型已受到严重侵蚀。Linux作为一种嵌入系统操作系统日益成功，这主要源于开源软件的价格优势。另外，芯片供应商的很多嵌入系统工具都采用开源Eclipse平台管理自己的开发工具，显著降低了建立这些工具的成本，简化了最终用户对工具的配置，使他们在工作中专注于工具特性，而不是主控环境的观感。这种说法并非表明调试工具不会在定价方面追随相同的下跌趋势。极端来说，很多处理供应商都提供小型评估套件，开发者花不到100美元就能对系统作实验。事实上你会发现，今天很多数百美元开发套件包含的功能在十年前只出现在贵得多的工具中。

　　当片上调试电路扩张到流行的处理器架构上时，业界可能会继续看到较高端的调试功能试图进入较低价开发工具套件。很多处理器（包括小型的8 bit处理器）都包含一些专利的片上调试电路。Atmel公司AVR开发工具总监Dag Arne Braend称：“片上调试系统是芯片中最复杂的电路之一，因为它必须与所有子系统作非侵入性互连。很难判定这种复杂性所引发的额外成本，因为对某些东西，很多系统永远都不会用于现场器件中。”

　　实时跟踪看来是下一个新兴的片上调试功能，采用ARM核心并带ETM（嵌入跟踪微单元）的处理器能够实现处理器的指令下载和数据跟踪。Cortex-M3核心支持一种新的实时跟踪能力。跟踪能够实现反序指令执行，有越来越多的仿真器正支持这种功能。Green Hills Software公司的Multi Time Machine调试套件能够使开发者在片上调试与仿真器调试之间转换，支持仿真的反序执行。
        IEEE-ISTO 5001-2003是Nexus 5001 Forum针对全球嵌入处理器调试方法的开放式工业标准，它为嵌入处理器的软件开发与调试提供了一种通用接口。Nexus 5001 Forum最初关注点是汽车传动应用，但结果是发展成为一个通用标准。Nexus 5001 Forum成员遍及半导体、开发工具和汽车电子业。随着硅片成本不断下跌，以及片上调试接口与功能的标准化，处理器供应商很可能将高端的片上调试能力从高端处理器带入较低端的处理器，以提供更强大的片上可视性。这将成为获得设计成功的必需步骤。

　　设计辅助

　　针对系统级仿真工具的较高价格，Virtutech公司首席执行官John Lambert提供了一个立即可行的迁移因素。他说：“有一个开发团队通常用我们的平台作为他们当前项目的前后端支持，但一旦他们使用了这一工具，就更加彻底理解了它的价值，并用于未来项目设计周期的两端。”

　　这个理论表明，当嵌入系统设计者称自己需要更好的调试工具时，他们的原意可能并非如此。调试工具的主要功能是提供系统运行时状态的可视性。当一个系统包含了复杂接口、传感器和促动器时，调试器可能是用于检查这些外部系统功能的最方便工具，因为要为所有这些紧密耦合的子系统生成准确的信号是一个重大挑战。因此，你可能会把它们称为调试工具，而不是设计辅助工具，一个原因是只有到了项目的系统集成阶段，这些工具的功能才可以使用，这时调试已走入正轨。

　　将调试工具看作设计辅助工具提供了一个有价值的观点，尤其是在做闭环控制的系统时，此时输出会影响系统的输入。闭环控制系统的行为验证可能是一个挑战。我曾用最终系统软件和传感器硬件，对一只传感器要在一系列预期环境中使用的自动增益控制算法作了性能特性描述和验证（参考文献2）。在一个纯软件调试环境下，不存在对这种条件的仿真方法，甚至对类似事情的测试，因为传感器没有精确模型。结果是，我及时发现了传感器的一种未知特性。

　　第二个例子是获取系统集成测试数据，并用一个数据表程序运行这些数据，以分析闭环控制算法的功能是否正常。同样，没有哪种软件仿真或设计工作可以真正将设备联系在一起并收集数据；在集成期间运行测试要比试图建立一次精确的原型系统模型更有性价比。但是，我确实使用获得的系统行为信息，为下一代开发工作建立了仿真模型。

　　调试嵌入系统的另一个特点是，问题并非只来自软件错误。不过，因为在软件中修改大多数错误要更有成本效益和日程效益，设计者通常还是用软件修复来解决问题。然而，当软件变化时做一个修复和记录修复，与寻找、诊断和确定一个可接受的分辨率所需要的跨学科合作工作量不相适应。事实上，很多嵌入系统调试问题都是跨学科的问题，需要对系统硬件、软件和特定域约束条件的理解和专业知识。如果做系统集成测试的人恰好是三个方面的专家，那就没有问题了，但这种人寥若晨星。

　　由于嵌入系统调试的跨学科特性，调试工具与工程服务就有了填补空缺的机会。仅仅因为调试工具能提供系统的某种可视性，而并不意味着开发者能用到这个特性。Green Hills Software公司首席技术官David Kleidermacher同意这个说法：“对开发者来说，工具中有太多选项需要大量的学习曲线，因此很多这类特性的使用率不高。”由于时间压力，开发者倾向使用最简单的功能，而先进的功能更多地是作为他们从前期项目中学到的一部分经验。作为对这种认识的一种响应，Green Hills公司在自己的Multi Time Machine调试工具中增加了“永远打开”（always-on）的跟踪能力；跟踪能力对开发者已越来越有用，因为默认条件几乎不会让开发者付出什么成本，不需要使用学习曲线，并且比显式地打开跟踪-捕捉功能更有效率。

　　开发者调试嵌入系统时面临的另一个挑战是测试台的搭建与配置。这是一个低成本但高价值的问题，很多工具供应商都尝试在自己的工具集中解决这个问题。很多评估板的电源现在都带有USB连接，大大简化了这些电路板的电源设置工作。在嵌入系统与主控系统之间传送用户采集数据的接口现在也更易于使用，并且有了在不久的将来用无线接口作调试的说法。很多开发工具套件都提供一种预先配置好的设置，使开发者对电路板作测试，确认电路板及其工具都能在一种已知环境下正常工作。德州仪器公司技术研究员Reid Tatge解释说，该公司开发工具的一个目标就是使嵌入开发工作像“wintel”系统（即采用英特尔公司微处理器和微软公司Windows操作系统）的开发一样，从而简化设计者使用自己嵌入处理器的学习曲线。
        Micrium公司C/Probe的目标是使开发者能更简便地实现自己系统行为的快速虚拟化。该工具包括两部分软件：其一运行在主控系统上，完成数据分析与显示，另一个是在目标系统上装入的一个代码段。这段代码负责管理I/O与资源请求，以及与主控系统的通信。尽管它是一种侵入性的嵌入系统代码仪表化方式，但它能在系统不挂起情况下访问系统。该工具现售价约1千美元。

　　National Instruments公司的LabView提供强大的虚拟化支持，并包括一个图形编程功能。它还带有围绕各个应用域而组织的内置测量与分析功能，这样开发者就可以选择要使用的功能。调试虚拟化最适用于数据流执行模型。包含硬件、软件和特定域功能的工具套件起始价约为1千美元，但如果需要增加大量特定域工具，则价格可能超过1万美元。

　　这种类型的定价灵活性表明很多工具供应商都面临的一个挑战；客户希望根据不同的接触点，只支付到最适当的可视性水平。例如，有些开发者面向一个操作系统，而并不关心其下处理器架构的细节。其它开发者则面向指令集架构。当然还有一些开发者关注较低级的交互。如果在架构层，它连接系统中的所有资源。

　　即使工具针对一个设计者需求提供了可视性，但知道要寻找的内容则是另一个困难，因为片上系统和主控系统之间的通信链接限制了捕捉数据的数量与类型，这些数据可以给主控系统作实时分析和事后分析。另外，处理器供应商并非总会公开自己在芯片中实现的特性；他们可能选择隐藏这些特性，因为它们是实验性的，供应商还没有准备好为它们提供健壮的生产级支持。但是，内部工具与专业的现场应用工程服务可以完全利用这些隐藏的资源。而从能在有限情况下的专家式使用，到工具足够健壮，可以在各种场合和专业水平下的使用，两者间还有相当大的差距。不幸的是，工程服务是劳动力密集型工作，价格高昂，其成本远远超出大多数软件开发预算的门槛，除非是遇到最紧急的查错情况。

　　要获得持续发展，调试工具就需要获得硬件、软件和领域专家的相关信息输入。在某些情况下，处理器客户或工具供应商不太愿意分享自己艰难获得的经验。如果他们与工具开发商分享关键的经验，就可能缩短竞争对手的学习曲线，避免一些计划安排与工程专业成本，如学习如何使嵌入系统在某种方式下工作。现场应用工程师的经验可以帮助使工具开发商具备必要的洞察力，使调试工具在这些情况下更加有用。

　　几十年来，嵌入系统已实现了多处理器设计，但对于紧密耦合的多核心和多处理器系统，仍在持续出现新的机会。另外，越来越多的嵌入系统正在自己系统内使用更多的传感器，以充分获取和掌控更复杂的行为。这些嵌入系统中的新兴趋势将要求调试工具提供更强大的一致性和相应的虚拟化能力，因为子系统之间的交互作用将比以往更加复杂。

参考文献
1. Nass, Richard, “Annual study uncovers the embedded market,” Embedded.com, Sept 2, 2007.
2. Cravotta, Robert, “Valuing Uncertainty,” EDN, Jan 5, 2006, pg 38.

---

　　附文：COCOMO与基于事实的进度安排

　　现实的进度安排是建立好软件的关键。过紧的截止日期不可避免地会成为压力来源，从而导致交出一个未完成的项目。认识到截止期限太紧会使你将注意力集中在最好或最重要的特性上，它也会使你对最终产品中整合的内容作出正确决策。有很多方案可以帮助项目管理者对软件开发项目作出功能、成本与时间上的权衡，从而得到更精确的计划安排。

　　其中一个方案就是COCOMO（结构化成本模型），这是一种软件成本的估算模型，它使用了利用历史项目数据和当前项目特性的回归公式。软件工程师Barry Boehm首先于1981年公开了该模型。COCOMO II 模型包含有多年软件开发中的变化，在规划新的软件开发项目时估算成本、工作量和日程安排。COCOMO II模型现公布在南加州大学系统与软件工程中心网站（参考文献A）。

　　COCOMO II包括应用构成、早期设计，以及后结构子模型，它根据项目规划与设计过程的进度，提供日益增加的精确性。COCOMO II可以辅助建立项目预算与日程；作软件成本与日程风险管理决策；在软件成本、日程安排、功能、性能与质量因素之间作出权衡；以及决定一个软件系统的哪些部分要开发、重用、租用或购买。持续提高COCOMO II预测准确性的重要因素是良好的数据。COCOMO II研究小组正在请求软件业的协助，采集各个开发项目的数据；数据采集将能实现一个更精确的预测模型，以估算软件项目的成本。

　　Fog Creek Software公司的首席执行官Joel Spolsky在一篇文章中给出了基于事实的日程安排，这是另一种在日程模型中包含历史数据的方案（参考文献B）。文章以一种普通方式对该模型作了说明，不过Fog Creek将此模型用于它的FogBugz商用产品。第一步是以批量小时数为度量单位来规划进度，例如不超过16小时，以确保估算人精确地考虑完成某个任务所需要的步骤。遵守这个时间表，可以将每个开发者的估算值与实际结果作比较，并建立一个估计的变化速度，这样不仅能帮助你在一段时间上改善自己的估算，而且还提供了一个用于Monte Carlo仿真的模型，可计算出在任何给定日期交付任务的概率，并绘制成图。有了图示的可能交付日期，就可以进行研究，如改变不同特性的优先级或包含变化会对日程有哪些影响。

参考文献
1. "COCOMO II."?
2. Spolsky, Joel, "Evidence Based Scheduling," Joel on Software, Oct 26, 2007.

*博客内容为网友个人发布，仅代表博主个人观点，如有侵权请联系工作人员删除。