An interview with Sadiq Syed, SVP Digital Buildings at Schneider Electric, on unifying electrical and mechanical systems, data, and AI for truly interoperable buildings.
At Schneider Electric’s Innovation Summit 2025, one of the recurring themes was how to move beyond simply “connecting” systems toward native interoperability in buildings. As part of that broader discussion, the company featured EcoStruxure™ Foresight, a new digital buildings platform described as an “operating system” for the built environment—bringing power, energy, and building management into a unified architecture.
In this interview, AutomatedBuildings.com contributing editor Tracy Markie talks with Sadiq Syed, Senior Vice President of Digital Buildings at Schneider Electric, about what’s actually new in this kind of platform approach, how he thinks about openness and standards, the role of AI, and what still slows the industry’s progress toward interoperable buildings.
What follows is an edited Q&A.
Q&A
Tracy Markie:
Let’s start with your role. You’re relatively new to Schneider Electric—about a year in. What does your position as SVP of Digital Buildings cover?
Sadiq Syed:
I lead the Digital Buildings line of business within Schneider Electric’s Digital Energy business unit, which is part of the broader Energy Management organization.
I’m responsible for end-to-end innovation across the building automation domain globally. That includes our field devices and connected products—controllers, sensors, actuators, and other field devices—the edge control layer for building and energy systems, and the optimization and analytics layer on top, where we deliver use cases like fault detection, diagnostics, and energy management.
So the scope spans hardware and software, from devices at the edge through the control platforms and up into data and analytics.
Tracy:
At Innovation Summit 2025, you described this new platform as an “operating system” for the built environment. In practical terms, what does that mean and why is it important to you?
Sadiq:
The idea is to bring energy, power, and building management onto a single architecture rather than treating them as separate domains that get integrated later.
Historically, electrical and mechanical systems have been designed, installed, and operated largely independently. Yet the use cases that matter now—energy performance, resilience, and better operations—span both sides. What we’re doing with this platform is trying to natively integrate electrical and mechanical domains so those use cases can be addressed more directly, without relying only on loose connections and custom integration work after the fact.
EcoStruxure Foresight is one implementation of that idea, but the core concept is the underlying architecture: a common way to bring these domains together.
Tracy:
The industry has been chasing interoperability for a long time. We’ve had LonWorks and BACnet at the protocol layer, then frameworks like Niagara on top. What do you see as fundamentally different about this approach?
Sadiq:
Historically, we’ve focused on connecting systems, not truly integrating them.
APIs, gateways, and middleware have allowed us to move data between siloed systems and present a single user interface. That has value, but underneath it, those systems usually still have separate data models and separate logic. The integration is often shallow, and that limits the kind of intelligence you can build.
What we’re working on now is architecting the electrical and mechanical domains together from the start. That means sharing a common data context and allowing events in one domain to be directly and consistently related to events in the other.
A simple example is relating a potential electrical issue on a switchboard to a developing mechanical problem on a chiller. Today, operators often make that connection only after they investigate a failure. With native integration, we can shorten the time between cause and diagnosis significantly, which is important in environments like data centers, life sciences, and healthcare where uptime and resilience are critical.
Tracy:
For our readers, “open” is a critical word. Is this mainly a vertically integrated stack from one vendor, or is it a platform that others can realistically participate in?
Sadiq:
We’re trying to do both things at once.
Within our own portfolio, we want native, multi-domain integration across electrical and mechanical systems. That is where we can take full advantage of the architecture and deliver the most complete use cases.
At the same time, we recognize that most large portfolios are inherently multi-vendor. It’s rare to find a campus or portfolio with a single OEM. So the platform is intended to be extensible. We already integrate third-party systems today, and that continues to be part of the strategy.
The difference is that when systems are part of a natively integrated architecture, we can support deeper, cross-domain use cases. When we integrate at a higher, more superficial level with external systems, the scope of possible use cases can be more limited, but the platform is not closed to them.
Tracy:
How does this align with ongoing standards efforts? Many of us are working with NIST and ASHRAE 223. Are you creating something new, or building on what’s already there?
Sadiq:
We’re not trying to create a new standard. The intent is to be standards-based and work within the existing landscape.
There are already many protocols and standards in this space. Our goal is to remain compatible with them rather than adding another layer of complexity. So the architecture is designed to operate within that existing ecosystem and make use of it, rather than replace it.
Tracy:
From a stack perspective, where does most of this integration happen—at the device level, at the edge, in the cloud?
Sadiq:
There are two key levels.
One is the edge control layer, where we bring together the different domains—electrical and mechanical—for real-time control and coordination.
The other is the data layer above that, where we aggregate and contextualize data. In large environments, you can be dealing with millions of data points. At the edge, that data is still relatively raw. You need a place where it can be normalized, semantically tagged, and combined so that it’s usable by applications, whether those are developed by us or by partners.
So the approach is full-stack—devices, edge control, and data/analytics—but with particular emphasis on the edge control and data layers as the points where real integration happens.
Tracy:
Let’s turn to AI. At Innovation Summit 2025, AI was framed as part of a “golden triangle” with compute and electrification. Where does AI actually show up in your digital buildings work today?
Sadiq:
AI is present at several layers.
At the device and edge level, AI can help with onboarding devices and mapping and tagging data so that it’s correctly understood by the platform.
At the platform or data layer, AI is used to contextualize and interpret data, identify patterns and anomalies, and relate signals from different systems.
At the application level, AI supports use cases like predictive maintenance, fault detection, and recommendation engines that guide operators on likely causes and useful next steps based on what has been seen in other similar systems.
We’re also focused on using AI to reduce deployment and commissioning time. Historically, bringing a system online might take many weeks. With better tools, including AI-assisted workflows, we believe that time can be significantly reduced, which matters a great deal for partners and end users.
We use a mix of commercially available AI technologies and open frameworks, and we have an internal AI hub that helps the different business units choose and deploy the right tools for the right use cases.
Tracy:
If the technology is progressing, what do you see as the main obstacles that still prevent us from having truly interoperable buildings?
Sadiq:
I’d group them into three areas.
First, there’s collaboration and mindset. Interoperability requires that multiple parties be comfortable working together and accepting a level of openness. That is as much cultural as technical.
Second, there’s cost and economics. Solutions have to make sense at the price points customers are willing to pay. Interoperability can add value, but it also has to be delivered efficiently so that projects can get approved and scaled.
Third, there are business models. Some historical OEM business models have been more aligned with closed systems than open ones. Changing that takes time. Customers increasingly expect interoperability, so business models have to evolve to reflect that expectation.
Tracy:
Are concepts like digital twins part of your day-to-day work in digital buildings, or more of a future direction?
Sadiq:
They are part of both the present and the roadmap.
We’re working on the models, semantics, and representations needed to support digital twins—essentially a virtual counterpart of a system that you can analyze, simulate, and use to inform decisions before and after deployment.
Digital twins tie directly into interoperability, because they depend on having consistent, well-structured data across systems. In our roadmap for the next 12 to 18 months, you’ll see more work on this front, grounded in specific use cases rather than just as an abstract concept.
Tracy:
Which verticals are pushing you the hardest on these ideas right now?
Sadiq:
Three sectors stand out.
Data centers are one, where uptime and energy performance are both critical and where the density of computation is increasing rapidly.
Healthcare is another, where reliability, safety, and regulatory compliance are major drivers.
Life sciences is a third, with stringent environmental and process requirements that demand high levels of control and visibility.
We also see interest from commercial real estate owners with large portfolios and from education, especially universities with many buildings and complex campuses. But the three sectors I mentioned are currently the most active in driving requirements around integration, visibility, and data-driven operations.
Tracy:
Anything you’d like to leave our readers with?
Sadiq:
I’d encourage readers to look at how cross-domain integration—linking electrical and mechanical systems with a coherent data layer—can change the kinds of questions we can ask and answer about building performance.
Whether it is done through platforms like EcoStruxure Foresight or other approaches, the shift toward treating energy, power, and building controls as parts of a connected whole, rather than separate disciplines, is central to where the industry is going.
And input from communities like AutomatedBuildings.com is important in shaping how that actually takes form in real projects.
Tracy:
Sadiq, thanks for the conversation and for sharing your perspective on digital buildings and interoperability.
Sadiq:
Thank you, Tracy. It was a pleasure
