FESA Deployment-Unit Documentation
Fesa version 3 User doc.
FESA Team
Copyright CERN&GSI 2012. All rights reserved.

1. Introduction

The deployment-unit is used to further define dependencies between different FESA-classes, used by inheritance and composition. As well the RealTime-scheduling of a class-composition and a choice between the different binary types which can be produced is done here.

2. Deploy-Unit

The Deployment-Unit Schema subdivided into several complementary areas, for which the equipment specialist has to make design choices:

3. Include

This element is optional and is not meant to be touched (added/removed) by the developer because it's automatically managed by the FESA plug-in. It is automatically inserted in the design-document as soon as the developer adds a class.

It is used to receive the scheduling information of the different classes. The scheduling of the base class is not duplicated in the XML design document but included using the "XInclude" concept provided by XML.

The included document contains only the useful information, required to make the scheduling working.

4. Information

All basic informational attributes of the deployment-unit are defined here:

5. Ownership

Here a ownership is defined in terms of responsible, creator and optionally a list of editors having some specific rights.

5.1. Responsible

Describes a long term responsibility, less ephemeral than a creator or an editor (departure, moving,..).

5.2. Creator

Defines the creator of the equipment-software in terms of user's login

5.3. Editor

Allows to manage user privileges for different editors of the equipment-software.

6. Class

All classes you want to use for this deployment-unit should be listed here.

7. Scheduler

Here the RealTime-scheduling of all participating classes is managed.

7.1. Concurrency-layer

Each concurrency layer describes one thread which takes care of all scheduling-units which share the same priority.

7.2. Scheduling-unit

Here one can refer to the scheduling-units of all classes of this equipment.

8. Executable

Here the developer can choose between the usage of the same binary for the RT-Part and for the Server(Interface)-Part, or a split-application. The advantage of a split-application is, that one can restart one part of the equipment-software without touching the other part.

As well it is e.g. possible to produce a server-only binary, if the class has no rt-functionality.

  • Children:
  • 8.1. Mixed Binary

    A binary where Server and RT-Part will run in the same process (the extension _M will be added to the binary-name)

    8.2. RT Binary

    A binary which only consists of the RT-Part (the extension _R will be added to the binary-name)

    8.3. Server Binary

    A binary which only consists of the Server-Part (the extension _S will be added to the binary-name)