A probe into the domestic internet of Things Platform (eight): China Mobile IoT open platform Onenet

Platform positioning

Onenet is one of the open and win equipment cloud platform built by the Mobile IoT Co., Ltd., which provides easy cloud access, storage, computing and presentation for a variety of cross-platform IoT applications and industry solutions, rapidly creating networked product applications and reducing development costs.

IoT PAAs Infrastructure: Provides smart device self-service development tools, back-Office support services, Internet of Things network, short MMS, location, device management, message distribution, remote upgrade and other basic services

SaaS Business Services: Provide a third-party application development platform to quickly meet different business needs and quickly build web and app applications with light-application incubators

IoT Data Cloud: Provides multi-dimensional business operations services such as highly scalable databases, real-time data processing, intelligent predictive offline data analysis, data visualization, and more

Developer community: The high-frequency developer community, bringing together different sources of knowledge and bringing together more IoT enthusiasts to get projects and development started to spread

Architecture

As a PAAs layer, onenet bridges the SaaS layer and IaaS layer, providing the core capabilities of the middle tier, respectively, upstream and downstream.

Application Scenarios

Platform Features

Platform Information Model

Terminology Introduction

• Product ID (Products ID, PID)
  • Product ID refers to a separate ID number assigned by onenet backstage to your real product, and if you have a product with two different series (e.g. Iphone7/iphone7 PLUS), it is recommended to create two products to obtain two product IDs respectively.
• APIKey
  • For authentication and permission control for onenet operations, the header domain of the HTTP request message must carry the Apikey field when using the Onenet Restful API. The onenet will determine whether the user has permissions to the corresponding action based on the Apikey field.
  • The permission model of Apikey is described by setting whether the cloud resources can be added, viewed, modified, deleted, etc., and the lowest permission level can be refined to the access to a data stream. Apikey are divided into two types:
  • 1. Product Apikey: When creating a product, Onenet generates a default apikey for the product, which is masterkey and has the maximum permissions to access All resources under the product.
  • 2. Device Apikey: The user creates a key for a device under a product called the device Apikey, the function of the device Apikey is limited to the resources of the device , but not to other devices access operation.
• Equipment
  • The "Device" in the cloud refers to the entity under the "product" mentioned above, and also refers to the unique virtual name of a real device of a user on onenet.
• Unit ID (Device ID, did)
  • Device ID is an independent and unique ID number assigned by Onenet backstage to one of your real devices, with multiple devices under one product and a unique device ID for each individual device.
• Registration Code (Register code)
  • A product has a unique registration code, which is used as a parameter in the API for device registration.
• Device number
  • When a user creates a device on onenet, if the device Access protocol chooses HTTP, the device number needs to be filled in. The device number is the unique identification number owned by each real device, does not require onenet background assignment, the user can customize the device number, but must guarantee the independence and uniqueness between each device, it is recommended that the user enter the device number with the serial number of the original product line.
• Authentication information (auth_info)
  • When a user creates a device on onenet, if the device access agreement chooses EDP or MQTT, then the authentication information needs to be filled in. Authentication information is the unique identification number of each real device, does not need onenet background assignment, the user can customize authentication information, but must ensure the independence and uniqueness between each device, it is recommended that users enter the authentication information using the serial number or MAC address of the original product line.
• SN (serial number, serial numbers)
  • That is, each real device unique identification number, provided by the user, its role is to implement the device binding function.
  • Please note: in essence, the device number, authentication information , and SN all represent the unique and independent identity code that each of the user's real devices has, and the effect is the same. For onenet to accurately locate which product under which device, the reason why they are not uniform, because the use of different protocols to access the device, the background part of the system because of planning reasons, the original components generally maintain the definition under this agreement, so the interface still follows the initial wording, You just need to know from the role: Device number = authentication information =SN on it.
