嵌入系统设计的挑战

嵌入系统设计的挑战

Thomas A. Henzinger 和  Joseph Sifakis  

摘要 我们总结了在嵌入式系统设计中的一些当前趋势 ，并指出它们的特诊，诸如分析和计算模型之间的裂口，安全关键和最佳工程实践之间的间隙。我们对嵌入式系统设计要求有一种一贯的科学基础，而且我们对这样的一个基础讨论了少数关键需求：需要完成若干异质性（heterogeneity）之间的展示。我们相信一个令人满意的的嵌入式系统设计科学之发展将对计算机科学重振来说提供提供一个适时挑战。

1.动机

计算机科学正在进入到一个成熟期。有一种感觉说，许多源于计算机科学所定义的问题要么被解决了，要么需要一种不可预测的突破（比如 P 与 NP 问题）。其是对以下这样一种观点的一个反思，计算机科学研究中许多当前主张的挑战将现存技术推到其极限（比如，语义网【4】；验证编译器【15】；感知网络【6】），将它们推到新的应用领域（比如生物学【12】），或者将它们推到两者的组合（比如，纳米技术；量子计算）。并不奇怪，许多最聪明的学生不再以成为计算机科学家为目标，而是选择直接进入生命科学或纳米工程【8】。

我们有不一样的观点。跟随【18,22】，我们相信计算科学中存在有一大片未知领域。这个领域就是嵌入式系统设计。就像我们将会解释的那样，计算机科学的当前范式不能应用到嵌入式系统设计中：为了涵盖建立在电气工程中的模型和方法，那些范式有待丰富。然而嵌入式系统设计，不应当也不能留给电气工程师（should not and cannot be left to the electrical engineers），因为计算和软件是嵌入式系统的完整部分。实际上，当前设计、验证和维护过程的短处使软件（自相矛盾的）成为汽车、航空航天、制药和其它关键应用系统中有最多耗费和最少可靠性的部分。由于我们日常生活中嵌入式系统的普遍增长，这就对振兴计算机科学组成了一种独特机会。

在下面我们会概括出“作为嵌入式系统设计之挑战”我们所见到的为何。以我们的观念，嵌入式系统设计挑战之浮现不单是由于技术问题，更多而重要的是，这种挑战需要构建一种新的科学基础 —— 这种基础就是，系统性的且 公平的自底向上来对计算和物理作集成(a foundation that systematically and even-handedly integrates, from the bottom up, computation and physicality)【14】。

2. 当前用于系统设计的科学基础，以及它们的限制

2.1 嵌入式系统设计问题

什么是一个嵌入式系统？一个嵌入式系统就是涉及了受到物理约束的计算这样一种工程技术。物理约束是通过两种计算过程和物理世界的交互而浮现的：（1）对一个物理环境的反应，以及（2）在一个物理平台上执行。相应的，物理约束的这两个类型就是反应约束（reaction constraints）和执行约束（execution constraints）。通常的反应约束会说明截止期（deadlines），吞吐量（throughput）以及抖动（jitter）；它们源自系统的行为需要（behavioral requirements）。通常的执行约束在“可用的处理器速度、能量和硬件失效率”上设下了界限；它们源自系统的实现需求（implementation requirements）。反应约束在控制理论中有研究；执行约束在计算机工程中有研究。对计算和两种约束的互相作用获取控制（从而符合给定的需求集合）是嵌入式系统设计的关键。

一般系统设计（Systems design in general）。系统设计是从需求中衍生出来的过程 ，来自“可以或多或少自动的生成一个系统”的一个模型。一个模型是对一种系统的一个抽象表达。比如说，软件设计是衍生一段不能编译程序的过程；硬件设计是衍生一种硬件描述（从其中可合成一个电路）的过程。在两个领域中，设计过程常常是自底向上和自顶向下活动的混合：是重用和对现存组件模型的适用；且是为满足给定需求而对体系架构模型的连续细化。

嵌入式系统设计。嵌入式系统是由硬件、软件和一个环境组成的。这个它们和大多计算系统是共通的。然而，嵌入式和其它计算系统有一个本质不同：因为嵌入式系统涉及到的计算受到物理约束，从物理上（平台和环境）隔离出来的的有力计算（软件），这种计算是使计算科学成为可能的核心概念之一，并不是为了嵌入式系统而工作的。取而代之的，嵌入式系统设计要求一种全体方式，其以一贯的风格对来自硬件设计、软件设计和控制理论的重要范式作出整合。

我们假定，这样的一种整体方式不能简单的只是硬件设计的一种扩展，也不能是软件设计的扩展，而必须基于一种 “将来自这两个世界的技术归入其中”的新基础。这是因为当前用于硬件和用于软件的设计理论和实践都朝向这两个领域的各自属性去裁剪；实际上，它们通常使用的抽象是截然相反的。为了看到这一点，我们现在看一下通常用在硬件设计中的抽象，以及那些用在软件设计中的抽象。


