Get started Bring yourself up to speed with our introductory content.

The IoT journey for manufacturers: Concept, production and beyond

Many articles written about the internet of things focus on collecting data insights, yet few explain the IoT journey itself. Navigating the path to connect appliances and start generating data is easier if companies understand best practices, as well as how to recognize potential obstacles.

This article provides guidance to appliance manufacturers and OEMs (for example, home appliance OEMs) through key phases on their journey to embed connectivity and enable IoT features for their appliance — from initial concept, prototyping, production to post-production. Keep in mind that these phases can occur in parallel or their order changed.

Specification phase

Assign two key roles
The first step is to fill two key roles: product manager and program manager.

An experienced product manager should be given authority and responsibility to manage the entire development process, from initial concepts, specifications and development to mass production and interfacing with vendors and internal teams. The product manager should have experience and knowledge across wide domains, including electronics hardware, industrial design, embedded software/firmware, UX, cloud/IoT platforms, mobile apps, component vendors and contract manufacturer negotiations, and understand certification processes and challenges.

A program manager oversees schedules and dependencies across various teams and vendors.

Identify must-have features
Instead of incorporating elaborate experiences for end users, it’s better to first enable basic IoT features and keep the system remotely upgradable for future enhancements. Some recommended features include:

  • Remote maintenance, support and remote upgrades for appliance connectivity module, cloud, mobile apps
  • Remote monitoring and remote device management
  • Role-based access control and dashboard for administrators, dealers, support, retail and other users
  • Ability to collect usage data from appliances (only with user permission) to provide insight for future product features
  • Maintain end-to-end security and compliance for regional privacy

Set up versioning control system
Install a proper repository and version control system for documents such as specifications, software, design, source code, test assets, RFQs, vendors, IoT platform literature, industrial design assets and more to ensure traceability and interlinking and enforce it across all teams.

Generate clear specifications
From the marketing requirements document, the product manager must generate clear, quantifiable and measurable specifications and document them in a product requirements document covering various components, such as electrical, electronics, firmware, software, regulatory, commercial, packaging, environmental, repair and serviceability, durability, expected volume, COGS, BOM, industrial and more. Features should be prioritized, leading to a minimum viable product definition and subsequent phase requirements.

For software, translate high-level marketing requirements into user stories. Convert these into a requirements document covering embedded firmware and software, IoT platforms, cloud, mobile, security, authentication and privacy. Don’t overlook tolerances on electronics, region-wise certification, software security, environmental and packaging.

Typically, some specifications get updated after the prototyping phase, after components get finalized before manufacturing.

Platform, cloud and key component selection phase

Select an appropriate IoT platform
With many IoT platforms on the market, making the right choice can be confusing. Since a typical appliance has a lifespan of five years or more, keep in mind long-term implications such as extended support.

Here are some questions to ask and things to consider when evaluating an IoT platform:

  • Is it recognized by OEM/appliance manufacturers?
  • Has it been field tested in full production in multiple regions?
  • If the platform vendor is a startup, what are its industry credentials? Types of customers and funding are critical considerations. If the vendor is acquired, is support during the transition period specified in legal documents?
  • Compare features such as provisioning, onboarding, remote device and connectivity module management, including OTA upgrade for each; remote diagnostics and logging; authentication/identity management; role-based access control, configurations and dashboards; security, privacy (for example, personally identifiable information), multiregion support; decommissioning; edge and cloud basic analytics; data aggregation/storage; rule and event management; API and API management integration into business apps; and partner management.
  • Factor in commercial development costs, production licenses, per unit licenses, post production maintenance and support.

Select connectivity module and management
Many appliance manufacturers lack the expertise to build their own connectivity modules and obtain the necessary certifications in their target markets. Although more expensive, the final product certification complexity is reduced significantly by choosing modules pre-certified for Wi-Fi/BLE, 3G/GSM and other standards. Most popular modules with larger market share are safer choices in terms of interop, support and certification.

It’s also a good idea to employ RF consultants during this phase and during hardware design and printed circuit board assembly (PCBA).

Module device management, provisioning, commissioning, deployment and decommissioning are other important considerations. IoT platforms offering integrated device management for the device software/firmware and the connectivity module firmware have clear advantages. Connectivity management becomes an important factor if a cellular connectivity module is selected.

Similarly, other component choices must be made for various electronic parts meeting the specifications.

Select application cloud
Popular public clouds, some offering their own IoT platforms, make integration into an application cloud fairly easy. However, when data is transferred from the IoT platform to the application cloud, privacy and crossing regional boundaries are important considerations that must be factored in.

User experience and industrial design phase

Select an integrated approach to user experience and industrial design
A connected appliance user experience simultaneously touches both the virtual world (mobile app, cloud) and the physical world (physical buttons on the device or a touchscreen display). Device controls and states that experience unreliable connectivity and latency present a complex design challenge. An integrated high-quality user experience with simplicity of use needs multiple iterations, including friendly customer or employee feedback.

