For more than fifteen years, the Sedona Framework has been one of the most recognizable edge programming environments in building automation. Thousands of controllers around the world still execute Sedona applications every second, proving how successful its original design was.
However, building automation architecture is evolving, and the expectations placed on edge devices are increasing rapidly.
The requirements placed on today’s edge controllers are fundamentally different from those of 2008. Merging the IT and OT environments, modern dashboards, data accessibility through multiple protocols simultaneously, data tagging, integration with cloud platforms, execute complex control algorithms, maintain secure communications, and support continuous software updates… all while remaining deterministic and resource efficient.
Today’s edge controllers are expected to:
- Allow for real-time programming by human, and with use of AI and LLM
- Run applications locally, not depend on the cloud for core functionality, but with possibility for 24/7 adjustments for improved energy efficiency
- Expose data natively through open protocols without manual engineering effort
- Support trends, alarms, schedules, and tags at the edge
- Allow for remote updates with minimum downtime
- Work with on-premise and remote tools for commissioning, diagnostics, and servicing
- Deliver semantic data models that make information understandable across systems, ready for digital twins and analytics
- Provide a unified platform for applications combining HVAC, energy management, DDC, lighting, and zone control
- Scale easily from small applications to large architectures without redesigning.

All of this must happen while maintaining the characteristics that make embedded controllers valuable: deterministic application execution, reliability, data sharing between devices and efficient use of hardware resources.
This new generation of requirements is the reason nano EDGE ENGINE (nEE) was created.
For engineers familiar with the Sedona Framework, nano EDGE ENGINE will feel immediately familiar, significantly shortening the learning curve for anyone experienced with component-based programming on a wire sheet. The familiar engineering experience is supported by a modern software architecture designed for the connected, data-driven building automation systems of tomorrow.
The open philosophy.
At first glance, Sedona and nano EDGE ENGINE feel familiar because both technologies are built around several fundamental principles:
- Real-time application execution
- Modular software architecture
- Platform independence
- Lightweight runtimes suitable for embedded hardware
- Application development using graphical components
- Reusable software building blocks
- Open development philosophy with SDK
For engineers who have spent years developing Sedona applications, opening nano EDGE ENGINE for the first time feels natural. The programming concepts are recognizable: components, networks, connections, properties, and reusable logic blocks.
Why Sedona was a revolution?
When Sedona Framework appeared, it challenged one of the fundamental assumptions of building automation: that application logic had to be locked inside proprietary controller firmware. Before Sedona, many BMS controllers required vendor-specific programming environments, and often closed development ecosystems. Sedona introduced a different approach, a lightweight, open, component-oriented programming model where control applications could be created by assembling reusable software components on a graphical wire sheet and deployed across different IP-based embedded controllers.
The revolutionary idea was not only the graphical programming environment itself, but the separation between hardware, runtime, and application logic. A system integrator could focus on creating the control strategy instead of rewriting firmware for every controller platform. Components became reusable building blocks, allowing HVAC sequences, calculations, alarms, schedules, and integrations to be represented as software objects that could be connected, configured, and reused.
Sedona also represented a major step toward open control in the building automation industry. By promoting an open technology approach, Sedona enabled a broader ecosystem of developers, manufacturers, and integrators to participate without being tied to a single proprietary platform.
nano EDGE ENGINE – Where innovation meets simplicity.

nano EDGE ENGINE (nEE) was created for a new generation of intelligent edge devices. It is not simply a programming environment; it is a complete embedded software platform designed to transform controllers, I/O modules, sensors, and other field devices into smart, connected edge devices ready for the Internet of Things era. It’s modular design is possible thanks to the architecture based on a microcontroller rather than a microprocessor.

The fundamental idea behind nEE is simple: every edge device should have the ability to execute intelligent applications, communicate with open protocols, manage its own resources, expose meaningful data, and integrate naturally with modern building ecosystems.
At its core, nano EDGE ENGINE provides the environment required to build, run, and manage multiple user applications directly on edge devices. It combines deterministic control execution, communication capabilities, data management, diagnostics, and system services into a single lightweight software architecture.
The name itself describes its philosophy:
nano – an extremely lightweight software engine designed to run efficiently on embedded edge devices based on microcontrollers, including controllers, actuators, I/O modules, and sensors.
EDGE – a platform designed to bring intelligence closer to the equipment by enabling local decision-making, data processing, connectivity, and integration with cloud services.
ENGINE – a foundation that allows developers and system integrators to create control logic, integrate devices, collect and expose data, and build complete edge applications.
This approach creates a new generation of software-defined building devices where hardware becomes a flexible platform rather than a fixed-function controller.
Data Is the foundation of nano EDGE ENGINE.
One of the biggest architectural differences between traditional controller programming and nEE is the importance placed on data.
In nano EDGE ENGINE, Data Points are the fundamental building blocks of the system.
A Data Point represents a meaningful value within the application:
- Sensor measurement
- Setpoint
- Command value
- Non-volatile variable
- Calculation result
By making Data Points central elements of the architecture, nEE creates a natural connection between control logic, automation networks, visualization, and cloud analytics platforms.
Every Data Point can become a shared information object. This enables:
- Automatic BACnet and Modbus exposure
- nanoWebUI visualisation
- Haystack 4 tagging
- Integration with analytics platforms
- Consistent data structures across applications
The result is an edge architecture designed not only for controlling equipment, but also for managing and delivering valuable building data.

