CIMA documentation 1 Project objectives 1.1 Study of existing needs 1.2 Solution chosen 2 State of the work 2.1 Description 2.1.1 What is inside the CIMA platform 2.1.2 Global architecture schema (deployment diagram) 2.1.2.1 OM2M 2.1.2.1.1 state of the art (synthèse TER + nouvelles contraintes) 2.1.2.1.2 platform choice 2.1.2.2 Discovery layer 2.1.2.2.1 Discovery bundle in OM2M 2.1.2.2.1.1 Detecting new connection 2.1.2.2.1.2 Object Identification(to complete, now just for testing) 2.1.2.2.2 Semantic management of object capabilities 2.1.2.2.2.1 Identification and descritpion of capabilities 2.1.2.2.2.2 Reuse of work from the ASAWoO project 2.1.2.3 Infrastructure controller (NSCL) 2.1.2.3.1 Client notification system 2.1.2.4 Access to an objet via the gateway 2.1.2.4.1 Access via OM2M : DeviceController 2.1.2.4.2 Direct access : port forwarding (to complete, unfinished) 2.1.2.5 Discovery server on the object 2.1.2.5.1 OSGi (Equinox) 2.1.2.5.2 SAJE (unfinished, to complete) 2.1.2.5.3 Capability provider (object specific) 2.1.3 Internal functioning 2.1.3.1 OSGi / OM2M (links to docs) 2.1.3.2 Static diagrams (classes: domaine + implem) 2.1.3.3 Dynamic diagrams (communication) 3 HOW TO USE CIMA 3.1 Installation 3.1.1 Cloud 3.1.2 Gateway 3.1.3 Object : Installation osgi on the object 3.2 Use 3.2.1 Client 3.2.1.1 Connection to the NSCL 3.2.1.1.1 Registering : post on InfrastructureController 1/17 3.2.1.1.2 Notification system : several methods, OM2M­based 3.2.1.2 InfrastructureController API 3.2.2 Creating a server on the object 3.2.2.1 ServerInfos & WotCapabilityExposer APIs 4 Remaining work / perspectives 4.1 Complete / test unfinished parts 4.2 Create a manual configuration interface for new objects 4.3 Implement other servers / CapabilityProviders 4.4 Create a "lightweight server" for resource limited objects 4.5 Manage objects not connected with IP (USB, HDMI...) 1 Project objectives 1.1 Study of existing needs 1.2 Solution chosen 2 State of the work 2.1 Description 2.1.1 What is inside the CIMA platform Layer­platform interoperability Materials Applications (CIMA) is a project to meet needs unmet by existing within the LIRIS platforms to facilitate the reuse of common hardware for many types of applications, it either as part of experiments for research and demonstrations to external partners. This platform will be installed on a dedicated structured framework in several layers machine. Needs expressed by this project will be listed in detail in the section of the state of the art (below). ❏ OASIS : is a platform that relies on a server to retrieve the flow of video cameras and send it to one or more clients through the network in real time. ❏ Voir : is a platform that allows both to create new recognition algorithms and use these algorithms for higher level applications. ❏ UbiWare : is an application level protocol developed for accessing data by exposing the data in REST services, peer to peer. ❏ PupInt : is a platform for the use of various hardware components of interaction (screens, touch screens, ...). Based on the OM2M framework, we developed the CIMA platform that is composed of a gateway part and a cloud part. In cima platform, we have two parts: 2/17 ❏ Gateway part: GSCL: A gateway module runs a M2M application which offers M2M capabilities and act as a bridge between M2M devices and the M2M Access Network. In GSCL we implemented a gateway application (GA) that behaves like a directory of connected objects and must make a discovery service to detect connections of different objects on the local network in different exhibitors information concerning as the identifier, the communication protocol, the uri or the contact address of the object which are then sent to the NSCL, and some additional information to enable clients to contact objects without using the GSCL namely the gateway address and the port of cloud­device communication in the gateway that are sent to a CIMA server running on the gateway and to short­circuit the GSCL. C server: We set up a server in C using sockets which serves as a bridge between the device and the cloud. This server opens two sockets for each device in the gateway as follows: A first socket to read data from the cloud to transfer them to the second socket and the other for transferring the data from the second socket to the cloud. The second socket to read data from the first socket for transferring the device and transfer data from the device to the first socket. Thus, clients who subscribe to the NSCL can directly contact the object without going through the OM2M layer. ❏ Cloud part: NSCL: In this Part we have NA (Network Application) , clients subscribe close to it to receive notifications when the connection or disconnection of a device. 3/17 2.1.2 Global architecture schema (deployment diagram) 2.1.2.1 OM2M 4/17 2.1.2.1.1 state of the art (synthèse TER + nouvelles contraintes) This state of art focused on the application and functional side of open source M2M solutions. The needs expressed by the platform CIMA are as follows: ❏ Connecting an object (sensor, camera, robot) with different types of connectors (ZigBee, Bluetooth, USB, Wifi, Ethernet ...). ❏ Detection and discovery of various functionalities of a connected thanks to a declarative language for describing the object. ❏ Offrir la possibilité : ❏ To access data from the sensors. ❏ To send commands to actuators. ❏ To deploy and execute code on the connected objects. ❏ Allow short­circuited the solution itself in order to avoid a bottleneck for high performance applications. Differents studies criteria we selected were therefore as follows: ❏ Genericity: A solution will be more generic it is agnostic platform, OS agnostic or agnostic language. In summary, the desired solution must be as independent as possible of the specific hardware, operating system on which it is deployed. It must also implement a wide range of protocols (application, network, data link ...) and in the best case able to withstand a wide range of programming languages. ❏ Correspondence with the objectives of the project ASAWoO: To give a guideline in this state of the art online, we integrate our criteria matches the between use cases of the solution and objectives ASAWoO project. ❏ Community: Community revolving around the project is an important criterion. Indeed, motivation, investment provides energy around the project. The community includes both users and professional developers or "hobbyists". To judge that we can measure the activity of a forum, a mailing list, support or documentation. ❏ Licence : The license of the solution must above all be Open Source. The needs expressed do not mention a willingness to use a proprietary and / or under paid license solution. A license to modify at will the source code would be a plus as the needs expressed by the ASAWoO project are unlikely to result in a turnkey solution. Solutions studied: OM2M: 5/17 “The OM2M project, initiated by LAAS-CNRS, is an open source implementation of the ETSI M2M Standard. It provides a horizontal M2M service platform for developing services independently of the underlying network, with the aim to facilitate the deployment of vertical applications and heterogeneous devices.” “OM2M exposes a RESTfull API providing primitive procedures for machines authentication, resources discovery, applications registration, containers management, synchronous and asynchronous communications, access rights authorization, groups organisation, and re­targeting.” “OM2M is a Java implementation running on top of an OSGi Equinox runtime, making it highly extensible via plugins. It is built as an Eclipse product using Mave, and Tycho. Each plugin offers specific functionalities, and can be remotely installed, started, stopped, updated, and uninstalled without requiring a reboot.” DeviceHive DeviceHive is a framework of M2M (Machine to Machine) open source, developed by the company DataArt. The purpose of this framework is to provide the basic building blocks for the low-level communication between connected objects so that developers focus more on the functionality of the client applications. The architecture of the framework is divided into 3 parts: The device part concerns the deployment of code on a connected object. The framework manages NET languages., C / C + +, J2EE, Python, Android and iOS. There is therefore a wide range of implementations but concerns cross-compilations may appear except for Python and J2EE, but connected objects must have a processing power capable of an interpreter or a virtual machine running. At the communication layer, the framework can handle two types of objects: those with a TCP / IP stack with a protocol based on the REST pattern and those that have none with management some binary protocols (USB, ZigBee, Bluetooth, ...). The bridge portion is to bridge the gap between the objects with no TCP / IP stack and the Internet. This part is supposed to aggregate and redistribute messages between the objects and the Cloud. The classic implementation of the gateway is to the translated binary protocol REST protocol and vice versa. The framework handles. NET languages, C + +, Python and J2EE for this part. The gateway does not usually running on a platform high stress, independence with respect to the platform and the OS can be obtained through the use of languages ​that are high portability Java and Python. The client side which is a consuming application web services offered by objects connected.