008 What are the common requirements for the data client configuration?

  • Status: accepted
  • Deciders: partners

Assumptions

  • A data client should not access the file system directly
  • The TEK reads the configuration from a TEK specific storage and forward it to the data client
  • The TEK is responsible to identify the correct plugin for the each configuration file
  • Different vendors may already supply configuration files in proprietary formats.
  • The DC configuration of a specific client should be the same for different implementations of the TEK.
  • The configuration of the TEK itself may be implementation specific.
  • The complete data client configuration and data client "discovery" configuration must be compatible between alle TEK implementations.
  • OS specific limitations may restrict the location of shared libraries and configuration files.

Decision

  • Separated configuration files of TEK and Plugins
  • Separated configuration files of plugin and data clients
  • Data client configurations are not necessarily nested below plugin configurations

Ideas

The TEK uses different directories for data client shared libraries and data client configuration.
The directory structure for the binaries is implementation specific to the TEK implementation. The structure of the configuration on the other side is equal in all TEK implementations.

Possible configuration structure - does not influence the south api

  1. All plugin configurations are in a subdirectory 'data_client:plugins'
  2. Each Plugin has its own subdirectory. Its name is not constrained.
  3. Each plugin configuration directory contains a 'plugin.json'
  4. All client/device configurations are in a subdirectory 'data_clients'
  5. Each client has its own subdirectory. Its name is not constrained.
  6. Each client directory contains a client.json configuration file.
  7. A client.json or plugin.json can contain references to additional files.

example/proposal of the directory structure

.../binaries/
      |
      + data_client_plugins/
        |
        + dc-s7.dll
        + dc-ads.dll 
.../configuration/
      |
      + data_clients/
      |  |
      |  + NC/
      |  |  |
      |  |  + client.json
      |  + PLC/
      |  |  |
      |  |  + client.json
      |  |  + symbols.xml // Siemens specific 
      |
      + data_client_plugins/
         |
         + siemens-s7
         |  + plugin.json // TEK-Spec conformant
         |  + lic.bin // Siemens specific 
         + beckhoff-ads/
            |
            + plugin.json

// plugin.json
{
    "tek.plugin-name":"Siemens Step7",
    "tek.plugin-library": "dc-s7", // loads dc-s7.so resp. dc-s7.dll
    "tek.additional-files": {
        "secret-license-file": "lic.bin"
    }
    // optional plugin specific properties
}

// client.json
{
    "tek.plugin" : "siemens-s7", // references directory inside data_client_plugins
    "tek.additional-files" : {
        "symbols" : "symbols.xml"
    }
    // ... optional plugin and client specific properties
}

struct additional_file
{
    char* name; // name of additional file
    char* content; // content of additional file
};


struct configuration
{
    char * config; // json content
    additional_file* additional_files;
    size_t additional_files_count;
};

Configuration options

TEK and plugins

one common configuration file for tek and data client

  • Bad, because ist may be large and hard to edit.
  • Bad, because the configuration of the data clients can not be copied to another TEK without modifications

different configuration files for tek and data client

  • Good

Plugin and data client

different configuration for plugin and device

  • Good

combined configuration of plugin and device

  • Bad, because it is not easy to disable a device

Plugin and data client hierarchy

device configuration below plugin configuration

  • Bad, because a single device can not be copied/moved between different TEKs.

device configuration in own directory

  • Good, because naming conflicts are impossible