实时软件分析以及实时软件开发

《实时软件分析以及实时软件开发》由会员上传分享，免费在线阅读，更多相关内容在教育资源-天天文库。

实时软件设计的概念和方法郑泽胜一、实时系统的概念要弄清楚实时系统的概念，必须清楚实时的概念。“实时”是指在规定的时限内能够传递正确的结果，迟到的结果就是错误。举一个典型例子来说明什么是实时系统。例如，一种典型的医疗卫生器械——做心脏病手术的机器人，必须在300ms之内缝合完毕伤口，如果在300ms之外缝合完毕，就可能会导致病人丧生，这样的结果对于实时系统来说是不可接受的。但是对于分时系统，比喻说网络打印排队系统，打印晚了几分钟，则是可以接受的，并无灾乱性的后果。要澄清一点的是，实时系统并不是“快速”的系统。“快速”的说法很笼统，到底什么是“快速的系统”？是1s,100ms还是100us？显然并无定论，所以说“快速”只是一个相对概念。另外，很多实时系统绝对响应时间并不比分时系统快，例如航空订票系统，可能输入后需要等待10秒钟，才有结果送回；但是unix的Shell命令ls-al，敲完命令后，1秒钟之后就有结果送回。但是航空订票系统是实时系统，但是Unix的Shell命令是分时系统。唯一不同的是：实时系统的响应时间是可以确定的——也就是说，无论外界环境多么苛刻或者多么恶劣，航空订票系统都必须在确定的时间内给出响应。但是分时系统的unix终端上键入ls–al，通常1秒钟就会有结果，不过我们偶尔等上10秒也不会有什么很坏的影响。也就是说， 实时系统并非是指“快速”的系统（虽然它们通常都很“快”），实时系统是指有限定的响应时间的系统，这种系统对于事件的响应具有可预测性。同实时系统概念有重叠但不完全相同的还有一个概念，叫“嵌入式系统”。嵌入式系统是指微控制器“嵌入”到仪器设备之内的控制系统，从微电脑控制的洗衣机到洗碗机等等各种信息家电，一直到PC的板卡，各个领域运行着大量的嵌入式系统。绝大多数嵌入式系统同时也是实时系统，对于这些系统，我们有时也称之为“实时嵌入式系统”。需要指出的是，我们使用实时系统这个名词，更多的是强调系统的可调度性以及时间响应的确定性；而我们使用嵌入式系统，更多是强调系统的灵巧性、低功耗。实时系统又可以分为“硬实时系统”和“软实时系统”。二者的区别在于：前者如果在不满足响应时限、响应不及时或反应过早的情况下都会导致灾难性的后果，典型的例子有航空航天系统、医疗器械等。这类系统的时限需求是硬性的，例如，对于医疗器械系统通常的说法是：激光切割流程完毕后300ms必须缝合伤口，以止住流血。而后者则在不满足响应时限时，系统性能退化，但并不会导致灾难性的后果，典型的例子如交换系统。这类系统的时限需求是要保证一个比例满足相应时限要求，例如，对于交换系统通常的说法是：用户拿起话机，交换系统保证95％的概率在300ms内送去拨号音。 二、实时操作系统的一些主要概念1、实时操作系统实时操作系统是指具有实时性，能支持实时控制系统工作的操作系统。实时操作系统的首要任务是调度一切可利用的资源完成实时控制任务，其次才着眼于提高计算机系统的使用效率，其重要特点是要通过任务调度来满足对于重要事件在规定的时间内做出正确的响应。实时多任务操作系统与分时多任务操作系统有着明显的区别。具体的说，对于分时操作系统，软件的执行在时间上的要求，并不严格，时间上的延误或者时序上的错误，一般不会造成灾难性的后果。而对于实时操作系统，主要任务是对事件进行实时的处理，虽然事件可能在无法预知的时刻到达，但是软件上必须在事件随机发生时能够在严格的时限内（系统响应时间）做出响应。即使是系统处在尖峰负荷下，也应如此——系统时间响应的超时就意味着“致命”的失败。另外，实时操作系统的重要特点是具有系统的可确定性，即系统能对运行情况的最好和最坏等的情况能做出精确的估计。2、实时操作系统的发展过程实时操作系统（RTOS）的研究是从六十年代开始的。从系统结构上看，RTOS到现在已经历了如下三个阶段：1)早期的实时操作系统 早期的实时操作系统，还不能称为真正的RTOS，它只是小而简单的、带有一定专用性的软件，功能较弱，可以认为是一种实时监控程序。它一般为用户提供对系统的初始化管理以及简单的实时时钟管理，有的实时监控程序也引入了任务调度及简单的任务间协调等功能，属于这类实时监控程序的有RTMX等。这个时期，实时应用较简单，实时性要求也不高。应用程序、实时监控程序和硬件运行平台往往是紧密联系在一起的。2)专用实时操作系统随着应用的发展，早期的RTOS已越来越显示出明显的不足了。有些实时系统的开发者为了满足实时应用的需要，自己研制与特定硬件相匹配的实时操作系统。这类专用实时操作系统在国外称为Real-TimeOperatingSystemDevelopedinHouse。它是在早期用户为满足自身开发需要而研制的，它一般只能适用于特定的硬件环境，且缺乏严格的评测，移植性也不太好。属于这类实时操作系统的有Intel公司的iMAX86等。3)通用实时操作系统在各种专用RTOS中，一些多任务的机制如基于优先级的调度、实时时钟管理、任务间的通信、同步互斥机构等基本上是相同的，不同的只是面向各自的硬件环境与应用目标。实际上，相同的多任务机制是能够共享的，因而可以把这部分很好地组织起来，形成一个通用的实时操作相同内核。这类实时操作系统大多采用软组件结构，以一个个软件“标准组件” 构成通用的实时操作系统，一方面，在RTOS内核的最底层将不同的硬件特性屏蔽掉；另一方面，对不同的应用环境提供了标准的、可剪裁的系统服务软组件。这使得用户可根据不同的实时应用要求及硬件环境选择不同的软组件，也使得实时操作系统开发商在开发过程中减少了重复性工作。这类通用实时操作系统，有IntegratedSystem（已经被WindRiverSystems公司收购）公司的pSOSystem、Intel公司的iRMX386、ReadySystem公司（后被MicrotecResearch收购）的VRTX32、WindRiverSystems公司的VxWorks、AcceleratedTechnologyInc的NucleusPLUS等。它们一般都提供了实时性较好的内核、多种任务通信机制、基于TCP/IP的网络组件、文件管理及I/O服务，提供了集编辑、编译、调试、仿真为一体的集成开发环境，支持用户使用C、C++进行应用程序的开发。3、实时操作系统的主要研究方向实时操作系统经过多年的发展，先后从实模式进化到保护模式，从微内核技术进化到到超微内核技术，在系统规模上也从单处理器的RTOS发展到支持多处理器的RTOS和网络RTOS，在操作系统研究领域中形成了一个重要分支。今后，RTOS研究方向主要集中在如下几个方面：1)RTOS的标准化研究 如今国外的RTOS开发商有数十家，提供了上百个RTOS，它们各具特色。但这也给应用开发者带来难题，首先是应用代码的重用性难，当选择不同的RTOS开发时，不能保护用户已有的软件投资，RTOS的标准化研究越来越被重视。美国IEEE协会在UNIX的基础上，制定了实时UNIX系统的标准POSIX1001.4系列协议，但仍有许多工作还待完成。1)多处理器结构RTOS、分布式实时操作系统和实时网络的研究实时应用的飞速发展，对RTOS的性能提出了更高的要求。单处理器的计算机系统已不能很好地满足某些复杂实时应用系统的需要，开发支持多处理器结构的RTOS已成为发展方向，这方面比较成功的系统有pSOS+m等。至于分布式RTOS，国外一些RTOS厂家虽已推出部分产品，如QNX、Chorus、Plan9等，但分布式实时操作系统的研究还未完全成熟，特别是在网络实时性和多处理器间任务调度算法上还需进一步研究。2)集成的开放式实时系统开发环境的研究RTOS研究的另一个重要方向是集成开发环境的研究。开发实时应用系统，只有RTOS是不够的，需要集编辑、编译、调试、模拟仿真等功能为一体的集成开发环境的支持。开发环境的研究还包括网络上多主机间协作开发与调试应用技术的研究、RTOS与环境的无缝连接技术等。4）实时系统的可视化建模相对于分时系统以及数据库应用系统来说，实时系统的可视化建模技术是很滞后的。相应地，这也导致了世界范围内大型实时软件开发的严重障碍。统一建模语言UML（UnifiedModelingLanguage™）的出现，给实时系统的可视化建模技术发展提供了一个较好的平台。美国国防部开发JSF战斗机时，估算出JSF战斗机开发过程中大约 需要书写5000万条源码语句，这种惊人的、史无前例的实时软件开发工作量，如果没有可视化建模工具，而延续传统的实时开发方法，基本上是不可能开发出来的。这就促使美国空军资助I-logix公司开发了Rhapsody。通过特有的把UML各类视图映射为具体目标机程序语言的技术，Rhapsody提供给你一个完整的用于复杂实时嵌入式应用软件从分析、设计一直到代码实现和软件测试的开发环境。Rhapsody采用基于UML模型的开发方法，通过从设计模型中直接生成高质量的代码，将开发的重心从编码转移到设计上来，这种自动化的软件开发方法有效的促进了团队合作，极大的提高了软件重用率和代码质量，也大大缩短了整体的开发时间。美国空军的数个外协单位采用Rhapsody作为可视化的建模和开发工具，保证了JSF战斗机的按时交货。4、实时操作系统中的几个重要的评价指标RTOS是操作系统研究的一个重要分支，它与一般商用多任务OS如Unix、Windows等有共同的一面，也有不同的一面。对于商用多任务OS，其目的是方便用户管理计算机资源，追求系统资源最大利用率；而RTOS追求的是调度的实时性、时间响应时间的可确定性、系统的高度的可靠性。评价一个实时操作系统一般可以从任务调度、内存管理、任务通讯、内存开销、任务切换时间、最大中断禁止时间等几个方面来衡量。1)任务调度机制：RTOS 的实时性和多任务能力在很大程度上取决于它的任务调度机制。从调度策略上来讲，分优先级调度策略和时间片轮转调度策略；从调度方式上来讲，分可抢占、不可抢占、选择可抢占调度方式；从时间片来看，分固定与可变时间片轮转。在大多数商用的实时系统中，为了让操作系统能够在有突发事件时，迅速取得系统控制权以便对事件作出反应，所以大都提供了“抢占式任务调度”的功能，也就是操作系统有权主动终止应用程序（应用任务）的执行，并且将执行权交给拥有最高优先级的任务。有两种可以作出精确描述实时应用的时间测定正确性的著名的算法：速率单调：在工作量由一组定期任务组成的应用中，每个任务的执行时间定长，这种速率单调调度算法能够保证其可调度性。速率单调调度算法简单地说就是越是高频地任务安排越高地优先级。因此，在系统中，最高频的任务具有最高的优先级。如果一个应用本来就是就全是定期地或者能够全部变成定期地，那么开发人员实在是太幸运了，因为可以使用速率单调调度算法，并且可以完全正确地断言这个应用能够满足时限。时限驱动：对于一个由定期和不定期任务混合或者任务的执行时长随着时间变化的应用，可以使用时限驱动算法。这个算法的准则是下一个要安排执行的任务是一个时限最早的任务，该任务完成之后，下一个时限最早的任务被选择调度和执行。2 )内存管理：如同分时操作系统一样，实时操作系统使用内存管理单元（MMU）进行内存管理。实时操作系统内存管理模式可以分为实模式与保护模式。目前主流的实时操作系统一般都可以提供两种模式，让用户根据应用自举选择。3)最小内存开销：RTOS的设计过程中，最小内存开销是一个较重要的指标，这是因为在工业控制领域中的某些工控机（如上下位机控制系统中的下位机），由于基于降低成本的考虑，其内存的配置一般都不大，例如康拓5000系列5185板，其基本内存配置仅为256KSRAM＋128KEPROM，而在这有限的空间内不仅要装载实时操作系统，还要装载用户程序。因此，在RTOS的设计中，其占用内存大小是一个很重要的指标，这是RTOS设计与其它操作系统设计的明显区别之一。4)中断禁止时间与中断延迟事件：当RTOS运行在核心态或执行某些系统调用的时候，是不会因为外部中断的到来而中断执行的。只有当RTOS重新回到用户态时才响应外部中断请求，这一过程所需的最大时间就是中断禁止时间。中断延时时间是指系统确认中断开始直到执行中断服务程序的第一条指令为止整个处理过程所需要的时间。实时操作系统的中断延迟时间由下列三个因素决定：——处理器硬件电路的延迟时间，通常这个时间可以忽略。——实时操作系统处理中断并将控制权转移给相关处理程序所需要的时间。——实时操作系统的中断禁止时间。 为了缩短系统对于中断请求的响应时间——中断延迟时间，大多数商用实时操作系统都采用了“可中断式”的核心程序，也就是说，当中断发生时，即便正在执行的是核心服务函数，实时操作系统也能够保证会在一定的时间（也就是实时操作系统厂家公布的实时操作系统的中断延迟时间）内，调用恰当的中断服务例程。当然也有相当多图2-1：非抢占式核心的操作系统的中断延迟时间一般要比抢占式核心长的实时操作系统，例如实时Linux，采用非抢占式的核心程序，也就是执行中的系统核心服务函数不能被其它的程序所中断（注意这与上文所讲述的非抢占式的任务调度不相同，前者的对象一般是应用程序或任务）。在这类系统中，如果系统核心函数服务的对象是某个低优先级的任务，那么即使提出中断请求的是应该拥有更搞优先级的任务，系统都必须等到目前这个核心函数结束后，才能将控制权转移给等待中的高优先级任务。图1 -1表示了抢占式核心和非抢占式核心之间对于中断响应的可能的差别。5)任务切换时间：当由于某种原因使一个任务退出运行时，RTOS保存它的运行现场信息、插入相应队列、并依据一定的调度算法重新选择一个新任务使之投入运行，这一过程所需时间称为任务切换时间。更准确地说，任务切换时间是实时操作系统将控制权从一个任务的执行中取回，然后交给另外一个任务所需要的时间。它包括保存目前正在执行任务的现场信息所需要的时间、RTOS决定下一个调度任务所须的调度时间以及RTOS把另外一个任务调入系统执行所需要的时间。上述几项中，最大中断禁止时间和任务切换时间是评价一个RTOS实时性最重要的两个技术指标。5、实时操作系统的功能实时操作系统应具有如下的功能：1)任务管理： 分时操作系统中的基本调度单位一般是进程（或者线程），而对于实时操作系统，操作系统内核调度的基本单位就是任务。任务一般由任务控制块、程序区、数据区、堆栈区组成，对于多数实时操作系统来说，堆栈一般又分为系统堆栈和用户堆栈，系统堆栈用于任务做系统调用访问系统核心时用到的堆栈，把它从用户堆栈中独立出来，是为了保证系统核心的安全性。任务的驱动一般是基于消息或者事件的，即任务的设计是按照依次处理可能接收到的消息和事件，周而复始轮询循环的。大多数实时操作系统的任务有四种状态：运行(Executing)，就绪(Ready)，挂起(Suspended)，冬眠(Dormant)。运行：获得CPU控制权。就绪：进入任务等待队列。通过调度转为运行状态。挂起：任务发生阻塞，移出任务等待队列，等待系统实时事件的发生而唤醒。从而转为就绪或运行。冬眠：任务完成或错误等原因被清除的任务。也可以认为是系统中不存在了的任务。系统中只能有一个任务在运行状态。各任务按级别通过时间片分别获得对CPU的访问权。实时操作系统一个最重要的功能就是多任务管理和基于优先级的任务调度。2)任务间同步和通信：目前，主要的实时操作系统的任务间同步和通信的机制有：消息、事件、信号量，而部分实时操作系统仍然在沿用邮箱机制，另外一些实时操作系统提供了共享内存的任务间通信机制。消息机制的概念和分时操作系统没有差别，其基本思想是任务通过系统公用的数据交换区（包括私有消息缓冲区和共用消息缓冲池）来交互任务间需要通信的信息。消息机制的系统调用一般包括消息队列的创建(q_create)、删除(q_delete)、接收消息(q_receive )、发送消息(q_send)、广播消息(q_broadcast)、紧急消息(q_urgency)。目前，大多数实时操作系统支持的消息队列既可以是定长的，也可以是变长的。事件机制适用于任务间需要同步，并且通信的数据量不大的情况，一般说来，任务之间的事件通信机制是可以覆盖的，即任务A先后发送三次事件给任务B，如果B还没有来得及处理的话，任务B只需要处理一次事件就行了。事件机制的系统调用一般包括发送事件(ev_send)、接收事件(ev_receive)。目前大多数实时操作系统支持的16－32个事件。如同分时操作系统中的信号量一样，实时操作系统提供的信号量机制也是为了解决对于临界资源共享的加锁机制。信号量机制提供了信号量的创建（sm_create）、信号量的删除(sm_delete)、信号量的P操作(sm_p)、信号量的V操作(sm_v)。实时操作系统与分时操作系统在信号量机制上有一个明显的区别，那就是优秀的商用实时操作系统要解决信号量机制的优先级倒置的问题。3)内存管理：和分时操作系统一样，实时操作系统会借用CPU的内存管理单元（MMU）来完成内存管理，实时操作系统内存管理模式可以分为实模式与保护模式。目前主流的实时操作系统一般都可以提供两种模式，让用户根据应用自举选择。一般说来，实时操作系统的内存管理，还有对于内存的优化分配，以尽量减少整个系统的内存占有量的要求。4)实时时钟服务：目前，商用的实时操作系统在硬件的硬时钟中断的基础上，提供了实时时钟服务。实时时钟是系统调度的基础，也是系统定时服务器的基础。实时时钟服务一般包括定时唤醒(tm_wkafter 或者tm_wkwhen)、定时事件(tm_evafter或者tm_evwhen)机制。另外部分优秀的实时操作系统提供了定时消息机制，即应用任务（比喻说任务A）向系统定时服务器申请定时器，当定时时间到后，定时服务器返回任务A一条消息。相应的系统调用一般有定时器申请(tm_start)，定时器删除（tm_delete）、定时器重置(tm_restart)，定时消息的接收一般采用消息队列的接收机制(q_receive)。是否提供灵活的、高精确度的定时器服务是衡量实时操作系统功能完整性的一个重要指标。5)中断管理服务：如同分时操作系统一样，中断管理服务是操作系统的一个核心和基本的功能。实时操作系统的中断管理有自己的特殊的要求，那就是中断处理程序要更加短小、精悍，以减少中断禁止时间和中断延迟时间。6、优先级倒置发生的条件和解决途径如前文所述，抢占式的结构在降低中断延迟时间上有很大的优势，但是为什么还有许多流行的实时操作系统采用非抢占式的核心结构？原因之一是为了避免优先级倒置失控的问题发生。要了解这个问题，请看如下的情况：高优先级任务H和低优先级任务L要共享一片内存Y，并且都要进行写操作，为了保证数据的完整性，它们需要通过一个信号量S来保证对于内存块的互斥访问。任务M的优先级介入H和L之间。(1)、低优先级的任务L取得了信号量S的所有权—— 即做了P操作，进入关键段，但还没有做V操作；(2)、此时属于另一个高优先级的任务H的中断事件发生，实时操作系统核心通过核心调度，将任务L切换下去，将任务H置为运行态；(3)、H开始执行，到中途需要访问共享内存Y，必须先对S做P操作，因为此信号量目前还没有恢复，于是H阻塞在信号量S上。(4)、L重新取得控制权，并恢复执行；(5)、此时属于另外一个中优先级任务M的中断事件发生，因为M的优先级比L高，于是实时操作系统核心再次将L切换下去，任务M取得CPU的执行权，于是优先级比H低的M可以跳过H直接执行，而H为了等待L所拥有的信号量S，反而无法在M之前取得执行权。当出现这种情况时，就产生了优先级倒置的失控问题，也就是任务H和M所表现的行为就象是它们的优先级被倒置了似的。更有甚者，只要中优先级的任务M不断出现，优先级倒置的现象就不会停止，显然这会使系统的行为变得不稳定又难以预测。 对于任何应用系统来说，如果在优先级不同的任务之间分配系统资源的时候采用的是传统的互斥机制，那么优先级倒置失控的现象都有可能出现。当然，如果操作系统的服务程序设计不良，这种情况也可能出现在操作系统中。例如，如果在一个实时操作系统中，两个高优先级和低优先级的任务企图同时存取某个队列，那么优先级倒置的失控问题也会发生。为了防止优先级倒置的失控问题出现，传统的非抢占式实时操作系统大都尝试在核心结构中避免这种同时抢用系统资源的情况出现；当然，它们付出代价就是任务重调度延迟时间的增加。抢占式实时操作系统是如何避免优先级倒置的呢？思路有两个：（1）利用非抢占的低级服务函数来支援高级的抢占式的服务函数，以避免优先级倒置的失控现象发生。由于这些非抢占式的服务函数的处理都很简单，执行的速度也快，因此可以降低对于任务重调度的延迟时间的影响。许多实时UNIX操作系统都已经使用这种结构，这也包括Mach和Chous等，Microtec公司的高性能通用实时操作系统核心VRTXsa也采用这种结构。（2）采用“优先级继承”的技术。以前面提及的H、L和M任务交互为例，若在其中加入一种信号机制，则整个处理过程就变成如下：(1)、低优先级任务L锁定优先级继承信号量S；(2)、另一个高优先级的任务H出现，并从L手中取得执行权；(3)、H尝试锁定S，不成功被阻塞；操作系统调度核心取得控制权；(4)、调度核心让L恢复执行，并通过S让L暂时继承H的优先级；(5)、其它中优先级的任务M出现，但是无法从L手中取得执行权；(6)、L继续执行，直到它将S的所有权放弃给H，此时调度核心将恢复L到原来的低优先级。 (7)、H恢复执行；(8)、H执行完毕后，M执行。采用优先级继承机制的抢占式的操作系统核心，可以避免优先级倒置的失控问题发生。目前，已经有部分操作系统提供了有优先级继承机制的信号量的系统调用，即开发者开发实时应用软件时可以轻易地透过这一机制，将优先级倒置地问题控制住。例如实时操作系统pSOSystem3.0提供了Mutexsemaphores机制。7、BSPBSP的全称是Boardsupportpackages，即板支持包，说的简单一点，就是一段启动代码，和PC机主板的BIOS的地位和作用差不多，但是一般来说，BSP提供的功能就差得太多。编写8031等8位单片机软件时前面要有一小段程序完成设置栈指针、软复位、中断屏蔽等等操作，称这短程序为BSP其实也是可以的。实时操作系统的BSP一般复杂一点，但一般也是设临时栈指针，之后初始化寄存器（控制外围器件如RAM条，控制I/O口的寄存器）……，再之后是程序跳到实时操作系统内核入口。我们用如下的表来对比实时操作系统的BSP与分时操作系统的BIOS之间的差别。表2-1：BSP与BIOS之间的差别driverdriver||RTOSOS(win9x，winnt..) ^^||BSPBIOS^^||实验板主板PC机的BIOS和操作系统比较独立，BSP和嵌入实时操作系统关系也差不多，只不过写BSP时用一下实时操作系统为你定义好的寄存器比较方便。实时操作系统的driver和PC的driver差不多，一般的RTOS定义了一套自己的driver接口，照着接口写driver和写PC的driver差不多；不过由于RTOS灵活性较大，和硬件较紧密，开发者完全可以抛开它的接口自己写，这和PC机区别可能就大了一点。8、实时操作系统的标准化——μITRON操作系统（OS）技术规范差别之大及使用的微控制器(MPU)品种之繁多，使实时操作系统(RTOS)的标准化成了一个大问题。另外，低档微控制器硬件资源的欠缺，也使软件开发成为难题。设在东京的IndustrialTRON(theRTOSNucleus，实时操作系统中心)或叫ITRON（工业实时操作系统中心），组织制订嵌入式系统RTOS的标准。该组织于1987年发布了第一个ITRON规范，即ITRON1。其后，又着手开发针对8位和16位μC、有较小的功能集的μ ITRON规范和用于32位处理器的ITRON2规范，并于1989年发布了μITRON和ITRON2两个技术规范。μITRON规范是ITRON规范高度伸缩后的一种版本。设计师们不仅在8位μC上而且也在16位和32位μC上实现了μITRON规范OS。ITRON的创始人是想把嵌入式系统的RTOS规范标准化，他们不得不在优化硬件系统和提高软件效率之间权衡。简单地说，用μC构置的系统，由于硬件资源有限，只有在能从可利用的硬件中获得最大收益时，才会使用RTOS。同时，使用RTOS也只是提高了软件的效率。但是，如果想在RTOS提供的更高的抽象服务层上工作，你会发现内核操作的运行时间是硬件功能的大障碍。当然，探讨嵌入式系统中如何在硬件优化与软件效率之间折衷考虑，是一个至关重要的课题。例如，在一个8位的微控制器系统里，一些高级功能，例如存储器库管理功能，几乎都用不上，但却要增加系统软件的开销，并使系统功能降低。在一个以32位微控制器为基础的系统里，这些高级功能通过RTOS就会提高软件效率。ITRON在设计其OS规范时，就考虑到要最大限度地发挥微控制器内所含硬件的功能。尤其突出的是，ITRON规范对应该通过微控制器硬件层次结构标准化的那些特征标志，和应该根据硬件及其功能性质优化判定的那些成份，都做了明确的区分。此外，μ ITRON规范也提到，嵌入式系统对目标代码的兼容性并没有多大需要。另一方面，从学习的角度看，当命名系统调用或其功能时，兼容性却是必不可少的。与其他的RTOS不同，ITRON对各种特征标志都进行了标准化，如任务调度规则、系统调用名称和功能、参数名称（它们的阶级及意义），以及代码（名称及意义）。影响实时功能的问题，如中处理和参数的长度，并未标准化。根据ITRON规范，把由内核程序提供的那些功能尽可能地相互独立，使每个应用程序只选择它需要的那些功能。针对这个目标，大多数μITRON规范的内核都是以程序库格式提供的。你先选择内核功能，运行时再把它们链接到应用程序上。这样，系统就只纳入那些需要的功能。此外，每次系统调用只提供一个单一的功能，以便于只纳入那些需要的功能。μITRON规范包括许多特性，其中包括处理器的层次结构不是虚拟的。虽然ITRON规范的OS运行在不同的处理器上，但是标准并没有把不需要的运行条件虚拟化，因此，可以使处理功能更高。μITRON规范也规定了高速响应问题。影响实时应用中响应时间的那些因素，一般都与作业转换功能和中断处理例行程序有关。ITRON规范规定，在规定的高速作业转换时间上，可以将寄存器换出。也可以在发生外部中断时，旁路RTOS以启动运行一个中断处理程序。根据NEC公司V800系列工具高级技术应用工程师DavidEasler的观点，μITRON处理内核程序调用的方式有利于加快响应时间。他还认为，μITRON与其他RTOS之间的基本差别在于，其他RTOS用软件中断来自内核程序库的调用功能；μITRON则是规定使用标准的C-格式调用。把层次结构与执行过程分开，μ ITRON所提供的方法就优于其他的RTOS；如果用户要改变既定层以下的执行过程，你可以继续使用既定层以上的规范而不用改动。同样，μIRTON也把自己限定为层次结构式的规范。作为开发者，你有充分的自由去运行你选定的应用程序。这样，μITRON标准就为公平的技术竞争提供了一个层次施展的空间。为了使ITRON规范易于学习和消化，开发者作了大量艰苦的努力。例如，ITRON委员会系统地定义了ITRON规范的系统调用名称和功能，使它们便于记忆。所有的ITRON系统调用都是七个或八个字符长，形式分别为xxx-yyy和zxxx-yyy。xxx部分代表运算方法，yyy则代表运算目标（图1）。在八个字符的系统调用指令中，Z代表从无Z的七个字符系统调用指令中导出的系统调用指令。Easler认为，学习μITRON和学习C语言一样并不复杂，因为开发者用不着变换处理器，或学习其他RTOS厂家调用各种信箱序列，或其他RTOS如何处理缓冲器。根据ITRON技术规范，“任务（task）”这个术语是指并行处理的一个单元。在单一任务内的诸多程序是按顺序执行的；多任务的诸多程序则是并行执行的。ITRON规范采用优先权调度方式。每项任务都被指定一个优先级；优先数值越小，优先级别越高。ITRON规范采用一个叫做任务身份证（ID）的号码指定作业。任务控制块（TCB）含有用以管理作业的信息。ITRONOS规范通过系统调用指令按TCB的数值来处理设定和修改。在μ ITRON的概念里，资源是执行一项任务所需要的某种要素，各种资源是执行一项任务所需要的不同要素。所谓资源包括硬件（如处理器、存储器和I／O器件）和软件（如各种文档和程序）。ITRON规范提供专门用于指定资源的同步和通信功能。根据μITRON规范包括五种作业状态：运行、准备、等待、静止和非存在（虚拟）状态。为了便于程序的开发，ITRON规范对任务用以控制其本身的系统调用指令与作业用以控制其他任务的系统调用指令，作了明确的区分。这种方法阐明了作业状态的过渡，并使系统调用简明易懂。根据ITRON规范，一个目标就是系统调用指令要加以处理，也是你用ID号做出识别的任何项目，例如一项任务。除各种任务外，目标还包括同步和通信机制，如存储器库、事件标记和信箱。OS对每种目标提供目标管理表（例如，对各种任务提供TCB）。μITRON3.0规范把系统调用分为三级：R级（LevelR），即要求级；S级（LevelS），即标准级和E级（LevelE），即扩展级。除这三个级别外，还有C级（LevelC），用于处理与CPU相关的系统调用。R级涉及的是实施μITRON3.0规范所需要的各种功能。S级覆盖实现实时、多任务OS的各项基本功能。E级包括各种附加的和扩展的功能。这个级包括目标生成和删除功能、各种聚集功能、存储器库和定时器处理程序。与CPU相关的C级在CPU的基础上，提供要关硬件的各种功能。μITRON规范的内核在低档微控制器中，尤其能够发挥作用。这些器件以前受存储器和执行速度的限制，不能使用RTOS。μ ITRON处理进程提供了相当大的优势，而且在8位和16位微控制器中，正日益变成首屈一指的标准内核规范。对μITRON的支持也来美国的部分厂家。例如，Cygnus公司除了本机内核应用编程接口（API）外，还提供该公司带μITRON3.0兼容API的嵌入式CygnusOS(eCos)。有了μITRON兼容的API，eCos就能植入并反复使用μITRON应用程序。值得注意的是，eCos是一个开放式的源OS，而且Cygnus公司还将提供eCos的源代码、GNU编译程序及排障调试程序（www.sourceware.cygnus.com）。工业界的许多专家认为，Cygnus公司的这一举措会造成μITRON标准的迅速扩展。NEC公司提供与μITRON兼容的RX850RTOS，与该公司的NECV850／E系列微处理器一块儿工作。RX850RTOS工具组包括一个RTOS任务识别调试程序，可显示状态的过渡。用RX850RTOS工具组，通过验证事件状态的过渡和观察中断事件定时及功能线索持续时间，对系统的功能进行分析并画出轮廓曲线。利用RD850任务调试程序，还可以观察各种OS资源，如各种任务和信号量，以及系统缓冲器和队列。当你将其用于运行在25MHz的NECV851微处理器上时，RTOS内核的二进制代码占用3k～8k字节。其作业转换时间最快为1-3μS，最慢为5μS。RX850是许可证经营的RTOS，所以你要装多少器件，就付多少相应的费用。RX850的起价为800美元。AcceleratedTechnologyInc(ATI)将其实时内核程序、NucleusPlus，纳入μ ITRON接口标准，使其用户能自由地将其传统的应用程序转给任务数号的CPU，还有免费提供专利源代码的好处。该公司计划将其内核程序植入日立公司SH系列的处理器。许多迹象表明，μITRON有潜力变成嵌入式RTOS的世界标准。CygnusSolutions公司工程部主任PaulBeeskens认为，ITRON应摆脱其仅瞄向日本的做法，更国际化一些，则很有机会真的成为世界标准。Beeskens还认为，“ITRON应当提供可广泛选择的英文文件和技术信息”。即μITRON委员会必须扩展以纳入更广泛的国际支持者，例如，标准用英文开发，而且在开发时就应该能提供。NEC公司的Easler认为，美国的嵌入式市场对高功能、存储器覆盖区小的OS，没有通用的标准。对较大覆盖区的OS有一个标准，如Posix需要大量使用存储器的许多相符数据和API。（μITRONRTOS适合16k字节的存储器）。同时，这个标准也定义了调用各种功能的方式，以及内核程序运行作业的方式。Easler还认为：“虽然这种标准化是宽松的，但μITRON的定时是决定性的，而Posix却并不严格”。GrapeSystems公司销售工程师KojiMugita认为：“通过平台可快速移植和使用方便，是μITRON的最大优点。由于嵌入式软件行业非常分散，在全世界有50多个软件厂家，有一个像μITRON这样的标准，就会使嵌入式软件产品的开发者，稍加修改就可以把软件用于以后的应用中，而无须考虑他们使用的是什么样的微处理器。”μITRON的主要缺点是效率欠佳，另外就是主流的通用实时操作系统还没有支持它的迹象。 三、实时系统需求分析、设计方法综述以及实时程序设计1、实时系统设计的一些基本问题实时系统具有以下一些特点，从而区分于其他系统：与外部环境交互：实时系统通常需要与外部环境进行交互，例如，可以控制机器及生产过程，或者监控化学反应并随时汇报危急情况，这种情况通常需要从外部接收数据并提供输出和控制外部环境。时限响应：实时系统对紧急事件必须在确定的时限那给出响应，无论现在的系统是否处于峰值处理状态。实时控制：实时系统经常包括实时控制，从接收到的输入数据中做出控制决策。“反应”系统：很多实时系统都是“反应”的系统，也就是说，由事件驱动并且必须对外界事件进行响应。并发处理：实时系统通常需要处理不同类型的任务：一类是周期性任务——按照固定时间间隔执行的任务；另外一类任务是非周期性的，常常是随机性任务——要求在任务出现的任意时刻能进行相应处理。一般对非周期性任务的处理都有响应要求，这样当新的事件到来时，即使系统正在处理别的任务，也必须及时响应，从而导致需要并发地处理多个相互竞争地请求。 实时系统与周围环境有密切联系，因而可能造成处理机负荷过载。在过载情况下，一般允许系统性能合理降级。由于资源有限，导致有些任务必须等待处理，甚至造成任务丢失。因此，最简单地实际处理方案可以将任务按重要性分为关键、基本、不重要等级别。关键地任务必须达到时间限期要求，需要优先处理；基本任务也有时间限期，但达不到要求关系不大，则可稍后处理；不重要地任务理论上可以无限期等待。这样，许多情况下只要能够做到关键任务集的规模合理，往往可以在有限资源条件下，保证关键任务完成的前提下达到系统目标。但是，在一些复杂的环境中，在无法用这种简单办法来解决问题时，就需要仔细分析系统的特性，进行有效设计以保证所开发的实时系统的目标。而实时系统的设计有自己的许多如上所述的特点，一般系统的设计或开发方法尚不能解决实时系统中的并发处理、时限响应等问题。所以，对于实时系统，有必要研究其专门的一些分析、设计和开发方法。2、实时系统设计的一些基本概念与一般的系统设计一样，实时系统软件也包括一些和一般系统相同的分析和设计概念，这里就不再讨论。下面给出几点对于实时系统设计有特别重要意义的概念：有限状态机（FSM）： 很多实时系统，特别是实时控制系统，其整个分析机制与系统的状态有相当大的关系。有限状态机由有限的状态和相互之间的转移构成，在任何时候只能处于给定数目的状态中的一个。当接收到一个输入事件时，状态机产生一个输出，同时也可能伴随着状态的转移。主要有两种方法来建立有限状态机，一种是“状态转移图”，另一种是“状态转移表”，分别用图形方式和表格方式建立有限状态机。实时系统经常会应用于比较大型的系统中，这时采用图形或表格方式对理解复杂的系统具有很大的帮助。并发任务：实时系统通常都会有很多事件同时产生。一个任务描述一个事件，整个系统的并发机制是通过让很多任务并行运行而实现的。一个强调并发任务的系统设计通常都会显得更加清楚并且易于理解。信息隐藏：信息隐藏是一个与各种系统设计都有关的设计概念，其原则是每个模块应该隐藏可能会做改变的设计结果。采用信息隐藏的优点是使模块可供修改，易于理解，因此增强了软件的可维护性。3、实时系统分析和设计常用的方法首先要区分两个不同的概念：系统分析和系统设计。系统分析指的是由用户提供的，说明软件系统应该做什么以及需要在什么环境下运行等情况的方案；系统设计则是指那些由系统分析员或设计者提供的描述软件系统如何实现这些需求的方案。在实时系统的设计中，系统的瞬时表现是最难描述的，但同时也是最重要的因素。以下讲述的传统的实时软件分析和设计常用的一些方法。语言描述及数学分析：在系统分析和设计中，语言描述是不可缺少的，但其功能也只是对其他方法提供的分析和设计进行补充。在系统分析中，也可以采用数学分析来描述对系统功能的需求。数学分析是一种精确而有效的方法，对系统性能的优化可以通过优化相应的数学模型而获得，但在大系统中，其作用相对受限。 流程图：流程图也许是最早出现的软件系统模型，而且也有着很广泛的应用，因此，简单的系统可以采用流程图来进行建模。流程图适合指令不超过5000到10000条的系统。在多任务的系统中，流程图可用来对各个任务进行分别描述，但是进程之间的交互就不太容易描述，同时也无法描述其瞬时的表现。结构图：结构图是一种广泛采用的、用以描述系统模块结构的方法。结构图从左到右代表了执行的顺序，从上到下代表了程序模块的细节化。结构图可以在相当多的计算机科学的文献以及其他描述系统的文章中见到。伪代码和编程设计语言(PDL)：编程设计语言与伪代码只有细小的差别。编程设计语言是一种与系统运行的底层硬件环境相分离开来的抽象语言，它以一种类似于真正的编写代码的方式来说明系统。ADA就是一个成功应用编程设计语言的例子。使用编程设计语言或伪代码的好处是，它们比直接应用语言来描述系统需求更抽象，而同时比前述所有方法都更接近实际的编程语言。有限状态机：有限状态机是实时系统设计中的一种数学模型，是一种重要的、易于建立的、应用比较广泛的、以描述控制特性为主的建模方法，它可以应用于从系统分析到设计的所有阶段。有限状态机的组成如下：（1）一个有限的状态集合Q （2）一个有限的输入集合I（3）一个变迁函数δ：Q×I→Q，变迁函数也是一个状态函数，在某一状态下，给定输入后，FSM转入该函数产生的新状态。δ是一个部分函数，它的定义域内的某些数值可以是未定义的。有限状态机通常用图的方式来表示，其节点代表状态。若在输入I下状态由q1转变为状态q2，则有一条标有输入I的弧线从状态q1指向q2。此时，其变迁函数δ(q1，i)=q2。图１示意了一个简单的有限状态机。图3-1简单有限状态机图3-1中的左图表明该FSM有q0、q1、q2、q3四个状态，输入集中有a、b、c三个元素。有限状态机非常适合于描述这样的系统：系统含有有限个状态，不同事件的发生（以不同的输入符号来表示）可以用不同状态之间的转换来模拟。举例来说，一盏灯可以是开着的，也可以是关着的，“开”与“关” 都是指状态；还可以通过某种外部的控制（如按一下开关）使灯的状态从开变换到关，而我们在按一下开关就会导致反方向的状态变换。我们可以用图3-2中的有限状态机来描述这个简单的系统。根据控制系统的不同要求，我们可以利用有限状态机来的方法建立不同复杂性的模型。图形3-2：灯的有限状态机总的来说，有限状态机的优点在于简单易用，状态间的关系能够直观看到。但应用在实时系统中时，其最大的缺点是：任何时刻系统只能有一个状态，无法表示并发性，不能描述异步并发的系统。另外，在系统部件较多时，状态数随之增加，导致复杂性显著增长。为了消除这些缺点，一些新的方法应运而生。下面将介绍的Petri网就是其中一种，与FSM相比，它具有更强的建模能力，并能描述系统的并发、异步、同步等特性。Petri网：Petri网是一种使用图形方式对系统进行需求规格说明的技术，用来定义多进程、多任务系统的数学模型，易于描述系统的并发、竞争、同步等特征，并可用于评价和改进系统。如今，Petri网已经大量应用于包括硬件、软件和社会领域等各种系统的模型化。类似于有限状态机，Petri网也是通过一些定义好的状态来描述事物的抽象的虚拟机。但与FSM相比，Petri网不仅能描述同步模型，更适合于相互独立、协同操作的处理系统。Petri网的组成成分包括： (1)一个有限的库所（place）集合，表示系统的状态。(2)一个有限的变迁（transition）集合，表示系统中的事件。(3)一个有限的连接库所到变迁或者反向的有向箭头的集合，又分输入(input)和输出(output)。Input表示变迁/事件的前提，output表示变迁/事件的结果。图3-3为一Petri网示例，图中的库所用圆圈表示，变迁由矩形表示。Petri网有如下特性：(1)状态：通过标记Petri网的库所来给出其状态，标记Petri网的库所在图形中表现为对库所插入数目不同的令牌。(2)状态变化规则：一个变迁可以有多个输入或输出库所，如果一条有向箭头是从库所到变迁，则该库所是该变迁的一个输入库所，反之则为输出库所。如果一个变迁中每一个输入库所都至少有一个令牌，则称该变迁是一个使能变迁。(3)点燃：一个使能变迁可以被点燃，即从该变迁的每一个输入库所中移走一个令牌，在该变迁的每一个输出库所中增加一个令牌。 图3-3Petri网示例图3-3中，库所中的星号代表令牌。由(a)中可以看出，变迁t1和t2都是使能的，(b)表示了点燃t1的过程，(c)表示了点燃t2的过程。从这个模型中可以看出，在给定初始令牌后，Petri网的发展过程可能是不同的。在Petri网中，经常利用变迁来模拟一个事件，而点燃则用来表示事件的发生。这样，如果一个变迁所表示的事件的发生条件是满足的，那么这个变迁就是使能的，库所中的星号标记则说明某个条件是满足的。图3-3中的Petri网可分为两部分，一部分是由变迁t1、t3组成，另一部分由t2、t4组成，这相当于是两个独立的工作流，并且共享了资源p3。开始时，双方可以互不干涉地、异步地进行，因为变迁t1和t2双方互不妨碍。点燃t1后，t3处于使能状态，点燃t2后，t4处于使能状态。在两个变迁都点燃后，两个工作流都有新的变迁处于使能状态，但是这两个变迁的点燃处于竞争状态，两个工作流中只能有一个获得p3的资源从而得以继续变迁。如果资源满足的情况可以解决这种冲突，就可以设p3的令牌有两个，两个工作流就互不干扰，可以并发执行。 数据流图：数据流图主要是作为软件系统建模中的结构化分析工具。建立数据流图从分析系统的功能需求开始，分析系统中的数据流并且确定主要的函数。数据流图需要细分系统和子系统，从而在图中对数据流有清楚的表现。控制流图是一种在系统中实现控制信号流的数据流图。这些控制信号能够描述离散的从开关或感应器得到的信号数据，同时也能包含从离散时钟得到的离散的定时信息。数据流图和控制流图结合使用，可以提供更具控制性的信息。总体来说，数据流图特点是：强调数据的流动，不太强调控制信号的流动，对于确定并发性很有用。实际上，如果缺少了并发性的特点，数据流图就是有限状态机。数据流图最主要的缺点是描述同步很困难。数据流图容易理解，应用广泛，通常是和一些其他方法结合使用来产生连贯的软件需求文档。表3-1给出了上面讲述的各种系统分析方法的优缺点的对比。表8-1：系统分析方法的对比方法优点缺点语言描述广泛应用，能起说明作用。不够明确，无法相应产生代码。数学分析精确，是一种正式的分析方法，可在此基础上进行代码优化。难于应用，并非很多系统设计人员都能够通过数学方式对系统分析。流程图广泛应用，对单任务系统非常适合。没有并发处理，不能表现瞬时状态，多采用GOTO语句。结构图广泛应用，适合于小系统，鼓励自顶向下的设计方式。没有条件转移，没有并发处理，不能表现瞬时状态。伪代码和PDL与编程语言接近，是正式应用的分析和设计方法。容易出错且不易发现。有限状态机广泛应用，易于建立，方便于代码产生和优化。没有并发处理，随着状态的增加系统复杂性显著增加。Petri网广泛应用，适合于多进程处理，对并行性有很好的表示。应用于过小的系统时显得不必要。 数据流图广泛应用，并发处理，易于理解。不易于表示同步性4、实时系统的并发并发(concurrency)是实时系统的一个重要特征。在实时系统中，外部事件在任意时刻都可能出现，有时甚至会同时出现，必须保证在规定的时间期限内及时处理。多个事件可以列入队列进行调度，或依次顺序处理，或并发处理。并发处理具有以下明显优越性：·可以有效利用硬件资源；·帮助程序设计员将一个程序分解为几个不同的活动，而不必考虑这些活动的具体执行顺序；但是，并发常常会给处理带来一些难以解决的问题。下面我们举例说明：见图3-4，假定系统S有以下特性：(1)系统S能够响应两种事件E1和E2。(2)系统能够执行四个原子操作：T1、T2、T3和T4。原子操作是指操作不再可分割。(3)每个原子操作需要一个单位时间。(4)在响应某个事件时，将执行一系列顺序操作，顺序操作执行的第一个操作最关键；系统必须在事件发生后的一个单元时间内开始执行该操作，并必须在该事件发生后两个单位时间之内完成。顺序执行的操作系列之间相互独立。(5)系统S响应时间E1时，顺序执行三个原子操作：T1、T2和T3，且在事件发生之后6个单元事件内完成T3操作。 (1)系统S响应事件E2时，顺序执行两个原子操作：T4和T2，且T2操作必须在事件发生之后的4个单位时间内完成。对于系统的外部环境，存在如下情况：（1）在时刻0，事件E1发生。（2）在时刻1.5，事件E2发生。（3）在时刻3.5，事件E1发生。以上系统必须同时响应多个事件，执行多个操作系列的情况，称为并发。理想并发(ideallyconcurrent)是指事件发生后，系统立即响应，执行相应的操作序列；且多个事件发生时，可以同时执行任意多个独立操作序列。见图3-5。然而理想并发只是一种理想化处理，一般系统只有一个处理器，一次只能执行一个原子操作。在这样的系统中，实际上不可能处理任意数量的并发操作，操作必须顺序执行。但若按先进先出的策略执行操作，结果将如图3-6所示。在时刻1.5发生的E2事件，必须到时刻3以后才能获得处理器；在时刻3.5发生的E1，至少要到时刻5才可能获得处理器；因而系统无法达到规定的时间要求。为达到时间要求，系统必须在一个操作执行结束后，打断正在执行的操作序列，转而处理另一操作序列。如果能够合理地安排以适当延迟前一个操作，往往可以达到时间要求。这种利用延迟机制来满足并发要求地情况称为准并发(quasi-concurrent)，见图8-7。 5、面向对象的并发模型概述在采用面相对象开发方法处理实时系统时，最困难的问题是如何把对象概念与并发概念结合起来。可以通过某些对象来组成实时软件。实时系统的基本工具包括：协作进程，中断服务例程，实时时钟和物理输入输出设备。还有一部分“纯实时软件”，它不使用进程，而利用同步技术，即在程序执行前固定和决定进程调度。更加灵活的异步技术可应用于实时和面向对象相结合的领域，但是，使用进程会限制快速响应方面的要求。可以通过改变进程的优先级或把进程迁移到其他的处理器，从而调节系统性能来影响系统的响应性能。有关系统在实时方面的问题有以下几点：·粒度大小。·协作软件间的优先级。·中断服务例程：控制和处理某优先级的硬件中断激励。·实时时钟：可用来触发进程切换和调整进程队列。· 与进程和物理分布相关的其他复杂问题，如调度、优先级、进程间通信、进程中断、服务例程通信、错误检测和恢复、进程破坏和清除、共享资源保护等等。这些问题将严重影响设计者在设计过程中对软件的考虑。设计者必须在某种程度上时刻考虑粗粒度行为模式，以保证整个软件正确地调度性能与健壮性问题。这将是复杂地，因为一个进程可能被比它优先级高的进程打断，后果可能是在一系列的进程上同时传播许多激励，进而可能影响性能和健壮性。为了尽量减少产生错误的可能性，设计者和实现者倾向于使进程相对具有较粗粒度，进程数量相对少，进程结构相对静态；使得实时结构和代码结构尽量吻合，把实时问题直接反映到代码中。在面向对象方法方面，作为类继承体系的代码结构提供了其他编程技术无可比拟的复用性和可扩展性。几组对象通过负责过程间通信的类动态建立实时结构。动态绑定技术可以避免让代码中固定的结构承担过多责任，以提高类的可扩展性，进而提高可用性。但许多动态绑定的细粒度代替进程，导致出现了较多的细粒度对象。这样，动态实时结构和类继承的静态代码结构不一致，就难以通过代码了解系统行为，即难以看到相对高层的实时动态结构——粗粒度行为动态模式。因此，我们必须建立面相对象的实时模型。面向对象的实时模型分为两种：显示并发模型和隐式并发模型。 隐式并发模型的特点是推迟并发设计。它把对象模型作为建模基础。在进入运行阶段之前，将对象看成自主单元，各种对象的活动看成是以理想并发方式完成特定的工作。好似每个对象都拥有一个自己的处理器，这个处理器为对象提供了一个执行线程。进入系统的外部事件被看成一个处理请求，以广播方式传给一些对象，这些对象接着向其他对象进一步提出处理请求。理论上，对应一个请求，可以有任意多个对象执行相应处理。在实现时，由调度程序最终处理其对象的操作顺序。显式并发模型则首先考虑并发。应先把并发概念与对象分开。在建立对象后，用实时操作系统支持的进程概念来表示并发，形成了对象和进程两个抽象层次，即先将系统分解为准并发进程作为开始，而在每个进程内部采用面向对象的技术。对象间交互表示成嵌套的函数调用；通过加入锁、监视器、信号量等显式同步机制，来保证对象的完整性。因此我们说，显示模型和隐式模型的区别就是对象和进程结合的事件早晚不同。显示模型较早实施结合，在分析阶段，就要考虑并发问题，设计阶段任务轻松了。且通过将进程置于对象之上，对象中不必考虑并发，对象串行化。其缺点是需要较早决定把应用分解为进程的方案。隐式模型则可推迟考虑并发，在分析阶段，只考虑对象模型，而不考虑并发，但在设计阶段必须考虑进程结构，解决同步问题。显示并发和隐式并发的并发模型见图8-7。 图8-7：面向对象的并发模型实际问题往往非常复杂，应认真考虑对象方案。从并发的程度来看，我们可提出三中并发的级别：·低级并发：每个对象的执行保持完整，对象依次交互，并发工作。·中级并发：对象的操作可以中断，不同对象之间发生并发。·高级并发：同一对象内部各操作之间发生并发。越高级的并发处理越复杂。要解决并发的实时问题，可采用以下方法：·对已有的面向对象语言进行扩充，使之支持并发机制。·对已有的面向对象语言，增加实现并发机制的类库。 一般说来，并发机制可以解决实时系统的问题，但是数据的一致性（同一个对象上，两个并发请求访问同一数据时带来的不确定性）和同步问题会给问题的处理带来极大的困难。应该尽量避免高级并发，即避免对象内部的并发，使对象内部各操作互拆，以简化问题。6、面向对象的实时系统设计方法——OCTOPUS概述面向对象技术在实时系统设计中的应用目前仍然有限。因此对诺基亚公司在移动通信系统软件的设计开发中国中提出的OCTUPUS方法所获得的成就，Awad等人进行了总结，较为全面地归纳了面向对象地实时系统设计方法。这可以说是一个开创行动，很有启发意义。OCTPUS方法的命名是基于该方法设计多方面的技术，博采众长，像章鱼似的有多个触角。OCTOPUS方法，以对象模型技术OMT(objectmodelingtechnique)和熔合方法(thefusionmethod)为基础。OMT的对象模型符号可以简洁地表示必要细节，将结构、功能以及动态模型分开使系统易于建立、便于理解。而Fusion方法地可借鉴之处在于在分析阶段侧重描述外部行为，而在设计阶段侧重描述应用系统内部行为，使得不同阶段重点突出。OCTOPUS方法不仅尽最大可能保留了OMT合Fusion方法地长处，还提出了对实时系统响应行为、时间域以及并发地处理方法。具体有对并发、同步、通信、中断处理、ASIC、硬件界面、端对端响应时间等方面地处理。这里只对其设计方法做描述。 OCTOPUS方法将软件开发的主要阶段很好地结合起来，从规格说明到运行，模型之间过渡紧密自然。它还支持渐增式软件开发。OCTOPUS方法也支持异构软件开发，使面向对象地部分成为整个非面向对象系统地一部分。它将传统地实时操作系统作为运行平台，通过系统有效的步骤将对象映射到进程，从而解决了将进程与对象结合起来的难题。因而OCTOPUS方法当前是一个将面向对象与实时系统相结合的较好方法。从系统角度来看，OCTOPUS在系统、子系统、类、对象抽象层次上建立结构模型、功能模型和动态模型，这些抽象层次分布在各个不同的开发阶段。图8-8：OCTOPUS方法的软件系统开发过程结构系统规格说明阶段见图8-8、表8-2，通过上下文图表示系统环境，通过一系列使用实例(usecase)的图形文字表示系统功能和动态行为。使用实例可以补充以系统与环境之间的场景来表示动态行为。系统各部分在考虑使用实例阶段基本上可认为是黑盒子。表8-2：OCTOPUS概貌抽象程度开发阶段结构模型功能模型动态模型系统(问题域)系统规格说明书系统环境图系统使用实例图/全部使用实例系统使用实例图/全部使用实例(场景) 子系统系统体系结构子系统图在子系统分析功能模型中说明在子系统的分析动态模型中说明类子系统分析类图和类说明书子系统操作表单子系统事件表/事件组图/事件表图/状态图/活动表/重要性程度表/(复合事件)/场景对象子系统设计类大纲/进程大纲/进程间消息大纲成员函数大纲(并入在结构模型中的大纲中)对象交互线程/事件线程/对象组系统体系结构阶段，由子系统图描述系统结构，标出子系统间的主要界面。但是功能模型和动态模型暂不进行，而到下一个开发阶段进行。在系统体系结构阶段，把子系统看为是黑盒子。对每个子系统都进行子系统分析，结构模型由子系统类图和类描述表共同描述，功能模型由操作清单来描述，动态模型中包括事件清单、状态图、动作表、重要性程度表，还可能包括一系列复合事件。子系统在功能模型和动态模型中都被看成是黑盒，但功能模型和动态模型可以引用结构模型中的类。每个子系统都有子系统设计阶段，该阶段是子系统分析阶段的继续。动态模型有一系列对象交互线程表示。这些交互线程进一步设计为合格事件线程，接着由此导出对象组。结构模型可以由以上这些系统地建立起地进程描述、类描述和进程间消息描述构成。功能模型主要通过说明与结构模型中地类对应地成员函数描述。 在子系统实现阶段，见图8-9，所有模型转换为所选编程语言地源码。图8-8和图8-9左边地圆形箭头强调了开发过程是迭代进行的。接近实现阶段时，迭代程度降低，因为此时在阶段内部的迭代更频繁，而阶段间的迭代减少了。图8-9：OCTOPUS方法的子系统开发过程结构OCTOPUS处理实时系统并发的独特方法是：先采用隐式并发模型，然后逐渐过渡到显式模型，利用对象组实现到进程的映射。这是一种能够有效将对象和进程结合起来的方法。7、实时程序设计的一些准则（1）实时单元和分时单元的合理划分 对于实时系统，实时和分时单元的合理划分，是提高整个系统实时性能的一个重要手段。例如，对于信令处理系统来说，对信令的翻译、解释和转移、传递、应答是实时单元，而对于信令的监视打印、非法信令的打印等则是分时单元。实时单元应该放到实时任务里面去处理，而分时单元的处理应该由实时任务通过消息或者共享内存模式传递数据，启动分时进程的在线或者后台处理。（2）实时任务的划分任务是代码运行的一个映象，从系统的角度看，任务是竞争系统资源的最小运行单元。任务可以使用或等待CPU、I/O设备及内存空间等系统资源，并独立于其它任务，与它们一起并发运行（宏观上如此）。操作系统内核通过一定的指示来进行任务的切换，这些指示都是来自对内核的系统调用。在应用程序中，任务在表面上具有与普通函数相似的格式，但任务有着自己较明显的特点：1.任务具有任务初始化的起点（如获取一些系统对象的ID等）；2.具有存放执行内容的私用数据区（如任务创建时明确定义的用户堆栈和堆栈）；3.任务的主体结构表现为一个无限循环体或有明确的终止（任务不同于函数，无返回）。 在设计一个较为复杂的多任务应用时，进行的合理的任务划分对系统的运行效率、实时性和吞吐量影响极大。任务分解过细会引起任务频繁切换的开销增加，而任务分解不够彻底会造成原本可以并行的操作只能按顺序串行完成，从而减少了系统的吞吐量。为了达到系统效率和吞吐量之间的平衡与折衷，在应用设计应遵循如下的任务分解规则（假设下述任务的发生都依赖于唯一的触发条件，如两个任务能够满足下面的条件之一，它们可以合理地分开）：1.时间：两个任务所依赖的周期条件具有不同的频率和时间段；2.异步性：两个任务所依赖的条件没有相互的时间关系；3.优先级：两个任务所依赖的条件需要有不同的优先级；4.清晰性/可维护性：两个任务可以可在功能上或逻辑上互相分开。从软件工程和面向对象的设计方法来看，各个模块(任务)间数据的通信量应该尽量小，并且最好少出现控制耦合(即一个任务可控制另一个任务的执行流程或功能)，如果非要出现不可，则应采取相应的措施（任务间通信）使他们实现同步或互斥，以避免可能引起的临界资源冲突，因为这可能会造成死锁。一般说来，很多时候为了提高实时系统的运行效率，我们设计时要考虑将两（多）个逻辑上应该分成两（多）个任务的任务合并为一个任务。例如：有两个任务A和B，他们分别做两个优先级没有明显分别的处理，他们通过消息通信，任务A是消息的发送者，任务B 是消息的接受者，如果他们之间通信的消息量很大，可能就需要考虑将这两个任务合并，然后通过任务内部的缓冲区等通信机制来实现他们之间的通信，当然前提是从逻辑上讲，这两个任务的合并是可能的。一般说来，可以把这种任务内部的两个处理模块之间的通信机制设计成为虚消息机制，即在系统分析和设计以时，我们可以认为它就是消息，在程序设计时，通过宏函数或者函数调用的封装，普通程序员仍然可以通过虚消息的收发来编写他所需要完成的应用程序，从程序员的角度来看，这一点仍然是消息驱动的机制，与实时操作系统提供的消息通信机制没有什么差别。对于大多数商用的实时操作系统，系统内核对应用任务的数量没有作限制，实际应用时是在配置表中定义最大的任务数，并为存放有关数据结构分配足够的内存空间。在设计一个复杂应用时，上面讲述的任务分解原则仅能作一个初步的参考，真正设计时还需要更多的实际分析和设计经验，才能使系统达到预定性能指标和效率。(3)提高程序效率的途径实时程序的设计相对于分时程序的设计，尤其强调程序效率的优化。很多在分时程序设计中对于提高程序效率有效的方法，仍然有效。比较常用的优化手段有：1）使循环体内工作量最小化：应仔细考虑循环体内的语句是否可以放在循环体外，使循环体内工作量最小，从而提高程序的时间效率。例如，如下代码效率不高。for(i=0;i