One of the goals of the Sedona Framework is to empower non-programmers to graphically assemble applications by wiring together predefined components. It is useful to consider two primary actors involved in building Sedona Framework applications:

In the real world, users don't fit into these two buckets so cleanly - many belong to both camps. But characterizing users according to these two actors is useful for discussion.

Sedona Language

Sedona Framework applications all start with software written in the Sedona programming language. The Sedona language is based on Java and C# - so if you are familiar with those languages then you should have no problem learning Sedona. Key characteristics of the Sedona language include:


The Sedona Framework's standard API includes a special class called Component. Classes that extend Component are designed to be used by integrators to assemble applications. All components have the following characteristics designed to enable component-oriented application assembly:

Slots are the members of a component class that specify how the component is exposed to an integrator during the assembly process. There are two types of slots: property defines a configuration or runtime variable and action defines a command that can be invoked.


Developers write software organized into classes much like C++, Java, or C#. These classes are then packaged up into a kit. A kit is the primary unit of deployment, versioning, and naming in the Sedona Framework. A kit is like a Java JAR file or a .NET DLL.

Kits are stored as a single file that ends with the ".kit" extension. The file itself is a standard archive file you can open using your favorite 'zip' tool. Inside the kit file is an XML manifest file that specifies meta-data about the kit such as its name, version, vendor, and description. The manifest also enumerates all the kit's component types that are available for constructing applications.

Kits are compiled from Sedona language source code using the sedonac compiler. During compilation, all the classes in the kit are checked for validity and compiled into a special format called IR for intermediate representation. The IR format is a text based "assembly language". IR code is portable, which means one kit file can be deployed for all platforms.


Sedona Framework software deployed as kits still isn't quite ready for execution. Even though we've compiled source language down to IR, we still don't have a format suitable for machine execution. The next step is to compile a set of kits into a single file called an scode image. SCode is a very compact, binary representation of the code, designed to be executed directly by the Sedona VM.

The sedonac compiler is used to compile a set of kits into a binary ".scode" file. During this compilation process the following tasks are performed:

To maximize performance, sedonac optimizes the scode for a specific platform's endianness and pointer size; this means that an scode image is not portable to other platforms.

Sedona Virtual Machine

Once a set of kits has been compiled into an scode file, we can run the scode using the Sedona Virtual Machine, or SVM for short. The SVM interprets the scode and brings Sedona programs to life!

The SVM itself is written in ANSI C and compiled for a target hardware platform. See the Porting chapter for instructions to get the SVM running on your target device.

Sedona Framework Applications

Writing code in the Sedona programming language and building kits is the domain of developers. Developers build libraries of ready-to-use components deployed as kits. Integrators can then use graphical programming tools to design applications by assembling and linking component instances.

Due to their dynamic nature, Sedona Framework applications are modeled and persisted differently from kits and scode. A Sedona Framework application is modeled as a tree of components. Each component is assigned a unique two byte identifier and a custom name. Components instances may also be customized via their configuration properties. Links are used to establish relationships between components to specify data and event flow within the application.

Sedona Framework applications may be stored in two different file formats. The Sedona Application XML format uses the ".sax" file extension, and is a human-readable XML file. The Sedona Application Binary format uses the ".sab" file extension and is a compact binary representation of the application. The binary format is the one used at runtime on Sedona Framework-enabled devices. The sedonac tool can be used to convert between the file formats.

Sedona Framework Devices

Of course the end goal of the Sedona Framework is to create programmable smart devices. This is where everything comes together. The typical process of Sedona Framework-enabling a device:


The diagram below illustrates the workflow for building and deploying Sedona Framework applications to devices.

Sedona Architecture

The Sedona developer workflow typically involves these steps:

  1. Build library of components in the Sedona programming language
  2. Components are compiled into kits using sedonac
  3. Developers or integrators will choose which kits to install onto a device, and then sedonac is used to link the kits into a binary scode image (this step is often done under the covers by a high level tool)
  4. The SVM and scode are loaded onto the device. These files may be predefined such as in ROM, or may be dynamically provisioned over the network using the Sox protocol.

System integrators are usually domain experts who build Sedona applications by "wiring together" the components provided by developers. These users typically use graphical tools to assemble applications. Applications may be modified remotely on a running device using the Sox protocol, or they may be built offline and stored in a "sax" file. If the app is built offline, then it compiled into a "sab" file with sedonac and installed on the device at commissioning time using the Sox protocol.