Smart Object Oriented (SOO) technology is the result of many years of research and development in the field of embedded systems including hardware and software topics such as ARM microcontrollers, System-on-Module integration, operating systems and software virtualization.
In early 2014, Prof. Daniel Rossier introduced the notion of Smart Object and the SOO technology based the paradigm of self-migration of running in-execution (live) environments. The idea is to address numerous technical challenges which are common to connected devices such as the deployment of new applications and their maintenance in embedded systems, wireless connectivity in preferably very scalable networks, highly secure execution environments, low power consumption and cost-effective hardware, etc. but above all, simple mechanisms to establish dynamic online synergies between applications themselves, in other words between execution environments which are visiting smart objects.
The SOO technology strongly relies on various low-level operating system concepts and embedded virtualization which plays a fundamental role in this architecture.
Smart Object is therefore defined to be any – preferably quadcore – ARM device which owns the resident part of the framework, also known as Agency. The agency is able to host (several) migrating environments, also known as Mobile Entities (ME), which are executed in the smart object in an isolated memory region (domain) and which can interact with all agency services using simple, efficient and well-defined interaction schemes. MEs themselves – within a smart object – can interact together according to their type. Currently, MEs are developped on top of our SO3 operating system.
The stragegic goals of the SOO framework is:
- To buid an ecosystem composed of devices – called Smart Objects – with various interfaces to sensors, actuators, communication modules, etc.
- To have an efficient mechanism to deploy new and future versions of an application inside these smart objects
- To make strong synergies between applications possible so that they can exchange and exploit information according to their needs.
- To allow developpers to focus on their application logic without considering all aspects related to the communication between devices mechanisms and security related to data. In this sense, MEs do not care about communication protocols.
- To have a (really) fully decentralized systems which do not rely on Internet and therefore, which is capable to run completely in an autonomous way.
As it appears on the figure above, a smart object can execute one or several ME at the same time. Actually, the agency runs on three specific CPUs while a dedicated CPU is devoted to the execution of all Mobile Entities which are scheduled by the AVZ hypervisor.
From the terminology point of view, each type of smart object and associated ME is referred by a name with the “SOO.” prefix. For example, SOO.blind refers to a smart object which can drive a motor for blinds. The associated SOO.blind ME constitutes the software part which contains the software logic to set the blind up or down, and to provide the user with profile management. The user can interact with the smart object with a simple tablet or smartphone which is connected via Bluetooth.
A concrete example with SOO.domotics
SOO.domotics represents the family of smart objects developed specifically for home automation and smart buildings. As examples, SOO.blind (as mentioned before) can drive the motor of a blind, SOO.outdoor collects data from sensors embedded in a weather station, SOO.display can provide any MEs which want to display information on a HDMI or VGA screen, SOO.net can provide MEs with Internet access; this can be useful to reach the ecosystem from anywhere in the world, etc. Another example (not shown on the figure) is SOO.heat which can manage heating systems.
How does synergy work?
Synergies between applications are possible thanks to interactions between Mobile Entities (ME) themselves which are set up during their visit inside a smart object. It is obvious that such mechanisms are highly opportunistic; no idea about when a cooperation will take place, but it will. When a ME arrives in a smart object, the agency, i.e. the resident software, will couple the ME with the other running instances (which, of course, can accept or refuse such a coupling) and make possible exchange of information or even algorithms between MEs. More than that, the ME can decide to kill itself, or to kill the other ME according to its internal strategy. These operations are triggered by the agency and run on dedicated CPUs which are different than the CPU used to run a ME.
When a user interacts with a smart object via Bluetooth, it can interact with all MEs running in the smart object at this point of time. It means that the user can manipulate MEs which are not originally intended to run specifically in this smart object, as long as the MEs are able (and authorized) to expose their user interface. Hence, a user connected to a SOO.blind smart object – as it is shown on this example – can also interact with the SOO.outdoor mobile entity and retrieve data or even have access to its configuration.