CN105022661A - 一种多处理器系统可调度性验证方法 - Google Patents

Abstract

本发明公开了一种多处理器系统可调度性验证方法，包括：对可调度性分析问题中的应用程序、运行平台、调度管理分别建立模型，形成可调度性分析模型；采用时间计算树逻辑TCTL描述系统可调度性的性质；完成对可调度性分析模型和性质的验证，若性质满足，则表示系统任务可调度；若性质不满足，则对生成的反例进行分析和解释。本发明解决了现有方法计算复杂，适用范围受限的问题，以及模型对任务依赖的支持度不高，模型结构杂乱导致的对系统的规模支持不足等问题，还可以对模型检测验证结果进一步解释和分析，向用户展示分析后的检测结果，且具有良好的扩展性和验证效率，降低了分析成本。

Description

一种多处理器系统可调度性验证方法

技术领域

本发明涉及嵌入式系统可调度分析技术领域，具体为一种多处理器系统可调度性验证方法。

背景技术

目前的可调度性分析方法包括处理器利用率边界测试、最坏情况响应时间分析和模拟测试，前两种方法通过计算处理器利用率边界或最坏情况响应时间是否满足一定的要求来分析系统中的任务是否可调度，而模拟测试在系统模拟环境下反复运行可能的任务调度序列，动态地测试是否存在不能调度的情况。

由于多处理器片上系统中任务之间常常存在依赖关系，处理器利用率边界测试的可调度条件变得越来越复杂，且通常过于保守，可能会把可调度的情况判定为不可调度。进行最坏情况响应时间分析时，多处理器系统中影响任务响应时间的因素变得越来越多且更复杂，导致时间计算不精确。而模拟测试方法中任务调度的序列的覆盖率不可能达到100％，不具有完备性，若没有出现不能调度的情况，只能说明用于测试的任务序列都可调度而不能保证系统在实际执行时不发生错误。

使用模型检测技术进行可调度性分析，一旦模型检测的结果为任务都可以在其截止时间前可调度，则系统在运行时一定可满足实时要求，弥补了传统方法不完备的缺点。为了验证系统设计的实时正确性，如果对每个实际系统都手工建立模型进行可调度性验证，不仅过程繁琐，且模型不可重复利用。而且，现有的模型检测工具和技术都要求使用者了解形式化的语言，才能对验证系统进行描述，建模困难问题给模型检测的广泛应用带来一定阻碍。现有的模型抽象和建模方法，根据研究者的不同思路，不同文献提出的多处理器系统实时任务可调度性分析模型中存在一些局限性，例如：有的模型中只支持的隐式截止时间的任务，即任务截止时间默认等于其周期；有的模型不支持任务依赖关系，或只支持一对一的任务依赖关系，有的模型将任务之间的依赖传递也作为任务处理；模型结构不清晰，调度策略不易扩展。此外，有的方法不支持生成不可调度时的反例，模型检测的验证结果无法反馈。

发明内容

针对上述问题，本发明的目的在于提供一种多处理器系统可调度性验证方法，弥补传统分析方法计算复杂，适用范围受限的缺陷，同时改善现有基于模型检测的可调度性分析方法对任务依赖的支持度不高、模型结构杂乱导致的对系统的规模支持不足等问题。

技术方法如下：

一种多处理器系统可调度性验证方法，包括：

采用模型检测工具UPPAAL对可调度性分析问题中的应用程序、运行平台、调度管理分别建立模型，形成可调度性分析模型；

采用时间计算树逻辑TCTL描述系统可调度性的性质；

采用模型检测工具UPPAAL完成对可调度性分析模型和性质的验证，获得验证结果：

若性质满足，则表示系统任务可调度；

若性质不满足，则对生成的反例进行分析和解释。

进一步的，建立所述可调度性分析模型具体包括：

所述应用程序包含任务、任务间依赖关系；对任务建立用于保存任务属性的数据结构和表示任务状态的任务模型；对任务间依赖关系建立模型，具体为用一个静态矩阵表示原始任务间的依赖关系，用一个动态矩阵保存当前时刻任务的运行状态，通过比较两个矩阵中的对应项获取当前时刻任务所依赖的任务的运行状态；

所述运行平台包括处理器和总线；建立处理器模型：处理器用一个队列表示，在队列中保存等待处理器的任务的编号；建立总线模型，当运行在不同处理器上的任务存在依赖关系时，通过总线模型传输消息；

