|
|
|
INTRODUCTION |
|
Welcome to the m2mpremier.com 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.
|
|
|
|
|
|
|
|
|
|
|
|
|
FEATURED ARTICLES |
|
|
|
|
|
CONTRIBUTED ARTICLES |
|
|
|
|
|
ADDITIONAL RESOURCES |
|
|