Configuration¶

In this chapter, the configuration of a CCF Control instance is described. The configuration is loaded and installed during start-up and initialisation of the application. The configuration (set of parameters) may be extended, by adding new adapters, requiring additional configuration information.

The configuration files needed for one instance of CCF Control, are shown in the following diagram:

The logging carried out by CCF is based on the “log4cplus” tool and consequently, also a “logging properties” file is installed and used by the application.

Main Configuration¶

This version of the configuration is based on YAML and a plain hierachical parameter naming scheme.

The following categories of parameters are defined:

System

Monitoring

Camera

Acquisition

Processing Pipeline

An example of a configuration, is available in CCF: “ccf/control/resource/config/ccf/control/config1.yaml”.

System Configuration Parameters¶

In the following the table the system related configuration parameters are listed:

sys.name (String)	Name allocated to the system. It is recommended that the name, uniquely identifies the instance system wide. A name of the form “<system><instance>”, is proposed, whereby “<system>” could be the name of an instrument and “<instance>”, the instance name within that context.
sys.req.endpoint (String)	Endpoint URI for the CII MAL Request/Reponse service. E.g., “zpb.rr://127.0.0.1:12092/”.
sys.db.endpoint (String)	Endpoint URI for the CII OLDB service. E.g., “127.0.0.1:7878”.
sys.db.prefix (String)	Prefix for all OLDB keys handled by this instance of CCF. May be allocated like “sys.name”.
sys.db.timeout.sec (Integer)	Timeout in seconds to apply when access the OLDB.
sys.sm.scxml (String)	Name of the state machine SCXML definition. Normally the default one shall be used but if a new application class is implemented, derived from the CCF class, it is possible to specify an alternative state machine for the internal state machine engine.
sys.pub_sub.endpoint (String)	Endpoint URI for the CII Pub/Sub service, used for publishing status information. Example: “zpb.ps://127.0.0.1:52234/”.
sys.log.properties (String)	Name of the log properties file for the “log4cplus” logging service. Example: “ccf/control/log.properties”, which is the default logging properties configuration delivered with CCF. It is possible to provide an alternative log properties file for the individual CCF instance, if of relevance.
sys.log.level (String)	Default log level to apply. May be overwritten with the “-l <level>” command line option, given to the application. Possible values: “ERROR”, “WARNING”, “STATE”, “EVENT”, “ACTION”, “INFO”, “DEBUG”, “DEBUG2”, “DEBUG3”, “TRACE”.
sys.init.setup (String)	Name of the Initialisation Setup to load during application start-up and initialisation. It provides default values for the setup parameters. A specific Initialisation Setup shall normally be provided for a specific instance. Example: “ccf/control/initSetup.yaml”.
sys.image.dir (String)	Location where image output files will be stored. The complate path for the storage location is: “$DATAROOT/<sys.image.dir>”, which consequently must exist.
sys.did# (String)	Names of dictionaries to load for the generation of the metadata in the output data products. “sys.did1 “ccf/control/ccf.did”. Note, “ccf/control/ccf.did” shall normally be loaded. New keys shall be provided via instance specified dictionaries.
sys.metadata.mapping (String)	Name mapping mapping internal names for parameters into the metadata names, typically FITS keywords to write in Data Product headers. Not supported for this version.
sys.simulation (String)	Defines whether to run the instance in normal or simulation mode. From the perspective of CCF, switching between normal and simulation mode, boils down to which Communication Adapter to use.
sys.req.hist.size (Integer)	Number of requests to keep in the internal history. For now, it’s only used for caching Recording Session status info for the “recif::RecStatus” request.
sys.req.hist.expiration (Integer)	Expiration time, in seconds, to apply for requests cached in the internal history.

Monitoring Configuration Parameters¶

In the following the table the monitoring related configuration parameters are listed:

mon.period (Integer)	Period in seconds for scheduling the Monitor Thread. Recommended value is 1s. Note, this determines how frequent the thread execution statistics is computed and updated in the OLDB.
mon.nb_of_samples	Number of samples to use for the sliding window of samples, used for calculating the thread execution statistics.

Camera Configuration Parameters¶

In the following the table the camera related configuration parameters are listed:

cam.name (String)	Name assigned to the camera.
cam.id (String)	ESO wide, unique ID assigned to the camera.
cam.model (String)	Camera model.
cam.chip.model (String)	Chip model.
cam.type (String)	Type of camera, e.g. “CCD”, “IR, “CMOS”.
cam.manufacturer (String)	Camera manufacturer.
cam.adapter.protocol (String)	Protocol used for communicating with the camera, e.g. “GigE Vision”.
cam.adapter.mapping (String)	Name mapping, mapping the internal names, used in the communication adapter, into the specific names, deined in the camera name space.
cam.adapter.api (String)	API (or SDK) used for implementation the communication with the camera. Example: “CCF/Aravis”.
cam.adapter.address (String)	Address used for connecting to the camera. Is typically an IP address + port number, for Ethernet/socket based communication protocols.
cam.adapter.sim_address (String)	Address of the CCF simulator, if an external simulator is used. Note, for the present version of CCF, simuilation is provided via a Simulation Communication Adapter.
cam.adapter.property# (String)	Property for the Communication Adapter. Example: “cam.adapter.property1: StreamBytesPerSecondMax=124000000”.
cam.chip.width (Integer)	Width in pixels, of detector chip.
cam.chip.height (Integer)	Height in pixels, of detector chip.
cam.chip.max_resolution (Integer)	The maximum possible resolution (bits/pixel) for the given camera.
cam.chip.resolution (Integer)	Resolution used in given set up.

