What do you need for an IoT Solution? Part two

  • IoT Software

Like any piece of complex hardware, IoT devices need an operating system in order to be useful. But because IoT devices tend to be small and resource-constrained, operating systems will vary in functionality, memory footprint, and feature set. Devices also need to be programmed–given the instructions they need to do the tasks that engineers need them to do. There are many vendors developing operating systems and programming tools and the choice you make for any given solution will be the product of several factors including:

– Availability of the software you need
– Compatibility of the software with the devices you’ve chosen
– Compatibility with other software/cloud systems in your solution

Of course, your solution may involve devices with a variety of operating systems and development environments. But the more you add to your solution, the more complex development and maintenance becomes so it pays to be mindful of the software choices you make and the implications of each one during the architectural phase of the project.

What Programming Languages should I chose?
When it comes to programming devices, the operating system running on the device may determine what languages can be used to program it. Many modern hardware devices can support multiple languages and board engineers may develop specific flavors of hardware to support various languages. Microsoft’s IoT core, for example, supports most languages that Windows develop in general supports including C#, C++, and JavaScript. Ubuntu Core, on the other hand, supports Python, Ruby, and Node.js.

This makes choosing a programming platform complex and attempting to even outline the matrix of options here would not present an adequate picture. Instead, we can suggest how to approach the decision-making process when it comes to a programming platform. These suggestions build upon the strategies we’ve been seeing throughout this posts, so some items will be familiar and other items will be new.

Determine what data you want to collect.
Your IoT architecture generally will begin by figuring out what problems you’re solving and this, most times, will be characterized in terms of the data you want to collect. This relates to programming languages because the data you want to collect will impact the devices you choose and the programming language(s) you choose will have to work with the device infrastructure you deploy.

Think about your broader software environment.
When you think about what software platform you want to use, it can be helpful to think about the development environment across your business group or enterprise. By using a language that already is deployed in other areas of your business can make tasks like resource balancing, code sharing, source control, hiring, and similar factors more efficient.

Choose a device or devices platform.
Once you’ve figured out what data you want to collect and have thought about your larger ecosystem, you’ll be better informed when it comes to choosing a device platform. As I said before, you may need more than one device platform so choosing platforms that are the most compatible with items above will give you a more efficient overall environment in which to develop your solution.

What about the cloud?
It may go without saying I’ll say it: an essential component of the software platform when making a platform decision is the cloud services you’ll use to support your software and hardware. I think it’s important to call out here as an essential aspect of the decision-making process.

What do you need for an IoT Solution?

In this series of blogposts, I want to talk about what we need to think about when to set up an IoT Solution before I explain how to do it.

I have split this into 3 blogposts.

This is only parts of what you must think about but can give you insights of how to think.
I will talk about:
– IoT Hardware (This one)
– IoT Software (Part two)
– Cloud Service Components (Part three)

Let´s talk about IoT Hardware

When thinking about building an IoT solution, perhaps the first area of consideration is what hardware you will need. This partly is driven by the fact that data is the main driver behind implementing many IoT solutions so figuring out what data you want to collect and how you want to collect it has a primary place in your architecture.

The hardware implemented in an IoT solution often includes a network infrastructure that is used to connect devices. Still, some devices could be stand-alone. How would this work? A sensor, for example, could collect temperature data or collect data about how a bridge is being stressed but not deliver those data immediately to a network database. A technician could come by on a regular schedule, collect the data from the device using an internet-connected tool which then delivers the data to the database.

IP-enabled Devices

An IP-enabled device is, simply, a device that can establish a connection to a network (for many IoT devices, this means the internet) and have a unique identity on that network. “IP” stands for “Internet Protocol and defines the way messages are delivered over a network. A message in networking terms is just a packet of information and single packet could deliver part of a text message or a video file. Most data that is transferred over the internet uses this communication protocol.

In terms of IoT, an IP-enabled device is one that can connect directly to a network like the internet and transmit or receive data. Examples we commonly think of are the home automation devices like doorbells and thermostats that use an internet connection to communicate with a central server. But industrial-grade IoT devices can be IP-enabled as well. IP-enabled devices require special hardware to enable this functionality.

Non-IP Enabled Devices

As mentioned above, it’s not necessary for a device to be IP-enabled to be a part of an IoT solution. Some devices don’t use IP to connect to other parts of an IoT solution but can use other protocols. These devices don’t connect to the internet per se, but their messages are routed to the internet via other hardware like a field gateway.

Devices can use industry-specific protocols (such as CoAP5, OPC), and short-range communication technologies (such as Bluetooth, ZigBee) to connect to other hardware. For example, when setting up an internet connected lock, you may need first to connect the lock to your phone using Bluetooth to set up a relationship with a cloud service. While this is a temporary situation, you can imagine a scenario where the device can only connect to a local device using Bluetooth and the secondary device brokers all the communication with the cloud service.

Sensors

We can break this category into two subcategories: sensors and smart sensors. We can define a sensor, then, as a device that collects a specific type of data about the physical environment. As IoT as a technology grows, the list of available sensors most likely will grow with it. There also are communities that will help you build your own sensors if the one you need doesn’t exist.

A smart sensor is a device that takes input from the physical environment and uses built-in compute resources to perform predefined functions upon detection of specific input and then process data before passing it on. That is, the device itself processes the data to some degree before sending it to the next node in the IoT architecture. Sensors of both types can be embedded on other devices which manages communication with a network or stand alone and handle all the necessary functions needed to collect and communicate data. Sensors that can collect data on a wide variety of things actively are being developed.

Examples:
– Temperature
– Humidity
– Pressure

D365 Field Service together with MS HoloLens creates a unique experience for your field technicians!

Here you have the modern way to make more use of time and money more effectively in your field service organization

Via video call hand-held video through MS HoloLens, the technicians can collaborate with a remote computer or mobile expert and troubleshoot live issues.

Modernize field service

Give the on-site technicians the opportunity to share what they see with remote experts, handsfree with Remote Assist on MS HoloLens. With modern tools like video call through mixed reality, comments and file sharing, technicians and
remote experts can solve problems in their context. The remote expert can show where the problem is, how to replace a piece and guide the technician throughout the process. It saves both time and money.

Solve the problems in a few minutes, not days

When the world is moving fast, and production is overloaded, it’s important to solve complex problems faster and fix the error at first time. With MS HoloLens, the technician does not try to explain how things look over the phone, try to explain how it works, and avoid misunderstandings, making sure you get a
safer service technician who knows that he’s just a touch of a button for help.
Customers get more satisfied because they can get their wrong remedied much faster as the technician will not have to go back to the service center to solve more difficult issues.

This saves you time, reduces travel costs and gains more efficiency.
If you then integrate it with your other processes and systems, you will receive full support for your service organization.

Could it be better?