Learning More about Advanced SCADA with High-Performance HMI Design, Responsive Design, Data Historian & Aliasing Capabilities

Before a recent ICONICS webcast Learn from the Experts and Become a SCADA Power User, we polled the registrants to see what SCADA topics they wanted our experts to cover. The top two answers were high-performance HMI and responsive design, with a tie for third between historian reader and aliasing. Inspired by this webcast, I wrote about these topics in addition to how to use high-performance SCADA and HMI applications in this blog: The Ins & Outs of Becoming a SCADA Power User. Below, I’d like to dive deeper into high-performance HMI design and responsive design, as well as covering a bit about using ICONICS historian reader and aliasing. This way, you’ll have all this good SCADA information conveniently in one place.

High-Performance HMI Design 

“High-performance HMI design” has been used to refer to current, advanced, and technologically sophisticated SCADA systems that can handle more complex industrial processes and manufacturing. And specifically, when we talk about high performance HMI design, we are talking about enabling the performance of users rather than the system metrics and response times. So, we're talking about UI and screen design and the look and feel, that sort of thing. The intent of high-performance HMI design is to allow for responsive, flexible, adaptive, and easy to design and customize screens/graphics that make it easier for you to do your job. If your chosen HMI does make it easier for you to get your job done, you're doing things correctly. You can learn more about how to use high-performance HMI by taking a look at our blog The Ins & Outs of Becoming a SCADA Power User. Now on to our historian reader. 

Historian Reader

ICONICS Hyper Historian is used for extracting data for a single tag. It's a standalone app available as part of the ICONICS Suite that allows for direct export of historical captured data for a given data point and time range to a CSV file. When you pull it up, you'll get a dialog that allows you to pick a single tag and start/end times; you also can pick whether you want the actual raw logged data or if you want some aggregates like min/max or average over a period. If you pick aggregates, you'll be able to choose the period over which you want to aggregate the data to be calculated. And then you'll be able to pick a file that the historian reader will export the data into. There are some other ways to get historical data besides the historian reader, but the historian reader is by far the easiest way. You run the program, you specify the tag, and it sends the data into a file where you can look at it.

But if you want more than one tag, for example, if you want the values of temperature readings for all monitored equipment or if you want the data in a format other than CVS, or if you’re feeding the data to a web app or loading it into a database, you might want to take a look at other ways you can access Hyper Historian. And all these methods can be found in the help documentation on the ICONICS website. One way is to use an OLE DB link server that you can hook into the SQL Server to allow essentially pseudo-queries within SQL Server to pull Hyper Historian information and input it into a table. Additionally, AnalytiX-BI has data sources that can pull Hyper Historian data, raw or aggregate, or even alarm histories into an AnalytiX-BI data model. And from there, you can either input it into tables within AnalytiX-BI or straight onto the screen. I'll cover responsive design next.&;

Responsive Design

Responsive design is something that’s been a big emphasis for people in the web design world for quite some time now but wasn’t in high demand within SCADA applications until much more recently. In general, it's a design approach that allows you to create optimal viewing across various devices and form factors, with the visual elements automatically readjusting their size and layout based on the device’s aspect ratio and screen resolution. Those of you who know the frustration of trying to browse a web page that wasn’t optimized for mobile viewing from your smartphone can understand the value of responsive design. So why shouldn’t the same design standards apply to your HMI and SCADA applications?

In terms of what problems are solved with SCADA responsive design, it really helps to optimize the user experience on any device; not only on a PC that might have different resolutions but also on anything from large TVs down to tablets or even smartphones. And this is achieved by allowing you to create content in a way that will automatically adjust to different platforms. As such, today’s technology is going away from the antiquated way of designing interfaces into a more fluid approach. You can understand this by thinking about how a liquid poured into the container adapts to that container as it fills it up.

Responsive design is a key principle supported by ICONICS visualization software, GraphWorX64, and is a terrific way to earn your SCADA power user badge since this means knowing how to optimally use ICONICS to get the most out of your operational data. This also includes understanding a bit about how this technology works. What follows is an explanation about aliasing, and I’ll go into this in a bit more detail because it’s extremely helpful and cool.

Aliasing

Aliasing is a tool in the ICONICS suite that allows you to create a placeholder in just about any part of your configuration. A placeholder is simply a variable that will be assigned its value at a later time. It allows you to create your application, including your entire asset hierarchy and visualization displays, without needing the data. You then feed data into the application through these placeholders. Placeholder values can be set at the time you deploy the configuration in order to provide flexibility in the output, whether used in graphics, reports, transactions, or just about any other configuration, and these can be changed in runtime as well. Placeholders are not tied to any real I/O, and (this is important) these are independent per user session.

