Commercialization Series - Blog 1: Manufacturing & Deployment
by Mike Aanenson, on December 22, 2021
In our last post, we kicked off our “Preparing to Commercialize a Connected Solution” blog series and outlined the topics you can expect to learn more about in the coming weeks. As a reminder, the goal of this series is to help organizations understand the key considerations that need to be made in order to successfully transition from a proof-of-concept phase to full commercial deployment of a connected solution.
For blog one, we’ll discuss manufacturing and deployment. During a proof-of-concept phase, you’ve likely only manufactured and/or deployed a small number of devices. As you look to scale up, you may be leveraging an existing new product introduction (NPI) process that ensures you check all the important boxes along the way. Work with the accounting team to develop budgets and pricing? Check. Work with the sales team to provide training and sales tools? Check. Work with the marketing team to prepare promotional content and campaigns? Check.
While your existing NPI process is a great place to start, it’s important to remember that bringing a connected solution to market at scale will require new “checkboxes” that you’ve likely not experienced before, especially for new tasks needed during the manufacturing process to ensure your devices are fully programed, tested, and ready to be sent to customers. In this post, we’ll provide high-level questions you’ll need to consider as you look to establish manufacturing processes around provisioning, user setup, and device firmware on a large scale for your connected solution.
Provisioning a device is the process of authorizing it to connect to your cloud-based solution and access/modify data and resources there. This can be compared to the process associated with purchasing a new cell phone. When you open the box and turn the phone on, you generally have to call your phone service provider and complete a few steps to prepare the phone to work with your service provider’s network.
How devices will be provisioned must be taken into account during the manufacturing process and is an important security step to ensure only approved devices can interact with your cloud-based solution. Exosite’s ExoSense® asset condition monitoring application provides several options for this process (see more in-depth technical info on our documentation site), but there are several details to consider as you prepare.
Question 1: What type of authentication will you use?
When it comes to authentication—how your devices will prove to the Exosite platform during the provisioning process that they were indeed made by you and purchased from you—there are a variety of options to choose from. Which option you select depends heavily on the device you are using, what the device’s firmware is capable of, the level of security that is necessary based on your application, and the sensitivity of your data (for a more in-depth discussion on security, see our white paper).
As seen in the image below, the ExoSense application supports a variety of authentication types.
Recommended Authentication Methods
The following two authentication approaches for devices are highly recommended based on their ability to provide a higher level of security. With these approaches, no secret information is transmitted in order to authenticate requests—instead, the private key can be stored on a hardware security chip that makes it difficult to obtain.
- Transport layer security (TLS) client certificate authentication. If possible, Exosite recommends the use of TLS client certificates. With this type of authentication, a device uses a unique private and public key that the Exosite platform uses to both authorize and identify the connecting device. Consider the security requirements for storage of the certificate in your edge device.
- Public key infrastructure (PKI) provisioning. Combined with TLS client certificate authentication, PKI enables a device to provision using a certificate signing request (CSR) that the Exosite platform utilizes to issue the device certificate through the configured Certificate Authority (CA) to both authorize and identify the connecting device. See our blog on PKI authentication for more in-depth information.
Additional Authentication Methods
The following two authentication approaches for devices are also supported and only recommended when TLS Client Certificates cannot be used.
- Token- and password-based authentication. With these types of authentication, a device receives a private authentication token or can provision credentials for a given password (of at least 20 characters) to be used in subsequent communications to identify and authenticate itself to Exosite’s platform.
Token- and password-based authentication, when used with encrypted communications, are generally secure but are susceptible to exposure. Token and password credentials are transferred over the wire in order to authenticate with the server, while TLS client certificate private keys never leave the device. This results in issues that range from non-secured storage in the manufacturing process, to low entropy of the credentials.
Tokens and passwords are typically used for initial prototypes to test connectivity. For scenarios when TLS Client Certificates are not possible, tokens and passwords may be used in production-scale deployments of devices. If used for large-scale production, turn off the ability for devices to register their own identity and instead upload lists of identities at manufacturing to limit and restrict devices attempting to provision. It is also important to ensure devices are using encrypted communication, as the tokens are sent with messages. When devices provision, whether using MQTT or HTTP, they will receive a token that they must securely store and use with all API communication. The device must also be able to re-provision if its token is revoked.
Question 2: How will this impact the manufacturing process?
Once you select the type of authentication that is best-suited for your application at scale, it’s time to establish how that will impact the flow of activities that take place during the manufacturing process. This includes, but isn’t limited to, how the appropriate identifiers, keys, or certs will be loaded on to your devices.
Below, we’ve identified key areas for consideration based on the type of authentication you’ve selected.
- TLS client certificate authentication. The main consideration when using TLS client certificates is setting up software and scripts to automate the creation of certificates, loading them onto the device, and uploading them into Exosite’s Murano platform. Individual device identities can be whitelisted along with their certificate, or many identities and certificates can be uploaded in bulk with a CSV file (see more in-depth technical information on our documentation site).
- Public key infrastructure (PKI) authentication. In addition to the automation considerations noted above when using TLS client certificates, when using PKI you must also consider how to set up the integration with the CA.
- Token- and password-based authentication. The main consideration when using token or password authentication is whitelisting the device identities. This can be done in bulk by uploading a CSV file (see more in-depth technical information on our documentation site). A device can finish the authentication during manufacturing or products can be shipped, waiting to authenticate when an installer sets the device up in the field (Note: The default authentication period after whitelisting is 48 hours, which can be customized). The authentication process is separate from claiming or assigning ownership of the edge device in software applications.
Question 3: Will there be an intermediary cloud connection?
It’s important to understand whether your devices will connect directly to the Exosite platform or if they will connect to another cloud platform that will then share the data with Exosite. If the latter solution setup will be used, you will need to ensure you have a provisioning and authentication process in place for the cloud platform your devices will connect to. Once your devices have connected to that platform and it is ready to share data with the Exosite platform, Exosite will authenticate that cloud-to-cloud connection, but will have to assume the authenticity of the device data. So, be sure to work with the cloud provider your devices will first connect to to ensure provisioning and authentication is handled properly.
Provisioning Key Takeaways
- TLS client certificates are the recommended authentication approach for higher-level security, but token- and password-based authentication are also supported when TLS certificates are not possible from edge connected devices.
- Consider authentication and security requirements as new device hardware and firmware requirements are being designed, rather than choosing what can be supported after hardware and software are developed.
- Automation is important for manufacturing/production on a large scale, whether building your own edge hardware or buying a configurable general-purpose device. APIs and bulk uploads of device identities and certificates are supported by Exosite’s Murano platform (learn more on our documentation site). Ensure device firmware for authentication has been tested before manufacturing and installation.
- Exosite offers support packages that provide a dedicated applications engineer to help with any provisioning needs. Learn more here.
The out-of-box experience for your users is an important aspect of your solution that you may not have had to consider during the proof-of-concept phase. As you move into commercial deployment, you’ll need to carefully evaluate the setup process for your customers—this will require an understanding of their technical capabilities, how they expect to interact with your devices, and how involved in the setup process you’d like to be.
Question 1: How technical are your customers?
Consider your customers’ capabilities from a technical perspective. Do they have engineers on staff that can configure a sensor and gateway that you sell? Or do they need a solution that just works out of the box? Once you have an understanding of this, you can use this as a guide to determine how much technical documentation you need to provide and how much pre-configuration of the devices you need to complete.
Question 2: How will device ownership be handled?
Next, consider the concept of device ownership. For consumer-focused smart devices, this topic is fairly clear-cut. A smart thermostat, for example, is purchased by an individual consumer who will own it, claim it, and manage its lifecycle.
However, this is often more complicated when it comes to commercial or industrial devices. In this scenario, it’s important to consider how you will enable your devices to be claimed on behalf of an organization (i.e., your customer) rather than an individual.
For example, will your organization manage user onboarding and assign edge IoT device ownership to their group within the application, or is it preferred to have end-users self claim the edge devices themselves? Allowing users to claim the edge devices themselves requires less administration but more setup in the IoT Connector used by the ExoSense application to enable self-claiming, setting up claim codes, and providing claim codes to users as stickers, QR codes, etc. See Question 3 below for more information.
For hardware only used by your organization, automatically assigning ownership by an in-house administrator or automation software using APIs is likely all that’s needed.
Question 3: How hands-on do you want to be in the device configuration process?
Finally, it’s time to think about the role you will play in the setup process, namely how involved you will be in device configuration.
- If your customers expect to open the box, turn on the device, and just have it work, you may need to be prepared to complete all of the device configuration, prepare the application, and assign the devices to your customers, so everything works the moment your customers turn devices on. This scenario requires significantly more administrative work on your end, but will ensure you have control over your customers’ experience and level of success.
- If you’d like to have less involvement in the setup process and/or your customers would prefer (and are technical enough) to handle it, you will need to ensure there is a clear process for them to create their own accounts, claim devices, etc. This may be as simple as providing a QR code for them to scan or a sticker on the device with a code that will enable them to begin the setup process. This scenario provides a greater level of flexibility for you—customers can purchase the devices from anywhere, set up everything on their own, and use the device however they want. However, you will have less control over their experience and level of success.
As you consider each option, take into account the expected scale of your product offering. If you plan to have a few hundred devices, high-touch administrative and management activities will likely be doable. If you plan to have thousands or hundreds of thousands of devices, you may need to leave more of the configuration/setup process to your customers.
For either scenario, Exosite provides the concept of “asset templates” that can simplify how devices are created within the ExoSense application. When a device is connected, templates provide a starting point to guide the creation of the digital version of the asset within the application, including how the device’s data pipeline is set up, how signals are mapped from the edge device, how that data is used for analytics and transformation functions, what rules apply, and how dashboards appear. Templates simplify the process for your customers, if you will allow them to set up devices, and expedite the process for your internal team, if they will own that function, so they don’t have to start from scratch every time.
User Setup Key Takeaways
- The number of connected edge devices and customers using your solution will drive the decision on whether to invest in allowing end-users to claim ownership of connected hardware.
- ExoSense supports scenarios where administrators in your organization fully control onboarding and assigning ownership, or allow self registration and claiming of devices.
- ExoSense natively supports customer businesses as ‘groups’ for assigning users, connected edge devices, and digital versions of their assets, including using the UI and API to create groups, assign users, and assign ownership of the edge IoT device and thus it’s streaming data.
- For more information on customer onboarding and deployment models, see our blog.
During the proof-of-concept phase, loading firmware onto your devices was probably handled manually on a small number of devices. As you move into commercial deployment, you’ll now need a process to load firmware onto hundreds, thousands, or even hundreds of thousands of devices at a time. The key considerations around this process depend heavily on the capabilities of your organization.
Question 1: Are you building custom hardware?
Our customers who are original equipment manufacturers (OEMs) generally build the hardware that is used in their connected solution. For example, an OEM may build both the electronic controller that is fitted into a piece of industrial equipment, as well as the gateway the controller will use to send data about that equipment to the cloud.
If you fit into this category, you likely already have standard electronic manufacturing processes in place that will allow you to load, verify, and test firmware. For a connected device, you’ll need to add a few additional steps to verify that devices can:
- Connect to the network (especially if they are relying on cellular connectivity)
- Talk to Exosite’s device protocol APIs
- Complete in-field updates (one benefit of which is that your devices will be updated to the latest and greatest software during the manufacturing process)
Question 2: Are you buying general hardware?
Our customers who do not manufacture hardware generally plan to purchase off-the-shelf connectivity hardware. It’s important to realize that most off-the-shelf industrial gateways either a) have no software at all, meaning you will have to build and burn your own image onto each unit, or b) have some software, but will still need your custom application loaded onto each unit.
If you fit into this category, it may be helpful to work with a system integrator or distributor that will purchase the hardware for you and preload and test the device firmware. If that is not an option, you’ll need to ensure you have or hire a resource within your company that can complete these tasks.
Question 3: Will your customers want/need to update firmware?
Regardless of whether you will build or buy hardware, you’ll also need to take your customers’ expectations into consideration when it comes to device firmware. If your customers are technical and will expect to have some control over this aspect of the solution, what paths will you give them to make changes/updates? Is it something they can do through the application UI? Will they have to do it from the device (e.g., log in to the device locally, use an SD card). Be sure to think through this experience and any associated user interface requirements.
Device Firmware Key Takeaways
- When manufacturing your own connectivity hardware, testing connectivity to the platform must be built into your processes by verifying that the hardware can talk over the expected network to the platform. This can be as simple as reading from an endpoint or potentially authenticating and writing data.
- When purchasing off-the-shelf general purpose hardware that must be configured and/or loaded with your own custom software package, it is important to find a distributor or integrator who specializes in performing this process. For small volume deployments, you may be able to handle this in house. However, it can be beneficial to find a provider to do this for you if you would like to purchase connected device hardware that is ready to go.
- Many of Exosite’s partners provide hardware that requires minimal setup to use with Exosite’s platform. Some can be purchased and ‘claimed’ with no configuration, while others typically just need your unique IoT Connector ID set. See Exosite’s partner page for more information.
- When building connected hardware, take advantage of the ability to remotely update the firmware over the network. This is one of the most important features of connected hardware. Exosite’s Murano platform and ExoSense application support OEMs and end users to manage software updates on connected edge devices.
It is common for organizations looking to sell connected solutions to overlook key aspects of the manufacturing process, including authentication, device firmware updates, and the end-user device onboarding experience. The main focus is often to get the device connected upfront and then work to monetize with customers, only to come back to these areas when it’s time to sell the product at scale. When manufacturing considerations are taken into account at the beginning—often in parallel to the proof of concept phase—it can simplify the process and reduce the potential for issues that may impact your ability to have devices delivered and installed.
This blog post only begins to touch on the considerations for manufacturing. Exosite’s team has helped hundreds of businesses build, connect, and deliver connected solutions. If you’d like help navigating this process, Exosite can guide you through these topics and offer business and technical support throughout your product’s lifecycle.
Still in the early phases of your connectivity journey? Check out our blog on becoming a full solution company. You’ll find helpful tips about how to prepare your organization to add software to an existing hardware product, overcome challenges, and set yourself up for success.