[{"nid":"9737","project_id":"iot.hono","short_project_id":"hono","name":"Eclipse Hono","summary":"Eclipse Hono\u2122 provides remote service interfaces for connecting large numbers of IoT devices to a back end and interacting with them in a uniform way regardless of the device communication protocol.\n\u00a0...","description":"\u003Cp\u003EEclipse Hono\u2122 provides remote service interfaces for connecting large numbers of IoT devices to a back end and interacting with them in a uniform way regardless of the device communication protocol.\u003C\/p\u003E\n\u003Cp\u003E\u0026nbsp;\u003C\/p\u003E\n\u003Cp\u003EConnectivity is at the heart of IoT solutions. Devices (things) need to be connected to a back end component where the data and functionality of the devices is leveraged to provide some higher level business value. IoT solution developers can pick from a wide array of existing (open source) technology to implement a device connectivity \u0026amp; management layer for the particular type of devices at hand. While this is often fun for the developers to do, the resulting solutions are often silo applications lacking the ability to scale horizontally with the number of devices connected and the number of back end components consuming the device data and functionality.\u003C\/p\u003E\n\u003Cp\u003E\u0026nbsp;\u003C\/p\u003E\n\u003Cp\u003EThe Eclipse IoT Working Group has therefore discussed \u0026nbsp;a more generic, cloud-based IoT platform architecture which better supports the implementation of IoT solutions without requiring developers to solve some of the recurring (technical) challenges over and over again. The diagram below provides an overview of the IoT Server Platform as discussed in the working group.\u003C\/p\u003E\n\u003Cp\u003E\u0026nbsp;\u003C\/p\u003E\n\u003Cp\u003E\u0026nbsp;\u003C\/p\u003E\n\u003Cp\u003EThe diagram shows how devices in the field are connected to a cloud-based back end either via a Field Gateway (e.g. something like Eclipse Kura) or directly to so-called \u003Cem\u003EProtocol Adapters\u003C\/em\u003E. The Protocol Adapters\u0027 responsibility is abstracting communication protocols as well as providing location transparency of devices to the other back end components. The devices upload (sensor) data to the back end while the functions\/services they expose can be invoked from the back end. These two directions of information flow can be characterized as follows:\u003C\/p\u003E\n\u003Cul\u003E\n\u003Cli\u003ETelemetry\u003Cbr\u003E\u003Cbr\u003E\n\t\u003Cstrong\u003EData\u003C\/strong\u003E flowing downstream (left to right) from devices to the back end to a consumer like a Business Application or the Device Management component usually \u003Cstrong\u003Econsists of\u003C\/strong\u003E\u0026nbsp;a small set of discrete values like \u003Cstrong\u003Esensor readings\u003C\/strong\u003E or status property values. In most cases these messages are one-way only, i.e. devices sending this kind of data usually do not expect a reply from the back end.\u003C\/li\u003E\n\u003Cli\u003ECommand \u0026amp; Control\u003Cbr\u003E\u003Cbr\u003E\n\t\u003Cstrong\u003EMessages\u003C\/strong\u003E flowing upstream (right to left) from back end components like Business Applications often \u003Cstrong\u003Erepresent invocations of services\u003C\/strong\u003E or functionality provided by connected devices, e.g. instructions to download and apply a firmware update, setting configuration parameters or querying the current reading of a sensor. In most cases a reply to the sent message is expected by the back end component.\u003C\/li\u003E\n\u003C\/ul\u003E\n\u003Cp\u003EIt seems reasonable to assume that the number of messages flowing upstream (Telemetry) will be orders of magnitude larger than the number of messages flowing downstream (Command \u0026amp; Control). The aggregated overall number of messages flowing upstream is expected to be in the range of several hundred thousand to millions per second. Note that in this architecture the same (cloud-based) infrastructure is shared by multiple solutions.\u003C\/p\u003E\n\u003Cp\u003E\u0026nbsp;\u003C\/p\u003E\n\u003Cp\u003EThe IoT Connector component provides the central link between the device-facing Protocol Adapters, additional re-usable back end components, e.g. Device Management or Software Provisioning, and last but not least the IoT solutions leveraging the devices\u0027 data and services. Solution developers can use the IoT Connector to uniformly and transparently interact with all kinds of devices without the need for caring about the particular communication protocol(s) the devices use. Multiple solutions can use the same IoT Connector instance \u003Cstrong\u003Erunning in a shared cloud environment\u003C\/strong\u003E in order to \u003Cstrong\u003Eshare the data and functionality of all connected devices\u003C\/strong\u003E. The IoT Connector ensures that only those components can consume data and control devices that have been granted authorization by the device owner. In this regard the IoT Connector can be considered an IoT specific message broker targeted at cloud deployment scenarios.\u003C\/p\u003E\n\u003Cp\u003E\u0026nbsp;\u003C\/p\u003E\n\u003Cp\u003EThe IoT Connector component needs to fulfill a set of\u0026nbsp;\u003Cstrong\u003Enon-functional requirements\u003C\/strong\u003E, in particular regarding\u0026nbsp;\u003Cstrong\u003Ehorizontal scalability\u003C\/strong\u003E, that are specific to both the deployment environment (cloud) and the intended architectural platform characteristics (as opposed to embedding a connectivity layer into applications individually). However, these requirements are not specific to any particular application domain. From a technical point of view it makes no difference if a sensor reading received via a LWM2M protocol adapter represents a temperature or the relative humidity. In both cases the IoT Connector\u0027s responsibility is to forward the messages containing the values to (potentially multiple) authorized consumers without introducing too much latency.\u003C\/p\u003E\n\u003Cp\u003E\u0026nbsp;\u003C\/p\u003E\n\u003Cp\u003E\u003Cstrong\u003EFeatures at a glance\u003C\/strong\u003E\u003C\/p\u003E\n\u003Cul\u003E\n\u003Cli\u003ESecure message dispatching\u003C\/li\u003E\n\u003Cli\u003ESupport for different message exchange patterns\u003C\/li\u003E\n\u003Cli\u003EUsed for cloud service federation\u003C\/li\u003E\n\u003Cli\u003EProvides interfaces to support implementation of protocol adaptors which allow:\n\u003Cul\u003E\n\u003Cli\u003ESending telemetry data\u003C\/li\u003E\n\u003Cli\u003EReceiving device control messages (from applications\/solutions)\u003C\/li\u003E\n\u003Cli\u003ERegistering authorized consumers of telemetry data received from connected devices\u003C\/li\u003E\n\u003C\/ul\u003E\n\u003C\/li\u003E\n\u003C\/ul\u003E\n\u003Cp\u003EKey words: Device Connectivity, IoT, Device Control, CoAP, AMQP, MQTT, HTTP, Data Ingestion, Kafka\u003C\/p\u003E\n","url":"https:\/\/projects.eclipse.org\/projects\/iot.hono","website_url":"https:\/\/www.eclipse.org\/hono","website_repo":[{"url":"https:\/\/github.com\/eclipse-hono\/hono-website","source_branch":"main","checkout_dir":"hono"}],"logo":"https:\/\/projects.eclipse.org\/sites\/default\/files\/styles\/project_logo\/public\/HONO-Logo_Bild-Wort_quadrat-w-200x180px.png?itok=G7R8Vn3j","tags":["mqtt m2m iot messaging amqp coap"],"licenses":[{"name":"Eclipse Public License 2.0","short_name":"EPL-2.0","url":"http:\/\/www.eclipse.org\/legal\/epl-2.0"}],"github_repos":[],"github":{"org":"eclipse-hono","ignored_repos":[]},"gitlab_repos":[],"gitlab":{"project_group":"","ignored_sub_groups":[]},"gerrit_repos":[],"contributors":[],"committers":[{"username":"matthiask","full_name":"Matthias Kaemmer","url":"https:\/\/api.eclipse.org\/account\/profile\/matthiask"},{"username":"clohmannxg7","full_name":"Carsten Lohmann","url":"https:\/\/api.eclipse.org\/account\/profile\/clohmannxg7"},{"username":"khudalla","full_name":"Kai Hudalla","url":"https:\/\/api.eclipse.org\/account\/profile\/khudalla"},{"username":"dbosanac","full_name":"Dejan Bosanac","url":"https:\/\/api.eclipse.org\/account\/profile\/dbosanac"}],"project_leads":[{"username":"dbosanac","full_name":"Dejan Bosanac","url":"https:\/\/api.eclipse.org\/account\/profile\/dbosanac"},{"username":"khudalla","full_name":"Kai Hudalla","url":"https:\/\/api.eclipse.org\/account\/profile\/khudalla"}],"working_groups":[{"name":"Internet of Things (IoT)","id":"internet-things-iot"}],"industry_collaborations":[{"name":"Internet of Things (IoT)","id":"internet-things-iot"}],"technology_types":["IoT and Edge"],"spec_project_working_group":[],"state":"Regular","provisioned":true,"latest_release_name":"2.4.1","releases":"https:\/\/projects.eclipse.org\/api\/projects\/iot.hono\/releases","top_level_project":"iot","slsa":{"build_level":""},"dev_list":{"name":"hono-dev","email":"hono-dev@eclipse.org","url":"https:\/\/accounts.eclipse.org\/mailing-list\/hono-dev"},"mailing_lists":[],"reviews":"https:\/\/projects.eclipse.org\/api\/projects\/iot.hono\/reviews","documentation_url":"https:\/\/www.eclipse.org\/hono\/docs\/","gettingstarted_url":"https:\/\/www.eclipse.org\/hono\/docs\/getting-started\/","download_url":"http:\/\/www.eclipse.org\/hono\/downloads\/","scope":"\u003Cp\u003EEclipse Hono\u2122 provides \u003Cstrong\u003Eremote service interfaces\u003C\/strong\u003E for connecting \u003Cstrong\u003Elarge numbers of IoT devices\u003C\/strong\u003E to a back end and interacting with them in a \u003Cstrong\u003Euniform\u003C\/strong\u003E way regardless of the device communication protocol.\u003C\/p\u003E\n\u003Cp\u003E\u0026nbsp;\u003C\/p\u003E\n\u003Cp\u003EHono specifically supports scalable and secure ingestion of large volumes of sensor data by means of its Telemetry and Event APIs. Hono\u0027s Command \u0026amp; Control API allows for sending commands (request messages) to devices and receive a reply to such a command from a device in an asynchronous way.\u003C\/p\u003E\n\u003Cp\u003EFinally, Hono provides APIs for integration with existing device and credentials management systems.\u003C\/p\u003E\n\u003Cp\u003EThe Hono project provides implementations of the remote service interfaces mentioned above, leveraging existing messaging infrastructure components. \u003Cstrong\u003EIt is not the project\u0027s intention to create an additional message broker\u003C\/strong\u003E\u0026nbsp;implementation.\u003C\/p\u003E\n\u003Cp\u003E\u0026nbsp;\u003C\/p\u003E\n","security_team":{"individual_members":[],"groups":{"include_committers":true,"include_project_leads":false}}}]