2.2 分析性模型 对比 计算性模型（Analytical versus Computational Modeling）

硬件对比软件设计。硬件系统被设计为互连的内在并行组件的构成。各个组件是通过分析模型（analytical models，方程式）来刻画的，其说明了它们的转换函数（transfer functions）。这些模型是决定性的（或概率性的），而且它们的构成是通过说明“数据流是如何跨越多个组件”来定义的。作为对照，软件系统的是从有序组件来定义的，诸如对象和线程，其结构常会剧烈的改变（组件被生成、被删除而且可能会移动）。其组件是通过计算模型（程序）来刻画的，它的语义通过一种抽象的执行引擎（同样称为一台虚拟机器，或者一自动机）被定义成操作性的。抽象机器可能是非确定性的，而且它们的组件是通过说明“控制流是如何跨越多个组件”来定义的；比方说，独立进程的原子动作可能是交错的，可能是通过同步原语的一个固定集合来控制。

因此，用于构造硬件模型的基本操作就是转换函数之组合；用于构造软件模型的基本操作就是自动机的产生（the product of automata）。就从基本组件构造动态系统而言，这些是两个完全不同观点：一个是动态的（即基于公式的）另一个是静态的（基于机器的）。分析性观点在电气工程中是普遍的；计算性观点，在计算机科学是普遍的：一个电路的网络列表（netlist）是就一个分析模型而言的一个例子；以一种命令式语言写下的任何程序是就计算模型而言的一个例子。由于两种类型的模型有非常不同的长处和短处，设计过程的蕴含是戏剧性的。

分析性和计算性模型提供了正交抽象（orthogonal abstractions）。分析性模型自然的处理并发以及有量的约束，但伴随局部和增加的详细说明（非决定性）以及伴随计算复杂性时它们是困难的。象征性的，基于方程式的模型和相关的分析方法不单单被用在硬件设计和控制理论中，同样还在排产（scheduling）和性能评估（performance evaluation）（比如，联网）中用到。

计算模型在另一方面自然的支持非决定性抽象层级结构，且支持计算复杂性的一种丰富理论，不过它们在训化并发性和吸收物理限制是时是不同的（they have difficulties taming concurrency and incorporating physical constraints）。计算机科学的许多主要范式（比如，图灵机；并发线程模型；编程语言的结构化操作语义）的精确成功是因为，它们从并发的所有物理概念中、从所有在计算上的物理约束中抽象出来（they abstract away from all physical notions of concurrency and from all physical constraints on computation）。实际上，计算机科学的整个子领域的构造和繁荣就是因为这些抽象：在操作系统和分布计算中，分时和并行被抽象到同一个有名概念，即非决定性有序计算（nondeterministic sequential computation）；在算法和复杂性理论中，实时被抽象到 大-O 时间，物理内存被抽象到 大-O 空间。然而这些强有力的抽象大体上对嵌入式系统设计是不足的。

分析性和计算性模型之目标是不同的系统需求。基于方程式的设计和基于机器的设计之间的差异被反映在它们很好支持的需求类型中。系统设计师处理两种需求。功能需求（Functional requirements）说明期望的服务、功能和特征，是独立于实现的。额外功能需求说明主要的性能，其刻画实时使用的效率以及实现资源的使用效率；而且鲁棒性，在异于名义上的一种环境下刻画了递送某些最低功能的能力。就同样的功能需求而言，额外功能属性可有依赖于大量因素和选择的差异 ，包括整体系统体系架构和背后平台的特征。

功能需求自然的反映在离散的基于逻辑的形式体系中。然而，就表达许多额外功能需求而言，需要实际评估量（real-valued quantities）来表现物理约束和可能性。就软件而言，优势驱动器有正确的功能性（the dominant driver is correct functionality），而且甚至性能和鲁棒性是分离说明的（比如，交换的消息数量；忍受失效的数量）。就硬件而言，持续性能和鲁棒性度量是更凸显的，而且涉及到物理资源级别，诸如时钟频率、能量消耗、延迟性、平均失效时间（mean-time to failure）及成本。就集成在大量市场产品中的嵌入式系统而言，在给定技术和经济约束下，量化“性能和鲁棒性之间的权衡”的能力有策略重要性。

分析性和计算性模型支持不同的设计过程。在基于数据流的模型和基于控制流的模型之间的差异关于设计方法有深远蕴含。基于方程式的模型衍生出丰富的分析工具，特别是在随机行为的表现中。此外，如果不同基础构建块的数量是小的（就像在电路设计中那样），那就能证明自动合成技（automatic synthesis techniques）术在设计非常大的系统时非凡的成功，以至于创造了一整个工业（电气设计自动化）。另一方面，基于机器的模型（虽然牺牲了有力分析和合成技术）可以直接执行。它们给了设计师更精细的控制粒度，而且为设计变异和优化提供了更大空间。实际上，健壮的软件体系架构和有效的算法仍旧是分头设计的，不是自动生成的，而这可能在将来某时仍旧如此。因此，强调从设计合（design synthesis）成迁移到了设计验证（design verification）（正确性证明）。

