From the CTO’s desk, issue 1

Where we pop the hood on plgd to show how our IoT engine helps enterprises dodge the potholes along route Digital Transformation.

Where we pop the hood on plgd to show how our IoT engine helps enterprises dodge the potholes along route Digital Transformation.

Hey Jozef, what’s happening at the CTO’s desk?

Coffee. Plus, well this is the first edition, right? So I’ll rewind a bit: we’ve developed a device-to-device client application, device provisioning service to onboard devices without user involvement, we’re working on support for DTLS for device to cloud connectivity, and we’re solving some other problems for our customers. Should I talk about them?

I’m all ears.

Ok, cool. So our new d2d client application can run on multiple platforms, enabling our users to securely interact with devices on a local network. No internet connectivity, no cloud, just pure TCP/UDP between your device and your pc, mobile, or even a router. And our device provisioning service (DPS) – we also call it Call Home – enables devices to automatically connect to the hub without any user intervention. The DPS is automated and secure; it provisions, pre-configures, and connects thousands of devices to your desired plgd hub quicker than a cat. Literally, that’d be done in less time than your coffee machine takes to make a single shot.

Nice. So you mentioned security – what security provisions are there?

Well, the DPS verifies device authenticity – determining that devices are from the manufacturer they purport to be. The pre-registered Trusted Platform Module or trusted manufacturer certificate is key. Once a successful TLS handshake is established, the device will be provisioned with an identity certificate, pre-configured to the desired state, and onboarded to the customer’s plgd hub instance.

Ok, and then outside security – other differences plgd brings…?

A major difference we bring is that we enable customers to avoid vendor lock-in. You can deploy our service anywhere, for example to Azure or Amazon or Google Cloud, or in your internal data center.

Aha, and so how are you able to achieve no lock-in?

How we achieve no vendor lock-in is with the CoAP protocol, and Open Connectivity Foundation (OCF) specifications. And the plgd hub, device libraries, client libraries, and all the tools are free. They’re on GitHub, available under the Apache license. Our product is simpler than others, too; or, rather, going through product digitalization is much simpler with plgd.

How so?

Well, our product has a similar feature set to Microsoft’s product but the plgd service is compatible with the iotivity-lite library, which is an implementation of OCF standards. Without this, if a team wants the open standards of OCF, implementing it can be hard. So we make that simpler.

Sounds good, so what’s in the pipeline?

Ok, support for DTLS – Datagram Transport Layer Security – this is what we’re working on right now. We support it already for device to device communication, but we want to enable DTLS for communication to the cloud or the hub because currently the cloud service supports only TCP connections.

Oki doke – and what advantage does plgd bring here?

The advantage is in memory footprint. We’re talking about constrained devices here. Take the ESP32 with iotivity-lite library, provisioned with identity certificate, and securely (DTLS) connected to the hub: the secure device stack takes only 249KB of memory (RAM). That gives you plenty of RAM for your application logic. Your secure connectivity and API stack is good to go.

Alright, and I think you mentioned there’re one or two other problems you’re solving…?

Yep. So currently if a customer is using iotivity-lite, they need to solve the device firmware update on their own, which can be very time consuming. So we’re wiring the firmware update functionality directly into our stack, saving the customer that task – we like to give first-class service. With a standardized communication protocol (OCF) we’re able to support multiple over-the-air platforms, again keeping it no-vendor-lock-in. If the customer already has an OTA platform in place, or wants to switch, our part of the stack won’t get in the way. The API is standardized, and the OTA platform can be switched – that’s the power of our anti-corruption layer. On the first run in this development, customers will be able to use hawkBit, a widely used OTA platform. So these features are going to really simplify things again. We’re big into simplifying, as you can gather.

Simple is good. Anything else I’d find if I were rifling about on the CTO’s desk?

Well, one question we’re answering is, if a device is malfunctioning or the developer needs to investigate unexpected behavior, how do we simplify access? You can’t just shh the device. Well, you can, if you’re uninterested in security – with one username and password on all your devices…

So another feature we’re making for customers is log streaming. This enables customers to browse logs in the same way as they would in a microservices-based application. So this is about simplifying again – no need to dig about in the library – enabling the user to debug or find issues more easily.

Cool, quite a lot going on at the CTO’s desk, then. Thanks Jozef.