Industrial and software UX teams must work closely to deliver the right design experience from the integrated system and the individual screens and controls. The connected appliance packaging should also be designed well in advance.

Proof of concept to aid user experience
To understand the user experience, iterative and rapid proof of concepts (POCs) are important, although mocked up actions, controls, and simulations can be used. The POC aids the design phase, as well as the prototyping phase. The POCs can be carried out via off-the-shelf hardware kits.

Software systems architecture
A software system architecture needs to be developed for the software on the appliance, IoT platform, application cloud, mobile, user management and overall integrated system.

The architecture should address security, safety, privacy, failover recovery, remote diagnostics/logging, provisioning, upgrades, revocation, decommissioning, role-based access, authentication/identity management and more.

Security, privacy and safety are especially critical since the liability implications of a hacked appliance causing damage to the user, along with harming the company’s reputation, can be enormous. European privacy laws and standards will take effect next year, and there will be severe penalties for companies not meeting them.

An abstraction layer for the IoT platform for interfaces and touchpoints must be created that can smooth a migration to another IoT platform if it becomes necessary in the future.

Here are some of the key components of system architecture that must be supported by the IoT platform and their impact on the overall system architecture:

  • Role-based access control for cloud, devices and dashboards. Different users require different permissions, with proper authentication. Similarly, various configuration dashboards and status display dashboards must be supported.
  • Security and privacy. A ground-up approach, with the ability to handle failures, attacks, recovery, revocation, upgrades, and privacy law compliance, including PII/ European GDPR, must be considered. When using a public key infrastructure (PKI), the ability to revoke and restore devices, re-key, and recovery after an attack is critical. Secure booting, key storage, and secure APIs are other considerations.
  • Includes first-time boot up, followed by setting up credentials on the appliance (for example, a Wi-Fi appliance booting up as an access point), device claiming by the user/unclaiming, and registration/deregistration on the cloud with claimed user.
  • Remote appliance/device and module management, diagnostics and logging.
  • Software/firmware upgrades and recovery through campaigns/schedules across regions, appliances, cloud and mobile apps. Upgrade features need to be for both appliance and connectivity modules.
  • Embedded device security. Secure boot up, firmware upgrades, key provisioning and storage at manufacturing, and overall key management during the product lifecycle are needed.
  • LAN connectivity. When a mobile and an appliance are on the same LAN, the mobile can directly interact with the appliance, instead of via the cloud, reducing latency and costs. The IoT platform should support dynamic switching between the LAN and cloud.

Planning phase

Create a test and validation plan
A detailed test plan covering functions, performance, stability, validation, certification and user testing is needed, with each test producing a quantifiable and measurable result.

Since parts of testing should be automated, a test automation team is also needed. Some tests may require dedicated hardware, with hardware design teams assigned. The test setup and plan must be conveyed to the contract manufacturer for factory testing well ahead of time.

Project execution plan
Assemble a detailed project plan involving all teams (UX, ID, software, hardware), vendors (components, software), contract manufacturers, consultants and test teams, along with corresponding tasks and milestones

Prototyping phase

Build looks-like/works-like prototypes
Designers should build looks-like (ID, color, material) and works-like (mechanical, PCB, connectivity) prototypes as close to the product requirement document’s specifications as possible, using off-the-shelf kits. A works-like prototype must meet specifications, component selections, PCB, mechanics, feel and assembly, starting with breadboards and progressing to functional PCBs. Component selection can be lengthy, and PCBs should undergo several cycles before production. Multiple works-like/looks-like prototypes are typical. Final component selection typically happens at the end of this phase.

Development phase

Software development
Embedded software/firmware on the appliance, cloud configuration and application software, configuration and integration with the chosen IoT platform, mobile apps, DevOps + CI/CD and more are required. While each software development phase can be kept agile, dependencies on the hardware phases dictate that the overall development is in a waterfall model. Software development will progress through different phases on various hardware prototypes. Developing a software system with hardware functionality simulated is also recommended.

Develop PCBA, board support package and low-level firmware
Design final form factor printed circuit board assembly, and develop final (board support package) and low-level firmware. RF consultants with expertise in laying out antennas and general EMI/EMC are important. Power considerations are also critical.

Systems integration phase

Develop engineering prototype
Once iterative prototyping on looks-like/works-like is completed, the looks-like/works-like system must be integrated into one unit, with final PCBA, form factor and mechanical parts, through an iterative DFM/DFA process for high volume production. Engineering prototype is a key milestone.

We recommend pre-compliance EMI/EMC testing on the engineering prototype, as well as testing power consumption and thermal.

Final device firmware, embedded software, Wi-Fi module connectivity and management, IoT platform configuration and status updates, mobile apps and the rest of the cloud system must be integrated and tested for functionality and robustness on the engineering prototype.

Testing phase

Test each phase through mass production
We recommended carrying out minimum relevant tests at every phase and detailed tests at all levels at the engineering prototype phase.

