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 resources:
- 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 device.
This specification is multi display ready and multi touch ready. Other main features are:
- Models, Listeners, Events, Event generators, Event handling, Pumps, Thread safe
- 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 characteristics:
- 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.
This specification targets deterministic Java for safety critical systems. It is designed to make it possible to have Java software certified at the highest possible certification levels, like DO178 level A for example. Therefore HRTJ targets libraries that, due to their sizes, can be certified at a reasonable cost.
This specification is about hard real-time, not soft real-time. A hard real-time system guaranties that expected behaviors will occur at the right time. The HRTJ specification uses deterministic hard real time constraints.
The HRTJ specification relies on the B-ON specification.
This specification provides a universal widgets-based framework across all Java Runtime Environment configurations.
MWT is a widget toolkit designed for a wide range of devices, including embedded devices with limited processing power.
MWT defines a graphical environment that avoids portability issues so that an application running on a constrained device can run on any other hardware device such as cellphones-PDA or PC. The aim of this library is to be sufficient to create complex applications with a minimal framework.
MWT defines three distinct roles:
- "Widget Designers" that create new widgets by specifying widget contents and behaviors.
- "Look and Feel Designers" that create consistent sets of rendering systems in order to define the way widgets are displayed on screens.
- "Application Designers" that create the HMI and the functional parts of the application.
The same binary HMI application can run the same way on all devices providing a compliant MWT framework (embedded devices, cellphones, Android-based devices, setopbox-TV, PC, etc...).
The SNI-GT specification is dedicated to green threads virtual machine architectures. the SNI-GT specification allows to:
- 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 RTOS
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 block
- 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 program.
Reading and writing in the shared memory are operations with predictable performance characteristics.
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 Edje Device Configuration specification defines the minimal standard runtime environment for embedded devices.
It defines all the default API packages (138 classes/interfaces):
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 space)
-events triggering (time, asynchronous (hardware) events, ...) and action invocation
-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 transport.
This specification is intended to be given to the OSGi Alliance. It represents a work-in-progress answer to the RFP126. Contributions are welcome.
This specification defines OSGi for embedded devices addressing cost and robustness concerns on various Java Platforms.
The OSGi-ED specification makes minimal assumptions about the software system:
- A Java virtual machine may run on an OS, on an embedded RTOS, or directly on bare metal (The device boots directly in Java).
- A library implementing at least OSGi/EmbeddedDevice-1.0 environment running on top of the Java virtual machine.
The OSGi-ED profile specification introduces high robust semantic:
- A thread-safe framework
- True bundle context from which private classes cannot escape
- No stale reference, introducing a notion of object ownership
- Transactionnal bundles life cycle
- A controlled initialization sequence upon each reboot and restart
- DSDO, DSD1, and DSD2 that characterize how software is loaded into devices.
The OSGi-ED profile specification relies on the Eclasspath specification.