009 data client model access

• Status: accepted
• Deciders: partners

Context and Problem Statement

TEK implementations need to know the model and capabilities of a data client. i.e. which fields can be read, are there any events which can be emitted by the data client or which alarms and conditions are provided.

This data model of a data client is needed to know what to expect from the data client at runtime and to validate script interactions with a given data client.

Decision Drivers

• simplicity: the execution flow ist easily understandable
• understandability: how ist this problem solved in other similar contexts (e.g. data binding in OPC-UA SDK's or data access in known PLC access libraries)
• extensibility, upgradability: how easy and backwards compatible can new features be integrated
• usability: how easily can errors in the custom scrips and in the configuration be detected

Considered Options

• TEK reads data client model/capabilities directly from data client
• data client registers model at TEK

Decision Outcome

data client registers model at TEK

Pros and Cons of the Options

TEK reads data client model/capabilities directly from data client

The data client implements methods for all relevant model parts which are used by the TEK.

interface south_api {    
    List<field> get_declared_field();
    List<field> get_declared_events();    
};

• Good, because the execution flow is easily understandable (less usage of callback functions)
• Good, because the interface is easier to read and understand
• Bad, because data clients must implement functions for model parts which are not supported by a specific data client (i.e. events might not be of interest)
• Bad, because it may be unclear which functionality in the DC is mandatory and which is optional

data client registers model at TEK

The TEK interface contains method definitions for registering fields, events and other model parts.

With this option a data client can decide which model it actively must support and is not forced to implement empty functions.

interface tek {
    // ...
    RESULT register_field(data_client, field, type);
    RESULT register_event(data_client, event);
    // ...
};

A data client implements a single method register containing code responsible for registering all model related parts at the TEK.

interface data_client {
    RESULT register(tek);
}

• Good, because the data client must not implement code for not used model parts
• Good, because the interface can be extended in a way that existing DC can be reused without modification
• Good, because it is assumed that the required amount of code in the DC is smaller
• Bad, because the data client implementor must deal with function pointers