Implement Advanced Data Solutions in Manufacturing by Integrating Tulip with InfluxDB

Session date: Jul 23, 2024 08:00am (Pacific Time)

Join us for an engaging webinar as we explore integrating Tulip’s frontline operations platform with InfluxDB’s time series database capabilities. This session will provide a comprehensive overview of both platforms, highlighting how Tulip’s versatile app-building platform complements InfluxDB’s robust data handling for seamless operational workflows. We will discuss the strategic advantages of using these technologies in tandem, including streamlined data sharing and enhanced real-time analytics to drive operational improvements.

The session includes a live demo of setting up the InfluxDB connector with your Tulip apps, showing how simple it is to transfer and retrieve data to and from your frontline operations. We’ll also present a practical use case to highlight the tangible benefits and efficiencies this integration offers. Whether you are a seasoned developer or new to time series databases, this webinar will equip you with the knowledge and tools to effectively use Tulip and InfluxDB in your operations to drive business value and optimize data flows.

This session will dive into:

• Comprehensive overview of both Tulip and InfluxDB platforms
• Practical use case demonstrating real-world benefits and efficiency gains
• The integration of Tulip and InfluxDB + setting up the InfluxDB connector within Tulip
• Writing data to InfluxDB and querying it back into Tulip applications

Watch the Webinar

Watch the webinar “Implement Advanced Data Solutions in Manufacturing by Integrating Tulip with InfluxDB” by filling out the form and clicking on the Watch Webinar 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 “Implement Advanced Data Solutions in Manufacturing by Integrating Tulip with InfluxDB.” 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:

• Anais Dotis-Georgiou: Developer Advocate, InfluxData
• William VanBuskirk: Product Manager, Tulip

Anais Dotis-Georgiou:

So, I have given it a little while for everybody to join, so I’ll just go ahead and get started with some general housekeeping. The first and foremost is that there will be a recording available of this webinar at the end that will be mailed out to you, so you’ll have access to that and any of the, you know, slides that have any links. You also get access to all of those links as a result. So, yes, if you need to follow up on any of those resources, they will be made available to you shortly. Additionally, if you have any questions at all, I encourage you to ask them in the Q and A. We’d love to get to those questions at the end of the webinar, but also, if you don’t have the time or you remember a question after the webinar is over, I want to encourage you to visit both the InfluxData community and also go to the forums for Tulip as well at Tulip community, and ask any questions that you might have about either. We’re happy to ask your questions, answer your questions, and also just get any feedback you have about this webinar so we can make our future webinars even better.

So, with that being said, I’m going to go ahead and actually go ahead and get started. So, William, if you wouldn’t mind switching to the next slide. So, my name is Anais Dotis-Georgiou, and I’m a developer advocate at InfluxData. A developer advocate is someone who represents the company to the community and vice versa. And I do that through creating technical demos, through giving webinars like this, through answering questions on community forums, and then also bringing back any product feedback back to product when they have the capacity to change the roadmap to accommodate the feedback that I give. So, I encourage you to connect with me on LinkedIn if you want to. I also encourage you to check out the slack and influx community forums. I am on there quite frequently and happy to answer any questions that you have or just generally talk about anything related to time series data, InfluxDB, or machine learning. So please come at me. Next slide.

So, I have given it a little while for everybody to join, so I’ll just go ahead and get started with some general housekeeping. The first and foremost is that there will be a recording available of this webinar at the end that will be mailed out to you, so you’ll have access to that and any of the, you know, slides that have any links. You also get access to all of those links as a result. So, yes, if you need to follow up on any of those resources, they will be made available to you shortly. Additionally, if you have any questions at all, I encourage you to ask them in the Q and A. We’d love to get to those questions at the end of the webinar, but also, if you don’t have the time or you remember a question after the webinar is over, I want to encourage you to visit both the InfluxData community and also go to the forums for Tulip as well at Tulip community, and ask any questions that you might have about either. We’re happy to ask your questions, answer your questions, and also just get any feedback you have about this webinar so we can make our future webinars even better. So, with that being said, I’m going to go ahead and actually go ahead and get started. So, William, if you wouldn’t mind switching to the next slide.

So, my name is Anais Dotis-Georgiou, and I’m a developer advocate at InfluxData. A developer advocate is someone who represents the company to the community and vice versa. And I do that through creating technical demos, through giving webinars like this, through answering questions on community forums, and then also bringing back any product feedback back to product when they have the capacity to change the roadmap to accommodate the feedback that I give. So, I encourage you to connect with me on LinkedIn if you want to. I also encourage you to check out the slack and influx community forums. I am on there quite frequently and happy to answer any questions that you have or just generally talk about anything related to time series data, InfluxDB, or machine learning. So please come at me. Next slide.

