The Global Aliasing System or GAS is a powerful referencing feature implemented in GENESIS64 , that you can use in applications like GraphWorX64, TrendWorX64, and AlarmWorX64 to display multiple data sources using a single reference. When you use global aliases a dynamic operation such as a mouse up on a button can change the reference from one value or group of values to another. This allows you to change between one group of objects and any other group of objects that have a similar set of properties.
When you design a display any process point can contain one or more global aliases. By indicating the value of each alias the Global Aliasing Server is able to resolve the reference and insert the correct value for the tag at runtime. That tag is then used to display the current data being observed or controlled. In practice you might define a button that cycles through a set of ten different values with each click. With each click the global alias changes from value 1 to value 2 to value 3 ... and so on to value 10 at which point it returns to value 1. Each click then changes the data source for a process point in a GraphWorX64 display (for example), and at runtime the data changes on your display. With this system in place you have made a single process point and the button do the work of ten process points on a single display or alternatively the work of ten displays with a single process point. That is the power of global aliasing.
Consider the following sets of hierarchies in the table below.
Comparing Alias Hierarchies
|
Global Aliasing |
Object Hierarchy |
Building Example |
File Structure |
|
Theme |
Namespace |
Buildings |
Root |
|
Alias |
Class |
Building ID |
Folder |
|
Alias Child |
Object |
Floor |
File |
|
Alias Grandchild |
Component |
Room |
Content Type |
|
Alias Value |
Property |
Device |
Content |
Global aliases can be anything that your imagination can think of. For the system to work it needs to have an organizational structure that groups common objects into classes with similar properties, along with a common namespace that allows the referencing system to make sense to your developers or users. Aliasing works in object hierarchies that are used in software design (Microsoft Office, for example); and it works for file systems, physical systems such as buildings, and many other systems that you can design. For information about configuring global aliasing, refer to Global Aliasing Configurator.
A global alias is a data string that enables you to reference multiple data sources (e.g. a trend pen in TrendWorX64 or a process point in GraphWorX64 ) with one unique name. In GraphWorX64 global aliases refer to the fact that those aliases are available to any application on that computer. Because you can reference multiple data sources from a single location, global aliasing can reduce the overall number of individual display files you need to create and the number of tags that you need to manage.
The Global Aliasing system provides global storage for a string of aliases and resolves the aliases in runtime. The aliases can be used in OPC tags, menu items, file names, etc. The figure below shows how a global alias links to multiple OPC tags in a GraphWorX64 display, for example. The data values with which the global aliases are associated are called alias values. All global aliases and alias values are created and configured in the Global Aliasing Configurator .
Single Alias for Multiple Data Sources
A collection of aliases with similar properties is called a theme. Aliases can have subclasses, eventually leading up to the value or property you want to return. Consider lights in a building that you monitor, with each individual light reporting its current condition. Each light is assigned an alias, and that alias is globally available to GENESIS64 applications. In the scheme shown in the building example column buildings are subdivided into individual buildings, floors, rooms, and then the data sources you want to monitor. The address to a particular data source might be the following:
@Buildings.Administration.Floor_1.Room_103.Light_08
With this addressing scheme for three buildings, each with six floors, 34 rooms, and 20 lights you would have to define 12,240 unique tags on a display to fully define the namespace. However, you could do the following: define a Building_ID alias; substitution of which into your path would yield:
@Buildings.<# Building_ID#>.Room_103.Light_08.
|
|
Note. Global aliases are referenced by enclosing them in angle brackets and number symbols: <# Global_Alias_Name#>. |
This single substitution now cuts the number of unique tags you need to create by a factor of three. Multiple aliases could reduce the problem to the following:
@Buildings.<# Building_ID#>.<# Room_ID#>.<# Light_ID#>
Now the problem has been reduced to defining three unique objects or aliases that you can use anywhere. To accommodate the actual alias values you would need to define those values within each alias: the three different buildings, floors 1 through 6, rooms 01 through 34, and lights 01 through 20. The individual "objects" you've had to define is now reduced to 3 + 6 + 34 + 20 = 63; which is a lot less work than defining 12,240 unique tags. Once you'd defined the aliases and values you reuse them over and over.
Consider a GraphWorX display of your three buildings, which for the sake of argument are all of the same design. When you select the value for the Building_ID your display changes to show the label in the title bar indicating which building you are looking at. For the sake of this example, we'll say it's the Administration building. On that same display you select the floor number and your display now shows a diagram of the floor with the rooms it contains. You only need to have one floor/room diagram for all of your buildings. When you specify your room number, another display can appear showing the different lights in the room. Again you only need have one room diagram. Then finally you select the lights you want to examine, or perhaps you have a status indicator showing the light condition without clicking. You've reduced your design problem down to a very small number of common components, and specified an individual data source using only three different values. Your aliases allow the complete path to be built from the references you supply, a process that is referred to as alias resolution. For more about this process, refer to Global Alias Resolution.
For uses of global aliases, refer to:
Using a Global Alias in a GraphWorX64 Display
Using Global Aliases with TrendWorX64
Using Global Aliases in AlarmWorX64
Global aliases are stored in the central global database (Microsoft SQL Server or Microsoft SQL Server Express) and those aliases can be accessed over the network by clients allowing you to reduce the amount of work even further. With global aliases you can use a generic display to view the data from many different tags. When you install GENESIS64 the installer creates a GAS server database. You may want to or need to create and configure your own GAS databases when as you create global aliases.
Global aliases and the related concept of themes save you a lot of time and effort, but require that you put a little time and thought into organizing your alias schemes so that it makes sense to your users. Without global aliases the amount of work required to build sophisticated HMI displays would be so large that they would be entirely impractical. That makes global aliases a central concept and practice that you can use again and again in your work.
To provide a reasonable performance, the local clients do not connect directly to the database (Global Aliasing Engine Server or GAS), but communicate with a Global Aliasing Client ( GAC), which will obtain the requested information and cache it locally. The figure below shows the Global Aliasing System architecture.
|
|
Note. For examples of how Global Aliasing is used in GraphWorX64 displays, see the example files in the GenDemo : FLOOR_CONTROL_GAS.GDFX, FLOOR_OVERVIEW_GAS.GDFX, and LAS_Example.GDFX (for a language aliasing demo). |
Global Aliasing System Architecture
Notice the central role that the FrameWorX server plays in making global aliases function correctly. If you find that your global aliases do not resolve, or you are missing connections to the data sources required to resolve your global aliases you should make sure the FrameWorX server is functioning correctly and the service is running.
See Also:
Global Aliases Tab on the Data Browser