Detailed testing on the engineering prototype is expected to cover: functional and systems testing (manual and automated), performance, stability, ICT tests on PCBA, production line validation, security and privacy tests/audits, limits and user-centric tests. Design validation tests focus on environmental, reliability, cosmetic and validation with production-build environments.

Regulatory testing includes certification/compliances (UL, CE, FCC and so on) and safety. Regional compliances may require testing in specific regions. Cellular connectivity may require operator-specific tests. It’s important to measure production yield/scrap and run QA/QC tests on production units such as black-box testing.

Before final deployment, beta field trials with friendly customers are critical and can last many months, with continuous improvements and tweaks.

During mass production, continuous monitoring of scrap quantity and yield on operation parameters helps minimize errors.

Support and upgrade phase

Support, managed services and upgrades post-production
Prior to deployment, establish 24/7 cloud/appliance/app health monitoring, issue response and ticketing systems, as well as 24/7 L1 support. Field issues are difficult to debug and it’s critical to have remote debug/logging to trace issues. During this period, software/firmware upgrades for issue resolutions, and also later on feature enhancements, will continue. Both hotfixes and periodic upgrade schedules must be managed across regions through OTA appliance makers that have large maintenance/support period cycles, typically from five to 10 years or more.


An early technology innovator named Benjamin Franklin supposedly once said, “If you fail to plan, you are planning to fail.” This is timely advice when it comes to successfully delivering IoT products to market. I sincerely hope that the above roadmap I’ve shared will provide you with a smoother journey as you develop and roll out your IoT appliance.

All IoT Agenda network contributors are responsible for the content and accuracy of their posts. Opinions are of the writers and do not necessarily convey the thoughts of IoT Agenda.

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

How are you reacting to the ongoing Cisco reorganization?
If the comments from its employees are correct (inefficient organization), then its reorg should be welcomed news.
Wow this is pretty amazing, considering how Cisco has been the head of the networking pack for a while.
Nepotism is a weakness that kills companies and countries, I won't be paying for the salaries of VP's that are staying because they are someone's budy.
As a stockholder and fan of the earlier company this has been par for the course. Transition Project! It doesn't take rocket science to know a consulting firm will tell a company to cut heads because then they can show an immediate impact to the bottom line (this is always the recommendation). Getting rid of intellectual capital creates a death spiral and sends the wrong message to all stakeholders. It is all about innovation and acquisition for what can't be made in-house. Contrary to an earlier post, Cisco has not been the leader for a while now. All one has to do is check the trend of the stock.
Cisco is stuck in mentality of a decade ago. The look like RIM but with more cash to burn through!
No surprises here
Is Cisco's Set-top box and VoIP business rocking?
Eliminating the bottom 5 percent has been standard annual performance management at Cisco, GE, and plenty of other companies for years. Nothing new there
Cisco has out priced themselves forcing existing customers to look elseware. The "layoff" provides even more reasons.
Sales rep said one thing. Tech support keeps changing. Customers start feeling like something is going on. Upper management never tells the truth on whats going bad. Until it starts effecting their wallets.
Cisco hasn't innovated for the past decade. They are in trouble. I am not buying any gear from them in the next few year.
Cisco is in a death spiral where they decide to cut the "bottom 5 %", which is really a way to cut whomever they want to. They do ratings and rankings of all employees, and then they are told to weight the layoff numbers as per individual executives, who decide where they want the emphasis to be in their own personal span of control. This is where there is no integrity to the layoffs. If a VP in one area decides in favor of one area of focus, say sales and engineering, then the other cross-functions, regardless of skills, expertise, or need, are cut to make up for it. Thus there is really no way to guage the low 5%. It is really a crapshoot. Old folks, chronism, whims, VP buddy system, mecurial VP decisions, and so forth, rule the layoffs at Cisco. They continue to carve away the best in favor of the young and inexperience who make the has been older male executives feel like they are going to get their youth fix from these decisions.
The Cisco partnership with EMC/VMware isn't looking to good right now.

Faked evaluations and rolling "limited restructuring" are opportunistically being used to consolidate control in the business units increasing nepotism. This is the time that old scores are being settled. Family, tribal members, and friends are being rewarded with promotions and bonuses at the expense of the less connected who are responsible for the real achievement.

This is the final nail in the coffin of Cisco's old merit based culture. Cisco has now fully replaced a meritocracy with a kleptocracy imported from the third world. Long term there is no way Cisco can sustain itself as a company with this culture.
Every Company Needs to reinvent itself if it wants to survive the timeline. The change must be handled carefully.
Cisco layoffs means "Cisco is going down" and all customers with it . Be carefull!
Cisco was a good company once. It's now completely corrupted and if you're in management and want to do the right thing, you have to leave and go do it somewhere else--they don't need your kind anymore.
All this is bullshit.
Training for CCNA
Reorganization is the right approach to modernize new technology