Coming soon! Our webinar just ended. Check back soon to watch the video.
In this webinar, Frederik Van Leeckwyck, the Business Development Manager at Factry.IO will share how their Industrial Historian solution, Factry Historian, helps their customer, A&S Energie, achieve greater efficiencies with their energy generation. A&S Energie is a Belgian biomass plant that supplies electricity to households by burning non-recyclable wood. They replaced their existing Industrial Historian solution with the Factry Historian which allowed A&S Energie to increase the use of the process data to make their staff more efficient as well as find failures faster.
The Factry solution collects and processes data from industrial systems and stores it in InfluxDB. In addition to sharing how well A&S Energie is able to manage their plant, Frederick will also review the challenges and pitfalls specific to time series data in industrial settings as well as how they were successfully able to migrate from an existing process historian to Factry’s Historian, powered by open source InfluxDB.
Watch the webinar “How Factry’s Industrial Historian Solution Helps A&S Energie Generate Electricity Efficiently” by filling out the form and clicking on the download button on the right. This will open the recording.
Here is an unedited transcript of the webinar “How Factry’s Industrial Historian Solution Helps A&S Energie Generate Electricity Efficiently”. This is provided for those who prefer to read than watch the webinar. Please note that the transcript is raw. We apologize for any transcribing errors.
• Chris Churilo: Director Product Marketing, InfluxData
• Frederik Van Leeckwyck: Business Development and Marketing Manager, Factry
Chris Churilo 00:00:00.567 Good morning, good afternoon, everybody. My name is Chris Churilo and I work in product marketing here at InfluxData. Thank you so much for joining our webinar this morning. Today we have one of our fabulous users, Factry, who are actually customers, Factry. And what Frederik from Factry is going to review today is a use case with one of their customers, A&S Energie. And with that, I’m going to stop talking and let Frederik introduce himself more thoroughly and also take it away.
Frederik Van Leeckwyck 00:00:32.975 All right, Chris. Thank you very much for the intro and hi everyone. Thank you all for joining. So I guess I should probably say good morning, good afternoon, and good evening to all of you. And also thank you to InfluxData for hosting this webinar. So, during session, which should take about an hour, I would like to share with you how Factry uses Influx technology in Factry Historian to help A&S E or A&S Energie produce electricity efficiently and with more confidence.
Frederik Van Leeckwyck 00:01:10.571 So, to start off, I would like to share with you first just a little bit about myself. So speaking to you is Frederik Van Leeckwyck. I’m a bioscience engineer by education and I’ve been involved in engineering for a couple years already. And at Factry, I lead and I’m responsible for the business development efforts. And for this project, in particular, at A&S Energie, I was the project lead, which meant making sure that we got the project delivered on time, which we did. And I consider myself very fortunate that I can really have—share my love for technology both in my private and professional life.
Frederik Van Leeckwyck 00:01:54.758 So the agenda for the webinar today. It consists of four points. First off, I would like to start with an introduction about Factry as a company and A&S Energie as the energy plants, as one of our clients. Secondly, I would like to dive into a little bit of industrial IoT. So what is industrial IoT? How does it compare to the consumer IoT? So nuancing the things—the Internet of Things a little bit. And then in point three, we’re going to dive into the bulk of this presentation. So we’re going to share how we used InfluxDB’s technology at A&S Energie from a technical point of view and also from an outcome perspective. So what value did A&S Energie get out of this solution? And we should end with a recap and some takeaways, of course. But many of you probably have a very busy schedule and takeaways—I wouldn’t want to wait with the takeaways until the very end. So, for those of you who can only attend a short part of this webinar, I would like to start off with the takeaways as well.
Frederik Van Leeckwyck 00:03:11.865 So the key takeaways are threefold, I believe. I believe with this technology, with this project, at A&S Energie, we’ve proven that InfluxDB is ready for use in industry and is really powerful in that use case. We have many installations over Factry Historian running based on InfluxDB for many years now. And this is performing really well. And especially since it’s used for storing data, especially if you combine this with Grafana for the visualization of the data. This has proven to be really valuable because it increases the data visibility. It puts process data, industrial process data, at people’s fingertips. And this increased data visibility has shown to really have real value. And we’ll show that towards the end of the presentation as well. And then, I believe, we can also look at it from a bit of a broader perspective. And if you look at the project we did for A&S Energie, was done completely with open source components, of which InfluxDB is one. And, I believe, at the end of this presentation, you’ll also agree with me that open source can play a really good role in a production context where typically it was finding increased use in the enterprise, in production more or less absent. But I believe the time is there that we can really introduce open source technologies in the production environment.
Frederik Van Leeckwyck 00:04:44.146 So without further ado, let’s dive into the introduction about Factry and A&S Energie. So a little bit about Factry, what we do, very simply stated, is data-driven operational improvement. And we focus ourselves on the process industry which can be the processing of real physical things, like food processing for example, on the one hand. And on the other hand, you could say also processing—energy generation is also a process that runs continuously. And we were founded by a couple of ex-Siemens MES specialists. And I want you to envision this together with me. Imagine you’re working at Siemens, you’re working on an MES product, which stands for Manufacturing Execution System, and you’re working with these technologies in your daily job. In the evening, you come home. You open up your laptop. You open up your IEE. And you start working with open source languages with—you’re using projects backed by amazing communities. And I believe you quickly will come to the same realization as we had. We can probably do this better. And we can probably do this with open source technologies. So that’s why—our founder has written a blog in 2016 —that’s when Factry was founded—and you can—I share with you the link here. But you can also very quickly Google that if you just type into Google “open-source historian,” you will very quickly find that blog. It’s on the first page. And this has proven to be the founding of Factry. So we built Historian and I’ll show you what it does and what value it has in this presentation based on open source technologies.
Frederik Van Leeckwyck 00:06:30.045 So this is a slide from our very first presentation and you can see that early on, already in 2016, we decided on the technologies that we were going to use in our products. And if you want to gain insight into how processes are running in your factory or your energy plans, you need two types of data. You need time-based data and you need relational data. So the time-based data, very simply stated, it’s going to give you—it’s just a set of values. For example, the value at that sensor at that point in time was this. The value of this sensor at that point in time was that, and so on. So that’s, very simply stated, time-based data. Relational data is something you will encounter next to that. And that’s typically what you see if you talk about management dashboard, KPIs, and so on. Most of the time, this is based on relational data. And we see there’s a link between them. So we decided to focus on these technologies and if you look at InfluxDB back then—so we benchmarked several Time Series Databases back in the days and quickly found that Influx was the most powerful for our use case and decided to go with them. But you’ll see throughout this presentation that other pieces of software such as Postgres have also been used at A&S Energie and have proven to be valuable there.
Frederik Van Leeckwyck 00:08:02.189 So Factry Historian. I believe for those of you who are used to working with the Influx’s technologies, then you probably also heard about Grafana. So this is what you would see as an end user. The Historian gives you real-time and historical insights for everyone from the machine operator to the plant manager. And there’s good reason why we highlight everyone. The technology in itself is very—it’s really advanced. It does amazing things. And it has become so powerful that it’s—now that everyone can start using this and everybody can gain insights into how the processes are running. And that’s what I meant with putting data at people’s fingertips. It’s so easy to use that you can see that everyone in these plants is working with the data. And I’ll show you more concrete examples at the end of the presentation, or towards at least. So, Historian, it’s one software product—one of our software products. And this is used to visualize but also build further applications on top of that. And they’re based in Gent, so if you’re ever in Gent, I hereby invite you to visit our office and maybe we might explore this lovely city together.
Frederik Van Leeckwyck 00:09:20.529 Then that’s a bit about Factry. We dive into A&S Energie. So what is A&S Energie? It’s a power plant. And what they do is they burn non-recyclable wood at a rate of about 22 metric tons per hour. And non-recyclable is really the key here. So what does it mean? It’s wood that has no other purpose anymore except for burning it. This means that this type of wood also cannot be used for engineered wood, for example. Burning is the only—it’s the final thing you can do with it. So it’s really non-recyclable wood there. By burning that, they get—they generate power for about 55,000 households. And the total plants needed an investment of about €90 million or $106 million. The plant itself has been operational since 2010 and if you look at it from a—this is really new. This is a really modern plant. It’s state-of-the-art. But if you compare that with the development in the IT landscape, this is more or less the middle ages, if you could call it like that. A lot of things have changed since 2010. Industry 4.0, which is a really popular term, wasn’t even coined back then. InfluxDB didn’t exist. But the plant itself, of course, was already running. So the plant itself is really modern, but if you look from an IT perspective, a lot has changed since its initial operation in the summer of 2010. So the building looks like this. It’s huge. It’s huge. It’s incredibly nice to visit once. They typically open up. You can tour the plant once every year. It’s a very big building and at the core of it all is this. It’s a huge kettle, nine stories high. And it’s constantly fed with wood, non-recyclable wood, which is then burned to generate steam. Steam passes over a turbine and generates electricity. So that’s at the core of what they do.
Frederik Van Leeckwyck 00:11:21.200 So that’s a bit of an introduction about Factry and A&S Energie. So now we’ll dive in—dive you—dive a little bit more into the industrial IoT. And, I believe, if we talk about IoT, typically, we all think of consumer devices. If you look on the right, for example, the Amazon personal assistant at home. That’s a typical consumer device. And something that’s maybe some of you already have. And this is something we immediately recognize as part of the consumer Internet of Things. So it’s machines talking to machines, using the Internet communication technologies. And on the left side, you can see tado, for example. This is a smart thermostat. This would also be a consumer Internet of Things. We know they were at InfluxDays last week. They’re also monitoring their smart thermostats with InfluxDB’s technology. And, as you can see, these are consumer devices. So these things are consumer devices. But, in the industry, these things are a lot bigger. This is a steam turbine. It’s huge. But also these things need to be monitored. And I believe it’s important to stand still a little bit and to nuance these things. If you look on the left, you can see the Internet of Things. Typically, we’re talking about consumer devices. While, in the industrial Internet of Things, we’re going to be talking about industrial equipment. And the useful life is also totally different. For consumer devices, typical useful life would be years. While in the industry, hopefully, many decades. The cost also is several orders of magnitude different. And because of the very nature of the Internet of Things and the consumer Internet of Things, these devices are distributed. Smart thermostats are present in various people’s homes. So it’s distributed. While, if you look at the industrial Internet of Things, in a lot of cases, it’s rather confined. The A&S Energie, it’s a single plant. All measurements, all sensors, are present in the plant. So data collection should also be done locally. We can sometimes see—we have a few installations running where more distributed data is needed. But I would not compare this to the same scale as the consumer Internet of Things. So I believe it’s important to make this distinction and—for further clarification also during the rest of this presentation.
Frederik Van Leeckwyck 00:14:03.194 So now we’ve had—we’ve seen a little bit about Factry, A&S Energie, and we understand what the industrial Internet of Things is, and also what it’s—how it compares to the consumer worlds. Now we come to the bulk of this presentation where we’re going to share with you how we used InfluxDB at A&S Energie. We’ll share with you, first off, how A&S Energie was working before our intervention. And then, next, we’re going to go into five steps towards the business value at the end. So we’re going to be sharing a little bit about historians, what they are, what they do, how InfluxDB has been used by us in the industry and as a component of Factry Historian. We’ll stand still at one point where we migrated their existing historian to Factry Historian through InfluxDB. We’ll share with you some more technical information on how we collect data from the industrial systems. And, finally, we will share with you how this time series data is now actively being used by the different people within the plant, or in plants.
Frederik Van Leeckwyck 00:15:17.903 So how was A&S Energie working before? So A&S Energie is being operated, being run, by a team of about 25 people, consisting of management and operators. So, operators, they work in shifts. So you come in in the morning—as an operator, you come in in the morning. You have an eight-hour shift ahead of you. And part of the things you need to do in your shift is you need to complete a piece of paper with on it several values of counters of certain values that are present that are needed for reporting on the status of the power plant. So you take this piece of paper and you go around in the total plant. You go in the various rooms. You note the counters on this piece of paper. You end up in the control room. You also there note some values from the screens. And, in the end, at the end of your shift, the total paper is completed. Management then takes over. They take this piece of paper. They type—they copy the values from the piece of paper into Excel then which does some calculations and some conditional formatting—which, in the end, gives them the KPIs they need to see whether the plant is running well or whether things need an intervention. And, as mentioned very briefly before, they already had a historian so they were already calculating—or collecting—I’m sorry —data from their process. But it was underutilized. It was sitting in a closet somewhere collecting data but nothing was really being done with it. And if you look at the total process, what they were doing, it worked. They were gathering data. They were taking—they were making sure that the plant was running. But it was error-prone and rather time-consuming. And I’ll share with you also how much time we were able to save by using these technologies.
Frederik Van Leeckwyck 00:17:17.981 So, as I mentioned, the operators, they also took some values from the control room. And this is how a typical control room looks like in the industry. What you can see here is a scale of system that’s being used to control the plant and what you see here are certain screens that are used to really interfere in the process and monitor it. You can also see your trending here. Some webcams, some cameras that are used to monitor the plant from a distance. And, maybe less obvious here, you can also see pieces of paper and a pen. People writing down values or things they see from these systems on paper, which are then used for reporting as kind of a logbook. So this is, I think, very good example of how a—what a typical control room looks like. So people are writing down values from these screens on the paper which was then used for reporting. So that was how they were working before.
Frederik Van Leeckwyck 00:18:18.060 So now let’s start with the first part about historians to give you the background you need to understand this a little bit better. So historians, what are they? They are pieces of software nowadays that are used to collect process data from production sites. Very general, you can find them in many different industries. And typically, they are categorized. Or you can see that these historians, that they will advertise based on what their ingestion protocols are, what kind of languages do they speak, or what the amount of writes per second are, or what the different kinds of data retrieval modes, how you can query them, these kind of things. So these are the characteristics that are typically used to categorize historians. But, in the end, what you typically see, in most cases, these are proprietary Time Series Databases that are sold by large vendors on proprietary systems. And I’m not kidding—if I share with you this screen. This is something that we encountered a couple of months ago where we needed to set up a test system to make some—to do some tests for our development. And I decided to include this because this was really wonderful to hear the Microsoft Windows 2000’s start-up chime for the first time in over 10 years. But, really, these are the types of systems that you often encounter in industry. And, so, really, sometimes, a bit old-fashioned and definitely very closed. So those are historians. They collect data. This is then used for further integration with other pieces of software.
Frederik Van Leeckwyck 00:20:08.029 So what role can InfluxDB play in the industry? This is the second point. So InfluxDB is being used to store time series data, right? We’ve seen that in the beginning, we store time series data. But even just—you’re not going to just collect them. You want that to be useful. So what is useful? In a lot of cases, the classical use case for a historian is trending, making graphs. And we noticed very early on, to make this historian very easy to use for everyone, that it would be much easier for the operators to just select a metric from a drop-down menu. Say I want to see the value from this specific sensor, give it to me now. So, operators, more or less, people working with these systems, management, they want to—they want really simple things. They want, more or less, they want to see pointy-clicky things, right? Also, you can see that a lot of the times, in a lot of the cases, the metrics are named after the sensor. So there’s already some classification present in the measurement name. And the sensors have a unique name which can be found in the P&ID diagram, so the piping and process implementation diagram. So the sensor is already uniquely categorized. The measurement name in the database can thus be very easily selected by the people working in the plant that know how their process is running as well. And, thirdly, we can see that if you’re using InfluxDB in the industry, data being collected is also not as homogeneous and a bit more difficult to compare if you compared to, for example, monitoring CPU usage of a certain server. If you would have to—if you’re monitoring a data center, for example, you could monitor the CPU load for your different machines and you could compare them. But to moderate pressures, for example, it might make sense to compare pressures, but in a lot of cases, it really doesn’t because it could mean that you’re monitoring pressures for the one installation on one end of your site and pressures for another measurement in a totally different part of your site, and they have no relation whatsoever. So it’s also a bit difficult to compare that.
Frederik Van Leeckwyck 00:22:41.896 Now, if this all sounds a little bit difficult or a little bit technical, I made a short video that I would like to share with you now to show you how—what we mean with easy-to-use. I’d like to run this for you now. It’s only 17 seconds. But what you see here is Grafana for visualization. And people in the plant, they just want to see a drop-down menu with the values from, for example, their temperature measurements. They just want to select it and see the graph, very simple, so no WHERE clauses, no additional, maybe more technical, things. At least in the beginning, they just want something very easy to use.
Frederik Van Leeckwyck 00:23:29.583 Then what you see if we’re using this type of databases, so InfluxDB, in the industry. We can see that the write loads are in the order of magnitudes between several tens and several thousands writes per second. Local sites, so small companies, SMEs, that typically have one or just a few production lines, have between 10 and 100 measurements being written per second to the database. Larger sites, such as A&S Energie, can go up to several thousands. So, for A&S Energie, it’s between 2 and 3,000 measurements per second being written. And this can, of course, be a little bit higher if you go onto the corporate level where you start aggregating the data from different sites. In some industries, you have to go much higher and you need data at a much higher resolution. But for the use cases that we’ve used InfluxDB so far, this has proven to be valuable enough. And then, lastly, or lastly on this slide at least, the use of InfluxDB is also platform-independence. We’ve seen the screenshot of Windows 2000 a little bit earlier. Most historians are based on proprietary systems and are Windows-based. InfluxDB has a database that’s platform-independent, so I believe this is also really valuable. And we run all installations on Linux.
Frederik Van Leeckwyck 00:24:56.916 Another third point, what’s also rather special of using InfluxDB in the industry is that, in all cases, we use infinite retention policies which means we—there’s no load dumping. We keep the data at its original resolution for as long as needed. And, because, if you see it—what we’ve seen it a couple of slides ago. If you look at the table where industrial Internet of Things, data collection is rather confined. And data collection is being done from that single plant. In most cases, we use a local virtual machine at the site to collect the data. So there’s hardly ever a cloud-based system being set up. We have a few of our historians running in the cloud but it’s still rather rare, I would say. So those are a few peculiarities of InfluxDB in the industry that we’ve encountered so far.
Frederik Van Leeckwyck 00:25:58.688 Now, for A&S Energie, I mentioned that they already had a historian running, and they wanted to migrate it to InfluxDB. It was not being used that much. So they wanted to use Factry Historian. And to do that, they needed to migrate the data into InfluxDB. Since the plant had been running since 2010 already, they already had years of data at second level precision at their disposal. But, as mentioned, it was not being used yet. So we built a custom migration tool written in Golang to transfer the data from the old historian to the new. We’re looking into open sourcing this migration tool, by the way. But we’re still making sure that we don’t run into any legal issues there. But it could be nice to open source a migration tool from different industrial vendors of historians and making sure that you can easily transfer these to this database. Once the tool had been built, it took us 47 days to migrate. And, of course, we kept track of how well this process was running. And you could clearly see that the bottleneck from migration was in the read speeds of the existing historian. So network was not an issue. Disk speed was not an issue. It was really the read speeds of this existing historian. So in the end, after migration, the data was compressed from 120 gigabytes previously, in their previous historian, to 30 gigabytes in InfluxDB. And once we collected, once we transferred everything, we made a switch to live data collection after the migration. So now they are gathering data. So, now, A&S Energie is collecting data from all their industrial systems through Factry Historian. I will share you through this setup in a minute. And then all this data is then being stored in InfluxDB.
Frederik Van Leeckwyck 00:28:05.804 So now we come into rather technical part where we share with you how data is being collected, so how the collector setup works. And it’s pretty important to stand still here because, of course, there’s certain things we need to take into account to make sure that we don’t lose data, on the one hand. And that we are in line with security policies for the network security within these plants, of course. So we build collectors at Factry for different protocols. And they are being used as input for InfluxDB. So what do these collectors do? They talk an industrial protocol on one end and HTTP on the other. And they work according to a store-and-forward model. So that means that each collector has a local buffer where they store data on-disk for the—in the cases, for example, that the network connection would be down, that we still keep a local copy of the data. As soon as the network connection is back up, the data is being forwarded to the database. But next to data being buffered, we also keep a local copy of the configuration so that in the rare case where the collector would start and would not have any network connection to know which data it should collect, it can rely on its local configuration copy and start collecting data from there.
Frederik Van Leeckwyck 00:29:41.428 So setting up these collectors is somewhat complicated. Why? Because, typically, in manufacturing sites, energy plants, you have separated networks. And these networks are strongly separated by a firewall and, typically, you would find the production network on the one hand and the business network on the other. And because these collectors are built in the way we did them. So this makes sure that we only need outgoing connections from the production network to the business network from the machine where the collector is running to where our API is collecting the data. So the setup looks a little bit like this. You have the production network below the line. You have the business network above the line. And in the production network, you have this data system, the PLCs that are controlling the process. And our collectors collect data from these systems, right? For example, they speak OPC UA in most cases recently. So these collectors, they gather data and they forward it through the firewall towards an API component that sits in the business network. This component does more or less two things. On the one hand, it’s being used to configure metrics, configure measurements, why do people using this software. And next to that, it also has a runtime, which collects the data and forwards it to InfluxDB.
Frederik Van Leeckwyck 00:31:11.558 So collectors, they are built to register themselves. So we have, as mentioned, many different collectors that gather data from these industrial systems. So in the operator interface, you create a collector. You give it a name. You give it a type. You save it. You generate a JWT token for this new collector. This is rather technical but I’ll share with you how this looks like in a minute. And this token contains two things. It contains authorization, so am I allowed to send data? And secondly, it contains the location of the historian API, where to send the data to. Then you start the collector within the production network and the only thing you posit is this token. And it’s the only thing this binary needs. So most of the time, you deploy a single binary. It starts with this token and it starts—it signs up to the historian API and then starts collecting data as soon as it’s configured. So this looks like this. This token on the left hand, this is the only piece of data we need to pass to a collector. And from that point and time, the collector knows where it should have—where it should send the data from, to, at least, when it expires, what type of collector it is, and so on.
Frederik Van Leeckwyck 00:32:31.639 So, for a person using the software, this looks like this. You have here on the right side, you can see collectors. So here we added two collectors. One that speaks OPC UA and one that gets its data from binary Excel files. So the OPCUA collector, you add it. You give it the endpoint of the OPC UA server. You add authentication, use a name and a password if that’s necessary. You save the settings. You generate a token. And the token is the only thing you need to pass to the data collectors in the production network. As soon as this collector starts, it will become active. And that means that you can start collecting or adding metrics to it. So, at A&S Energie, we have two types of collectors in use. One is speaking OPC UA, so an industrial protocol to gather data from the SCADA systems. It collects data from two separate SCADA systems. So two systems that are used to control the plants. And we save the status of the OPC—we save the OPC status as a tag in Influx for our own reference. Secondly, we also gather data from Excel files that are being output by their systems and that contain emission data. So, of course, as they’re burning wood, they have certain emissions, particulate emissions and certain gases that they need to check for environmental legislation. So these files are also being scraped by one other collector. Data is also being sent to the historian API and then ends up in InfluxDB. So we have many different collectors that all speak their own language.
Frederik Van Leeckwyck 00:34:22.033 Then, once the collector is added, you then add metrics to that. Often, in the industry, they are called tags. And in the case of OPC UA, most of the time, we have two types of metrics where metrics are either polled or monitored. Polled means give me a value every two seconds, for example, where you’re going to request a value every two seconds. And monitored, that would be give me—or send me a new value only if it changes. Which it would be useful for a valve, for example, if it opens or closes. So only give me the value if it changes rather than every two seconds, for example. So configuring metrics is also done in the same interface. You select a group. You give it a name. You give it a description. You say, “I want to add this to my OPC UA collector.” You give it a node ID, collection type, an interval, and an offset if that’s necessary. You add it. And, immediately afterwards, the collector will start. It will notice that new metrics have been added. It will check if it can request that value from the OPC UA server. If it’s possible, it will validate it and as soon as this metric is valid, it will start sending the data to Influx. And important to note here is that this interface and what you see here, this is something that people use in the business network. So the collector sits in the production network, as we have seen, and sends the data. That’s the collector that takes the initiative to collect to this system—to connect to this system and get its metrics from there.
Frederik Van Leeckwyck 00:36:02.501 So that’s, again, coming back to the setup, so the collectors are being defined. They sit in the production network and they take the initiative to send data out to the API and then to Influx. And also they take the initiative to request their configuration from the business network. And by doing so, you take away all the potential security vulnerabilities you could have by opening—by allowing connections from the business network towards the production network. And, of course, the historian needs to be monitored as well. Next to monitoring the plant, we also need to monitor the historian. So that’s why we eat our own, or InfluxData’s, or Grafana’s dog food. If no new data comes in for 30 seconds, we get alerted immediately and that’s why we are able to offer Historian as a service. It already happens—or it happens that we know that something is wrong in the plant before our clients do because we get notified very quickly on data collection issues in the historian.
Frederik Van Leeckwyck 00:37:09.193 So we’ve seen now a lot of technical things. We’ve seen how data was migrated, how it’s being used in the industry, how the collectors work from a security point of view and also a use point of view. Now, what do we do with all this data? And, as I mentioned in the beginning, trending and visualization of the data being collected is, I would say, use case number one. So dashboards is something that has proven to be really interesting for the people at A&S Energie. So you can see that they used Grafana for ad-hoc trending and really everybody uses these—everybody’s, in the meantime, already very well used to creating their own dashboards for trending certain value very quickly. Building a dashboard, adding measurements, seeing how—what it looks like, and then discarding the dashboards afterwards. And you can even see that certain dashboards have been—that certain dashboards have really found their way into the control room. And that they’re being used next to the SCADA systems because they are live—or more or less live—or showing more or less live data. And, as mentioned, so the operators, management, they make their own dashboards and that’s what I meant with—in the beginning, where I said there’s a dramatic increase in data visibility. Data is now present at their fingertips. And you see that they start using it in ways that we could never imagine in the beginning. And, also, they are discovering new uses of their dashboards and of their data with dashboards every single day.
Frederik Van Leeckwyck 00:38:50.366 So this is a screenshot of one of their—one of the dashboards that was being used for ad-hoc trending. So just measurements, things that they do very quickly and then discard afterwards. But this is, for example, one of their dashboards that they use to monitor silo levels. We anonymized this, of course. But these are silo levels. And it’s being used by the people there to see what the status and the volume is of their silos, whether they need to empty it or fill it up. And you can see that they—they used the alerting feature, for example. They also used some more advanced functionalities of Influx. For example, give us a difference compared to the previous day. How is this silo being filled or emptied? And you can see, we weren’t able to share this right now, but every person in the company has its own folder with their own dashboards and they use it very easily.
Frederik Van Leeckwyck 00:39:52.214 So next to trending and visualization, the second use is sampling. So, as mentioned in the earlier slides, we’ve seen this table with time series data on the left side and relational data on the right side. So we also need to gather KPIs for management to know whether their plant is running well or not. And to do so, we built a plant model based on ISA 95 in Postgres. So this is the Postgres elephant. So ISA 95, for those of you who don’t know it, that’s an international standard for the integration of enterprise and control systems. And it consists of terminology and models. And one of those models is this plant model where you can see a hierarchy from the enterprise down to the production units. So it looks—it goes like this: from enterprise to site to area to production units. So a site would be A&S Energie. An area would be an area within the site, for example, a control room, the turbine room, etc. And then you can see a certain unit would be a turbine. And we give this turbine properties. For example, give me the total run time of this turbine at midnight every single day so we can report this to management whether there was, for some reason, some downtime of the turbine, for example. So we monitor it. This equipment model in ISA 95 in the Postgres database. We give it certain attributes that are—define sampling frequency. And then we ask a system that should have a value present, and it should have this value to input this into the database. In some cases, this is still manual. Some counters at A&S Energie still need to be recorded manually. But if the value is present in InfluxDB, we can add it so people—so this system at midnight will sample the total runtime of the turbine with this very simply query: select last value from this turbine where time is before now. And then this value that is being returned is stored in Postgres and then used for further reporting based on calculations.
Frederik Van Leeckwyck 00:42:16.502 So once data is present in the relational Postgres database, we add—there’s a second or third service running that does calculations on these collected measurements. So the calculation demon gets notified by new entries, then calculates KPIs for management. So actually these are rollup metrics. So that could be very simple, from mass to volume, total hours of runtime, the difference compared to yesterday, these kind of things. This is the kind of data that’s, typically, then being used for KPI reporting.
Frederik Van Leeckwyck 00:42:55.858 So a lot of technicality, a lot of things on how we implemented InfluxDB and how we helped A&S Energie. Now, what does A&S Energie get out of this? What we’ve seen quantifiably already, at this point in time —it’s been running now for close to a half year—is that management saves about 10% per day on reporting. The process of collecting things on paper and inputting in Excel is completely a thing of the past. They don’t have to spend any time on that anymore. They just log into the system and very quickly see whether the plant is running okay or not. And, if not, they can quickly—because the data is readily available, they can quickly find out what’s wrong. And, earlier this year, because the data was that visible and they were so—because the data was that available to them, they were able to avoid a very costly unplanned downtime because they saw that some values were increasingly off and they really—they were really grateful for that. So that’s quantifiable, but there’s—the feedback we get is also rather qualitative. You can see that because everybody that’s working with these systems on a daily basis, their work satisfaction has gone up. This is really something they mentioned to us. They said, “The software is so easy to use for both from a configuration point as from a use point of view, that it’s really helping us to do a better job on a daily basis.” So that was really interesting and very nice to hear from the clients.
Frederik Van Leeckwyck 00:44:45.512 So we’re ending, or we’re coming towards the last slide of this presentation where we end up again, or we try to wrap it up with the key takeaways. I believe with A&S Energie, we’ve shown that InfluxDB is ready for use in industry. It’s been running fantastically and has been doing a really good job as part of the historian solution. And together with Grafana, this increased data visibility has been really powerful. And then my third point, as I mentioned in the beginning, that open source really has a role to play in production. It’s something really valuable. The whole project was done with—so everything is running on Linux servers. We use InfluxDB and Grafana, Postgres database, everything is being deployed with puppets. So a complete open source stack that’s actively being used to monitor a complete energy plant. I think it’s something rather nice. So that was the end of my presentation. I hope I’ve been able to share with you how this technology as part of the historian has proven its value already, how it works from a technical point of view, and also how A&S Energie has been able to use this system at this point in time.
Chris Churilo 00:46:16.607 That was a very well-done webinar. That was brilliant, Frederik. I think everyone appreciates the historical perspective, also, what you actually implemented for your customer A&S Energie as well as how you used InfluxDB in your Historian as a service solution. So if anybody has any questions, please feel free. Put them in the Q&A in the chat panel. We do have a couple of questions that we will read out loud and have Frederik and team answer. I just wanted to remind everybody, please post your questions in the chat in the Q&A. And we’re about 10 minutes away from the top of the hour. So if you all also want to raise your hand and ask your questions directly, just let me know. And I can also unmute you and we can start to have a conversation. So the first question that we have is: For the sake of load balancing, is it possible to run multiple OPC UA collectors simultaneously?
Frederik Van Leeckwyck 00:47:19.394 Yeah, so we currently have multiple OPC UA collectors running simultaneously, but we’ve not—we don’t have the possibility yet to use them for load balancing purposes. This is something that’s been requested already a couple of times. So I think we’re aware of this need and this is something that we’re going to spend some time on investigating. So, yeah, it’s a work-in-progress, I must say.
Chris Churilo 00:47:51.395 All right. So the second question, from Ronan, is: What’s the biggest barrier to adoption of this kind of system in industry?
Frederik Van Leeckwyck 00:48:00.548 I think one of the questions we sometimes get asked is, yeah, the perceived risk of using open source software. I believe that’s definitely one that comes up quite often. Although, I think times are changing. I think that’s definitely one of the things we see there for this—as a barrier for adoption. Secondly, also, these technologies, definitely if you look at Influx, for example, they’re perceived as rather new. And, as I mentioned, the industrial equipment should last for decades and you can see that, yeah, this is put into perspective. Okay, Influx is a rather new technology, but I want my turbine to still be operational in 30 years. How do you relate to that? That’s also a question we sometimes get.
Chris Churilo 00:49:02.837 Cool. Thank you for that. Ronan, if you have a follow-up question, just go ahead and post that as well. We have another question from Andy: What OPC UA stack/language did you use for the collectors?
Chris Churilo 00:49:48.585 Andy, hopefully, that answers your question. Just feel free to put in a follow-up question. So my question to you, Frederik, is how did A&S Energie come to the conclusion that they needed a change? What got them interested?
Frederik Van Leeckwyck 00:50:06.462 Yeah, that’s a bit of a background story there. So what they are doing is they are building a new plant, a second A&S, called A&U. And the management of the current plant, they knew that they were not going to have—they knew that they were going to spend their time as efficiently as possible. So they realized, the way we’re working now, this can’t be done anymore. So that was their reason to look for a change. And in our initial meetings with them, yeah, I think things were just, let’s say, pretty standard. But as soon as we showed Factry Historian running at one of our clients, they were really amazed. And I believe that really kickstarted the further conversation. And we also visited one of our other clients together with A&S management and it was also fantastic to see that. As soon as they saw what was possible, they were immediately very enthusiastic.
Chris Churilo 00:51:26.559 Excellent.
Frederik Van Leeckwyck 00:51:27.472 And a good answer to your question?
Chris Churilo 00:51:29.003 Yeah, no, that was really good. I mean, I just was wondering because when you say Windows—when I saw that screenshot of Windows 2000, it—sometimes when things are just working, people don’t want to make a change.
Frederik Van Leeckwyck 00:51:42.681 Sure. Yeah. Yeah, yeah, yeah. Indeed. That’s a whole debate in itself, I believe [laughter].
Chris Churilo 00:51:52.848 Excellent. So we’ll keep the lines open for just a few more minutes because we’re almost at the top of the hour. If you do have any other questions, feel free to raise your hand at this point if you rather start a conversation or post your questions in the Q&A or the chat panel. And as we’re waiting for questions to come in, I just want to remind everybody, this session is being recorded, so after I do a quick edit, I will post it so you can take another listen to it. We will also turn this into a paper so that if you want to share this with any of your colleagues, especially some of this background information. I think that would be probably quite useful to a number of people. And so, Frederik, this is just one example of a customer. I understand that you’re also working with other customers that are in—they have an industrial IoT need but they’re—it’s not just energy but also food production. I think you have a couple other clients in some other—
Frederik Van Leeckwyck 00:52:55.850 Yeah, yeah, yeah, for sure. And we see that, as mentioned in the beginning, it more or less boils down to either the process industry, which would be chemistry, food production, these kind of things. Or energy production, such as this biomass plant. So things that are running continuously where it makes sense to gather time series data while in manufacturing, of course, you also have discreet manufacturing with work stations. There, I believe, the use case is also there but we found so far that the continuous processing is more clear. They see the value more quickly.
Chris Churilo 00:53:40.941 Excellent. Any last words of advice for any of our listeners today, how to approach using InfluxDB from any of their solutions?
Frederik Van Leeckwyck 00:53:52.218 How do you mean, Chris [laughter]?
Chris Churilo 00:53:54.085 It’s so easy to just use. But sometimes I feel like it does warrant thinking a little bit about the data that you want to collect. Just from your experience, just for the audience as we just close up this webinar.
Frederik Van Leeckwyck 00:54:12.095 Sure. Sure. I think, so you have very good documentation with good ways of advising how to best structure the data, how to organize it, what to store in fields, what to store in tags. And what we’re doing goes a little bit against what you’re advising, but that’s not necessarily bad. It’s just a different use case. And that would also be my advice. Make sure that you know the product from a technical point of view. Make sure that you know it rather well before you start making choices on how you’re going to use the technology. That would be my advice, Chris.
Chris Churilo 00:54:54.521 Excellent [laughter], cool. Well, we don’t have any questions—anymore questions now, but, as always, questions usually come back towards me. So if anybody has a question that they would like me to pass along to Frederik or his team, you guys have my email address with the webinar invite, so feel free to just forward that to me. Or send that to me and I’ll forward it off to the team to get that answered. As mentioned earlier, this is being recorded, so once I do an edit, I will post it so you can take another listen to it. And if you would like to actually be a presenter in any of these webinars yourself just let me know and I’ll be happy to accommodate. Frederik, this was fantastic. I really appreciate all the effort you put behind pulling together a really fantastic presentation and webinar for our guests today.
Frederik Van Leeckwyck 00:55:42.696 Thank you.
Chris Churilo 00:55:43.637 And hopefully it’ll serve as really great inspiration for everybody.
Frederik Van Leeckwyck 00:55:47.523 I hope so too. Thanks a lot for the opportunity, Chris.
Chris Churilo 00:55:50.504 Thank you. And we will see you guys again next time. Thanks, everybody.
Frederik Van Leeckwyck 00:55:55.599 Okay. Thanks. Bye-bye.
Chris Churilo 00:55:57.276 Bye-bye.
Track and graph your Aerospike node statistics as well as statistics for all of the configured namespaces.
Knowing how well your webserver is handling your traffic helps you build great experiences for your users. Collect server statistics to maintain exceptional performance.
Collect and graph performance metrics from the MON and OSD nodes in a Ceph storage cluster.
Use the Dovecot stats protocol to collect and graph metrics on configured domains.
Easily monitor and track key web server performance metrics from any running HAProxy instance.
Gather metrics about the running Kubernetes pods and containers for a single host.
Collect and act on a set of Mesos statistics and metrics that enable you to monitor resource usage and detect abnormal situations early.
Gather and graph metrics from this simple and lightweight messaging protocol ideal for IoT devices.
Gather phusion passenger stats to securely operate web apps, microservices & APIs with outstanding reliability, performance and control.
The Prometheus plugin gathers metrics from any webpage exposing metrics with Prometheus format.
Monitor the status of the puppet server – the success or failure of actual puppet runs on the end nodes themselves.