Develop Custom Scheduler of a Multicore Control System

Overview

This example shows how to model a customer scheduler using the SimEvents® MATLAB Discrete-Event System block. The model includes a Scheduler block that can simulate a multicore system with an arbitrary number of cores, tasks, and mutually exclusive resources.

The model configures the Scheduler block to process tasks of closed-loop control systems. The simulation measures the performance of these control systems, and provides metrics of the run-time environment, such as latencies and resource contingencies. These results can help designers of control systems develop architectural specifications for their functional components.

Creating Custom Scheduler in MATLAB

The Scheduler block of the root model is developed primarily as a MATLAB® discrete-event system. MATLAB file seSchedulerClass contains the implementation of the corresponding discrete-event System object.

The example models a controller as a Simulink® exported function model. Execution of a controller is mapped to a software task that is scheduled to execute periodically. A task can be divided into multiple segments (or subtasks). Due to data dependencies, these segments must be executed in sequential order.

The Scheduler block includes the following parameters:

Number of cores: Number of cores available for the operating system to use.
Scheduling policy: Select either "Priority-based" or "Round robin" as the scheduling policy of the operating system. Priority-based scheduling sorts and executes tasks in a prioritized order. Round robin policy allows tasks to equally take turns.
Number of tasks: Number of tasks in this operating system.
Task periods: How frequently each task is instantiated for execution.
Task priorities: Priority of each task (smaller value indicates higher priority).
Number of segments in each task: Number of segments (subtasks) a task has.
Simulink function for each segment: Executables associated with each segment of a task. These executables are represented by Simulink functions of an exported function model.
Execution durations of each segment: Time for a task segment to complete, if it is executed on a processor without interruption.
Number of mutually exclusive resources: Number of mutually exclusive resources of the operating system. One task at a time can acquire and use the resource. Operating system uses mechanisms such as mutexes to manage these resources.
Use of resources by each task: Cell vector. Each element of the vector indicates the use of resources by a task.

Comparing Different Core Allocations

The Scheduler block allows you to assign an arbitrary number of cores and explore how that impacts system performance. We begin with a scenario where two cores have been assigned to execute the two control tasks. With sufficient processing capacity, both closed-loop control systems perform well in response to set point changes.

The timing diagram of the scheduler indicates that control tasks are concurrently processed by both cores, with cores having medium and balanced utilizations.

In comparison, when only one core is assigned, the performance of Controller1 degrades due to task overruns (see Plant1). The timing diagram clearly indicates such task overruns, and the significantly increased latencies.

Notice that the performance of control task 2 remains unchanged. This is because the scheduler applies the priority-based policy where processing capacity is maximally assigned to high priority tasks.

Comparing Different Scheduling Policies

At this point, if the Scheduler switches to use a round robin scheduling policy, the control system performs differently. Compared to the previous case, where processing capacity remains the same, Plant 1 becomes stable, with the cost of degrading the performance of Plant 2. This change is due to the fact that the round-robin policy evenly assigns the processing capacity among all tasks.

Comparing Different Resource Allocations

Now let us configure the scheduler back to use two cores, and explore different resource allocation schemes. We add a resource that can be shared by tasks in a mutually exclusive fashion.

As indicated by the timing diagram, although concurrent execution is allowed with two cores, the tasks are processed in a sequential fashion. Only one core is in use. This is because a task must wait for the required resource before it can be processed.

You can eliminate such resource contingency by assigning more resources. Let us configure the scheduler block to use 2 resources, and allow a task to have a dedicated resource.

With each task having its own resource, tasks are processed concurrently.

Related Examples

Simulate Scheduler of a Multicore Control System