This specification focuses on devices with
non-volatile and volatile memories (eeprom, flash, ram, ... ). At the
application level, it focuses on applications that have some sort of
initialization phases before entering into a mission phase that exists until
the device is shut down or rebooted. This specification allows to fully
control memory usage and start-up sequences on devices with limited memory
- Controlling the sequence of initialization in a deterministic way,
- Defining persistent immutable read-only objects that may be placed into
non-volatile memory areas, and do not require copies to be done in RAM to be
manipulated: they are alive from system's startup.
- Defining immortal read-write objects.
This specification serves as a very robust foundation for implementing
embedded Java software.
This specification aims at providing the
minimal cornerstone for quick construction of advanced, portable and
user-friendly applications for a wide and heterogeneous range of devices
with just-what-is-needed resources. This specification serves as a very
robust foundation for implementing complex widget and/or windowing systems.
Typical devices have some form of display, some input sensors, and
potentially some sound rendering capabilities. This specification spans a
potentially wide set of devices.
This specification takes its roots from established patterns such as MVC and
MVP. It allows anyone to use it with minimal learning cost: it is a
straightforward framework to design with. The main asset of this
specification is probably its flexibility to fit customer needs at minimal
cost: rapid design of HMIs without jeopardizing the Bill Of Material of the
This specification is multi display ready and multi touch ready. Other main
- Models, Listeners, Events, Event generators, Event handling, Pumps, Thread
- Screens, Display, Displayable, View, CompositeView, Alphanumeric Display,
LEDs, Audio Tones
- 2D rendering, Image transformation, Tranparency, Flying Image, Fonts
- Command, Button, Keyboard, Pointer, Keypad, State
A device built on this specification must have the following minimum
- Display: optional (several displays are permitted); size: any, type:
graphic or alpha-numeric, depth: 1-bit or more, pixel aspect ratio:
approximately 1:1, alpha numeric: at least one line with one character
- Input: optional; Any user-input mechanisms: buttons, rotary switches,
keyboards, multi touch screens, mouse-like-pointers, etc ...
- Output: optional; Any sound mechanisms that provide the ability to play
tones: buzzer, PWM, etc ..., Any kind of LEDs.
- Memory: about 30 kilobytes of non-volatile memory if the whole MicroUI
implementation is required by an application. For graphical screens, at
least one display size of volatile memory for each graphical screen. For a
128x128 monochrome display, this is 2 kilobytes of ram; for a 320x240 16bit
color display, this is 150 kilobytes.
The SNI-GT specification is dedicated to
green threads virtual machine architectures. the SNI-GT specification allows
- Call a C function from a Java method
- Access Java Immortal arrays (See the B-ON specification to learn more
about immortal objects) in a C function
- Manage in C the life cycle of the Java world (aka the vm) from the
This specification provides the segregation
of the processes which can be written either in C or Java. It allows the
certification of each individual part separately.
The data sharing between processes uses the concept of shared memory blocks,
with introspection on those blocks. The provided facilities include:
- Notification when the content changes
- Reinitialization of the block, testing the presence of data in the data
- A mechanism for serialization and de-serialization
The SP specification allows the creation of several data stores. These can
be entirely defined statically, or increased during the execution of a
Reading and writing in the shared memory are operations with predictable
This specification defines a Trusted
Execution Environment (TEE) for
software modules, called Features. Each module runs in an isolated
execution environment, which provides a sandbox for module's resources
such as RAM control, CPU bandwidth control, integrity of applications,
code execution control, along with confidentiality of module's assets.
Kernel & Features semantic (KF) allows an application to be split
between multiple modules: (1) the Kernel, (2) zero or more modules. A
module is fully controlled by the Kernel: it can be installed
(dynamically or statically per-installed), started, stopped and
uninstalled at any time independently of the system state. In
particular, a module can always be killed at any time and all its owned
resources (RAM, flash, ...) be removed without compromising the rest of
This specification serves as one of the most secure foundation for
implementing embedded software in MCU/MPU based electronic devices.
The HomeEZ language allows one to write
scenario for smart markets, such as Smart Home, so its name. It is designed
to be simple so that no particular notion about software programming is
needed to achieve fluency in the language. Its purpose is to handle and to
describe automation applications. It has two levels of descriptive power:
the first one deals with straight forward objects (naming, linking, binding
actions on events), while the second one provides a more expert semantic
with classes that organize manipulated concepts.
HomeEZ is not typed, has an XML based syntax. The concepts provided by
HomeEZ are :
-automatic pool of devices management
-construction and manipulation of direct acyclic graphs of devices (name
-events triggering (time, asynchronous (hardware) events, ...) and action
-atomic states of devices management and variables manipulation
-scenario instance and scenario classes
-expressions computation model
The LWM2M protocol is becoming the standard
for remotely managing a device through a set of
normalized operations. However, although its semantics can be implemented on
any kind of
protocols, the LWM2M specification is written in a way that it is tightly
coupled to the CoAP
protocol, compliant with a lossy network such as UDP or SMS transport.
The goal of this specification is to propose an alternative composition of
LWM2M semantics with
CoAP message format based on MQTT publish/subscribe paradigm on top of a TCP