In the previous blog post, we discussed the potential benefits for Original Equipment Manufacturers (OEMs) of digitizing software and content distribution to “Things.” We also discussed the capabilities OEMs would need to address to incorporate a future-proof system and the complexities involved.
In this article, we will discuss the software lifecycle process and various realization models for software and content distribution to software driven things.
Software lifecycle processes
Every software and content package has a lifecycle that is associated with the DevOps of the software and content provider. A software and content distribution system is the machinery that orchestrates and wires this lifecycle. The typical lifecycle is depicted:
Software Content Management
The ability to manage different versions and maintain history is a key capability of content management. Multiple replicas of content should be maintained across different sites to ensure high availability, decentralized distribution and protection. The content needs to be backed up constantly and supported by adequate recovery mechanisms. Access mechanisms of stored content will ensure adequate access controls at granular levels, and at the same time, be fast and easy. The content management infrastructure could also be used for purposes beyond software – for example, training materials.
Often overlooked, dependency management is crucial. The system should support the ability to model dependencies across hardware components, software components, their compatibility, topologies and interdependency –
When we add the contextual dependencies of a software and content package, we have a highly complex model. Managing contextual dependencies is critical for a scalable, future-proof and sustainable software and content device distribution system. The diagram shows the package’s range of possible dependencies:
Configuration Management: A device software and content distribution system manages the current state and configuration of all of its devices. This involves information on the current software and content version, dependency versions, the last patch upgrade, upgrade status and configuration values. Some systems extend this functionality to associate service records and even to attaching log files for troubleshooting.
Device Agents: The device agent is the software which either resides on a fully connected asset, or is housed on an intermediary gateway device for indirectly connected or unconnected assets. These agents are responsible for delivering content and may also perform updates. To address the challenge of variety and onboarding new asset classes quickly, a simple agent framework which can be easily extended by specific R&D teams is a key requirement. This also ensures uniformity.
Distribution and Delivery: For a global OEM, the install base is often distributed across continents. A fast and efficient distribution and delivery mechanism that can seamlessly cater to the install base is key to the success of any content distribution platform both from a user experience and reliability standpoint. One option being increasingly considered recently is leveraging a content delivery networks (CDN) to address this concern.
The system should be able to customize the distribution logic as per the needs of the manufacturer. For example, ann elevator OEM might want to distribute firmware on a site-by-site basis – regionally or globally.
Security: Security should cover all areas including the device, network, transport, data and application. It’s very important to secure delivery by adequate encryption mechanisms and establish trust and access control mechanisms for both users and devices. For example, a gas engine manufacturer might want to limit control of software distribution to assets on a site to the site manager only.
Realization models: The realization methods for establishing these capabilities will vary greatly, being organization-specific. Although there is no standardized approach, there are three common models emerging for device software and content distribution:
1) IoT Platforms with extended software and content distribution capability
There are several advantages to these platforms. They generally come with a device agent framework and provide Out-of-the-Box (OOTB) support for most of device platforms and languages. They support controlled and automatic upgrades and offer the potential for futuristic road maps aligned to the evolution of intelligent devices. However, there are distinct challenges:
- They are primarily focused on machine/sensor data collection, storage and analysis and hence do not often address contextual dependencies and modeling eco-system complexities.
- There is a lack of support for geographical-distributed delivery.
- These platforms support only a portion of the entire lifecycle and have limited support for customization.
- They may be priced for supporting IoT features even though organizations only use them for content distribution.
- No OOTB monetization techniques are supported.
2) Traditional software distribution platforms offering IoT extensions
These platforms offer well-addressed distribution and delivery challenges, as well as close integration to enterprise systems. They offer the advantage of competitive software monetization models and often provide SaaS based distribution options. However:
- their offering is purpose built for mobile and computing devices and not for IOT
- the agents provided by them are available on only a few hardware platforms
- their platform cannot be customized to align to the domain specific software delivery processes needed in IOT
3) A Hybrid platform based on a standardized foundation
Packaged products or pointed solutions can only address a subset of opportunities and problems. Therefore, OEMs need a well-designed approach that enables flexible ecosystem modeling and dependency mapping frameworks as well as the potential to leverage existing capabilities. A Hybrid platform based on a standardized foundation can be a very flexible and ideal platform for adopting future changes. Because this kind of platform will be organization-specific, it can push an organization ahead of the pack to differentiate itself.
Some OEMs may be put off by the fact that these solutions can take a comparatively longer time to market and stabilize. They may also require multiple partners and/or vendors to implement – for example, solution providers, solution stack vendors and managed service partners. But if manufacturers pursue a hybrid platform approach by following a “build some, borrow some” principle, they can facilitate smooth integration with existing process and systems, and manage diverse requirements across organizational entities while leveraging their existing investments.
OEMs will eventually implement strategies to help them realize revenues through digital services. Selling and distributing the software portion of Things will be at the heart of this journey. Currently, however, most of these organizations have been designed to sell and service boxes. They’re not set up to work in Digital, and many of them end up focusing on solving immediate problems which creates siloed systems that eventually impact end user experience and revenue generation potential. We recommend that manufacturers to take a longer-term view, one that is geared to smoothen the transition to the Digital era and support deployment of current and future digital services.
A software and content distribution system should be capable of reflecting the real world of complex organizational structures (centered around assets) and be flexible to accommodate various orchestration requirements depending on business and service needs. A hybrid platform approach can achieve this and accelerate the digital journey of manufacturers.