FSF reference

0.1

This reference manual contains the description of the API provided by the FSF library.

Introduction to FSF

The First Scheduling Framework (FSF) is the result of a joint effort from four european research groups to propose an API for flexible real-time scheduling in Real Time operating systems. See the FIRST web page for more details in the project.

Objectives

Scheduling theory generally assumes that real-time systems are mostly composed of activities with hard real-time requirements, many systems are built today by composing different application or components in the same system, leading to a mixture of many different kinds of requirements with small parts of the system having hard real-time requirements and other larger parts with requirements for more flexible scheduling, taking into account quality of service. Hard real-time scheduling techniques are extremely pessimistic for the latter part of the application, and consequently it is necessary to use techniques that let the system resources be fully utilized to achieve the highest possible quality.

The FIRST project aims at developing a framework for a scheduling architecture that provides the ability to compose several applications or components into the system, and to flexibly schedule the available resources while guaranteeing hard real-time requirements. The FIRST Scheduling Framework (FSF) is independent of the underlying implementation, and can run on different underlying scheduling strategies. It is based on establishing service contracts that represent the complex and flexible requirements of the application, and which are managed by the underlying system to provide the required level of service.

FSF provides a generalized architecture framework that combines different kinds of requirements:

co-operation and coexistence of standard real-time scheduling schemes, time-triggered and eventtriggered, dynamic and fixed priority based, as well as off-line based through a common architecture that is independent on the underlying scheduling mechanism

integration of different timing requirements such as hard and soft, and more flexible notions

temporal encapsulation of subsystems in order to support the composability and reusability of available components including legacy subsystems.

FSF has been implemented in two POSIX compliant real-time operating systems, MaRTE and SHARK, which are based on FP and EDF scheduling schemes, respectively, thus illustrating the platform independence of the presented approach.

Contracts

The service contract is the mechanism that we have chosen for the application to dynamically specify its own set of complex and flexible execution requirements. From the application s perspective, the requirements of an application or application component are written as a set of service contracts, which are negotiated with the underlying implementation. To accept a set of contracts, the system has to check as part of the negotiation if it has enough resources to guarantee all the minimum requirements specified, while keeping guarantees on all the previously accepted contracts negotiated by other application components. If as a result of this negotiation the set of contracts is accepted, the system will reserve enough capacity to guarantee the minimum requested resources, and will adapt any spare capacity available to share it among the different contracts that have specified their desire or ability for using additional capacity.

As a result of the negotiation process, if a contract is accepted, a server is created for it. The server is a software object that is the run-time representation of the contract; it stores all the information related to the resources currently reserved for that contract, the resources already consumed, and the resources required to handle the budget consumption and replenishment events in the particular operating system being used.

Because there are various application requirements specified in the contract, they are divided into several groups, also allowing the underlying implementation to give different levels of support trading them against implementation complexity. This gives way to a modular implementation of the framework, with each module addressing specific application requirements. The minimum resources required by the application to be reserved by the system are specified in the core module. The requirements for mutual exclusive synchronization among parts of the application being scheduled by different servers or among different applications are specified in the shared objects module. Flexible resource usage is associated with the spare capacity and dynamic reclamation modules. The ability to compose applications or application components with several threads of control, thus requiring hierarchical scheduling of several threads inside the same server are supported by the hierarchical scheduling module. Finally, the requirements of distributed applications are supported by the distributed and the distributed spare capacity modules. We will now explain these modules together with their associated application requirements.

Generated on Tue Apr 5 17:01:24 2005 for FSF by

1.3.4