Assessing Hardware during IoT Application Development

When first beginning an IoT project, many enterprises pursue pilot studies to understand the feasibility and long-term scalability of their application design. An early and very important step in IoT application development is to align on hardware requirements for your project - and ensure that the capability to collect and ultimately send data to the cloud is feasible.

For the August edition of Losant Discussions, we are diving into hardware and the processes that our community of developers uses to establish requirements, assess, and select hardware components for their IoT applications.

This is an open conversation around hardware assessment, and we are most interested in our developer’s perspectives - What is challenging? What is essential?

The below prompts are to get you thinking about hardware and the issues you may or may not face in your day-to-day development work.

  • Knowing that its very use-case specific, when developing projects for your enterprise, what is commonly used at the prototype level for hardware?

  • How often as IoT developers can you influence this decision?

  • What hardware characteristics are essential to understand early on in enterprise pilot-scale development for your application? What key factors are missing from the below criteria:

    • Data acquisition and control
    • Data processing and storage
    • Connectivity
    • Power Management
    • Footprint / Size
  • How do you balance cost vs. functionality?

  • When you move on from pilot studies, how often are you reassessing your hardware needs?

  • When developing for a pilot scale, factors like flexibility, affordability, and modularity may have larger importance, than during production, when hardware needs to be reliable, manufacturable, and be easily integrated - how do you manage the transition at the hardware level?

  • Developer/maker boards (Raspberry Pi, Particle, Espressif, etc.) are commonly used for independent projects - How often are these same boards used at scale for production enterprise applications?

    • How do you choose between microcontrollers and single-board computers?
  • Are there use cases or applications you were unable to pursue due to lack of adequate hardware?

I’ll be here throughout the afternoon and beyond to moderate, assist and act as your connection to Losant experts - and I’ll be chiming in with my own perspective here and there.

See you in the chat below!
@Aidan_Zebertavage

@Aidan_Zebertavage, excellent point/discussion and, as promised, here are :red_circle:'s 2 :moneybag: cents as this particular subject is very close to our biz.

This is, ultimately, the same question(s) that everyone in the industry will have to answer since the devices, nodes, sensors, motes (however you want to describe them) are the very ‘things’ that make the Internet of Things. Having thousands or even hundreds of thousands of these now available, it is impossible and, quite frankly, unnecessary to go thru all of them in this discussion. However, we must try to ‘categorize’ them as efficient and narrow as possible to at least begin making some sense of the discussion at hand.

At least for us, these start at two main categories: 1) DIY’s, or do-it-yourself (as you mentioned : ‘Developer/Maker’ boards) and 2) Off the Shelf, or OTS already made/manufactured by somebody else for mass/commercial consumption. Why would you choose one over the other, again, is a plethora of different applications, opinions, needs, technologies, etc, and with both there are PROs and CONs, again, depending on all above. We at :red_circle:, taking into consideration we’re a bootstrapped, family-owned, small biz IoT provider where our main strength and focus has been connectivity, have opted for the OTS / Off the Shelf kind for our upcoming IoT packages’ solutions, and I’ll give a bit of as to why below to help in the discussion that impacts, not only OTS, but DIY as well; let’s start with the 2 main questions everyone should ask themselves 1st:

I. What is your intended ‘goal’ for your IoT device/solution/project? One would be unwise to assume that everyone involved in an IoT project even knows the ‘why’, and much less the ‘how’. And that’s ok; we’re all learning here, but at least you need to ask yourself this question first, as honestly and efficiently as possible - the success (or lack of) your project depends on this very question and corresponding answer. The folks at Beecham Research found interesting conclusions as part of their Why IoT Projects Fail survey : “…many IoT adopters [are] unclear what they want from IoT…” and, as a result, are “…wasting time, energy and resources on projects that will ultimately be unsuccessful”. We know this to be true. In an industrial project we participated in some years ago we asked the question: “Are you involved in IoT because you see the value or because of FOMO?”. We never got an answer. We’ve heard through these last 2-4 years how thousands of dollars were invested in a ‘software tool’ that couldn’t ‘connect’ well, or that ‘connectivity’ was never taken into consideration and only at the last minute a radio of technology ‘x’ was ‘dropped in’, or that the device needed to be ‘plugged in’ on an AC outlet and the project money was devoured by the UL certification alone - again, some things that look ‘trivial’ and were not taken into consideration since the beginning, now are all examples of failed projects that didn’t ask this first question and went ahead with just what they ‘knew’ (or thought they knew) about IoT. These are just some examples as well of why we decided to go OTS : knowing well in advanced our main goal was a commercial one geared towards solving specific, tangible and prioritized problems that we knew we didn’t had the resources and/or know-how to do it ourselves. Of course, our view is ‘biased’ based on our specific needs and applications, and also doesn’t mean that DIY isn’t the way to go for these or other situations, but I think you get the idea here. Which leads me to the second question…

