Some questions concerning HIST

[Nabla]

Hi all,
i've recently approach Foundation technology, so i'm trying to look for benefits in the use of different manufacturer's hosts.
Looking the HIST page on the Foundation Fieldbus web site I wasn't able to understand the exact meaning of explanation detalis of feature described there.
Could someone let me show differences between Device Description Services, DD Method Execution, DD Menu Handling and DD Edit Display Handling? Without the last feature (DD Edit Display Handling), but with all the other above, what kind of actions I won't be able to do?

Thank you

[rezabejd]

I'm unsure of the extent to which the HIST test reveals differences between hosts. If I was shopping for a host, I'd spend a few days or a week somewhere like SAIT (http://www.sait.ab.ca/flash.htm ) or Lee College (http://www.lee.edu/ ) and "audition" candidate systems for myself. I'd go in with a list of specific tasks (things like on-line changes, changing configuration to an online system, control in field devices, BLAS functionality demo, etc.) and see how each system handles them.

John Rezabek
BP

Hi all,
i've recently approach Foundation technology, so i'm trying to look for benefits in the use of different manufacturer's hosts.
Looking the HIST page on the Foundation Fieldbus web site I wasn't able to understand the exact meaning of explanation detalis of feature described there.
Could someone let me show differences between Device Description Services, DD Method Execution, DD Menu Handling and DD Edit Display Handling? Without the last feature (DD Edit Display Handling), but with all the other above, what kind of actions I won't be able to do?

Thank you

[jberge]

The HIST test validates if...

# H1 FEATURES SUPPORTED
*Device Tag Assignment
If the host software is able to assign a physical device tag (PD_TAG) to an H1 device
*Device Address Assignment
If the host software is able to assign an address to an H1 device
*Configuration of Link Master Devices
If the host software configures the H1 link master devices properly, permitting them to take over the LAS function if the host interface fails, and to return LAS to the host interface when it recovers.

# HSE FEATURES SUPPORTED
*Basic HSE Device Support
If the host interface supports DHCP and SNTP for the HSE network, and that HSE devices appear in the host's network status table (live list). If the host software is able to read and write parameters in blocks in a HSE device or in H1 devices on the underlying H1 network.
*Device Redundancy Support
If the host software is able to configure a redundant HSE device pair such that a secondary takes over in case primary fails and that primary and secondary roles are restored when failed device recovers.
*Interface Redundancy Support
If the host software is able to configure an HSE device with redundant ports so that the "B" port is used if the "A" port fails.
*Linking Device Support: 42a2
If the host is able to configure a HSE linking device so that the host software is able to perform the H1 tests: assign address and tag to an H1 device, configure link master and function block links.
*Linking Device Support: 42b
If the host software is able to configure a HSE linking device to forward reports distributed from H1 devices to the host over the HSE network, e.g. alerts, trend, and MVC
*Linking Device Support: 42c
If the host software is able to configure a HSE linking device to republish a function block link from a block (in a H1 device) on one H1 port to a block (in a H1 device) on another H1 port of the same HSE linking device. Similarly, from a block in a H1 device to a block in a HSE device. And also from a block in a H1 device on one H1 port to a block in a H1 device on an H1 port on another HSE linking device.

# FUNCTION BLOCK FEATURES
These tests apply to both the host software's H1 and HSE capability since the function blocks in H1 and HSE devices are the same.
*Block Tag Configuration
If the host is able to configure a function block tag in a device. Note: some hosts may require a special utility software other than the regular configuration tool to do this as the user defined tag may normally not be downloaded to the device.
*Block Instantiation
If the host is able to instantiate, and to delete function blocks, in devices supporting this feature
*Standard Blocks
If the host software is able to identify the standard (and enhanced) blocks in a device and read the value of parameters in standard blocks and the standard parameters of enhanced bocks. The host software shall also be able to write parameters that are not read-only.
*Enhanced Blocks
If the host software is able to read the additional parameters of enhanced blocks and write the parameters that are not read-only.
*Custom Blocks
If the host software is able to read parameters of custom blocks and write the parameters that are not read-only.
*Function Block Linkage Configuration
If the host software is able to download a link between blocks in different devices to those devices, together with associated schedule etc.
*FF Alert Configuration
If the host software is able to configure a device to direct its alerts (alarm or event) to be captured by the host software
*FF Alert
If the host software is able to capture and acknowledge alerts (alarm or event) generated in devices. Note: additionally users may wish to ascertain that these trend samples are indeed logged in the database and can be viewed just like alarms generated in the host software.
*FF Trend Configuration
If the host software is able to configure a device to direct its trend sample lots to be captured by the host software
*FF Trending
If the host software is able to capture trend sample lots generated in devices. Note: additionally users may wish to ascertain that these trend samples are indeed logged in the database and can be viewed just like trending done in the host software.
*Device Description Services
If the host software is able to correctly display parameter labels, values, help text, and enumeration text, etc. Note: It is also important to verify if the host software require additional proprietary files to support devices since this limits device options. Verify if some or all host software applications are able to function without proprietary files.
*DD Method Execution
If the host software is able to present methods (i.e. scripts for e.g. setup, calibration, and diagnostics) and execute them correctly.
*DD Menu
If the host software is able to present and navigate information in a predefined menu format.
*DD Edit Displays
If the host software is able to present and navigate information in a predefined edit display.
*Capability Files
If the host software accepts capabilities files. Note: Users may additionally wish to verify that the host software has been tested against a device that supports instantiable function blocks even though block instantiation is not supported in the host software. Even if instantiation is not supported, the host must be able to work with the default set of blocks in such a device without having to modify the capabilities files. Additionally users may wish to ascertain that the host software also makes use of information in capabilities files, this includes limits to the number of VCR and function block, device class and profile information, as well as current consumption.
*Multi-Variable Optimization
If the host software is able to configure a device to publish MVC, and if the subscriber can capture it.
*Software Download
If the host software is able to download firmware in a device.
*Flexible Function Block - Fixed OD
If the host software is able to download a block algorithm (created in device vendor tool) to a flexible function block (with a fixed set of parameters) in a device and can access the parameters and establish links to function blocks in other devices.
*Flexible Function Block - Variable OD
If the host software is able to download a block algorithm and parameter definition (created in device vendor tool) to a device and using the application specific DD and CF files (generated by the device vendor tool) be able to access the parameters and establish links to function blocks in other devices.
*Device Replacement
If the host software is able to detect a device has been removed, and also detect if it is replaced by the same type of devise of a different revision having different functionality. Note: this test is also intended to check what features the host software has to assist in configuration change to deal with the new device. Additionally the user may wish to check if parameters from a standard block automatically transfers to an enhanced block.

HIST is very technical, so it helps you alot by performing a very technical evaluation of capabilities it would be near impossible for a user to perform single handedly (and for a vendor do to with every potential customer). Remember it is "if" not "how". If making it happen requires special applications, lengthy preparation, and even a hundres clicks it is still considered a pass. Therefore I agree with Rezabeck that after narrowing down your choices you yourself take the finalist systems for a test drive to make sure it "feels" right.

DD services is a must, without it you cannot do anything. DD Method, Menu, and Edit Display are not critical. Even without those you can do everything you have to do, although it may not always be as neat looking and may require more clicks. Perhaps if FF put out a guideline on how device vendor can incorporate Method, Menu, and Edit Display with a consistent style (and do it for standard block DD) these may gain greater acceptance.

Jonas