Lisa Ryan: Hey, it's Lisa Ryan. Welcome to the Manufacturers Network Podcast. I'm excited to introduce our guest today, Mike Bowers. Mike is the chief architect at Faircom, with over 35 years of experience in software development and architecture. His knowledge extends to the database revolution, manufacturing 4.0, the industrial internet of things, Edge computing, and data integration. So Mike, welcome to the show.

Mike Bowers: Oh, I'm glad to be here, Lisa.

Lisa Ryan: Please share your background and what led you to work with Faircom.

Mike Bowers: I've been presenting at conferences on the database revolution for decades. Faircom is a database company that has been selling database software for the last 40 years. You may not have heard of Faircom because it's an embedded database, probably embedded in your phone, satellites, and networks. For example, every phone call you make on Verizon goes through the database, but they don't.

We never did. We were an engineering company, and we never advertised. I never knew much about Faircom, but they saw me at conferences discussing a new database technology that has yet to be implemented. They liked and wanted to implement the ideas, so they recruited me to build that technology into Faircom.

When I got to Faircom, we started building that in. They also realized that since we're an embedded database, the manufacturing world needs to capture data, and they need to capture it in the equipment. They need to capture it on the manufacturing floor. Unlike IT, which tries to go to the cloud and stick everything servers up in distant data centers, manufacturing must capture data on the factory floor.

Manufacturing doesn't want to do that because you can't afford the downtime if the cloud goes down if your network connection to the cloud goes down, if it becomes intermittent, you can stop your manufacturing floor, you can stop processes dead, and you can't afford that. So you need to run locally. And that's where the Faircom database is good. Before my being hired by Faircom, they started selling the product to manufacturers as a database platform. I have an extensive background in manufacturing. I worked in the silicon industry. I wore bunny suits and Intel commercials, and so I've been done all that.

I worked in the automotive industry at Freightliner, which automates vehicles. The Sprinter van is there- a computer runs the whole van. You push on the gas, but it doesn't physically cause the fuel to be injected. It tells the computer you want to inject fuel and does all the injections. So that whole computer system.

I wrote the compiler, the language, everything that programs that van. So I'm proud of that one. It was a lot of fun. I worked in the agriculture industry with extensive, huge farm equipment that picks up one-ton bales, compresses them, and you push a button, and it does all the work.

It's robotics and automation. I spent a lot of my career in manufacturing, and then I spent a lot of my career in the database industry and software development. I wrote a book on HTML and CSS that's still published out there. So I've done a lot of different things. Vericom hired me for the database, but we realized Faircom was trying to enter manufacturing. And because we have a perfect product for that, from a database perspective, I've done all this integration work in factories, and I realized factories struggle with integration costs. It's so expensive to hire people like me, which is what I did, is to go into a factory and automate the factory, and to go to the proprietary protocols on this machine, write the drivers to extract the data, to put them into your manufacturing execution system or your SCADA systems or your ERP systems. All that's a point-to-point development work. And I had spent a lot of time in my career building integration systems that were more generic. So, when Ferricom hired me, I realized there was an opportunity to solve two problems at once. Build this new revolutionary database technology and Make it an integration platform at the same time because I've been working on both problems my entire career.

Coming to Faircom turned out to be even better than I thought. I was excited to work on the database side, but then I realized, wow, I get to work on this other integration solution I've worked on for several decades. My last job was at a large multi-billion dollar international corporation.

I was the head data architect for that organization with thousands of developers. They needed integration for everything. As I said, thousands of developers were integrating data, so I designed a new integration platform because we had nothing that would work out of the box. We bought everything. We had products from IBM and Oracle, and you name the big companies, Microsoft. We had them all, but none could integrate in all the needed ways. So, when I came to Faircom, I started building a new platform for Faircom. We call it the IoT platform.

It's an integration hub. The idea is to integrate data from factory machines and bring it into a standard format. JSON is the standard format, and the JSON is what the factory needs to shape the data the way it needs it. So it's plug-and-play and leverages technologies like MQTT and OPC UA as universal protocols in the factory.

And then, get the data- into JSON from all of these protocols, whether Modbus, OBC, MQTT, Siemens S7, or Alan Bradley's Ethernet IP. You name it. There are hundreds of protocols, right? You must get data out of those protocols into a standard universal format.

Some people call it a universal or a uniform namespace. The idea is a standard format. And once you get your data into a standard format like JSON, you shape the data in a standard way so that you can plug and play your equipment. Then, you can dramatically introduce your manufacturing costs.

You can extract the data from the equipment, and it can become a point-click operation. However, instead of hiring someone like me and paying me exorbitant fees, which I was okay with as a developer, the factory didn't like it. Thus, you spent millions of dollars to grab this data from the equipment.