• Data Flow (Datastream)
  • A data stream can be understood as a class of data, such as the temperature of the sensor, the latitude and longitude of the position, the humidity of the air. Users can customize the data flow name, which is the data flow ID, and one device can add multiple data streams.
• Data points (Datapoint)
  • That is, a specific data value in a data stream. Data points are stored in a "key-value" manner. Where key consists of device ID, data stream ID, time, and so on, the value part can be any data object, such as an integer, string, or JSON data type.
• Sdk
  • Standard Protocol Product SDK: The end-side software development Kit for the Open protocol of the device Access Protocol, Onenet provides the SDK for multiple languages, providing the basic functions of device connection, data uploading and so on.
  • Private Protocol Product SDK: When using the private protocol to access the device, Onenet will automatically generate the SDK source code according to the developer-defined device data model, and the developer will embed the SDK into the device and automatically interface with the platform. Onenet provides the SDK full source for proprietary protocol products.

Overall access process

Device Access

• Create a product on the Onenet platform
  • Create a device in the product to add data flow to the device.
  • Device end to write terminal access code, mainly to complete  protocol encapsulation, data upload and other work.
  • After the data upload of terminal equipment is successful, the platform will generate data points over time in the corresponding data flow.
  • In order to visualize the changes in the data, users can use the application incubator to customize and publish personalized applications.
• Devices can be interfaced to the platform via private protocols and standard protocols
• Private protocol Description:
  • RGMP (Remote Gateway Management Protocol) is the Platform's private protocol, the platform does not provide protocol message description, according to the developer-defined device data model, the platform will automatically generate the SDK source code, the developer will embed the SDK into the device, to achieve the docking platform.
• Standard protocol Description:
  • including http,edp,mqtt,modbus,jt/t808. The platform provides a message description document for each protocol, the developer can implement the protocol of the device and platform according to the document, and the platform can be interfaced with the corresponding protocol SDK provided by the platform.

Standard protocol –EDP Protocol

• The EDP Protocol (enhanced device Protocol) is a fully exposed TCP-based long-connection protocol that is specifically tailored to the IoT features of the Onenet platform, providing features such as device access, encrypted transmission, data storage, and the features and functions of the protocol, including:
• Long Connection Protocol
  Terminal data point escalation, supported data point types include
  • Integral type (int)
  • Floating point (float)
  • Strings (String)
  • Json
  • Binary data
• Platform data issued
• End-to-end data forwarding

Standard protocol –modbus Protocol

• The Modbus protocol is a general industry standard protocol applied to electronic controllers. This protocol supports legacy RS-232, RS-422, RS-485, and Ethernet devices. Typical industrial equipment including PLC, DTU and so on are using Modbus protocol as a standard protocol between them, the features and functions of the protocol include:
• Long Connection Protocol
• Onenet Platform for Modbus host
• Determine the content and periodicity of a single command through the properties of a single data stream
• Automatically convert terminal escalated data to data points in the data stream

Standard protocol –MQTT Protocol

• The MQTT protocol is an Instant messaging protocol for IoT applications that uses TCP/IP to provide network connectivity, enable message masking for payload content, reduce overhead, and effectively lower network traffic, and the features and functions of the protocol include:
• Long Connection Protocol
• Terminal data point escalation, supported data point types include:
  • Integral type (int)
  • Floating point (float)
  • Strings (String)
  • JSON format
• Platform Message issued
• Topic-based subscription, publishing, and message push enable message unicast and multicast between devices

Standard protocol –http Protocol

• Onenet support devices using the HTTP protocol is to follow the restful principle of access to the platform, the protocol has access authentication, control commands issued, alarm starting and other functions, suitable for platform and platform data docking, its features and functions include:
• Short Connection Protocol
• Terminal data point escalation, supported data point types include:
  • Integral type (int)
  • Floating point (float)
  • Strings (String)
  • JSON format
  • Binary data
• Platform-side related resource management

Standard protocol –jt/t808 Protocol

