Main Content

Simulate Scheduler of a Multicore Control System

Open Model

Overview

This example shows how to model the task scheduling of a control application using SimEvents® blocks. SimEvents expands Simulink® with the capability to model and simulate architectural components of a real-time system.

The top model includes two areas of blocks:

  • Functional Components includes two closed-loop systems. Each has a proportional controller operating a plant.

  • Architectural Components includes SimEvents blocks modeling the tasks and scheduler of this control system.

Modeling Tasks and Scheduler

This example models a controller as a Simulink exported function model. It maps execution of a controller to a software task that an operating system periodically schedules and executes. A task can be divided into multiple segments (or subtasks). Due to data dependencies, these segments must be executed in sequential order.

A task is specified with the following parameters:

  • ID: Unique identifier of a task.

  • Period: How frequently a task is instantiated for execution.

  • Priority: Priority of the task (smaller value indicates higher priority).

  • List of runnable segments (functions): Executables associated with each segment of the task. These executables are represented by Simulink functions of an exported function model.

  • Segment execution duration: Time for a task segment to complete, if it is executed on a processor without interruption.

  • Needs disk i/o resource for each segment: Whether a segment of the task requires the use of a mutex-protected shared resource (a hard disk).

For example, block Task 2 specifies a task for the second controller (block Controller2). The task includes two segments, "t2_run" and "t2_write", both modeled as Simulink functions in model seSwcController2. In these segments, "t2_write" requires the use of the mutex-protected shared resource.

Scheduler of the operating system is modelled with the following components:

  • Task creation: Block Task 1 and Task 2 create tasks and manage task states. A SimEvents entity represents an instance of a task. Properties of a task (such as its priority) are modelled as entity attributes.

  • Task queue: Upon instantiation, a task joins a ready task queue, which is modelled by the Entity Queue block OS Task Queue. To simulate a non-preemptive priority-based scheduling policy, the queue block is configured to sort tasks by the taskPriority attribute.

  • CPU: The processor of the system is modelled as an Entity Server block CPU. It accepts entities from the OS Task Queue and processes the entity for a duration as specified by the task's Segment execution duration parameter. At the end of this delay, the corresponding Simulink function of this task segment is called, as a part of the block's Service complete action.

  • Lock/unlock Mutex: Before a task segment enters the block CPU, it must acquire the required resource at the preceding Lock Mutex block. After the task segment completes and exits the block CPU, the resource is released at the Unlock Mutex block.

  • Managing task states: Blocks under the mask of Task 1 and Task 2 manage the run-time state of tasks. Upon completion of a task segment, if the task has subsequent segments to execute, the task is routed back to the OS Task Queue. Otherwise, this task instance is completed and discarded.

Results and Displays

The block CPU is configured with two cores. Simulating the model generates the following Gantt chart.

  • The higher priority task, Task 2 (red bars), is scheduled to core 1 (y = 1).

  • The lower priority task, Task 1 (blue bars), is scheduled to core 2 (y = 2).

  • The second segment of Task 2 uses the mutex DiskLock. Green bars indicate the usage (y = 3).

Explore the Model

Change the following parameters and explore how task schedules and controller performance changes with re-configured architectural parameters.

  • In block CPU, configure parameter Capacity to change the number of cores.

  • In blocks Task 1 and Task 2, configure parameters such as Period and Priority to change task specifications.

For example, if we change Need disk i/o resource for each segment parameter of the Task 1 block to [0 0 1], the t1_write segment of Controller 1 must acquire mutex DiskLock before it can start to run. Simulation generates a Gantt chart that illustrates that change.

  • Both tasks have segments that use mutex DiskLock, as indicated by green bars (y = 3).

  • The third segment of Task 1 now must execute in a serial fashion with the second segment of Task 2 (see y = 1), because both segments share the mutex DiskLock.

Related Examples

See Also

| | | | |

Related Topics