Note, some of the camera category configuration parameters may be available via the camera interface.

Acquisition Configuration Parameters¶

In the following the table the acquisition configuration parameters are listed:

acq.priority (Integer)	Priority of the thread. Reserved for possible future deployment on RT Linux.
acq.max_rate (Double)	Maximum rate for the data acquisition (Hz).
acq.inputq.size (Integer)	Number of frame buffer elements in the Input Queue. In the optimal case, two buffers would be sufficient. However, due to the deployment on a non real-time platform, it is necessary to allocate extra buffers to average out jittering.
acq.allow_lost_frames (Boolean)	If true, frames lost at the level of interaction with the camera, are silently ignored.
acq.allow_frame_skipping (Boolean)	If true, in case there are no free buffers available in the Input Queue, these are siliently discarded. Otherwise a warning log is produced.

Processing Pipeline Configuration Parameters¶

In the following the table the Processing Pipeline configuration parameters are listed:

proc#.name (String)	Name of the Processing Thread with the given index assigned to it (“proc#”: “#” defines the instance, e.g. “Processing Thread 1”.
proc#.priority (Integer)	Priority of the thread. Reserved for possible future deployment on RT Linux.
proc#.outputq.size (Integer)	Number of frame buffer elements in the Output Queue allocated to the Processing Thread 1. In the optimal case, two buffers would be sufficient. However, due to the deployment on a non real-time platform, it is necessary to allocate extra buffers to average out jittering.
proc#.allow_frame_skipping (Boolean)	If true, in case there are no free buffers available in the Processing Thread’s Output Queue, these are siliently discarded. Otherwise a warning log is produced.
proc#.recipe#.adapter (String)	Name of the Processing Recipe Adapter to be applied on the image frames, for processing purposes. The name must match the name allocated in the Processing Recipe Adapter implementation, e.g. “ccf::stdrecipe::RecipeCentroid”.
proc#.recipe#.name (String)	Logical name allocated to the Processing Recipe instance. Serves mainly to get meaningly and easy understandable logging output from the recipe.
proc#.pub#.adapter (String)	Name of the Data Publisher Adapter used to publish the processed image frames, for processing purposes. The name must match the name allocated in the Processing Recipe Adapter implementation, e.g. “ccf::stdpub::PubFits”. “proc#” refers to the Processing Thread instance. “pub#” refers to the Data Publisher Thread instance.
proc#.pub#.name (String)	Logical name allocated to the Data Publisher instance. Serves mainly to get meaningly and easy understandable logging output from the recipe.
proc#.pub#.priority (Integer)	Priority of the thread. Reserved for possible future deployment on RT Linux.

Initialisation Setup¶

An Initialisation Setup must be specified in the Main Configuration to define the default setup of the system after start-up of the application.

The Initialisation Setup merely lists the various possible Setup Parameters, defined for the given instance. The issue of the setup is handled in the next chapter.

An example of an Initialisation Setup, is provided within the CCF Package: “ccf/control/resource/config/ccf/control/initSetup1.yaml”.

Camera Name Mapping¶

The Camera Name Mapping file is a file in YAML format, used to map the names for camera properties, used in the Communciation Adapter, into the specific names defined for the associated camera.

Using a Camera Name Mapping makes sense, if a generic Communication Adapter can be re-used to control multiple cameras, if it is avoided to hardcode names in the Communication Adapter.

If the names are hardcoded in the Communication Adapter, or not used in connection with the given camera/SDK, a Camera Name Mapping is not needed.

An example of a Camera Name Mapping is provided by the CCF Package: “ccf/protocols/aravis/lib/resource/config/ccf/protocols/aravis/avtMapping.yaml”.

Metadata Name Mapping¶

The purpose of the Metadata Name Mapping file is to map parameters registered in connection with a given image frame, into the actual metadata names, required in the Output Data Product File.

When a frame is received, the Communication Adapter may register metadata, describing the image, in its frame buffer object. In addition, Processing Recipes may add such metadata, which should be added in the Output Data Product Files. When a Metadata Name Mapping is provided, the target Output Data Product metadata keys, shall be registered in a Dictionary, defined in the configuration.

Note: The Metadata Name Mapping feature is not supported for this version.

Dictionaries¶

A Dictionary is used to describe the properties of the metadata keywords to be written in the Data Product Output Files. The format and tools to handle Dictionaies, is provided by the ICS Core Data Interface Tools (DIT) Package.

A base Dictionary is provided by the CCF Package: “ccf/control/resource/dictionary/ccf/control/ccf.did”. This Dictionary shall normally always be specified in the configuration and used.

Simulation Data File¶

Whether or not a Simulation Data File, typically a FITS cube, is used as basis for the simulation, depends on the implementation of the simulated behaviour in the given context.

In the present version, the simulation is implemented within the Simulation Communication Adapter and it is based on a FITS file as input. The FITS file is then played back, according to the given setup/exposure parameters.

If a context specific simulator is provided, it may use another type of file, or no input file at all.

A small tool is provided to allow the users of CCF to create their own FITS data cubes, with an emulated star moving in the field of view. The tool is named “ccfGenFitsCube”.