嵌入式软件深入智能化设备

越来越多的智能设备正在进入我们生活的角角落落，包括您的电脑，智能电话，最新的苹果iPad等等。而设备中的嵌入式软件还在不停地促使您的汽车，洗衣机和电网向着智能化的方向发展。事实上，在我们的生活中，已经越来越难找到不包含嵌入式软件的大型电子设备了。

有谁会想到，为了去一趟杂货店，我们的汽车需要多少电子控制单元(ECU)不停地运作?又有谁会想到，今天的汽车所能带给我们的舒适享受已将过去我们认为烦恼，琐碎的驾驶变成了一种美好的体验。然而，然而，随着基于软件的设备变得更加普遍和复杂，嵌入式工程师越来越面临着简化设备的设计和测试过程，实现设备缺陷可追溯性的巨大挑战。

目前的嵌入式开发过程通常包括不同形式的设计仿真、验证、确认和系统测试。在这些阶段，设计和测试工具间很难过渡。这往往会造成需要将测试代码，测试案例，和仿真与I/O接口重新写入到模型中。

此外，由于传统设计工具也正变得越来越繁重，而模型和用例也日益复杂，我们很难将用于纯仿真测试的多个模型连结在一起。这些问题对企业在利润，人员需求，文档化及产品上市时间等方面提出了挑战。

　　实时测试软件的角色

对之前开发过程中用到的设计和测试工具、模型以及仿真数据进行复用，是目前嵌入式控制设备开发的一个趋势。许多设计和测试工程师在整个开发过程中会积极地复用设计模型。然而，如果这些工程师在设计流程中也对测试进行复用，那么就能进一步实现更高的效率和质量(见图)。

为了满足这一需求，一种新型软件——实时测试软件诞生了。该软件能够帮助工程师在整个嵌入式设计流程中复用测试任务，例如激励配置、测试序列、分析程序和需求跟踪。所谓“实时”是指该软件对嵌入式系统其余部分进行建模，从而具备在真实环境中，对测试设备(DCT)进行测试固件的能力。

在设计流程的各个阶段，从最初的产品定义一直到最终的系统测试，您可以通过使用相同的测试软件组件来获得更好的连续性。这对于诊断临床故障而言尤为重要——由于特征采集和生产中的测试程序不同导致很难判断故障原因的案例屡见不鲜。

例如，当开发嵌入式控制软件时，激励配置，分析程序以及其他模型在环(MIL)设计任务中使用到的组件将会被复用，以创建硬件在环(HIL)以及原型控制器的现场测试。

一旦这一阶段完成，演进的软件测试组件将是HIL、子系统，和系统集成测试系统开发的起点。

最终，在设计阶段制造商所使用的生产测试计划与原先设计阶段的测试计划具有相同的“DNA”。同样地，在ASIC设计中，计算机辅助工程(CAE)工具使用的测试台和分析仪将应用于基于仪器的测试系统。最后，开发团队将以同样的方式来生产和检查结果。

这样将使这些团队更快更高效地做出决策和调整，节省了时间成本和预算。这种方法不仅使得团队在应对测试中出现的问题时具有高度的灵活性和适应能力，并且，当由于中期项目需求变动而产生更多测试用例，或在设计流程各阶段中进行故障追溯时，这一方法也是很有帮助的。

然而，尤其需要注意的是，尽管实时测试软件使得嵌入式设计和测试的效率有了显著的提升，但在解决您的嵌入式设计和测试需求时，您需要考虑到的绝对不仅于此。为了确保您开发需求的准确性和并保证您的设计可转成真实的产品，，除了聘请专家以外，您还应该制定并遵循风格指南和精细的流程。

有些公司已经开始以全新的视角看待嵌入式开发程序，把测试组件作为开发过程中一个通用DNA。这样的公司无疑将更具有竞争力。设计完成后进行的测试任务将会成为产品设计过程中不可缺少的一环。

尽管他们本身的目的不同，但随后的测试组件将会共享一个通用的结构。他们在某些时候会是之前步骤的克隆，在另一些情况下则是其他步骤的演变。这一关系将会扩展目前项目的通用需求到测试组件和过程的实际复用。这将大大节省成本、时间和人力，同时终端用户可以从最新的软件设备中获得更佳的品质。