Subordinate Application Tags
Not counted towards your tag license limit.
Provides monitoring and access to all tags in a selected subordinate application. The application holding the Subordinate Application tag is referred to as a Master application.
All the tags in the selected subordinate application will be visible as children of the Subordinate Application tag, so long as all user-defined types defined in the subordinate application are also defined in the master application. If the master application and subordinate application are not built on the same layer where that custom type is defined, then you must copy the definition from the subordinate application to the master application.
A master application can have several subordinate application tags, but each must link to a separate application. If two link to the same application, only one will function at a time.
You must have a security account with the Manager privilege in the subordinate application before you can configure a subordinate application tag to link to that application. You will be prompted for a username and password.
Security Management for Subordinate Applications
It may be convenient for a user to have a single sign-in account that can be used across applications. The only practical way to bundle security access to multiple applications within a single account is to use Windows Security Integration with all the relevant applications.
Active Directory accounts are independent of your applications. They gain access to your applications through AD Security Groups, which map to roles within the applications for which you have enabled Windows Security Integration (WSI). By associating a Windows AD account with the AD Security Groups for several applications, you achieve your goal of creating a single account with access to multiple applications.
For example, consider three applications, A, B and C. They all have a common role Operator and each has a unique role, Role-A, Role-B and Role-C respectively. Assume that all three apps use a common ADGroupPrefix of "VTScada". The AD account will be a member of four AD Groups; VTScada-Operator, VTScada-Role-A, VTScada-Role-B and VTScada-Role-C. The AD account, when used in each app will be assigned two roles, the common Operator and the appropriate Role-X.
You may wish to differentiate the Operator role between the three applications. Do so either by setting a different ADGroupPrefix for each application (the preferred solution) or by creating unique names for roles within each application.
For more information, refer to the Windows Security Integration topics, starting with Running Multiple Applications with WSI.
Do not use the "Shared Security" feature of the Administrative dialog. Windows Security Integration is a better solution. If you attempt to select a subordinate application that uses shared security, a warning message will be displayed.
Note to advanced developers: If writing an expression that involves a subordinate application, the value of a SubordinateApplication tag is TRUE when the subordinate application is running and synchronized with the master application, and FALSE when it is not.
Subordinate Application tags are excluded from tag exports.
Master & Subordinate Applications - A full description of master and subordinate applications.
Copy Types to Other Applications - Ensure that types defined in the subordinate are available in the master.
The ID tab of every tag includes the same common elements: Name, Area, Description, and Help ID.
Name:
Uniquely identifies each tag in the application. If the tag is a child of another, the parent names will be displayed in a separate area before the name field.
You may right-click on the tag's name to add or remove a conditional start expression.
Area
The area field is used to group similar tags together. By defining an area, you make it possible to:
- Filter for particular tag groups when searching in the tag browser
- Link dial-out alarm rosters to Alarm tags having a particular area
- Limit the number of tags loaded upon startup.
- Filter the alarm display to show only certain areas.
- Filter tag selection by area when building reports
When working with Parent-Child tag structures, the area property of all child tags will automatically match the configured area of a parent. Naturally, you can change any tag's area as required. In the case of a child tag, the field background will turn yellow to indicate that you have applied an override. (Orange in the case of user-defined types. Refer to Configuration Field Colors)
To use the area field effectively, you might consider setting the same Area for each I/O driver and its related I/O tags to group all the tags representing the equipment processes installed at each I/O device. You might also consider naming the Area property for the physical location of the tag (i.e. a station or name of a landmark near the location of the I/O device). For serial port or Roster tags, you might configure the Area property according to the purpose of each tag, such as System or Communications.
You may define as many areas as you wish and you may leave the area blank for some tags (note that for Modem tags that are to be used with the Alarm Notification System, it is actually required that the area field be left blank).
To define a new area, type the name in the field. It will immediately be added. To use an existing area, use the drop-down list feature. Re-typing an existing area name is not recommended since a typo or misspelling will result in a second area being created.
There is no tool to remove an area name from VTScada since such a tool is unnecessary. An area definition will exist as long as any tag uses it and will stop existing when no tag uses it (following the next re-start).
Description
Tag names tend to be brief. The description field provides a way to give each tag a human-friendly note describing its purpose. While not mandatory, the description is highly recommended.
Tag descriptions are displayed in the tag browser, in the list of tags to be selected for a report and also on-screen when the operator holds the pointer over the tag’s widget. For installations that use the Alarm Notification System, the description will be spoken when identifying the tag that caused the alarm.
The description field will store up to 65,500 characters, but this will exceed the practical limits of what can be displayed on-screen.
This note is relevant only to those with a multilingual user interface:
When editing any textual parameter (description, area, engineering units...) always work in the phrase editor. Any changes made directly to the textual parameter will result in a new phrase being created rather than the existing phrase being changed.
In a unilingual application this makes no difference, but in a multilingual application it is regarded as poor practice.
Help Search Key
Used only by those who have created their own CHM-format context sensitive help files to accompany their application.
Subordinate Application tag properties: Settings Tab
The Settings tab holds a drop-down list, from which you can select the subordinate application.
Authentication to an account possessing the Manager privilege is required if the subordinate application is secured. Trihedral strongly recommends that all applications be secured.
Immediately upon selecting the subordinate application, you will be prompted to authenticate with that application.
Enter the user name and password for an account in the subordinate application that possesses the Manager privilege.
The following widgets are available to display information about your application’s Subordinate Application tags.
Alarms in the subordinate application will not propagate to the master application's site icon widgets.