Optimization of Wind Turbine Operations Using Multiple Factry OPC-UA Collectors
Session date: Jan 22, 2019 08:00am (Pacific Time)
Optimizing electricity output from wind turbines requires constant adaptation to the environmental conditions, while staying within the legislative boundaries. Specifically, wind turbine operators such as Vleemo have to respect shadow flicker and ice formation limitations but still keep their turbines running as much as possible within these boundaries.
In the past, turbines were primarily monitored using remote-controlled SCADA systems. Now, all sensor information from the Vleemo turbines is gathered in InfluxDB using multiple Factry OPC-UA collectors. We then augment this information with external data such as weather forecasts.
The turbine statuses are interpreted on the fly, based on the raw data in InfluxDB. Relevant information is subsequently displayed centrally in Grafana, so Vleemo can take immediate action when necessary. In the end, this allows them to become more productive and save time in their day to day operations.
Watch the Webinar
Watch the webinar “Optimization of Wind Turbine Operations Using Multiple Factry OPC-UA Collectors” by filling out the form and clicking on the download button on the right. This will open the recording.
[et_pb_toggle _builder_version=”3.17.6” title=”Transcript” title_font_size=”26” border_width_all=”0px” border_width_bottom=”1px” module_class=”transcript-toggle” closed_toggle_background_color=”rgba(255,255,255,0)”]
Here is an unedited transcript of the webinar “Optimization of Wind Turbine Operations Using Multiple Factry OPC-UA Collectors”. 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.
Speakers:
- Chris Churilo: Director Product Marketing, InfluxData
- Frederik Van Leeckwyck: Business Development and Marketing Manager, Factry
Frederik Van Leeckwyck: 00:00:00.973 Also, hello to everyone. Good morning, good afternoon, and good evening to all of you joining. During this one hour session, I will be talking about the optimization of wind farm operations with Factry Historian, which is based on InfluxDB for storage and our own OPC-UA collectors. I wish to thank InfluxData for making this webinar possible, and I’d also like to thank Vleemo for giving us the permission to share their story with all of you. Also, I would like to thank Vleemo for this lovely picture you see here on the first slide, a picture showing the port of Antwerp and the very wind turbines we will be talking about today. So speaking to you today is Frederik Van Leeckwyck. I am a bioscience engineer and on the right you can see how I look like. I’m responsible for business development at Factry and I was there from the beginning as I co-founded the company together with my colleague Jeroen. For Vleemo in particular, I was the project leader in the beginning. The last couple of months, a colleague of mine has been taking over the project but I was involved from the very beginning so I hope to be able to give you a complete picture of what we’ve achieved together with them. And I consider myself very lucky to be able to express my love for technology and I’ve also have been able to make my hobby my job. So the agenda for today’s webinar. So during this session, we’ll take you to four points, four topics, an introduction about Factry as a company and Vleemo as a company. Also, what their challenges. Then we’ll have a very small bit about industrial IoT, what it is, and then nuancing what the things are in industrial IoT. Then thirdly, and this is the bulk of the webinar, we’ll be talking about Factry, what we did with InfluxDB at our plant. Vleemo will share with you how they used to run their operations.
Frederik Van Leeckwyck: 00:02:21.771 We’ll start with the basics and then go through several iterations where we add additional data and create additional value with that data that’s being added. And in the end, we’ll finish with a small recap and some takeaways. And for those of you who are not able to attend the complete webinar, let me give you a hint of some of the takeaways already right now. So Vleemo has been able to improve their operations just by providing a single source or by having a single source of information on all data that’s relevant for their turbine operations. So we’ve seen that by collecting data from different sources, presenting it, interpreting it, and presenting it visually, that they are able to work with data very quickly, very iteratively, and it’s become a go-to tool for them. Secondly, we’ll show you that by interpreting the gathered time series data, that we were able to do more detailed reporting and give them clear insights in where additional optimization potential is for operating their wind turbines. And lastly, just by doing this work, we’ve been able to show you that this technology stack is definitely fit for purpose. So let’s start with the introduction about Factry and Vleemo.
Frederik Van Leeckwyck: 00:03:59.686 So Factry was founded two and a half years ago with a clear mission to enable data-driven operational improvements, and we were founded by people who had experience at Siemens, more or less in the world of industrial IT. But after some time, we decided or we felt that we can do this - we can work better in the world of industrial IT. We can do it better with open or open source technologies. So that’s why my colleague Jeroen has in 2016, you can see the link down below, has written a blog about building open source process historian, and this has been the beginning of our activities. And throughout these years, we’ve been implementing that technology stack across various, both manufacturing companies and renewable energy operators and suppliers. And this is a slide that’s coming from our initial slide deck, our very first slide deck where we already made the realization that to do a proper job in enabling data-driven optimization, we need two types of data. We need time-based data and relational data. And on the left column you see time-based data being gathered in InfluxDB, which has, of course, their old logo, just to show you that already back then we were using OPC-UA as a protocol to gather data from industrial systems into a time series database, in this case, InfluxDB, and then use that data if relevant to link it with other systems within IT for reporting purposes mostly, then relational data. But today will be mostly about time based data. So Factry Historian is the first product we built two and a half years ago then, being used as mentioned in the manufacturing sector or renewable energy for giving everyone real-time and historical insights. And two of the components that we used there are Grafana and InfluxDB, and Factry as a company adds to that its own software and the service that comes with it.
Frederik Van Leeckwyck: 00:06:18.347 We are based in Ghent. It’s a lovely city. This is how it looks like. So if you’re ever around, we’d love to show you around. Then about Vleemo. So Vleemo is a wind turbine operator, which means that they are responsible for making sure that the turbines are running and they are supposed to be running. So the turbines they operate, they generate power for about 58,000 households and right now, they operate 30 wind turbines across 6 wind farms, and this is expanding in the coming months and years. So so far, they have max power of about 80 megawatts. And what’s peculiar here is they operate in the port of Antwerp. And to give you an idea, you’ve also already seen it in that first picture, the port of Antwerp. This is how it looks like. This is Europe’s second biggest port. And if you look closely, you can see on the top right and the top left, you can see some wind turbines and they are scattered throughout the port of Antwerp. So what’s peculiar here is that they are not standing in fields or in agriculture, no. They are really in a very, very busy port, scattered throughout in the industry and office buildings. So that implies that they need to operate their turbines taking into account, yeah, this port’s environment, right? So the challenge for that company is of course to generate as much electricity as possible, given variable weather conditions. Of course, they can only generate electricity when there is wind, but also they need to stay within the regulatory boundaries. And for this webinar, we’ll be talking about two regulatory boundaries that are relevant here.
Frederik Van Leeckwyck: 00:08:28.359 So the first regulatory boundary is kind of like a nuisance, right? It’s called Shadow Flicker. And for those of you who are not familiar with that, so Shadow Flicker, you get Shadow Flicker when there is direct sunlight and a wind turbine in between a house for example or an office building, and the sun. So you have this casting of shadows mainly because of the blades, and so the effect you get when you’re inside that building is you get, yeah, Shadow Flicker. So constant on and off, on and off of shadow. And to stop people from going mad, there’s some regulatory boundaries there. So in essence, it boils down to, at least in Belgium, maximum 30 minutes of Shadow Flicker exposure per day per object, let’s just summarize this as a house or an office, and also a limitation of maximum eight hours per year. So you can already see that there is the possibility for an optimization there because this limitation puts you in a position that you’d rather maximize those 30 minutes per day in moments when there’s lots of things in order to end with your eight hours maximum per year. So that’s a first regulatory boundary. And second regulatory boundary is safety. So like today, it’s snowing in Belgium for the first time this year and temperatures are below zero degree centigrade, which are conditions where ice can be formed on the turbine blades. And as soon as ice is being formed on those blades, you need to stop the turbine of course, from purely a safety point of view, because we don’t want big chunks of ice being hurled around and damaging buildings, or worse, hit people. So you stop the turbine when ice is formed, and within the turbines, you have blade heating systems that are of course used to melt the ice from the blades so that when the ice is gone you can restart the turbine. But special thing is here that you can only restart it after visual inspection by a mobile dispatch team. So this means that when it starts freezing at night, you can only restart the turbine in the morning for example, when you are able to do that visual inspection. Also, because the turbines are scattered throughout the port of Antwerp, you need to go and visit more or less each individual turbine and do a visual inspection and give the green light to start it up again and only then can you start the turbine.
Frederik Van Leeckwyck: 00:11:25.663 So those are the two regulatory boundaries in scope of this webinar. So small part about Industrial IoT then. IoT, Internet of Things. I believe we all noticed, we know these consumer devices that we probably all have, smart speakers, smart thermostats such as the one on the left, data which is also using InfluxDB’s technology. But these are consumer devices, right? And in the industrial IoT, we’re talking about other devices, much larger and totally different scales. So this is some pictures that I took when Vleemo was giving an exhibition where you could visit new turbines being constructed, and this is the scale of the equipment that we are talking about today. So to nuance these things in the industrial Internet of Things, and on the table on the right, you’re talking about industrial equipment with a useful life of decades rather than years, with investments going to several million euros rather than hundreds of euros for consumers, and the scale at which data is being generated can be either distributed, which is the case here, or confined in the case of, for example, a biomass plant or a manufacturing plant. So that’s small nuance. And now let’s dive into the bulk of this webinar. So I’m going to take you to a couple of points that you can see on the right. So we’ll start with how Vleemo was doing their operations, at least from a digital point of view, before Factry came into the picture. Then I’ll explain to you very high level, the modular setup of Factry Historian and where InfluxDB fits into that picture. And then we’ll start with the basics of data collection, adding additional sensor data, adding weather forecasts, adding status interpretation, adding a Shadow Flicker calendar, and then fitting all these pieces together to allow for optimization of the operations. And in the end, we’ll also have a small part about monitoring this complete stack.
Frederik Van Leeckwyck: 00:13:41.565 So before Factry, Vleemo was looking at the status of their wind farms or their wind turbines in the wind farms by having a look on this data system that is controlling each individual turbine, and they were doing so with a remote desktop connection. So you have to imagine having the port of Antwerp, you have these six different wind farms. Each wind farm has its data system. So they were using remote desktop connection to log into each individual data system, see how or what the turbine status is, and then make some decisions based on that. There was also no, or rather limited data collection. There was an historian system present on some of these systems but it was not really utilized, definitely either not used or underutilized. So in the end, it boiled down that they had limited opportunities for data-driven optimization and a lot of it was done based on experience, which they most definitely have, right? So again to reiterate, their challenge is to generate as much electricity as possible given these variable weather conditions, while staying within the regulatory boundaries as I have shared with you before. So now, a bit about Factry Historian, the modular architecture about it. So on the bottom half, on the bottom you see local network on the left. So you see three sites, which could be wind farms in this case, where typically via the OPC-UA protocol, they’ll be collecting data from the industrial control systems, in this case the SCADA. So here we have three sites. In reality for Vleemo, those are six sites. All data is being sent through our own runtime API which does validation of the data, which checks whether the data is coming in and which gives the user a user interface to control which data should be collected from the industrial control systems. Then the data is being put into different groups which are represented by different databases in InfluxDB, and finally this can be used for dashboarding and analysis.
Frederik Van Leeckwyck: 00:16:01.324 And the top part is mostly situated in the corporate or business network if we’re talking about on-premise installations or the cloud, however you want to name it, in other cases such as the case here for Vleemo. So these collectors, this software that we build ourselves, they are used as input for InfluxDB. They talk in industrial protocol on one end, for example OPC-UA, and HTTP on the other, and they are built according to a store and for-work model. So which means that if there’s no connection to the storage backend, they keep a local buffer of the data that’s being gathered, and as soon as the connection is back up, the data is being forwarded. And they also keep a local copy of the configuration to enable the startup of these collectors in those rare cases where this connection would not be available, so that these collectors can at least do their job. So collector setup, typically what you see is that you have a production network close to the equipment. For example, each individual wind farm has a small network and there you’d run these collectors that are responsible, they’re quite close to the data source, and then the data is being sent through the business network or through the internet. And to make this possible and to make this easy to configure, we only allow outgoing connections from the production network to the business network so that you don’t need to open any ports or any network connections from the internet for example to watch that network. It’s only outgoing connections or at least the connections are open from the production network to the business network. So if you want to add collectors, these collectors responsible for collecting data from these industrial control systems, though in this case we started with six collectors. So for each, we created that collector and gave it a name and a type. We generate one token for this new collector which is used for authorization on the one hand and for finding out the location of the API, the backend API on the other hand. And then you can just start the collector as a service and the only environment variable or the only configuration that you need to pass is this JWT token. So mostly these collectors are single binary deployments, which makes it easy to update them as well, and as soon as they have started they connect to the API, validate themselves, and then you can start configuring them in the operator interface.
Frederik Van Leeckwyck: 00:18:39.860 So this is a bit how it looks like. You have the graphical administration panels where you can add collectors. Here we have now added for demonstration purposes three OPC-UA collectors with names and end points, username, passwords, etc. And you can see that all three of them are active, which means that they are valid and have been able to connect to the OPC-UA server. Once the collectors are being - once the collectors are added, you can add metrics to them, often called tags in the industry and in the OPC-UA protocol which we used a lot here. Those can be either told or monitored. And configuring metrics looks a bit like this; so you have your different groups, wind park number two for example, and there you can add one or more data points you wish to collect. So in this case, we’re gathering a couple of hundreds of data points for these 30 turbines, so close to 600 data points for all data from these 30 turbines, which is basic data but also additional data from Meteo systems and additional sensors. We’ll go through that, and next to that we also add more data that’s being calculated on the fly. That will be discussed in point F. So let’s start with the basics of data collection. Now that you know how this architecture looks like with the collectors backend API and storage in InfluxDB. So the basic data you can collect from turbines are how much energy is being produced, what is the wind speed, what is the wind direction, what is the position of the nacelle, so the part on top that directs itself into the wind direction, and the status codes of turbines. So this more or less basic data sets is what you started with in the beginning, so for all these turbines. So graphically this looks a bit like this. So you have in this case again three, but in reality six wind farms being controlled, each of them being controlled through a SCADA system and the industrial control system. With the OPC-UA protocol, we gather data in our collectors which are then responsible for sending that into the cloud via runtime, which is finally sent to InfluxDB for long-term storage, which can then be used for visualization, but you also see one arrow going back and we’ll explain to you what that means in this case.
Frederik Van Leeckwyck: 00:21:22.067 So this is the initial use case. Those of you who have worked with Grafana already can see or will recognize this type of data. So you see here the position of the nacelle. You can see here the amount of energy that’s being generated, wind speed, wind direction, so basic data. And on the top left you can see they can select which park, which turbine, in order to see the right data. So this is just basic data collection being done, already giving them historical insights into what’s happening in the course of their weeks, months, and years. But taking that to a more high level, you can see here the status dashboard that gave them a quick overview of how all their different turbines are running. So I don’t have to explain to you that the green box probably means that everything’s okay and an orange one for example, DDZ03, means this turbine is in maintenance. So this one it’s definitely not running but we know it’s not running. Therefore we put it in orange. So this is kind of like status dashboards built in Grafana, again with the same type of data, but already this gives them this central overview of their complete turbine operations. So the benefits they already received just from having data centrally available is that they have now this central overview that everyone in the company, everyone at Vleemo can use to have a quick overview of how everything was running. Remember before, they had to log in via remote desktop into each individual SCADA system per wind farm to have a look at how the turbines were doing. But now also of course because we archived this data, we now get a long-term insights into what’s the status of our assets over the long term so that they can increase or at least make possible their reporting functionality.
Frederik Van Leeckwyck: 00:23:30.306 What we’ve seen already in the bit over a year now that everything is running, we can see that or we’ve heard that this is now the go-to tool for new hires. So if new people enter that company, Grafana is the go-to tool for new hires so they can immediately see how the turbines are running. And also made possible thanks to, yeah, quite an expressive and open API is that Vleemo is now able to selectively share data with third parties such as research institutes, where they can very quickly add data that they wish to collect and then share this data with third parties to also optimize their operations. So what we’ve seen here is the basics. We’ve seen just simple data collection from the industrial control system, and now we’re going to add a few layers of additional value to that in order to really improve the operations. So the first or the second iteration that we did is adding additional sensor data. So for a few turbines, Vleemo has purchased external sensors that are stuck to the turbine blades. So there’s large stickers more or less and they are put on the turbine blades in various positions and they give fine-grained information on the blades’ temperature and thus, the potential ice formation that you could have. Now these are standalone systems that also transmit their data to the supplier of those sensors. So we contacted that supplier and they had the possibility to open up that data via REST API. So we created that data and added to the database in a structure that is in line with the addition to the basic data that we were already collecting. So what you see here is we now add this part on top, additional sensors also being added, a new data source being added, and then stored into InfluxDB. So this is a bit how that dashboard looks like. Then you can see many different sensors, and this is just for one turbine.
Frederik Van Leeckwyck: 00:25:49.297 So a lot of sensors but giving them much more fine-grained information into what the temperature is in the turbine blade and whether or not ice is being detected, and also the [inaudible] we have there. In another screenshot, you could see that as soon as they turn on, of course, the blade heating, that the temperatures are rising, which is of course what they want to see. And probably what you can see here, this peak, is definitely a moment where after going below zero degree centigrade, they started heating up the blades in order to start the turbine operations. So the benefits they got from that is they now have more detailed information to either operate or stop the turbine running during winter conditions, and so they are now able - they are gathering more fine-grained data and seeing whether or not it’s - whether or not they should operate or stop the turbine. And they’re also able to validate whether that additional sensor system makes sense in that specific case. If so, they can roll it out to more turbines. The third iteration is adding weather forecast data to that. So of course you can imagine the weather is changing all the time so knowing what’s coming via the weather forecast is really relevant for Vleemo. And they can of course watch the news or subscribe to a weather forecast service but it’s really easy if you can just create your REST API and add that to the database as well. So we query it. We add it to this initial data source, query that regularly, add it to the database, and write that to InfluxDB with future timestamps. Now we have that. So what does it look like? Now we add this weather data to it and also store that in the same data structure. So what you get then is this simple dashboard, again, control or centralization of all the data. And on the right there you see - I believe this is the most relevant for this particular case. So again, they can now start looking into the future with the same system, whether or not it’s going to be freezing and whether or not they can expect the turbines to be not operational.
Frederik Van Leeckwyck: 00:28:15.765 Now as I have mentioned in the beginning, when there’s ice formation and you heat the blades, you can only restart the turbine after visual inspection of the turbines. Now the turbines are scattered throughout the port of Antwerp so this means that from the moment you are permitted to restart them again, you should be able to do so as quickly as possible. So you need a dispatching team that is able to release each individual turbine as quickly as possible. So the sooner you know that you’re going to have winter conditions, the better you can plan a dispatching team that’s available on the ground to release, to give the okay restart the turbine when the temperatures are again above zero. So that’s a very clear benefit for them. Now they never forget whether or not they can - now they never forget what the weather will be. The data is centrally available in InfluxDB and in Grafana. On this dashboard we see here, there’s some alerts, that alert for minimum temperatures in the next couple of days so that they are always aware and can better plan the dispatching team.
Frederik Van Leeckwyck: 00:29:29.266 Point F, adding additional status interpretation. And this has been, let’s say a very big addition to the data that was already being collected. And this is something that’s constantly ongoing. So we started with the initial manual status interpretation based on the data that’s being collected already last year, and there are still improving, still optimizing this. Now what are we talking about here? So I mentioned in the beginning that one of the parts of the basic data collection is turbine status. The turbine manufacturer has a list of status codes that of course describe the status of the turbine. Now in some cases, this information is a bit too high level. But based on all the data we have available, we can interpret this turbine status in more detail than the turbine manufacturer does. So we’ve written and developed together with Vleemo a custom algorithm to outperform the turbine status classification by the turbine manufacturer. To do so, we’ve written a custom daemon in Go to constantly read and write to InfluxDB and this custom daemon is constantly being improved over time. And it’s built with replay functionality in mind so that every time we have new insights into how to improve this classification, you can replay this daemon more or less like a tape. For example, replay the whole December 2018 where the status is being interpreted more fine-grained, and this in the end gives them clearer and finer insights into optimization potential. So we have now discussed an algorithm that’s getting data from InfluxDB and writing it back. The type of data we’re talking about here is for example, look at the status. Look at the value of this specific measurement in Influx and then see if two minutes before, this specific measurement also had this value. So it’s becoming very quickly rather complex, and it’s of course based on their experience. But once this is all there, they can do this very fine-grained interpretation of the status of these different turbines. And the end result is this. You recognize this dashboard with all the green blocks? So each block representing one turbine but now, they get into much more detailed status codes. You can see of course the red blocks with ICE means of course the turbine is stopped but it can be reset, so it should be able - they should be able to restart the turbine. And this is an interpretation of the turbine status which has more details than what the turbine manufacturer itself is able to supply.
Frederik Van Leeckwyck: 00:32:40.006 So again, this big overview gives them insights into where is the optimization potential, should this turbine be running, and why is it not running? And give the people that are working at Vleemo the possibility to act very quickly. So the benefits there is that we improved this Grafana overview so they now have very fine-grained information for everyone that’s responsible for managing the operations so that they can take more appropriate action. They definitely save time for dispatching. Rather than getting a turbine status code from the manufacturer, now they have a human readable turbine status which is also more detailed, so this allows them to very quickly make the right decisions in order to, for example, stop or start the turbine. And in the end, because of this replay functionality, they can increase their reporting on lost revenue. And what is lost revenue? Lost revenue is defined as the energy that you missed by a turbine that is not running that could have been running. Because the wind was blowing, it could have been running but it was not running. Why was it not running and can we make sure that we don’t encounter that situation anymore or that we can limit the time that situation happens? And to do so, we need these detailed insights into why the status is either running - this turbine is either running on not running.
Frederik Van Leeckwyck: 00:34:12.587 Then point G, Shadow Flicker calendar. Also a very nice addition by the people from Vleemo. And this has to do with the Shadow Flicker limitation that I’ve mentioned in the beginning. So they of course know where all the turbines are located in the port of Antwerp and they have dedicated geospatial information systems, software to determine the potential Shadow Flicker on windows of, for example, offices in the port. So of course they know the state - we know the state - we know the position of the sun and we know the possibility of Shadow Flicker being cast on the offices in - on the windows of the offices in the port. But of course, you only know the potential. You don’t really know whether or not it will happen already because of course, you also need direct sunlight. So they exported this data and Vleemo was able to upload that data themselves into InfluxDB and just add an extra or a new data source. So this is being added directly to InfluxDB, because this is not changing all that much. It’s a fixed calendar more or less. They know which windows there are. They know the office buildings in relation - the location of the office buildings in relation to the turbine. They can add it to the database as well. And if you would look at that information in Grafana, this more or less looks like this. So on top, you have these specs in the spec graph and each block represents a window, a receptor that could be susceptible to Shadow Flicker. And of course it is only susceptible when there is direct sunlight. And you can see in the bottom row between 0 and 1, whether or not at that point in time there was direct sunlight or there was no direct sunlight and the combination of both too. There’s the possibility to have Shadow Flicker and secondly, there was direct sunlight so you have Shadow Flicker. This combination is present only when these two parameters are - these two values are high. Only then the turbine should be stopped, of course taking into account this limitation of 30 minutes per day or eight hours per year.
Frederik Van Leeckwyck: 00:36:40.995 So we now get in Grafana again, centrally available, all the data about when a turbine could be stopped, to show that they are in line with this regulatory boundary. And as I’ve mentioned to you, it shouldn’t really be stopped when it’s clouded, so there’s potential for Shadow Flicker but it’s clouded so it’s not really the case. And to go a little bit deeper even, so what if the window owner for example, the owner of that office building in the port of Antwerp says, “Yeah. Today I can tolerate this Shadow Flicker because, for example, today we’re not in the office. It’s team building. We’re not in the office and so now you can override this calendar.” So what if they tolerate it? There’s optimization potential there. But then to do so, you need to put more pieces together. And this is now found in part H. I’m going to explain to you how we see the - how we start seeing these different pieces of data being fit together. Because what we now have available in InfluxDB is the Shadow Flicker potential, real time and forecasted information about direct sunlight, and then for example, that’s not the case yet but it’s a possibility to have, for example, the window owner, the office for example, sending us a message saying, “Today, we will not be in the office so you don’t have to respect the limitation. We won’t be bothered.” So this could be used to control turbine behavior based on more information than you normally have available in an industrial control system. So is there Shadow Flicker potential, yes or no? Is there direct sunlight, yes or no? Has the window owner not given permission then to override? Then you need to stop the turbine. So definitely, if you start putting these pieces together, at least the last one or any other additional decision criteria, you can see that this data is only available or would only be available in InfluxDB. So a very nice thing to have would be an OPC-UA server that is exposing a calculated value based on, for example, these three criteria and exposing that back to the automation, back to the industrial control system. And that’s exactly what we’re currently doing. So we have written an open source OPC-UA server. We’ve written an OPC-UA server that is able to take one or more measurements that are available in the database, expose them over OPC-UA, and then the industrial control systems can subscribe to that data point and potentially overwrite a decision they would have normally made purely in the industrial control system.
Frederik Van Leeckwyck: 00:39:53.961 So we get now the possibility to flow data back to the turbines. So the core functionality of this OPC-UA server, we will be releasing open source anytime soon, normally still this week. So this will be a simple server for exposing data from InfluxDB over OPC-UA. Most of the time, the basic use case we see will be exposing the lost value of a certain measurement in InfluxDB, but we will be adding more additional functionality to that as well. So if you’re interested in that, please have a look at that URL. And then lastly wrapping everything up, of course we’ve seen this modular setup. We’ve seen many different collectors in each individual wind farm. We’ve seen additional collectors to collect data from these extra sensors, from weather forecasts, from custom interpretations. We have quite a lot of data flowing in already from different sources and you need to monitor this whole system. And if there’s one thing that InfluxDB and their ecosystem of tools is really good at, it’s monitoring these kind of setups. So we use that same technology stack to monitor the whole Factry Historian cloud setup, and we use it in the way that if no new data comes in for 30 seconds, we get alerted immediately. And this together allows us to offer to the market kind of like historian-as-a-service, make sure that everything’s always running smoothly. So we eat our own dog food’, right?
Frederik Van Leeckwyck: 00:41:38.949 So wrapping everything up, what’s net business value, and again, the key takeaways. So quantifiably for Vleemo, Vleemo is now able to quantify the amount and the source of lost revenue, because they have very clear insights into when is a turbine not running when it should have been running, right? So that is lost revenue. They can very easily quantify it and make the necessary changes in their operations to decrease that lost revenue. Secondly, because of this customer status interpretation that goes much further than what the turbine manufacturer is doing themselves and giving a human readable interpretation of the status of that turbine, they constantly save time for ad hoc root cause analysis by, for example, a dispatching team in the port. Qualitatively, you can see that they can provide signal to the different companies, the other companies in the port that are there constantly monitoring their turbine equipment, and are able to intervene very quickly and give that signal that they are able to intervene very quickly to other companies in the ports. And we’ve seen that because the data is so centrally available, interpreted with a custom algorithm that it becomes a daily tool for them, it’s really very fluent, very open, and they can work with this day-in day-out. So I hope with this high level information, with this setup, that I’ve been able to show you that by gathering all this data centrally in InfluxDB from all these different sources and adding customer interpretation on that, that they are able to perform operational improvements and that they are able to work with the data to see where the improvement possibilities are and act on that, and because of this interpretation of time series data, they can now report, see where the optimization potential lies, so that they can do data-driven optimization. And we’ve seen it already many times before, the technology stack that we’re using here is completely based on open or open source technology, so it’s a technology stack that is definitely fit for purpose. We’ve been running this system for a bit over a year now and this is running really smoothly.
Frederik Van Leeckwyck: 00:44:03.784 So if I can invite you for a couple of next steps. The 12th of March 2019, we’ll be holding our next Time Series Belgium meetup so if you are ever around you’re very welcome to join. And we’ll also be present at the Hannover Messe, a large industrial automation and industrial IT fair in Germany between the 1st and the 5th of April, and we will be presenting this case in much more detail. And lastly, if you’d like to be informed about our open source OPC-UA server, exposing data from Influx, you can also find the link there. So hereby, I would like to end my talk, pass the word back to Chris, and I look forward to your potential questions.
Chris Churilo: 00:44:53.463 So it’s pretty exciting that you guys were able to create that OPC-UA server, so that really makes this whole solution come full circle. I mean, collecting the data, being able to analyze it, making sure the neighbors are happy, making sure you’re working optimally, and then sending that information back to the devices themselves in order to further control the environment. So that’s really cool, Frederik. You have a question from Tom. And Tom asked, “Do you have any other application areas today for your product?”
Frederik Van Leeckwyck: 00:45:27.046 Yeah, for sure. This similar setup is running in food manufacturing plants all over the world. It’s running in biomass centrals. Yeah. Many different kind of processing applications. Yeah. And you can see that the use cases, the clients, they fall in two main categories: on the one hand, manufacturing, typically the processing industry and in a lot of cases even food companies, and on the other hand more the renewable energy world such as wind turbines and hydropower plants, biomass plants, etc. So those are two main areas of application.
Chris Churilo: 00:46:20.812 And we’ve actually shared the case study for A&S Energie, so that is posted to the website. You can do a search on that and listen to the webinar, as well as read the papers, so those things are available to you. We still have a few minutes so we’re going to leave the lines open. If you have questions please put them in the Q & A or the chat. And we have another question that just came in on the Q & A. And [inaudible] asked, “What about the UI? Are you going to replace Grafana on the custom UI or keep it as-is?
Frederik Van Leeckwyck: 00:46:54.422 Our stance is that it doesn’t make sense, at least from Factry’s point of view, to compete with such a very easy to use user interface. So we’re not going to go in that direction. However, it’s on our roadmap to have basic trending functionality in the administration interface so that if you’re browsing specific tags from an OPC-UA server that you wish to potentially plot, that you can very quickly see whether or not you’ve selected the right tag, for example the temperature, before finally adding it to the historian and starting the data collection. But that’s more like an administration feature rather than a user feature. For user features, we would for example use Grafana or see how InfluxData’s solution fits the picture there.
Frederik Van Leeckwyck: 00:47:56.317 And I think a lot of people agree if the product works and it’s continuously being updated by the community, why not keep using Grafana? It’s a great product. Let’s see. Tom asked, “What is your real USP relative to competition? Is the server unique?”
Frederik Van Leeckwyck: 00:48:16.630 OPC-UA servers exist since many years already so that in itself was not a big differentiator. However, it’s only now that you can see these types of protocols being implemented in a more open way, an open source way, which makes them available for much more typically also smaller companies that in the past didn’t really have that functionality available. So we hope by open-sourcing this type of functionality or software that companies are able to start with this more advanced, if I may call it like that, way of working, that it becomes more accessible to them. To give you an example, again, two and a half years ago, we open sourced our initial OPC-UA collector, which is able to collect data from industrial systems and store it in InfluxDB. So that’s, let’s say, the classical use case or the classical functionality of a historian. We know that this piece of software is running all across the world in manufacturing plants, renewable energy. Just last week, we were talking with a Norwegian company that does mountain drilling and they’ve been using that open source software package for over a year already, that’s at least how we understood it, this time frame of a year. And again, this functionality existed already but because it was open sourced and was available for more people, they were able to experiment with it and to our surprise it worked already for a long time for that company. So again, the functionality in itself is not really new but it opens up new possibilities because it’s more open.
Chris Churilo: 00:50:19.233 So Tom, just let us know if that answered your question. And I also want to reiterate what Frederik said a couple of times now; both the OPC collector and the OPC server are open source. So please take a look at that as well as the InfluxData TICK Stack, and hopefully you can find those to be quite useful for the solutions that you’re working on. We still have a few more minutes before we have to shut the lines down so we’ll leave them open for any of your questions. And then Tom, just let us know if we answered your question. Just give us a thumbs up or thumbs down so Frederik can actually dig into that a little bit deeper.
Frederik Van Leeckwyck: 00:51:00.467 Yes. [crosstalk].
Chris Churilo: 00:51:01.239 Okay. Here’s Tom’s follow up question, “Is your business model - what is your business mode? Are you a SaaS?”
Frederik Van Leeckwyck: 00:51:10.035 Partly. So to elaborate on the open source and business model. So this fits are our mission very well, so we try to make - we try to give these kinds of solutions, these technologies, we try to make sure that more and more people, more and more companies can use them. Now just by open sourcing this, we don’t earn any money, so there’s of course a business model behind that. Both for the server and for the collectors, we have also closed source versions, which are improved in terms of functionality, easier to administer, and more reliable buffering of the data. And next to that, we monitor and support that whole system. So in that sense, you could indeed say it’s a SaaS business. However if you’re talking about the industry, it’s not , for example, a CRM system that you can just start using online for a small business for example. There’s always, or in a lot of cases, there is some sort of implementation trajectory needed and that’s then more on a project basis. So yeah, it’s a bit shared. It’s a recurring or SaaS-based business model on the one hand for the software itself and the service that it supplies, but typically we also integrate that, and that’s more on a project basis.
Chris Churilo: 00:52:43.290 Excellent. And Tom said that you did answer his earlier question about the server. So we just have a couple of minutes left and we can definitely - sorry, let me just make sure again. Oh, this question’s answered. So if anybody has any other questions, please feel free to ask them. You can also raise your hand and we can have a conversation because we do have a few more minutes. But if for some reason after the webinar you realize, “Oh, I do have a couple of questions.” Feel free to just shoot me an email and I will forward them on to Frederik. That happens quite a bit sometimes. We just get inspired after we’ve thought about it a little bit more. And here, we’ll definitely be able to answer them very quickly. So Frederik, maybe just some final thoughts on some things that surprised you guys, some things that you expected when you were working on this project with Vleemo.
Frederik Van Leeckwyck: 00:53:40.264 Yeah. Well, looking back at it, what I mentioned in this webinar and what I called the basics, we knew that this was the type of data that they initially wished to collect. Also, this custom status interpretation was something that we foresaw in the beginning. Awe see that throughout everything we do, we have, let’s say, one or more initial use cases which we study together with them and then the tool becomes - yeah, people start using it more on a daily basis and of course they wish to extend that functionality. And what we’ve seen is if we think really well about the architecture in which we’re going to store the data, the how are we going to name the measurements, which tags are we going to use, the fields, etc., all this whole architecture, if I may call it like that, also for storing the data in the database and also how are we going to deploy collectors, etc., if we really think about it very well in the beginning, then the system is very easy to extend. So adding the weather data to it for example, adding this additional sensor. Right now, we’re thinking about adding more sensors to it. For example, if you want to do that, if you think really well about the architecture, then this system, this model or setup, this way of working with InfluxDB makes this very easily possible. So that’s definitely something that I would remark there. Is that a good answer to your question?
Chris Churilo: 00:55:23.903 I think that’s a great answer and I completely agree with you. It’s so easy to get started that sometimes we just kind of start throwing stuff in and then down the road we can’t remember what this measurement is or what that database is, because we didn’t sit down and kind of think about just the naming. Sometimes just the naming of things can make all the difference.
Frederik Van Leeckwyck: 00:55:46.822 Yes, indeed.
Chris Churilo: 00:55:47.840 Awesome. Well, thank you. As always, really well done, always very thorough. And I think I’ve learned a lot about shadows that I didn’t even understand and I love the way that you guys added that weather data in there. I thought that’s a pretty clever way of handling that. And as I mentioned earlier, this is being recorded so I’ll do a quick cleanup and we’ll post it later on today so you can take another listen to it. And if you have any other questions for Frederik, just shoot me an email and I’ll forward it to him, and I can even put you in contact with him if you just want to be able to have a conversation with him and the team at Factry. And Frederik, thank you so much. Wonderful job like always and I appreciate it and I’m sure audience does as well.
Frederik Van Leeckwyck: 00:56:34.110 Thank you.
Chris Churilo: 00:56:35.053 Thank you. Everyone, have a wonderful rest of your day. Bye bye.
[/et_pb_toggle]