William VanBuskirk:
Hey, everyone. My name is William VanBuskirk. I lead our alliances in the US for Tulip. Essentially, I’m really excited about working with people like Anais to really showcase the open ecosystem of Tulip. I’ve been until about a year prior to that, I was at a PwC, writing a lot of operations consulting. So, I really have been a manufacturer my whole life. Loved walking through, really, any factory, whether it’s making, you know, cars, medicine, rivets, you name it.

Anais Dotis-Georgiou:
Next slide. So, I’m a developer advocate for InfluxData, and InfluxData is the creator of InfluxDB. And InfluxDB is a time series database. So, it’s just a database that’s optimized for any data that has a timestamp associated with it. So that means any data that has sensor data, so that can be pressure data, temperature data, humidity data, concentration, flow rate, etcetera. And all of these types of data make it a great use case for industrial IoT. So, I just wanted to highlight really quickly why InfluxDB is a good choice for industrial IoT time series data. The first is that its purpose built to handle time series data. It’s built on an open data architecture that leverages the Apache ecosystem under the hood, things like data fusion, Apache, Parquet, etcetera. And so you’re able to really leverage all of the compression capabilities that those offer as well as being able to natively query in SQL. So that kind of makes a just querying a lot simpler.

But additionally, you know, another thing is that it allows you and helps you to optimize equipment effectiveness and production process by monitoring things like pressure, temperature, humidity, etcetera, and various performance and production metrics. It also enables you to do things like do predictive maintenance and, you know, be able to tell when a particular machine will experience downtime or requires maintenance so that you can both limit the downtime and also, you know, help minimize costs as well. And while you can’t do predictive maintenance directly with InfluxDB, we offer a bunch of tools that enable you to very easily integrate with other tooling that specializes in predictive maintenance, things like forecasting and anomaly detections that you can handle those type of things.

And then we’re also trusted by a lot of customers across the industrial IoT space. We have things like Honeywell, Heineken, BTC, and I’ll go over some other customers in detail in a second. And Bboxx, actually, Bboxx is one of my favorite customer case stories because they’re providing affordable, clean energy solutions in developing countries and they’re using InfluxDB to monitor all of their solar panels. Next slide.

I did want to take a moment to talk about some industrial IT partnerships and integrations. So on the application side, we have Grafana, for example, which allows you to visualize all of your time series data, especially that data that’s on the manufacturing floor, and create alerts so that you can do things like notify an operator when something needs to be addressed.

We also have Tableau for example, which is very popular tool, and we have a JDCB driver with that, and that allows you to take advantage of Tableau. They also have forecasting out of the box that also compares a variety of statistical forecasting methods that you can apply to your time series data really easily. So you can create forecasts with that without even having to decide which forecasting method to select. Cause it’ll automatically perform a performance analysis and select the best one factory which provides industrial applications that are focusing on performance and process data management.

Superset is another open source visualization tool, really easy to use. And at the end of this slide as well, I’ll share or this webinar, I’ll share some resources for how you can get started with a lot of these tools. And then we use InfluxDB for the data persistence and for middleware. We have various ways that you can ensure that data really smoothly flows between different systems, different devices, and different sensors.

So we have Telegraf, which is also an InfluxData product, and that’s a collection agent for metrics and events. And it makes collecting data and bringing that to InfluxDB extremely easy, especially because there are over 200 input plugins that allow you to get data from a wide variety of different sources and different protocols. So wherever your IoT data is being collected from whatever sensor and whatever protocol you’re using, you can use Telegraf to unify all of that data and then store that in InfluxDB.

We also provide integrations with Kepware, with HiveMQ and their MQTT broker. Telegraf natively supports things like MQTT and SNMP. We have HighByte, Apache, NiFi, etcetera. Lots of different middleware options.

And then we have different processes and assets as well. We integrate with industrial processes and assets, including things like Scada Systems plc, different robotics, sensors, plants, factories. We have people in all sorts of industries, from agriculture to automotive that are using InfluxDB.

Then last but not least, you can also leverage a bunch of different platforms, things like ThingWorx initiate, and Tulip, of course, that facilitate the integration of InfluxDB within the industrial IoT ecosystem that help provide additional tooling and functionalities to actually get the most out of your time series and sensor data. Next slide.