II.Once you’ve asked yourself the question above, and have the answer and have gone DIY/OTS, do you know enough to ask the hard questions from a device standpoint? Ok, so you know what you want from an IoT device, you know how to solve it and what hardware to use. Whether DIY or OTS, and depending on application, now you need to ask yourself the next round of hard questions: is this IoT device/solution oriented towards the industry, or education, or science, household, or just a hobby? Once again, these 2nd round of questioning goes hand in hand with the 1st to determine what kind of device to pursue: DIY or OTS, and what to look for in each. For example, if its for educational purposes or as a hobby - or even commercial ones! - we know well the cost and awesome availability of DIY’s resources such as Arduinos, Raspberrys, etc have - not to mention the total control the developer have over these. But, again, if eventually the goal is to ‘sell’ these (or even if this wasn’t the intended purpose and then that changed!) then this is exactly the point where things can go on the unforeseen territory.

How will they connect, 1st, at a local level and then at scale, say at a WAN or even LPWAN or even national level? What technology(ies) to pursue in said connection based on that purpose? Do I need to follow guidelines, certifications, licensing for that? Do I go wired or wireless? Do i know enough one way or the other? Once again, having a clear vision and answering all these questions as quickly, ‘humble’ and efficient as possible will help you determine what kind of device to pursue, help to sought, and/or ‘adjust’ quickly as your project goes along.

Going back to our specific :red_circle: case, we knew we were not ready (yet) to go DIY, so we opted for OTS as mentioned already, and then we knew we wanted to go the LPWAN (low power wide area network) for our intended solutions based on specific long range requirements - meaning we went wireless, which is what we know best :wink: To that effect, these are some of the hard questions we ask from manufacturers and solution providers, again, as mere example of the topic at hand and not the end-all-be-all guideline (some of these apply to both, DIY and OTS!):

a. If the device is ‘plugged in’ to the wall, is it/does it need to be UL/CE listed, certified (of course, depending on country/jurisdiction)?
b. If wireless, and meant for commercial use, is it FCC (in the case of US) Part 15 certified? If DIY and for commercial applications, you NEED to make sure you understand this!
c. If technology ‘X’ for wireless communication is used, is it proprietary or open-sourced? Does it require licensing and/or royalties for its use: personal, educational or commercial?
d. Is the device/technology available/mfr through just one vendor or multiple?
e. Is there any kind of ‘Alliance’ or local/national/global standardization ‘entity’ (i.e. 3GPP, IEEE, LoRa Alliance, etc) that governs the device?
f. Whether wired or wireless, what type of information (payload) needs to be sent, what speed, bandwidth, latency requirements?
g. If battery operated, can I use typical easily available ones such as AAA, AA, CR or coin? How much will the battery last? Can I use more effective batteries such as Li or even rechargeable? How much will these cost over time?
h. If wireless, do I understand the limits and capabilities of my radio technology of choice? Does it fit the range I need to pursue? Is it, again, a proprietary radio technology offered by just one vendor or multiple or open-sourced? How does it handle the level of data and requirements from point f above? Can it be upgraded easily without ‘Rip-n-Replace’?
i. If wireless, do I know what kind of antenna is best, internal or external? How do I make sure these are of the correct band/kind? Do I know the most basic of antenna theory to make sure the device’s performance is not affected : i.e. frequency/band, VSWR, loss/gain, etc?
j. If wireless and OTS, do I get as much of these specs above mentioned from the mfr as possible (even DIY in some cases)? Are they going to support me well after the POS (Point of Sale)?
k. What precautions, guidelines and procedures you need in order to install these devices safely and legally, again, especially on the commercial side of things: indoor, outdoor specs needed (such as IPxy), cabling, grounding, etc (if wired, although even wireless hardware has wires!)?
l. Last, but not least, how secure IS my device? Does it come with embedded security of some kind or do I have to ‘add’ it? How far does the security go: between device and access point/gateway, or between device and network or all the way to the application (aka end-to-end encryption)? What kind, is it proprietary or the likes of AES, TLS, HTTPS, etc? Can you build security on top of it?

