Building a Foundation Model for Energy on Databricks with Applied Computing

Summary

Industrial facilities generate hundreds of thousands of sensor readings per second — temperature, pressure, velocity, and more — but only 2% of global compute is allocated to the physical industrial economy, which is more than double the size of the digital economy, representing a $350 billion per year opportunity from a 1% efficiency improvement.
Orbital, the foundation model for energy operations built by Applied Computing, is both physics-informed and domain-specific: it incorporates physics constraints that eliminate hallucinations in safety-critical contexts where general-purpose language models routinely fail.
The Databricks Data and AI platform provides the enterprise backbone for Orbital, ingesting structured and unstructured data from industrial historians and P&IDs, with LakeFlow Connect handling legacy OPC-UA and Modbus protocols and MLflow and Mosaic AI managing the ML pipeline.

Building a Foundation Model for Energy on Databricks with Applied Computing

Energy is arguably the most critical industry on earth, and yet the complexity of the processes and the implications of getting it wrong have been barriers to AI adoption, until now. this video will give context to the current challenges faced by the energy sector and explain how Orbital, the foundation model for energy developed by Applied Computing, can address those challenges by providing an AI model that is both physics-informed and domain specific. The session will also unpack how Databricks provides the enterprise-ready backbone for Orbital, supporting rapid data ingestion, creation, indexing, model training and more
Talk By: Bryce Bartmann, Head of Forward Deployed Engineering, Applied Computing ;

Chapters

FAQs

What is Orbital and what makes it different from general-purpose AI models?

Orbital is a foundation model for energy operations developed by Applied Computing, designed for the language of machines: time-series data, chemistry, physics, and operational plant context from facilities such as refineries, gas plants, power grids, and wind turbines. Unlike general-purpose language models, Orbital is physics-informed, meaning it incorporates physical constraints that prevent outputs that violate the laws governing the real industrial process — a requirement when the stakes include safety-critical decisions. This video explains why physics constraints are essential for eliminating hallucinations in industrial AI and how they are built into Orbital's architecture.

Why is industrial AI adoption so much harder than digital AI?

Industrial AI faces unique challenges because machines communicate simultaneously in time-series, chemistry, physics, and operational context — all inseparable and occurring at hundreds of thousands of sensor transmissions per second, continuously, for years. Only about 2% of global compute is allocated to analyzing this physical industrial economy, even though it is more than double the size of the digital economy. Legacy data formats, including OPC-UA and Modbus protocols, add further complexity to ingesting and unifying industrial data from historians and P&ID diagrams.

How does the Databricks Data and AI platform support the Orbital ML pipeline?

The Databricks Data and AI platform serves as the enterprise backbone for Orbital, handling rapid ingestion of structured and unstructured data from industrial historians and P&ID diagrams into a unified lakehouse. LakeFlow Connect manages ingestion from legacy industrial protocols including OPC-UA and Modbus, while MLflow provides lifecycle management, Mosaic AI supports model training, and the lakehouse architecture handles the messy, multi-format nature of industrial sensor data. This video explains why the lakehouse model is a natural fit for industrial data that traditional data platforms cannot unify.

What is the human and environmental cost of not applying AI to industrial operations?

According to this video, 330,000 people die every year in industrial accidents — and the sensor signals that predicted each event were present in unanalyzed data. A 1% improvement in industrial energy intensity would prevent approximately 380 million tons of carbon from entering the atmosphere without requiring new infrastructure or carbon capture technology. Additionally, 730 million people still lack access to electricity, and better use of existing industrial data could help close that gap by making energy systems more efficient and reliable.

Full transcript