To take a simple example: Say you want to make a symbol for a variable frequency drive (VFD), and you have a large number of VFDs in your project. Instead of making a separate symbol for each one, you can use aliasing to include placeholders in the appropriate parts of your data sources within that symbol. You then only have to maintain a single symbol and by way of aliasing, you can use it to look at data for any VFD throughout your system.

Here's another example: Say I have a system with three data sources as follows:

100 Foxborough / Floor 1 / Room 1 / Temperature

100 Foxborough / Floor 1 / Room 2 / Temperature

100 Foxborough / Floor 1 / Room 3 / Temperature

As an alternative, I could just write my data source with a placeholder like this:

100 Foxborough / Floor 1 / <#RoomNumber#> / Temperature

Then, when I go to request it, if I say: <#RoomNumber#> = Room 1, I will get

100 Foxborough / Floor 1 / Room 1 / Temperature .... and so on. And I can change that on the fly by using simple buttons or graphical symbols, so the operator can simply tap on the relevant piece of equipment to immediately see the data corresponding to it.

In this way, aliasing allows you to parameterize data source paths. It enables ICONICS GraphWorX64 to use placeholders that will be filled in at runtime. And it’s immensely helpful for deploying SCADA systems and results in substantial benefits allowing you to reduce your engineering time by making more reusable, flexible, and scalable displays. Now let’s look at some popular types of aliasing which include language aliasing, color aliasing, and screen reuse.

Popular Types of Aliasing

Language aliasing allows the screen designer to use placeholders for words and terms and then depending on the user's choice, fill those placeholders in with different language translations for the proper term for the placeholder. For example, if there's a label on a graphic that is intended to say "temperature" in whatever language the user selects, then the designer of the GraphWorX page can use an alias of ”T_Label” and define the alias so that the value of the alias is "temperature" if the user selects English or "temperatura" if the user selects Spanish, or "sıcaklık" if the user selects Turkish, and so on. 

Color aliasing allows the screen designer to use placeholders for colors and then, depending on the user's choice, fill in those placeholders with a particular color from a color scheme. In its simplest form, you might have color aliases "background" and "foreground". If the user selects the "day" theme, the background could be set to white, and the foreground set to black. If the user selects the "night" theme, then "background" would be set to a dark color and "foreground" set to a light color. This is a popular feature within our system integrator community as well because it enables them to quickly deliver brand labeled applications that match the color scheme and branding of the customer they’re working with.

Of course, you could, if you opted to, forgo the use of color aliases, but then you'd have to create a separate copy of each screen for each possible color theme. For example, if an application involved 100 graphic screens and you wanted to offer three color themes for day, night, and high contrast, that would mean the SCADA system admins would have to deal with 300 screens instead of 100 screens. And whenever they wanted to, let's say, add a new process point to one screen, they'd have to make the same change to the two other screens that correspond to the other two themes.

Screen reuse allows the screen designer to use placeholders for parts of the address of a process point. This means that instead of having to build 100 screens to display data about 100 different meters, a designer could build one screen to display the data for an aliased meter so instead of using "ac:Site1/MainMeter/KW" as the data source, the designer would use "ac:<#SiteAlias#>/MainMeter/KW". Then the designer would design the rest of the screen so when the user clicks on Site #1, the SiteAlias would be set to "Site1", making the data source effectively be "ac:Site1/MainMeter/KW". When the user clicks on Site #2, the alias would be set to "Site2", and the data source would evaluate to "ac:Site2/MainMeter/KW". Designing your screens in this way means that the person developing the SCADA application does not have to create separate meter screens for each site. And even more importantly, they don’t have to maintain separate screens for each site, so a change to the single alias-using screen will (since there's only that one screen) show up regardless of which site was clicked.

Similarly, if you have a building with 100 fans, aliases let you define just a single "fan" screen and use it regardless of which fan the user wants to look at. Without aliases, there'd be 100 different screens to build and maintain.

Done properly, aliases are invisible to the "operator" (or the person viewing the GraphWorX screens to monitor some plant or building processes). Aliases are an immense benefit to the people who actually build and maintain the GraphWorX screens. The bottom line is that without aliases, system administrators would have to build and maintain A LOT of almost-identical screens.

Major Takeaway – Not All SCADAs Are Created Equal

Not all SCADAs are created equal. They just aren’t. Some are much more technologically advanced with impressive capabilities that will help you and your team do your jobs easier and better. What that translates to is the ability to achieve operational optimization, which of course is what we’re all striving for. With that in mind, why not check out our high-performance and responsive HMI/SCADA GENESIS64 with aliasing and our historian reader Hyper Historian. There is also a wealth of information on our website, and you can always contact us or request a demo. The choice is yours.