You're limited to whatever the developer gave you. Later, you say, " I've got a new version of the equipment. Can you get this extra data? " Oh, sure, for an excellent hefty price tag: 100,000 or 50,000, depending on what you're doing. So you're limited in getting the data out of the equipment, and then you're limited.

I'll write a custom code to get it into my manufacturing execution system. And I write unique code to do that. And it's a point-to-point solution. But I need it to go somewhere else now. I want it to go to the cloud. I want it to go to the SCADA system. I want it to go over here to this operation software we just purchased.

And then you're like, that's more custom software development work. So manufacturers are stuck in this quagmire of proprietary protocols and customized software development work, which limits them from getting the data they need to improve their manufacturing processes. Some people say data is the new currency.

And that's true. Data is like money. And if you can't get the money or data out of your equipment, you're limited in the value or money you get from it. So that was what I came to Faircharm to do: build a new database technology.

I've also built a whole new integration platform. You point and click, and data flows in these universal formats. So you can have a plug-and-play factory.

Lisa Ryan: So, for people who aren't, who don't understand all of these different acronyms, the integration field understands. So you have all of these various programs that are in manufacturing, and how do you get them to talk to each other to put them on this point and click, like in the very basic of terms, how does it work that Yeah, that it speeds up the process for what you were doing before as a consultant to what you can do now getting all of these different programs to talk to each other.

Mike Bowers: Oh, that's the perfect question because if they're all proprietary protocols, as manufacturing companies often do, they'll invest in one primary vendor like Siemens or Allen Bradley. If they buy everything from that one vendor and use all their solutions, which is very expensive, they might be able to have a plug-and-play factory.

But the reality is that they need to buy equipment that does the job to make whatever they're making. And that equipment has all these. Proprietary protocols are binary low-level protocols where you have to say this little bit means this bit means that, and this bit means there's an alert, this bit means the machine's stopping, and this bit means it's starting. Then, you have to gather all those bits and convert them.

It's super expensive and proprietary. How do you get that into a standard way? What we do is on our product is we get, we create drivers that can talk to the Siemens protocols or the Allen Bradley protocols, and then the industry knows that this is a real problem with all these proprietary protocols that lock you into a vendor that make it complicated and expensive to get data out.

Several protocols are more open-ended. Modbus is a pretty open-ended protocol. It's still down at the bit level where you're tweaking this bit, which means this number represents the other thing. But it's not proprietary. So that was the first step. And then Vintner said now we need to be more self-describing.

Let's use a protocol like OBCUA to ask the machine what data it has. It will come back with a list. I have temperature, air pressure, and the stamper frequency numbers. Then you say, " Okay, I'm interested in stamper frequency. How often are you stamping? "

I want to see how productive my equipment is. I want to know if it's producing at a high rate, slowing down, or getting old. And so, I like the stamper frequency number. With OBC UA, you say, " Okay, give me the stamper frequency. " It'll send it over, or you can pull it and say every 10 minutes, you can get the number every two seconds, whatever you need to do.

So, the industry has evolved from these proprietary protocols to more generic ones like Modbus. Open ones like OPC UA that tag the data, and you can ask it questions, but OPC UA is good as it is. It's costly because it is so cool. And vendors who it takes, it's tough to implement an OPC UA feature into your product if you're selling a piece of equipment to implement that in is super expensive.

So they pass that onto the factory and say you'll pay more for OPC UA. Faircom provides drivers that allow you to connect to your native protocols, so you don't have to buy the expensive OPC UA solution if you don't already have it. But we also connect to OPC UA when you do have it.

Some equipment is now evolving to produce MQTT messages. MQTT is a new protocol that is transforming the whole manufacturing world because it's open source, it's standard, and it's not proprietary. It uses Canada's. It's flexible, and most people send JSON messages over it. JSON is a simple way of human-readable messages that you can format and say the temperature is 71 degrees.

You can just, and humans and machines can read it so that we can troubleshoot it in the factory. You can also push messages around. It's like email. Or Twitter: you publish a message, and anyone who wants that topic can subscribe and get it, just like a podcast.

If you want the podcast, you subscribe. If you don't, you don't get it. That's what MQTT does. That model is game-changing for manufacturing. Some equipment is starting to support MQTT as well. And MQTT is taking over the industry. So, we built an MQTT broker right into our product.

We have built-in drivers for all these proprietary protocols. So you go into our product and say, " Okay, connect to that device using this protocol. " We automatically gather the data, convert it to JSON, and deliver that data to any other protocol. So, we have this universal translator.

That gathers data from any protocol and sends it to another one. So it's, and we use techniques that no one else can do because we have our embedded database inside. After all, we have a, we're a database company. So when it

Lisa Ryan: Would this be a low-code platform then? You had mentioned something before about low code. So, what is that in the scheme of things?

Mike Bowers: As I said before, I spent it on high code. If you hired me to convert data from a machine, I would have to write a lot of code. I had to use a programming language, and it would take a ton of code, and that's why it's so expensive. Low code means all the heavy lifting has been done for you. Faircom has done the heavy lifting. We've once written all the hard code in these drivers, converting it to a universal communication format like JSON and standard structures.

