OVERVIEW
Abstract: This two pages document is intended to give you a good understanding about how the NearBus system works and which is its main focus.
Why is NearBus Different ?
The "Power Bit" paradigm
To understand the difference between NearBus and a traditional Messaging protocol we need to start with the objective that each was designed for. In Internet of Things (which is different to Things on Internet) the connected "things" are by definition very simple devices even without intelligence (physical objects without processing capabilities) so they usually have a simple behavior and reduced control capabilities.
For example, in an electrical home heating system each electric heater will only have two states ON and OFF(*), that means that only 1 bit will be necessary to control a 2000W power device few times an hour. On the other hand a temperature sensor will typically provide 10 bit readings a dozen times an hour in order to offer good accuracy and response time.
From the security point of view a failure or loss of connectivity in the temperature sensor (independently if it is caused by a HW issue or a hacker attack) represents a affrodable risk because in this situation the Local Controller can simply disconnect the attached heater and no high damage will be accomplished.
But with a Cloud controlled heater the scenery is completely different. A failure in the communication system (or a malicious attack) could leave a 2000W heater out of control and the damages could be higher.
This simple example shows that the procedure used to control power devices has different requirements than the system used to read sensor devices.
Following this line of thinking the NearBus system has been developed to fill the gap that today exists to control devices through internet, mainly because most of the protocols are designed to work as sensor protocols and do not solve completely these issues in the Internet of Thing context.
(*) usually a power heater is discretely controlled because its high thermal inertia .
The "Cloud-Alive" Protocol
In contrast to the traditional sensor oriented protocols that are defined to Get/Read data from low power devices the NearBus is defined as a Keep-Alive protocol.
That means that the main function of each NearBus Agent (that consumes the 90% of its limited resources) will be to survive in a hostile environment and report its state to the cloud in a periodic way.
Additionally with each Keep-Alive the agent synchronizes a small piece of the microcontroller's memory, the Memory-Map, with the Cloud in order to Get and Post (read/write) the required parameters.
Under this paradigm the main focus of the NearBus system will be to assure that the connection is UP and Reliable and when some issue arises will solve it as soon as possible (for example restarting the HW). As a last resort, if this is not possible, the Agent will lead to a predictable Power OFF state.
This paradigm allows to NearBus to reach a high level of availability mainly because the link is permanently under supervision so the failures will usually be detected and fixed before a control action is executed.
NearBus Safe Mode
NearBus implements several safety features in order to improve the availability. As example the NearBIOS outputs can be configured in safe mode when they manage Power Loads. Under this mode the output never remains turned ON in a permanent way. Instead the outputs work as monostable outputs so the Cloud controller should refresh the ON state before it go to LOW (x seconds). This technique assure than under a connectivity blackout the system will show the same behavior than under a power blackout.
Note: This feature is not available at the current release, if you are interested in try it please contact us al info@nearbus.net.
Main Features
The main features of the NearBus System are:
+ NearBus is really a Platform Independent solution, integrating in the same system different MCU hardwares in a transparent way (for example you can implement a home temperature control system using Arduino for controlling the power heater and OpenPicus for sensing the temperature).
+ NearBus is an Open and Free platform (all the NearBus SW components are Open Source and Free).
+ NearBus allows you to "read" and "write" registers in your MCU from the Cloud without any computer interaction (NearBus is a PC-Less system).
+ NearBus is easy to integrate in any MCU platform (the communication works like a simple function call in each of the end points ( the NearBus Agent and NearBus API).
+ NearBus offers a Real Cloud Experience because it does not require any local computer processing (the MCU is connected directly to the cloud in a native way).
+ NearBus allows you to deploy all the intelligence of your remote device on the cloud, reducing the complexity and deploying time of yours projects.
+ Thanks to the Transparent Mode NearBus is extremely easy to integrate in your deployed projects, giving you the incredible power of interconnecting them in the Cloud.
+ NearBus allows you to make MCU devices around the world interact via internet in pseudo real time at no cost so the possibilities are almost unlimited.