This is kind of a high level reference architecture for industrial IoT with InfluxDB, and it illustrates how InfluxDB integrates with all the different IoT data sources. I specifically want to focus on Telegraf, which supports not only MQTT support, but also OPC, UA, Mobis, HTTP, Kafka, AWS, Kinesis, etcetera. So no matter. Like I said, no matter where you have time series data coming from, you can use Telegraf to unify all that time series data into InfluxDB, and it’s configurable through a single TOML configuration. So it’s a low code solution and it offers buffering and caching capabilities as well as the ability to reduce the binary size of Telegraf to be just including the plugins that you need. And so that makes it really easy to sidecar as well. So it’s a great tool. Also it has these plugins that are called execd plugins, which make Telegraf extensible in any language. So that if you want to pull data in with Telegraf, you can maybe use a regular input plugin and then use an exec T processor plugin to write a script that will process that data in a very custom and unique way before sending it to InfluxDB.

We also have client libraries available in a ton of different languages that you can leverage. I am particularly fond of the Python client library, not only because it’s my home language, but because it has native support for both reading and writing pandas and polar data frames directly, which just make working with a variety of machine learning tools that much simpler, just because so many of them integrate directly with pandas and Polars. And then we have a bunch of partner solutions as well. I mentioned those already. And so that basically enables InfluxDB to be part of industrial IoT applications, from anything from monitoring and diagnostics to supervisor intelligent automation, to predictive maintenance, to process operation and resource optimization. And yeah, so that’s pretty much the summary on that. Next slide.

And so now I wanted to take a second to go over some use cases. So next slide. The very first one is Juniz. So Juniz is a company that develops intelligent management systems that control and optimize the operation of batteries and battery storage systems. So they’re collecting thousands of metrics every day, hundreds of thousands of metrics every day, on battery health, on climate, on temperature. And their tech stack includes Telegraf, Mobis, MQTT, Grafana, Docker, and InfluxDB. So they’re using InfluxDB Cloud Dedicated, and they store all of their energy, their battery and energy data in InfluxDB. Next slide.

And then we also have Goshen. And Goshen is a leading vehicle electric battery management and system manufacturer, so similar to Juno’s, they’re also working in the battery space, but they are using InfluxDB for saving long term storage costs for the company so that they can do long term analysis as well on some of the battery management. And they chose InfluxDB, particularly because of the good compression that it offers, especially with InfluxDB v three, built on the patchy ecosystem on things like Parquet and arrow, and being stored columnarly, that just provides opportunities for really cheap compression. Just because when you store anything in a columnar fashion and you’re monitoring an environment where sometimes or oftentimes values don’t change from one row in the column to the next, then you can really easily encapsulate large quantities of data with things like dictionary encoding and perform faster scans over those columns of data. So, next slide.

Sticking to theme here, we’re talking all about our battery customers today. Tesla also uses InfluxDB to monitor their power banks, their power walls for home usage, and they monitor things like health, availability, and performance of both their solar panels and their battery setup. So another kind of energy use case and storing all that data in InfluxDB next slide, and similar to Juniz, that uses Grafana to both perform some dashboarding as well as some alerting. This is a very common approach. Most users use Grafana with InfluxDB to build their manufacturing dashboards and perform their alerting. That’s because InfluxDB has a UI where you can explore your data. But we, we don’t recommend, there’s no dashboarding solution in InfluxDBv three. And we wanted to defer to the experts and encourage you to use things like Apache Superset, things like Grafana, Tableau, whatever your visualization tool of choice is.

And so without further ado, we’ll hand it over to William so he can talk about Tulip.

William VanBuskirk:
All right, thanks, Anais. So before jumping into Tulip, let’s talk about the, you know, the industry we’re at right now within manufacturing manufacturers, really, all factories are faced with two things. All factories are unique, and they’re dynamic.

So factories are unique. I’ve been in a lot of factories, whether they’re making power tools, rivets, medical devices, pharmaceuticals, you name it, there’s always a very unique process going on. They’re also dynamic. They’re always changing. They’re incorporating new SKUs, new models, new ways of doing things. So to really build manufacturing software for a unique and dynamic areas is, frankly difficult.

But for us, we see these two big areas crop up time and time again. One big element is composability. We see the need to give people a composable platform so that instead of giving customers an out of the box, stagnant solution that is very difficult to change, we see the need to give customers a dynamic platform where customers can really make it their own, make tool up their own, and then finally human centric augmentation. Ill touch on this on the next slide. But we’re all passionate about the forgotten operator really thinking about a lot of capital has been invested in more machines, more robots, which is great, but there’s still a lot to be done to equip the operator with the right tools, the right tech, the right data to really improve their efficiency, safety and frankly, well being.

So, to double click on that a bit more, here’s two themes of digital transformation. Within manufacturing. You have a very machine-focused transformation, a lot of robots, a lot of automation, essentially taking people out of the equation. And that’s one element. And that can happen sometimes. I think there’s many jobs that are the three Ds, dull, dirty and dangerous, that it’s better suited for a machine.

