You are here: Foswiki>FESA Web>FESA3>FESA3HTMLDocumentation (26 Mar 2012, AlexanderSchwinn)Edit Attach
FESA Metamodel

Fesa version 3.0 User doc.

FESA Team

Copyright CERN&GSI 2011. All rights reserved.

1. Introduction

The first step to develop equipment software with FESA is, to define what the equipment software has to do and what it's structure will be. An equipment specialist designs this equipment-software using the FESA’s design tool. By doing-so he describes the equipment, based on a XML-design-document. This document is validated against a FESA XML-schema, which enforces all FESA-design-constraints. After the XML-class design is finished, FESA automatically can generate C++ source-code out of this design-document. The developer only need's to implement some well defined methods(E.g. the communication to the hardware). In these C++ methods the developer can easily use all provided FESA-services.

Designing any equipment software with FESA starts answering the following questions:
  • What are the published services provided by the equipment software( properties) to clients?
  • How the software abstraction of the accelerator device should be structured?
  • What are the building-blocks?
  • What is the real-time behavior?

2. Equipment-Model

The metamodel is subdivided into several complementary areas, for which the equipment specialist has to make design choices:

3. Information

All basic informational attributes of a FESA class are defined here:
  • Attributes:
    • class-name: The name of this class
    • class-version: An integer number to describe the version of this class
    • type: A qualifier to specifying if the class is:
      • Abstract: An abstract class cannot be instantiated in terms of creating device instances. Abstract classes typically are used as base classes in the context of inheritance.
      • Concrete: For concrete classes there is no restriction at all, they can be extended and instantiated.
      • Final: Final classes cannot be extended but can be instantiated.
    • state: Defines the state of the FESA class. Possible values can be:
      • development: The class is under development.
      • operational: The class 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 class is marked to be deleted.
The purpose of this state is to simplify the FESA class life cycle management.
    • fesa-version: The FESA-version number mainly covers the versioning of the metamodel (The xsd-schema for the different xml documents)
    • fesa-release: The FESA-release number covers the versioning of the C++ code, linking strongly the class with a given fesa release.
    • description: Contains a brief description of the class.

4. Ownership

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

4.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

4.2. Creator

Defines the class design creator in terms of user's login.
  • Attributes:
    • login: User’s login

4.3. Editor

Allows to manage user privileges for different editors of the class.
  • 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 class.

5. Relationship

FESA defines three types of relationship between FESA classes.

5.1. Association

  • Attributes:
    • class-version: The version of the class we want to communicate with
    • class-name: The class we want to communicate with
Light coupling between FESA classes. Only the public interface ( properties) of the related class can be accessed. The related class is identified by the couple class-name/version. A class can define 0..n association relationships. A typical example where the association is useful is when a system is modeled using the delegation model.

Let’s imagine a class, named “Signal-class”, which needs to control a timing-hardware. But this timing-hardware is as well shared by other systems. So instead of embedding all the knowledge to control the timing-hardware in the“Signal-class”, the idea behind the association is, to delegate the control of the timing-hardware to a generic “Timing-class”. Therefore the “Signal-class” provides a property to control the timing-hardware, but internally calls the appropriate "Timing-class" property to do the job by using a device instance of the "Timing-class".

The class, which should be associated does not even need to run on the same front-end, since the connection to it's properties is done via the middleware. As well check the on-subscription-event-source for more information.

5.2. Composition

  • Attributes:
    • class-version: The version of the class which will be used inside this class
    • class-name: The class which will be used inside this class
This type of relationship allows to combine simple FESA classes to model a complex system and therefore allows FESA class code reuse. Breaking a complex system into sub-systems, comes down to say this complex system is “composed of” many FESA classes. Composition is a stronger form of aggregation where the whole composition and the parts have the same lifetime. The figure below shows such a system using the composition relationship. All classes of the composition need to be gathered by using one deployment-unit. The deployment-unit will create a binary which consists of all classes and represents the whole composition.

TT and PT FESA classes have no dependencies with other FESA classes and could be, if it makes sense, either deployed as stand-alone class or re-used by another system.

5.3. Inheritance

This type of relationship should be used to model variants of a similar device-type, or when it makes sense to define a common abstract FESA class to enforce a common interface or behavior to derived classes. Inheritance between FESA classes should be applied as soon as the “Is a” and “Is like” relationship is true. A FESA class may extend only one direct base class. To inherit from more than one class is not foreseen in FESA.
  • Attributes:
    • class-version: The version of the class to inherit from
    • class-name: The class to inherit from
The following picture shows a possible inheritance-scenario:

Inheritance in FESA, allows reusing existing design-data and code provided by the base class (direct one or indirect ones). Here a short overview what inheritance means for the different sections within FESA:
  • interface:
    • Each property defined by any base class is inherited.
    • A derived class can override a property defined by a base class by defining a property with the same name regardless of the property definition.
    • An abstract class can defined properties without providing any implementation, that is to say in the FESA world, without providing the related server- action. ( This is similar to the concept of “interface” in object-oriented programming languages, which allow defining a contract, that any derived class should implement.)
  • data:
    • The data-model defined by the base classes are fully inherited. The field names have to be unique across all the inherited data model.
  • action:
    • server-action:
      • Each server- action defined in any base class is inherited.
      • A concrete class extending an abstract class should provide the implementation of any abstract-server-action defined by the base classes. The name of the server-action has to match the name of the abstract action.
    • rt-action:
      • Each rt-action defined in any base class is inherited. These actions can be scheduled in the derived class.
      • A derived class can override a rt-action defined by any base class by defining a rt-action with the same name.
      • As well it is possible to define an abstract-rt-action in the base-class. This action needs to be implemented in the derived class.

6. Interface

In this section the set of services published to the outside ( clients from the control-room or middle-tier software layer) is defined. Designing an equipment’s interface involves listing so-called properties that can be remotely accessed through the controls-middleware.

6.1. Device-interface

The device-interface groups all the properties which are device-specific. They can be thought as non-static methods in an object-oriented languages. Therefore accessing a device-interface property will require a device-instance.

6.1.1. Setting

This element is meant to group all the setting properties defined by a FESA class which can be used by clients to control the equipment, using the controls middleware.

General information about setting properies can be found here.

6.1.2. Acquisition

This element is meant to group all the acquisition properties defined by a FESA class which can be used by clients to acquire equipment's data, using the controls middleware.

General information about acquisition properies can be found here.