嵌入式系统设计必须平等的对待以下中的两者：平等的对待计算限制和物理限制；平等的对待软件和硬件；平等的对待抽象机器和转换函数；平等的对待非确定性（nondeterminism）和可能性；平等的对待功能需求和性能需求；平等的对待量化分析和性质分析；平等的对待布体系（booleans）和实数。这不可能通过简单的对分析性技术和计算技术作并列来达到，而是需要它们紧密合成到跨越两种角度的一种新的数学基础中。

3. 当前对嵌入式系统设计的工程实践 ，以及它们的限制


3.1基于模型的设计（Model-based Design）

基于语言的和基于合成的起源（Language-based and synthesis-based origins）。历史的来说，对嵌入系统设计的许多方法论追寻到它们的起源是两个来源之一，这两个来源是：位于软件传统中的基于语言方法，和出自硬件传统的合成方法 。一种基于语言的方式是有一个特定目标运行时系统的一种特定编程语言的核心。比如包括 Ada ，更最近的是RT-Java【5】。就这些语言而言，存在导致事件驱动在标准平台上得以实现的编译技术 （有抢占优先的固定优先级排产）。另一方面，基于合成的方法是从硬件设计方法论中演进出来的。它们始于在“一个硬件描述语言的一个易处理（常是结构化的）片段”中的一种系统描述 ，这种硬件描述语言诸如 VHDL 和 Verilog （理想地自动化地）衍生出遵循一给定约束集合的一种实现。

独立实现（Implementation independence）最近趋势是关注基于语言和基于合成方式的组合（硬件/软件 协同设计codesign），而且从一种特定的实现平台上获取（在早期设计过程期间）最大独立。我们将这些共同的新方式称为基于模型的，因为它们强调将设计级别从实现级别分离开来，而且它们环绕的是抽象系统的语义（而非实现语义）。结果就是，在基于模型方式中的许多努力都进入到开发有效率的代码生成器之中。我们这里对一些有代表性的方法论仅提供一个简短和不完整的选择。

基于模型的方法论（Model-based methodologies）。同步语言（诸如Lustre 和 Esterel【11】）在不同种类的软件结构中体现出一种抽象硬件语义（同步性 ，synchronicity）（功能的；命令的）。对若干平台而言（包括裸机和时间触发体系架构），实现技术是有效的。原自设计自动化社区，SystemC【19】同样选择了一种同步硬件语义，但允许从软件中（C++）引入异步执行和交互机制。实现（Implementations）需要硬件里被实现的组件之间的一个隔离，而且那些以软件来实现；不同的设计空间探索技术在做出这样决的分割策中提供了指导。第三种基于模型的方式是围绕一个类构造的，这是一类以MATLABSimulink 为模范的流行语言，其语义是通过其模拟引擎而被定义成可操作的。

更最近的模型语言，诸如UML【20】和 AADL【10】，在它们选取语义时试图更一般化，因此带来了两个方向的扩展：从一种特定编程语言中独立出来，以及将系统体系架构作为一种组织计算、通讯和约束的手段来强调。然而我们相信，这些尝试最终不会符合，除非它们可以吸收基于新的基础性结构来克服当前基于模型设计的弱点：就处理物理限制的计算模型而言，缺乏分析性工具；以及将非计算模型自动转换到有效计算模型中的困难。这把我们导向“为了对异构模型之间的关系和转换有一个更好理解”的那种核心需要。

模型转换（Model transformations）。所有基于模型设计的核心是模型转换的一个效率理论(Central to all model-based design is an effective theory of model transformations)。设计常常涉及到多个模型（在不同的粒度级别表现出一个系统的不同观点）的使用。通常设计进行既不是严格的自顶向下（从需求到实现），也不是严格的自底向上（通过集成库组件）；而是一种更少导向的风格（通过迭代模型构造、模型分析和模型转换）。介于模型之间的某些转换可以自动化；其它时候，设计师必须指导模型构造。在模型转换中的最终成功故事是编译理论（theory of compilation）：今天，对由一个好的优化编译器（其来自一门高级语言写下的程序）产生的代码之手动改进是困难的。另一方面，代码生成器常常产生来自基于公式模型的低效代码：固定点方程式集合可得到迭代计算（或近似），但更有效的算法洞察和数据结构必须由设计师来负担。

