参见图1，本发明中任务分配与调度策略评估的框架图。
[0039]本发明框架接收配置设定作为输入，以及一个确定的任务分配与调度实例，将这些参数应用到模型中，并多次运行查询语句，最终生成该任务分配与调度实例在输入参数的环境下的稳定性表现(即性能产出)。其中，框架接收配置设定包括:
[0040]I)若干个任务DAG (Directed Acyclic Graph，有向无环图):如果DAG超过I个，则多个DAG在调度时必须映射到一个任务分配与调度实例上，即所有的任务DAG都在同一个调度中执行；
[0041]2)MPSoC的相关参数:包括处理单元(PE)的个数、类型、额定功耗以及制程变异区间，这些参数是与MPSoC相关的。其中，制程变异区间是一个正态分布的函数，框架会在运行时自动从中选择值，该值作为MPSoC相对于额定功率的百分比，用户应该指定其方差；
[0042]3)设计约束:包括所有任务的完成时间、MPSoC的最大功耗，以及需要实现的性能产出等。
[0043]统计模型检查(Statistical Model Checking，SMC)技术通过模型的随机运行来产生大量的试验结果，并针对特定的查询约束建立统计结论。
[0044]本发明提出的制程变异下基于UPPAAL-SMC的MPSoC任务调度建模与评估方法，对于给定的一个调度策略，首先用该策略生成一个任务调度的实例，再将该实例转换成框架的输入参数；框架接受这些输入参数，会将其转换为UPPAAL-SMC模型中的配置文件，并在模型中运行；再通过给定的约束查询，就可以得出该调度策略在给定设计约束下的性能产出。
[0045]如图2所示，本发明的基于UPPAAL-SMC的MPSoC任务调度建模与评估方法包括:步骤一:任务分配与调度实例生成步骤；步骤二:模型转换步骤；步骤三:查询生成步骤；步骤四:任务分配与调度实例的分析与评估步骤。
[0046]其中，任务分配与调度实例生成步骤是对调度策略进行评估的首要操作，本步骤根据采用的调度策略，在特定的MPSoC上，为给定的任务集生成任务分配与调度实例。
[0047]任务分配与调度实例生成后，即为给定的任务集生成任务分配与调度实例之后，执行模型转换步骤，本步骤在考虑制程变异的前提下进行任务建模、PE建模和功耗建模，形成任务模型、PE模型和功耗模型，并进行模型的后台配置，将任务分配与调度实例进行模型转换。
[0048]本发明的框架由两部分构成:前台模型和后台配置。前台模型包括了对任务、PE和功耗的建模；后台配置包括了框架接收的配置设定参数，以及对任务分配与调度应用背景的描述。后台配置控制所有结构性、逻辑性的信息，当UPPAAL-SMC对框架进行初始化时，会首先读取配置部分，并将配置应用到任务分配与调度实例中，再执行约束查询，后台配置中的信息和任务集、PE息息相关，决定着框架的运行过程。
[0049]如图3所示，本发明框架没有对整个任务序列进行建模，而是对所有的任务节点进行了抽象与统一，对单一任务节点进行建模，并根据前驱、后继节点的配置情况。
[0050]任务从“初始”节点开始运行，并运行初始化函数(initialize O函数)，跳转到“准备”节点。在initialize函数中，节点会首先读取后台配置，并判断自己的前驱、后继节点的个数和序号；接着，节点判断自己是不是整个任务序列的初始节点，如果是，则根据后台配置生成服从正态分布的随机数，对时间和功耗的制程变异进行初始化。本发明框架根据Box-Muller算法，利用UPPAAL-SMC中提供的random函数，将其生成的平均分布随机数转换为正态分布随机数。
[0051]到达“准备”节点后，任务对自身的前驱节点进行判断。如果不存在前驱节点(pre_num== O)，则跳转到“开始”节点；否则，跳转到“接收”节点，等待它的前驱节点完成并发送消息；当start_task消息来到时，模型首先对消息进行选择，判断是否为任务通信类型message_task_t ;如果是，再调用is_this函数判断是否是自己的前驱节点发出的消息；如果是，则将自己等待的前驱节点数减一，跳转到“开始”状态；然后，对其剩余前驱节点进行判断，已决定继续等待接受消息或准备开始运行。
[0052]到达“开始”节点后，任务如果没有前驱节点，则从后台配置assigned中读取并判断本任务应该被分配到哪个PE上，接着向目标PE发送分配消息(aSSign_pr0C)，通知目标PE本任务将要执行，并跳转到“运行”状态。
[0053]到达“运行”节点后，任务进入了等待状态。此时，该任务将等待执行者PE完成任务，并发送finish_task(任务完成)信号；任务执行时间的流动由PE负责。当finish_task消息到来时，模型判断是否是message_task_t，接着判断自己是否为消息的接收者，如果是，则跳转到“完成”节点。
[0054]到达“完成”节点后，任务会判断自己是否存在后继节点，如果没有则会跳转到“终止”节点，结束自身的运行；如果该任务存在后继节点，则会跳转到“发送”节点，并进入一个循环；当任务的剩余后继节点大于O时，任务会在每次循环中发送start_task (任务开始)消息，通知其后继节点可以开始运行，并更新自己的后继节点计数器。
[0055]如图4所示，本发明中，PE模型是对所有PE的抽象模型，通过后台配置来控制PE的表现，包括功耗、制程变异等。PE模型的初始节点为“开始”，处于“开始”节点时，Processor (处理器)首先调用queue_empty函数对队列进行判断，如果队列为空，即当前该Processor并没有接到任何任务请求，则进入下方的“等待”节点；如果队列不为空，则跳转到“运行”节点，并读取队列中的头部任务，对sid (安全标识符)、tid (线程控制符)、real_time_cost(实际执行时间)等进行更新，使sid和tid记录当前将要执行的任务的信息，real_time_C0St保存依据制程变异计算出的实际完成时间，为“运行”节点执行任务做准备。同时，PE模型发出一个request_power信号，告知功耗模型更新功耗情况；此外，如图所示，“开始”节点包含了一个自循环的有向边，该边的状态迀移在收到aSSign_pr0C信号时触发，首先对消息进行选择，判断是否为message_proc_t类型的信号，再判断自己是否为该消息的接收者，如果是，则将其加入自己的任务队列。类似的自循环边在“等待”、“运行”、“完成”节点均有体现。在“开始”节点，Processor判断队列是否为空，并进行相应动作，同时监听assign_proc信号。
[0056]当Processor到达“运行”节点时，会在该节点停留固定的时间，这一点通过不变式和跳转条件的组合来实现。而在状态迀移的同时，Processor发送一个finish_task信号，携带目标任务的sid和tid，告知相关任务模型运行已结束，使目标任务从“运行”节点迀移到“完成”节点，与此同时，“运行”节点在迀移时还对任务队列执行出队操作，更新了任务队列。从语义上来讲，“运行”节点负责队列头部任务的运行，根据额定时间和制程变异确定实际执行时间，并在时间结束后发送消息，通知任务。此外，“运行”节点也存在一个环路来监听任务模型发来的assign_proc消息。
[0057]“完成”节点作为一个中间节点存在，由于UPPAAL-SMC禁止在同一个状态迀移边上设定两个不同的同步值，因此让Processor首先到达“完成”节点，再从“完成”节点迀移到“开始”节点，完成其一次完整的任务执行过程。在从“完成”节点迀移到“开始”节点的过程中，Processor发出一个free_power信号，通知功耗模型释放Processor占用的功耗，更新功耗的信息。
[0058]PE模型通过与任务模型和功耗模型间的通信，控制任务的执行过程，与功耗信息的更新，是整个框架中动态性较强的模型。在模型中包括了多个监听新任务消息的回路，增加了一些语法上的冗余，但是有效地避免了 PE模型接收不到新任务消息的情况，实现了功能上的完整和语义上的完善。
[0059]如图5所示，功耗模型负责对功耗的情况进行监控与维护，包含“处理”和“等待”两个节点。功耗模型初始处于“处理”状态，而在“处理”和“等待”状态时，都接收两种信号，分别是:request_power (供电需求)和free_power。当功耗模型接到request_power的信号时，它会根据发送者的pid，调用power_alloc函数，增加当前功耗current_power，并且，如果当前的功耗大于历史最大功耗(cu