The design of this interface is based upon the assumption that many ITEMIDs are associated with other ITEMIDs which represent related values such as Engineering Units range or Description or perhaps Alarm Status. For example the system might be built internally of `records' that represent complex objects (like PID Controllers, Timers, Counters, Analog Inputs, etc). These record items would have properties (like current value, setpoint, hi alarm limit, low alarm limit, description, etc).
How `Properties' relate to ItemIDs.
In most cases it is expected (but not required) that such properties can also be accessed via ItemIDs such as FIC101.HI_EU, FIC101.DESC, FIC101.ALMSTAT, etc. These related ITEMIDs could be used in an OPCGroup. These methods provide a way to easily determine if such an alternate method of access can be used for the properties if large amounts of information needs to be obtained more efficiently.
A system like the one above (i.e. one composed internally of 'records') may also expose a hierarchical address space to OPC in the form of A100 as a 'branch' and A100.CV, A100.SP, A100.OUT, A100.DESC as 'children'. In other words, the properties of an item that happens to be a record, will generally map into lower level ITEMIDS. Another way to look at this is that things, like A100, that have properties are going to show up as 'Branch' Nodes in the OPC Browser and things that are properties are going to show up as 'children' nodes in the OPC Browser.
Note that the A100 item could in fact be embedded in a higher level "Plant.Building.Line" hierarchy however for the moment we will ignore this as it is not relevant to this discussion.
The general intent of these methods is to provide the following functions:
It should be noted that the first 8 properties (the OPC Specific Property Set 1) are 'special cases' in that they represent data that would exist within the OPC Server if this item were added to an OPC Group and may not represent `named' properties of the 'real' tag record in the underlying system. Several of the properties in this set coincide with fields in the OPCITEMATTRIBUTES structure. These include, CanonicalDataType, AccessRights, EUType and EUInfo. These properties, as well as those representing the properties of the Value, Timestamp and Quality, apply to an individual and valid ITEMID (one that is represented by a property ID greater than 99). Therefore, the OPC Specific Property Set 1 behaves differently in the methods on this interface. Refer to each method definition for the behavior description.
Examples
This is just an example. It is not intended to impose any particular structure on any server implementation.
A typical OPC ITEMID might be FIC101.CV. This could represent the current value of a tag or function block called FIC101. This function block commonly has other properties associated with it such as Engineering Units, a loop description, etc. This function block could also have alarm limits and status, a setpoint, tuning parameters as well as documentation cross references, maintenance information, help screens, default operator displays and a limitless set of other properties. All of these properties are associated with each other by virtue of their common association with FIC101. This interface provides a convenient shortcut to accessing those related properties.
For example an Analog Input function block might have a value, hi and low limits and a status. These might have ItemIDs of F100.CV, F100.HI, F100.LO, F100.STAT. Passing any of these ItemIDs to either IOPCItemProperties::QueryAvailableProperties or IOPCBrowse::GetProperties would likely produce the same result; i.e. a list of 4 property IDs (in addition to the 8 reserved property IDs) corresponding to each attribute. The same property IDs would likely be returned regardless of which ItemID was passed. Passing these 4 property IDs to IOPCItemProperties::LookupItemIDs or IOPCBrowse::GetProperties would also give the same result in each case in that it would return the ItemIDs mentioned here. Passing these property IDs to IOPCItemProperties::GetItemProperties or IOPCBrowse::GetProperties would also produce the same results for the values of each attribute. The one thing that would be different would be that passing any of the 8 reserved property IDs would fetch information related to the specific ItemID (i.e. would return the value, quality and timestamp associated with the specific ItemID passed as the first parameter to GetItemProperties).
An MMI package for example might use these methods to allow the user to indicate that the Hi and Lo Engineering Units values should be used to scale a bar graph representation of the value.
Note that because these associations can be 'many to many' and can also be circular, a client application would not want to automatically investigate them all.
It is NOT intended that property browsing be hierarchical.
Another similar example could be a function block such as a TIMER or COUNTER in a high end PLC where various Properties are associated with each object.