就额外功能需求来说（诸如时间），将由人指导的设计决策从自动化模型转换中分离出来甚至还没有得到很好的理解。实际上，工程实践常常依赖代码生成的一种“试错（trial-and-error）”循环 ，测试和再设计跟随其后（比如，当终止期丢失时优先级稍作调整）。一种替换是开发出可以表达反应约束的高级编程语言， 一起的还有“保证反应约束保留在一给定的执行平台中”的编译器【13】。这样的一种编译器必须在由程序说明的反应约束（比如超时）和平台执行约束（典型的以最差情况执行时间形式作提供）之间作调节。我们相信说，这种方式到其它额外功能维度的一个扩展（诸如能量消耗和容错）是一个有希望的调研方向。

3.2 关键的工程 对比 最佳的工程（Critical versus Best-Effort Engineering）

保证安全对比优化性能（Guaranteeing safety versus optimizing performance）今日的系统工程方法论同样可沿着另一条轴线作出分类：关键系统工程（critical systems engineering），和最佳系统工程（best-effort systems engineering）。前者试图不惜任何代价确保系统安全，即便当系统操作处于极端条件之下；后者试图优化系统性能（以及成本），这是当系统在希望条件下执行之时。关键工程将设计视为一种约束-满意度问题（constraint-satisfaction problem）；最佳工程则将之视为一个优化问题。

关键系统工程基于最坏情况分析（即，对系统动力学的保守近似）并基于保留的静态资源。就易处理保护近似的存在而言（For tractable conservative approximations to exist），执行平台常常需要简化（比如，不带操作系统的裸机；允许“代码执行的时间之可预测性”的处理器体系架构）。这种方式的典型例子是在avionics 中的那些用于安全临界系统的例子。实时约束满意度在“最坏情况执行时间和静态排产”的基础上得到了保证。在所有时间都要得到最高必须的计算能力（The maximal necessary computing power is made available at all times）。依赖性（Dependability）主要是通过使用大量冗余及通过部署用于失效侦测和恢复的所有静态设备来达到的。

作个对比，最佳系统工程基于平均情形（而非最差情形）分析之上，而且基于动态资源分配之上。寻求对资源的有效使用（比如，优化吞吐量、抖动或能力）且为“一些退化甚至是临时的服务拒绝是可以仍受的（比如在远程通讯中）”的应用所使用。对关键系统的“硬”最坏情形需求被“软”QoS（服务决绝）需求所代替。比如说，一个硬截止期要么满足要么错过；对一个软截止期，存在一个不同满意度的连续统。QoS 需求可通过适应性（基于反馈）排产机制（scheduling mechanisms）来执行，为优化性能和从名义行为的偏离中恢复，其在运行时调整了一些系统参数。由于承诺策略而使服务可能临时被拒绝 ，从而确保 QoS 级别保持在最小临界值之上。

一个变宽的间隙（A widening gap.）这两种方式 —— 关键工程和最佳工程 ——大体上是分离的。这由“硬”实时和“软”实时之间的隔离得到反映。它们相应于不同的研究团体和不同的实践。硬方式依赖静态（设计时）分析；软方式依赖于动态（运行时）适应。结果就是，它们适应了不同的计算模型，而且使用不同的执行平台、中间件和网络。比方说，对电缆驱动自动系统（drive-by-wire automotive systems）而言，时间触发技术被视为不可或缺【17】。大多数安全关键系统采用非常简单的静态排产原理，要么是带有抢占的固定优先级排产，要么就是同步执行的轮询排产（round-robin scheduling）。常说，对伴有不确定环境的系统来说，这样的一个分离是不可避免的。满足硬约束以及对可用资源作出最可能的使用看起来是两个互相冲突的需求。硬实时方式导致对系统资源的低下使用。另一方面，软方式有临时性不可用的风险。

我们相信（还没有检查过），介于这两种方式之间的间隙将会继续扩大。这是因为在嵌入系统设计中的不确定性由于两个原因在增加。首先，由于嵌入系统被部署在一种有较大差异情形中，这些情形的环境并不很好的知晓，伴以介于最坏情形和期待行为之间的较大距离。其次，因为在大规模集成电路（VLSI）设计中的快速进展，嵌入系统就是在“带有高速缓存、管道和推测执行的复杂软硬件层状多核体系架构”上实现的。精确最差情形分析接着的困难使保守的、关键安全解决方案甚至在资源和设计成本上更加昂贵（和最佳解决方案比较）。关键工程和最佳工程之间的区分常常已导致一个系统的关键和非关键部分之间的物理分离，各自运行专用硬件或各自经历专用的时间槽。由于最坏情形和平均情形之间的间隙在增大，这样的被隔离体系架构可能会变得更加流行。

