< PreviousField Device Integration (FDI) – Part 3: Server RELEASED FCG TS62769-3 , Ed. 1.2.0, 21 Jun 2019 Page 9 of 62 • The Information Model is created using information from FDI Packages. However, not all of the information in an FDI Package is reflected in the Information Model. • Referential integrity of the Information Model is maintained using information from FDI Packages. • FDI Packages can contain Attachments that contain device manuals and protocol specific information (see FCG TS62769-4). Those Attachments, including device manuals and protocol specific support files, are exposed via the Information Model. • FDI Device Packages contain information about device types (see FCG TS62769-4). Each device type defined in a package is mapped to a distinct DeviceType node in the Information Model. • FDI Profile Packages are used to provide interaction with devices for which an FDI Device Package does not exist (see FCG TS62769-4). • Multiple revisions of an FDI Package generate distinct DeviceType nodes in the Information Model (see FCG TS62769-4). FDI Packages contain digital signatures that allow an FDI Server to authenticate their contents (see FCG TS62769- 4). An FDI Server shall verify the FDI Technology Version (see FCG TS62769-1) of any FDI Package it uses to ensure the FDI Package is compatible with the FDI Server. 5 Information Model 5.1 General The FDI Server shall use the Device Definition of an FDI Package to maintain the Information Model. The Device Definition can contain conditional expressions. Conditional expressions are used when a certain aspect of the Device Definition is not static but rather is dependent on the state of the device. Whenever the online or offline values of a Device Instance are modified, the FDI Server shall re-evaluate the relevant conditional expressions and modify the Information Model accordingly. The evaluation of conditional expressions can invalidate variables in the Information Model. The FDI Server shall change the AccessLevel attribute of invalidated variables such that they are neither readable nor writable and the status of these variables shall be set to bad. Read and write service requests for invalidated variables shall return a failure. The Device Definition can specify relationships between variables in a device. These relationships can impact the value of variables in the Information Model. The FDI Server shall generate DataChange Notifications to any FDI Clients that are subscribing to Information Model elements that have changed. FDI Packages provide Business Logic that is used by the FDI Server to maintain the integrity of the Information Model. The Business Logic specified in an FDI Package can invoke built-in functions that shall be implemented by the FDI Server. The built-in functions that shall be implemented by the FDI Server are specified in FCG TS61804. 5.2 Online/Offline Overview The Information Model maintained by the FDI Server contains online and offline values. The online values reflect values in a physical component/device. The offline values reflect values stored in a configuration database. Field Device Integration (FDI) – Part 3: Server RELEASED FCG TS62769-3, Ed. 1.2.0, 21 Jun 2019 Page 10 of 62 The offline values are updated through write service requests from an FDI Client or Business Logic executed by the FDI Server. The offline values are not updated when the FDI Server reads data from the device or writes data to the device. The online values in the Information Model are not updated through write service requests. Successful write service requests through the Information Model result in value changes in the physical devices. The online values in the Information Model will then be updated as a result of read service requests or subscriptions. FDI Servers can provide a server-specific mechanism for creating Device Instances without the presence of physical hardware. The FDI Server creates these instances using information in FDI Packages. All read/write requests for online values for Device Instances with no physical device shall return an error. The transfer of information between the offline values and the physical device is supported through the TransferToDevice and TransferFromDevice methods in the Information Model. These Methods shall implement the download and upload procedures, respectively, as specified in FCG TS61804-4. When no implementation is provided based on FCG TS61804-4, then these Methods shall return Bad_NotSupported, as per IEC 62541-4. The Device shall have been locked prior to invoking these methods, as specified in FCG TS62769-5. Transfer to device The TransferToDevice method shall implement the download procedure as specified in FCG TS61804-4. This transfers the offline values to the physical device. As a general rule, the FDI Server should not change the Online variable node when writing a value to the device. The Online variable node should be updated only in the process of read operations or subscriptions. Notwithstanding, as specified in FCG TS62769-5, the FDI Server will reset any cached Value for the target Nodes in the Information Model so that they will be re-read next time they are requested. The status information returned for each variable included in the write service request is used to compose the TransferResult, as specified in FCG TS62769-5. Transfer from device The TransferFromDevice method shall implement the upload procedure as specified in FCG TS61804-4. This transfers the values from the physical device to the offline values. If any read operations from the device fail during upload, the corresponding offline value shall not be modified. The status information returned for each variable included in the read service request is used to compose the TransferResult, as specified in FCG TS62769-5. 5.3 Access privileges Systems implement security and access policies based on a number of characteristics such as user role and plant area. FDI Servers use these policies, along with information in FDI Packages, to determine the access privileges granted to the user. The elements of an FDI Package can be associated with one or more usage attributes. The FDI Server uses these attributes to set the UserAccessLevel attribute of Variables and the UserExecutable attribute of Methods. The usage attributes in an FDI Package are simply hints to be used by the FDI Server, i.e., they may be disregarded or overridden by the FDI Server. See also Annex B. 5.4 Private Parameters The Parameters and Actions specified in an FDI Package may be declared private. Private Parameters and Actions shall not be browsable; they shall only be accessible through references from other elements of an FDI Package. Field Device Integration (FDI) – Part 3: Server RELEASED FCG TS62769-3 , Ed. 1.2.0, 21 Jun 2019 Page 11 of 62 More specifically, the FDI Server shall support private Parameters and Actions as follows. • The FDI Server shall create nodes in the Information Model for the private Parameters and Actions. • The FDI Server shall not include information about private Parameters and Actions in a response to a Browse, BrowseNext, QueryFirst, or QueryNext service request. • The FDI Server shall return the NodeIds of private Parameters and Actions when the name of a private Parameter or Action is passed to TranslateBrowsePathsToNodeIds. • The FDI Server shall process a read/write service request for a private Parameter in the same way as it does for public (browsable) Parameters (see 5.7 and 5.8). • The FDI Server shall execute private Actions in the same way as it does public (browsable) Actions (see 5.12). An example of private parameters is parameters that should only be modified through an Action. These parameters should not be visible to FDI Clients to prevent direct access. FDI Clients invoke Actions to access these private parameters. 5.5 Locking The FDI Server provides locking services to grant FDI Clients exclusive access to Device and Network elements in the Information Model. The locking services consist of a set of Methods and status information. The methods, and their behavior, are specified in FCG TS62769-5. The following behavior shall be implemented by the FDI Server to support locks. • Locking applies to both online and offline nodes. • Once locked by one FDI Client, any attempt to write to a Parameter or to execute an Action by another FDI Client shall be rejected. • Locking is not required for read services. • Parameters that are locked by one FDI Client can still be read by other FDI Clients, i.e., read requests on a Parameter that is locked are not rejected. Internal use of the locking mechanism for maintaining the Information Model integrity is FDI Server vendor specific. Figure 2 illustrates a locking sequence with multiple service invocations during the locked state. Optional Process Service Requests to Device FDIClient FDIServer InitLock() ExitLock() Service Request Process Service Request Figure 2 – Locking services Field Device Integration (FDI) – Part 3: Server RELEASED FCG TS62769-3, Ed. 1.2.0, 21 Jun 2019 Page 12 of 62 A service request that requires locking shall fail either partially or completely if no lock has been acquired by the FDI Client via InitLock prior to requesting the service. The FDI Client has to release the lock via ExitLock after all service requests have been completed. NOTE A write operation will partially fail, i.e., it will return a status code for each variable in the set of variables to be written since some may belong to devices that are locked and some to devices that are not locked. FDI Servers may queue InitLock requests until a service for which a lock has been created completes and the lock has been released. However, such an optimization is not part of the standard behavior required of an FDI Server. 5.6 EditContext Concept and usage model The FDI Server provides the EditContext model to interact with Clients during their editing task. The concept is closely related to UIDs and fulfills the needs for Server-driven UI dialogs based on EDDL rules. An EditContext can be used to make changes to Variable Values visible to the Server without applying them to the online or offline representation of a Device. The Server will apply business logic associated to the edited Variable which – in some cases – causes changes to other Variable Values (e.g. if an engineering unit is changed) or the UID (e.g. a Variable becomes invisible). Thus, the Client can use an EditContext to modify (edit) Parameters like engineering units, ranges and more, verify any side effects, and re-adjust the settings before applying the changes. An FDI Server may implement different EditContext strategies: • A single EditContext instance for all dialogues of an FDI Client. • Multiple EditContext instances. • Hierarchical EditContext instances. Field Device Integration (FDI) – Part 3: Server RELEASED FCG TS62769-3 , Ed. 1.2.0, 21 Jun 2019 Page 13 of 62 FDI Client FDI ClientFDI Server OPC UA EditContext Management Business Logic Processor OPC UA Services EditContext A Business Logic Device Cache 100.0Parameter 1°C Option 1 Option 2 0Min:mm 2000Maxmm OKCancelApply 0Min:mm 2000Maxmm OKCancelApply FDI Server OPC UA EditContext ManagementBusiness Logic Processor OPC UA Services EditContext A EditContext B EditContext B.1 Business Logic Device Cache 100.0 Parameter 1°C Option 1 Option 2 OKCancelApply 100.0 Parameter 1°C Option 1 Option 2 0Min: mm 2000Max mm OKCancelApply Figure 3 – EditContext models Figure 3 shows two possible Server strategies and how the Client can adapt. In the lower scenario the Server provides a single EditContext instance for all dialogs. Here, the Client groups all dialogs and exposes a single set of buttons to Apply and Cancel, because it always concerns all edits. In the upper scenario, the Server provides multiple EditContext instances, one of them as child of another one. Each instance can be addressed separately. If the changes in a child instance are applied, they are transferred to the parent. If the changes in a root instance are applied, they are transferred to the Device. The parent-child dependencies are defined in FCG TS61804-4 in section Session Management. Services A set of Services is provided to the FDI Client to maintain EditContext instances (see FCG TS62769-5 for a detailed description of these Services): • GetContext – This Service is used to request an EditContext instance. The Client specifies certain characteristics for the Server to decide which EditContext instance to return. Depending on its internal strategy, the Server returns the same instance or new instances. • RegisterNodes – The FDI Client has to register all Nodes of the Information Model that shall be maintained in an EditContext. It is possible to register Nodes of the online and of the offline representation of a Device. The result is new NodeIds that the Client shall use when calling Services to read, write, subscribe to Variables or to invoke Actions. Field Device Integration (FDI) – Part 3: Server RELEASED FCG TS62769-3, Ed. 1.2.0, 21 Jun 2019 Page 14 of 62 • Apply – Transfer the modified (edited) Variable Values to the parent (either a parent EditContext instance or the Device). If the same Variable has been edited in the parent instance it will be overwritten with a call of the Apply Service for the child. • Reset – Clears all modifications. A Reset of already applied modifications is not possible. • Discard – Deletes an EditContext instance (and its children). Edited Values that have not been applied are discarded. Once deleted, all registered NodeIds will be invalid. If such NodeIds are still subscribed, the Client is notified with proper StatusCodes. The Client first calls GetEditContext to acquire an EditContext instance. It will then register the Nodes it wants to be part of it. The registration returns new NodeIds which can then be used for reading, writing or subscribing Variables and for calling Methods. The Client can call GetEditContext multiple times, for instance when it opens an additional edit window or for a completely separate dialog (diagnosis in parallel to configuration). It is up to the Server strategy whether it returns a new instance or the same instance. The Client is expected to adapt its user interface to the EditContext strategy of the Server. See Figure 3 for how Clients may position the Apply and Cancel buttons so that the User clearly understands which changes s/he applies or discards. NodeIds RegisterNode returns two NodeIds for each registered Node: a ContextNodeId and a DeviceNodeId. The Client uses these NodeIds when calling OPC UA Services to read, write and subscribe or call a Method. Using the ContextNodeId addresses the Value in the EditContext instance. Using the DeviceNodeId addresses the Value in the Device. Reading Reading or subscribing a Variable with the ContextNodeId will return the edited Value from the EditContext instance. If no edited Value exists, the Value from the parent instance or the Device (online or offline) will be returned. The StatusCode indicates whether the Value originates from the Device (StatusCode Good defined in IEC 62541) or from an EditContext instance (StatusCode Good_Edited defined in FCG TS62769-5). Reading or subscribing a Variable with the DeviceNodeId will return the Value from the Device (online or offline). Writing Writing to a Variable with the ContextNodeId modifies the Value in the EditContext instance. Writing to a Variable with the DeviceNodeId modifies the Value in the Device (online or offline). Any edited Values for this Variable in the addressed EditContext instance or its parents will be reset. Writing dominant and dependent Variables In some cases, the value of a Variable depends on the value of another Variable. FCG TS61804-4 specifies how these dependencies are evaluated. When such Variables are edited, the FDI Server shall follow the state diagrams specified in Figure 4 for “Online” and Figure 5 for “Offline”. These diagrams specify the states and transitions during the editing process of this kind of Variables. Status is the StatusCode that FDI Clients will receive with the Value when monitoring or reading these Variables with the ContextNodeId. For dependent Variables any Good or Uncertain StatusCode transfers to an Uncertain_DominantValueChanged and a Bad to Bad_DominantValueChanged. For dominant Field Device Integration (FDI) – Part 3: Server RELEASED FCG TS62769-3 , Ed. 1.2.0, 21 Jun 2019 Page 15 of 62 Variables a Good transfers into Good_DependentValueChanged, an Uncertain into Uncertain_DependentValueChanged and a Bad to Bad_DependentValueChanged. Status: DOM = Good_Edited DEP = {Uncertain/Bad}_DominantValueChanged Status: DEP = Good_Edited DOM = {Good/Uncertain/Bad}_DependentValueChanged DOM = Dominant Variable DEP = Dependent Variable Edit DOM Edit DEP Status: DOM = <device status> DEP = <device status> Apply Status: DOM = Good_Edited DEP = Good_Edited Also edit DEP Status: DOM = <device status> DEP = <device status> Apply Also edit DOM Initial (empty EditContext) Status: DOM = <device status> DEP = <device status> DOM is updated in device DOM cleared in EditContext Apply Figure 4 – Online EditContext state diagram for dominant and dependent Variables NOTE If both the dominant and the dependent Variable are to be changed, it is highly recommended for the online case to make these changes in subsequent editing sessions. Systems may enforce this. Field Device Integration (FDI) – Part 3: Server RELEASED FCG TS62769-3, Ed. 1.2.0, 21 Jun 2019 Page 16 of 62 Status: DOM = Good_Edited DEP = {Uncertain/Bad}_DominantValueChanged Status: DEP = Good_Edited DOM = {Good/Uncertain/Bad}_DependentValueChanged DOM = Dominant Variable DEP = Dependent Variable Edit DOM Edit DEP Status: DOM = <offline device status> DEP = <offline device status> Apply Status: DOM = Good_Edited DEP = Good_Edited Also edit DEP Status: DOM = <offline device status> DEP = <offline device status> Apply Also edit DOM Initial (empty EditContext) Status: DOM = <offline device status> DEP = <offline device status> Apply Figure 5 – Offline EditContext state diagram for dominant and dependent Variables Actions (EDD METHODS) Before invoking Actions, the Client has to register the ActionSet Node of the Device. The NodeId of this Node has to be specified when calling InvokeAction. Calling InvokeAction with the ContextNodeId of the ActionSet Node associates it with the proper EditContext instance. The Server will implicitly create an EditContext instance for the invoked Action. This is illustrated in Figure 6. FDI Client 0 Min:mm 2000Maxmm OKCancelApply FDI Server OPC UA EditContext ManagementBusiness Logic Processor EditContext A EditContext A.1 Business Logic 100.0 Parameter 1°C Option 1 Option 2 OKCancelApply (4) Dialog for Action ABC (1) EditContext for UID (5) EditContext for Action ABC is used Action ABC Action ABC (2) Button invokes Action (3) Server creates EditContext and executes Action Figure 6 – EditContext for EDD Methods Field Device Integration (FDI) – Part 3: Server RELEASED FCG TS62769-3 , Ed. 1.2.0, 21 Jun 2019 Page 17 of 62 The EDD METHOD represented by the Action uses builtins to modify Values in the EditContext or the Device, to synchronize changes with the underlying cache or to discard them. If the Action execution fails, the EditContext for the Action is discarded. UIDs The UID Interpreter in the Client calls GetEditContext before it calls up a top-level UID. Additional EditContexts for dialogs may be instantiated by the Server and passed to the Client inside each UID document. See FCG TS62769-2 for the UID Schema and the handling of an EditContext in the UID Interpreter. Synchronization A Lock has to be created before the first Value is written to an EditContext. Locking is also required when writing directly to the Device. 5.7 Reading General The Read service specified in IEC 62541-4 can be used to read a single value or multiple values from a single device or multiple devices. If a Read service request specifies multiple values are to be read, the values are read in the order they appear in the service request. All values that are returned to the FDI Client as result of a Read service request shall be unscaled. A failure encountered while reading a single value shall not abort the read process; all values shall be read. Each value returned contains a status indicating success or failure. Standard OPC UA service status information is returned by the FDI Server as a result of the service calls as specified in 6.2. An FDI Package can define read actions that are executed by the FDI Server during read service requests. These actions shall not require user interaction; they are strictly intended to be used for Business Logic processing. Any read action that eventually requires user interaction will not perform the built-in but will return an error if possible. The following read actions may be defined in an FDI Package: • Pre-read Actions • Post-read Actions The FDI Server invokes pre-read and post-read actions during the processing of read service requests of online values only; they are not invoked when reading offline values. In addition to read actions, an FDI Package can define refresh actions that are executed by the FDI Server during read service requests. These actions shall not require user interaction; they are strictly intended to be used for Business Logic processing. Any refresh action that eventually requires user interaction will not perform the built- in but will return an error if possible. The FDI Server invokes refresh actions during the processing of read service requests of both offline and online values. The refresh actions mentioned in 5.7.1 are not to be mixed up with refresh relations. NOTE Refresh actions are defined by means of the EDDL REFRESH_ACTIONS construct inside an EDDL VARIABLE construct. On the other hand, refresh relations are defined by means of the EDDL REFRESH construct. The handling of refresh relations is included in the generic event “Process Conditionals/Relations” that appear in the sequence diagrams for read, write and subscription services. The explanations that follow the diagrams include refresh relations in the general term “EDDL relations”. See FCG TS61804-3 for more details on both refresh actions and refresh relations. Field Device Integration (FDI) – Part 3: Server RELEASED FCG TS62769-3, Ed. 1.2.0, 21 Jun 2019 Page 18 of 62 Reading offline variables The sequence diagram in Figure 7 shows the behavior of the FDI Server when an offline value is read. Optional FDIClientFDIServerEDDL:BusinessLogic Select Refresh Action() Execute Refresh Action() Process Conditionals/Relations Read Parameters Loop for all nodes in the service request Figure 7 – Offline variable read If a variable has refresh actions associated with it, the FDI Server always executes those actions regardless of MaxAge. If the refresh actions fail, the status returned for that variable shall indicate the read failed. The FDI Server evaluates conditionals and relations after the refresh actions are executed. This provides an opportunity for the re-evaluation of conditional expressions in EDDL Business Logic and the processing of EDDL relations. Reading online variables The FDI Server can cache the online values read from a device. The FDI Server maintains a timestamp for each online value that indicates when the value was read from the device. The FDI Server uses the MaxAge argument of a Read service request to determine whether the cached value can be returned. If the difference between the timestamp and the current time exceeds the MaxAge argument the FDI Server shall read the value from the device. Otherwise, the cached value can be returned. Read actions are only executed when the variable is read from the device. The sequence diagram in Figure 8 shows the behavior of the FDI Server when an online value is read. Next >