However, there’s a number of applications where look, the human ingenuity is still required in operations. So in our perspective, we think it’s really vital to, instead of trying to force fit technology into a process and take people out, it’s valuable to wrap technology around the operator. As you see in the image on the right, we’re putting in work instructions connecting older devices, streamlining how the operator interacts with their ERP, their PLM, or really any, any three layer acronym system. So now they’re, they’re able to really stay at their station, they’re able to have access to all the data they need to make better decisions and really make sure they’re winning the hour, the day and the week.

So, those are the two elements of transformation we definitely skew on the right of equipping the people first to, you know, spur on transformation. And frankly, we see a very quick time to value. It’s much less capital intensive. Now one thing I do want to highlight though, is why, why though, why the big focus on people? And I want to keep this slide as simple as possible. So past four years, pretty much post Covid, we’ve seen in the US about 0.3% labor productivity, 0.3%. Typically this number is around three to four, maybe 5% a year as a given. But frankly, a lot of operations companies have squeezed that towel as much as they can and they’re really not getting a lot of value out of the standard lean methodology, standard continuous improvement tools. Not to say they’re bad, but to say there’s now a need to continue to explore how to augment and extend those toolkits, to continue to create labor productivity gains.

So, essentially, like I mentioned, look, labor productivity is completely flatlined. A lot of manufacturers of all kinds, automotive, discrete pharmaceuticals, are looking for different ways, different methods to improve labor productivity. Again, that’s really why we built Tulip, is to really understand how to better augment and extend the operators capabilities, ways of working.

What is Tulip? I know I gave some of the industry context. I’ll jump now into what is Tulip? And then I’ll go into a quick demo after this.

First off, we’re a platform, a frontline operations platform, but we’re all about no code. I myself, I’m a mechanical engineer. I know how to solve problems, but I don’t know how to make a web app. To Anais’s point, you know, I’m looking at her slides. I’m pretty scrappy on Python, but that’s about it. So I don’t have enough to make a web app. But what we want to do at Tulip is we want to equip people like myself, mechanical engineers, process engineers, to make apps fit for purpose, that solve problems on their shop floors.

We really streamline connectivity, and that could be from the plant floor up, connecting your machines, your devices, or even up to enterprise systems like your ERP, to really give. Give operators a single pane of glass to connect with all their necessary systems and tools and devices. Then finally, I think there’s this balance of, we are no code, but we still have a lot of top down governance and scalability, that a central. It can have some assurance and some confidence that nothing’s running amok. And there’s a very clear sense of guidance and governance in terms of how systems are integrated.

Before I jump into any more demos, I’ll just walk through a bit of an imaginary factory in terms of how is Tulip used. So, just to highlight this, this is just kind of a made up factory. It’s really simple, discrete manufacturing. You’ve got a flip to it real quick. Here we go. You have some inbound material here. You’ve got some storage, some racking, some material prep, work order execution, and finally some quality checks. And then things are shipped out the door.

And our perspective is, look, manufacturers, sometimes they need all these apps, sometimes they need even more apps, other times they have a specific problem, and we want to give them the ability to solve that exact problem and nothing more. For now, for example, I’ll double down on the order execution app. Here’s an app where an operator can click or tap or scan a barcode. To access a work order, complete. Those parts have work instructions in the app they can really customize from the process engineer, get a shipping label, complete it, it’s integrated to a printer, they can print out the shipping label, and now they’re done with the job. And the list goes on with other examples such as quality inspection apps and others. I’ll just pull up the editor real quick just to highlight how simple this is.

Again, we love to tell customers, if you know PowerPoint, you know Excel, you can probably make a Tulip app. So essentially we have here the number of steps. Think of these like PowerPoint pages. Essentially, if you go into one specific step, you may see a couple of triggers. These triggers are really just a low code, no code way of moving data around. So very simple. The whole goal is that if you know the problem, you should be able to solve it, even if you don’t have a background in computer science. So that’s a broad view of the demo.

One thing I do want to highlight is feel free—as I’m giving a demo, as I’m talking through some of these apps and use cases—to keep the questions coming.

But that’s just a quick summary, and this is specific to discrete manufacturing. We do have other factories. One of the other examples are our focus on pharmaceuticals and life sciences, other areas like GXP, certifications on sampling, and Wayne dispense. So that’s really Tulip in a nutshell.

To keep going, though, just to highlight a couple of things that we saw together, I think I really highlighted four things. We saw a web based app editor, how simple it is to click and drag make apps that are fit for purpose. I didn’t necessarily show this, but we do have our own edge hardware that connects seamlessly with OPC, UA, MQTT, but they’re obviously, we’re very amenable to using third party hardware. That’s part of our open ecosystem view of making things as open as possible.

