Hines-Ortega方法简化复杂的软件设计问题

在当今快速变化的市场上，嵌入式系统开发人员常常面临着设计在最后阶段还要改变的问题，以及应付数量不断增长的多处理器目标架构带来的设计挑战；与此同时，开发人员们还必须处理那些与系统底层资源直接打交道的软件模块之间的复杂关系，这些关系往往会使费时费力的开发周期延长并推迟开发进度，以便能跟上设计变更的要求。所以说在典型的嵌入式开发环境中，软件问题往往比硬件问题更复杂，而且开发环境随着各种关联设计的出现会变得更加糟糕。

Ken Hines

副总裁兼首席专家

Ross Ortega

副总裁兼技术总监

Consystant Design Technologies公司

值得庆幸的是，现在一种新的方法可以处理这种复杂的情况，名为Hines-Ortega的新设计方法可使设计人员工作于更高的抽象级上。基本上，Hines-Ortega让设计人员能更有效地进行开发、测试及调试复杂软件，而不必理会低层的实现问题。这种以协同为中心的方法使设计人员可将功能行为与各软件组件的协同性分开，从而简化了设计和调试，加快了与硬件集成的速度，使得代码可重新利用，同时也使嵌入式设计能很容易地再用于不同的硬件平台上。

在嵌入式系统设计中，软件一般都滞后于硬件的开发，而且这也一直是嵌入式系统产品进度拖延和发布延误的主要原因。尽管许多公司都要求产品应尽快上市，但嵌入式软件设计人员却发现自己受到设计方法的禁锢，往往要被迫等到硬件到位后才能着手进行开发；而当他们好不容易可以开始软件开发时，又发现每一项都需要作专门设计，因为以往项目中本来可以利用的软件与具体的系统配置联系非常紧密，要想重新使用不是那么容易。

那些完全利用嵌入式系统来制造不同产品的公司则要冒更大的延误风险，传统的开发方式在越来越紧的时间压力下正在崩溃，事实上向多种不同处理器结构发展的趋势给开发带来了很重的负担。

系列处理器

在体系结构级上，开发人员正在寻找一系列低成本专用处理器，以用于网络、图象处理和数字信号等应用场合。与采用一种昂贵的通用处理器相比，这类专用处理器能保证提高系统性能，并降低整体成本。不过，对嵌入式系统开发人员来说，有潜力的目标架构的不断增长已对市场上的开发资源和开发能力构成了威胁，因为半数以上的嵌入式产品开发进度都已经拖后了好几个月。

连锁效应

的确，在开发后期发生硬件设计变更，会给采用多种分布式网络处理器的设计带来严重的问题。在传统开发方式里，基础硬件的任何改变都会引起相关软件发生大的变化，这是因为开发人员不能将软件功能与硬件低层之间的联系以及与其它软件组件分开，与硬件相关的通信和控制过程与软件功能紧密结合在一起，所以硬件配置发生任何变化都会要求软件做出大的修改。

除了应对复杂的多处理器结构带来的设计挑战以外，产品开发人员还认为传统的开发方式使他们在开发时有些力不从心。通常采用这类结构的公司都设立独立的开发小组来进行开发，各组负责一种专用类型处理器。在这种情况下，各开发小组在系统级上会缺乏一致的看法，有关系统级的考虑因素常被忽略，或者最多也只能折衷采纳。整个开发会因此受损而达不到最佳状态，由于常常要应付因某个子系统变化连锁影响到另一些子系统而暴露出来的问题，软件复用和转向其它平台的想法也被淹没在实现设计所需的无数琐碎事情之中。

嵌入式系统软件的效率取决于软件功能与实现细节的分离，包括各组件同其它应用组件、服务例程、操作系统软硬件资源等的相互协同关系。Hines-Ortega方法包含了这种将功能与协同分离的思路，为实现功能与交互的分离，该新方法在嵌入式设计中引入了一种更高级抽象概念。新方法为可视化设计、模拟、系统级调试、目标平台选择以及代码合成提供了一种概念性框架。

根据Hines-Ortega方法，开发人员分两个阶段进行嵌入式系统设计，即与目标对象无关阶段和与目标对象有关阶段。在前一阶段中，开发人员将系统设计为一个抽象模型，并对系统模型和运行情况进行模拟和调试，以确保它在模块级运行正确；在后一阶段里，开发人员将经过验证的设计和具体硬件资源联系起来，根据映射模型自动生成针对具体平台的C或Java代码，可以利用现成的代码，并进行正常的单元和系统测试。

能否完成这两个阶段取决于开发人员构造嵌入式系统抽象模型的能力，这种抽象模型将各组件的软件功能行为与描述各组件间相互作用细节的软件交互相隔离。各组件通过相关协同接口进行交互。协同接口又将各组件与协同程序相连，协同程序对组件间可能发生的连接、状态和交换处理等都作了明确的描述。

以协同为中心的处理方法强调松散组合软件组件间的直接协作，而把具体实现的问题向后推，这样软件开发人员就能在系统开发的早期开始设计软件，既与硬件开发同步又独立于具体的实现细节。

实际上，以协同为中心的方法有助于开发人员专注于应用上的问题，而不是实现细节，从而提高工作效率。例如建立一个循环调度程序，开发人员可以做一些通过协同接口与某个协同程序通讯的组件，协同程序包含了所有和循环调度程序协议有关的信息。

按这种处理方法，任何一个组件都无需参照其它组件，事实上各组件甚至都不用知道它们在某个循环协议中正在与别的组件协作。因此开发人员可以专注于应用的要求，而不是纠缠于相互作用协议和实施细节。协同程序本身会处理所有所需的参考信息，如果应用需要改变调度程序协议,变更也只限于协同程序和协同接口。

独立行为

抽象系统模型设计好以后，开发人员就可以通过对模型进行模拟和调试来验证组件功能的协同正确性。以协同为中心的设计具有很强大的系统级调试能力，同时能在系统级观察各软件模块，使开发人员在必要时容易地进入到各层软件找出并解决问题。而最重要的是，这种能力完全独立于实现方法。

这种抽象设计甚至可在不同的多处理器平台或单处理器平台上实现，在第二阶段的最后一步，开发人员将组件和协同程序反映到具体目标平台资源上，如通信信道、子系统和处理器等，代码合成阶段生成针对给定硬件和操作系统的软件，无需中间的软件抽象层。换句话说，生成的软件可直接调用本身的操作系统以发挥出其功能和独特的性能。

这种将相互作用与功能分离的能力使得以协同为中心的方法有别于另外两个常用系统设计方法，即面向对象的设计方法(OOP)和统一建模语言(UML)。

开发人员用OOP定义一组接口，使一个对象在另一个对象前面就像是一组方法或过程。从理论上讲，OOP传统的动态类型检查功能允许对象相互作用而无需事先知道作用规则，但实际上动态类型检查已经让位给静态类型检查以保证相互作用的可预测性。使用静态类型检查就要求对象要包含其它对象使用方法的一些信息。