跨越间隙（Bridging the gap）我们认为说，技术趋势迫使我们修改这种二元观点以及关键性和最佳实践之间的分离。片上系统（system-on-chip）和片上网络（network-on-chip）增加的计算能力允许关键和非关键应用整合到一个单独芯片上去。这减少了通讯成本而且增加了硬件可靠性。还允许对资源有一个更合理而有成效的管理。为达到这一点，我们需要诸方法用于确保一个足够强壮的（但不绝对）共享通用资源的关键和非关键组件间的分离。特别来说，用于适应性系统的设计技术应当通过“利用任何介于硬和软约束之间的互补性”来灵活应用可用资源。一种可能性就是将关键需求的满意度视作最小确保QoS 级别。这样一种方式将（再次）须要布尔值和定量方式的集成。

4. 对一个解决方案的两个需求

异构和构造性（Heterogeneity and constructivity）我们发展一种嵌入式系统设计科学（an EmbeddedSystems Design Science）的愿景是，公正的去集成一个系统之分析观点和计算观点 ，且从方法论上去定量地在关键和最佳工程决策之间作权衡。就设立这样的一种嵌入式系统设计科学来说，需要对待两种相反力量。这些相应于对“在设计过程中涵盖异构并达到构造性”的需求。异构是从带有不同特征的组建构造出来的嵌入式系统的属性 。异构有若干来源和表现（下面将得到讨论），现存知识体大体上分入无关模型和相应的结果中。构造性就是从带已知属性的构建块和粘合组件建造出满足给定需求的复杂系统之可能性。构造性可以通过算法来达到（编译与合成），但同样通过体系架构和设计原则可以达到。

异构和构造性这两种需求从不同方向来拉。围绕异构的是向外看，将这种集成理论朝向“给分析和计算模型之间间隙提供跨越，以及给关键和最佳技术之间提供跨越”的一种统一观点。达到构造性的是向内看，朝向发展一种用于系统构造的易处理理论。由于构造性在受限设置中最容易达到，所以一种嵌入式系统设计科学就给智能平衡（intelligently balancing）和权衡两种抱负提供了手段。

4.1 环绕异构（Encompassing Heterogeneity）

设计师伴随有大量“各有不同特性的组件，从种种观点看，各个都凸显出一个系统的不同维度”的系统。两个核心问题就是有意义的对异构组件进行组合，以确保它们的相应互操作，以及在设计过程中对异构观点进行有意义的精细化和整合。表面分类可以在硬件和软件组件之间作区分，或者在连续时间（模拟）和离散时间（数字）组件之间作区分，但异构有两个更基本的来源：带不同执行和交互语义的子系统之组合；以及对一个系统来自不同视角的抽象观点。

执行异构和交互语义（Heterogeneity of execution and interaction semantics）在语义谱线的一个极端是充分同步化组件，其以带一个全局时钟的时钟步伐进行一致处理，而且在原子事务内交互。这样的一个紧耦合系统对大多数合成化硬件（synthesizable hardware）及对硬实时软件（hard real-time software）来说是标准模型在谱线的另一极端是完全异步的组件，其以独立速度进行处理，而且交互是非原子化的（nonatomically）。这样一个松耦合的组件对大多数多线程软件来说是标准模型。在这两极之间，存在各种中间及混合模型（例如，全局异步局部同步模型  globally-asynchronous locally-synchronous models）。为了更好的理解它们的共性和差异；将来自交互语义的执行解耦是有用的【21】。

执行语义（Execution semantics.）同步执行典型的被用在硬件中，被用在同步编程语言中，被用在时间出发系统中。它将一个系统的执行当做全局步骤的一个序列。它假设同步，意思是说在一个步骤期间环境不会变更，或等价的就是，这个系统的改变要比它环境相应的改变快无限多（the system is infinitely faster than its environment）。在每一个执行步骤中，所有系统组件通过执行某种量子计算(quantum computation)来出力。因此，同步执行范例对公平性就有一种内建的强假设：在每一步中所有组件都可向前移动。异步执行，作为对比，并不使用全局计算步骤的任何主张。异步执行被大多数分布式系统描述语言所采用（诸如SDL【16】和 UML）并为多线程编程模型所采用（诸如Ada 和 Java）。对组件之间共享计算缺乏内建机制，这可通过对排产的约束得到补偿（比如，优先级；适应性），也可通过交互机制（比如，共享变量）得到补偿。

交互语义（Interaction semantics）交互就是系统组件为达到期望全局行为所施行动作之组合。交互可以是原子的或非原子的。就原子交互而言，包括在诸参与组件内的状态变更在和其它交互时是不能被改变的。作为一种规则，同步编程语言和硬件描述语言使用的是原子交互。作为对比，带缓存交互的语言（比如，SDL）和多线程语言（比如，java）一般使用的是非原子交互。两种交互类型都可能涉及强同步和弱同步。强同步交互只有当所有参与的组件都一致时才会发生（比如，CSP集结）。弱同步交互是非对称的；它们只需要一个初始动作的参与，这个动作可能是也可能不是和其它动作的同步（比如，同步语言中的输出）。

