IOT on GCP (Final)

With Cloud IoT, the cloud acts as the server. This means the network can by dynamically allocated to satisfy demand. You don’t own the hardware, which means you only pay for the resources you use. You don’t have to manage infrastructure, just your sensors and devices, and scaling.

Google Cloud IoT includes all the ML models and AI capacity available with Google Cloud ML Engine. Edge TPUs are designed to complement Google’s cloud TPU offering, so you can accelerate ML training in the cloud, then have lightning fast ML inference at the edge. This allows sensors to be more than data collectors — it allows them to make local, real time intelligent decisions.

Google IoT Core achieves root of trust in both hardware and software by using Microchip’s CrpytoAuthenication device. The authorization keys generated by the device are isolated from software and the board hardware.

After sensors are setup, we need to pick a communication protocol. Choices are HTTP or MQTT. Both are allowed by Google. Which is better for your situation?

Some devices cannot communicate to the cloud platform directly, such as over Bluetooth Low Energy (BLE).

When picking a sensor, the goal is typically to have a long life with little human interaction. They might be in a remote location, or embedded within a system. Durability must be considered. Accuracy, Versatility, Power Consumption, Special Environmental Considerations, Cost.

Devices communicate two types of data: telemetry and state. Devices transmit an ID, class or type, model, revision, data manufactured, and hardware serial number.

Metadata contains information about a device. That is what these things are called. Data collected by a device is called telemetry. This is the eyes and ears data that IoT devices provide to applications. Telemetry is read only data about the environment, usually collected through sensors. State information describes the current status of the device, not of the environment. This information can be read/write. It is updated, but usually not frequently.

Device commands might be valid for a limited period of time, so they should include a time to live (TTL) or other expiration value. Operational information is data that is most relevant to the operation of the device as opposed to the business application. This might include things such as CPU operating temperature and battery state. Short term value to maintain operating state.

Google has made starter kits to make connecting to the Google Cloud IoT platform easy for devs. Devs use kits to quickly create prototypes for projects. Kits may be selected for their device processor, sensors, expansion capabilities, etc.

When connecting to GCP, you will need to specify which communication protocol your devices will use. The choices are MQTT, HTTP or both.

MQTT is an industry standard IoT protocol (Message Queue Telemetry Transport. It is a publish subscribe messaging protocol. Clients publish to the MQTT broker, from which clients in subscribe mode receive data. The pub/sub model is event driven. Subscribers do not need to know the publisher, only the broker through an open TCP connection. If the connection is broken, the broker can hold messages for later transmission. The reslt is that MQTT is highly scalable architecture.

HTTP is a connectionless protocol. With the HTTP bridge, devices do not maintain a connection to the cloud. Instead, they send requests and receive responses. Client requests are sent without having to first check that the recipient is available. This means that devices have no way of knowing whether they are in a convo with the server or vice versa. This means some feature IoT core provides, like last heartbeat, will not be available on HTTP.

MQTT is considered to be data focused, while HTTP is document focused. MQTT uses lower bandwitdh, low latency high throughput, raw binary data, where HTTP is lightweight, firewall friendly, base64 encoded.

MQTT is better suited to the rigors of IoT. MQTT guarantees at least one attempt at delivery, that it will be delivered at least once, and that the message will be delivered only once. MQTT has last will and testament, meaning subscribers will be notified by the broker if the client is disconnected. Messages will also be retained, and subscribers will get an immediate status update.

Both bridges use public key (asymmetric) device authentication and JSOn Web Tokens (JWTs).