Versions Compared

Old Version 1

changes.mady.by.user Theodor Rohde

Saved on

compared with

New Version 2

changes.mady.by.user Theodor Rohde

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

This common question often arises from integrators who run their own type of IoT platform tailored to a particular use-case. In contrast to this our platform is primary considered for device management of Lobaro and 3rd party sensors and gateways. It's meant as secure abstraction layer to the actual hardware and gives the following benefits to the integrator or end-user:

  • Client Asymmetrically encrypted data transfers, client and server certificate-based secured data transfers , using DTLS between hardware and Lobaro while maintaining battery lifetime friendly UDP data transfers over NB-IoT, while still being able to use battery life friendly UDP transfers with little overhead.
  • Administration of client and server certificates.
  • Remote configuration of sensors via simple Functionality for remote configuration updates using simple standardized APIs (HTTPS PUSH, REST, MQTT, SFTP)
  • Functionality to trigger remote firmware updates if new features become available or a security update must be deployed
  • Providing a simple frontend for data retrieval independent of any upstream external system 
  • Merging different sensor technologies (e.g. Wireless-MBUS, LoRaWAN, NB-IoT) to create a uniform interface for connecting external systems and platforms.
  • .
  • Support for Firmware Updates Over The Air (FOTA).
  • Intermediate storage for sensor data before further processing in the downstream platform.
  • Simple interface independent of downstream platform with CSV export of data for simple applications.
  • Possibility of merging sensors of different wireless technologies (NB-IoT, LoRaWAN, wireless MBUS) with uniform API to the downstream system.
  • Quickly bring IoT applications to market by focusing on the use case and the actual Fast time to market for integrators and platform operators, as they can focus on the use case and data without having to deal with hardware -dependent and firmware implementation details of or secure data transfers with unknown hardware.Small memory footprint can in most cases run in parallel to your own system on your serverfrom the sensor / gateway.
  • Usually low hardware requirements for the server on which the on-premise instance of the Lobaro Platform is installed. Often it can run in parallel on a server next to the use-case specific platform.
  • Internal APIs between hardware and Lobaro Platform can be changed, e.g. for firmware extensions, without compromising a stable API to the downstream system and thus increasing the stability of the end application.

As you can see, all these functions require a high level of knowledge about the hardware and how it works. Lobaro can only provide support for the direct, secure and correct integration of its own hardware in exceptional cases. In the vast majority of cases, the manageable prices for using the Lobaro Platform are the economically much better option.