Another big element is real time analytics. I think some of those dashboards I was showing you, the key is that if it’s in Tulip, the best place to analyze it is of course in Tulip. But we’re also, again, open ecosystem, big fan of sending data out to other systems like InfluxDB, to tell an enterprise story about what’s going on in the shop floor.

And then, finally, world class ecosystem. That includes what we’re doing here working with technology partners. It also includes our library of pre built applications to really accelerate your time to value and your adoption. So those are four big elements of what is Tulip. Now, we talked about a couple of these use cases already around digital guidance. I mentioned some work instructions around production management. I mentioned some tracking use cases, but the list goes on. I’ll just put this up on the screen for a little bit of this essentially is a summary of all of the problems we solve at Tulip.

So whether you’re faced with a quality problem, digital guidance, production management, traceability, inventory maintenance list goes on, we’ve got a way to solve that problem. Again, it’s not that we have a singular point solution for each of these use cases, but rather we have a starting point for all of these. But we have a platform where you can easily drag and drop and build your own app to solve these specific problems, to really make it your own. Again, factories are unique and dynamic and we get that. So I’ll walk through a couple of examples of just what we’ve done in the past with some of our customers.

I think a big element here with the DMG Moore case study is just how quickly DMG Mori was able to expand to go to a number of sites, currently around twelve to twelve to 15. I think the key here too is that they didn’t have 20 apps to solve the same problem, but they were really able to standardize and say, okay, well, we’re going to do [inaudible]. If we’re going to do production management, here’s the 80% complete app, here’s the de facto standard, and now there’s some ability for plans to share best practices, plans to not have to start from scratch to say, okay, well, if I’m working on quality management and this plant over here already fixed it, how can I borrow their solution and then, you know, fine tune it, tailor it and make it my own? That was a big winning point for Team [inaudible]. And frankly, secondly is, look, sometimes it’s not about pushing the latest and greatest tech. Sometimes it’s about simply saying, look, you know, how can you, you may have a problem with five s auditing. How can we make a simple checklist easier and data driven? So we’re getting off paper and we’re getting off of whiteboards and we’re getting into a place where, you know, this data can be more easily analyzed to understand trends.

One outcome I really want to highlight is our TECO tractors story where moving from a paper based solution to a digital work instructions and basically a digital record instead of a bunch of paper travelers that enabled them to double their production, to really rethink how they manage capacity on the shop floor. I love the story of a shadow factory, a hidden factory. I think a lot of companies that are thinking about building new factories, new capex injection, but frankly, in a lot of operations, there’s a hidden factory beneath the foundation. There’s a lot of opportunity, improved capacity in your existing footprint with new tools and tech.

It was really exciting to see Teco take on that journey by building apps that are, again, fit for purpose. It wasn’t that they jumped in, looked at our use case list and made everything under the sun, but it was all about working hand in hand, saying, what’s the biggest pain point? How can we address that? What’s the second biggest pain point? Let’s address that as well, and then going down the list. So those are some two case studies, DMG Mori and TECO tractors. That’s kind of a high level summary of what we’ve been doing at customers.

And again, in the chat, please feel free to keep the questions coming. We can kind of get a backlog of those and we can then walk through them towards the end of the conversation.

So let’s talk a little bit about what Tulip and InfluxData look like. I think a big element I’ve already mentioned is that we’re an open ecosystem. So you can store data on Tulip, you can analyze data on Tulip. But when there’s situations where you’re trying to ask an enterprise question, hey, why is my quality bad? And include all of the data from products in the field, include all the data from different sensors or different enterprise systems, then there begets a need to flow it up a level and connect to other systems of record, like InfluxData.

So, here’s the storyline of what this looks like. With a bit of a flow left to right, we see a lot of customers, obviously, having their frontline operators talk to Tulip with their apps. And those apps could be anything from, again, an app on a phone, app on a computer, app on an HMI, what have you. But Tulip is bringing in that operator information and context. Tulip is bringing in systems of record data, whether it’s ERP, PLM and more. It’s also bringing in data from your [inaudible], potentially getting contacts from Litmus or HighByte.

And finally, it could also be connected devices. I know banner and insertor, some of our big partners. But finally, it doesn’t start there. It stopped there, though. But there may be a need to say, okay, that’s all great. On the shop floor. I now want to send all of this data to InfluxDB to then pair it with other data, to have a bit more of a contextualization, to say, okay, well, how can I look at predictive maintenance holistically? How could I look at predictive quality more holistically? And like Anais said, there’s a number of visualization tools here. I just put Grafana as an example. So that’s kind of the flow from. From left to right around how we get data on the shop floor into either the operator’s hands, supervisors hands, plant manager’s hands, and others.

