How MCP and Native .NET Namespace Exposure Enable AI-Driven Development
For systems integrators and system engineers, the traditional bottleneck in industrial automation is not technology. It is engineering hours. Every SCADA and IIoT project requires the same labor-intensive tasks: modeling the process in a tag namespace, configuring communication drivers, building HMI screens, and setting up alarm and historian schemas. These tasks demand skilled engineers who understand both the process and the platform.
The newest FrameworX update introduces a different approach by exposing its entire architecture, every .NET namespace, every Designer API, every configuration object, to AI agents via the Model Context Protocol (MCP). This is not AI-assisted development where a chatbot suggests code snippets. This is Autonomous Engineering, where the AI builds working configurations directly from natural language specifications.
FrameworX AI Designer is the production implementation of that approach. Engineers connect Claude or other AI agents directly to the Designer IDE and build SCADA/HMI solutions through natural language, with every change appearing in real time. The difference between AI-assisted and Autonomous Engineering comes down to access. Platforms that bolt chatbots onto closed architectures provide suggestions. FrameworX, with its unified architecture and MCP integration, gives AI agents the ability to read and write the same configuration objects that define your runtime, enabling direct execution of engineering intent.
WHERE SCADA ENGINEERS SPEND THEIR TIME
Understanding where engineering hours go on a typical project explains why AI integration at the configuration level produces outsized results. A skilled SCADA engineer spends 60 to 70 percent of project time on repetitive, mechanical tasks rather than solving the actual process problem.
| Task Area | Typical Effort | What the AI Does |
| Tag configuration and database building | 20 to 30 percent of project time | Generates ISA-95 compliant tag hierarchies from a description of your facility. A 500-tag database that takes two days takes 30 minutes. |
| Screen and display development | 25 to 35 percent | Builds displays from natural language descriptions, wires them to tags, applies High Performance HMI principles by default. |
| Alarm configuration | 10 to 15 percent | Suggests alarm limits based on industry standards, generates ISA-18.2 compliant messages, flags missing deadbands. |
| Scripting and logic | 15 to 20 percent | Writes scripts from behavior descriptions, documents them, saves them as reusable parametric components. |
| Historian and reporting | 5 to 10 percent | Recommends what to log based on equipment type, generates reports and trend configurations. |
| Testing and debugging | 10 to 15 percent | Audits the project, flags issues before commissioning, generates test plans. |
| Documentation | 5 to 10 percent (often skipped) | Generates tag dictionaries, alarm rationalization, screen descriptions as a byproduct of the build process. |
The FrameworX AI Designer addresses every one of these task areas. Project timelines are reduced by 40 to 50 percent. That is the direct result of eliminating the repetitive, mechanical work that consumes most of a SCADA engineer’s development hours.
THE ARCHITECTURAL FOUNDATION: THREE VIEWS, ONE MODEL
FrameworX is built on a unified data architecture where every object exists in three synchronized forms:
- Config Tables are the JSON and database definitions. What MCP tools use for import and export operations. What you write_objects to.
- Runtime Namespace is the live instance at runtime. What tags, scripts, and expressions read from. Tag.Plant1/Boiler/Temperature returns the live value.
- Designer UI is the visual editor. What a human clicks through. Each tab and page in Designer maps to one config table.
Figure 1: MCP enables AI agents to access FrameworX config tables and runtime namespaces directly, transforming natural language into working configurations.
This means when you execute write_objects(table_type=’DevicesChannels’, data=…), it produces the same result as manually filling in the Devices, Channels grid in Designer. At runtime it appears under Device.Channels.*. One object, three names, complete consistency. This is why AI can do real engineering work on FrameworX and cannot on platforms with closed, proprietary object models.
Why Open Architecture Matters
Most SCADA and IIoT platforms treat their internal object models as proprietary. If you want to automate configuration, you are limited to vendor-specific import tools or custom scripting against undocumented interfaces. AI integration typically means sending data out to external services, adding latency, complexity, and security considerations.
FrameworX takes a different approach. Because the platform is 100% managed .NET with a consistent three-view architecture, MCP provides AI agents with the same access an engineer has through the Designer UI. The AI does not need special adapters or translation layers. It works directly with the same config tables that define your runtime.
Module Architecture: Config Tables to Runtime Namespaces
| Module | Config Tables | Runtime Namespace | Designer UI Tab |
| UNS | UnsTags, UnsTagProviders | Tag.* | Tags page, TagProviders page |
| Devices | DevicesChannels, DevicesNodes, DevicesPoints | Device.Channels.*, Device.Nodes.*, Device.Points.* | Devices: Channels, Nodes, Points |
| Alarms | AlarmsItems, AlarmsGroups | Alarm.Items.*, Alarm.Groups.* | Alarms: Items, Groups |
| Historian | HistorianHistorianTags, HistorianStorageLoc | Historian.Tags.*, Historian.Storage.* | Historian: Tags, Storage |
| Displays | DisplaysList, DisplaysSymbols | Display.*, Display.Symbols.* | Displays: Draw, Symbols |
| Scripts | ScriptsTasks, ScriptsClasses | Script.Tasks.*, Script.Classes.* | Scripts: Tasks, Classes |
| Security | SecurityUsers | Security.Users.* | Security: Users |
When an AI agent connects via MCP, it reads and writes to any of these config tables, achieving the same results as an engineer working in the Designer UI, but programmatically and at scale.
THREE CORE CAPABILITIES
1. The AI-Powered Designer
The FrameworX AI Designer includes MCP-based AI integration that functions as a knowledgeable assistant throughout the entire development process. It understands the FrameworX platform completely, every object, property, method, and best practice, and applies that knowledge in context as engineers work. 18 purpose-built tools cover 73 configuration schemas across the full development lifecycle.
Tag Database Generation
Describe your facility structure and equipment and the AI generates an ISA-95 compliant tag hierarchy. The AI understands ISA-95 hierarchy (Enterprise, Site, Area, Line, Cell, Unit) and Unified Namespace principles. Instead of manually designing your namespace, you describe your facility and the AI structures it correctly from day one. Tags carry semantic meaning, Site1/Area2/Line3/Tank5/Temperature/PV instead of PLC1_DB4_DW22. Naming conventions are enforced consistently throughout.
Screen Development
The AI generates displays from natural language descriptions, wires them to the correct tags, and applies High Performance HMI principles by default. It understands what a pump faceplate, a trend display, or an overview screen needs to contain and how it should behave. Screens are built for operators, not engineers, reducing cognitive load and making abnormal situations unmistakable.
Scripting and Reusable Components
Describe the required behavior and the AI writes the script, explains what it does, and structures it as a reusable, documented component. Over the course of a project this builds an organizational library of parametric, reusable scripts that carry forward to every subsequent project. The AI does not write hardcoded one-offs. It generates parametric, reusable modules with inline documentation automatically.
The compounding effect: Your first AI-assisted project builds your competitive advantage. Projects two through ten benefit from everything the first project created, amplified by AI again. The gap between FrameworX teams and everyone else grows with every project delivered.
Audit and Documentation
The AI reviews completed work and identifies issues before commissioning. Alarm configurations without deadbands, unbound tags, missing states. It generates project documentation, tag dictionaries, alarm rationalization, and screen descriptions as a byproduct of the build process, not a separate effort after the fact. Documentation exists because the process generates it, not because someone found time to write it.
From Intent to Configuration: A Practical Example
Consider adding monitoring for a new pump station with three VFD-controlled pumps. In a traditional workflow, the engineer manually creates tags in the UNS hierarchy, configures the Modbus driver and register mappings, builds or adapts display graphics, sets up alarm thresholds, and configures historian logging. Each step requires navigating different Designer tabs and understanding the relationships between modules.
With FrameworX AI Designer, the engineer provides a single prompt:
“Add a 3-pump station under Tag.Plant1/Utilities/PumpStation2. Each pump has a Yaskawa VFD with speed, current, fault status, and run command. Connect via Modbus TCP at 192.168.1.50. Use our standard pump faceplate. Alarm on any fault or current above 15A.”
The MCP agent translates this into a coordinated sequence of write_objects calls: 12 UNS tags with proper data types, a Modbus TCP channel, three device nodes (one per VFD), register mappings for speed/current/fault/run, fault and high-current alarms for each pump, and three pump faceplate instances bound to tags. The engineer reviews the generated configuration in the Designer UI, makes adjustments, and deploys.
The practical effect is straightforward. Junior engineers produce work at a quality level that previously required senior oversight. Senior engineers spend their time on architecture and problem-solving rather than repetitive configuration. New engineers become productive in days, not months.
2. Modern Platform Architecture
The capabilities in the AI Designer exist because of what the platform is built on. Several architectural decisions in FrameworX are worth understanding specifically.
Unified Namespace Native
Tag structures in FrameworX follow ISA-95 hierarchy and UNS principles by design. Enterprise, Site, Area, Line, Unit, Tag is the native structure. This determines how easily data moves between systems, from the PLC to MES, ERP, cloud analytics, or any other consumer. Tags carry semantic meaning rather than device-relative addresses, which eliminates the remapping work that plagues integrations built on legacy flat namespaces. The structure connects naturally to MQTT brokers, Unified Namespace architectures, and cloud platforms without remapping.
Open Connectivity
OPC-UA, MQTT, REST, SQL, and major cloud platforms are supported natively. There is no proprietary middleware requirement and no vendor lock-in on the connectivity layer. The platform connects to what your environment already has. The AI assists in mapping device registers to UNS tags and reads uploaded PLC documentation to generate tag imports automatically.
Edge to Enterprise Deployment
FrameworX runs fully on-premise, at the edge, in hybrid configurations, or cloud-hosted. The deployment model fits your security and infrastructure requirements. An edge deployment is not a stripped-down runtime. Every capability available in a server deployment, including AI, ML.NET, historian, alarming, and scripting, runs at the edge. This makes FrameworX viable for remote sites, OEM equipment, and distributed architectures where a central server is not practical.
Data Hub
FrameworX operates as a data hub between your OT and IT environments. It collects from PLCs and field devices, contextualizes that data into a UNS-compliant structure, and publishes it to whatever systems need it: historians, MES, ERP, cloud analytics platforms, or MQTT brokers. You are not dependent on a separate middleware product to move data between layers.
Security Architecture
Role-based access control, encrypted communications, and audit trails are built into the platform. IEC 62443 alignment is a design consideration, not a retrofit. The AI generates compliance documentation, asset inventories, access control matrices, and data flow documentation as part of the project build process.
The MCP integration itself operates within the platform security model. AI agents are subject to the same role-based permissions as any human user in the Designer. Token usage, session scope, and access boundaries are all configurable by the administrator. The AI uses the same front door, with the same locks. No data leaves the local environment unless you configure it to. The AI does not phone home, does not require cloud connectivity, and does not store your project data externally.
Legacy Migration
The AI imports existing tag databases from CSV, XML, and OPC exports, restructures them to UNS-compliant hierarchies, and assists in rebuilding legacy screens in FrameworX with modernized layouts. This directly addresses the migration cost that keeps organizations on platforms like Wonderware, FactoryTalk, Citect, and iFIX. A migration that typically requires 12 to 18 months of engineering effort is substantially compressed. The AI also identifies dead configuration, tags and screens that exist in the legacy system but are no longer used, so migration becomes an opportunity to clean up rather than replicate problems.
The reason most organizations are still on their 2009 SCADA platform is not loyalty. It is the cost of leaving. FrameworX AI Designer eliminates that cost. Your legacy system becomes source material, not a trap.
Scalable Without Penalty
Tag counts, client connections, and historian capacity scale to meet your requirements. You are not penalized for growth with exponential licensing costs. Pricing is structured around how you deploy and what you need, not around the theoretical maximum of the platform. A single-application edge deployment is priced accordingly. An enterprise deployment with unlimited tags is priced accordingly.
3. Runtime Intelligence
The AI does not stop when you commission the project. FrameworX brings machine intelligence into live operations natively, without bolt-ons, without data scientists. This is where FrameworX moves beyond what any legacy platform offers regardless of how it is extended.
ML.NET Native Machine Learning
Machine learning models run inside the FrameworX runtime. No external Python environment, no cloud ML service, no separate integration layer. SCADA engineers, not data scientists, train models against historian data and deploy them directly. Models run at the edge with no latency and no external connectivity requirement.
Predictive maintenance based on vibration, temperature, or current signature patterns is straightforward to implement. Batch quality prediction from in-process parameters is achievable. Energy optimization through real-time setpoint recommendations is within reach of the engineering team that built the system, using data they already have. The MCP assists the engineer in selecting the right model type, structuring training data from the historian, and explaining what the model does and how confident it is. No Python. No cloud. No data science degree required.
AI Runtime Strategies via MCP
The same AI integration present in the Designer connects to live runtime data. This produces alarm strategies that adapt to operating mode rather than relying on static limits, anomaly detection that identifies process deviations before they reach alarm state, and operator guidance that provides context. Not just an alarm number, but what the condition means and what the recommended response is.
The AI knows what is running, what shift it is, what product is being made. Its recommendations are always in context. Your SCADA system stops being a dashboard that shows you what happened and becomes an intelligent system that tells you what is about to happen and what to do about it.
Natural Language Historian Queries
Process engineers and operators query historian data in plain language. “Show me every instance in the last 90 days where Line 2 yield dropped below target and what the upstream conditions were” returns a result without SQL, without a reporting tool, without IT involvement. The AI identifies correlations in historian data and generates shift reports, batch records, and regulatory compliance reports automatically from process data. Data that has been collected for years becomes accessible to the people who need it.
ADDITIONAL CAPABILITIES
Change Management
Configuration changes are tracked with semantic context. The AI identifies downstream impacts before changes are deployed and generates Management of Change documentation automatically. Not just “tag modified” but “alarm limit on Tank 3 temperature raised from 80 degrees to 87 degrees by user JSmith, here is the potential impact.”
Multi-Site Consistency
Template governance keeps naming conventions, alarm philosophy, and screen standards consistent across sites. The AI surfaces performance differences between sites running the same process and identifies the operating parameter differences that explain them.
Simulation and Validation
AI-generated process simulation enables testing before commissioning. Operator training scenarios built from real process data are developed without a separate simulation environment. Pre-commissioning validation runs the entire project against simulation before the first cable is connected.
Knowledge Capture
Expert reasoning captured during the build process, why a limit is set where it is, why a particular control strategy was chosen, is stored in the project and queryable by future engineers. New engineers ask the project knowledge base in natural language: “Why is this alarm limit set so low on this tank?” and get the answer the engineer gave when they configured it. Institutional knowledge that currently retires with senior engineers stays in the platform.
BENEFITS FOR SYSTEMS INTEGRATORS AND ENGINEERS
| Benefit | Detail |
| Faster project delivery | Repetitive configuration tasks that took hours are completed in minutes. Engineers focus on process understanding and system architecture. |
| Consistency at scale | AI-generated configurations follow naming conventions and standards every time. No variation between engineers or projects. |
| Lower barrier to entry | Engineers new to the platform describe what they need in natural language while learning the underlying architecture. |
| Full visibility | Everything the AI creates appears in the standard Designer UI. No black boxes, no hidden configuration. Review, modify, and deploy with confidence. |
| Documentation without effort | Auto-generated tag dictionaries, alarm rationalization, screen descriptions. Documentation exists because the process produces it. |
| Predictive operations | ML.NET models running natively in the runtime predict equipment failures, quality outcomes, and energy optimization without cloud dependency. |
| Knowledge retention | Institutional knowledge captured in the project, not in people. Survives turnover and retirement. |
| Migration risk eliminated | AI-assisted legacy migration compresses 12 to 18 month projects. Dead configuration identified and eliminated. |
| Flexible deployment | Full enterprise, single application, or anything in between. Complete functionality at the edge. Priced for how you use it. |
TIME SAVINGS REFERENCE
The following estimates are based on typical mid-size SCADA projects with the AI Designer handling the initial configuration pass, with engineers reviewing and finalizing.
| Task | Traditional Time | With AI Designer | Savings |
| 500-tag database | 2 days | 30 minutes | ~15 hours |
| 20-screen project | 3 weeks | ~1 week | ~80 hours |
| Project documentation | 3 to 5 days | Auto-generated | ~30 hours |
| Commissioning prep and testing | 2 days | Half day | ~12 hours |
| Typical mid-size project total | ~8 weeks | ~3 to 4 weeks | 50% labor cost |
Even at 30 percent time savings, a $150,000 project labor cost becomes $105,000. The AI pays for itself on the first project.
THE DISTINCTION
As established at the outset, the difference between AI-assisted and Autonomous Engineering comes down to access. Every capability described in this paper exists because FrameworX exposes its entire architecture to AI agents through MCP, the same config tables, runtime namespaces, and Designer operations that human engineers use. This is not a feature that was bolted on. It is a consequence of how the platform was built.
For systems integrators and engineers, this means spending less time on repetitive configuration and more time on what matters: understanding the process, optimizing performance, and delivering value to your customers.
Projects are delivered faster and at higher quality. Operations become proactive rather than reactive. The platform scales to your scope and is priced accordingly. The capabilities that legacy platforms require separate products, consultants, and integration projects to approximate are native to FrameworX from day one.
We did not bolt on a chatbot. We gave AI a seat at the engineering desk.