Reusable Application Layers

While VTScada's development tools are useful for a wide variety of industries, you may want to create additional reusable objects. These objects might be device drivers, reports, tag types, widgets, or other software modules.

With the VTScada layering system, you can create these tools in one application then re-use them in many others. This feature is especially useful for system integrators who develop applications for several clients in a particular industry. It is also recommended for use with subordinate applications (Master & Subordinate Applications).

Perhaps the best reason to use an OEM layer is that this is the easiest way to distribute custom tags, etc. to other applications.

OEM Technically: "Original Equipment Manufacturer". In practice, any application can be an OEM layer. layers are used for any, and sometimes all of the following reasons:

• You have a set of industry-specific tools that you want to re-use for a number of client applications.
• You want to ensure consistency of certain things across applications.
• You don't want to distribute your source code.
• You want to ensure that other developers, using your application, cannot modify the structure of certain tags or other objects. Sometimes, this is to protect those objects, and sometimes the reason is demarcation of responsibilities.

 

A certain amount of care and planning is required for the design of your OEM layer to ensure that everything works smoothly. Certain items can or cannot be overridden at the local level, depending on how you configure things.

How it works:

Every standard application is built on top of the VTScada System Layer application. All the pages you see in a new application, all of the default tags including Alarm Priorities, Fonts, and Menu Items, all the built-in reports, the Idea Studio with all of its widgets, and much more are defined in the VTScada layer and inherited by your application. You can change some of those tools, such as choosing a different font for one of the Font tags. Other things, such as the Alarm page and Operator Notes page, can be used but not changed.

Perhaps in your application, you build a new tag type called The Gizmo for equipment unique to your industry. You also create a widget that represents all the I/O and alarms for The Gizmo. Further, you have created a report so that operators can view a daily summary of how The Gizmo performed yesterday.

You are using tools inherited from the VTScada layer to build new features in your application.

 

Two plants use The Gizmo brand hardware for their operations. Your application will be distributed to both plants to serve as the OEM layer for their applications. The applications at Plant A and Plant B also inherit all the features of the underlying VTScada layer, so they also have all the standard tags, widgets, reports, etc.

If the Gizmo manufacturing company adds a new feature, you will modify your application to incorporate that into your tag type, widget and report. You then send a Snapshot ChangeSet to both Plant A and Plant B, updating the OEM layer at each location. They can now install and use the latest Gizmo, without needing to do a thing to their applications. The changes were incorporated when they applied the ChangeSet to the OEM layer.

 

Any VTScada application can be used as the base layer ("type" or "OEM layer") for another. When creating every new VTScada application, a required step is to select its type. (The "Quick Add" option in the wizard simply sets the type to Standard Application, meaning the VTScada layer.) If, in the Add Application wizard, you select the Advanced option, and then New, you are given an opportunity to choose the layer that the new application will be built upon and inherit features from. It is possible to create a chain of many such layers, each inheriting the features of all the layers below it.

There is an exception to the rule: Script applications that you create cannot be used as OEM layers. Script applications are not built on top of other layers.

The primary benefits that you gain from the VTScada layering system are re-usability and extensibility:

Re-usability:

Inheritance from lower application layers to upper layers means that the custom tools that you create for an OEM layer can be used in other applications. You do not need to recreate those tools or features for every application.

Extensibility:

New functions can be added to existing objects such as tags and drivers without changing the structure of applications built on the OEM layer. For example, if you extend the feature set of a custom tag in an OEM layer, then applications built on that OEM layer will immediately have access to the new feature set in your custom tag. Note that certain changes may require a restart before taking effect.

 

Other benefits from the use of OEM layers include:

• Provides a clear distinction of who is responsible to maintain what portion of an application.
• Ensures consistency across applications.
• Separates the fundamental tools (tags, widgets and other code modules) from the application using those tools. Where application-specific customizations are required, it may be possible to apply a local override to the OEM definition, depending on what you are changing and whether source code is provide with the OEM layer.

OEM layers should be used by:

• A system integrator who deploys SCADA/HMI applications with similar general functionality such as water wells or gas plants.
• A organization that uses a standard set of SCADA/HMI functionality across two or more facilities
• An original equipment manufacturer that deploys a common user interface with their equipment, where the user interface needs minimal or no unique configuration for each equipment installation.
• An organization that needs a clear line between the parts of an application that can be edited and the parts that are under more strict change-control.

Best Practices:

• Whenever the application design calls for two or more of the same complex tag type, widget, or other object, consider creating its template in the OEM layer.
• Choose the type of ChangeSet according to your intended purpose.
  • For distributed development, standard ChangeSets are best because updates are merged.
  • For customers, Snapshot ChangeSets are best because they cannot see your development history.
  • To protect your proprietary work and to prevent edits of the resulting application, choose not to include source code with your Snapshot ChangeSet. This works best when used as an OEM layer.

If you intend to send updates, it is important to use "Create from ChangeSet" and never "Clone from ChangeSet". A clone will have a different GUID, and you will never be able to distribute updates to it.

• If distributing a Snapshot ChangeSet without source code, and if you want to leave the default Overview page intact for applications to edit, then delete the OEM layer's copy of Overview. The default VTScada version will take its place and be available to the dependent applications. After deleting your copy of Overview, you will need to edit the page menu to put the VTScada version back in.
• Consider enabling security in your OEM layer.
• Consider setting the flag, DoNotStart, in your OEM layer, just before creating the ChangeSet for distribution.
• Clean the OEM layer application before distribution.
  You will inevitably create instances of tags, widgets and pages in the OEM layer when designing and testing new objects. Before distributing the OEM layer, delete everything that you do not want to be part of applications built on that layer. For example, a new VTScada application has a TCP/IP Port tag type, but it does not come with instances of TCP/IP Port tags.
• In an installation with primary and backup servers, ensure that Application Configuration option, "Synchronize the configuration of OEM layers via derived applications" is selected in the top-level application (found in the "Other" tab of the Edit Properties page of the Application Configuration dialog) so that updates to the OEM layer will be distributed using the same server list.