|
 |
Deployment Guide
|
|
|
 |
|
INTRODUCTION |
|
Welcome to the M2M Premier Project Lifecycle. This section breaks
down all of the steps involved in deploying machine-to-machine
technology and the typical costs involved in each step. To begin, please select from the directory below. |
|
|
|
|
|
|
|
|
|
|
DEPLOYMENT STAGE BREAKDOWN |
|
|
|
One of the most important decisions a company can make about its M2M deployment is whether to embed communication hardware in the device being networked, or to retrofit it with hardware that connects externally. There are advantages to both approaches, and making the decision is usually a straightforward process.
Some of the steps below apply to the technology providers, some to the adopters, and some to both.
Define Business Objectives
Every M2M deployment must begin with clearly defining business objectives. M2M is often extremely disruptive to existing business processes and cultural acumen, making it crucial that the entire enterprise is onboard.
Customization Requirements (Adopters)
It wasn’t very long ago that almost every M2M application was customized. As the industry matured, technology providers created off-the-shelf components that made it possible to streamline portions of the deployment. However, it’s likely that in any medium-to-large-scale project some customization will be required.
Budgeting and Bandwidth (Both)
M2M applications tend to be cost sensitive and open ended, which makes this step the one most likely to stall deployments. The most volatile aspect of creating a budget for M2M are data communications costs. As the M2M SIG (Special Interest Group) explains in its Best Practices document, “network services costs can be the most significant single recurring cost item for an M2M application. As a result, once the specific communication requirements of an application are determined, methods for optimizing communications cast are quite important to achieving the desired ROI (return on investment) and, in some cases, to determining the economic viability of the application.”
In an M2M application, communications cost takes the form of bandwidth, which is only affordable if the application uses just what it needs to not waste the resource.
Select Communications Model (Both)
Today in M2M, too much is made of the choice of network communication. For most deployments, the choice is straightforward depending on the specific bandwidth and service requirements. Meanwhile, the hierarchy continues to evolve, beginning with wired versus wireless and then delving into wide-area versus local-area. Whatever the case, network service providers, including cellular operators and MVNOs (mobile virtual network operators), are becoming increasingly adept at meeting connectivity needs.
For the specific requirements of transmitting data, the network speed is often an afterthought. According to SIG Best Practices, “Bandwidth is only one—and not necessarily the most important—requirement in determining which network(s) and communications technologies to use. Other requirements may include realtime delivery of data, consistent performance, reliability of data delivery, acknowledgement of data delivery, and perhaps most important, availability of network coverage of the machines that need to communicate.”
Site Survey (Adopters)
If network coverage is the most important aspect when selecting a communications model, then this next step is vital for end users that will actually operate the assets being networked. A site survey consists of verifying that ample coverage is available where the machines will operate throughout the lifetime of the deployment. This feature is becoming a service-portfolio staple of M2M application providers and system integrators.
Hardware Selection (Both)
For end users, purchasing communications hardware for either wired or wireless connectivity has reached the plug-and-play stage. That’s because the burden of making the hardware ready for deployment falls on the application and hardware providers. The development process for this group, by comparison, is infamous in M2M for having a steep and costly learning curve.
For end users, the greatest challenge may be figuring out which hardware options meet the requirements of the application.
The selection process goes well beyond technology features. For example, developers should also weigh such things as the manufacturer’s purchase-order process, volume discount schedule, lead time for orders, warranty and return material authorization process, willingness and ability to make firmware changes for business opportunities, general rapport with the company, and track record of defects in the market.
Hardware developers, meanwhile, have to consider a number of options for their communication modules. SIG recommends: “If you can use a certified device without modification, then you may avoid the need to have your device certified. If your application requires features that are not available on certified devices, then your next approach would be to build the hardware to your specification and add wireless capability to that hardware. This is done by embedding a module into your device.”
Perhaps the most important thing to keep in mind is choosing the right hardware comes down to far more than price alone.
Integration and Testing (Both)
During the last two years, M2M technology providers have made substantial gains in the areas of integration and provisioning. Previously, these were two areas where the end user was either on its own, or a great deal of customized integration was required from an application provider of consulting firm. Now, with specialized application providers establishing best practices and even network service providers managing the go-live process for adopters, standard procedures are emerging for integration and testing.
Certification (Providers)
Unfortunately, the “completion of carrier approvals” remains more than just an afterthought. Certification refers to the process of getting wireless M2M products approved for operation on a cellular network.
Still, certification remains an arduous step in the development process that needs to be allocated in the original budgeting process.
In addition to carrier approval, developers must also pass FCC testing by an approved test house.
The remaining step in the certification process is to gain approval from a testing lab that handles specific requirements for wireless communication.
Activation/Provisioning (Both)
The activation and provisioning process can be one of the most simple steps in an M2M deployment. However, if the M2M equipment manufacturer has not paid attention to details, this simple step can easily become a pain point for the customer.
According to SIG, modems and wireless networks should support over-the-air activations. With OTASP (over-the-air service provisioning), little to no user intervention is required to provision a device for use on a carrier network.
Training (Both)
As a disruptive technology, M2M requires considerable investment on the part of adopters to adapt their business processes. For example, deploying an M2M remote monitoring application requires OEMs (original-equipment manufacturers) to switch from a reactive to a proactive service model. Additionally, managing machine data requires familiarity with tools and performance information that were previously unavailable.
Management and Maintenance (Both)
The M2M deployment process isn’t over with the go-live; management and maintenance continue for the full lifecycle of the project. Typical deployments are generally estimated at five years, and the technical challenges can vary depending on the location of the asset and the method of data communication.
That backend management includes data and physical security as well as firmware updates as the application requirements change.
Application Enhancement (Both)
Many adopters say once they’ve completed a single M2M deployment, additional projects can also be employed. This approach enables companies to make multiple improvements from a single M2M investment. For some companies, the same application/network infrastructure used for one application can also be used for several others. That’s because the application infrastructure serves basically the same function regardless of the specific nature of the application.
Logistically speaking, technology providers are developing methods to help customers leverage their existing investment in device networking.
|
|
|
|
|
| |
|
|