6.2. Global-interface

The Global-interface groups all the global device properties which can be thought of as static methods in an object-oriented languages. Therefore accessing a global-interface property will require to use the global-device.

6.2.1. Setting

This element is meant to group all the setting properties defined by a FESA class which can be used by clients to control the equipment, using the controls middleware.

General information about setting properies can be found here.

6.2.2. Acquisition

This element is meant to group all the acquisition properties defined by a FESA class which can be used by clients to acquire equipment's data, using the controls middleware.

General information about acquisition properies can be found here.

6.3. Interface - shared definitions

In order to avoid duplication, the context of the chapters below is used by different other chapters.

6.3.1. Property

A FESA-property is considered as interface to the outside-world. Clients can use properties in order to obtain data from a FESA-class, or to send data to the class.

Within a property the class developer can define the data which send to(received by) the client in so called value-items.

Furthermore the class developer has to define server- actions for the property. A get- or set-call, triggered by any client, causes the property to execute a server- action which handles the client request.

Properties are roughly structured into tree types:
  • acquisition-property
  • setting-propertys
  • command-propertys

    • All tree types are available as global-, and as device-properties. Furtermore specialized property-sub-types can be avaiable, which all base on these three types.

    6.3.2. Setting-property

    A setting- property can be accessed in write-mode( set) in order to set specific values of the class or in read( get, subscription) mode in order to obtain the current settings.

    6.3.3. Command-property

    A command property can be accessed only in write-mode( set). Most of the time such a property implements actions like "Reset" or "Calibrate" Usually the corresponding server- actions can be operated whitout any particular data sent by the client.

    6.3.4. Acquisition-property

    An acquisition- property can be accessed only in read( get, subscription) mode.

    6.3.5. GSI-Setting-Property

    This GSI-specific Setting property expands the basic FESA-Setting property.

    It is used by GSI-operations to control all parameters of the device.

    One instance of this property-type has to be named "Setting". In this instance all frequently used data, needed for daily operations should be gathered.

    For exotic values, which are not used in daily operations, additional GSI-Setting-Properties should be defined.

    The two properties "Setting" and "Acquisition" are related, and it is recommended to use the same value-items in both properties where this is applicable. For instance, for a motor, both the Setting and the Acquisition property should contain a value-item “position”. The position item in Setting is used to control the position, whereas the position item in Acquisition is used to return the measured value.

    6.3.6. GSI-Init-Property

    This GSI-specific property is used to reinitialize the device with its default values (loaded from the device-instance xml file TODO: Implement GSI-Specific action to do so). This is a write-only operation.

    6.3.7. GSI-Power-Property

    This GSI-specific property is used to enable or disable a device or to put it in standby mode. The Power property is write-only.

    6.3.8. GSI-Reset-Property

    This GSI-specific property is used to reset the hardware-device. All persistent values should be kept. This is a write-only operation.

    Please note that it will not be possible to read values from the device during restart.

    6.3.9. alarm-event-property

    This GSI-specific property is still under construction. (Currently the same than used at CERN).

    Since this property is not tested at all, and may change in the future, it is recommended to do'nt use it for now.

    6.3.10. GSI-Acquisition-Property

    This GSI-specific Acquisition property expands the basic FESA-Acquisition property. by the multiplexing-context-item.

    It is used by GSI-operations to retrieve acquisition-data from the hardware. It also contains information on the circumstances under which the acquisition was made.

    One instance of this property-type has to be named "Acquisition". In this instance all frequently used data, needed for daily operations should be gathered.

    For exotic values, which are not used in daily operations, additional GSI-Acquisition-Properties should be defined.

    6.3.11. GSI-Version-Property

    This GSI-specific Acquisition property expands the basic FESA-Acquisition property by the version-item.

    The name of the GSI-Version-Property always is "Version". It can be used by clients in order get the current Class-Version, the used FESA release, the DeployUnit release, Hardware-Firmware versions and any other versioning-strings.

    The basic version-items "class_version", "deploy_unit_release" and "fesa_release" are automatically filled by the framework.

    6.3.12. GSI-Status-Property

    This GSI-specific acquisition property expands the basic FESA-Acquisition property by some GSI-specific value-items.

    The name of the GSI-Status-Property always is "Status". It contains information about the state of the device and shall give the operator an overview whether the device works correctly. If the device doesn't work properly the status property gives a hint of what could be wrong.

    The Status property shall be used to report errors in the hardware only. Errors in the control system shall be reported using exceptions.

    The difference between the Status property and the _status field-suffix (c.f. type AQN_STATUS) is the following:
  • The Status property represents the status of the whole device.
  • The suffix _status refers to one control value only.
  • Status is not cycle dependent, whereas _status can be cycle dependent.

    • 6.3.13. global-alarm-event-property

    This GSI-specific property is still under construction. (Currently the same than used at CERN).

    Since this property is not tested at all, and may change in the future, it is recommended to do'nt use it for now.

    6.3.14. power-item

    The GSI-specific power-item automatically transforms the GSI-power-field in a data-format which is supported by the rda-middleware.

    For general information about value items, refere to the general value-item documentation.

    6.3.15. multiplexing-context-item

    The GSI-specific multiplexing-context-item automatically transforms the GSI-multiplexing-context-field in a data-format which is supported by the rda-middleware. This allows the usage of default-server actions when referencing a multiplexing-context-field.

    For general information about value items, refere to the general value-item documentation.
    • direction
    • acqStamp The timestamp which indicates when the acquisition data was measured.
    • cycleStamp The timestamp which indicates when the cycle started on which the acquisition data was measured.
    • cycleName The name of the cycle on which the acquisition data was measured.
    • data-field-ref

    6.3.16. version-item

    The GSI-specific value-item is used to add a version-name in combination with a version string to the rda middleware.

    For general information about value items, refere to the general value-item documentation.
    • direction
    • name
    • array The char-array, where the version-string will be stored.

    6.3.17. status-item

    This GSI-specific item is used to automatically transforms the GSI-status-field in a data-format which is supported by the rda-middleware.

    For general information about value items, refere to the general value-item documentation.

    6.3.18. detailed-status-item

    This GSI-specific item is used to automatically transforms the GSI-detailed-status-field in a data-format which is supported by the rda-middleware.

    For general information about value items, refere to the general value-item documentation.

    6.3.19. mode-item

    This GSI-specific item is used to automatically transforms the GSi-mode-field in a data-format which is supported by the rda-middleware.

    For general information about value items, refere to the general value-item documentation.

    6.3.20. control-item

    This GSI-specific item is used to automatically transfor the GSI-control-field in a data-format which is supported by the rda-middleware.

    For general information about value items, refere to the general value-item documentation.

    6.3.21. error_collection-item

    The GSI-specific error_collection-item automatically transforms the GSI-error_collection-field in a data-format which is supported by the rda-middleware. This allows the usage of default-server actions.

    For general information about value items, refere to the general value-item documentation.
    • direction
    • error_codes Array of error-codes, which is send to rda.
    • error_messages Array of error-messages, which is send to rda.
    • error_timestamps Array of error-timestamps, which is send to rda.
    • error_cycle_names Array of error-cycle-names, which is send to rda.
    • data-field-ref

    6.3.22. Property Description

    The description provides a short explanation of what the property does.

    6.3.23. Proprty-name

    The name of a property is unique within a FESA class

    6.3.24. Multiplexed

    "TRUE" means that this property supports the usage of multiplexed data.

    6.3.25. Visibility

    This attribute indicates clearly the property category, allowing, for instance to make a distinction between the operational interface and the expert interface. The different options are:
    • operational: The property is used by the operating to control the accelerator.
    • expert: The property is dedicated to experts and should not be used by operational applications.
    • deprecated: This is a warning, saying that this property should not be used anymore, since it may disappear within the next versions of this class.
    The visibility is as well used to manage the FESA class life-cycle. For instance it should not be possible to change an “operational” property as soon as a FESA class is operational.

    6.3.26. On-Change

    This attribute tells if the property supports subscribption using "on_change". A client subscribing to a class, using "on-change" mode, will only receive data if it's different from the previous data. While without using "on-change" the data is received even if it's still identical to the previous one.

    6.3.27. Subscribable

    This attribute tells if the property supports usage of subscription. For example it could make sense to forbid subscription for an expert acquisition-property, which returs a huge amount of data.

    6.3.28. Server-action-ref

    Used to refer to a server- action which will be executed when this property is triggered by a client( get/ set/ subscription). The server-action has to be defined previously in the "actions" element.
    • Attributes:
      • server-action-name-ref: Contains the name of the server- action. (All available actions are displayed in a drop-down box)

    6.3.29. Abstract-server-action

    An abstract-server- action can only be created in an "abstract" class and has to be implemented by each derived class. In the abstract base-class no implementation has to be provided. Refere to the chapter " inheritance" for more information.
    • Attributes:
      • server-action-name: Contains the name of the server- action. (All available actions are displayed in a drop-down box)

    6.3.30. Value-item

    The data-container which is transfered when the client triggers a property via " get", " set" or subscription is a composite structure that is build of one or several so called "value-items". This concrete value item defines one value, which is passed between the client and the FESA class. The value which is passed may either be copy of a internal data-field, or any other user defined value.
    • Attributes:
    • Children:
      • data-type
      • data-field-ref (optional item) A reference to a data-field can only be used when the passed value can be inserted in(or extracted to) the corresponding data-field without any specific treatment. Of course, the type of the value-item is constrained to be identical with the type of its related data-field. By linking together the value-item with an internal data-field, the transfer of data between the value-item and its related data-field is managed by the Framework.
      • data-field-bit-ref When the type of a data-field corresponds to a bit-pattern, you may select individual bits within the word. In this case only this particular bit will be transmitted across the middleware as a boolean value-item.
      • unit

    6.3.31. Filter-item

    Filter-items provide the option to fine-tune the execution of server- actions by passing additional data elements. The structure of a filter-item is the same as for the value-item, apart from the fact that its entries never reference existing data-field and are always defined within the filter’s naming scope.

    As an example, filters could be used for data conversion, low-pass or filtering and averaging of measurements, selection or a particular signal component or time-window, or parameters of a signal transform (e.g. radix of an FFT).

    6.3.32. Priority-offset

    Within the priority offset of a property one can adjust the priority level which will be used to execute the connected server- actions.

    6.3.33. Cycle-stamp-item

    The cycle-stamp-item describes the time when a specific cycle in which the acquisition was done, has started. It is only relevant for multiplexed properties.

    6.3.34. Cycle-name-item

    The cycle-name-item contains the name of the cycle in which the acquisition was done. It is only relevant for multiplexed properties.

    6.3.35. Update-flag-item

    This item is only relevant for subscription. It indicates the type of the client notification. (initial update, normal update, or update triggered by a foreign clinet-set)
    • Attributes:
    • Children:
      • custom-type-scalar: The data-type of the update-flag-item is always a custom-type-scalar, named NOTIFICATION_UPDATE

    6.3.36. Acquisition-stamp-item

    The acquisition-stamp-item describes the concrete time when the acquisition-data was measured.

    6.3.37. Set-action

    When a client triggers a " Set" of this property using the controls middleware, a set-action will be triggered. Here you can define which set-action you would like to trigger for this property.
    • Attributes:
      • partial-setting: Boolean value saying that the composite data defined by the property can be seen as a set of individual data entries, which can be set individually or by any arbitrary grouping. If partial-setting is false, the client has to send the property data as a whole.
      • transaction
    • Children:

    6.3.38. Get-action

    When a client triggers a " get" of this property using the controls middleware, a get-action will be triggered. Here you can define which get-action you would like to trigger for this property.

    6.3.39. Item-name

    Defines the name of the property-item. This name will be the name of the data-entry in the data container of this property, which is transfered between the client and the FESA-class. The name should be unique in the scope of the property definition.

    6.3.40. Optional

    TODO: What does optional mean?

    6.3.41. Data-type

    Defines the data-type, used for this item.

    6.3.42. ID

    This attribute provides a document-wide unique identifier for the value-item. It is automatically generated on purpose, with the aim of managing the Fesa Class life cycle.

    6.3.43. Direction

    Defines the direction of the data-flow. Possible options: Depending of the context in which the value-item is defined, the direction can be predefined and fixed (immutable). For example value-items defined in the context of an acquisition-property have a fixed value equal to "OUT". Recommendations: for setting-property this attribute needs to be set conscientiously for each value-item, knowing that some value-items are just read-only values, meaning that they are present only when getting the property.

    7. Custom-types

    Besides the fesa-data-types, it is possible to define "custom data types" in FESA. Some of the custom-types are already predefined and used by the framework, others are class-specific.

    7.1. Constant-unsigned-int

    This Type allows to define unsigned int constants. Such constants e.g. can be used to define array dimensions of fields. For histrorical reasons this sub-type was not yet integrated in the type "Constant".
    • Attributes:
    • Children:
      • description: Here you can put a short description of this unsigned int constant.

    7.2. Constant

    This Type allows to define any type of constant.(only unsigned int constants are treat seperately for historical reasons)
    • Attributes:
      • name
      • value
      • type: Enumeration specifying the type:
        • const bool: Boolean value
        • const signed char: Signed byte value
        • const char*: Pointer to character
        • const short: Short value
        • const long: Long value (signed)
        • const long long: Long long value (64 bits)
        • const float: Float value
        • const double: Double value (Scientific notation is supported)
    • Children:
      • description: Here you can put a short description of this constant.

    7.3. Enum

    This type allows to specify an enumeration by adding items for each possible enumerated value.
    • Attributes:
    • Children:
      • description
      • item: Items are used to specify values for the enumeration
        • Attributes:
          • symbol: Specifies the name of this item.
          • value
          • access

    7.4. State-enum

    This type allows to specify an device-status enumeration. A state-enum contains some predefined states which may be used by the class-developer.

    7.4.1. State

    This item allows to specifiy a state in detail.

    7.5. Bit-enum

    This custom-type allows to define bit pattern of 16 and 32 bits.
    • Attributes:
      • name: Defines the name of this bit-enum
    • Children:
      • description: Here you can put a short description of this bit-enum.
      • bit : One of the bits of the bit-enum.
        • Attributes:
          • name: Defines the name associated with this bit.

    7.6. Custom-types - shared definitions

    In order to avoid duplication, the context of the chapters below is used by different other chapters.

    7.6.1. Access

    "Access" describes the access type which can be used for an item.
    • RO: Read only (not settable).
    • WO: Write only (settable but nor readable).
    • RW: Read write (settable and readable).

    7.6.2. Name

    The name of the custom-type, constrained by the pattern: ([_A-Za-z])([_A-Za-z0-9:])*

    7.6.3. Value

    This item contains the value which is used for this constant.

    7.6.4. Meaning

    This item contains standardized values to add information about the state of the equipment. The different meanings are:
    • ON: The equipment is ON/enabled.
    • OFF: The equipment is OFF/disabled.
    • WARNING:There is a non-blocking situation worth knowing about.
    • ERROR: There is a problem with the controlled equipment or the control chain.
    • NONE: There is no standard meaning associated with the value. This is the default value.

    8. Data

    At the heart of any equipment-software, the device-model represents the software abstraction of an underlying device. This is a data-holder of which the attributes are continuously transferred to and from the hardware in order to ensure that the real device and its software are synchronized at run-time. Specifying a proper device-model is one of the most important steps of equipment-software design and it consists in defining a set of fields. Every piece of information about the underlying hardware-device is stored as field.These fields are structured into the following categories:

    8.1. Device-data

    Device-data groups all the device- fields which can be thought non-static variables in an object-oriented languages. Therefore accessing a device-data field will require a device-instance.

    8.1.1. Configuration

    Configuration-fields are only initialized once. After startup of a FESA-class they keep their value and are not changed any more. All configuration fields are read-only fields.

    8.1.1.1. HW-address

    This field is used to store hardware adresses.

    8.1.1.1.1. Host

    Here you can fill in detailed information about a hardware-address.
    • Attributes:
      • port-number: A boolean enumeration which is used to specify whether the port number is needed or not.
      • name: The name of the host.
    • Children:
      • description: Here you may add a description about the defined host.

    8.1.1.1.2. Logical-address

    Here you can specify a logical-address which may be necesarry to use the defined hardware-address.
    • Attributes:
      • name: The name of the logical address.
    • Children:
      • description: Here you may add a description about the defined logical-address.

    8.1.1.2. Device-relations-field

    Used for the association-relationship. ( TODO: add usefull info here )
    • Attributes:
      • name: The name of the device-relations-field.
    • Children:
      • description: Here you may add a description about the defined device-relations-field.

    8.1.1.3. Event-field

    Event fields are used to represent FESA internal events.
    • Attributes:
      • name: The name of this event-field.
    • Children:
      • description: Here you may add a description about the defined event-field.

    8.1.2. Setting

    Setting- fields are used to store values which are needed to control the hardware-equipment.

    8.1.3. Acquisition

    Aquisition-fields fields are used to store data, which was produced by the hardware-equipment.

    8.2. Global-data

    The global-data groups all the global fields which can be thought of as static variables in an object-oriented languages. In the code they can be accessed by using the global-instance.

    8.2.1. Configuration

    Configuration- fields are only initialized once. The values for initialization are provided by the instantiation-document

    After startup of a FESA class they keep thair value and are not changed any more. All configuration fields are read-only fields.

    8.2.2. Setting

    Setting- fields are used to store values which are needed to control the hardware-equipment.

    8.2.3. Acquisition

    Aquisition- fields are used to store data, which was produced by the hardware-equipment.

    8.3. Timing-domain-data

    Accelerator facilities are often seperated into different timing domains to seperate between the timing of different sub-accelerators which need to work together. Here fields which are timing-domain specific can be stored.

    8.3.1. Configuration

    Configuration- fields are only initialized once. The values for initialization are provided by the instantiation-document

    8.4. Data - shared definitions

    In order to avoid duplication, the context of the chapters below is used by different other chapters.

    8.4.1. Field

    A field in FESA is used to store data, which either comes from the physical-device, or from a client. There are tree main field-types, and some specialized types, which can be used. The main types are:

    8.4.2. Configuration field

    Configuration- fields are only initialized once. The values for initialization are provided by the instantiation-document

    8.4.3. Setting field

    Setting- fields are used to store values which are needed to control the hardware-equipment.

    8.4.4. Acquisition field

    Aquisition- fields are used to store data, which was produced by the hardware-equipment.

    8.4.5. Fault-field

    A fault- field is used to indicate a internal status. (Similar to the alarm-field, but only for internal usage)

    8.4.6. Acquisition state-field

    An aquisition-state- field indicates the current state of e.g. the hardware-equipment or some measurement values. An acquisition state-field and can be used to inform clients about state-changes.

    8.4.7. Setting state-field

    Different from the acquisition-state-field, a setting-state-field is used to request for new states. E.g. a client may send a state, which should be gained by the hardware-device.

    8.4.8. Acq-stamp-field

    An aquisition-stamp- field can store the value of an acquisition-stamp. The acquisition-stamp e.g. can be obtained from the timing-event or from the hardware-device.
    • Attributes:
    • Children:
      • description Here you can describe the usage of this field.
      • scalar: The data-type of the acq-stamp-item is always a long-long scalar

    8.4.9. GSI-power-field

    This GSI-specific setting field is used in order to enable or disable the device. As well it is possible to use a standby-mode if defined.

    The used enumeration "DEVICE_MODE_POWER" allows the following values:
  • 1 ON: The device is in fully operational state
  • 2 OFF: The device is turned off
  • 3 ...: To be defined per class, by the class developer

    • Please note, that every state in "DEVICE_MODE_POWER" as well has to exist in "DEVICE_MODE", in order to check, if the state-change was successfull.

    If needed, the developer may add a „standby“ mode, which signals, that the device is in a kind of parking mode. A „Standby“ mode is defined by the following charactersitics:
  • It is save
  • It does not wear out
  • It consumes little energy
  • It takes short time to go from „standby“ to „ON“

    • 8.4.10. GSI-multiplexing-context-field

    This GSI-specific acquisition field is used to store multiplexing-information of acquisition data.

    The used structure-datatype "GSI_MUX_CONTEXT" consists of the following items:
  • acqStamp: stores the time when a measurement was done (UTC in nanoseconds)
  • cycleStamp: stores the time, when the current cycle has started. Only if available. (UTC in nanoseconds)
  • cycleName: stores the name of the cycle which started at "cycleStamp". Only if available.

    • More information on how to use the field in a RT-Action can be found here

    8.4.11. GSI-status-field

    This GSI specific field describes the summary of the device status. The status should be coherent with active alarm fault states.

    The used enumeration "DEVICE_STATUS" allows the following mutually exclusive values:
  • 0 UNKNOWN: The device status is unknown
  • 1 OK: The device is in fully operational state
  • 2 WARNING: The device is not fully operational; A device in WARNING state can still be used operationally, but clients must be informed of a problem that might become worse. Details should be explained in the error_collection field
  • 3 ERROR: The device is in a fault state. Details should be explained in the error_collection field

    • The enumeration-value should always be coherent with the active alarm-state.

    8.4.12. GSI-detailed-status-field

    This GSI specific field in detail shows the current state of the device(not mutually exclusive). Each bit of this bit-field can be used to model one device-sub-state.

    This field is used to complement the information contained in the status field.

    The used bit-enumeration "DETAILED_STATUS" has to be defined by the class developer:
  • Bit0: MY_FIRST_STATE To be defined per class, by the class developer
  • Bit1: MY_FIRST_STATE To be defined per class, by the class developer
  • Bit2: ...

    • 8.4.13. GSI-mode-field

    This GSI specific field describes the mode, in which the device currently is operating.

    The used enumeration "DEVICE_MODE" allows the following mutually exclusive values:
  • 0 UNKNOWN: The device mode is unknown
  • 1 ON: The device is in fully operational state
  • 2 OFF: The device is turned off
  • 3 STANDBY: The device is in a stand-by mode. This mode is a sort of “parking mode” in which the device can stay for hours or even days. It is defined by the following characteristics:

    • It is safe
    • it does not wear out
    • it consumes little energy
    • it takes a short time to go from STANDBY to ON mode

  • 4 POWER_DOWN: The device is shutting down. Note that some properties may not be accessible during this time. After shutdown the device will be in the mode OFF
  • 5 POWER_UP: The device is starting up. Note that some properties may not be accessable during this time. After (re)starting the device probably will be in the mode ON
  • 6 INTERLOCK: The device received an interlock and therefore is currently not operational. The device-state should be switched to error when this mode is used
  • 7-127 RESERVED: Reserved for further unification
  • 128 MY_FIRST_MODE : To be defined per class, by the class developer
  • 129 MY_SECOND_MODE : To be defined per class, by the class developer
  • 130 ...

    • 8.4.14. GSI-control-field

    This GSI specific field describes if the device is controlled remotely or local.

    The used bit-enumeration "DEVICE_CONTROL" allows the following values:
  • 0 REMOTE: The device is controlled normally through the control system
  • 1 LOCAL: The device is controlled locally. But it can be accessed in read-only mode via the control system

    • 8.4.15. GSI-error_collection-field

    The GSI-specific error_collection-field is designed as Ringbuffer of the depth [MAX_NUMBER_OF_ERROR_MESSAGES]. It stores all active error messages, thair corresponding error-codes, timestamps and cycle-names.

    The field provides the method addError(...) which should be used to report errors. It automatically takes care for the ringbuffer-aspect, provides an error-timestamp and saves the error as log-message in the logging-system.

    More information on how to use the method can be found here

    For permanent state-changes of the device, if triggered by an error, as well an appropriate alarm should be raised.

    The error_collection array has the leangth "MAX_NUMBER_OF_ERROR_MESSAGES". Each element has the struct-type "GSI_ERROR" which provides the following values:
  • error_string: The variable error-string of the error. To be filled by the class-developer via AddError(...). The maximum leangth of this string is defined by the constant "MAX_ERROR_MESSAGE_LENGTH".
  • error_code: The error code currently is only a placeholder. Later each device will have predefined error-codes.
  • error_timestamp: An error-timestamp will be automatically added by using the method addError(...). The stamp is saved as string with a maximum leangth of [MAX_TIMESTAMP_LENGTH].
  • error_cycle_name: As well the cycle-name will be automatically filled by using the method addError(...). The maximum leangth of this string is defined by the constant [MAX_CYCLE_NAME_LENGTH].

    • 8.4.16. alarm-field

    This GSI-specific field is still under construction. (Currently the same than used at CERN).

    Since this field is not tested at all, and may change in the future, it is recommended to do'nt use it for now.

    8.4.17. global-alarm-field

    This GSI-specific field is still under construction. (Currently the same than used at CERN).

    Since this field is not tested at all, and may change in the future, it is recommended to do'nt use it for now.

    8.4.18. telegram-group-field

    This GSI-specific field is still under construction. (Currently the same than used at CERN).

    Since this field is not tested at all, and may change in the future, it is recommended to do'nt use it for now.

    8.4.19. Default

    by adding a default-node, a device-specific default value will be used to initialize this field.

    This value has to be filled in the instantiation document of the according front-end.

    8.4.20. Name

    Here you can specify the name of this field.

    8.4.21. Persistent

    Boolaen value. Persistance is a service which can be used for setting-fields. If enabled, the actual value of the corresponding field is always saved in a so called "persistancy-file".

    If the FESA class is restarted, the value of this field, stored in the persistancy-file, will be used to initialize the field on the new startup.

    8.4.22. Multiplexed

    Boolean value
    • TRUE: Means that this field exists multiple times. To identify the right field-instance a so called " cycle-descriptor" needs to be used.
    • FALSE: Means that there is only a single instance of this field.
    Detailed information about "multiplexing" can be found here.

    8.4.23. Extra-Multiplexed

    For setting-fields it is possible to add additinal multiplexing criteria which are defined in the instantiation-document. This flag indicates, that the corresponding field uses these additional criteria.

    For each extra-criteria, the existing entities of the field are doubled.

    E.g. If the field uses normal multiplexing, having 12 different cycles: 12 entities.

    If six extra-criteria are added: 12 * (6+1) = 84 entities of the field.

    The additional information to identify the right entity of the field is extracted from the payload of the Timing-System.

    8.4.24. Multiplexing

    Enumeration. For acquisition-fields it is possible to choose between different types of multiplexing. Generally one can say multiplexing means, that a field exists multiple times. To identify the right field-instance a so called " cycle-descriptor" needs to be used. The possible opions for acquisition fields are:
    • CYCLE_TYPE: This field exists once per defined cycle-descriptors.
    • CYCLE_OCCURRENCE: There are X occurences of the field, managed by a ring-buffer. The size "X" of the ring-buffer can be defined in the instantiation-document.
    • NONE: Means that there is only a single instance of this field. No cycle-descriptor is necesarry to identify the right instance.
    Detailed information about "multiplexing" can as well be found here.

    8.4.25. Severity

    Enumeration, which describes the seriousness of something. Possible values:
    • ERROR: There is a serious problem.
    • WARNING: There is a non-blocking situation worth knowing about.
    • OK: Ther is no problem at all.

    9. Actions

    Actions are a component of the framework, where actually something happens. There are different types of actions for different purposes. Some are automatically generated by FESA, others need to be filled by the class developer. Take a look into the different actions to see their purpose.

    9.1. Get-server-action

    A get-server-action can be triggered by " get" command of a client, or a subscription. Usually it is used to read out acquisition-fields and send the data to the client.

    Each setting-property and each acquisition-property needs to implement a get-server-action.

    9.2. Set-server-action

    A set-server-action can be triggered by a " set" command of a client. Usually it is used to write client data into setting-fields.

    Each setting-property and each acquisition-property needs to implement a get-server-action.

    9.3. RT-action

    RealTime-actions execute user-specific code. They are used to do any kind of harware interaction. RealTime actions are started with high RT-priorities, which allows them to delay e.g. server-actions and communicate with the hardware in minimum time.

    9.4. Abstract-RT-action

    An abstract RealTime-action has no implementation in the base-class. However, the child-class needs to provide an implementation for the action.

    9.5. Actions - shared definitions

    In order to avoid duplication, the context of the chapters below is used by different other chapters.

    9.5.1. Notified-property

    Whenever this action is executed, the defined properties will trigger a client-update for all clients which have a subscription to the property.
    • Attributes:
      • property-name-ref: Choose the property you want to notify from this enumeration.

    9.5.2. Fire-on-demand-event

    Set-server-actions and rt-actions have the possibility to trigger the start of other rt-actions using on-demand-events. Here you can specify which on-demand-event will be fired.
    • Attributes:
      • on-demand-event-name-ref: Choose the on-demand-event you want to fire from this enumeration.

    9.5.3. Disabling-alarm

    Within this item you can force a server-action to automatically lower the alarm state of an alarm-field, when the action is executed.
    • Attributes:
      • alarm-field-name-ref: Choose the alarm-field you want to lower from this enumeration.

    9.5.4. Disabling-fault

    Within this item you can force a server-action to automatically lower the severity state of a fault-field, when the action is executed.
    • Attributes:
      • fault-field-name-ref: Choose the fault-field you want to lower from this enumeration.

    9.5.5. Implementation

    By this enumaration you can choose if you want to fill the server-action at your own, or if you want to use a predefined action
    • custom: You have to fill the server action at your own.
    • default: A generic, framework internal server action will be used.
    Usually the generic default action satisfies all basic needs. Only if you need to e.g. perform some unique data-operations, you need do a custom-implementation.

    9.5.6. Action name

    Give a meaningful name to your action, which describes the activity it is made for.

    9.5.7. Description

    Here you can further explain the purpose of this action.

    10. Events

    Any type of event, and as well the corresponding event-sources can be defined here. Logical-events in FESA are used to trigger the execution of rt-actions.

    10.1. Event Sources

    A event source describes a source of a FESA-internal event. All sources, defined here will be instantiated.

    10.1.1. Timer-event-source

    The timer-event-source is a FESA internal "pulse-generator". For each defined logical-timer-event you can specify a period in the instantiation document of each front-end.
    • Attributes:
      • name:The name of this event source is always the fixed string "Timer"

    10.1.2. Timing-event-source

    The timing-event-source uses the events of the accelerator-timing in order to trigger the execution of rt-actions. The binding between a FESA-internal logical-event and a real timing event is front-end-specific, and therefore done in the instantiation document.
    • Attributes:
      • name:The name of this event source is always the fixed string "Timing"

    10.1.3. Custom-event-source

    If you need to implement a trigger for the execution of rt-actions at your own. (E.g. events sent by the equipment-harware), this event source allows you to do so. By choosing a custom-events-source, the framwork will generate a empty event-source for you, which you can implement according to your own needs.
    • Attributes:
      • name:Give a meaningful name to your custom-event-source.
    • Children:
      • description:Here you can describe the purpose of your custom-event-source.

    10.1.4. On-demand-event-source

    The on-demand-event-source is used to trigger the execution of one rt-action by another rt-action, or by a set-server-action. The "fire-on-demand-event" item can be attached directly to the action in the class design.
    • Attributes:
      • name:The name of this event source is always the fixed string "OnDemand"

    10.1.5. On-subscription-event-source

    The On-subscription-event-source allows to subscribe as client to properties of foreign FESA classes and to react on value-updates of these properties by executing a rt-actions. More information about this concept can be found here.
    • Attributes:
      • name:The name of this event source is always the fixed string "OnSubscription"

    10.2. Device-events

    Device-events allow to map a FESA internal logical-event to many different concrete-events per device-instance, which can be defined per device in the instantiation document.

    10.3. Global-events

    A global event is identical for each device. The maping to the concrete-event is done in the global part of the instantiation document.

    10.4. Events - shared definitions

    In order to avoid duplication, the context of the chapters below is used by different other chapters.

    10.4.1. Logical-event

    A logical event describes a FESA-internal event. The mapping to the concrete-event is done in the instantiation document.
    • Attributes:
      • use:( TODO: add usefull info here )
        • required: ( TODO: add usefull info here )
        • optional: ( TODO: add usefull info here )
      • name: Provide a meaningful name for this logical event.
      • type: There are two possible types:
        • single: Per device, only one concrete-event is mapped to this logical-event in the instantiation document.
        • multiple: It is possible to map many different concrete-events to this logical-event in the instantiation document.
    • Children:
      • description: Add a description what the this logical-event is used for.
      • source-ref: Specify which event-source is used to fire this event.
      • event-field-ref: Reference to the event-field of this logical event.

    11. Scheduling-units

    Scheduling-units are used to freely map the different FESA-internal logical-events to rt-actions.

    11.1. Scheduling-unit

    A scheduling unit creates a 1 to 1 realtion between a logical-event and a rt-action. Whenever the choosen logical-event is triggered, the corresponding rt-action will be executed.
    • Attributes:
      • name:Give some meaningful name to the scheduling unit.
    • Children:
      • selection-criterion
      • rt-action-ref:
        • Attributes:
          • rt-action-name-ref:Choose a rt-action from this enumartion.
      • logical-event-ref:
        • Attributes:
          • logical-event-name-ref:Choose a logical-event from this enumartion.

    11.1.1. Selection-criterion

    A selection criterion allows to execute a rt-action not for all device-instances of a class, but only for a choosen selection.

    11.1.1.1. Selection-rule

    Here a selection-rule can be defined in order to group a collection of device-instances for which the rt-action will be executed.
    • Attributes:
      • selection-rule-name: Provide a meaningful name for this selection rule.
    • Children:
      • unary-operation: Only one criteria, a so called "operand" is used to check if a device-instances belongs to the device-collection.
        • Attributes:
          • operand-name-ref: Add some text here
      • binary-operation

    11.1.1.2. Operand

    An operand either can be true or false for a specific device-instance. This either is defined by one of the device's fields, or by logically conected collection of sub-operands.

    11.1.1.2.1. Field-selection

    Here you can specify the field, which you want to check in order to figure out if a operand is "true" for a specific device-instance.
    • Children:
      • field-ref/base-field-ref/hw-field-ref: Choose a field from one of the enumartion types.
      • field-value: ( TODO: add usefull info here )
      • implicit: ( TODO: add usefull info here )
      • explicit: ( TODO: add usefull info here )

    11.2. Scheduling-units - shared definitions

    In order to avoid duplication, the context of the chapters below is used by different other chapters.

    11.2.1. Binary-operation

    For a device-instance the result of these two logical connected criteria( operands) needs to be true, to be part of the device-collection.
    • Attributes:
      • operand1-name-ref: Choose a operand from this enumartion.
      • operation: The binary operation which connects the two operands.
      • operand2-name-ref: Choose a operand from this enumartion.
        • AND: Binary-operation is true, if both operands are true.
        • OR: Binary-operation is true, if one of the operands is true.

    12. Include

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

    It is used to receive the definition of the base-class when a FESA-class defines an "inheritance" relationship with another class. The definition 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 inheritance of the direct base classes working. The base-class itself can include the information of upper classes in case where the inheritance depth is more than 2.

    13. Equipment Model - Shared Definitions

    In order to avoid duplication, the context of the chapters below is used by different other chapters.

    13.1. Fesa data type

    Currently, data-types are restricted to the ones supported accross the whole controls system by the communication layer, which comprises the list illustrated in the table below:

    Scalar types Uni-dimensional array types Bi-dimensional array types
    bool bool bool
    signed char (byte) signed char (byte) signed char (byte)
    short short short
    long long long
    long long long long long long
    float float float
    double double double
    - char (string) char (string[])

    13.1.1. Scalar

    The scalar-type is the most basic FESA-data type one can choose. It only represents a single data-element.

    13.1.2. Array

    The array-type is used to represent a array of scalars.

    13.1.3. Array2D

    Similar to the array, but for an additional dimension.

    13.1.4. Custom-type-scalar

    Represents a scalar value which defines a custom-type as data-type.

    13.1.5. Custom-type-array

    The array-type is used to represent a array of custom-type-scalar.

    13.1.6. Custom-type-array2D

    Similar to the custom-type-array, but for an additional dimension.

    13.1.7. Dim

    Allows you to specify directly the array dimension by providing an unsigned value.

    13.1.8. Custom-constant-dim

    Allows you to specify the array dimension by referring to a constant-unsigned-int, which was previously defined in the custom-types.
    • Attributes:
      • constant-name-ref: Contains the reference to the constant.

    13.1.9. Variable-dim

    Allows you to specify that the dimension is defined per device in the instantiation-document. Optionally, one can specify the maximum and minimum limit if it's relevant.
    • Children:
      • min: Min value.
      • max: Max value.

    13.2. Data-field-ref

    Used to map this item to an existing internal data-field.
    • Attributes:
      • field-name-ref: contains the reference to the internal data-field

    13.3. Data-field-bit-ref

    Used to map this item to one bit of an existing internal data-field.
    • Attributes:
      • field-name-ref: contains the reference to the internal data-field
      • bit: used to specify the bit to export (starting from 0)

    13.4. Data-type-name-ref

    Contains the reference to the custom-type. Custom-types for value-items can be only constants, enumeration or bit-pattern. Therefore is not possible to refer a complex type, like C-structure. This restriction was brought by the middle ware layer which is able to transport only types shown in the above table. However, internal data-field doesn't have such a restriction.

    13.5. type

    Allows you to select a type from an enumeration which contains all the supported types as shown in the above table

    13.6. Unit

    Allows to specify in which unit the value is expressed
    • Attributes:
      • USI: select of unit from a predefined list containing most common units
      • exponent: allows to specify a power of ten to produce a multiple of the original unit.

    13.7. Concepts used in the FESA-Framework

    13.7.1. Device-Instance

    A device-instance is an software-instance of the corresponding underlying physical device. Since a FESA-class can manage many physical devices of the same type, for each of these physical devices one device-instance has to be defined in the instantiation-document.

    In actions device-instances are needed in order to identfy the right device. As well a client needs a device-handle in order to connect to the right devie-instance.

    13.7.2. Global-Instance

    A global-instance in FESA is used to describe all parts of the class, which are not device-specific. There is only one global-instance in each FESA-class. The name of this global-instance has to be defined in the instantiation-document.

    In actions a global-instance is needed in order to use the global-device. As well a client needs a device-handle of the global-device if he wants to connect to it.

    13.7.3. Setting

    The keyword "Setting" describes the direction of the data-flow which for a setting-property is " Client --> HardwareEquipment". The client as well can use " get" on a setting property in order to obtain the current pending setting-values.

    A mechanism, called double buffering is used to synchronize setting-fields between the server and the RT-side.

    Usually setting fields are filled in set-server-actions and read out by rt-actions.

    13.7.4. Acquisition

    The keyword "Acquisition" describes the direction of the data-flow which for an acquisition-property is "HardwareEquipment --> Client". Usually the data in an acquisition-property is measured by the hardware-equipment. Acquisition-fields usually are filled in rt-actions and read out by get-server-actions.

    13.7.5. Cycle (Virtual Accelerator)

    The accelerator complex provides beams for several experiments "in parallel". This makes the accelerator a shared resource which is managed by the central-timing system. The central-timing defines successive time-slots (so called cycles) during which the accelerator receives appropriate settings to achieve a particular beam with special characteristics for each cycle.

    13.7.6. Multiplexing

    Making a property, or a field “multiplexed”, tells that the corresponding setting or acquisition becomes specific per cycle.

    "Multiplexing" in FESA means, that a value is available more than once. To indentify a concrete entry of a multiplexed value a so called " cycle-selector" is used.

    The timing-system and the client both have to provide this cycle-selector.

    13.7.7. Rolling Buffer

    A rolling-buffer, as well called ring-buffer can be used for multiplexed acquisition-fields. Instead of storing one field-entry per cycle, it stores just a predefined number of cycles, and always overwrites the oldest field-entry.

    Especially for front-ends with low memory, the rolling-buffer can be usefull to manage huge multiplexed fields. E.g. Only the last played cycles can be stored, instead of providing a memory-segment per cycle, as the usual multiplexing does.

    13.7.8. Double Buffer

    FESA introduces a so called double-buffer mechanism, which is needed in order to synchronize setting-fields between the Server and the RT-Side. All setting-field data is stored twice, as "pending-data" and as "active-data".

    Whenever a server-action changes the pending-data of a field, a so called "hasChanged" flag is raised for this field. As soon as the next RT-Action for the corresponding device is played, the pending-data will be swapped with the active-data. (Not the data itself will be swapped, but only a pointer to the data, to avoid an additional time-consuming copy-operation)

    All that is done, in order to avoid priority inversion between server and rt-actions.

    13.7.9. Client

    A client, in the context of FESA is considered as middleware-user, who wants to communicate with a FESA-device. To do so, the client can use a big palette of middleware methods.

    Probably the most important ones are get, set and subscribe. In order to identify the needed information, the client has to specifiy a device-instance-name, a property-name and a cycle-context-string.

    13.7.10. Client-Get

    A "get" or "doGet" can be used by a client, in order to obtain data from a specific setting- or acquisition-property of a specific device-instance.

    Usually a device-reference-object can be obtained from the middleware, using the device-name. The property-name and the cycle-name can than be passed as parameters of the get-method. As well an additional parameter, called context can be used in order to more precisely describe the required data.

    The client-implementation of the "get" can be done via different languages, depending on the support of the middleware.

    Additionally it is possible to invoke the "get" either as synchronious or asynchronious call. That allows to avoid longer wait-times which can occur on complex server- actions.

    13.7.11. Client-Set

    A "set" or "doSet" can be used by a client, in order to send data to a specific setting-property of a specific device-instance, or to invoke a command-property.

    Usually a device-reference-object can be obtained from the middleware, using the device-name. The property-name, the cycle-name and the data which is to send can than be passed as parameters of the get-method. As well an additional parameter, called context can be used in order to more precisely describe the required data.

    The client-implementation of the "set" can be done via different languages, depending on the support of the middleware.

    Additionally it is possible to invoke the "set" either as synchronious or asynchronious call. That allows to avoid longer wait-times which can occur on complex server- actions.

    13.7.12. Subscription

    A "subscription" (monitorOn) can be used by a client, in order to receive a value from a specific property from a specific device automatically whenever it changes.

    Usually a device-reference-object can be obtained from the middleware, using the device-name. The property-name and the cycle-name can than be passed as parameters to the "subscribe" method. An additional parameter, called "context" can be used in order to more precisely describe the required data.

    The client-implementation of the "subscription" can be done via different languages, depending on the support of the middleware.

    13.7.13. Transactional

    The attribute "transactional" can be choosen on set-server-actions, in order to enable support for the "transaction" middleware-service. It allows to set new values to tousands of different devices on different front-ends simultaniously.

    A client can coordinate all the front-ends that participate in a transaction by proceeding two phases:
    • phase 1: Receives the new setting.
    • phase 2: Commit or rollback the new settings.

    13.7.14. Device-Handle

    A device-handle is a software object, which the client can obtain from the middleware in order to connect to the right software- device-instance. In order get the right handle, the client needs to know the name of the device.

    13.7.15. Instantiation Document

    The instantiation document keeps all configuration which is specific per front-end, or even per device-instance in a front-end-specific file. To create an empty instantiation document of your class, press "add FEC" and "create Instance" in the eclipse plugin.

    13.7.16. Deployment Unit

    A deployment-unit is a separate xml-document, which is used to cluster 1 to N FESA-classes together and to build a working binary-file out of them. The deployment-document gathers all classes which are used by inheritance and composition. As well the priorities of the different scheduling-units are defined in the deployment-document.

    13.7.17. Class Lifecycle

    Edit  | Attach | Print version | History: r1 | Backlinks | View wiki text | Edit wiki text | More topic actions
    Topic revision: r1 - 26 Mar 2012, AlexanderSchwinn
    This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
    Ideas, requests, problems regarding Foswiki? Send feedback