BY NICK DUTTON, VP Embedded,
and JULIE MULLINS, Director of Marketing
Zentri
www.zentri.com
It’s no longer a question of whether or not developers should build connected products, but how they will build connected products. Two critical elements of connected systems and products are device management and security. Both require careful consideration early in the design cycle for an effective design, all the way from development through manufacturing and product lifecycle management.
To get it right, designers and developers need to understand the underlying hardware as well as the operating system (OS), firmware, communications stacks, cloud services, application software, and security. Only then can they optimize for power, cost, connectivity, performance, and scalability.
The criticality of device management and security
The IoT journey involves four key, easily identifiable sections that include:
- The physical hardware, with its design incorporating plastics, electronics, and embedded firmware.
- The user experience with the mobile application.
- The cloud service allowing the company to manage the connected product post-deployment.
- The ability to connect to and change cloud vendors to make use of commercially available cloud services for storage, analytics, and so forth.
Most designers or developers have specialty skillsets within hardware selection, embedded development, or design but might not be intimately familiar with device management and security in each of the four key IoT sections. IoT developers must understand the full product lifecycle from hardware to RF to internet to cloud and all security in between. It’s hard for a developer to be an expert at all of these, though it’s important to understand their role, along with the role of relatively new concepts, such as device management.
Device management is a term that has risen to the fore with the IoT. A device management service provisions, authenticates, and authorizes each individual device such that there is now remote insight to a product’s status, location, firmware version, and more. This connection to the device is used for collecting and analyzing data, driving business logic rules, predicting and performing remote maintenance, enabling machine learning, and more.
The more comprehensive device management use cases enable the management of entire product fleets because of device management’s per-device granularity. Regardless of the number of products deployed, the firmware, features, and more can be adjusted based on user segments from business logic rules like opt-ins and usage statistics, location, product purchased, or nearly any other data point. For example, all weather monitors and drip systems in Europe can be updated to comply with the strict, European data governance laws versus those in the United States with the click of a button. If laws change, the firmware can be instantly updated to maintain compliancy. There is no need for multiple product SKUs (with different hardware) or strict, blanketed compliance software. The same is true for user opt-ins or social network-based upgrades that reward customers for partaking in a product community. The opportunities provided by this flexibility are limitless.
Today’s most successful IoT companies are those who have figured out device management, such as Apple and Tesla. In 2016, Tesla announced that their autonomous driving feature would be available as an over-the-air upgrade for $8,000. This is made possible by a device management service accessing each individual device to check software statuses, update firmware, and likely pair with a mobile app with a payment system.
Despite the seeming simplicity of device management, it’s much more than a fancy term for firmware updates. Beyond the operating system, it’s probably the most important piece in the connected product lifecycle.
Device management tracks and manages each particular device in the same way that a mobile device management (MDM) system knows your phone’s software version, ensures the correct apps are downloaded to the correct devices, and sends payments securely to the appropriate app store. Device management for IoT also enables the product manufacturer to, for example:
- Perform remote diagnostics
- Secure data
- Improve efficiencies
- Minimize costs
- Innovate
- Increase product agility
- Be closer to the customer (know which buttons are being used, communicate via an app, save favorites on the device, etc.)
- Get real-time analytic data on a product
- Obtain recurring revenue via updates and upgrades
- Transform a stagnant business model
When firmware is developed, the device management system can act as an internal, developer “app store” for features or applications to be viewed, stored, and shared to accelerate future product development. For example, with products that share mutual functionality, such as common temperature sensors, the majority of the code for a security camera with temperature sensors can be reused for a smoke detector with the same temperature sensors. This reduces the overall workload for new product development and can even be integrated with other systems such as workflow or project management platforms with the proper APIs.
Device management orchestrates cloud APIs where data is collected, parsed, dispersed, or shared for further benefits. This is the point when stored data can become actionable data to help dictate future business and development decisions. Because of device management’s importance and the amount of data it manages between the device, mobile app, and cloud services, it’s critical to have proper connected product security.
IoT is often touted for its benefits but known for its security breaches because of security cutbacks during product development. Once budgets or timelines are compromised, security tends to get lower priority.
Some don’t realize that they need security or are too anxious to launch their product. Some believe that the risk of a hack is more acceptable than implementing proper security or have fear that it will add extra, complex steps for the user experience. Others only think about securing the mobile device or cloud and forget about securing the device. But the product is only as secure as the weakest link, and reactively redesigning the product to patch security holes can be complex and costly. To avoid risk of massively tarnishing the brand, keep security a priority from start to finish and don’t forget to secure the device, such as with unique firmware. Sometimes developers need to take a strong position on this for the sake of their teams and the company.
To properly secure the product, include security during all three product phases: during production at the factory, in the product or cloud as the data is at rest, and while the data is in motion between the product, cloud, and mobile app (Fig. 1 ). Because it’s difficult to maintain security, look for an IoT platform that covers the entire product lifecycle as opposed to one aspect of the product.
Fig. 1: Securing an IoT product or system starts at the manufacturing plant and continues through the product’s life cycle, so designers need to build it in from the start and be able to support it long-term.
While the product is in the factory, a secure product is one that will secure your IP, encrypt firmware images, and securely inject product credentials and keys so the units ordered equal the units manufactured. Consider a scenario in which 20,000 units are manufactured despite only ordering 10,000. The additional 10,000 create a grey market using your stolen IP. This security is delivered by a secure operating system.
Once the product is generating data, its data must be secured at the storage site in the product and the cloud. To secure this at-rest data, the product needs encrypted product data, a per-product encrypted software binary, and secure device access to prevent hacks. A secure operating system and secure device management make this possible.
When the product or system is in use, it’s vital to secure the data in motion as it travels between device, cloud, and mobile app. All firmware updates should be encrypted and the product should enable secure data exchanges. Look for IoT platforms that include bank-level security with authentication and authorization from the data origination to where the data is being transferred. This security is driven by secure device management but must be coupled with a secure operating system.
Device management and security: make versus buy
There are three ways to approach connected product development:
- A native ground-up approach: build it all
- IoT platform using an agent: build the application on a platform supplied by a cloud vendor
- IoT platform with a full operating system: build the application on a platform built from the ground up
As expected, there are trade-offs associated with each (Fig. 2 ). Building an IoT product with nothing but low-level libraries and tools will take an average of two to four years to complete. Every piece of the stack — including connectivity, networking services, file systems, wireless services, RTOS, cloud services, cloud service connectors, security, and more — must be pieced together and then consistently updated throughout the product’s lifetime.
Fig. 2: Building an IoT product from scratch could take two to four years versus less than a year using currently available platforms, including a purpose-built OS.
IoT platforms already include this core foundation so that you can focus on your application and get to market in less than a year, on average. It doesn’t make sense to recreate an operating system simply to develop a word-processing application. Instead, the application should be developed on a complete OS that already includes the necessary framework, like Mac OSX. In the same way, it often doesn’t make sense to develop an IoT product without using the foundation of an IoT platform.
IoT platforms: agent versus OS-based
There are two types of IoT platforms to consider: one with an agent offered by a cloud vendor and one with its own operating system. The agent option is often selected when a company requires specific functionality that the agent’s cloud service offers, such as analytics. However, if you need an open platform with APIs that allow for easy extensibility and multiple cloud services, such as Amazon AWS for storage and IBM Watson for analysis, then the IoT platform with a built-in OS will be the most effective option because an agent typically locks you into its cloud service. The OS option is also more secure with security built into the OS to further secure the application. An agent can introduce a security hole at the junction where the agent begins. A breach below the agent could threaten the entire product.
Conclusion
Connected products are more involved and require new skillsets in the areas of device management and security to ensure a product’s success. While IoT features and functionalities can be added post-deployment, it’s important to build device management and security into the product from the start to avoid the complexity and cost of adding them in the future.
In the process of doing so, developers need to choose between building from scratch, using an agent, or opting for a full OS-based solution. The considerations when making the decision include time, resources, skillsets, cost, application functionality, the level of security required, and the team’s level of commitment to full product lifecycle management.
Advertisement
Learn more about Electronic Products Magazine