Here’s one other view that just kind of highlights the. The whole ecosystem of it. Again, the whole. The whole goal here is Tulip. What we call it is a system, not a record, but system of engagement, where we can be the front end of the ERP that connects the people to the ERP. We are the way that you can not only get data off the machines, but contextualize that data with operator input. It’s one thing to know your machines down, it’s nothing to know why it’s down and what the operator has to say about it to really tell that holistic story. But like Anais mentioned, there’s a ton of tools in the InfluxDB ecosystem that allow you to take data out of Tulip and other systems to tell more of an enterprise wide story around root cause analysis in your operations.

So, I’ll take a pause there on the architecture. Anais, anything I missed? Anything you want to double down on in terms of architectures?

Anais Dotis-Georgiou:
Yeah, just in terms of kind of looking at InfluxDB and the surrounding ecosystem for gaining insights, I did want to just mention we have in our influx community organization examples for how to leverage InfluxDB with a variety of ETL and data processing tools we recently partners with.

Quix is a Python streaming tool that’s pretty low code and has a bunch of plugins for InfluxDB and also a bunch of pre-built templates to perform things like anomaly detection and forecasting. But you can also have the opportunity to edit any of the codes you want as well and do things like pull down transformers from hugging face or predefined models from hugging face and apply them to your time series data.

You can also use other stream processing tools like Kafka or byte wax or Red Panda to kind of perform any of that work that you need to do before, you know, necessarily visualizing your data or creating alerts on it. So. Absolutely. Thank you.

William VanBuskirk:
Perfect. Yeah, and just like I just mentioned, you know, it’s an open ecosystem. You know, I think with both Tulip and InfluxDB, a big passion, frankly, of ours is to do that. It’s less about us telling you, “Here are the 1-3 tools you need to use,” and it’s more about us being as open as possible and making sure that, you know, you and your specific use case, you’re using the tool that’s really fit for purpose for your operation.

So, with that being said, I can jump into a bit of a demo in terms of how these things are intertwined. So, I’ll pull up a couple of examples here. Pull up a super simple app of just what an operator may look like day to day. They may be looking at an app where they can change the state of an operation. They can put in some downtime; they can put in some idle time. They can log back to running, they can log good parts and bad parts. Well, the key here, though, is by default, we can store a lot of this data in Tulip, but it can also be the need, like we mentioned, to easily and seamlessly get this data out on the shop floor. I’ll just highlight this really quick.

A big area for this is our connector platform where we can really seamlessly streamline how data can be sent from, in this case, Tulip to InfluxDB. It’s really simple. I’ll pull up one of these connectors. It’s as simple as if, you know, postman, you can just drop in the URL, drop in some of the headers, drop in, for example, the measurement, the field of value, and you’re good to go. So, we wanted to make it as simple as possible, frankly. The other simple part of this too is our library, our Tulip library. You can actually install connectors like this as a starting point, so you’re not starting from scratch. A big priority around our library and our ecosystem is to give users the community, the library, the training courses—to not feel like they’re on their own. That they have to build everything themselves. That’s a big passion of ours.

But I’ll flip back to that app that we just mentioned, and I’ll show how easy it is. So, back to that downtime state change again. If this is an app, I have a button here. It says “machine error.” Or, for example, “[inaudible] shortage.” I’m thinking, all right, when an operator hits the button, I want them to hit another button. Tell me, okay, why is it down?

In this case, I have my standard Tulip triggers. I have a really simple trigger here that says, okay, well, if this button gets clicked, I want you to send everything you know about the current situation, including the operator, the work order that was being worked on, all of this context, sent it to InfluxDB using the rest API connector.

What I’ll do now is I’ll just pull up the data Explorer view just to highlight some of this data I’ve been writing back and forth right now. We’ve got data around downtime, around the site, around the person, around the time of the event. And that allows you. I’ll pull up this slide again, it allows you to really have that broader contextual story to all of the elements at play here.

So, when you’re trying to ask a question, okay, well, why do we not meet our number today? It’s not, “All right, well, I guess our people weren’t working hard enough.” Now you can look at supplier data, you can look at people data systems data, to say, hey, maybe the problem is, you know, we have some delinquent suppliers. Maybe we have a bad process. We should talk to our engineers about, you know, refining our work instructions, and you can really get into that, that specific root cause. So that’s a big thing for us.

And then, you know, thinking about time series from scratch is difficult. So, using a lot of InfluxDB tools and partner ecosystem really streamlines that.

So, I’ll take a pause there if there’s any questions on the demo or questions on the library content. Yeah, so I did have a couple questions about the library. I’ll pull that up right now live, just to kind of walk through it.

