IEC 62769-6-2021 pdf free download – Field device integration (FDI) – Part 6: Technology Mapping.
4.1.3 FDI Type Library The Device Access Services and the UIP Services can be modelled as .NET interfaces passing .NET data type arguments. These interfaces and data types are used for the data exchange and interaction between the UIP and the FDI Client. For runtime error handling purposes during interface method calls, .NET exceptions classes are defined.
The FDI .NET interfaces, data types, and exception classes are defined in a single FDI Type Library. The FDI Type Library is a strong-named Assembly. The file name of this Assembly shall be ‘fdi.dll’. The fdi.dll shall be versioned as per IEC 62769-1:2020, 8.1. The FDI Type Library is part of the FDI Core Technology as per IEC 62769-1:2020, 8.3.2.1 and therefore directly influences the FDI Technology Version. All Compatible changes of the fdi.dll lead to an increase of the minor portion of the FDI Technology Version. Incompatible changes lead to an increase of the major portion of the FDI Technology Version (see IEC 62769-1:2020, 8.3.2.2). The FDI Type Library is signed with a single unique key by the issuer of the file.
The FDI Type Library shall be installed separately as part of every FDI Client installation. User Interface Plug-Ins (UIP) and the FDI Client Application shall use this instance of the fdi.dll. UIPs shall not carry or deploy the FDI Type Library. The FDI Client is responsible to provide means to allow updates of this type library over time. Figure 1 shows the FDI Type Library structure.
4.2 UIP representation
The UIP Variant can contain either a single or multiple runtime modules (.NET Assembly) and their related supplementary files (for example: resource files). The runtime module of the UIP Variant is called “UIP executable”. The supplementary file(s) of the UIP Variant is/are called “UIP supplement(s)”. UIP supplement(s) is/are stored under (a) subfolder(s) of the UIP executable installation directory.
EXAMPLE Resource files and application configuration data. The RuntimeId of a UIP Variant shall be “.NET Framework CLR4”, see IEC 62769-4. FDI Clients supporting this RuntimeId shall support the .NET Framework 4.6.1 or higher using the CLR4 and UIPs with this RuntimeId shall use the .NET Framework 4.6.1 or lower supporting the CLR4 (meaning .NET Framework 4.0 up to .NET Framework 4.6.1). The UIP Variant shall be self-contained. All UIP required libraries (.NET Assemblies) required by a UIP Variant are stored within the same Folder.
4.3uIP executable representation
The implementation of the UlP depends on the type of user interface elements that can beembedded into the user interface hosting environment of the FDl Client. UIP shall beimplemented as a .NET System.windows.Forms class UserControl or a WindowsPresentation Foundation (WPF) system.windows.Controls class userControl.
Ulexecutables and their required libraries shall have strong names.The signing of a strong-named Assembly can be done using a self-generated key.
NOTEThe identity of strong-named Assemblies consists of a name，version,culture，public key token and digitalsignature.
UIP executables and their required libraries shall be shipped with file containing the publickey in order to enable Assembly verification.
4.4uIP executable compatibility rules
The compatibility rules for different versions of the UlP component are specified inlEC 62769-4.
The compilation target platform for the UlP shall be “anyCPu”. lf this is not feasible, the Ulpshall be shipped in two variants.One UlP variant shall be compiled for target platform “x86”.The second UIP variant shall be compiled for target platform “x64”. The compilation platformtarget shall be described in the catalog.xml file,which is defined in lEC 62769-4. Thiscatalog.xml file contains an xml element “Cpulnformation”that describes the User InterfacePlug-in variant. The allowed values that shall be used in the xml element “Cpulnformation” are
“anyCPU””,”x86″ or “x64”.
4.5Allowed .NET Common Language Run-time versions4.5.1General
Specific CLR(Common Language Run-time) versions are released for the execution ofsoftware components built with specific .NET Framework versions. The .NET CLR version 4.0
is used to execute software components built with .NET Framework 4.0. .NET Componentsare built for one CLR version only but can be capable to run also under a newer CLR version.
FDI Clients can be built based on CLR version 4.0 or future versions. An FDl Client has torealize the following situations when starting a UIP.
. When the UlP to be started was built for the same run-time, the UlP can be started by theFDI Client as usual.
When the UlP to be started was built with another CLR version and is not compiled for thecurrent running CLR version, the FDl Client shall start the UlP in a surrogate process withthe adequate CLR version.(More details are described in 4.5.2.)
Taking this behavior in account,a UlP shall be developed for CLR version 4.0 or any futureversion. lf the CLR versions do not match, the UlP shall be started in a separate process.The
UIP will then not be displayed as an integrated module within the FDl Client. lt is up to theFDI Client to realize the surrogate process.
4.5.2CLR compatibility strategy
ln the future,FDI Clients and UIPs will be permitted to be built on different incompatibleversions of the CLR.IEC 62769-6 pdf download.