← Industrial AI Podcast
Industrial AI Podcast
Governed Autonomy: Why Edge AI Needs Guardrails
00:53:27
Discover how local policy enforcement is reshaping industrial AI safety. What happens when your smart machines lose their connection?
Loading summary
Transcript55 lines
- [00:00]
A
This podcast is presented by nxai, your partner for Time series, foundation models and physical AI.
- [00:19]
B
Hi there. Welcome to a new episode of the Industrial AI podcast. My name is Peter Seaberg and I'm your host. Today I'm going to be talking to Steven Yates. He's the co founder and CTO at Federent. Steven and I are going to be talking about governed autonomy for hai. Hi Steven.
- [00:40]
A
Hi. Good morning, Peter. Thanks for having me on.
- [00:43]
B
You're welcome. Please introduce yourself to our listeners.
- [00:47]
A
Hi. So yes, I have. I'm Steve Yates. I have 38 years of experience professionally in embedded and edge computing, industrial controls. Actually though before that I started building computers 49 years ago at the age of 14. So. 49 years ago, sorry. At the age of 14. Yeah, sorry. It's been a long time. It's easy to lose track. So I'm an engineer by training, formerly a hardware engineer at intel and GE Fanuc. Before founding my hardware design house, ADI Engineering. I bootstrapped over time from a pure service company into a high volume white label white box, rather private labeled OEM serving customers, tier 1 telecoms and computer OEMs that was acquired by Silicom back in 2015. And I'm a registered professional engineer in the state of Virginia, an IEEE senior member and hold 20 US patents. I co founded Federant back about a year and a half ago with my longtime friend and colleague Tony masters, who is CTO. Actually.
- [02:03]
B
49 years experience, that's a lot. We're not going to be talking about each of those stages. We're going to probably concentrate on the final stage of the one that you've been talking about until today. But I do want to start actually with going back. I'm not sure what the numbers of years are. You don't have to share that. But I do want to talk about PLCs and I want to talk about specifically designing them. Because that's one of the things that you did at GE Fanuc. I think you mentioned it and I read somewhere that specifically you were involved or you were the Designer of the System 9030. Tell us about how that was. What was that? What was that? Designing that PLC at that time?
- [02:53]
A
Yeah, so actually I was early in my career a hardware design engineer at GE Fanuc and I did work on a couple actually. More specifically I was designing or helping to design ASICs for GE Fanuc for PLC CPU and I O modules, including the 9030 and 9070. So I think it's very interesting actually to have that kind of perspective and that kind of experience, because I think we're seeing things now with AI entering the physical world, entering into critical industries where, frankly, I think the industry has forgotten about some of the foundational design principles that kept industrial systems safe and reliable and trustworthy. And I think it's urgent that actually industry get back to those. So some of the things are just authority, autonomy, determinism, have to live locally. They can't be dependent on a link or a connection or a cloud service or other things that aren't guaranteed in the real world. And so with a plc, determinism and authority. And I use the word governance a lot, by the way. I use it a little differently than a lot of other people, especially in the age of AI, use it. But, you know, all of these things lived literally in the same cabinet, even in the same rack. You know, they, they didn't live off site, they weren't separated by a link. The system was safe and correct by design, free from external dependencies. And that's just a bedrock principle that in the age of, of AI, the industry has, I think, forgotten about.
- [04:44]
B
And I probably have been one of those persons who did forget. If you ask my co producer, Robert, you know, I've been talking about EDGE for at least 5 years and I've been talking about the importance and etc. Etc. But I may have been one of those persons forgotten the basics of. And that's why we're talking about them now. One more thing, you mentioned intel as well, and I've been with intel as well. Now that's not. But the reason for coming quickly back to that maybe is that we, we talk about OT it all the time and I haven't been part of it until myself and I haven't been talking about Gordon Moore. And that was the time of Moore as well. And always going back to the 4004. Now I think the date we're talking is 1975. And then I was thinking, now who was first it or OT? So I, I would say the birth of it was the 4004 was a microprocessor now. And then I went back and I found out, and I assume that you maybe can share a little bit with us there, that I understand that the first PLC was Dick Morley's Modicon 084. Now that was for General Motors. I understand maybe, maybe you can share. But what I understand is that that was not a single processor. Right. So when you say that you were designing asics, that is kind of supporting this idea that they were still Discrete logic elements rather than one microprocessor as it was later on then in the IT world.
- [06:20]
A
Right, yeah, I'm actually not quite that old, but. No, no, no, that's okay. I've actually learned to embrace my experience and age starting an edge AI company. I think it's an asset, so I don't hide it. I'm not offended. No. To be clear, when I was designing or helping to design PLC CPUs at GE Fanuc, the purpose of the ASIC wasn't to replace a microprocessor. In fact, the 9030 had a 386 class processor from intel in it as the main CPU. The PLC was really. There were several PLCs. And you know, these memories are a bit dusty, so I may get some of the details wrong. But, you know, some were just responsible for system control, memory control, I O control. But a lot of the functionality that was really important was interfacing to the backplane, to other IO modules or other modules, rather inside of the 9030 backplane system. So they were implementing what at the time were proprietary GE Fanuc communications protocols and backplane interfaces. So. But I think you're right, the 4004. And actually, I have to say really quick, when I was at intel, they celebrated their 20th anniversary. And there was quite the celebration of that event, actually back then, one of the things that intel produced was a poster that was hung up at every facility that had the name of every intel employee. And it was, I can't tell you as someone who started building computers at 13, what an incredible moment it was to see my name at the very end in very small print, but on the same sheet of paper as Ted Hoff and Andy Grove and Robert Noyce and Gordon Moore and all of the other titans of the industry that founded and built Intel. That was quite the moment.
- [08:21]
B
We can talk for hours and we shall do this sometime when we meet, because I was there at the 25th birthday anniversary in Silicon Valley, actually, which means I probably was not there at the 20s. So you may have been there a little bit before me. Yeah, we can, I'm sure we can spend hours on that amazing time that then you and also I a little bit later spent with those guys.
- [08:44]
A
Yes.
- [08:45]
B
Let's come back to you. You gave a quick introduction and tell us about exactly the authority. You use the word governments and you use it exactly for or this shop floor OT architecture with the PLC in the center and how that kept. And it still keeps, I assume, you know, 99% of all of our Installed, base production authority, local.
- [09:09]
A
Yeah. So I do use the word governance and I've tried to come up with a different word or better word just to avoid confusion, but frankly, I haven't been able to come up with a better one yet. So in the age of AI, when most people use the word governance, they're talking about sort of corporate boardroom type governance, AI ethics and corporate policy compliance and things like that. When I talk about it, I'm talking about runtime governance at the point of action. It really means enforcing policies, making sure that operational boundaries are not exceeded at the point of action without external dependency. And external dependency, again, includes constant connectivity to some sort of a cloud control plane. If you look at how edge AI is architected today, usually what's partitioned to the edge and what runs at the edge is inference. And that's wonderful. It's a great innovation. I don't mean to be negative about it in the least, but inference is not the same as governance, you know, a system. And there's numerous examples of this that are starting to emerge. It's still kind of early days for industrial and physical AI that make consequential decisions in the real world, but there's numerous analyst reports that point to this as a major and urgent issue. And we're starting to actually see some real incidents that are occurring in the real world as a result of it. So kind of the idea is that operational boundaries have to be enforced at the point of action, not at the far end of a link. And this becomes especially urgent as operational decisions are no longer deterministic. They can actually evolve independently from other nodes, at fleet scale, or independently from the cloud. Prompting is not governance. We've seen numerous, and I can go into details if you want, where prompts don't assure safety. And so there is the need for architectural enforcement that the system just can't override, like a plc.
- [11:19]
B
Now, I do want to go into more detail there, but I share with us, I could do that, but I want you to, because I've been talking, you know, ads for five years. But you tell that from your experience as you've been following the development of the architecture. Why have we been moving maybe sometimes instead? Five years ago, especially in Europe, nobody wanted to go cloud because they were always that. That's what we called at Intel. I'm not sure if that's a term you had at that time, our crown jewels. So you're you. You wouldn't put your crown jewels outside, so to say. I think that's been changed all of that has been changing a lot. But nevertheless, tell us, why are we, why have we, why has the market been moving to edge, maybe in addition to cloud? And, and then let's move into what potential problem we maybe introduce by doing that.
- [12:19]
A
Yeah. Oh yeah. There's many different motivations for the industry to move to edge. Many of them we've talked about for quite a long time. Latency and data sovereignty and geolocation concerns, resilience. But there's others as well, right? Numerous times. We just can't afford a round trip to a data center in terms of energy, in terms of time, in terms of cost, or even just coverage. So edge AI specifically. And when I talk about edge anymore, you know, I have a long history in edge networking and edge compute anymore, my brain, when you talk about edge, just immediately goes to edge AI. It's really about solving, you know, solving tough problems where a cloud first architecture isn't suitable. If you look at how AI has evolved to this point, and it's a wonderful thing, I'm not being critical. It has evolved in a cloud centric way in hyperscalers running in large AI data centers. And that's a wonderful architecture for what I call digital AI. It's AI that exists in the information domain. It's chatbots and LLMs, it's corporate tools, design tools, coding tools. Right. I mean, we all use them all the time and it's been foundational to the success of AI. So it's a, it's a wonderful thing. But you know, hyperscale data centers have, well, I hate to use the word perfect, the engineer in me hates that word, but indulge me a little. You know, they have as close to perfect connectivity as you can get. They have, you know, assured power nearby or on site support technicians, essentially pristine sort of laboratory grade environments where the real world doesn't rear its ugly head very often. And you know, that's fine if what you're building is a customer support tool or a chatbot or something like that, but if we have UAVs or autonomous robots on, you know, infield robots in agriculture or military systems, or autonomous haul trucks in remote mines, you know, we're taking an architecture that was developed for office applications and deploying it in pit mines or battlefields. And you know, you certainly wouldn't move your office into the middle of a pit mine or a battlefield. So why are we moving our office AI architectures there?
- [14:57]
B
Let's look at a couple of examples. Maybe take us by the hand and tell us why not what is happening, what have we been doing without realizing? Well, without, not everybody, but you know, maybe including myself, realizing what it is that we have not taken care of. And maybe we start with one example that has been completely obvious to me. It must have been like 15 years ago, I think it was University of Stuttgart and they were showing this example of running the shop floor through a cloud. You know, I really say 15, it may have been 20. And that's, everybody was like, oh, that's impossible, you cannot do that. You know, if there's a small glitch in the network. So maybe that's one example of where we are not certain of what we're doing. And maybe you can explain that. What happens to authority and governments by moving to the edge.
- [15:52]
A
So when authority and runtime governance live in the cloud, when access to the cloud is not available for whatever reason, right, it's an outage under your network provider's sla. It's an authentication problem or even account problem logging into the cloud. It's some force majeure. It's the real world rearing its ugly head. In those cases, your AI can still run, it can still run inference workloads at the edge, but now this non deterministic AI is operating essentially on its own, independently. And I can point to some specific examples, but let me just explain generally first. So it makes decisions, its state evolves based on inputs, based on data, based on circumstance. And across a fleet of nodes, states become divergent. And there's no way right now, no standard way to reconcile those divergent states upon reconnection, to make sure that operational decisions are within allowable or safe limits. And this problem is becoming actually again, we're at early days of it, right? But the problem is about to get a lot more urgent. The EU AI act in August, now just a few months away, requires high impact systems to keep continuous logging, continuous attestation in terms of decisions AI makes to allow for continuous human oversight. There's no allowances for 99.9% network SLAs, which sound good on the surface, but essentially it's an admission that you're 0.1% non compliant with the EU AI Act. It doesn't have provisions for force majeure, by the way. It's like me saying I'm only going to be reading my phone 0.1% of the time while driving. It's absurd on its face and right? No, no, my driving has to be correct by design. I have to just not use my phone while driving, period. It doesn't matter how little or how much it is it to be zero. So there are some examples actually and I have an upcoming article coming out, probably can't say where because it hasn't been published yet. But you know, in the next few months. A couple of the examples I point out in that are one, there was a BHP mine in Queensland, Australia where an autonomous haul truck actually lost connectivity with central controller. An operator exited the haul truck, the haul truck then reestablished connectivity and around that time resumed motion and actually collided with an excavator. Now fortunately no one was injured and there wasn't serious property damage. But that transition from connected and governed to unconnected and ungoverned and back led the mine truck to autonomously decide to resume motion and, and that resulted in a collision because its operation wasn't governed. There was nothing, you know, limiting its actions and saying that that was an unsafe action. And this is the type of scenario that is according to a Deloitte survey or rather white paper that was just published called I think it was Physical, the Moment of Acceleration. It came out a couple of months ago. It's a great, great read. They've identified this governance gap as a key element that is about to become a major issue with physical AI. And of course physical AI is AI that makes consequential decisions in the real world. You know, it touches atoms, not in a nuclear sense, but in a physical sense. And they've said that governance is an emerging dimension that has not been solved yet. Well, wait a minute, GE Phanix solved it with PLCs. Admittedly they weren't AI, right? Edge AI didn't exist. But GE Fanuc solved this, you know, decades ago. The industry solved this. The OT industry solved this probably starting in the 1950s. I mean there was Relay Logic that controlled industrial machines decades before there were such things as microprocessors. And I get it, right, that's not AI. It's a little bit apples to oranges comparison. But the thing is the real world, the requirements for the real world haven't changed over those decades. Right. You know, if my, if my Claude query fails, I can just retry it. It's an inconvenience. Recently there was a software startup, I believe their name was pocketos. This is public information, well known story where AI and agentic AI workload actually deleted their entire production environment because it decided autonomously that was a good idea. Even though it was prompted specifically not to take any destructive actions, it decided to. Now, you know, that was kind of a I'm sure a. Oh, crap moment. Fortunately, they were able to restore it from a backup. But, you know, an environmental release can't be restored from a backup. An injury can't be rolled back. You know, a severe economic loss because a plant shut down or a chemical reaction, you know, the control mechanism stopped. Well, the reaction doesn't stop. Right. So the needs of the real world haven't changed. What's changed is how the industry now is starting to control it. And it's being built on an architecture that just was built for office applications. And not to repeat myself, that is the gap in a nutshell.
- [22:02]
B
All right, so let's move towards a solution. Just so I don't forget you mentioning the, the EU AI Act.
- [22:13]
A
Yes.
- [22:13]
B
We have not always been hearing so many good things about this act, but it's, it's interesting and I'm sure you didn't, you didn't start with what we will be listening to your company and your thoughts. I'm sure they have been coming as they, as they came and. But then you are aware, you must have seen somewhere. Oh, look at that. EU AI act is expecting exactly what today is not available in the market. So tell us what is then. Where do you see the solution to the problem that you've been describing?
- [22:48]
A
Yeah, and by the way, I'm certainly not a lawyer, I'm not an attorney and I'm not an expert on the eu AI, but it is noteworthy that this is becoming an issue and there's similar regulations that are starting to emerge, not just within the eu, but I think certainly in the US and I think soon, globally. So, I'm sorry, could you repeat the question?
- [23:15]
B
Yeah, so we're moving towards the solution here. You were pointing back to the plc.
- [23:20]
A
Oh, right.
- [23:21]
B
Very much. Yeah, but. Yeah, but. And I'm looking forward to hear from you. What is, what is the solution? As you said specifically, you do like the edge and it's. You're not, you're not against it at all, but you're pointing towards this problem that we have of governance of. I'm not sure if I can put it in my word. I think it's almost like if, if all these edges are little islands and they are connected to a central place, to a cloud, and if one of these islands get disconnected and you gave an example of the truck and suddenly it starts doing its own thing because it is not coordinated anymore. Maybe that's in my words, I don't know. So what is the solution that you, with your company are coming up with?
- [24:11]
A
Yeah, I mean, I think there's four key capabilities that are needed to form the solution. It's not just one thing, it's multiple things working in concert. So first of all is the idea of local policy enforcement. And another way to look at that is local boundary enforcement, something that the system can't override, something that's baked into the architecture and essentially to replace the plc, or I shouldn't say replace, scratch that word, augment the PLC. In the age of edge AI, PLCs will retain a place. But the issue is that edge AI agents can actually make autonomous decisions that PLCs can't govern. A PLC looking at actions would see individual actions that may still fall within boundaries that it's been programmed to enforce. But at an operational system level, the overall consequence of those actions is something unsafe. So local policy enforcement, architecturally that the system can't override, that's number one. Number two is cryptographic decision attestation that basically proves what happened at the point of action, not dependent on external things or cloud access or networks or anything else. So cryptographic decision attestation. What model ran, what model made a decision, what policy authorized that decision to be made? What was state when that was made? The third thing is operational boundaries at the point of action. And the fourth thing is reconciling that upon reconnection. So partition aware, reconciliation of state. When there's divergent states, this becomes a large scale autonomous systems problem. So partition aware, reconciliation of divergent states upon reconnection, and of course none of this matters at all unless the system is easy to deploy, reliable, secure. The types of industries that we're mainly serving right now in our early days of Federant are critical. Remote industries and agriculture. So these are environments that are austere, where there is very limited AI or IT support nearby. And so the systems have to be, the solutions have to be easy to deploy, remotely manageable, and by the way, remotely manageable. I know I'm implying cloud, so let me clarify a little bit about cloud. I am not anti cloud, I am not anti telco. Right? I'm anti dependency, and I'm anti misapplication of architectures to areas they were never designed to apply to. That's what I'm against. The cloud is actually essential, it's fundamental to what even we are doing. But we're recasting the role of cloud a bit at the far edge to become augmenting, to become supervisory and not blocking, to become optimizing. Instead of a time critical dependency that is necessary to assure safe and compliant and reliable decisions at the real world. So that is what we're saying needs to happen, is the role of cloud doesn't even need to be totally redefined. There's a missing layer to provide these things at the edge. And that's essentially what Federant is building. And we could talk about that a little more.
- [27:59]
B
Yeah, tell us about that. Tell us about veteran. And I'm going to ask you specifically, when I saw the word veteran and again last night, and when we talk about these things, what comes into my brain is like industrial, industrial grade. And Boris Schieringer, who I believe introduced that term, we met last night and we talked about also again, specifically here about federal connections. So when we, and, and when we talk about, for example, Germany, it's the Federal Republic of Germany, and when we talk about federal AI, we mean that the algorithm is coming to you, to your data, close to you, maybe on the edge, rather than sending the data into the cloud. Now your reaction is saying, interesting, says maybe it was, maybe it's not related. But you tell us, tell us about fedrant. When did you start fedrand? And then I think we hear what it is you're saying, what you're working on today, and then maybe going to the specific solution that you have to the problem that we've been talking about.
- [29:09]
A
So that's interesting, what you said about federal AI in Germany. I wasn't aware of that. So thanks. I'll have to actually study that, read about it. The fact that our company is named Federant, maybe as Bob Ross used to say, is a happy little accident.
- [29:24]
B
I suppose
- [29:26]
A
it's not purposeful, but maybe that is itself a signal. Right. So the idea for Federant, or the name for Federant rather, is that we're federating operational governance with the edge, with connectivity and with operational ease. So we're federating things. We're the one who federates edge AI, therefore Federant. That's just kind of where it came from. Plus, you know, logistics, you know, silly things. The domain was open. It looked like we could get trademarks, which we have now. So, you know, it passed our legal due diligence. Okay, so the idea came. Well, we started it unofficially. I started it as actually an extension of a personal project I was building about two years ago. I'm a longtime Starlink user. I have some remote property where I've had Starlink for four years. I actually have a good German car, a sprinter, Sprinter van, I guess, if you can call A sprinter, a car.
- [30:35]
B
And I'm going to ask you very specifically, I was going to do it later, but tell us now, because I read about that and being a camper myself, I read this about this post and you go into as much detail, as little as you want. And although it's about Starlink, the Starlink dish, and I was looking into going for Starling as a camper as well. Tell us about your experience. And although that is, I believe, an experience as a consumer, so to speak, I do believe that all of us, because I did understand what that did to you in a private environment and in how exactly the same way that could do specific things in a business environment.
- [31:22]
A
Yeah. So, you know, I love the outdoors, love camping, love seeing things. And I need to stay in contact. I need to. I sometimes work remotely. Right. That's the wonderful thing about how you build a company in 2026. Although, frankly, I built my first company in the 90s. Remote, we were ahead of our time. But connectivity is key and even in developed nations, even in the U.S. i just posted a blog post, or, sorry, LinkedIn post this morning about how I went to the EU embassy open house tour in Washington, D.C. last week and standing on embassy row in some of the most expensive real estate in the us I could not get a usable cellular signal to navigate back to the Metro. I had to literally walk inside the Hungarian embassy and use their guest network to find the nearest metro station. Which is amazing.
- [32:21]
B
So that's amazing. People would have thought it would be the other way around, right?
- [32:25]
A
Yeah, yeah. I had to rely on a foreign government's connectivity in the capital of the US to find my way to a metro station. And, you know, this is the network that we're building, building edge AI on as a critical dependency. Anyway, so my Sprinter, I've had a first generation flat, high performance dish on the roof of my Sprinter. I can share notes about how I did that, you know, offline, if you're interested. It's a little off topic for this, but I installed it myself. I actually put a hole in the roof of my Sprinter, you know, which was a fraught moment, sealed it up, you know, all's good, it hasn't leaked, it works. I have a solar panel up there. And so, you know, Starlink was a. Was a fantastic way to provide connectivity anywhere. But as I found out after installing it, anywhere means anywhere other than parked under a tree or parked under a balcony or driving under a bridge or in a tunnel or any other obstruction. And the obstruction can actually be surprisingly Light or small, it doesn't have to be a thick tree canopy, it can be wispy pines. You know, frankly I'm not an expert in terms of the communications, but there's not the link budget. Right. And to keep latency down, I'm sure the amount of forward error correction is less than say with other types of broadcast based satellite services, you know, DirecTV or Sirius XM or whatnot. You know, the modulation order is higher and so forth. Right. So the link is less resilient. Now Starlink is a wonderful invention. I'm a big fan. I've been using it for years and you know, it has continued to get better as more satellites have launched. But still, you know, I was camping recently in central Florida and there was a light canopy of pines, tall sort of wispy pine trees, not like firs, but you know, they only have pine needles at the very top. They're common in Florida. And even with that I could see blue sky. Even with that, I got with again, this is my highest performance Starlink dish with the best business plan they offer with a guaranteed SLA. I got a 93.6% ping rate which was perfectly adequate for office use, for cloud use, for email web browsing. Perfectly, perfectly adequate for that. But you know, 6.4% of the time I didn't have a connection. And those outages ranged from seconds or actually, you know, they range from, you know, tenths of a second, but they, they were 10, 15, 20, 30, 50 seconds. Right. And so the connectivity is ubiquitous, but it's not as reliable. It doesn't have, you know, old school telco grade reliability. The Starlink SLA for business service is 99.9% which sounds good. And again, it's an amazing thing that they have invented and deployed. But if you read the fine print, the 99.9% excludes outages under 60 seconds. They don't count at all. A 59.9 second outage doesn't even show up as an SLA violation. And of course like all SLAs, it excludes force majeure. So you know, snow on the dish, heavy rains causing rain, fades, obstructions, you know, the fact that your installation is under some sort, or not even under there is an obstruction in the field of view. Those things aren't covered. And so that got me thinking, okay, you know, it's ubiquitous but not as reliable as terrestrial. And this is the connectivity that many remote industries are going to rely on. The reliability will continue to get better with more satellites, but it's never going to be 100%. And the point is that this isn't a connectivity problem that industrial AI is facing at the edge. And I think the industry is looking at it primarily as a connectivity problem. It's an architectural problem. And so that's where the idea from Federant came from. A personal project.
- [37:03]
B
Yeah. And I thought that very convincing. Yeah. And interesting how you say not always do you have connectivity at all? And for that reason I was looking also at Starlink. Oh and by the way, I could tell you this one moment where we were camping and we saw these. We believe we were being invaded by marshmen. And what they were, they were these starlings. But they come in a row.
- [37:28]
A
Oh yeah.
- [37:29]
B
They come in a row of 20 and we were camping and we really thought we were being invaded. It was amazing.
- [37:35]
A
Oh yeah.
- [37:36]
B
It's a complete different topic. We have, we have so many topics that we should be talking about offline.
- [37:42]
A
Yeah. I've seen a Starlink training before and it's, it's a little unsettling. If you didn't know what it was, it's. It would be a little unsettling. Unsettling, yeah. Right.
- [37:52]
B
Now tell us about the Fadrant edge platform, how that is different from cloud anchored solutions. What are the different modules that you have? What is the solution that this is providing to solve the problem that we talk about.
- [38:12]
A
Yeah. So there's three different elements to the solution. And let me also add real quick. Open source is important to me personally. It's important to us as a company. I think it's important to the industry as a foundation to build on. So two of the three products are actually open source or maybe I shouldn't call them products. Two of the three elements in the platform are open source. And I'll be blunt, we've had a great conversation. We're not open washing them. These are legitimately open source to try to enable the industry. So the open source elements are actually being promoted and provided under the base called Federon, you know, kind of like a particle of federation if you will, like a neutron or electron. So Federon is the brand of our edge resident hardware and software that is open now. There's two elements to that. There's a hardware component and a software and firmware component. Hardware isn't or custom or I should say, you know, optimized. Hardware isn't 100% mandatory for the solution to work but to get the most out of it, it's very helpful. And we couldn't find, you know, off the shelf hardware that had the right combination of features and I could be happy to describe what they are. So after having built and bootstrapped and survived the acquisition of my hardware company achieving a soft landing, I kind of swore to myself I wouldn't do another hardware company. And so here I am. But we're having to so the Federon Base is our rugged open hardware reference design. It's a production ready reference design and reference architecture. We are developing it, we are producing units for people that want to buy from us. But we're not doing so in an exclusive way, frankly. We're doing it to blaze a trail. We're doing it to generate proof points to the ODM and OEM community to build demand signals that will allow them to actually supply differentiated families of compatible devices. And I've worked with the global ODM community in the past at scale with past companies. Something I didn't say about intel with my design house and OEM product company called ADI Engineering is that we did over 50 contracted projects to Intel's Edge Networking Network Processing EDGE group where we developed reference designs for new Intel SoCs between one and three years between or before product launch. And these designs all were designed to and intended to enable the ODM community openly. So my DNA for products is open through and through. So anyhow, Federon Base, it's meant to blaze a trail, it's meant to engage the ODM community community and you can buy from us. The second element is the Federon os. It's an Edge first open source operating system. By the way, I think the word OS or the phrase OS is highly overused. So again, I was a little resistant to use it myself, but I truly think it fits and it's the best descriptor. So we're calling it that, acknowledging that it's a bit overused, but we think it actually fits. So this is resident on Devices at the Edge, our current version of it, it's based on Ubuntu. I could go into more technical details if you're interested. I won't right now, but it's the edge first open source OS that really embodies all of the partition tolerance and reconciliation and autonomous disconnected governance. It's the mechanism by which all of that happens. And then our commercial product is called Federant. It's under our own brand since it's a commercial product, it's called Federant Assure, which is commercial fleet governance. And it does run on the cloud, right? I mean again, not anti cloud, it's just that the cloud has to be a bit recast in terms of its role in far edge AI. So that's the three elements of the Federant architecture. Let me also say that on the topic of open source that it's a little premature for me to go into a lot of details here, but we are actually working with a leading open source community establishing a work stream that is, how should I say, trying to standardize in an open and collaborative way the idea of deployment, security, governance, reliability of edge AI in the real world. And you know, this is a. It's not officially approved yet to be clear, but it looks like it's heading that way. So I don't want to say a whole lot about it other than this would accelerate our strategy and would provide a focal point for, you know, serious and authentic open community co development and standardization. And we're very excited about that.
- [43:51]
B
Very good. Let's go back to the example where in my words, there was this truck that lost connectivity. The operator left the truck and at some point in time the truck, the autonomous truck, decided it was time to start moving again and run into another truck or whatever. So.
- [44:11]
A
Yeah, and an excavator.
- [44:12]
B
Yes, right, excavator. So if in the future this company would be using your solution where exactly? Maybe in one of these three modules that you talked about. And what specifically is it that will make sure that this will not happen?
- [44:33]
A
Yeah, so on the truck, on the device itself would be something like the Federon Base. With the Federon os it would have a processor that can operate independently and autonomously. But when connectivity is lost, because you know, in a large scale pit mine in the outback or wherever, the loss of connectivity isn't really a failure mode, it's just operational reality. It happens. Right. So let's don't pretend like it doesn't. Anyway, so that would assure, that would enforce policies, you know, I don't know the exact precise policy that was violated in that. Right. I don't have, I don't have access to the detailed reports. But a policy would be when, you know, upon re establishment of connection, you know, don't automatically restart motion, you know, perform safety checks, make sure interlocks are, are resolved and establish a condition there where motion isn't resumed after connectivity loss until certain criteria are met. Or better yet, you know, another policy would be, you know, when connectivity is lost, you know, here is a, you know, safe mode. Here are certain actions that are authorized, you know, only do these. It is possible that you could just simply shut down and wait. The problem is for a lot of autonomous systems. You know, maybe for a mine truck, shutting down and waiting actually would be the best policy. But for other applications, connectivity loss, shutting down and waiting for reconnection isn't. You know I mentioned a chemical reactor or a uav. Right. A mine ventilation system, you know, shutting that down if connectivity and authority is lost isn't a safe action. So that's what would happen. Right. The Federon base running the Federon OS would have a set of predefined policies that establish the surface area of what is acceptable and safe operation and restarting motion of the mine truck without resolving every safety condition. Operational condition interlock would be specifically prohibited.
- [46:57]
B
Very good. So let's. We need to come to a close here. If not, we could, we could talk for hours now. Don't want to. Almost like assuming you have maybe an X call as well here. So assuming that we will be that you're going to have customers using your solution as without the exception of your product. It's, it's going to be open source. Other companies working on a similar. On the same or similar solutions so that we start recognizing the problem and we start providing solutions. What is that going to do to the total market in which we are operating of cloud solutions, of data centers, of Edge? How do you see that developing which could not have developed that way without solutions like yours putting into the market?
- [47:56]
A
Yeah, I think if you didn't have a solution like this, you have the status quo. And right now the status quo is that. I don't want to misquote statistics, but it's a surprisingly high percentage of pilot deployments of Edge. AI really never make it out of the. The lab. I think it's in excess of 90%. So yeah, it's shockingly high. And the issue is that things work in the lab. They work in a pilot. You put one or two test systems out. By the way, we have our first test systems out too. But we're not pretending like they're the complete answer to everything. Right. They're just the start of discovering how this works in the real world. But anyhow, you put a few test systems out and you're getting positive results and then you try to scale. And I think I was at the Edge AI foundation summit in San Diego a few months ago. There was a representative I think from Zedita or another company there. Great company. Right. And his comment was that inference at the edge is like 5% of the challenge. The 95% is the operational ugliness of actually running things at the far edge. And so I think that's what you'll see. And again, Deloitte has talked about this. There was a recent report from the Edge AI foundation and Wevolver about State of the Edge. They actually spent quite a bit of time talking about DDIL environments and how they impact edge AI. By the way, DDIL is an acronym which is, I believe it's denied disrupted, Intermittent and Limited environments. It's more used to refer to defense type scenarios. But I think the industry is finding out that all it takes for a farm or a mine or a disaster zone to become a DDIL environment is a connectivity drop. A tree that's blocking your Starlink signal, a backhoe that cuts fiber. Right. As you build critical dependencies on the cloud, all of these things become detail environments. So anyhow, that's, I guess that's what we're seeing.
- [50:13]
B
Very good. Steve, tell us about your team. Where are you based? Are you looking for talent? Yeah, and if so, what should they bring?
- [50:20]
A
So we're, you know, we're in the U.S. the company is based in Virginia, although we have a distributed team. So we have a US team of senior developers and architects, obviously executives, marketing, sales and so forth. We have some international component to that as well. We're working with market leading, best of breed companies that bring specific domain expertise in India, in actually Ukraine. There's I think no one on the planet who has outside of SpaceX I should qualify, but I think there's no one on the planet who has better knowledge of how Starlink actually works and how the terminals are actually built than some really smart people in Ukraine we're always looking for people that are well versed in real edge systems. In industrial systems development. We don't have, I guess formal job openings posted at the moment. But these people are quite rare, they're hard to find and so we tend to be opportunistic and we'll, I hate to say create positions, but it's close to it.
- [51:41]
B
Nevertheless, if one of our listeners feels that they are maybe one of the persons you're referring to. Stephen, thank you very, very much for opening our eyes. Opening my eyes from the beginning as I saw what you were writing about, what you and your company are working towards it. As I said, I'm probably the first person who has not been completely aware of the potential of, you know, losing governance when moving to the edge. And thank you very much for bringing that to our attention and sharing with us the solution that you are working on and providing to the market.
- [52:22]
A
Yeah, thanks again, Peter, for having me on. I've really enjoyed the discussion. I hope your listeners get something out of it. And again, please, you know, if anyone's interested in joining the movement, and I do view this not as a product, almost not as a company, it's more of a movement that we're starting that we just happen to have a company based around. But, you know, if your listeners are interested, please feel free to get in touch with me.
- [52:52]
B
Very good.
- [52:52]
A
And we can have an interesting technical discussion.
- [52:54]
B
And you and I will make sure that we keep each other up to date. And maybe we're going to have the opportunity to talk to about our common time at intel number one and about camping and out camping camping sprinters. Stephen, thank you very much for your time. Have a great day.
- [53:12]
A
Thanks, Peter. Take care. You too. Bye.