Actors

The Sedona Framework is designed 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:

• Developers are software engineers who write components using the Sedona programming language. These components include function blocks, IO drivers, and packaged applications. Components are then bundled into modules and deployed as kits.
• Integrators are typically domain experts who use graphical tools to assemble applications from the components written by developers. Components are configured via their properties and wired together with links.

In the real world, users don't fit into these two buckets so cleanly - most users fit into 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:

• Familiar Java/C# syntax
• Object oriented (inheritance, polymorphism, all that good stuff)
• Component oriented (first class properties and actions, reflection, graphical assembly)
• Single inheritance only (no interfaces)
• Static memory model (no new keyword)
• Semicolons are optional as statement separator

Components

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:

• Two byte component id for identity and naming inside an application
• A short ASCII character name as a human label
• Designed to be organized into a tree structure similar to your file system
• Reflective type
• Named set of reflective slots

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.

Kits

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 PKZIP 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 application assembly.

Kits are compiled from Sedona language source code using the sedonac compiler. During the 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. During this step the compiler also generates a Java classfile for each of the Sedona classes, which can be run on the Java VM.

SCode

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, which is 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:

• Layout method code in memory
• Layout fields in memory
• Layout reflection meta-data in memory
• Optimize for big-endian or little-endian
• Optimize for native platform pointer size
• Link method calls to their memory locations

For performance, we optimize scode for a specific endianness and pointer size - which means that an scode image is not portable. Typically this compilation step happens automatically under the covers during device commissioning.

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 on the Java VM

The Sedona Framework may also be run on a Java Virtual Machine. When Sedona source code is compiled into a kit file, the compiler generates Java bytecode. This allows you to use kit files like Java JAR files.

Running on the Java VM has a couple advantages over the SVM. First, a Java VM such as HotSpot uses a sophisticated JIT to compile and optimize Java bytecode to machine code at runtime. This potentially allows Sedona to run much faster on Java. Another advantage is that you can tap into Java ecosystem for tools such as debuggers. You will probably find Java an easier environment to use for testing and debugging your code. Java will enforce array bounds checking and give you print stack traces with line numbers when exceptions are raised.

However the resources and cost required to run Sedona Framework applications on Java make it an unsuitable solution for most embedded devices. Java typically requires dozens of megabytes of RAM and depending on the vendor might require a runtime license fee. The SVM is designed to run in as little as a 100KB making it ideal for embedded devices.

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 by 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. The Sedona Application - Binary format uses the ".sab" file extension and is a compact binary representation of the application database. The binary format is the one used by the 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:

• Port the SVM to the device's hardware platform
• Enable the SVM to run (typically loaded or run from FLASH on startup)
• Enable commissioning of an scode image. This allows integrators to pick their own kits to use for applications. In some low-end devices the scode may be fixed or even in ROM. Typically the scode is loaded or stored in FLASH, and a pointer to the base address is passed to the VM at boot time.
• Enable load/save of the sab application file. In some cases an integrator may dump a whole new application into FLASH; other times the application is assembled on the fly at runtime and then saved to FLASH. In dedicated devices the application might be fixed or even stored in ROM.

Workflow

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

The 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 often domain experts who build applications by wiring together the components built by developers. These users typically use graphical tools to assemble applications. Applications may be built on-line with a live 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 onto the device at commissioning time using the Sox protocol.