Again, these are just ‘some’ of the really hard questions one has to ask; I know is a LOT to digest but make no mistake about it: if you don’t pay attention to any/all of these - especially if in the business of scaling even at the educational or hobby level - you may very well end-up paying the same price as those mentioned before. Hope this adds a lot more ‘juice’ to the discussion and helps everyone achieve their particular IoT goals. :red_circle:

1 Like

@Jose_Cruz,

Wow! Reading your response has sparked some excellent discussions internally here at Losant on hardware assessment.

I had not even considered the long term implications of something that could be perceived as relatively simple as, “does my hardware need to be plugged in?” - It’s clear that red wireless takes a very methodical and holistic approach to hardware assessments to ensure that you are considering not only all of your options but also how they ultimately impact the purpose of your IoT application - those ripple effects may seem small at first, but over the course of development you may find that they turn into a tidal wave of problems if you don’t ask the hard questions up-front!

I took a stab at distilling down some of your key points and criteria:

  1. Before diving into hardware choices and assessments, having a full understanding of the intent of your IoT solution and what you expect to gain from it will help guide some of your hardware and architecture decisions.

  2. Overall Device Type - DIYs vs OTS - Does the hardware support your needs for your IoT solution? Do you know enough about your devices to be truly critical in your assessments?

  3. Criteria to Consider (not exhaustive):

  • Power Source
  • Certification Requirements (Wired vs. Wireless, Domestic vs. International Certification Standards)
  • Ease of Use (Proprietary or open-sourced communication, licensing, royalties, intended use)
  • Global Standards (how widely supported is a particular communication protocol or hardware type)
  • Ease of Sourcing (manufacturability, supply chain)
  • Data Type (Speed, Bandwith, Latency)
  • Transmission Range
  • Support
  • Security
  • Many others, specific to use case, industry, geography.

I’m interested in hearing more about your development goals, especially as you mentioned that you are not yet ready to take on DIY hardware - and how your process may change should red decide to head down that path.

Thanks!
@Aidan_Zebertavage

1 Like

@Aidan_Zebertavage, excellent synopsis!!! Right smack at the :heart: of the matter at hand! Well done!

We take pride in our approach, although the ‘road less traveled by most’; and it hasn’t necessarily all been ‘by design’, some we’ve been left without any other choice (following experience and forced by the hands of circumstances alike) to :mantelpiece_clock:take our time’ before we go into full commercial production mode. And yet, in the case of software, we did in fact took the semi-DIY/hybrid path (aka Losant :wink: ) in contrast to our hardware non-DIY/OTS path, again due to experience and circumstances. And correctly assumed: we’re not saying we won’t ‘ever’ go DIY; just not for the moment - as they say, learn to :baby: ‘crawl’ before you can learn to :walking_woman: ‘walk’…

Stay tuned, we keep discovering and learning as we go along and, as good friends, users/developers and humble partners of Losant, we’ll be happy to share for the benefit of all of us here in the community! :red_circle:

