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:

• Children:
  • include
  • information
  • ownership
  • class
  • scheduler
  • executable

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:

• Children:
  • deploy-unit-name: The name of this deploy-unit.
  • deploy-unit-major-version: An integer number to describe the major-version of this deploy-unit. Increase this digit, if you do a non-backward compatible change.
  • deploy-unit-minor-version: An integer number to describe the minor-version of this deploy-unit. Increase this digit, if you add a new, backward compatible feature.
  • deploy-unit-tiny-version: An integer number to describe the tiny-version of this deploy-unit. Increase this digit if you do a bug-fix, rebuild or any other minor change.
  • state: Defines the state of the FESA deploy-unit. Possible values can be:
    • development: The deploy-unit is under development.
    • operational: The deploy-unit is delivered and ready to be used.
    • inUse: TODO: I have no idea what is the difference between operational and inUse--> Add useful info here!
    • deprecated: The deploy-unit is marked to be deleted.
    The purpose of this state is to simplify the FESA life cycle management.
  • description: Contains a brief description of the deploy-unit.
  • fesa-version: The FESA-Framework-version which is used for this deploy-unit-design.
  • repository-path: The repository path where this deploy-unit is stored.
  • build-time: TODO: Add useful information here!

5. Ownership

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

• Children:
  • responsible
  • creator
  • editor

5.1. Responsible

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

• Attributes:
  • name: The name of the responsible person

5.2. Creator

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

• Attributes:
  • login: User’s login

5.3. Editor

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

• Attributes:
  • login: User’s login
  • access-type:
    • full-access: Grants the same rights as the creator to this editor.
    • limited-access: Gives the rights to deploy and instantiate the equipment-software.

6. Class

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

• Children:
  • class-name: The name of the included class
  • class-major-version: The major-version of the class
  • class-minor-version: The minor-version of the class
  • class-tiny-version: The tiny-version of the class
  • device-instance:
    • required: A device-instance of the given class will be created
    • optional: It is possible to create a device-instance of the given class, but not essential
    • none: It is not possible to instantiate the specified class. (e.g. for abstract classes)
  • path: Path to the working folder of the included class (automatically filled-in by the eclipse-plugin)

7. Scheduler

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

• Children:
  • concurrency-layer

7.1. Concurrency-layer

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

• Attributes:
  • event-queue-size: The number of events, which should be buffered, as long as the system is to busy to execute RealTime-actions of this layer. "-1" means "unlimited"
  • name: Each concurrency-layer needs a unique name
  • prio: The default-priority, used for this layer (Can be fine-tuned in the instantiation-document )
• Children:
  • scheduling-unit

7.2. Scheduling-unit

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

• Attributes:
  • per-device-group: TODO: Check what this flag is used for.
  • scheduling-unit-name-ref: Here you can choose the scheduling-unit you want to use in this concurrency-layer from a given enumeration

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.

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)