抽象的异构（Heterogeneity of abstractions.）系统设计涉及对“那些在各异的细节度上代表一个系统”的模型之使用，而且这些模型在一种抽象（或等价的，纯化refinement）层级上互相关联。异构抽象（其和模型的不同风格相关）通常是最有力的抽象：一个显著的例子就是对用于电路的实值晶体管级模型（realvalued transistor-level models）的布尔值门级抽象（the boolean-valued gate-level abstraction）。

在嵌入式系统中，一个关键抽象就是相关于“应用软件到它的一个给定平台上的实现”的那种抽象。应用软件在其从物理时间抽离出去的意义上来说，大体上是不计时的（untimed）。对物理时间的参考可能会在实时陈述（比如超时）的参数中出现，其被当做外部事件。然而，跑在一给定平台上的应用代码是“可以模拟为一个时控自动机或混合自动机（a timed or hybrid automaton）”的一种动态系统【1】。运行时状态不但包括应用软件的变量，同样含有“所有需要用来刻画其动态行为”的变量，包括时钟变量。模拟实现可能需要额外的定量约束，诸如描述“失效和外部事件达到律则”用的或然率。我们需要找出易处理理论，从而将应用层和实现层联系起来。特别的来说，这样的理论必须提供用于“在实现中保存应用软件的所有重要属性”的手段。

异构在抽象中的另一个原因就是，对模拟一个系统的不同额外功能维度要使用不同的抽象。一些维度（比如在特定集设置中的定时和能量消耗）可能高度相关；另外一些（诸如定时和容错）可能经过独立可组合解决方案是可完成的。一般的，就“分离的正交维度，和介于干涉维度之间的量化权衡 ”而言我们尚缺乏实践理论。

元模型（Metamodeling）我们不是头一个强调需要在系统设计中包含异构的人。相当晚近的强调关注所谓的“元模型（metamodels）”其是用来表达不同模型和它们互操作的语义框架【2，9，3】。我们认为我们需要这样的一种元模型，其不仅是在一个通用（元）语言中的子模型的不相交并集（disjoint union），而且在模型构成期间能保存操作并支持有意义分析及跨越异构模型边界的传输。这就导致了设计中的构造性议题。

4.2 达到构造性（Achieving Constructivity）

系统构造问题可以如下表述：“从来自一给定元件集的满足一给定需求来构建一个系统”。 这是任何工程学科中的一个关键问题；它存在于各种系统设计活动“包括建模、架构、编程、合成、更新以及重用”的基础中。这种一般问题就其本质来说是棘手的。给定一个形式化框架来描述及组合元件，要构造的系统可以刻画为一个“仅当有限状态模型的一个规约是可能时其才是可计算的”单调函数的一个固定点 (the system to be constructed can be characterized as a fixpoint of a monotonic function which is computable only when a reduction to finite-state models is possible)。然而即便在这种情况下，算法的复杂性对真实世界系统也是抑制的。

用于绕开这个障碍的是怎样可能的林荫道？我们需要两个补充方向。首先，我们需要“由需求和约束特定类型以及由组件和构成机制详细类型刻画的”用于详细而受限应用上下文的构造方法。很明显，硬件合成技术、软件编译技术、算法（比如，用于排产、互斥、时钟同步）、体系架构（时间触发，公共签名publish-subscribe）以及协议（比如，用于多媒体同步）都为详细上下文作出了贡献。重要的是要强调说，许多实践上有兴趣结果不太需要计算，而且或多或少是通过构造来保证其正确性。第二，我们需要的理论允许在用于系统构造的一个系统性处理中对上述结果作增加组合（allow the incremental combination of the above results in a systematic process for system construction）。就集成异构模型而言这样的理论将特别有用，这是因为各个子系统的目标可在那些“其最自然的捕获到这些子系统中的每一个”的模型中最有效的来完成。用于递增系统构造的一个结果框架可能采用两种规则。构造性规则（Compositionality rules）从子系统的局部属性中推断出全局系统属性（比如，从个体组件的死锁解放中推断出全局死锁解放）。非干涉规则（Noninterference rules）保证在系统构造过程期间，子系统的所有重要属性得到保存（比如，为用于管理两个系统资源的两个排产算法确立非干涉）。这就为研究提议了以下行动路线。

出于性能和健壮性的构造性（Constructivity for performance and robustness）聚焦必须从仅用于确保函数属性的组合方法和体系架构迁移到额外功能需求，诸如性能和健壮性。

性能（Performance.）核心议题是“控制系统资源的”组件构造（调度程序）从而满足或优化给定性能需求。这些覆盖一大范围的资源相关的涉及“上下界、平均、抖动和或然率” 的约束。通常不同资源的需求是对抗性的，比方说，时间性和能效，或关于截止期和使用最大化。因此我们需要构造“允许对性能需求和权衡分析作联合考虑”的方法。

