Master & Subordinate Applications

A master application is one that is able to monitor and control one or more subordinate applications. Master applications provide the following features:

  • Monitor the status (including alarms) of tags in one or more subordinate applications.
  • View, trend and report on logged data from tags in the subordinate applications.
  • View all pages in the subordinate applications for which you have security privileges.
    Pages are automatically added to the master application's menu, contained within a folder named for the subordinate application.
  • View tag configuration in the subordinate applications.
  • Acknowledge alarms in the subordinate application from the master application.
    (Alarm from subordinate applications do not sound in the master application, but are visible.)
  • Draw and use subordinate application tag instances in master application pages.
  • View page notes from subordinate applications.
  • Add page notes to subordinate applications.
  • View alarm database groups in subordinate applications.

Township A and Township B are completely separate applications.
Master Application can monitor both.

Related information:

Subordinate Application Tags

Copy Types to Other Applications

Windows Security Integration

Restrictions and Notes

  • A master application can see only the immediate subordinate applications. If one of those is also a master application, its subordinates are not visible to its master application.
  • There is no requirement that you layer the master application on top of the subordinate application. The concept of master and subordinate applications is distinctly different from VTScada's system of layered applications.
  • You must install the subordinate application in the same VTScada Application Manager as the master application. The subordinate application need not run when you create the Subordinate Application tag, but no tag values are available unless it is running.
  • User-defined tag types defined in any subordinate application must also be defined in the master application.
    It is significantly easier to manage master and subordinate applications when they are all built on a common layer. In particular, this will eliminate the need to copy tag type definitions (and updates to same) from subordinate applications to master applications. It also reduces the likelihood of conflicts if subordinate applications contain custom tag types with the same name but differing definitions.
  • Master applications do not have access to draw custom widgets from subordinate applications unless that widget is also copied to the master application. Likewise, master applications cannot edit pages from subordinate applications. (Subordinate pages and their custom widgets are visible to the master application.) Like custom tag types, custom widgets should be stored in a common OEM layer that both the subordinate and master application are built upon.
  • Idea Studio palettes from subordinate applications are not available in master applications.
  • System resource limitations may restrict the number of subordinate applications a master can monitor, especially if those applications are "large" with many thousands of tags. Numbers are not available because any hypothetical limit will depend on hardware and on the design of the subordinate applications.
  • Master applications cannot log data to subordinate applications.
    Nothing will stop you from selecting a subordinate application's Historian while working with logger tags in the master application, but no logging will occur. Likewise, do not link SQLLogger tags from a subordinate application to SQLLoggerGroup tags in the master application.
  • If working in a master application and configuring any of Polling Drivers, DriverMux or Transaction tags, do not select child tags from the subordinate applications. Behavior in this situation is undefined.
    While master applications can write to tags in subordinate applications, you are advised to keep process control of an application within that application.
  • Subordinate alarms are labeled for their application, as viewed from the master application. They are not sent out by the alarm notification system in the master application.
  • Tag naming rules continue to apply. The overall length of a tag name, including components from both the master and the subordinate application cannot exceed 255 characters.
  • If using realm filtering, refer to notes in [RealmName-REALMFILTER] Section

  • On root session (Server):

    • Master App plays all alarm sounds

    • When a Master App is running the Subordinate App:

      • Plays no sounds

      • Disables Mute and Silence buttons

  • On VIC/Anywhere connection:

    • All Apps play all sounds

Process

An application becomes a master application when you add a Subordinate Application tag, which is the parent for all tags in the subordinate application. Before creating a Subordinate Application tag, ensure that the following are in place:

  1. Configure security.
    • Enable security in what will become the master application.

      This is not a technical requirement, but it is strongly recommended.
    • Secure the subordinate application.
    • Ensure that you have access to an account with the Manager privilege in the subordinate application.
      After authentication, the Subordinate Application tag will continue to function regardless of any changes made to the account used for authentication.
    • If output tags in the subordinate application are protected by custom privileges and if you intend to write to those tags from the master application, then your security account in the master application must possess custom privileges that match the privilege index numbers (not the names) of those in the subordinate application.
    • By definition, master applications are meant to have extensive abilities to monitor subordinate applications. If your intention is to allow an employee to monitor application A and B, but not C, then it is better to have them sign in to applications A and B directly rather than a master application that monitors all three.
  2. Ensure that tag definitions and widgets are available to all applications.
    • All user-defined tag types in the subordinate application must also exist in the master application. This includes any defined in underlying OEM layers of subordinate application. The type and its child tags are not visible otherwise.
    • All user-defined widgets in the subordinate application must also exist in the master application.
    • The recommended approach is to ensure that the master application and subordinate applications are based on a common OEM layer where those tag types and widgets are defined. This is by far the easiest method to use in terms of long-term maintenance.
    • As an advanced option, steps to copy types are provided in Copy Types to Other Applications. This practice is not recommended, but may be necessary in rare circumstances.
  3. Create one Subordinate Application tag in the master application for each subordinate application.

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.