Designed for modern integration.
nano EDGE ENGINE introduces several concepts that simplify deployment and maintenance:
1 Automatic Data Exposure
Data Points can automatically become available to external systems through BACnet and Modbus, significantly reducing engineering effort during integration.
Instead of manually creating hundreds of network objects, the system can automatically expose application data according to configured rules.
2 Tool Independence
The operating system is independent from engineering tools.

Whether working through Niagara Workbench or iC Tool, device provides the necessary information about installed libraries, components, and applications.
The intelligence remains inside the device, not inside a specific programming tool. That bring significant advantage not only in the initial commissioning and programming phase, but also during the future maintenance. Tool independence means no connection with specific tool version, and possibility to tune, or reprogram using component blocks inside the device itself.
3 One-Click Backup and Recovery
The complete device structure, including:
- System configuration
- Applications
- Libraries
- Networks
- Non-volatile controller specific values
can be backed up and restored as a complete project. The tools support multi-device management and addressing, ensuring the backups and recoveries can be executed on multiple devices at once.
4 Plug-and-Play Hardware Replacement
With application and operating system storage based on an industrial grade SD cards, replacement of hardware becomes significantly easier. The complete device environment can be transferred without rebuilding the application from scratch.
The evolution of edge intelligence.
Sedona introduced the idea that controllers could become programmable software platforms. nano EDGE ENGINE takes this idea further.
It preserves the simplicity of component-based programming while introducing the capabilities required for today’s connected buildings: structured data, multiprotocol open communication, cloud readiness, intelligent edge processing, and scalable applications. The result is not only a controller that executes logic. It is an intelligent edge platform where control, communication, and data become part of one unified architecture.
This is why nano EDGE ENGINE can be seen as the next evolution of the Sedona philosophy, the move from programmable controllers toward intelligent edge devices.
| Type | Sedona Framework | nano EDGE ENGINE |
| Application engineering type | Sedona Function Blocks | nano Function Blocks |
| Engineering environment | iC Tool, Niagara AX (EOL) | iC Tool and Niagara Workbench support |
| Protocol layers | Serial and IP. BACnet, Modbus, M-Bus, DALI | Serial and IP. BACnet, Modbus, DALI-2, M-Bus (in progress), Haystack API |
| Runtime model | Sedona Virtual Machine (SVM) | .NET runtime |
| Execution model | Component scan execution | Cycle-driven execution with independent application cycles |
| Application execution | One main execution environment managed by the Sedona runtime | Multiple independent applications and user services running with dedicated execution cycles |
| Application portability | Applications portable between compatible Sedona platforms | Hardware-independent applications running on nEE embedded edge devices |
| Multithreading support | Single-threaded execution model | Multithreaded architecture supporting independent applications |
| Modularity | Yes, with Kits | Yes, with Libraries |
| Tool dependency | Yes, requires matching kits and manifests to interpret application components | No, Device provides application schema, installed libraries, and component information automatically to connected tools |
| Library dependency management | Application depends on installed Kits and manifests. Missing required Kits can prevent proper application interpretation and management | Device provides information about installed libraries and components, allowing tools to understand the application structure dynamically |
| Native Data Exposure | No, requires manual implementation | Yes, Native Data Point exposure through BACnet, Modbus and other protocols |
| SDK | Yes | Yes |
| Programming language | Sedona language | C# |
| Development ecosystem | Sedona-specific | Modern .NET/C# development ecosystem |
| Cloud/IoT readiness | Not part of original framework design | Designed for IoT-ready edge device |
Shift in architecture design -> from logic-driven to data-driven.
The biggest architectural difference between Sedona Framework and nano EDGE ENGINE is not the programming language, the engineering tool, or even the execution model. The fundamental shift is the way the system is designed around logic versus data.
Sedona was created in an era when the primary challenge was making controllers programmable. The main question was: “How can we move application logic from proprietary firmware into a flexible, reusable software environment?” Sedona solved this problem by introducing a component-based programming model where control strategies could be built from reusable software blocks. The focus was on creating, executing, and managing control logic at the edge.
nano EDGE ENGINE takes this concept into the next generation of building automation. Modern edge devices are no longer only responsible for executing sequences; they are becoming intelligent data platforms that connect equipment, systems, and cloud services. The central question has changed to: “How can we create, structure, expose, manage, and utilize the data generated at the edge?”
This is why nEE is built around Data Points as fundamental elements of the architecture. Logic still exists and remains essential, but it operates within a larger ecosystem where every value has meaning, structure, connectivity, and lifecycle management.
A Data Point is not simply a variable. It represents a piece of building intelligence that can be:
- Used inside application logic
- Connected to physical inputs and outputs
- Linked with external network devices
- Exposed automatically through BACnet and Modbus
- Structured into equipment models
- Tagged using semantic models such as Haystack 4
- Consumed by visualization, analytics, and cloud platforms
This represents a major evolution in the role of the edge device.
The Sedona philosophy was: “Make the controller programmable.”
The nano EDGE ENGINE philosophy is: “Make the controller intelligent, connected and data-driven.”
Find more about nano EDGE ENGINE at nee.tech
Author:
Pawel Szarmanski
Senior Product Manager