构造排产程序中的另一个固有困难来自一个系统的执行和外部环境中的不确定性和不可预测性。在此上下文中，就“用在静态排产技术中的时间常量”而言的贫乏决策暗示贫乏性能【23】。一种方式是构造适应性排产程序，其依照它们关于系统环境的知识，通过动态调整它们的排产策略来控制执行。然而，当前还没有“为不同种类资源的用于组合适应性技术”的令人满意的理论 。这样一种方式必须应对关键系统工程的关注，其当前还几乎是排它性的依赖于静态技术。就嵌入式系统科学的预想而言，开发“允许对用于不同资源类的关键和非关键性能需求进行联合关注”的一个系统构造框架是一个主要挑战。

健壮性（Robustness）关键议题是组件构造的性能如同在从常规期望操作环境中分离的环境下所希冀的那样。这样的分离可能包含极端输入量，平台失效以及恶意攻击。相应的，健壮性需求包括属性的一个广阔谱线，诸如安全性[safety]（抗失效），保密性 [security] (抗攻击)，以及实用性 [availability]（资源易得性）。健壮性在系统构造中是一个横贯性议题 ，涉及所有设计活动并影响所有设计决策。比方说，系统保密性必须考虑软硬件体系架构的属性，必须考虑信息处理（加密、存取、传输）就如同必须考虑编程原则一样。构建健壮系统的技术之当前状态仍旧是胚胎。为了严肃的构造健壮系统，需要一个长期而持续的研究努力来开发出一种框架。我们这里的目的仅是要指出一些现存方式的不足之处。

在动态系统中，健壮性可作为一贯性被形式化（robustness can be formalized as continuity），就是说，输入值小的扰动（perturbation）会引发输出值的扰动。就离散系统而言，还没有这样可用的形式化，这里一个单独输入或状态位的变更可以导致完全不同的输出行为。更糟的是，我们用于嵌入式系统的模型中有许多甚至是在连续域中。比如说，在时控自动机中，一个输入在达到时间上的一个任意小的变更都可能会改变自动机的整个行为。

在计算机科学中，冗余常常是从不可靠组件中构建出可靠系统的唯一解决方案。我们需要理论、方法和工具来支持“无需诉诸这样巨大而昂贵的过度工程下”构造健壮的嵌入式系统。一个希望是说，持续性可以在充分量化模型总实现，这里的量化信息不但表达出可能性、时间以及其它资源假设级别，还表达了功能特征。比方说，如果我们不再对绝对（布尔值重要）或失效的非可能性（nonpossibility）可能性有兴趣，而是对失效的适当时间（实数重要）有兴趣，我们就能够构造持续模型，这里在特定参数中的小变更仅包含失效率中的小变更。

递增构造（Incremental construction）就嵌入式系统而言的实践方法论需要缩放（scale）并克服当前算法性验证和合成技术的限制。就达到缩放性而言的一种路线就是依赖组合构造和非干涉规则（compositionality and noninterference rules），其仅需要对整体系统体系架构作轻量分析。这样的通过构造而调整的技术（correct-by-construction techniques）存在于非常具体详细的属性和体系架构中。比方说，时间触发的体系架构对分布式实时系统作及时确保且能容错通讯；一个令牌环协议对连接到一个环的强同步进程确保了互斥。重要的是要通过对介于体系架构和属性之间的综合性交互作更多研究来扩展“通过构造而调整”范例。

通过构造而调整技术的一个相关类被聚焦在组件接口的使用上【7】。一个良好设计的接口恰好暴露出关于“其对检查伴有其它组件的组合性是必须的（which is necessary to check for composability with other components）”的一个组件之信息。在某种意义上，一个接口形式体系就是组件组合的一种“类型理论（type theory）”。最近趋势是面向富接口，其暴露关于一个组件的功能以及额外功能信息，比如说，资源假设级别。就在这种量化约束下的递增设计而言，接口理论特别有希望，这是因为两个或更多接口的组合当运算“被合置起来的基本组件所消耗的资源组合量”时可得到定义。

5. 总结

我们相信嵌入式系统设计的挑战为重振计算机科学提供了一个独特的机会。这种挑战以及因此的机遇，跨越了从理论基础到工程实践的谱线。作为开始，我们需要用于系统建模和分析的一种数学基础，这种基础为了以一致的操作性风格去处理计算和物理限制而整合了抽象机器模型和转换函数模型。基于这样的一个理论，“伴有最佳系统工程来优化性能的实践和健壮性的关键系统来确保功能需求的实践之组合（to combine practices for critical systems engineering to guarantee functional requirements, with best-effort systems engineering to optimize performance and robustness）”就应当是可能的。该方法论理论及工具需要对一个系统的组件涵盖异构执行及交互机制，而且这些机制需要提供抽象　——　在相对那些可被自动化的东西需要人的创造性的设计中隔离子问题的抽象。这种努力是一种真正伟大的挑战：它需要和流行的软硬件设计观点相分离的范例，而且用成本和质量的话来讲它会对我们未来嵌入式基础设计提供潜在奖赏。