• Onenet defines an extension protocol jtext based on the jt/t808 protocol, which enables fast access to the platform for devices that have already transmitted data based on the JT/T808 protocol, including the features and functions of the Protocol:
• Ministry of Transport customized standard communication protocol for vehicle dynamic monitoring
• Equipment and platforms can be long connected to detect the upper/lower status of the equipment in time
• Standard "Location information reporting" and other message formats to facilitate terminal fast access platforms that already support the JT/T808 protocol
• Based on "up/Down data transmission" mode, can flexibly upload user-defined data, query the latest data response

Private Protocol –RGMP Protocol

• To simplify the developer's development process and improve the security of user device data transmission, Onenet provides a dedicated private protocol for the device access platform, the RGMP protocol (Remote Gateway Management Protocol).
• The biggest difference between the RGMP agreement and the public agreement is that the Onenet platform does not provide the protocol's message description, but instead automatically generates the SDK source code based on the developer-defined device data model, and the developer embeds the SDK into the device for docking with the platform.
• The RGMP protocol has the advantages of flexible business data format, compact and efficient data transmission and high real-time performance, and its main features and functions include:
• Private message format ensures data security
• Remote Configuration Updates
• Platform Notification Information issued
• Remote firmware upgrade (OTA)
• Terminal data point escalation, supported data point types include:
  • Integral type (int)
  • Floating point (float)
  • Strings (String)
  • Binary data
  • Boolean value

Third-party platform access

• Used by developers to develop their own personalized business systems using data push and API services provided by onenet
• In the Onenet platform, fill in the third-party URL address to receive the data, the URL address should be an accessible address, and provide token verification of the Get method;
  • Token value as the user's identity on onenet, used for message digest
  • After randomly generating encodingaeskey and selecting message Plus decryption mode
  • The user can edit and modify the configuration content that has been configured successfully

Third-party platform access-data push message format

• The platform registers addresses with HTTP POST requests to the third-party platform to push data, pushing data-related information in the form of a JSON string into the body part of the HTTP request.
• When the third-party platform receives the data, it receives the plaintext or ciphertext message of the data according to the encryption selection.
• Clear Text Format
  • Depending on the msg part of the Type field, it can be divided into a number of point messages, device downline messages
  • In clear text transmission, there is MSG, Msg_signature, nonce fields, respectively, the data transmitted in clear text, msg part of the message digest, for summary calculation of the random string
• Ciphertext format
  • In the case of encrypted transmissions, there are enc_msg, Msg_signature, nonce fields, the Enc_msg field represents the encrypted transmitted data, and the second two fields are consistent with the plaintext transmission

Third-party platform access-encryption and decryption scheme

• Platform provides encryption and decryption technology based on AES algorithm
• The Encodingaeskey is the BASE64 encoded form of the message plus decryption key, which is fixed at 43 characters, and is selected from a total of 62 character a-z,a-z,0-9. When the service is opened, you can also apply for changes.
• The AES key is computed as Aeskey=base64_decode (encodingaeskey + "="), encodingaeskey the trailing "=" of a character, and generates 32 bytes of Aeskey with Base64_decode.
• AES uses CBC mode, the key length is 32 bytes (256 bits), the data is filled with pkcs#7, the initial IV vector takes the key 16 bytes;
  The PKCS#7:K is the secret key byte number (using a), the BUF is the content to be encrypted, and N is its number of bytes. Buf needs to be filled with an integer multiple of K. The tail padding (k-n%k) bytes in buf, the content of each byte is (k-n%k).
  Detailed Details: http://tools.ietf.org/html/rfc2315