所述调度管理包括调度器和调度策略，建立调度器模型和调度策略模型；调度器将处理器和对应的调度策略相关联，调度策略用于实现调度算法；当有新任务请求处理器时，调度器用对应的调度策略将任务编号插入到处理器队列中相应的位置。

跟进一步的，所述任务属性包括任务编号、时间偏移、最好和最坏执行时间、截止时间、周期及其映射到的处理器编号。

更进一步的，还包括建立依赖管理器模型，用于完成对所述动态矩阵的更新操作。

本发明的有益效果是：本发明实现可调度性分析验证流程的自动化，解决了现有方法计算复杂，适用范围受限的问题，同时改善现有方法模型对任务依赖的支持度不高，模型结构杂乱导致的对系统的规模支持不足等问题，还可以对模型检测验证结果进一步解释和分析，向用户展示分析后的检测结果，且具有良好的扩展性和验证效率，降低了分析成本。

附图说明

图1为本发明多处理器系统可调度性验证方法的流程框图。

图2为本发明多处理器系统可调度性验证方法中的任务模型。

图3为本发明多处理器系统可调度性验证方法中的依赖管理器模型。

图4为本发明多处理器系统可调度性验证方法中的总线模型。

图5为本发明多处理器系统可调度性验证方法中的调度器模型。

图6为本发明多处理器系统可调度性验证方法中的速率单调策略模型。

图7为本发明多处理器系统可调度性验证方法中的最早截止时间优先策略模型。

图8为本发明实施例中不可调度时任务甘特图。

具体实施方式

下面结合具体实施例对本发明做进一步说明。本发明提供了一个用于多处理器可调度分析的方法，针对于多处理器实时系统提供了一套可配置的可调度分析的模板，模板可根据待验证系统的特性完成配置，并最终通过模型检测工具完成可调度性分析。具体流程如图1所示，包括：

1)采用模型检测工具UPPAAL对可调度性分析问题中的应用程序、运行平台、调度管理分别建立模型，形成可调度性分析模型。

其中应用程序包含任务、任务间依赖关系；运行平台包括处理器和总线；调度管理包括调度器和调度策略。

对任务建立用于保存任务属性的数据结构和表示任务状态的任务模型。任务属性包含任务编号、时间偏移、最好和最坏执行时间、截止时间、周期及映射到的处理器编号。任务模型如图2所示，图中的节点表示任务在生命周期中可能的状态，Error表示任务违反了其截止时间后的状态。

对任务间依赖关系建立模型，具体为用一个静态矩阵表示原始任务间的依赖关系，静态矩阵D[i][j]表示任务i是否依赖于任务j。用一个动态矩阵保存当前时刻任务的运行状态，如是否运行结束，当任务运行结束后更新其对应的列。此外加入依赖管理器模型，如图3所示，用于完成对于动态矩阵的更新操作。通过比较两个矩阵中的对应项获取当前时刻任务所依赖的任务的运行状态。通过修改任务状态的更新操作和判断依赖满足的方法，使模型可以处理较复杂的任务依赖关系。

建立处理器模型：处理器用一个队列表示，在队列中保存等待处理器的任务的编号；建立总线模型(如图4所示)，当运行在不同处理器上的任务存在依赖关系时，通过总线模型传输消息。

建立调度器模型(如图5所示)和调度策略模型。调度器将处理器和对应的调度策略相关联，当有新任务请求处理器时，调度器用对应的调度策略将任务编号插入到处理器队列中相应的位置。调度策略用于实现具体飞调度算法，如固定优先级算法、速率单调算法，最早截止时间优先算法等，其中速率单调测量模型如图6所示，最早截止时间优先策略模型如图7所示。并且其他的调度算法可以建模后增加到模型中，提高了模型的可扩展性。

2)采用时间计算树逻辑TCTL描述系统可调度性的性质。可调度性的性质表示在所有的路径上所有任务都不会达到Error状态。

3)采用模型检测工具UPPAAL完成对可调度性分析模型和性质的验证，获得验证结果，判断系统是否可调度，具体为：

若性质满足，则表示系统任务可调度；

若性质不满足，则对生成的反例进行分析和解释，并转换为图形再反馈。

对于不同的系统，设计人员可以使用实际系统的信息对模型进行配置，对模型中的一些数据结构赋值，根据具体信息实例化模型中的模块，构成待验证的系统模型，方法在执行验证之后获得系统是否满足任务可调度的性质的结果，反馈给设计人员，让设计人员快速、便捷、直观地完成实时任务可调度性分析的过程。

