In the old times, stories were how humans shared information with one another. Today, data is, supposedly, how we share information with one another… but is that accurate? As everyone obsesses over data, the question brews: is your data telling you a story or is it just numbers on the screen?
For many industrial companies, the answer was unsatisfying… until the Reporting module in Ignition came into play, equipped with the PDF—”Plant Drama Forecast” (spoiler alert: no drama has been reported, but that’s also thanks to the quick problem-solving as a result of data and reporting).
Table of Contents
Set the scene
We’re here to talk about a water and wastewater company in Denmark—a huge one, with over 18 treatment plants, 16 waterworks, 1,300 pumping stations, and 3,500 km of rainwater and wastewater pipes. They handle wastewater for 425,000 consumers and supply drinking water to 300,000 consumers.
Safe to say: everything in the operation needs to go as smoothly as possible to treat water well and supply clean water to the citizens. That’s why we have been building a complex modern SCADA system in Ignition to connect machines, plants, and systems. We’ve worked on the essential first step: get data. The next step is to actually use it, and that means analysis.
The challenges
The keywords for this part of the project were “Alarm Analysis”. As in any SCADA-related realm, alarms are crucial indicators that you need to take action. Thus, the way you see and interpret the alarms decides what action you’re going to take. You want your data to tell a significant part of the story already, so you can focus on decision-making.
That’s why they wanted to present data in reports that share knowledge about what’s really going on. Let’s get into some practical examples.
The solution
Alarm Analysis – Municipality report
So, this is data that they already have, but the report is “bringing it to life”, and sharing it with the relevant people. The report can be created automatically within a timeframe of their choice, and automatically sent via email to anyone. The elements you see here, like the pie chart, are standard components in Ignition. The Pie Chart takes a Data Source with two keys: a Label (typically a string) and a Value (typically a numerical value).
The conversation bubbles in the picture express a few best practices that should be found in a report like this.
First, let’s understand how reports work.
In the reporting module, you don’t have the same components as in Vision or Perspective. You have charts and labels, but they are not the same and the amount of components is limited. With those components, you configure your report. That determines how the sheet will look. It’s like a blueprint for a document file – where the data is going to go and how that document file is going to look when the report is generated.
But when is the report generated? Well, it can be generated on a report viewer (either in Vision or Perspective) or it can be generated by a scheduled action to be saved as a file or sent by email, for example. Essentially, we use the report module to create the blueprint of the report and the data flow for it, and then we create/view that report from somewhere using Vision or Perspective.
This report was created using the Reporting module and Vision, as this is what our client uses. But both Vision and Perspective have a “Report Viewer” component. That means that the reports that we create using the reporting module can be seen from either one. As for the “Report Viewer” components, they are very similar aside from some small functionalities. The one for Perspective, however, looks much more modern.
Alarm Analysis – Plant report
In the first report, you saw that there were 21 alarms on the main plant. In this report, you can see exactly what pieces of equipment triggered alarms. Most importantly, you can see which piece of equipment triggered the highest number of alarms—thus, you know what needs your attention the most. Moreover, the table also gives you context: ok, you got an alarm, but what is it about? In this case, we have high/low pressure and temperature.
There’s another point here to be made: the good operators know their plants so well that they often have a hunch – “that pump doesn’t sound good”, for example. But it’s instinctual, they can’t quite put their finger on what’s going on. Data shines a light on exactly that, so they can take data-driven action.
Pump Time Report
Our client needed a report to tell them for how long certain pumps were running. They didn’t want the pumps running for too long in order to avoid damage. Thanks to the report, they can decide when to give a pump some rest and/or do maintenance.
The benefits of reports
Instead of giving you bullet points, let’s share a few practical situations in which reports save resources (this is not about this specific client, but rather stories gathered from our experience).
Prevent damage/downtime
Say you have a report showing you the number of alarms in a given timeframe for a piece of equipment. In a month, a booster shows 21 alarms—so, there was an alarm almost every day. Is that booster going to break? What’s going on there?
Based on the report, you can go in and check that booster before it breaks. Thus, you prevented downtime. It’s also a way to remove the excuse “we didn’t expect that”.
Keep the team lead informed
The team lead gets a weekly report about alarms, especially the alarms that weren’t cleared.
When an alarm is triggered, the operator gets a red frame around and it blinks. He/she can acknowledge it to confirm that they’ve seen it, so it stops blinking, but it’s still red because it wasn’t resolved. If the alarm isn’t cleared, the team lead will see that in the report, and he/she will ask what’s going on – was that alarm unimportant, did anyone forget to clear it in the system, was it not resolved? Essentially, the team lead will know that an alarm is suspicious, and will act on it.
In the report, the team lead can also see the blocked alarms.
The operators may block alarms so they don’t fire while they do maintenance. But sometimes, even after the machine is up and running again, they forget to unblock them. The team lead will see in the report which alarms are blocked and if it makes sense for them to stay that way.
Be compliant and show it
A water and wastewater company, for example, has very strict rules and laws to follow to be able to deliver to their customers. On top of that, the governmental structure that is in charge of ensuring high-quality services from utility companies like this will want reports to see that the company is compliant.
While completely understandable from a safety point of view, for the utility company, this can be a hassle, especially if the task is manual.
An example of functionality that helps with this is a report being sent automatically monthly (or whatever timeframe you choose) to the relevant public official via email. The public official doesn’t have to log into any of your systems, they will just get a PDF in their inbox with the report. You keep the government happy and the fines away.
The report will contain the elements and parameters of your choice.
Extra note here: it’s all about transparency. When you have data, and you have it presented in reports, you keep the relevant people informed so they know when and how to best take action that benefits your operation business. Data and reports keep your employees accountable.
Best practices in reports
Reusable and parameterised
The reports should be heavily parameterised and reusable. If there are, for example, multiple machines that could use the same report, we create only one that is parametrised by the machine name, tags, or characteristics.
Queries vs. Scripts
The data sources should be queries if possible. If the desired functionality can’t be accomplished with a single query or nested queries, then we use scripts.
In case we are using scripts, they should be properly commented on. It must be very clear what the script is doing and especially where the data is coming from and how it’s being filtered.
Functions go into the scripting library
In the case functions are needed, it should be considered to place them in the scripting library, especially if they could be used in other reports or elements in the project. That way, we keep the data source script clean, and we make sure that all reports that use the same function get the latest changes to the function.
Optimise resource consumption
Querying and reading operations should be kept to the possible minimum, and recursive functions should be used with extreme care. There might be a case where the reports are created in the background (no front end) and the user has no influence on them, but if the user can determine how the report is created, we don’t want a report that takes very long to load or a potential gateway crashing report due to a recursive function being wrongly parametrised.
The scripts should be as little resource-demanding as possible. Whether there’s a front end or not, creating the report will take some resources from the server and could compromise performance elsewhere.
Only necessary data
The data made available as a data source for the design tab should only be the necessary, relevant data. When using scripting, we could make every piece of data in the script available as a data source for the design tab, but we should avoid this. Only the data that is going to be displayed or used as a condition in the design tab should be passed.
Add a “No Data” message
There should always be a message indicating if no data was retrieved. It’s important to make it clear when the data is not there because of the user’s input/lack of events and not because of missing data. We don’t want the user to think that there’s something wrong with the database just because there were no alarms in the selected area for the selected period, for example.
Scheduling
Schedule actions should be spaced considering the client’s needs and the report data. Also, the number of actions should be kept to a functional minimum. For example, if the report shows how many hours a machine has been running, it makes no sense to print or save a report every 15 min.
When sending an email on a scheduled action, the email message and subject should be modified to be descriptive of the type of report, the installation the report corresponds to, and the date of the report. The same goes for the attached file’s name in the email.
Take-home points
Whether you have a utility company like our client or any industrial company that wants to work smarter, promote transparency and accountability, and reduce risks, reports are the way to go.
Of course, the first step is to connect things and get your data in one place. When you have that, you’re ready for analysis. You find small problems in the daily work of the people on the plant floor that can be solved with data, and fix them. One by one.