致谢（译注：译者略）

参考

【1】R. Alur, C. Courcoubetis, N. Halbwachs, T.A. Henzinger, P.-H. Ho, X. Nicollin, A. Olivero, J. Sifakis, and S. Yovine. The algorithmic analysis of hybrid systems. Theoretical Computer Science, 138(1):3–34, 1995.

【2】F. Balarin, Y. Watanabe, H. Hsieh, L. Lavagno, C. Passerone, and A.L.Sangiovanni-Vincentelli. 
Metropolis: An integrated electronic system design environment.
IEEE Computer, 36(4):45–52, 2003.

【3】K. Balasubramanian, A.S. Gokhale, G. Karsai, J. Sztipanovits, and S. Neema.
Developing applications using model-driven design environments. 
IEEE Computer,39(2):33–40, 2006.

【4】T. Berners-Lee, J. Hendler, and O. Lassila. 
The Semantic Web. 
Scientific American,284(5):34–43, 2001

【5】.A. Burns and A. Wellings. Real-Time Systems and Programming Languages. Addison-Wesley, third edition, 2001.

【6】D.E. Culler and W. Hong. 
Wireless sensor networks. 
Commununications of the ACM, 47(6):30–33, 2004.

【7】L. de Alfaro and T.A. Henzinger. Interface-based design. In M. Broy, J. Grunbauer,D. Harel, and C.A.R. Hoare, editors
Engineering Theories of Software-intensive Systems 
NATO Science Series: Mathematics, Physics, and Chemistry 195, pages 83–104. Springer, 2005.

【8】P.J. Denning and A. McGettrick. 
Recentering Computer Science. 
Commununications of the ACM, 48(11):15–19, 2005.

【9】J. Eker, J.W. Janneck, E.A. Lee, J. Liu, X. Liu, J. Ludvig, S. Neuendorffer,S. Sachs, and Y. Xiong. 
Taming heterogeneity: The Ptolemy approach. 
Proceedings of the IEEE, 91(1):127–144, 2003.

【10】P.H. Feiler, B. Lewis, and S. Vestal. 
The SAE Architecture Analysis and Design Language (AADL) Standard: A basis for model-based architecture-driven embedded systems engineering. 
In Proceedings of the RTAS Workshop( 译注：指运行时抽象服务 Run-Time Abstraction Services 研讨会 ) on Model-driven Embedded Systems, pages 1–10, 2003.

【11】N. Halbwachs. 
Synchronous Programming of Reactive Systems. 
Kluwer Academic Publishers, 1993.

【12】D. Harel. 
A grand challenge for computing: Full reactive modeling of a multicellular animal. 
Bulletin of the EATCS, 81:226–235, 2003.

【13】T.A. Henzinger, C.M. Kirsch, M.A.A. Sanvido, and W. Pree. 
From control models to real-time code using Giotto. 
IEEE Control Systems Magazine, 23(1):50–64, 2003.

【14】T.A. Henzinger, E.A. Lee, A.L. Sangiovanni-Vincentelli, S.S. Sastry, and J. Sztipanovits. 
Mission Statement: Center for Hybrid and Embedded Software Systems
University of California, Berkeley, http://chess.eecs.berkeley.edu, 2002.

【15】C.A.R. Hoare. 
The Verifying Compiler: A grand challenge for computing research. 
Journal of the ACM, 50(1):63–69, 2003.

【16】ITU-T. Recommendation Z-100 Annex F1(11/00): 
Specification and Description Language (SDL) Formal Definition
International Telecommunication Union, Geneva, 2000.

【17】H. Kopetz. 
Real-Time Systems: Design Principles for Distributed Embedded Applications.

Kluwer Academic Publishers, 1997.

【18】E.A. Lee. 
Absolutely positively on time: What would it take? 
IEEE Computer, 38(7):85–87, 2005.

【19】P.R. Panda. 
SystemC: A modeling platform supporting multiple design abstractions.
 In Proceedings of the International Symposium on Systems Synthesis (ISSS), pages 75–80. ACM, 2001.

【20】J. Rumbaugh, I. Jacobson, and G. Booch. 
The Unified Modeling Language Reference Manual.
Addison-Wesley, second edition, 2004.

【21】J. Sifakis. 
A framework for component-based construction. 
In Proceedings of the Third International Conference on Software Engineering and Formal Methods (SEFM), pages 293–300. IEEE Computer Society, 2005.

【22】J.A. Stankovic, I. Lee, A. Mok, and R. Rajkumar. 
Opportunities and obligations for physical computing systems. 
IEEE Computer, 38(11):23–31, 2005.

【23】L. Thiele and R. Wilhelm. 
Design for timing predictability. Real-Time Systems,28(2-3):157–177, 2003.