 So I'm here to talk about Project FLEJ as our pit just mentioned. It's uniquely focused in the OT space, the industrial IoT space specifically. And so I'll be talking about exactly what is the project. But FLEJ builds intelligent pipelines from machines to the cloud to aggregate data, process data, and integrate data with the different systems you'll find in industrial places. They all say the ISA 95 stack, the operational systems, and the new systems being built in the cloud. So Project FLEJ is rather mature. The contributors are unique, though, in that most of them are from the industrial space. So some of these names may be new to this audience. But companies like Aviva, OSISOF, which is owned by Schneider, Google is a contributor to the project. RTE is the largest energy company in Europe. Jacksonville Energy Authority is the eighth largest utility in the United States. Teledyne Flur, one of the more respected sensor manufacturers, best known probably for infrared cameras. They actually embed FLEJ into their new generation cameras. Biba is the University of Austria, kind of the MIT of industrial out of Austria. So a lot of work in Germany captures another German systems integrator. BRP, a large, discrete manufacturer. They build small engines in Europe. You've probably heard of them. UC Davis, real cool use case on the bottom here I'll talk about at the Opus One Winery. Newman Aluminum, a supplier to BMW for aluminum parts. Allander, another very large energy company out of Europe and in Dianomics. So those are the major contributors today to the project. And as Arpit mentioned, the project has also been embraced by LF Energy, which is focused on green energy and open source projects around the development of green energy around the world. And FLEJ is being used as an edge technology there. It's also in trials, it says me, in a very large food processing company. And some of our public deployments are listed there. I'll talk about two of them specifically as I go down. It's also deployed. I'll have a use case here in one of the largest chemical companies in the world. And I'll talk about how it's pushing about 2 and a half million tags a day right now through their infrastructure. And then my name's Tom Arthur. I'm the co-founder of Dianomic and we're a contributor and also offer commercial help for those that are wanting to join the community, learn how to program it and distribute the code. So as Arpit talked about, the industrial edge is a little bit different than IT in general. So when I define the edge, I usually talk about it as being the first hop I don't own. And so in the industrial space, that usually is the, I'll call it machine edge. So the very first place one acquires data in industrial spaces is generally a SCADA system, a DCS, a PLC, or maybe a directly connected analog central. And then so gathering that data from the edge, processing that data and moving that to the various operational systems that industry uses. And it's almost always associated with the continuous monitoring OEE quality projects and applications, predictive maintenance, situation awareness. But really the big idea in OT is the future of the self-deriving factory. The more automation the factory, of course, the more data brings value and the opportunity to have that happen. So what exactly is Project Fledge? Fledge is a series of six microservices that first connects any kind of industrial asset and really any kind, any protocol, even analog signals. It'll connect those assets, it'll aggregate data. And tomorrow's factory, it won't be adequate just to connect to the PLC of a machine. You'll be putting aftermarket sensors on that machine as well. Let's say a camera looking at quality coming from this machine on this part or process, maybe vibration sensors that are doing predictive maintenance on the bearings so you know failure before it happens. So it's a natural place on the edge, not just to get PLC data, but to aggregate all the data associated with the health and maintenance of that specific machine. So Fledge connects the data, aggregates that data, and then it of course can buffer that data. Many, many networks in the industrial space are not that reliable. Assets might be remote, they might be actually still going on Bluetooth. Of course, the opportunities for 5G and all that, but the types and sources of network and the reliability is very vast in the industrial space. So buffering is critical. And then it begins to process that data and it can filter the data as it is ingested from the edge. And it can also filter the data on the egress as it sends that data to various destinations. It can then analyze that data on the edge and do events and notifications. And it's a natural place obviously to do machine learning techniques on the edge when you need to run inference on the edge. And there are many, many applications in the industrial space where that's a requirement usually due to latency and data volume. For instance, one of our projects has it on four vibration sensors on centrifuges that are producing gigabytes of data a day off four 10 kilohertz vibration sensors. So if you're gonna run ML on that, of course you have to run inference on the edge. And then last, it integrates that data. And in the industrial space, it must integrate it with the current operational systems, things like MES systems, OEE systems and historians, as well as of course send that data to the cloud. So you probably have in mind right now after that explanation is Fledge can connect data from machines and sensors and send it to a destination. But if you also track, it can connect to multiple data sources. Let's say the camera pointed at the output of the machine and the PLC. And then it can integrate that data to the operational systems at the industrial site as well as the cloud. But then Fledge can talk to Fledge so they can be deployed in the hierarchies or meshes and you create what I would call smart or intelligent OT data pipelines from machine all the way to the cloud and then do the processing where it's appropriate anywhere from the edge to the edge before the cloud or in the cloud. And Fledge allows that infrastructure and the redundancy of that infrastructure to occur. So the Fledge architecture, you probably have in mind after that second slide is a set of, as I said, six microservices. So the South microservice we call is built to integrate the data and connect to the machines and the sensor assets. These little blue boxes you see there, we call plugins. And what's interesting about the plugin architecture is that a coder writing in Python or C without completely rewriting the South microservice can add virtually any protocol in a matter of weeks. So today the Fledge project has about 100 protocols on the South side. And then the second thing you can do in the South microservice is begin to filter data as it ingresses Fledge. So once again, something like vibration data where you're processing 10 kilohertz data, it's a natural place then to start doing signal processing, doing functions like RMS or FFT. And so then from the South microservice data flows and is converted into a common JSON and we run Postgres at the storage layer. And from the storage layer, we have a North microservice which is where data then is integrated. And once again, you have the same plugin architecture where you can do data transformations and filters as it egresses Fledge. And then you have plugins to integrate Fledge with various destinations. So for instance, OMF is a protocol to a Py Historian or Google has contributed both IoT Core and Google Pub Sub to send it into Google Cloud or you'd have the various common and universal protocols you'll find in industrials like OPCUA or MQTTT or of course even protocols you find in IT like Kafka then to integrate that data, format that data, transform that data and send it on its way. And then in Fledge, you also have a service for doing set point control. Of course, this is a Linux project. And so it's good for set point control but it's not an RTOS obviously. So doing things like writes back to an MES system or writes back to a PLC based on some PID function and changing how this machine operates. And then the next microservice where we can do events and notifications. And then the last microservice is value, administrate and manage Fledge. All of this in REST, all of it using REST APIs, all of it of course open APIs or anyone then can go in and configure and manage these Fledge instances. And so my last two slides when I talked about pipelines I wanna give kind of the flow of common types of applications that have been built with Fledge. And this is doing with no code, low code or source code types of application building. So typically you might have PLC which would be time series data coming from this machine. You might have an infrared camera connected to that. So the plugin would be Jenny Cam and you're actually processing the array data. And then again, you might then have an accelerometer where we're actually taking vibration data and doing RMS and FFT signal processing as the data flows from machines and sensors. It can then be processed with machine learning on the edge and then integrate it to the cloud or an OEE system like Appiah Historian as these flows from machine to cloud are managed using Fledge. And then the last slide I have the largest deployment of Fledge today has about two and a half million tags flowing. And this is an implementation of a large chemical processing plant here in the United States. They had about 250,000 LoRa sensors deployed across 120 plants. All of that was being aggregated to about a dozen MQTT servers. And the problem was this is about a five year old deployment the formats of how these sensors from different manufacturers and the different data formats they have and how that was all aggregated in MQTT was very specific. But they always wanted that information or that data in their PyHistorians that the operators were using on a per plant basis. They couldn't figure out how to integrate the two. So in this case, the pipeline is actually cloud-based. So the MQTT servers flow their data into Fledge with our MQTT plugin. We do a data transformation where we can automatically identify, for instance, a new topic in MQTT. We can then process that new topic and send that data all in its way to the historian and understanding the format of the scheme of the historian automatically transform that data from this MQTT of a new topic and integrate that into the right historian at the right plant in the right format to the right operator. And those would be typical Fledge deployments. And with that, we're trying to build out a very large open-source community in the OT space. One of the things we've found in the OT space that actually in Linux itself is a new, is new to them. As you may know that Microsoft has done a very good job with OPCDA and is really a dominating technology in the OT application space. So we're hoping to build a very large community in OT, bring Linux into it and build these smart, intelligent data pipelines from machines to the cloud with open-source tools and processes. Thank you. Excellent. Thank you, Tom. That was very insightful. And if you can stop sharing, which will be on the screen. There you go. Okay. Very good. Again, to the audience, if there is any question, please put them in the Q&A box. Tom will be able to answer them in real time. I do have one quick question and this has to do more with the southbound. Like for the networking crowd, it's generally easier. I wouldn't say it's easier, right? It's either 5G or broadband. And yeah, there are protocols and all that. So not a big issue from a connectivity perspective. But for Edge and even more importantly, IOT, as we move into the extreme left constrained edge, as we call it in LF Edge, the protocols and the physical interfaces are quite prolific, right? And part of it is because each vertical has a physical requirement of hardening or compliance or whatever, right? And then of course the messaging protocol. How do you see that world evolving over time in terms of bringing, I mean, that's why frameworks are there, I'm sure. But what do you see needs to be done or should be evolving? Yeah, well in the industrial space, as you said, there are right now probably over 120 southbound protocols in the industrial space, a bunch of them that you and I probably never even heard of. And so that's the first issue. Often you can connect to those protocols using ethernet, sometimes not. Some of these sensors you actually have to do an analog conversion through some sort of ADC or signal process to actually interface that data. So that's the first problem. That's a problem that's been around in the industrial space since 1995. And there are commercial products that solve the protocol conversion. Basically, I'd call it a multi-protocol gateway. It goes from this to this. And then the next big issue besides that, and people are starting to standardize around probably a dozen protocols going forward to answer that first question. The other major problem in industrial is there is no data standard for a machine. This man's pump versus that man's pump. Just because I have OPCUA does not mean that I can move that data from this OPCU APLC to this guy sitting over here. I need to understand the pump. I need to understand the data formats, the schemas of that pump. And then I need Bill to convert that. So that's the first transformation that's critical on the edge. And then Fledge can handle that. So it's both a protocol problem and a data translation problem today. Very good. No, I think this is why frameworks are so important and critical, especially in this space where there is not a lot of memory or compute power to go in, right? Like what are the smallest deployments you've seen? Well, we've put it on Raspberry Pi zeros and actually deployed it on that. So it's anywhere from that. So Fledge of course can run on hardware like a Raspberry Pi, but in a VM or in a container. And you are seeing a lot more containerization also even in industrials pretty far out on the edge. Like a Cisco, we've deployed on Cisco switches in Cisco containers and substations. Okay, good. As another mechanism, sure. Got it, got it. No, excellent. And I think the last question, again, for people who want to ask questions, the Q&A bar is on. The last question I have is, you've been working very hard in the Fledge community to collaborate with LF Energy and the energy projects, right? We heard from our colleagues in APAC yesterday in keynotes that edge computing plays not just an important role in new applications like the cool stuff, AR, VR, blah, blah, blah. But it is an extremely important technology for marching towards the green revolution that we want to go to as a global community. So what are some examples that you have been focusing on just as a quick overview? Sure, two of the examples that are contributors to the project. One is RTE, which is the largest TSO in Europe. TSO, there's three parts of energy, there's generation, there's transmission and there's distribution. And so they run the big wires that transmit from generators to distributors that you probably... For my networking audience, core, edge and access. It's really similar, it's very parallel. Yeah, I went to Novell, I think I wanted something else. So they're building, actually a legacy protocol into FLEGE, it's IEC 104. And it's used in their substations and it will be because another problem in industrials is the CAPEX expenditure. They're buying assets the last 20, 30 years. And so they have what are called RTU servers, which are actually the switches in the substations that use this protocol 104. They need it to work with this emerging protocol called 61850, which is the newest protocol in green energy products from Siemens, ABB and Schneider. And so they need a universal way to go into these substations, control the old stuff with the new stuff. First thing they're building is IEC 104 as a south plug into FLEGE. Nice, nice. Okay. I know there'll be a lot of questions. I mean, this is a fascinating area, IoT and IOT particularly. So really appreciate your insights and thank you for giving us a great overview of FLEGE. So thank you, Tom. All right, thanks, Arbett. Take care.