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.

Summary

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.

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

-ADS BY GOOGLE

SearchCIO

SearchSecurity

SearchNetworking

SearchDataCenter

SearchDataManagement

Close