对于一个特定的任务调度问题，需要给定任务、任务依赖及处理器、总线的属性用于配置模型，得到具体系统的可调度性分析模型并保存在模型的.xml文件中，使用模型检测工具UPPAAL对模型及可调度性的性质进行验证，并对验证结果进行进一步解释和反馈。

该方法实现了方法流程的自动化。用户可以使用该方法描述系统的设计，并验证所描述系统的可调度性，可以查看配置后的可调度性分析模型及验证的结果。实现方法的系统模型配置、验证和结果解释的过程，我们预先构造出了可配置的模型，用工具实现自动化的模板配置，生成模型检测工具UPPAAL验证需要的模型文件.xml和性质文件.q，调用模型检测工具UPPAAL的验证模块进行验证，并对模型检测工具UPPAAL给出的验证结果进行解释后反馈。这样，用户只需给出系统的属性就能获得可调度性分析的验证结果，使方法的使用过程更便捷，结果反馈更直观。此外，用户可以保存系统描述信息和载入已有的系统描述信息。

选用一个双处理器实时系统进行方法的可行性验证，在该系统环境下，该任务集是不可调度的。该系统具有2个处理器p₀和p₁，处理器间通过总线连接，系统共有5个任务，任务τ₂依赖于任务τ₁，任务τ₄依赖于任务τ₁、τ₃。总线的最好情况和最坏情况传输延迟都是1个时间单位，处理器和任务的属性如表1、表2。

表1处理器属性

表2任务属性

使用上述可调度性分析模型，即将处理器、任务、总线的属性及任务依赖关系输入方法中，在工具原型中的配置方法如表2所示。

可实现对模型验证其是否满足可调度性性质，得到的验证结果是性质不满足，即在该系统环境下存在有任务不可调度。获得产生任务不可调度情况的甘特图如图8。从图中可以看出，由于处理器p₀的调度策略是速率单调调度RMS，而任务τ₀的周期为4个时间单位，其比任务τ₂具有更高的优先级，因此τ₀在时刻4抢占了处理器，导致任务τ₂在其截止时间6个时间单位内无法完成。

此时，若将处理器p₀的调度策略修改为最早截止时间优先调度EDF，其余性质不变，依然验证可调度性性质，使用的验证时间为0.375s，得到的验证结果是性质满足，即在该系统环境中，这些任务都是可调度的。处理器p₀采用EDF的调度策略时，其利用率1，说明任务确实是可调度的，验证结果无误。

Claims (4)

1.一种多处理器系统可调度性验证方法，其特征在于，包括：

采用模型检测工具UPPAAL对可调度性分析问题中的应用程序、运行平台、调度管理分别建立模型，形成可调度性分析模型；

采用时间计算树逻辑TCTL描述系统可调度性的性质；

采用模型检测工具UPPAAL完成对可调度性分析模型和性质的验证，获得验证结果：

若性质满足，则表示系统任务可调度；

若性质不满足，则对生成的反例进行分析和解释。

2.根据权利要求1所述的多处理器系统可调度性验证方法，其特征在于，建立所述可调度性分析模型具体包括：

所述应用程序包含任务、任务间依赖关系；对任务建立用于保存任务属性的数据结构和表示任务状态的任务模型；对任务间依赖关系建立模型，具体为用一个静态矩阵表示原始任务间的依赖关系，用一个动态矩阵保存当前时刻任务的运行状态，并通过比较两个矩阵中的对应项获取当前时刻任务所依赖的任务的运行状态；

所述运行平台包括处理器和总线；建立处理器模型：处理器用一个队列表示，在队列中保存等待处理器的任务的编号；建立总线模型，当运行在不同处理器上的任务存在依赖关系时，通过总线模型传输消息；

所述调度管理包括调度器和调度策略，建立调度器模型和调度策略模型；调度器将处理器和对应的调度策略相关联，调度策略用于实现调度算法；当有新任务请求处理器时，调度器用对应的调度策略将任务编号插入到处理器队列中相应的位置。

3.根据权利要求2所述的多处理器系统可调度性验证方法，其特征在于，所述任务属性包括任务编号、时间偏移、最好和最坏执行时间、截止时间、周期及其映射到的处理器编号。

4.根据权利要求2所述的多处理器系统可调度性验证方法，其特征在于，还包括建立依赖管理器模型，用于完成对所述动态矩阵的更新操作。