So, Tulip library, essentially, you can go here to Tulip dot com library. We have a homepage of some of our go-to apps, such as the composable MESA app suite. That’s the app suite I was showcasing. But it’s as simple as going into the library and searching for something like InfluxDB. And I can really easily connect to InfluxDB so I can install this connector. This comes with all the headers prefilled out. The URL’s all set. All you have to do is essentially authenticate, add your bucket details, and you’re off the races.

So, the whole goal here is to kind of lower the activation energy that’s required to think about how all these systems talk to each other. So, obviously, we do love open ecosystems. That means there can be some hairy integrations, but our goal is to make those as simple and as straightforward as possible. Anais, anything else to add on that?

Anais Dotis-Georgiou:
Sorry, I was muted. I did just want to kind of take a second and just show my screen, if you. Yeah, you could swap over. I did just want to take a moment.

Now, this is a very simple dashboard in Grafana. It’s just kind of monitoring a single continuous stirred tank reactor where basically, you know, some chemical engineer has some concentration of some chemical coming in at a constant feed and temperature, and that concentration is going through a reaction a to b, and then you have an output. And they’d probably be monitoring things like the concentration in the reactor over time, the cooling jacket temperature, so they can actually sustain the value, and the operator can determine what they want the set point of the reactor to be, some other components of some math. Essentially, that helps the operator determine whether or not their calculations for their processing and determining what their cooling jacket temperature should be is correct, as well as the actual temperature of the reactor.

You know, some plateaus in this temperature data, which probably indicate changes when the operator induced a different set point for the reactor. And so, this is just coming directly from InfluxDB. If we were to edit any individual source, we could see that we are getting a data source from InfluxDB, and we have plugins for Grafana that allow you to easily connect similarly to Tulip so that you can go ahead and perform any of your queries with SQL and visualize your data. So, this is a very simple example of what maybe a dashboard would look like in the chemical engineering space. But just to kind of highlight how a lot of users would leverage Grafana with InfluxDB and Tulip.

William VanBuskirk:
Perfect. I am keeping up with that too, it is like, it’s one thing to know, for example, in this situation, one thing to know. The reactor data around, okay, the reactor has these set points, this temperature, this pressure, but adding in that human element of, okay, well, you know, I saw this. I checked this. Here’s the latest check. Here’s who logged in. Here’s who logged out. To kind of tell that whole story across people, process, and machinery.

Anais Dotis-Georgiou:
Absolutely.

William VanBuskirk:
I did see a question.

Anais Dotis-Georgiou:
Oh, no, go for it. Did you see a question?

William VanBuskirk:
Yeah, I saw a question come in again on specifics, you know, around what about vertical solutions with Tulip? And that’s something. Spot on. Tulip serves a number of verticals, everything from discrete manufacturing, life sciences, automotive, and automotive, really across the tier. One, two, three, and OEM. I think a key theme here is in our library again—we have a lot of apps that can be used for automotive relatively quickly. I think, frankly, a lot of things we built for TECO, a lot of that thinking can definitely be applied to automotive. So, the thought here is, we thought through it. A lot of these apps are designed to streamline existing automotive processes, whether it’s ISO 9001 or PPAP, you name it. And our thought is that the library can really streamline how you can build those automotive-specific apps, whether it’s for mainline assembly or body stamping. Really any specific use case or problem.

Anais Dotis-Georgiou:
Yeah. Similarly, another person asked in the chat what implementations that you have specifically for automotive manufacturing. So, I don’t know if you want to take a second to answer that and then I can. I know you already did, but I don’t know if there’s anything that you want to add specifically about the automotive industry.

William VanBuskirk:
Yeah, I think just to really double down on that again, we’ve seen a number of times within automotive, the places that Tulip works the best is when their lean culture is already very mature. Because if the factory’s on fire, there’s no daily stand ups, there’s not a culture of Five S. As a consultant, those would be the first things I would jump in and say to some blocking and tackling. But when those core pillars of lean are already there, we then, as Tulip can say, “Hey, this is great. You’ve already mastered the fundamentals. Let’s go in and digitize those. Let’s go in and streamline how we get data to the shop floor in real time. Let’s go in and think about how to better track some of these metrics and show improvements or anomalies.” I did see one question. Go ahead.

Anais Dotis-Georgiou:
Oh, I just want to tack onto that. As far as InfluxDB is concerned, we definitely do have customers in the automotive space. I can’t think of all of them off the top of my head, but I will share a link in the webinar chat so you can see more. I do know that I believe that Volvo is a customer of ours using InfluxDB for, I think primarily DevOps monitoring, but also some, I don’t know for sure, don’t quote me on that, but potentially some things related to the manufacturing as well. But that’s one customer use case that I can think of off the top of my head.

