top of page




In general, the FourC Groovy M2M Cloud System consists of the Cloud System itself and devices running the FourC Groovy M2M Device Platform, or devices implementing a subset of the communication protocol in use.

FourC Groovy M2M Cloud System Architecture


The Cloud System is a web service enabled installed backend system with an optional html5-based GUI. It integrates an SQL database and with business logic in Java. The Cloud System can actually also be installed on company servers in case the customer chooses so.


The Cloud System's web service interface is fully available for the system owner, and can be used to implement any functionality towards the data within the system and the database. This opens up the possibility for innovative and custom applications for any purpose for the system owner. E.g., the system owner can provide data to public external interfaces by implementing lightweight proxies that validate and relay the queries.



Device Platform Architecture


The Device Platform is a highly optimised low level/middleware layer consisting of the boot system, the Linux kernel, the system software, all FourC developed components and the messaging provider. 


The Device Platform is mostly agnostic to any end-user applications that is deployed on it. Using virtualization, any application is installed in its virtualized environment, meaning it is fully secured and cannot break other applications running on the same device. The application environment has its own network IP address, and can use the Device Platform as the router.


There is an established belief that virtualization breaks the space constraints on embedded devices. However, by carefully choosing the application distributions to use on the device, the FourC Groovy M2M Device Platform includes storage deduplication routines ensuring that equal files across different application environments can be deduplicated on disk. Similarly, memory usage can be deduplicated if the same libraries and executables are used across several application environments. All this happens transparently and unnoticed by the application itself and is a huge space-saver on embedded devices. 


As an example, FourC has demonstrated running 100 independent application environments on a 64MB embedded system.



Messaging Sub-system


Messaging is currently based on AMQP, the international standardized protocol for advanced messaging and queuing. Features include time-to-live attributes on messages and store-and-forward, persistent, queued message handling even over reboots and power failures.


FourC has mapped every application within every device to a well-defined namespace, meaning that every component within every application can address any other component that is connected, provided appropriate permissions are in place.


Application designers can be allowed to use this messaging sub-system to ease the burden of having to implement a communication middleware system of their own. This means that the Device Platform's messaging component can act as the local message "post office" for the top-level applications. Still, there is full freedom within top-level applications to use any other kind of messaging or communication framework if the designer should choose to do so.


The messaging subsystem always ensures that data OTA never uses more bandwidth than necessary.



bottom of page