Now What?
You’ve Heard of M2M. You Understand the Business Value. You’re Ready to get Started. Now What?
There’s a saying about raising children that also fits pretty well for the M2M industry: “You know children are growing up when they start asking questions that have answers.” That’s a pretty big step for this industry to reach—especially the answer part.
Recently, M2M invited a panel of leading technology and service providers to answer some of the most challenging and persistent questions related to technology selection and deployment. Their answers, along with the collective experiences of the customers they represent, begin to form the basis for best practices in device networking.
The idea is to take all the typical answers a customer might receive in the course of researching M2M and put them back-to-back with equal billing. The theory goes that if customers know what questions to ask and what answers to expect, they’re better able to make decisions about how to put the technology to work.
The questions and responses are divided into two groups, with each group intended for a specific type of M2M adopter. First are questions about network-enabling fixed assets; these are tailored for companies that own the assets they want to network and also for manufacturers that plan to monitor assets at customer sites.
The second group of questions is about selecting and embedding cellular wireless radio modules. These comments are designed to help developers better understand factors such as certification, form factor, and support issues involved in bringing products to market with wireless M2M connectivity.
Whenever possible, answers were omitted that promoted specific products or swayed the reader too far in a direction that favored one specific type of technology. Understandably, though, vendors tend to answer questions from within their own frame of reference. Customers encounter the same thing when they’re researching potential solutions, and this reference is designed to give them as many perspectives as possible to the issues they may encounter.
Q&A SOURCES
To answer some of the most persistent and challenging questions about machine-to-machine adoption, M2M queried many of the industry’s leading technology and service providers.
Advantech
Paul Wacker, Product Manager, eAutomation Group
Aeris.net
Bob Fultz, Senior Vice President, Customer Engineering
Axeda
Dan Murphy, Director, Product Marketing
Comtech
Steve Whitehead, Technical Director
eDevice
Michael Freudmann, Vice President, Business Development
EMRT
Matthew Lehr, Senior Consultant, Embedded Systems
Michael Mahoney, Enterprise Solutions Consultant
Christian Nissen, Enterprise Solutions Consultant
Ezurio
Nick Hunn, Chief Technology Officer
Integ Process Group
Adam Green, Vice President, Business Development
Janus Remote Communications
Ken Hartman, Chief Technology Director
Kyocera Wireless
Dean Fledderjohn, General Manager, M2M Business Segment
Kore Telematics
Alex Brisbourne, President and Chief Operating Officer
Lantronix
Mark Prowten, Director, Device Networking Solutions
Motorola
Aviad Geffen, Unit Director, Wireless Modules
Multi-Tech
Duane Wald, OEM Sales Manager
Palantiri Systems
John Canosa, President and CEO
Precidia Technologies
Deepak Wanner, President
Qualcomm
Steve Pazol, Vice President/General Manager, nPhase
Siemens
Olivier Clerc, Hardware Application Engineer
Loic Bonvarlet, Software Application Engineer
Peter Fowler, Vice President/General Manager, Wireless Modules
Telit
Roger Dewey, President, Americas
Wavecom
Scott Deyoe, Field Application Engineer
Brad Teeter, Field Application Engineering Manager
Q&A: Fixed Assets
1.Hardware Selection
How can a customer determine which type of device-connectivity hardware is required for monitoring its fixed assets?
Lantronix (Prowten):
First, adopters need to understand what type of communication interface is on the fixed asset. Is it serial (RS-232, RS-485), USB, or a proprietary interface? Next, what type of connectivity is required on the network side: Ethernet, wireless, or cellular? From there, the customer can determine what hardware to consider.
Palantiri Systems (Canosa):
Hardware selection should be driven by the systemwide architecture. If external hardware is needed to support communications, it must be driven by the system requirements such as the need to support a specific software agent and whether the hardware is dedicated to a single device (one-to-one) or part of a gateway-style (one-to-many) deployment.
Multi-Tech (Wald):
An efficient and cost-effective means to transmit data from fixed assets to a central server is to use operator-owned, standards-based networks. The primary functions of the hardware are the physical interface and software protocol interfaces to the communications network. The most common operator-owned networks for device networking include dialup, Ethernet, Wi-Fi wireless, cellular wireless, and WiMAX wireless.
Monitoring fixed assets may be local, nationwide, or global. In each case, a single network may not provide the necessary coverage, and having the ability to use an alternate connectivity option may be an important consideration in selecting a communications vendor. Another criterion for selecting a hardware manufacturer is its infrastructure and experience in ensuring device compliance to requirements defined by the industry, the network operator, and/or regulatory bodies. This is a baseline for network compatibility and interoperability and is an indicator of a supplier’s ability and flexibility to react to a variety of issues that you will be faced with in the market.
Precidia (Wanner):
Customers should look not only at traditional criteria such as interface type or security features, but also consider the installation and management of these devices once in the field. Does it offer a simple means of remote access? Do its features aid in the supportability of this product? These are the tools that can differentiate device connectivity hardware products.
2.Fixed Wireless
When would a company choose wireless connectivity for networking fixed assets?
Integ Process Group (Green):
Wireless networks should only be selected when wired networks are not available. If possible, wired networks provide a level of robustness and longevity that wireless cannot match. When costs and convenience prohibit wired networks, wireless is selected. For assets in very remote locations, cellular or satellite wireless can be cost-effective.
eDevice (Freudmann):
There are several scenarios where wireless connectivity is the best option for networking fixed assets:
(1) For connecting fixed assets in remote locations where there is no wired network. Bringing fixed lines to such locations is usually very expensive and not cost-effective when compared to the cost of wireless connectivity.
(2) For connecting fixed assets in locations belonging to third parties. For example, a vending machine operator installing machines in a corporate environment may not be given access to telephone lines (due to cost) or to the corporate Ethernet network (due to system administrators’ concerns). This is also true when you want to maintain control of all costs relating to the rollout and operation of equipment installed in third parties’ premises.
(3) For connecting fixed assets that are located in numerous places that are not known at the time of manufacturing. Using wireless connectivity in such scenarios removes the unknown factor by reducing reliance on the availability of fixed networks in future rollout locations.
(4) Finally, when connecting several devices located in close proximity to one another, wireless connectivity should be considered as a means to reducing both capital and running costs. The wireless technology used in such applications, however, would not be cellular but rather short or medium-range RF (e.g. ISM or ZigBee) that incurs low or no running costs. Additional long-range connectivity units (either cellular or wired) will also be required.
Lantronix (Prowten):
Usually wireless is the best option for environments where running Ethernet cables is prohibited due to the amount of cable needed, location of the fixed assets, or if the fixed asset is required to be mobile. The cost of running cables can also be a factor in choosing wireless over wired connectivity.
Multi-Tech (Wald):
Wireless connectivity for traditionally monitored devices is becoming more complex as companies convert circuit-switched phone systems to packet switched VoIP. The RJ-11 jack is being replaced by restricted access RJ-45 network ports. In addition, local-area Ethernet and Wi-Fi data networks within a company are becoming off-limits to third-party devices as companies try to manage bandwidth and combat unwanted network traffic. An attractive alternative is wireless connectivity that bypasses the local network. In addition, companies that are expanding upon what has traditionally been monitored to include new device types located in remote areas with no wireline network access are prime candidates for wireless connectivity.
3. Security
What questions should an adopter ask its technology providers and/or equipment suppliers about data security for physical assets?
Advantech (Wacker):
At a minimum, one should ensure that authentication, authorization, and accounting are an integral part of the solution. Authentication ensures that users or systems are who they claim to be. Authorization makes sure that users or systems are only allowed to perform the functions they are allowed to do. Finally, accounting makes sure that important information is captured, such as connections start/stop times, amount of data transferred, or commands executed. In more demanding applications, where sensitive data is to be transferred over a public network, data encryption should be a requirement.
Lantronix (Prowten):
First, you need to determine if the connected equipment has any security currently implemented. If so, what levels of security? Is it log-in passwords, authentication methods such as LDAP or SecureID, encryption protocols such as AES, etc.? Is the data encrypted locally or on each end of transmission? Are there different log-ins for all equipment, such as administrative versus user login?
Ezurio (Hunn):
Does the solution provide end-to-end security and is the data encrypted to an industry-acceptable level? Don’t waste time talking about local security, such as client to Wi-Fi access points. That’s irrelevant; look at the big picture.
Axeda (Murphy):
Adopters should ask their technology providers if their system supports SSL data encryption as well as mutual authentication using bidrectional digital certificates. They should also ask how they can ensure only authorized parties have access to designated devices and data and enable end-customers to limit access, views, and even actions based on the user’s role. Finally, they need to ask how their provider or supplier can ensure compliance with regulatory requirements as well as prove system certification by a third-party, such as VeriSign.
Precidia (Wanner):
Every user has a different set of needs when it comes to security. Those dealing with mission-critical or consumer data such as creditcard numbers will obviously have standards that the vendor must understand and comply with. There is a common thread among users in all sectors though, beyond the need for field-tested firewalling and encryption—the importance of proper configuration. Properly configured devices have been demonstrated to be more resistant to hacking and other threats. Network-configuration managers simplify this task for users.
Palantiri Systems (Canosa):
The single most important question to ask is, “How successful have your customers been in getting their customers to accept deployment?”
4. Data Protocol
How can a company manage legacy data protocols in an Internet-based remote-monitoring system?
eDevice (Freudmann):
It depends on whether the company wishes to keep both the legacy equipment as-is and the backoffice application as-is, or wishes to maintain only one of them as-is. If both the equipment in the field and the backoffice application will remain intact, then the easiest solution is to use tunneling technology on both the equipment and the backoffice. On the equipment, it will be a combination hardware/software solution that is designed to speak to the legacy protocol without the legacy protocol having to be changed at all. On the backoffice side, it will be either client software running “next to” the backoffice software receiving and translating the data back into the legacy protocol, or middleware-server technology that will push the data to the legacy backoffice in a data format it understands. If a company is adopting a completely new backoffice application then the conversion of the legacy protocol can be done at the device level using programmable M2M connectivity hardware.
Comtech (Whitehead):
Many legacy protocols are based on traditional polling techniques, where the management application collects data sequentially from remote assets. By contrast, cellular networks and the Internet are inherently client-driven, which means that information from remote assets can be transferred concurrently to improve realtime performance. Legacy protocols are best implemented within the remote M2M device, which is adapted to gain the benefits of open Internet client driven protocols, realtime performance, scalability, data sharing, etc.
Qualcomm (Pazol):
While there are a number of methods for handling legacy data protocols, implementing a middleware platform is key. This allows you to deal with legacy protocols like Modbus and also allows companies to maximize their flexibility to deal with whatever comes along in the future.
Advantech (Wacker):
Managing legacy data protocols requires either internal or external expertise to develop protocol-translation software, or device-connectivity hardware capable of doing this conversion at the device level. For example, device servers are available that convert from one protocol to another, allowing legacy devices to easily integrate with modern enterprise systems.
5. Scalability
What questions should an adopter ask a technology provider about its ability to handle many thousands of devices?
Comtech (Whitehead):
The adopter needs to understand (in consultation with the solution provider) how much data is likely to be transferred and how often. Some important questions:
1. How many connections can be managed concurrently between the remote asset and central management application?
2. How long will it take to collect data from all remote units?
3. How many central applications can share the data collected from remote assets?
Advantech (Wacker):
Adopters should understand: 1) What additional capital expenditures, other than device-connectivity hardware, are required to support more devices? 2) What additional service fees or licensing costs (if any) are required to add remote devices? 3) Are there any performance or data-storage issues as additional devices are added?
eDevice (Freudmann):
The first question should be how many devices is the technology provider handling in existing running applications? The underlying technology used is also important, both hardware and software. For example, how many concurrent TCP sessions can a single server handle and how will it be scaled up once the maximum number of sessions is reached? How will load balancing be handled when there are multiple servers running? Finally, the network used and service provided are also important. If you are using a dialup Internet service provider, how robust and scalable is it? Where are the POPs located? How many concurrent sessions can be handled?
Integ Process Group (Green):
These days, the limitation is generally not the processing power at the central computer. As systems scale in size the network becomes a severe bottleneck. As a result one quickly has to move to a multiple-server environment (blades, for instance). The quality of supporting software applications also has an impact on scalability. Database sizes and GUIs all contribute to the effectiveness of tools as the device count increases. Advanced software to monitor thousands of devices is required.
6. Availability
How does a platform provider enable/guarantee availability of an M2M system and delivery of machine data?
EMRT (Lehr):
To guarantee the delivery of machine data within a larger M2M system, platform providers must address end-to-end points of failure using techniques such as redundancy, fault detection, ruggedization, and designing/planning for network outages. Additionally, techniques such as FMEA allow customers to anticipate failures and their symptoms and to “design in” recovery actions before field deployment.
Axeda (Murphy):
Platform providers must design their systems for continuous duty applications. The system’s server should be configured for high availability with redundancy at the Web server, application server, and database levels. Also, even when devices cannot communicate with the system’s server, for whatever reason, the data should be saved and transmitted in a queue. During the interruption, data should be continuously collected, logic evaluated, and alarms processed. This prevents data and alarms from being lost during communication interruption. When the connection is restored, the queued data is transmitted immediately (availability and size of the queue is configurable). Queuing helps ensure that valuable data is not lost due to intermittent connections or server failure.
Comtech (Whitehead):
Hosted services should offer redundancy of infrastructure such as network connections and servers, which are clustered and mirrored to recover from data loss.
Palantiri Systems (Canosa):
Clustering/redundancy and automatic failover are keys to availability. In addition, a process for disaster recovery must be documented in detail.
7. Enterprise Integration
What steps are required to integrate machine data with existing enterprise software applications?
Palantiri Systems (Canosa):
Being able to get machine information into existing enterprise applications is key to long-term M2M success. The key steps are: 1) selecting a vendor that has an architecture designed for two-way integration and, 2) understanding which data is valuable to what enterprise software package as well as the trigger for data exchange.
Qualcomm (Pazol):
Integrating machine data into existing enterprise software applications can be relatively simple if all that is being done is replacing current manual data entry steps with automated entry. On the other hand, much of the data that is newly exposed to the enterprise is really that—new data. Therefore, steps required in any significant IT integration project include project management, requirements/use case definition, development, data normalization, and testing. Therefore, to be effective in implementing wireless solutions, knowledge of the technical challenges is only part of the picture. A truly effective provider must be able to step up to the broader issues involved in helping a client assimilate new capabilities into their business process.
EMRT (Mahoney):
Integrating machine data with enterprise systems is similar in many ways to traditional system integration. Common steps include determining data-access method; defining data security; determining data-transformation requirements; determining integration technologies or standards to use; and integration testing. Once basic data integration is complete, M2M adopters can maximize the value of their intelligent machines by defining opportunities to represent, distribute, and reuse machine data across their enterprise, creating additional business value to enterprise constituents.
Integ Process Group (Green):
Many machine-data integrators will partner with key enterprise software vendors. Machine-data devices can be compatible with your enterprise software either by using the vendor protocol or by using a generic protocol that the enterprise software can read. By choosing a machine-data integrator that is familiar with these technologies can vastly aid successful implementation.
8. Customization
What tools are available for an adopter to customize the functionality and look and feel of its M2M application?
Axeda (Murphy):
Vendors should provide adopters with a software development kit to enable developers to customize, extend, and integrate the system. The kit should contain documentation on the programming APIs, information on how to extend the system, and sample code. Finally, the user interface should use the latest in rich-Internet application technology and enable end users to customize the interface to feature their own branding and preferred views.
Ezurio (Hunn):
These are generally custom, although if you know how the data is stored into the database, existing tools can often mind and process it.
Comtech (Whitehead):
Adopters can set up templates and aliases to describe their remote assets, devices, and data. Online reports can be produced across the network of remote assets. Adopters and their end users require data to be presented in specific ways and provide a framework for rapidly developing custom dashboards. Data can be delivered automatically to third-party backoffice systems through Web services, FTP, etc., for offline processing or integration within the enterprise.
Palantiri Systems (Canosa):
Tools are going to be based on the underlying architecture of the M2M solution. Key questions to ask include:
1) How open is the architecture? Does the vendor provide APIs that let you extend and enhance the user interface?
2) What technologies are used? A Flash-based user interface may not be the best thing for a company with a lot of development resources schooled in AJAX.
3) How does the architecture fit in with other corporate Web standards? If the goal is to provide outside access to customers, the system should support re-branding to retain your corporate identity.
Q&A:
Wireless Modules
1. Certification Cost & Complexity
What do developers need to understand about the process of cellular network certification for M2M devices?
Motorola (Geffen):
Cellular network certification process is a mandatory requirement by the carriers aimed to avoid any potential network outage that may be caused by M2M applications. The certification process can vary from 1-6 months, and developers are requested to perform various predefined test scenarios to meet with network-interoperability requirements.
Kore Telematics (Brisbourne):
Certification is a requirement in North America—not an option. Cost and time are the limiting factors. The process of cellular network certification in North America for M2M devices has three components: Industry Canada/FCC government certification; PTCRB certification; and operator-specific certification. In addition, if the device is intended for the automotive industry, it may require compliance to SAE standards. Each has its own cost and complexity.
Wavecom (Deyoe):
Develop a business relationship with the cellular provider early on in the project development to determine the certification that will be required as a result of the features to be offered. Choosing a pre-certified module can offer cost and time savings in the application-certification process.
Janus (Hartman):
It is necessary. It is tedious. It is expensive. It is time consuming. Also, it is of questionable value in terms of network operational issues in that it adds no value to the application.
2. Data Speed/Throughput
What should developers take into consideration regarding a module’s throughput class and cellular generation capability?
Aeris.net (Fultz):
This goes directly to the application requirements. Most M2M applications do not move a lot of data and require connectivity, not bandwidth. However, that is changing as coverage and cost of bandwidth improve. If the application does require bandwidth, data speed is critical and a developer needs to understand the real throughput versus the theoretical.
Motorola (Geffen):
A developer should always carefully examine whether there is a real need for high throughput. Often, developers pay more for high data rates when they don’t necessarily need them. A developer should make sure its buffers can manage the data rate before choosing higher throughput. If it cannot, the developer should verify that the class is configurable by the module manufacture.
Wavecom (Deyoe):
The developer should remember that advertised data rates for cellular technologies do not take into account a vehicle moving at a high rate of speed and the associated reduction in data throughput.
3. Developer Support Services
What should developers expect from their module provider beyond the hardware itself?
Kore Telematics (Brisbourne):
Developers should expect at a minimum a development kit including an application board complete with SIM socket, power management, serial interface and an antenna system. In addition, the module provider should supply technical manuals, installation notes, sample firmware and scripts, and some type of support line to answer additional questions.
Siemens (Bonvarlet):
Developers should expect best-in-class support to ensure a smooth integration (hardware, software, certifications) and specific/dedicated services for complex applications.
Kyocera Wireless (Fledderjohn):
Developers should expect tools and classes for development, testing, and certification; resources available for direct or indirect support issues; and ontime delivery of robust and stable product.
Wavecom (Deyoe):
Hardware is only the starting point for a wireless M2M solution. In addition, developers will need hardware and services to bring their application to life. Finding a partner that can provide a complete solution is the best way to ensure you get the documentation, application notes, answers, and technical support you need. Some manufacturers provide additional value-added services for a fee. These services may include design reviews, certification services, product testing, and custom hardware/software solutions.
Aeris.net (Fultz):
Developers should expect deep knowledge of both the module and the network services it supports. Right now, the module providers are focused on supporting the hardware and developers look to network providers for development issues regarding how best to use a given network.
Janus (Hartman):
Developers should expect application examples, customization of operational parameters/characteristics for better network conformity, detailed timely technical support (power supply considerations, network registration and startup characteristics, parametric configuration variables, and embedded code update re-flash provisions.
4. Programming Capability
How important is it to choose a module that can be reprogrammed or updated after initial deployment?
Aeris.net (Fultz):
Critical. Having the flexibility to fix over-the-air bugs, upgrade services, change firmware, etc. is a huge cost savings as opposed to having to physically touch a module after deployment. Of course, IP network connectivity is required for this.
Kore Telematics (Brisbourne):
Very important. The ability to perform troubleshooting over the air would be a major in-service advantage. Fault-finding abilities of most M2M devices is non-existent! It’s critical that “deep reset” capability exists on a unit by reset switch or OTA. This is becoming the norm in that a majority of devices are designed to be inaccessible both in installation and connectivity. Some devices are designed with no external interface and after the initial factor load, they cannot be updated without returning to the factory and disassembled. That is a future problem.
Motorola (Geffen):
OTA capability is extremely important. The modules are often produced with upgrades according to carrier’s requirements. It is important that fielded units can be upgraded with no need to physically attend the unit.
Siemens (Fowler):
This depends on whether the device already has over-the-air provisioning enabled via its main microprocessor. If, however, the device is using the module’s microprocessor to run the application, OTA is the only option and is therefore critical. From a portability standpoint from device generation to generation, an industry-standard offering such as Java is critical so that you are not locked into a module maker’s proprietary or semi-proprietary solution.
5. Form Factor Compatibility
How important is it to choose a module that is compatible with other products from the same manufacturer?
Motorola (Geffen):
This is becoming a key factor since it is better to build a platform that can use modules of different technologies and not have a different product/design for each technology. In addition, since chipsets are becoming obsolete and manufacturers are coming out with advanced technology, it is important that the manufacture commits to a form factor in its roadmap.
Kore Telematics (Brisbourne):
Form-factor compatibility is not critical. Most applications are tailored to the developer and once a module has been chosen it is, for the most part, not replaced.
Telit (Dewey):
First and foremost, the most obvious reason for selecting a vendor with compatible form factors across technologies and functionalities is the added degree of flexibility it gives the developer when it comes to addressing functionality-level and regional-market requirements for a final, integrated product. If the wireless M2M device selected is part of a family of form-fit-function compatible units addressing GSM, CDMA, Wi-Fi, and other wireless technologies, then the sale of the integrated solution to this multinational customer is a simple matter of populating that solution with the proper radio for the use region, which can be done as late as the fulfillment point. Additionally, this election of compatible devices affords the developer substantial savings in development costs and finished-goods inventories, since the number of different finished products required to address different markets is reduced.
As important as these factors are, there is one factor not readily apparent but which has a potentially much higher impact on the lifecycle planning and business case of the developer’s final integrated solution. That is the compatibility of form factors across generations of the same product. Typically, solution developers plan their solutions in lifecycles of 5-10 years of active duty. It is imperative for the developer to count on continuity of supply of the same form factor and function over this span of time, even if the radio device needs to go through generational changes to stay current with ever-changing wireless standards.
6. Module Launch Date/Longevity
What are the pros and cons of choosing a module that has been around more than two years compared to one that became available more recently?
Kyocera Wireless (Fledderjohn):
With more mature modules, there is a strong history of hardware and software stability, carrier certifications, documentation, and support. The developer knows it will have a strong supply chain and won’t have to recertify as with short-lifespan products.
Aeris.net (Fultz):
M2M at the device level can be complicated. So having a proven supplier is very important. However, new entrants can provide advantages of latest-generation technology and potentially find ways to reduce costs of the modules.
Siemens (Clerc):
A module which has been in the market for two years is most likely a stable product but has a better chance to be EOL’d first than the newer product.
7. Module Network Certifications
What is the benefit of choosing a module that has multiple cellular network certifications?
Wavecom (Deyoe):
Choosing a pre-certified module provides confidence that your application will work well within the network and can save significant costs associated with certifying the end application. Multiple network certifications offer the developer the flexibility of choosing the network carrier that offers the best plan and services for their end customer.
Siemens (Bonvarlet):
Multiple certifications will ensure worldwide coverage and demonstrate the quality of the module, tested in a variety of environments. It also shows the manufacturer’s ability to maintain a efficient relationship with different carriers.
Aeris.net (Fultz):
Multiple certifications provide more flexibility to the developers and end users so as to not be “stuck” with a given network provider.
Motorola (Geffen):
Multiple certifications make it easier to deploy the host device around the world, and it indicates that the device is stable and robust.
Kore Telematics (Brisbourne):
Sometimes an initial trial with one carrier may not prove the business case, and multiple certifications give a developer the option to look elsewhere for that sweet deal.
8. Software Stack Licensor/Owner
How can a developer find out a module’s software stack owner/licensor, and why is this information important?
Telit (Dewey):
Typically, developers enter non-disclosure relationships with wireless M2M device vendors and this is a very important question that should be posed by the developer to the device vendor in an RFQ. The level of control over the radio’s software and protocol stack is a strong indicator of several important aspects that will have significant impact on the developer’s efforts to bring a solution to market. Primarily, a large degree of control of the stack and software translates into enhanced ability to provide development support, address developer’s specific changes and or adaptations, and do all this in a timely manner.
Control of the software stack is one of the most important indicators of the degree to which a wireless device vendor will be able to advance in product generations maintaining full, backward compatibility. Backward compatibility guarantees the developer control over solution lifecycles. Without it, the developer is at the mercy of the wireless device vendor, having to react to functionality changes at every product generation by spending development, testing, and certification resources, potentially with little or no added value to the overall solution.
Motorola (Geffen):
This information is important due to the fact that the PTCRB and GCF requirements are raised approximately every three months. If the module provider is the owner of the stack, it is more flexible in maintaining it and does not rely on a third party for maintenance.
Wavecom (Teeter):
Customers should contact their module’s manufacturer to inquire about the vendor used to supply the software stack. Most manufacturers pay royalties and license fees on behalf of their customers and build this cost into the end price of the module. If you choose a manufacturer who owns their own stack, you can count on more flexibility and responsiveness to both network changes and customer needs.
Aeris.net (Fultz):
A developer can obtain this information by asking. Typically, the larger GSM module manufacturers have their own stacks. All CDMA module manufacturers use a Qualcomm stack. Ownership can be important for cost reasons, i.e., not having to worry about licensing costs.
9. Total Cost of Ownership
How important is the upfront hardware cost of a wireless module, and how can developers determine the total cost of ownership?
Wavecom (Teeter):
The upfront cost of a module does not always take into account the overall costs of developing the customer’s application. Typically, the module represents the most expensive component in many customer applications. Value-added features such as embedded application space, controllerless GPS, embedded TCP/IP stack, and an onboard SIM holder cut the cost of the final application. Customers may choose to implement such systems on an individual basis. This allows the customer to purchase a less-expensive module, but they still have to purchase many other components from different vendors and integrate the entire system.
Kore Telematics (Brisbourne):
Upfront cost is very important as these devices are placed into production to become mass quantities, resulting in bottomlines that must be tightly controlled. If we compare it to a network system comprised of a base station and many customer-premise units, it is not the $500,000 base station that needs tight costing, but the $350 customer unit, since this is where the mass-deployment occurs.
Aeris.net (Fultz):
If a developer only looks at the cost of the module, it will miss the larger lifecycle costs of networks, application services, certification, and others. Understanding the average life of the device and calculating a TCO is an important sales analysis required by both the radio suppliers and the network providers. For example, a GSM module may be $20 less expensive today, but the cost of CDMA network service over 48 months can be as much as $50 less.
Siemens (Clerc):
The total cost of ownership will include the certification costs for North America, the bill-of-materials cost, and the integration effort (NRE). Other costs (such as initial module pre-certification, GSM IP, and local support) are included in the cost of the GSM module.
Telit (Dewey):
Developers are abundantly aware of the impact of the initial hardware cost represented by the wireless M2M device. In the case of cellular technologies, it is not uncommon for the radio to account for more than half of the total bill of materials for the developer’s solution hardware. Because of that, making a selection based largely on the price of the radio alone is an equally common problem in wireless M2M adoption. Developers should take into consideration when selecting a radio vendor:
1. What kind of guarantee is the radio vendor providing for the availability of the device’s form/fit/function for the time span of the developer’s solution?
2. Adequate licensing: the developer needs to be cognizant of this factor and make sure the vendor provides enough evidence of adequate licensing from the various patent holders to sell the radio.