William VanBuskirk:
I saw a question from Adam coming in a little bit late. I wanted to see some context in terms of is Tulip and ERP or NES or is it really just a bi-analytics layer? I can go back. I’ll go ahead and share my screen really briefly ON this view. Here, just to highlight that. So, in some situations, for Greenfield, especially, Tulip may be a system of record and a system engagement where customers will use Tulip as the MES and the shop floor apps, where you’ll do things like production management, quality management with Tulip apps, again, to highlight our low code, no code environment. I know we did a demo of this before to really streamline.

Okay, how do you build something that’s really fit for purpose, that you can easily click and drag around, and other times for more of a brownfield development where there’s already a lot of systems in place, Tulip can come in and then say, “Hey, we can be the new de facto front end of a lot of your systems of record.” So, take SAP, oracle, NetSuite. We can now streamline how operators can interact with those systems of record, essentially by using our connectors. The same connector abstraction that we use to talk to InfluxDB. We can use that to talk to ERPs and PLMs and other systems.

I think the key here is, though, we’re kind of the glue, the glue between everything. We’re the glue between the systems of record, like I mentioned, as well as the people, the devices, the machines to, again, give that whole context of, okay, if we missed a goal, was it a machine problem? Was it a people problem, was it a scheduling problem? What was really the root cause?

So, Tulip kind of sits right in the middle of it then. One thing I was mentioning before is that the key theme here is that Tulip is an open ecosystem. There’s plenty of ways to analyze and store data in Tulip directly. There’s also plenty of connectors, such as our SQL connectors, our MongoDB, our InfluxDB connectors, to really streamline how data gets out of Tulip to tell more of an enterprise story of end to end.

How can I optimize my manufacturing layout in the case of TECO tractors? These are good questions. Yeah, feel free to keep the questions coming. Well, we’re getting a few more questions in.

I’ll just hover on this slide for, for a minute. One thing about, frankly, both InfluxDB and Tulip, is that there’s plenty of resources to go around. Whether it’s forums for asking questions, whether it’s support docs, whether it’s university or library content, to say, “Hey, I want to train how to build it, and I want an example, and I want a template.”

You know, Anais and I are both really passionate about bringing people in to build apps faster, leverage the platform quicker, and learn from others as a communal experience. So, the recording of this, feel free to check out some of these links. And I know there’s, there was a QR code of both, of both of our LinkedIn links. So, feel free to connect with us on LinkedIn and ask any other, other questions. We’re definitely here to support the community, here to support you all and, you know, make sure you all have what you need.

Anais Dotis-Georgiou:
I also want to encourage you to visit Influx community on GitHub. That’s just an organization that contains all sorts of examples of using Influx with a variety of other tech stacks. So, you can just have examples for how to get started, you know, using InfluxDB with a variety of other tools. You know, whether that is HiveMQ, whether that’s Quix, whether that’s Kafka, Tableau, Grafana, whatever that is, just that you can get started with some example repositories and get an idea for how to leverage them.

William VanBuskirk:
Okay, well, just to, just to kind of wrap things up, I think I really want to highlight three big points we’ve been touching on this whole time has been, you know, people.

First, Anais and I are really passionate about people centric analytics. Getting, getting data out of, out of people and really telling that people centric story. It’s one thing to get data off of PLC’s and machines, but really making sure people are included in the story is impactful.

Another element is the open ecosystem. I mean, even just looking at our slides, you see a ton of logos that are very open. Our whole goal is to kind of not be a silo of data or analytics, but to tell that end-to-end story, to make sure that you as the customer are able to use this data to be super fit for purpose, and then finally, rapid time to value. I mean, the whole goal, a lot of these demos that we’ve been showing, we built those relatively quickly, you know, weeks, if not days.

So, the whole goal is to, instead of trying to do a monolithic lift and go from zero to 100 after eight months of requirements gathering, our goal is to kind of, you know, go step by step, be very lean, very iterative, and solve the most important problem and then move on from there. So, some big key takeaways. Again, definitely, definitely appreciate everyone’s engagement and questions on the session.

Anais Dotis-Georgiou:
Yeah, thank you, everyone. And just as a reminder, there will be a recording of this webinar that will be sent out to you quite shortly, as well as any relevant links so that you can, like William said, check out the community, check out the universities, get those courses and learn more about InfluxData and Tulip.

So, thank you all so much for joining, and I hope to see you at future webinars as well. And thank you, William, for your time.

William VanBuskirk:
Absolutely. You too.

Anais Dotis-Georgiou:
All right, everyone, thank you. Have a good day.

[/et_pb_toggle]