A great topic! I’ll put some responses to your prompts below. We are an engineering/product development firm that creates products with/for our clients, everything from a sippy cup to large industrial machines. Considering IoT is part of almost every product plan. We also do projects where we are “retrofitting” existing products/machines with IoT hardware. So far, all of our projects have been with cellular modem HW, particularly Particle. Our first project began 3 years ago and now has 600 machines connecting to the cloud (units on 6 contintents!). Hopefully, soon, we will be embarking on a project using Wi-Fi.

  • Knowing that its very use-case specific, when developing projects for your enterprise, what is commonly used at the prototype level for hardware? Like I mentioned, so far we have used Particle HW. We use the development kit boards for the concept/pilot and then switch to their industrial versions, which are placed on (soldered or plugged into depending on model) our custom designed PCB. The Particle modules have their own micro and firmware. In some cases, there will be other boards we design to operate the machine/product in question that will have another micro selected by us or the client on which we will develop our own firmware to operate actuators, control sensors, manage power/batteries, etc.

  • How often as IoT developers can you influence this decision? So far, we always influence or help make the decision. Most of our clients are not familiar with the myriad of options available in this space. We, too, often find ourselves bewildered with the options/choices. We design the IoT hardware to be modular so that there is some element of “future-proofing” as well as the ability to swap out technologies if needed (like switching to Wi-Fi from cellular).

  • What hardware characteristics are essential to understand early on in enterprise pilot-scale development for your application? What key factors are missing from the below criteria: COST

    • Data acquisition and control
    • Data processing and storage
    • Connectivity
    • Power Management
    • Footprint / Size
  • How do you balance cost vs. functionality? I added “cost” in the previous prompt. This is a topic on its own. The IIoT space is relatively new and complete ROI examples can be hard to find. I just helped a client put together an ROI model for their execs and it was quite a daunting task. In sticking with the topic of HW, there is still SW/cloud cost bundled in. Particle’s business model is not so much built around selling you hardware, but around the cloud service fees for the fleet management capabilities and tied in data plans for the cellular option. These additional costs can be significant, but still need to be examined in the light of build vs. buy. The “Big 3” (Amazon, Google, Microsoft) all offer seemingly cheaper device/fleet management capabilities, but with many caveats I don’t have time to get into.

  • When you move on from pilot studies, how often are you reassessing your hardware needs? So far, all of our projects have stuck with the same HW platform. What is continually being reaasessed by our clients is the whole cellular vs. Wi-Fi decision. We advise that it is relatively straightforward to accomidate both with a modular design, but so far we have no takers.

  • When developing for a pilot scale, factors like flexibility, affordability, and modularity may have larger importance, than during production, when hardware needs to be reliable, manufacturable, and be easily integrated - how do you manage the transition at the hardware level? Our experience has been limited to Particle. They provide HW for both pilot and production scale, so the transition has been straightforward. We do have concerns with their ability to produce HW at scale as many of their industrial modules have been sold out for long periods of time. Perhaps the post-Covid world will see an improvement to this.

  • Developer/maker boards (Raspberry Pi, Particle, Espressif, etc.) are commonly used for independent projects - How often are these same boards used at scale for production enterprise applications? I have answered for Particle. The Pi is interesting, too. There is a company called CaptiveAire that sells a product called CASLink. You can download manual from their Web site and see that they are using the RP compute module at the core of their design. I have played around with some RP’s loaded with the Losant Edge Agent and managing them with the Balena.io cloud and it looks very, very interesting as the basis for an IoT architecture.

    • How do you choose between microcontrollers and single-board computers? Primarily cost and control. My team here at ITE design from the “bare metal” level, which is usually the lowest cost approach for client products/machines in production quantities. Though, we developed an industrial grade product with a SBC loaded with Linux several years ago that is still in production.
  • Are there use cases or applications you were unable to pursue due to lack of adequate hardware? Not really. There are a bewildering amount of options out there and many ways to design an IoT architecture. Our goal, through experience gained over time, is to help our clients to navigate the choices and provide a successful IoT solution.

Anyways, hopefully I have provided some insight. The IoT space is a facinating and ever-changing world that we are just in the very beginning of. Onward to the singularity!

2 Likes

@David_MacKenzie,

Excellent perspective - Understanding the cost implications of hardware selection is certainly something that needs to be considered early, and re-evaluated often, especially as applications begin to scale. This factor absolutely needs to be included in any assessment.

You are absolutely correct that because our industry is relatively new and just now beginning to see wider scale adoption, we will hopefully be able to leverage more complete ROI studies here in the future to be able to justify initial costs and development time - and frankly, the more adoption we see across industries will likely lead to further development of customized hardware to support those uses cases.

I am curious to learn more about how Particle may handle increased volumes for manufacturing at scale.

Really appreciate your input, thanks David!

Thanks,
@Aidan_Zebertavage

1 Like

@David_MacKenzie, great info! I’m curious to understand a bit better why clients are continually ‘re-assessing’ the connectivity part (of course, as long as you can share without going into confidential info conflict! :smiley: ) . Also, at this point, you haven’t needed/contemplated other connectivity solutions other than cellular and/or WiFi? Cheers! :red_circle:

1 Like