The internet of things (IoT) has several faces. Some have become familiar to almost all segments of society, like wearables, while others claim notoriety only in specific markets, such as industrial IoT systems. But there is more to the IoT than these two sectors. Another face that is gaining attention is the commercial IoT.
Although developers of this technology use design techniques, architectures and subsystems found in the consumer and industrial domains, the commercial IoT poses design challenges that differ significantly from its counterparts, placing unique demands on design teams. To ensure that their development projects succeed, engineers need to adapt to these differences.
What Is the Commercial IoT?
As the name implies, this IoT domain focuses on augmenting commerce, improving profits either by reducing operational costs or by adding new revenue streams. The technology is still in the early stages of its emergence, but developers have increasingly begun to see the commercial IoT take root in settings like office buildings, retail stores, hotels, healthcare facilities and entertainment venues.
In these environments, the technology has found traction in such applications as smart buildings, smart workplaces, connected lighting and HVAC (heating, ventilation and air conditioning) systems, asset tracking and location services.
Two trends are driving the rise of the commercial IoT. The first is rapid increase of short-range wireless devices, and the second is due to growing demands on edge computing to run local applications, collect data and perform command and control functions of devices within relatively short ranges.
What Makes Commercial IoT Different?
Though commercial IoT systems share common elements with their consumer and industrial counterparts, commercial use cases often require engineers to contend with a unique blend of design and business requirements.
For example, commercial projects must not only keep costs down—showing proven ROI, with a high internal rate of return—but they must also initially provide a complete solution.
“Most IoT applications are greenfield markets—meaning they target new use cases and immature markets that aren’t well understood,” says Mark Chung, CEO and co-founder of Verdigris Technologies. “When entering new markets, it’s insufficient to target just one part of the supply chain and optimize and turn it into a platform. More often, you need to ‘verticalize’ to provide a solution to the customer’s problem. Only once markets become mature can companies start to target and commoditize pieces of the product stack. Horizontal concepts—such as optimizing secure connections, offering better data fidelity or providing an easier operating system—can’t succeed until the market understands what IoT can do.”
Commercial IoT offerings must promise a longer operational life than consumer products. This business requirement translates into great pressure on development teams.
“One challenging design consideration for commercial IoT projects is lifespan,” says Ethan Pierce, senior solutions architect for Particle. “For consumer applications you might target a lifespan of 24 months. For commercial, this lifespan target is 3 to 5 or up to 10 years tops. As the engineer, you have to select technologies that align with the lifespan of your deployment. For example, with connectivity choices, where 2G networks are being shut down across the U.S., product creators have to make targeted decisions about the state of LTE and beyond.”
Along with the lifespan requirements, commercial system designs must provide for ongoing maintenance and upgrades. This, in turn, affects the scale of security incorporated in the product.
These broad issues are just the starting point for designers. As developers turn to the nuts-and-bolts issues, the design process gets even more complex.
Dealing with the Population Explosion
The greatest of these nuts-and-bolts challenges arises from the sheer number of sensors and devices that populate commercial IoT systems. The development team must define the business problem before deciding which sensors and devices the IoT application requires.
“This can be challenging because with new applications of IoT you might not know which data inputs you need at first—such as, you know your goal is to solve for preventative maintenance, but you’re not sure what data points reveal a failure before it happens,” says Pierce. “Often designers can fall into the trap of including more sensors than necessary, which provides excess data to manage and can drastically increase the cost of your solution. Select the sensors that help support your business case directly, and avoid those that might abstract the information away from what you already have.”
“Often designers can fall into the trap of including more sensors than necessary, which provides excess data to manage and can drastically increase the cost of your solution.”
Once the selection process is complete, the designer must provide management software that allows the user to easily manage all the devices in the system. “You want to offer observability into what version of software is deployed to devices, if they are online and what their operational status is,” says Justin Rigling, co-founder and CTO of Rigado.
After addressing these two issues, the engineer confronts a larger related issue: scalability.
The Importance of Scaling
Scalability has long been a challenge for designers, but the issue’s importance is more pronounced with the continuous growth of IoT systems that not only connect to other systems but also transfer and modify the data exchanged among associated systems. An effective approach to this challenge is to build maximum adaptability and flexibility into the design.
“Commercial IoT designs will have to efficiently adapt to changes in location, environment, equipment, range and bandwidth requirements while still meeting system performance expectations without the need to re-engineer the whole system,” says Laila Salman, lead technical services specialist for ANSYS.
The inclusion of flexibility should occur as early in the development process as possible, but don’t look for a one-size-fits-all solution. “When it comes to the variety of locations and environments, there isn’t a silver bullet framework,” Pierce says. “Many of these applications are doing something that’s literally never been done before—exciting though daunting. To deploy with success, every commercial IoT product should include a discovery process in development. Incorporate design of experiments early in your process to identify variables and constraints, and iterate accordingly.”
That said, trying to build universal functional hardware can be difficult and expensive. By overtaxing the design process with complexity and over-engineering to a 100% solution, designers risk missing a market window and business case. A way around this hurdle is to adopt a progressive approach. “One strategy to employ is the incremental approach,” says Chung. “First, design for the 90% use case, and prove the value of the design.”
Myriad Connectivity Challenges
In addition to scaling, commercial IoT development projects must contend with a number of connectivity challenges. These challenges often stem from features of the operating environment.
For example, in smart buildings, connected retail and smart warehouses, designers must deal with the presence of walls, floors, inventory and human occupants, which can degrade wireless signal propagation.
Other challenges arise as a result of harsh radio frequency (RF) environments in which the commercial IoT system must compete with extraneous RF signals and noise over a broad frequency range. This heightens the importance of RF coexistence.
Consideration of these connectivity challenges and many other issues should begin early in the development process, especially if the application involves hard-to-reach areas and large-scale implementations.
“You would approach this the same as I mentioned before, where a discovery process at the very beginning of the product development cycle is critical,” says Pierce. “Look specifically at antenna specs and radio spec frequencies versus bandwidth on range vs. performance. Look in-depth at the materials that devices are attached to, [and] transmitting through, and test extensively. Also explore retrofits if any prior design decisions are providing challenging results.”
Designers must also confirm that the components of the system operate as intended, evaluating system and device performance in its operational installed configuration.
“This is where engineers urgently need tools that will help them anticipate RF coexistence to model device performance in the presence of multiple sources of interference,” says Salman. “Designers should evaluate the performance of the devices and quantify what, if any, degradation will occur due to the RF environment.
Once engineers understand the operating environment, they can develop compensation methods. For example, should we increase the power levels? Should we use a beam-forming methodology? Or, should we use a mesh network for a more seamless experience?”
Designers will get the best results from the evaluation process if they do not focus on individual components and subsystems. Instead, development teams should concentrate on the system as a whole.
“With connectivity, designers should approach solving these challenges holistically and research what solutions are already available for the solution rather than specific elements of the solution,” Particle’s Pierce says. “For example, if you choose a connectivity technology for your edge device that ends up being restrictive, you then have to solve for that specific challenge before moving on to the next. This might be adding additional technologies that ultimately create a more costly gateway that is more challenging to scale.”
Wireless Technologies and Tools
Development teams must also follow commercial IT’s strict rules for adding new devices to networks. To this end, designs must support PoE (power over Ethernet), Wi-Fi and cellular gateways. Cellular connectivity has become increasingly important, with designers using it in new construction, where no internet protocol infrastructure exists. Development teams can also use cellular in locations where the IT department is applying requirements too strict to work with.
Low-power wireless also comes into play. Designers use Bluetooth to connect devices and systems to sensors and local controls. “In commercial, there are a lot of choices: Bluetooth, Thread, Zigbee, Z-Wave and more,” says Rigling. “This complicates the commercial space a bit because you need edge infrastructure that can connect to, and integrate with, multiple protocols. If not, you end up with overlapping infrastructures.”
The options, however, do not stop there. Requirements for dense sensor/device populations, internal and external environment support, and cost effectiveness make mesh network connections an increasingly popular choice. Mesh networking enables sensors and beacons to cover larger areas with fewer gateways because the end devices can network with each other to extend their range beyond standard gateway-to-end device connections.
Borrowing from Other IoT Domains
At some point, developers ask if they can borrow design ideas, development tools and business models from their IoT counterparts. The answer is yes—and no.
“Many lessons from consumer and industrial markets translate directly to commercial projects,” Verdigris Technologies’ Chung says. “It’s important, however, to keep in mind the key distinctions so that those ideas can be adapted.”
Remember the three domains of commercial, consumer and industrial IoT work with different advantages and disadvantages. For example, consumer market cost sensitivity translates directly to the commercial side; both markets require high ROI.
At the same time, consumer products enjoy volume and cost advantages that the commercial domain does not.
Industrial projects also have important similarities to commercial markets. For example, both require secure and reliable connectivity.
As for developer tools, commercial does require different tools and programs. “With commercial applications, devices will more likely need to managed at scale,” Pierce says. “Think thousands of tracked assets traveling across the country. It’s critical to have tools like over-the-air updates to get data to all devices instantaneously and fleet management tools for remote diagnostics.”
Finally, business models are tricky to directly copy. “With business models for commercial projects—and even commercial projects in a more industrial setting—you will have to start from scratch, based around your use case,” Pierce says. “How will you leverage your data? What’s the top recurring revenue generator?”
About the Author
Follow Robotics 24/7 on Linkedin
Article topics
Email Sign Up
Related Fleet Management News