We've done all that hard work, so now it's just a matter of putting a user interface on it, and you point and click. Low-code means point and click, so you can point and click and say, " Okay, connect to this. " For example, I have a temperature sensor. I want to connect to it.

It talks about Modbus. Okay. So I'll point, click, and say, " Connect to this sensor using Modbus. " I'm interested in the temperature. Now convert that from Celsius to Fahrenheit, point and click, point and click, point and click, and then send it over to MQTT so that somebody can subscribe to the topic of temperature on my temperature sensor.

So, point and click, point and click, and you've got that whole thing configured in minutes instead of paying someone like me $ 30,000,000 to write all that code to make a point. Use a point-to-point solution to get it in your MES and bring it into our hub. From our hub, it can go anywhere in a universal format.

We've built a universal translator, and all these protocols, drivers, and technologies, like MQTT and OPC UA, are built in, along with a database. We even have an application server built there to support web applications. So you can do point-and-click. So it's easy.

Lisa Ryan: You've mentioned a couple, but what protocols can this manufacturing integration platform support?

Mike Bowers: Yeah, the ones we support today are MQTT, OPC UA, Modbus, Allen Bradley, Ethernet IP, and Siemens S7. We also support SQL for the IT folks, the JSON protocols over HTTP, and all your RESTful stuff.

We also support pushing data to the REST endpoint. The IT world also needs all this data stuck in manufacturing. We have the three number one technologies IT needs to get data out SQL, REST, and MQTT. They use all three techniques. So we have that, and then we have ThemeWorks integration as well.

And we're building more protocols all the time. 

Lisa Ryan: So if you're working with a manufacturer and talking to them about using an integration platform because they can reduce their integration costs four times and all of that, and they, and basically, you go in speaking the language of it, which is terrifying to most manufacturers. 

So, how do you put it in? Simplified terms that people would understand. 

Mike Bowers: We've been spending a lot of money on this and want to reduce our integration costs. This sounds like a good idea, but how would we get started? And more importantly, how would we take the fear out of all this technology stuff that nobody except IT people understands?

First off, we could connect to your equipment. Whatever protocols you have, we usually have a protocol that supports most equipment. There are even hardware devices you can plug into equipment that convert protocols. If we don't support the exact protocol you have- and there are hundreds of protocols that equipment has- you can plug in these little hardware dongles that convert it to OPC UA, MQTT, or Modbus.

It's very easy to get the data. We just say, " plug, plug. " We'll plug into your equipment, get the equipment out, and don't even worry about IT because we talk their language. Our universal translator, our hub, automatically gets it to IT. You don't even have to worry about IT. It, they, in fact, here's the key point.

It's been begging you for data forever. We have the solution. You don't even have to worry about IT. You say we've got a hub that auto-translates what we understand in the manufacturing world to all that IT stuff. And the IT stuff- those guys- they know how to talk IT stuff. They can come to our equipment and product and go, " Oh, you've got SQL. "

Awesome. I know how to use that. Oh, you've got the best. Oh, I know how to use that. You got MQTT. Oh, I know how to use that. So they don't even need help. They can see the data sitting there in our products, and they come and get it and love it. Finally, we freed the data, and that's the key point here.

Instead of hiring people like me to get to a point- and now you're locked in, we free the data out. We bring it into our hub, and anyone can get it. We can push the data anywhere we need to push it. So yeah, you can forget about IT. And the other part is you don't need IT to make this work.

So that's one of the critical things about Faircom. We've been in business for 40 years, building lights-out systems that work—high-performance, high-volume, no maintenance, plug it in, and it works. Some of our customers have a big complaint that it's worked for so long, they forget and get scared- what if something happens?

How do I fix it? It's been working for seven years, and I've never touched it. If you think about it, that's scary because if it goes wrong, what do we do? We have no one. It's a good thing that Faircom knows how it works, and if you have any support, we support you beautifully and fix it.

And that's not an issue. But that's how we roll, so IT doesn't need to come in and install our product. It installs itself. You unzip and run it. It's just- it just works. You unzip, run, point, and click, and it's all doing the job for you. So it's super easy to install and maintain, and you can do it in your factory without IT. But then IT can come to get the data.

Lisa Ryan: So what about security? I know there are dangers to the cloud with ransomware and cybercriminals knowing what the cloud is and being able to break into it. If you have an integration platform that's easy to use, plug and play. Does that make it more susceptible so criminals can't get to it? 

Mike Bowers: Awesome question. You're right. If you put all your data in one place, that's one place for a hacker to go and steal the data. So you have to secure it. And so what we do by default is everything is secure.

We have built-in encryption. All the data we collect in our database is encrypted on disk. So if they were to steal the machine it...