< PreviousField Device Integration (FDI) – Part 4: FDI Packages RELEASED FCG TS62769-4 , Ed. 1.2.0, 21 Jun 2019 Page 69 of 79 Commonly used components shall be handled correctly (software parts and components shall be removed only, if no other references from other software programs exist). Existing FDI Package specific files shall not be deleted automatically and shall be reusable in FDI Packages provided by the same vendor. If an FDI Package, which is used and instantiated in a system, has been removed for any reason, the system shall be able to indicate which FDI Package is missing. It shall inform the user about removed FDI Packages and its supported device types: vendor, device name, type and version. The Device Instance data shall not be deleted from the Information Model until the instances are removed by the user. Field Device Integration (FDI) – Part 4: FDI Packages RELEASED FCG TS62769-4, Ed. 1.2.0, 21 Jun 2019 Page 70 of 79 Annex H (normative) Health Status Method H.1 Background Many devices contain embedded intelligence to calculate diagnostic conditions. Other devices may have limited embedded processing and rely on external business logic processing to calculate device diagnostic conditions. Diagnostic data representation may be in various forms and may be influenced by the device communication profile. H.2 Device Health Status Model The health status state provides a high level, consistent structured view to the current operating condition of a device independent of device or communication profile. The health status state is calculated in an EDD method by accessing one or more device variables, calculating the health status state and returning a standard value to the application. Some devices may offer configuration capability to map specific device diagnostic information to the health status state. The configuration of conditions to the health status state is device or communication profile specific and is not part of this standard. The health status state shall be calculated according to Table H.1. In the event of multiple conditions, the state with the lowest priority shall be returned. Table H.1 – Health Status State Health Status State Priority Conditions Indeterminate 0 The health status is unavailable and therefore indeterminate. For example, the device may not be connected, a communication fault has occurred or the device does not support the health status state. Failure 1 Output signal is invalid due to malfunction in the field device or its peripherals. Function Check 2 Output signal is temporarily invalid (e.g. frozen) due to ongoing work on the device. Out of Specifications 3 Deviations from the permissible ambient or process conditions determined by the device itself through self-monitoring or faults in the device itself indicate that the measuring uncertainty of sensors or deviations from the set value in actuators is probably greater than expected under operating conditions. Maintenance Required 4 Although the output signal is valid, the wear reserve is nearly exhausted or a function will soon be restricted due to operational conditions. Good 5 The device is operating under typical operating conditions such that Maintenance Requirement, Out of Specification, Failure and Function Check are not active. H.3 Standard EDD Method signature The EDD shall implement the GetHealthStatus method to provide access to health status state. The method definition will be specific to the EDD. The method definition can use communication Builtins and shall not use user interface Builtins. See FCG TS61804-4, 7.1 for a list of communication Builtins and user interface Builtins. Field Device Integration (FDI) – Part 4: FDI Packages RELEASED FCG TS62769-4 , Ed. 1.2.0, 21 Jun 2019 Page 71 of 79 The GetHealthStatus method shall return the health status state priority value according to Table H.1. Devices that do not support calculating the health status state shall return 0. METHOD GetHealthStatus { LABEL “GetHealthStatus”; TYPE unsigned char; DEFINITION { /* device specific definition */ /* return health status priority */ } } For modular, block-oriented devices, multiple health statuses may be available. In this case, the method name shall use the prefix GetHealthStatus_ (e.g. METHOD GetHealthStatus_TB). Block-oriented health status methods shall be listed in the METHOD_ITEMS attribute of the associated BLOCK_A declaration. H.4 Performance considerations Accessing health status information via a standard EDD method requires business logic processing in the FDI Server. The method will typically require at least one communication access to the device to collect the health status. Continuous scanning of the health status across several device and device networks may have a serious impact on the performance of the underlying communication networks. Underlying communication networks may provide optimized methods (e.g. asynchronous event driven messages) for obtaining health status information for continuous condition based monitoring. Field Device Integration (FDI) – Part 4: FDI Packages RELEASED FCG TS62769-4, Ed. 1.2.0, 21 Jun 2019 Page 72 of 79 Annex I (normative) Modular devices I.1 Concept The concept of modular devices is shown in Figure I.1 and is as follows: 1) The entire modular device is described in a single package. 2) The device’s modular structure and related configuration rules are described in a single EDD file. This EDD file represents the top level topology element of the modular device’s structure. This EDD file is referred in the catalog schema. 3) EDD files describing the modules are contained in separate EDD files, which are not exposed in the catalog XML. The reference to these modules’ EDD files is made from the COMPONENT defined attribute named EDD. 4) Packaging of other package elements as it is defined in 4.2 is not touched. FDI Device Package Catalog Head Station EDD EDD EDD Module EDD Figure I.1 – Modular device's package I.2 EDDL usage profile FDI Packages describing a modular device shall use the following EDDL defined constructs to describe the modular device’s structure (topology) and related configuration rules: 1) COMPONENT 2) COMPONENT_FOLDER 3) COMPONENT_RELATION The following EDDL defined syntax elements shall not be used: 1) COMPONENT_REFERENCE 2) INTERFACE 3) REQUIRED_INTERFACE 4) SUPPLIED_INTERFACE 5) FILTER NOTE The rationale behind this decision is to reduce complexity for the FDI host implementation and for FDI Package creation. The restriction also protects the integrity of modular device description of one vendor since FDI does not support the extension of an existing Field Device Integration (FDI) – Part 4: FDI Packages RELEASED FCG TS62769-4 , Ed. 1.2.0, 21 Jun 2019 Page 73 of 79 modular device description with externally (other vendor) defined modules. This could happen if FDI supports using the EDDL defined syntax element COMPONENT_REFERENCE. I.3 Processing recommendations I.3.1 Monolithic device with device variants An example of a monolithic device with several variants is a pressure transmitter, which may be applied in different applications and for different measurement ranges. The user places the top level element in the topology. Now the host application can ask the user which device variant shall be used. (The same information can be read from the device based on the device vendor implemented “DETECT” function.) In order to define the actually needed device variant the host application shall read the EDD and determine all COMPONENT and COMPONENT_FOLDER declarations. The device variant to be instantiated is determined by the user or the “DETECT” function. Finally the device variant is instantiated and the initial values are initialized. I.3.2 Remote IOs The user places the top level element in the topology, which is the Remote IOs Head Station. Device variants have to be selected according to the procedure described in 6.2.1. For the purpose of the configuration of the module setup the host needs to read the EDD and determines all COMPONENT, COMPONENT_FOLDER and COMPONENT_RELATION declarations to understand the device internal module catalog and the related configuration rules. The host can cache the device internal module catalog that is used only for the module configuration of this particular Head Station. If Head Stations variants are described in separate EDDs all of these EDDs shall be referred in the Catalog XML. These Head stations can share a common set of modules. The device internal module catalog shall be described in all Head stations EDDs. (This can be solved using “#include” in EDD source code). I.3.3 How to identify the top level topology element All topology elements of the modular device are based on COMPONENT or COMPONENT_FOLDER declarations. The following text describes how an FDI host can find the top most topology element inside an EDD file. The FDI host has to find all COMPONENT declarations that do not use the EDD attribute. These COMPONENT declarations belong to internal hierarchy of the Head Station. The top level declaration of this hierarchy can either be a COMPONENT or a COMPONENT_FOLDER. This top level declaration corresponds to the device type described in the Catalog XML. I.3.4 Packaging details example Based on the description found in D.2.4 and D.4.1, I.3.4 provides additional information that helps to understand how the module EDD files need to be added beside the Head Station EDD file which is also referred in the Catalog.XML file. The following example shows how three EDD files are integrated in a single package. There is one EDD file for the Head Station (Target="edd/HeadStation.edd") and two module EDD files (Target="edd/Module_A.edd" and Target="edd/Module_B.edd") <?xml version="1.0" encoding="UTF-8"?> <Relationships xmlns="http://schemas.openxmlformats.org/package/2006/relationships"> <Relationship Type="http://fdi-cooperation.com/2010/relationships/edd" Target="edd/HeadStation.edd" Id="rIdEDD_HeadStation"/> <Relationship Type="http://fdi-cooperation.com/2010/relationships/edd" Target="edd/Module_A.edd" Id="rIdEDD_Module_A"/> <Relationship Type="http://fdi-cooperation.com/2010/relationships/edd" Target="edd/Module_B.edd" Id="rIdEDD_Module_B"/> … </Relationships> Field Device Integration (FDI) – Part 4: FDI Packages RELEASED FCG TS62769-4, Ed. 1.2.0, 21 Jun 2019 Page 74 of 79 The entire set of EDD files can be found based on the specified relation type (Type = "http://fdi- cooperation.com/2010/relationships/edd"). The following catalog example is an excerpt to emphasize the concept of how the EDD file references work. The value calalog.xml defined element <EDD> refers to the package defined relation identifier (rIdEDD_HeadStation) that enables to retrieve the actual EDD file. <DeviceType> <Name> <value>Modular remote IO</value> . . . </Name> <ClassificationId>REMOTEIO</ClassificationId> . . . <Edd>rIdEDD_HeadStation</Edd> . . . </DeviceType> Field Device Integration (FDI) – Part 4: FDI Packages RELEASED FCG TS62769-4 , Ed. 1.2.0, 21 Jun 2019 Page 75 of 79 Annex J (normative) FDI Communication Packages for FDI Communication Server J.1 General Details on packages for the different profiles are defined in Annex F. Annex J defines details on FDI Communication Packages used for the description and reference of FDI Communication Servers. They can be considered independent of technology profiles. This only considers the package, not the FDI Communication Server itself, which is defined in more details in FCG TS62769-7. J.2 Protocol Support File No additional file is required for FDI Communication Server packages. J.3 CommunicationProfile definition No values of CommunicationProfile are defined for FDI Communication Server packages. J.4 Profile Device There is no concept of a profile device for an FDI Communication Server. J.5 Protocol version information There is no product version information used for an FDI Communication Server. J.6 Associating a Package with an FDI Communication Server An OPC UA based FDI Communication Server is uniquely identified by its ProductUri. The mapping of the catalog information shall be according to Table J.1. Table J.1 – Catalog Mapping Catalog Element OPC UA Mapping ProductUri ProductUri J.7 Handling of Catalog elements Some parts of the catalog need to be handled according to Table J.2. Table J.2 – Handling of Catalog elements Catalog Element Handling ClassificationId “NETWORK” ListOfSupportedDeviceRevisions XML Element not provided Field Device Integration (FDI) – Part 4: FDI Packages RELEASED FCG TS62769-4, Ed. 1.2.0, 21 Jun 2019 Page 76 of 79 J.8 Example An example for /fdicatalog/catalog.xml of an FDI Communication Server is listed below. <?xml version="1.0" encoding="UTF-8"?> <fdi:Catalog xmlns:fdi="http://fdi-cooperation.com/2010/package" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://fdi-cooperation.com/2010/package catalog.xsd"> <PackageId>f516f651-3e0f-4672-bcfe-67a4141a7a25</PackageId> <PackageType>Communication</PackageType> <Version>1.0.0</Version> <FdiVersionSupported>1.0.0</FdiVersionSupported> <ManufacturerName>Communication Provider GmbH</ManufacturerName> <ManufacturerContact>Hauptstrasse 17, Neustadt, Germany</ManufacturerContact> <ManufacturerUrl>http://cpg.local</ManufacturerUrl> <ManufacturerImage>rIdMfrLogo</ManufacturerImage> <CommunicationServer> <ProductUri>urn:cpg:comserver</ProductUri> </CommunicationServer> <ListOfDeviceTypes> <DeviceType> <Name> <value>FDI Communication Server for HART</value> <value xml:lang="de">FDI Kommunikationsserver für HART</value> </Name> <ClassificationId>NETWORK</ClassificationId> <ListOfInterfaces> <Interface> <ListOfCommunicationProfiles> <CommunicationProfile>hart_fsk</CommunicationProfile> </ListOfCommunicationProfiles> <Version>5.0.0</Version> <CommunicationRole>SERVER</CommunicationRole> </Interface> </ListOfInterfaces> <Edd>rIDEDD</Edd> <ListOfImages> <Image>rIdPicture1</Image> <Image>rIdPicture2</Image> </ListOfImages> <ListOfDocuments> <Document>rIdDocument1</Document> </ListOfDocuments> </DeviceType> </ListOfDeviceTypes> </fdi:Catalog> Field Device Integration (FDI) – Part 4: FDI Packages RELEASED FCG TS62769-4 , Ed. 1.2.0, 21 Jun 2019 Page 77 of 79 Annex K(normative) FDI Profile for EDDs K.1 Overview Annex K describes rules that need to be applied to an EDD in order to fulfil the conformance to the FDI profile for EDDs. Annex K does not define new EDD concepts or constructs but only defines that some optional constructs defined in the EDD specification are mandatory and some other concepts shall not be used in order to be compliant to the FDI profile for EDDs. K.2 Entry Point to Online handling The EDD shall contain at least one entry point to online handling (device_root_menu, diagnostic_root_menu, maintenance_root_menu or process_variables_root_menu). K.3 Entry Point to Offline handling The EDD shall contain at least one entry point to offline handling by providing the offline_root_menu. K.4 Upload and Download The EDD shall contain an upload menu (upload_from_device_root_menu or download_variables). The EDD shall contain a download menu (download_to_device_root_menu or upload_variables). The upload and download menu shall not contain any user interactions, i.e. no call to User Interface Builtins even in the case of an error. K.5 Initial Data Set The EDD shall provide a valid initial data set for offline configuration without being connected to the device. There shall be at least one device variant where this configuration could be directly downloaded without modifications. This can be achieved by using mechanisms defined in EDDL (e.g. INITIAL_VALUE, DEFAULT_VALUE) or by using the defaults of the respective data types. Note EDD offers additional concepts to create valid offline configurations like TEMPLATEs. Those can be used to create different variants of initial settings. K.6 Method GetHealthStatus The EDD shall include the GetHealthStatus method to provide access to health status state. See Annex H. K.7 Actions K.7.1 Pre- and Post-Read Actions The pre- and post-read actions (PRE_READ_ACTIONS and POST_READ_ACTIONS) on VARIABLEs or MENUs shall not contain any user interactions (call to User Interface Builtins). K.7.2 Pre- and Post-Write Actions The pre- and post-write actions (PRE_WRITE_ACTIONS and POST_WRITE_ACTIONS) on VARIABLEs or MENUs shall not contain any user interactions, i.e. no call to User Interface Builtins. Field Device Integration (FDI) – Part 4: FDI Packages RELEASED FCG TS62769-4, Ed. 1.2.0, 21 Jun 2019 Page 78 of 79 K.7.3 Refresh Actions on Variables The refresh actions (REFRESH_ACTIONS) on VARIABLEs shall not contain any user interactions, i.e. no call to User Interface Builtins. Note other refresh actions (e.g. on graphs) may have calls to User Interface Builtins. K.7.4 Actions on BIT_ENUMERATION Actions on BIT_ENUMERATION shall not contain any user interactions (call to User Interface Builtins). K.8 Shared files Use of shared files (using SHARED on the FILE construct) is not recommended and will be ignored in FDI Hosts. Note future versions of the FDI Technology may support this feature. Next >