[00:07] I'm Calum Adamson. I'm CEO and co-founder of Applied Computing. When they invited us to present today, they asked for our session to be technical. I don't know why they invited me, so I brought Bryce, our head of engineering. I'm going to spend two or three minutes
[00:20] though talking about why we're building a foundation model for energy operations. I don't think I need to explain what large language models are or how valuable they are. But I do want to pose
[00:32] three questions today, which uh which language makes the most money on Earth? Which language saves the most lives? Which language holds the key to saving our planet?
[00:49] Answer is the same for all three. The machines have been talking for decades, but we're only just starting to listen. We're only really able to start to listen now. This is the language of machines, and it's it's written in physics, it's written in
[01:02] time series, it's written in chemistry, and most importantly, it's written in context. But they speak all of it at once. They're inseparable. This is the way that reality actually works.
[01:15] Oh, let me skip back. And this is the language of cement plants, refineries, gas plants, power grids, wind turbines, you name it.
[01:32] Sensor data in these facilities is vast and high velocity. In a single industrial facility, hundreds of thousands of sensor transmissions every second. Temperature, pressure, velocity, viscosity, volume. Second after second for years and years
[01:45] and years. Machines telling us exactly what's about to happen in the real world before it does. So, I want to highlight what listening is actually worth. The digital economy, what you see all of
[01:58] these companies around here building products to optimize is worth about $16 trillion. 1% improvement gives us $160 billion a year. The physical industrial economy more
[02:11] than double the size of the digital economy. A 1% improvement there gives us $350 billion a year in perpetuity. But the money's the least interesting part of that equation.
[02:28] A 1% off industrial energy intensity nets about 380 million tons of carbon not entering the atmosphere. You don't need to build new infrastructure for that. You don't need to build a carbon capture product. You just need to make better use of the
[02:40] data. 330,000 people die every single year in industrial accidents. All of those signals for what was about to happen in the real world were in the data just unanalyzed.
[02:54] And 730 million people still do not have access to electricity. The gap there is not the ambition. The gap there is the cost and the reliability of the systems that deliver power
[03:06] to users. Every 1% increase or every 1% that we can gain back closes that gap.
[03:19] This is the digital world from 1995 to today. Obviously in all of this I'm being very reductive to make a point so you can take it with a pinch of salt, but it's it's true to a large extent. Salesforce, AWS, iPhone, GPT,
[03:31] Databricks, etc. And now the physical world. We've not really had a great leap in operational efficiency or operational optimization since about 1995. Sure
[03:43] we've built tons of point solution apps, but nothing that advances the entire sector at once. But a multi-trillion dollar industry to tell people that someone clicked a button in the physical world is kind of mired in 1995 with a skater system and
[03:57] Excel. Now, you can see where this comes from when you look at where the world points its compute.
[04:11] Global compute resource allocation, 98% pointed at the digital world, the digital economy. Less than 2% of money spent on compute is for physical systems. Um we've kind of aimed all of our intelligence at the smaller, easier problem to solve.
[04:28] And all that data that's in these physical systems, these machines, the language that they speak, um 90% of it goes unused, unanalyzed, um without any value created from it. Um this is the problem that we set out
[04:41] to solve at Applied Computing. So, we built Orbital. It's our foundation model for energy operations. Um the most valuable, most underused data set on Earth uh is the opera- operational data of the
[04:53] physical, industrial environment. Um and reading it, understanding it, interacting with it needs a fundamentally different foundation model, not a model that's trained um on the internet and not a standard ML
[05:06] pipeline. So, we built Orbital. It's a physics-informed foundation model for energy operations, and this allows me now to step into the technical part of the session and let Bryce take over the
[05:18] clicker. >> All right. Thank you. Can you hear me okay? Perfect. All right. So, I'm Bryce Bateman, and uh really looking forward to chatting to you today. I'm the head of engineering at Applied Computing. I'm going to tell you a little bit more
[05:30] about the technical aspects of Orbital, plus why we use Databricks uh to deploy Orbital. So, what is Orbital? Orbital uh is made up of five components. It's a domain-aware LLM.
[05:44] It's been uh basically trained and fine-tuned for the energy sector. We also work really hard on the time series. That's a major part of the solution. Uh as Kyle said, you know, a lot of the a lot of the data that is
[05:57] generated in industry is time series, and we focus a lot of our ability and our capability in Orbital around the time series itself to achieve things like optimization, uh anomaly detection, or root cause analysis. We also have a
[06:10] physics model. That physics model is really where we are able to make sure that the recommendations that Orbital makes are grounded in physics. Um and this also leads to the the next point,
[06:22] which is that we are able to reduce hallucination of our model by making sure that the model always checks that the physics is checking out with the uh with the recommendations that Orbital is making.
[06:35] We also have a tons of unstructured data in the uh in the in the industrial world, um and we obviously need to retrieve that. So, we have a rag system or a vector search that essentially allows us to explain to engineers a bit
[06:48] more about the procedures and operations of their plants. So, as I mentioned a little bit earlier, we have a validation layer that brings all of those four elements together to make sure that before we make a recommendation in the industrial world,
[07:02] that we don't hallucinate um because we're working in a really difficult environments where safety is of major concern, and hallucinations and bad recommendations are obviously not acceptable in that type of environment.
[07:14] So, what does that lead to in the deployments that we've had? The physics really in our AI has been able to get us 99% accurate inference on why something happened, what's about to happen, and
[07:26] what you what you should do next. So, why did we build Orbital on Databricks? The first is Oh, let me just go back. As Kyle said, industrial data is messy. I
[07:39] actually don't think just industrial data is messy. Um almost every industry's data is messy. Uh it's always poor quality. Like in the plants that we work in, that can be decades old. Some of it is not even digitized. Um it's not organized in any
[07:52] sort of catalogs. It's It's It's basically all over the place. And what we want to do is build AI on top of that type of data set. You can get yourself into quite a lot of trouble. But what we've done is being able to kind of
[08:04] modernize these platforms by bringing Databricks into the mix and basically bringing these uh plants and assets and companies into the modern era so that then we can achieve the goal that they often have, which is AI. So how do we do
[08:17] that on Databricks? Uh we basically use the lakehouse to bring together all the different data. There's three types of data that we focus on. Time series data, structured data, and unstructured data. So the time series coming from the SCADA
[08:30] systems or historians that are that industrial processes are generating. The structured data, things like uh processes, plant maintenance records, financial records, those types of things. And unstructured data, P&IDs,
[08:43] PFDs, all of the descriptions about the context of the actual plant or process itself. The lakehouse is able to store all of that data in one common platform, which means that we don't have to have a
[08:55] segregated data platform. It can all land up in the lakehouse and makes it much easier for us at Orbit at Applied Computing to run Orbital on top of that data once we get it in there. Obviously, the strict controls that we need to have in place around governance
[09:08] and Unity Catalog really helps us to achieve that. And then how do we bring the AI into that? So we don't want to stand up a bunch of our own infrastructure to run Orbital. We want to use what is already built and
[09:20] commoditized in the market. MLflow and Mosaic AI provides us with the backbones in terms of what we do for our AI. And then lastly, um the the data ingestion capabilities within Databricks
[09:32] uh are really groundbreaking for us in terms of being able to in uh digest or ingest data from multiple data sources, whether they're real-time data sources or they're even unstructured or structured data. Um the things like
[09:46] LakeFlow, uh declarative pipelines, LakeFlow Connect, uh it supplements the kind of capabilities that we have also built. So, let's get into the kind of capabilities that we built in Data Connect itself.
[09:58] So, in the industrial world, we do not have the uh kind of uh easy connector world that you have in the in the cloud. We don't have things like Google Drives, and we don't have things like Salesforce
[10:11] or any of those types of data sources to uh ingest data from. We have pretty hard and uh uh protocols to ingest. Things like OPC DA, for those of you who know what OPC DA, this is a protocol that's
[10:23] over 30 years old. It only runs on Windows 32 DCOM. It's a very hard protocol to connect into, uh it was especially when you're trying to live in the modern world. Um but we need to basically be pulling data from there.
[10:35] There's other systems that are also built, historians in the industrial world, that are used to capture a lot of time series data, OSIsoft PI, Yokogawa Exaquantum, Honeywell PHD, and the likes. Uh those are also mostly
[10:48] Windows-based systems. So, we can't deploy things like LakeFlow Connect on those types of systems. We need to think about how do we bring those in for Orbital and Applied Computing as well. Uh but we do have other systems like
[11:00] MQTT, where IoT data is coming from. And the other one that we're kind of tackling at the moment is that a lot of unstructured data doesn't sit in SharePoint even in some of these assets. It also sits in things like network drives, which, for those of you familiar
[11:13] with Databricks, is not We don't have a connector for that. But we can't deploy Orbital unless we have all of these capabilities. Uh and we need to be able to provide those uh services to our clients so that we can get their data
[11:26] into Databricks. So, what have we done? Uh we have leveraged all of the components that are also used in Databricks. Spark declarative pipelines, really happy that they open-sourced that
[11:38] in Spark 4.1. What that meant was we can build data ingestion pipelines that we can run on premise on client's infrastructure or in the cloud in the same way. Python custom data
[11:51] sources, which is the key for us to be able to build connectors that are customized for the types of protocols that are on the left-hand side. Really opened the door for us in terms of being able to connect to these data sources in
[12:03] a scalable way. Spark declarative pipelines as well, the structured streaming aspects of it, the ability to checkpoint, the ability to recover, the ability to backfill. All of those are incredibly important in terms of how we
[12:16] ingest streaming data. Obviously, the lakehouse, we use that comprehensively for analytical workloads and also for any of our training that we do on the data.
[12:29] Um Lakebase, we Orbital does have a front end that uses interact with. Lakebase gives the ability to bring that data into a low latency experience so that when they're working in the UI,
[12:41] things are snappy and fast. Um we also use vector search. So, we are using all of the latest AI parsing protocols that have just come out so Databricks document intelligence, AI parse
[12:53] document, AI prep search. Go check those out. Really powerful and get you shortcuts your journey of trying to get unstructured data into a vector search that then can provide you with retrieval
[13:05] of unstructured data into your solutions. And then obviously, Unity Catalog underpins all of it. We catalog absolutely everything that comes from the asset in bronze, silver, gold layers
[13:17] to make sure that we can also capture, govern, and control all of the data that's coming into Orbital. So, we've built it all on Lakehouse. There is no
[13:30] a cloud computing cloud. This is all hosted in a workspace for each tenant that we have. So, each customer has their own workspace. If they have their own Databricks deployments, we we will
[13:42] ingest into their Databricks deployments, but if they don't, we use our own to underpin all of what we do in Orbital. So, to just cover it for ingestion, we use Spark declarative pipelines and like
[13:55] I said, Python custom data sources, incredibly powerful at being able to provide you with the ability to extend ingesting data from non-custom data sources that Spark typically can support.
[14:07] We use Mosaic AI training. Now, this is one of the key features that I think is really important to understand, which is that while we do have our own GPUs that we use for building and training our models, we also need to have the ability
[14:21] to use burst capacity because as a startup, we can't just go and demand tons of GPUs from the likes of Azure or Nvidia or AWS. But, the AI runtime that Databricks
[14:33] provides, which gives service GPUs, if you haven't seen that yet, go check it out. You can get service GPUs, A10s, H100s, or clusters of H100s service fee and we thought that the cost of it was
[14:46] actually going to be pretty tough for us to use service GPU, but the fact of the matter is that training is is not always continuous, that we need to train, stop, review, train.
[14:58] The actual time in between has meant that the cost of using service GPUs for our training has dropped dramatically. So, that's quite an important learning that we've got. We use MLflow extensively. So, one of
[15:10] the things that when you're building AI solutions that you're probably all familiar with is that LLMs are non-deterministic. But, in a physical world or in an industrial world, engineers want things to be as deterministic as possible. They want the
[15:23] answer to be right and they want it to be grounded in fact. LLMs just based on how they predict the next word in front of it can go down many different routes and so we really struggle to make sure that we can keep
[15:35] it deterministic. But how we do that is we use MLflow evaluations and experiments to always validate that any model changes that we make return similar or answers grounded in truth and
[15:48] MLflow helps us with that. We obviously log all of those models in Unity Catalog. If you're our customer, we also any models that we generate for you, we store in your own catalog so that you can you own it. We do not
[16:01] export or use any of that data in some sort of ground or world model that we are secretly building in the background. We build all of our models for each of our customers. And then Mosaic AI serving and vector
[16:13] search. So when we are serving our models, latency is obviously incredibly important and we need the compute that is backing our inference to be as fast as possible and so Mosaic AI serving does that for us. Vector search is
[16:26] obviously a really incredibly good rag system for us to use and so when you look at it end-to-end, we are running Orbital on one stack using all of the capabilities that we are having
[16:38] Databricks. So Orbital, just to cover start summarizing how we do this. So the partnership that we have, we're a built-on partner with Databricks. So
[16:51] Applied Computing provides the foundation model. We are built on Databricks and we have amazing support from them to be get to get going and work really closely with their tech teams in terms of making sure
[17:04] that we are keeping up to speed with the latest and greatest from Databricks. The reason we're here today is partly we spend most of the mornings like you learning what's coming next. And the we we don't specialize in scale.
[17:17] We're a startup, but we use our partners Wipro to help us do deployments at our customers. So, as Cal said, um the you know, we are we are the a lot of
[17:29] the world is is targeting the digital world. We've seen evolutions from mainframe machines to PCs to the internet to mobile to cloud all enhancing and improving the digital
[17:41] world. But physics and AI or physic physics AI is now going to kind of leap the gap between the physical world and the digital world. And so, each wave that we've seen in the past
[17:54] was an was an evolution of the last one. But now that the wave reaches the real world, we're getting to the last frontiers of what we can do in terms of digital. So, that is it from us. I'd like to say
[18:06] thank you.

Learn more about the Databricks Data and AI platform.

The information provided herein is for general informational purposes only and may not reflect the most current product capabilities or configurations.