• BASE64 in MIME format, characters include 26 uppercase and lowercase letters, plus 10 digits, and a plus sign "+", a slash "/", a total of 64 characters, and an equal sign "=" as a suffix fill;
  For security reasons, the Platform Web site provides the ability to modify the Encodingaeskey (when the encodingaeskey may be compromised, corresponding to the encrypted symmetric key of the received message that was filled in on the third-party platform application), It is recommended that the current and previous encodingaeskey be saved, and if the current Encodingaeskey generated Aeskey decryption fails, then the decryption of the previous Aeskey is attempted.
• The encrypted message portion of the platform is enc_msg= Base64_encode (Aes_encrypt[random (16B) +msg_len (4B) +msg]), which is a byte string with a 16-byte random byte string stitching 4 bytes representing the length of the message body ( Here the 4 byte length is expressed as the network byte order, plus the byte string of the message itself as the plaintext of AES encryption, and then encrypt the plaintext by AES algorithm, and finally encrypt the cipher message body with BASE64 encoding operation.
• The decryption process of the encrypted message body is: 1) First the BASE64 decoding operation of the encrypted message body, Aes_msg=base64_decode (enc_msg), 2) The decoded content of the acquisition is decrypted with the AES algorithm, the clear text portion is obtained, Plain_msg=aes _decrypt (aes_msg), the key used in decryption is computed by Encodingaeskey, the initialized IV vector used is the first 16 bytes of the computed AES key, 3) The first 16 bytes of the plain_msg are removed, and the previous 4 bytes take out the message body length, Gets the true message part based on the length of the message body (it is recommended to get the real message in the length of the message to be compatible with plain_msg possible future structural changes).

Third-party platform Access-summary calculation scheme

• In order to verify the legality of the message body, each platform push message contains the message signature, the third party can be used to verify the authenticity of the message body, the plaintext message to the whole of the MSG part of the summary calculation, ciphertext message to enc_msg part of the whole summary calculation. The following are the specific practices:
• MSG_SIGNATURE=BASE64 (MD5 (sort (token+ nonce+ enc_msg/msg)), that is, by token, nonce (8-byte random string), message body (plaintext or ciphertext) in the order in bytes as a whole, calculates its MD5 value and presses BASE64 encoding as the message digest. When validating, take the nonce part to calculate the MD5 value of the received message, calculate the corresponding BASE64 encoding, and compare with the received msg_signature to know if there is a message tampering.

Third-party platform access-open API

Onenet offers the following categories of open APIs

• Equipment
• Data flow
• Data points
• Trigger
• Two-tier system data
• Command
• MQTT related

A command is a mechanism by which the application sends command data to the Onenet device cloud, which is then forwarded by the Onenet device cloud to the terminal equipment, and the terminal unit receives the command to respond to the device cloud.

After the command is issued, the application can query the command status and extract the response data of the command through the API.

The following steps are performed for the command:

1, the application through the API to the device cloud Send command data;

2. The device cloud generates the UUID of the command as a unique identifier for the command and returns to the application while forwarding the command data to the terminal device;

3, the terminal Equipment received command data after the execution of command data, can generate a response, or can not respond;

4, the device Cloud Tracking Record command response, if the device has a response, the associated command UUID and response results;

5. The application extracts the command execution result from the API to the device cloud (the command UUID identifier is carried in the API request).

Platform Interface – Create product

Platform Interface – Create a device

Platform interface – Add Data flow

Platform interface – Adding triggers

Users can use the trigger to monitor the data flow, to achieve the specific conditions of the event alarm, the current trigger support by SMS, mail and user-provided URL address three ways to push event alarm information. User pre-set the data flow to be monitored, event trigger conditions, the acceptance of alarm information, once the monitored data flow data meet the set conditions, the trigger will be set to accept the way to send the alarm message

Platform Interface – Add Apps

Users can create relevant applications for the data flow under the device, publish a visual display page of user data, and currently provide applications such as graphs, histograms, dials, object positions, pictures, and switches in the Onenet application incubator, where users ' data is uploaded to the platform.

A probe into the domestic internet of Things Platform (eight): China Mobile IoT open platform Onenet