A Personal Trek into the World of Wireless Data

[Note: I recently found this article that I had written 18 years ago in a publications database on the web. For context, this article was written 12 years after the first introduction of the IBM PC, and two years before the initial public availability of the World Wide Web. Some of the topics of discussion are quaint today, such as the focus on mainframe terminal-based applications and on the proprietary wireless networks that prevailed at the time. But the fundamental observations I made then are still true today. Wireless data applications have been a long time coming. – WS]

Wireless datacom is a jump-shift from conventional datacom. A look at some of the fundamental differences.

As technologies change the face of business communications, those who develop, market, manage and use new communications technologies also must go through a rite of passage to understand, interpret and implement new solutions. One particularly challenging transition is the shift from the world of conventional, wireline data communications to the wireless data communications world.

Two factors are stimulating interest in wireless data communications. One is the explosive growth of cellular service. Technology brought a unique and much-needed solution to an area--mobile voice communications--that had been poorly served in the past.

The second factor is the growing disparity between the automation tools available to those who primarily operate from fixed locations (i.e., traditional office desktops) and those who are "mobile." This disparity was not an issue when corporate information systems were primarily host-based transaction processing systems, but personal computers and workstations have altered expectations for employee productivity and effectiveness. As a result, organizations are now investigating ways of bringing mobile employees into the information network.

Last year, I made a personal and professional transition into the emerging world of wireless data communications. Even though I had worked extensively with large corporate data communications environments--IBM SNA, NetBIOS and Netware PC local area networks and "open systems" communications (i.e., TCP/IP and X.25)--my years of experience with traditional data communications proved to be of limited value.

Many fundamental differences exist between the new wireless data communications world and the familiar data communications environment from which I had come. I will focus on wireless data communications in wide area or metropolitian area data networks, as opposed to wireless LANs.

Scarce Spectrum

One of the most striking differences between traditional datacom and wireless data is that the basic, fundamental medium is extremely limited. Only so much radio spectrum is available, and unlike copper or optical fiber, there isn't any more being made. This fact affects all aspects of wireless communications, including its availability, cost and data rates.

The total amount of raw usable spectrum bandwidth available for wireless data communications is roughly equal to 1,700 to 2,000 T1 circuits, 250 to 300 Ethernets or 25 to 30 FDDI networks. While the wireless datacom industry is developing techniques for more efficient frequency reuse and allocation, data compression and high-efficiency protocols, the laws of physics will prevent us from converting to a totally wireless communications world.

Some industry pundits argue that spectrum isn't really scarce but it used inefficiently. While it is true that spectrum in the U.S. isn't used efficiently, the reality in today's market is that virtually all of the most usable frequency bands have already been allocated, either to a specific user or to an industry.

Moreover, the mechanism for allocating spectrum in this country is intensely political, and the rules of the game have been set up such that it is a win-lose situation: If you want access to spectrum, you have to dislodge whoever is currently using it. This process is expensive and uncertain.

In many cases, the incumbent owners of spectrum have long-standing relationships with the regulators, and regulatory authorities have a long history of favoring voice over data communications. The bottom line is that spectrum for data communications will remain scarce.

The scarcity of spectrum is part of what makes wireless communications so much more expensive than traditional landline communications (see Figure 1). Corporations should be wary of implementing wireless data communications casually or in volume, because it can quickly add up to serious money.

Telecommunications managers who pay the bills for cellular telephone service can appreciate how quickly wireless communications expenses can run up. In addition, many wireless data networks charge by the packet, which can accelerate costs even more.

The Federal Communications Commission's historical philosophy toward spectrum allocation is not consistent with efficient wireless data communications services. For example, spectrum tends to be allocated in channels that represent the spectrum capacity needed to carry human speech--about 25 kHz. The present practical maximum amount of data that can be pushed down such a channel is 19.2 kbps, hardly significant by conventional telecommunications standards.

Even though wireless data seldom achieves this maximum because of these networks' high errors rates, the effective data rate is usually enough to support the kinds of interactive terminal-oriented applications that are in common use today. Moving larger amounts of data, such as file transfers and faxes, tends to happen at speeds characteristic of dial-up telecommunications rather than the rates supported by LANs or backbone landlines. If the objective was to extend existing terminal-oriented applications out to the field using wireless communications, the scarcity of spectrum would prevent enough channels from being available to support a significant population of terminals going on line concurrently.

Another problem is that a single slice of spectrum is usually allocated to several geographically separated users. Various users in Seattle, Dallas and Boston may receive an allocation for the same frequency because their transmissions could not interfere. Most of these frequencies were originally allocated to local-only services, such as public safety and taxi dispatch, and little attempt was made to make coherent and consistent frequency assignments across the nation.

As a result, it is difficult to get a single uniform national channel assignment. Thus, a company may have data radio equipment in one city that won't operate in another city. While today's data radio equipment is usually "frequency agile," and thus able to operate on a broad range of frequencies, this capability doesn't come free--it increases the cost of the already expensive equipment. Moving data over the cellular telephone system and over certain national packet data services, however, provides national service on the same frequency bands.

Hostile Environment

Reliability problems are another surprise waiting to happen. Wireless data is not as reliable or accessible as data moving over wireline telecommunications or LANs. The radio environment has significant signal quality problems compared with copper wire or fiber optic media, and these problems are particularly troublesome for data communications, where small interruptions in the link can corrupt data or even drop the link.

Radio signals attenuate sharply over distance, and signal strength typically falls proportionately to the distance between the sender and receiver. In wireless communications, the sender and/or receiver is often moving, and it is impossible to install signal repeaters or amplifiers between them. As a result, a rapid decrease in signal strength is unavoidable.

This significantly limits the practical distance between sender and receiver. The equipment to increase that range--to detect a weak signal and to amplify and process it to a usable form--becomes more expensive as the desired separation between sender and receiver increases.

The radio environment is much noisier than the telecommunications environment, and a variety of factors make it difficult to distinguish the sender's attenuated radio signal from other radiated spectral energy in the band being used. Some of this noise is natural (like the interference from sun spots), while some comes from artificial sources--e.g., licensed in-band transmitters that are not operating properly and are spilling energy into the signal band.

Interference can also come from the sender's own signal as multiple reflected versions arrive at the receiver's antenna at different times (i.e., multipath effects). The strength and nature of interference is changing constantly, and when it is strong enough to disrupt the ability to distinguish signal from noise, bits of the data stream can become lost. This is especially common when one end of the link is moving. Again, more capable and expensive equipment can overcome some of these problems, but there are limits to what the technology can achieve.

The effects of range and interference, combined with the ever-present limits on available bandwidth, severely constrain the data rates that wireless systems can sustain. Wireless local area networks can support data rates of millions of bits per second, but the rates are still far below those provided by high-speed LANs like FDDI.

Conventional data protocols are not practical in the wireless environment

The difference in data rates is even more pronounced for metropolitan and wide area networks. In a world where wide area telecommunications networks often are designed with T1 as the minimum unit of capacity and new low-cost modems are achieving 56 kbps over dial-up connections, wireless data networks are struggling to deliver 19.2-kbps links to mobile users.

Unfortunately, the practical throughput on wireless networks is usually about half of this "rated" capacity because of the high overhead of signaling and error correction protocols. This will significantly influence the architecture of potential wireless applications. Many companies will find that it is neither feasible nor affordable to extend even terminal-oriented interactive transaction networks out over the wireless environment unchanged, let alone extend native connections to LANs.

As if the wireless data environment did not offer enough challenges for users, it is also not dependable. Those who "rent" airtime--which you will do unless you are one of the elite group that already owns spectrum--cannot assume that a wireless link will be available on demand. Most cellular telephone customers who live in large cities and use their phones during rush hour are already familiar with this phenomenon.

Spectrum is indeed scarce, and there are more people who want to use it than the available bandwidth can support. Even the largest wireless packet data network in this country is reported to hit capacity limits during peak use periods. The lack of dependable availability is likely to worsen as wireless data services become more accessible.

Yet More Data Protocols

Another surprising aspect of wireless data networks is that they use protocols that are entirely different from anything else you have ever seen. Conventional data protocols are not practical in the wireless environment because the bandwidth is too scarce and because normal bit error rates are too severe.

To maximize the bandwidth for user data, wireless protocols cannot afford to use large packet sizes, large packet or frame headers, frequent positive acknowledgments, inefficient error recovery methods (i.e., send the packet again) or other protocol overhead such as address and route broadcasts, or excessive link and session synchronization. Conventional data link and transport protocols--such as SNA, TCP/IP, NetWare, Ethernet and X.25--won't be used because they are spectrally inefficient and inadequate to deal with the error-prone radio environment.

Even modem-based data communications over standard cellular telephone channels increasingly use custom wireless protocols such as MNP-10 and modified versions of V.42bis. While wireless packet data network protocols are unique, most of these networks provide somewhat transparent gateways for the corporate network using conventional protocols such as SNA/SDLC, X.25 or bisync. The connection at the mobile radio modem is somewhat different, however, and often requires the end user device to incorporate some awareness of the wireless network protocol.

Wireless data protocols are newer than their wireline counterparts, and thus, not surprisingly, they tend to be less mature, robust, functional or integrated than their older siblings. For example, network managment functions are generally not supported into the wireless network, let alone across it.

With the exception of the cellular modem protocols, most wireless data protocols are proprietary to the network or equipment vendors. This contrasts with the trend toward "open systems" protocols that are controlled by vendor-independent standards organizations. This level of maturity does not yet exist in the wireless data communications industry. The consortium behind the evolving protocol for the Cellular Digital Packet Data network is dominated by network service providers.

While most of these proprietary protocols have published interfaces, they are still vendor-controlled, and in this regard they are no more "open" than SNA or NetWare. Most users will find the wireless data environment less "open" and more enslaved to the proprietary interests of the vendors than their corporate information networks.

The consequence is that users who are entering the wireless data world will have to learn about a different communications environment with new architectures, capabilities and protocols. While many of the concepts and techniques of classic datacom also will apply to wireless, the transition will be confusing, frustrating and challenging for a while.

The Need for Client/Server

Because wireless data communications is expensive and prone to errors, it is imperative to send the fewest bits possible through the air to perform the application. Looking at it from this context, most companies will conclude that they will not be able to run existing applications just by moving the operator out to the end of a wireless link.

Mainstream corporate transaction applications usually work interactively with operators using terminals. These applications send full screens of data as character streams, and often include additional bytes for screen formatting and other user interface functions. Many interactive terminal applications echo characters back to the screen from the application or resend the entire screen contents just to update one field.

LAN-based applications tend to move even larger volumes of data between the file or application server and the user's workstation. However, the cost of operating applications in a manner that sends a lot of data over the wireless connection quickly becomes prohibitive.

While the use of compression techniques can help reduce these costs, they are only a partial answer. Most companies will need to rewrite existing applications to migrate to a wireless environment. To minimize the data sent over the radio link, the application should send flags, codes and preformatted data rather than English-language character streams.

Applications should send dynamic data to a mobile user workstation that can interpret the coded data and manage the user interface locally with predefined screens. This implies an intelligent workstation for the mobile user, which further implies closely designed cooperation between the central application and the user's interface workstation. If this sounds like a client/server architecture, it is.

The original intent of the client/server architecture was to take advantage of the processing power of increasingly low-cost user workstations to handle local, user-specific processing tasks--e.g., graphical user interfaces, data formatting and editing, and local data manipulation. Under this concept, central application servers can be dedicated to functions that need to be centralized, such as core application and data-base transaction processing.

Adopting this architecture of application-to-application communication between the central server and the user workstation tends to reduce the volume of information that needs to flow between those two systems. A properly designed application can even more effectively minimize the data movement between the client and the server.

Most companies will need to rewrite applications to migrate to wireless

The client/server architecture is ideal for developing spectrally efficient, cost-effective applications for the wireless data environment. While corporations have been conservative and deliberate about adopting the client/server architecture in their existing information systems, the benefits of client/server are much more compelling in the wireless environment.

Looking to the Future

Wireless data applications will benefit many organizations as the need grows to provide large numbers of mobile workers the same automation advantages as office workers. The strong growth of portable computing will only amplify the need to tie mobile workers into the organization's information system.

This new wireless data communications environment presents unique challenges and pitfalls. Because spectrum is scarce, wireless data will never be cheap or easy to use. It will always require that the organization's systems and communications architects design applications and networks specifically for the radio environment.

Implementing applications in the wireless data world is difficult, but things will get better. While most of the companies that serve the wireless data market come from the voice side of the industry, they are getting increasingly sophisticated about computer systems and data communications. The FCC has developed a progressive, open-minded stance toward wireless communication, and it has actively fostered technological innovation and responded to market needs. These initiatives will stimulate revolutionary changes in corporate information systems similar to those that came from the introduction of the personal computer and the local area network.

Published in Business Communications Review, Vol. 23, Issue 4, April 1993.

Where Did These Charges Come From?

Last month we received the following queries from two customers:

Customer #1:  “I know that my devices only send 40 bytes and the portal is reporting they sent anywhere from 397-767 bytes. Where are the extra bytes coming from?”

Customer #2:  “My IIS is reporting that I have sent/received a total of 3,075 bytes, but when I look at the portal it says 6,000 KB. I am trying to figure out where the other 2,925 bytes are coming from.”

Unfortunately, these are typical queries we get from customers who have launched their first wireless application. Their first reaction is that something must be wrong with the carrier’s service or billing system and that they are being improperly charged.

Let me start off stating categorically what we tell customers every time these discussions start:

·         No carrier interjects billable bytes or data into a customer data stream that inflates the billable data volume – the data reported in the management portals. In fact, all of the carrier interactions with the device take place over the control channel (i.e., device registration and authentication, channel assignment and cell site hand-off, packet data protocol (PDP) context session initiation and termination, etc.), are not counted as billable transactions and do not show up in the count of billable data.

·         Carrier billing systems are ruthlessly accurate at counting the data incurred by communicating devices, down to the byte. They do not make mistakes. We have confirmed this numerous times by sniffing the raw packet traffic just outside the carrier’s point-of-presence at their GGSN.

So ALL of this measured data traffic is caused by the device and the central application with which they are usually communicating. But clearly it is more data volume than the customer expected. In fact it is a lot more – the 2x to 20x underestimations in the customer examples above are unfortunately typical. And since carriers charge for all data usage, these underestimations are expensive.

So what is causing the extra data that these applications are being charged for?

I will start by pointing out that carriers charge for every byte that is transmitted over the data channel. All of the carrier’s management functions are conducted over the control channel, so all data traffic flowing over the data channel – whether sent by the device or sent by the central application – is presumed to be caused by the customer application and is considered billable.

Another consideration is that carriers measure data by the “session.” Here the “session” in the wireless world is from when the PDP context is first established until it is closed. Within this PDP context session, data can flow back and forth between the device and the central application in multiple transactions or packets. At the close of the session, the carrier simply measures and reports the total number of bytes sent by the mobile device and the total sent by the central application over the air. Neither carriers nor their MVNOs capture or record any more detail than that, which contributes to the customer’s confusion about what causes session totals.

Yet another consideration is that the carriers charge for all data that is transmitted over the air. They do not guarantee the receipt and processing of data by the destination end point. If an action by an application node causes data to be sent over the wireless channel, it is billable even if it is not correctly “received” by the destination end point address.

So again, what is causing the extra data that these applications are being charged for? There are some principal causes.

Communications Protocol Overhead

A number of novice wireless application developers use TCP as the fundamental transport for their application – because it is what they are used to using in wireline communications, and it is the prevailing communications protocol in an Internet dominated world. Unfortunately, TCP is a relatively chatty protocol that imposes a high amount of data volume overhead on most M2M applications. TCP wraps a significant amount of data around the customer’s payload. TCP packet overhead can include fully qualified destination address, sender address, routing information, error correction checksums, packet sequence numbers, datagram descriptors – the list goes on and on.

In addition, TCP is a chatty protocol that causes a number of messages to be exchanged between the sender and destination in addition to the principal message carrying the customer’s intended payload. These additional messages may include TCP session negotiation and establishment, encryption negotiation, address advertisement and routing negotiation, confirmation of receipt, resend of incorrectly received packets, flow control throttling – this list also goes on and on. With the protocol stack often embedded in the radio module itself, much of this chatty overhead can not be turned off in the configuration of TCP. But even when it is accessible, many novice wireless developers do not do this because it isn’t needed over wireline connections and it “gives up” functionality.

All of the bytes involved in operating these communications protocols and transactions are billable data.

Application Overhead

The application itself can be designed to cause additional billable data traffic that is not directly involved in moving “application data” between the device and the central application. Sometimes these transactions are designed intentionally, and some unwittingly. For example, sometimes the application polls remote devices for the data it wants. Or the remote device sends heartbeats to signal to the application that it is still operational, to keep its PDP context session active, or to communicate its dynamically assigned IP address. The device or central application may be designed to require the receiving node to send an acknowledgement that the message or data was received correctly. All of these actions will generate billable traffic on the wireless network, and if they are being conducted using TCP and its headers, then the data volume can balloon.

Any transmissions which are used to configure or manage the device, or to troubleshoot the application will also cause billable traffic. This will include all commands sent to a remote device to change its configuration, release it to sleep mode, or clear or reset alarms. “Pinging” the device, collecting configuration parameters (e.g., device serial number, firmware version, current settings), or uploading logs will cause billable data traffic. Synchronizing state between the remote device and the central application will also generate additional traffic, as will having the application synchronize the time base with the device. All of these actions will generate data traffic that is measured and billed.

All of the bytes that the application causes to be sent between the device and the central application are billable traffic, not just the bytes that may be displayed in the application or stored in its database.

Communications Errors

Problems with the overall communication system may cause data to be sent over the wireless link that is billable, but which may not reach the destination application. Establishing a PDP context usually means that an end-to-end connection is established at the Layer 3 protocol level before any application communication starts, so this should usually not be an issue. Bugs do occur in customer applications or configurations, however, that do result in network traffic that is invisible to the customer application.

The most common cause of this type of unexpected data volume are defects in the application or device that cause messages to be sent repeatedly and frequently in error. The receiving node is not expecting the messages, or does not even recognize the contents, and so they are not “recorded” at the application. The sender keeps sending because it is not receiving an acknowledgement, because of a corruption of a timer setting, or from some other application defect. But since this bug produces data transmissions over the air, they are all billable.

Other communications errors can be the result of poor wireless application design. For example, a device may be designed to “recover” and restart a communications session if it does not receive an acknowledgement within a timeout period. But the variable latency in the wireless network may have caused a delay in the device registering or establishing the PDP context. The originally submitted data transmission may still be “in process” when the device decides to reset and start over. Any data sent before the PDP context was terminated will still be chargeable, even it is not usable to the destination application.

In marginal coverage, the wireless link may fail and the PDP context may terminate before a transmission that is in process can “complete. “ Any data transmitted before the link dropped would still be billable, even if the partial transmission is unrecognizable and unusable to the destination node.  All retries would also be billable transmissions, and these could add up if the coverage is marginal enough and the connection link cannot stay up long enough to complete a transaction. This phenomenon is fairly uncommon, but it can cause a significant volume of traffic if the application is designed to just keep trying. It is worth noting that marginal coverage, or even lack of coverage, is not a “bug” of wireless networks. These networks do not guarantee any coverage, and they only provide service on a “best efforts” basis.

All data sent over the wireless channel is billable, whether a transaction or session completed normally from the standpoint of the application.

Rounding

Another potential reason for the difference between what a user thinks they are sending, and the data volume for which they are billed, is rounding. Rounding is a practice followed by some carriers in which they “round up” the measured data traffic in a session to an even amount for billing purposes. Usually the measured data traffic in a session is rounded up to the next whole kilobyte, although some international carriers round up to the nearest 10 kilobytes. Rounding can undermine the efforts of diligent application developers who are selective about the data they send, send it in a compressed binary form, and use a low overhead protocol (such as UDP). Rounding can have a significant impact on the billable data volume when very small amounts of data are sent during a session, but its impact is less noticeable in applications that send higher data volumes.

Rounding usually shows up in the invoice or even the summary list of sessions. Most carrier portals provide the underlying real byte count of data sent to and from a remote device, so the effect of rounding can be identified.

Summary

The portal traffic statistics do not lie. What it reports is the actual billable traffic that the application is loading on the wireless network.

Analysis of the communications link is necessary to find the specific root cause of the unexpected data volume. The best way to diagnose these communications issues is to run a protocol “sniffer” on the communications feed from the carrier before it reaches the destination node. For some communications problems, data communications analysis may even need to be done in front of the firewall. Instrumenting the device and the central application to capture communications traffic and facilitate diagnostics is also usually helpful.

The bottom line in this type of situation is this:

The application developer’s surprise about the difference between the payload size and the chargeable data volume only indicates that they do not understand some fundamental principles about how their application works, how data communications protocols work, and how the cellular communications network works.

How M2M Cellular Modules Evolve

M2M applications use mobile radios that are built from the components originally designed to serve the cellular telephone industry. Although the functional requirements of M2M applications are relatively modest, it is less expensive just to use the full function, telephony-oriented components whose costs have been driven down by the volume of telephone handsets.  M2M-oriented embedded modules are built from these general cellular components. These modules are designed to fit the specific needs of M2M applications, including manufacturability, form factor, power requirements, and data inputs and outputs.

The technology underlying the cellular telephone network has been evolving over the years as carriers have sought to support more users on their limited spectrum, and to provide more functionality in their phones. Originally based on an analog architecture, cellular networks next evolved to a more efficient digital foundation. The digital signaling technology of cellular networks then evolved to ever more efficient and functional versions. The data communications services of GSM digital cellular networks, for instance, started with a technology called GPRS, which has evolved through fundamental redesigns to newer and better versions, typically called 2G, then 3G, and now 4G. M2M applications, and the radio modules that they embed in their devices, also continue to evolve along these lines with the technology in the underlying cellular networks.

We now have enough history of M2M module development that we can describe the evolution path that modules will follow in these technology versions. The market has seen GPRS modules become widespread. Subsequently 2G modules have also evolved to relatively low prices and broad use.  3G modules -- and now 4G modules -- are making their appearance in the M2M market, and we can see that they are evolving through the same orderly pattern as the earlier technologies, GPRS and 2G.

First of all, M2M modules tend to lag behind the state of the art in cellular technology because M2M performance needs are so modest and because M2M applications are highly sensitive to device costs. 2G M2M modules appeared only after the technology had been pioneered in the cellular handset part of the industry, and 2G M2M modules reached wide adoption years after 2G cellular phones became the dominant handset technology. The enabling components for a new technology like 2G are used by the cellular handset industry first as carriers leverage the greater functionality and spectrum efficiency of the technology in the large mobile telephony market. A technology like 2G is incorporated into M2M modules only later after the telephony market has driven costs down enough to match the price sensitive requirements of M2M applications.

Secondly, modules of a given technology stage are relatively expensive when they first appear, and their price declines over time as they mature. Even though modules mainly use the components of cellular telephones and enjoy the scale economies of that much larger market, there is enough unique about M2M module design and manufacturing that they follow their own price curve. But there is definitely a price curve. 2G modules today are less expensive than 3G modules, which in turn are less expensive that the few 4G/LTE modules that are available. As the overall M2M market has grown, it has enabled M2M modules to reach ever lower price points. Today, 2G modules are less expensive than the earlier GPRS modules ever were. Over time, 3G and 4G modules should come down in price as the previous generations of M2M modules have done.

Third, even as their prices decline, M2M modules offer more functionality over time. This occurs in a consistent pattern as well. When a new generation of M2M modules first appears, it is essentially a bare radio that complies with the new wireless technology. There is very little other functionality in the module. Incorporating this radio module into a working device requires that a co-processor be used alongside the radio module to handle a number of communications functions. The co-processor has to implement higher level protocol functions (such as TCP/IP), control registration and re-registration processes, handle store-and-forward, provide power management of the radio module, and multiplex the different device inputs and outputs with the radio module.

Over time the price of the new generation module goes down, but its functionality also increases. No longer just a bare radio, the module incorporates the TCP/IP protocol stack. It also handles power management and the higher level communications functions that used to be performed by a co-processor. At this stage, a device processor is still required to multiplex I/O and some other functions, as well as to support the overall application logic of running the device itself.

When a module reaches the full maturity of its technology stage, it provides enough capability that an additional processor can often be eliminated from the device, thereby reducing the overall device cost. In additional to all the cellular communication functions, these modules are a complete M2M System on Chip (SoC). They provide a user programmable processor with memory, resources for program and data storage, and several integral I/O ports. They also frequently incorporate value-added functions like battery management, GPS processing, integral temperature sensors and accelerometers, and other functions. 2G modules are now becoming available with this high level of functionality that enables ever more cost effective M2M devices to be built.

M2M modules evolve over time in a predictable pattern. M2M modules in a new cellular technology appear well after that technology has been added to the cellular infrastructure and deployed in handsets. The prices of these M2M modules start relatively high, significantly higher than modules using older technology, and then decline over time as improved versions are introduced and volume grows. Those improved versions also expand the functionality of modules within the technology, from the bare radios that are initially introduced to full M2M systems-on-chips. GPRS and 2G modules have run through this full life cycle, and 3G modules are in the middle of this progression. 4G or LTE modules for M2M applications are only starting to appear, so they face many years of evolution before they are cost effective and widely adopted.

The Dysfunctional Evolution of Wireless Applications

At the current embryonic state of the M2M industry, most wireless M2M applications are new. Many of these new M2M applications are actually existing applications that are being converted to communicate over wireless cellular connections. And even many M2M applications that are being newly developed for a wireless environment are being developed by engineers who are working on their first wireless application. Because wireless data communications is a different and uniquely challenging environment, most of these applications will take more time and effort to get working than originally projected. Many of the problems that engineers run into are architectural and fundamental, which ends up requiring an extensive redesign and rewrite of the application, or abandoning the project outright.

Why do M2M applications, and the engineers that develop them, get into this predicament? Some of the blame comes from the nature of the development process itself. Let me explain how this usually happens.

Fundamentally, most M2M applications are variants of client-server applications. A central server-based application communicates with remote devices that function as clients of the central application. The central application usually gathers data from the clients. Sometimes the central application sends commands to the clients, and sometimes the clients query data from the central application. Most M2M applications are fundamentally client-server in their architecture.

Client-server applications have been successfully architected and implemented for decades. The fundamental approaches are broadly known and practiced, and the development process is as well. And this is at the root of problems with M2M application development. Engineers who develop an M2M application like they do traditional client-server applications are prone to make architectural design decisions that, in a wireless environment, make the application perform poorly, expensive to operate, or simply unable to function.

When engineers start developing a client-server application, the application is usually initially prototyped in the lab. The server application is prototyped on a dedicated PC, and the client component of the application is simulated on a separate, dedicated PC. Usually the two PCs are connected using a direct serial connection to “simulate” the network. Sometimes the client application is actually compiled or ported to run on an actual client device, but at this stage it still communicates with the server over a direct serial connection. The basic functions of the server and the clients are implemented in this prototype, as well as the overall approach to how the server and clients will communicate with each other.

As the development of the client-server application proceeds, the functionality of the client and server components expands to meet the overall application requirements. The connection between the client and server is usually upgraded to running over a local TCP/IP-based network. The application is enhanced to deal with the aspects of communicating across a network, including dealing with multiple concurrent clients, dealing with network addressing, handling flow control, and interfacing to an underlying communications protocol stack. The fundamental architecture set in the bench prototype usually remains unchanged, however.

In the next stage, the client-server application is deployed to operate in the “field” over the public Internet. The communications capabilities of the clients are expanded to deal with static or dynamic address assignment, firewalls and routers, loss of Internet connectivity, and the slightly higher latency that can occur across the public Internet. Server applications are also enhanced to handle dynamic client addresses, the impact of firewalls at both the server and the client, and the expectation of dealing with even more concurrent clients. The fundamental architecture from the bench prototype still remains unchanged.

At this point, the communications architecture of the client-server application is pretty much set in concrete. The data model of the information being exchanged between client and server is fixed. The messaging structure and data flows between the client and server – both the messaging sequences and the message contents – are similarly embedded in the code. The application may be structured around assumptions of timing and latency, outage duration, communications bandwidth, and underlying protocol support that have been valid and worked fine over the networks on which the application has been developed so far. Circuitry has been designed, and software has been developed, tested, modified and refined.

Whether the application was intended to operate in a wireless environment from the start, or is being converted to operate wirelessly after successfully operating over wireline communications, an application developed in this sequence invariably faces serious problems when it attempts to use a wireless communications network. The developer assumes that since they are using a TCP/IP communications stack on both the server and remote client side, that they are isolated from vagaries in the underlying physical network. But many of the assumptions made about the underlying communications transport are completely invalid in a wireless network. By this point in development, however, those assumptions are deeply embedded in the application architecture and implemented in the code.

When this application is now deployed to operate over a wireless network, its performance can differ widely from what is desired or expected. The cost of usage-based charges over the wireless network is usually surprisingly high. The application will regularly experience higher latencies and prolonged loss of communications, which it may or may not handle gracefully. Communications may not be established between the remote devices and the server for reasons that are unfathomable to the developer, because a cell phone works fine in the same location. Very often, these issues are a result of the application design.

For a client-server application that was designed for a wireline transport, fixing it to work well over wireless is never easy. Making a few tweaks to try to get the application to work acceptably is almost never successful. By this stage, significant structural changes are often needed to get the application to work over a cellular transport. Sometimes the scope of those changes is so great that it would be easier to just rewrite the application. Unfortunately the same application developer whose unfamiliarity with wireless got things into this situation often does not immediately comprehend how significant the required design changes are. Not until a few fix attempts are unsuccessful does it become clearer to the developer how much the application needs to be fundamentally changed to work over a wireless transport. Now the project schedule and budget are truly blown.

Following the traditional approach of prototyping and developing client-server applications in a wireline environment, and using design practices that can be made to work over those connections, often leads novice wireless developers to develop applications that really can not work over cellular connections. Someday a large number of application developers will have experience in this environment and will avoid those mistakes. Unfortunately, we are not close to that point today.

Wireless Is Different: Advice For Application Developers

The number of applications being created to operate over wireless networks is growing tremendously. Whether writing consumer applications for smartphones, mobile business applications for portable computers, or M2M applications for remote devices, more software engineers are developing applications for this exciting environment. The field is new, however, so most of these engineers have no prior experience in designing applications that communicate over wireless networks. This will get them and their projects into trouble unless they carefully research how these communications networks operate, and understand how they will have to structure their applications to accommodate its unique characteristics.

Most software engineers who develop communicating applications learned their trade by designing applications to communicate over wireline TCP/IP networks. They have learned a set of architectural principles, design guidelines, algorithmic shortcuts, and communications practices appropriate to that communications environment. When they start to work on wireless applications, however, it will come as a shock to many of them that those principles and practices are simply wrong and will not work in the new environment.

In this discussion I am primarily focusing on applications that are designed to communicate across the worldwide public cellular telephone network. Many of my comments and observations will also apply to other wireless networks, including satellite networks, private radio WAN networks, wireless sensor networks, and proprietary unlicensed wireless networks.

Part of the confusion for new wireless developers comes because the cellular network supports TCP/IP communications interfaces on both ends – at the mobile device and at the cellular network point-of-presence accessed over landlines by a central server. Application developers are accustomed to TCP/IP providing a standard set of communications services and a dependable quality of service across a network connection, and abstracting the differences of the underlying physical networks from the developer’s concerns. While TCP/IP connections and sessions are indeed supported across the cellular network, that communication operates differently over wireless connections in some very important ways.

The rest of this discussion will review some of the important differences of wireless networks, how those differences impact TCP/IP-based communications, and the implications for applications designed for this environment.

Usage-Based Charges

In a wireline communications environment there is a fixed cost for the communications service (or at least a fixed monthly charge), and then applications can communicate across the connection as much as the contracted bandwidth will allow – which nowadays is usually a lot.

Wireless networks, on the other hand, charge based on usage – on how much data is transmitted across the network. In fact, cellular charges a lot more than wireline services for equivalent data volume – from 100 to 1,000 times more than wireline connections. Not only is cellular much more expensive for raw, bulk data transmission, but it is even more expensive for transactional usage. Cellular networks charge not only for the payload – the data the application is sending – but they also charge for all of the protocol. That includes headers, error checking bits, acknowledgements, handshaking and session negotiations, and so on. On top of that, some cellular networks take the data volume transmitted during a session and round it up to the nearest 1,000 bytes  or so when the session ends.

Using TCP/IP in a network with usage-based charges clearly incurs some significant costs. TCP/IP is a relatively “chatty” protocol, which is necessary for it to provide the flexibility, reliability and physical network abstraction that developers like so much. The protocol incurs chargeable communications overhead on several dimensions. All of its address advertisement and discovery, route discovery, and network registration transactions are chargeable. All of its session negotiation and establishment, flow control, delivery guarantee and error recovery transactions are chargeable. All of its extended services header information, worldwide addressing, source routing, error detection and other overhead bits are chargeable. Those costs are incurred before the first bit of useful application payload is conveyed.

Beyond the real cost of using TCP/IP, developers used to wireline networks often make their applications “chatty” as well. They send heartbeat and status messages when there is nothing noteworthy to report. When applications do send information, they send a whole block of data, most of which has not changed from the last time or otherwise has limited information content. Applications send text strings when a bit or two would convey as much information to a computer. Developers have applications send diagnostic information continually “just in case” they need to check the logs on a problem. Even worse, developers architect applications so that constant communications is necessary for it to work – to synchronize application state, to synchronize time, to get information by polling rather than send on events, etc. All of these application design decisions, which are done for the convenience of the developer and incur no costs over a wireline network, generate significant unnecessary usage charges over a cellular network.

Limited Bandwidth and Latency

Most wireline TCP/IP connections today are “broadband” connections that provide high bandwidth and low latency. The bandwidth available over wireline connections has grown significantly over the previous decade. As a result, developers have evolved their applications to use more graphics and animation, rich user interfaces, dynamically downloaded applets and plugins, XML-based protocols, and other bandwidth consuming techniques that improve functionality and usability. Developers have also written their applications to be highly interactive, to load or preload relatively large datasets, and to expect relatively short timeouts in managing communications.

On the other hand, wireless networks are significantly bandwidth constrained. Most wireless connections will only operate at data rates two to three orders of magnitude slower than the common wireline connections available today (i.e., only 1/100^th to 1/1000^th of the wireline data rate). Some networks offer faster channels or connections that approach low end wireline connections, but most M2M applications can not afford the premium charges and higher cost hardware these channels require. In any case, most wireless connections degrade the channel data rate when the remote device is in marginal coverage to even lower throughput than the ideal case.

Relative to their wireline counterparts, wireless networks also introduce higher latency in their connections. The higher latency doesn’t just come from the lower throughput of the communications channel, but also from delays introduced by cellular network elements and signaling in the underlying wireless physical network. In particular, there can be pronounced delays when a device needs to register on a new network (such as after repowering or resetting), when it changes the serving cell site, and when it seeks to establish a new session. Latency is also a symptom when a device is in marginal coverage and has difficulty maintaining the basic wireless connection with the network infrastructure.

Most application developers are not used to developing applications for such bandwidth constrained communications links, or for connections with variable and generally high latencies in interactive transactions. Developers may need to rethink the data flow designs in their applications to accommodate these relatively extreme constraints of wireless networks. Failing to take these factors into account may result in an application that does not work reliably, or which can not establish or maintain a connection at all.

Intermittent Sessions

In many TCP/IP-based applications, the application establishes a session or socket connection between the two ends of the application (i.e., usually server and client), and leaves that connection in place as long as the application is up, even when nothing is being communicated. In a wireline environment there is no “cost” to maintaining a session, and keeping the session active can reduce latency. With an active session, either the client or the server can initiate a short message with minimum delay and processing overhead. It is a little more programming work and processing overhead to initiate a session every time the client or server needs to communicate with its counterpart – and to promptly terminate that session when the transaction is finished.

Cellular networks do not allow sessions to be maintained for any significant period of time, particularly if they are quiescent. To minimize the non-productive consumption of their network resources – including the servers that keep track of active sessions – cellular carriers allow sessions to continue up to a threshold time, and then the carrier interjects and takes down the session. This kind of network intervention to terminate sessions is virtually unknown in the wireline Internet. In addition, some cellular networks will not tolerate devices that do not handle session management in a carrier-specific, wireless aware manner, and carriers may not provide service to devices that exhibit poor behavior.

A developer who has not designed his application to presume that sessions are not established – and that sessions must be set up before every transaction and taken down afterwards – may find the application performs poorly over a wireless network. Latency over wireless networks is already long, and waiting for a communications attempt to time out before beginning to reestablish a session only magnifies that.

Intermittent Connections

Once a device is connected to the wireline Internet, the developer and the application can rely on the communications facilities being available on demand. When the application needs to send data, it can just hand the data and destination address to the TCP/IP protocol stack and rely on it to perform the communications function across the network immediately. Timeouts and retries are often used to address the rare situation when the underlying communications service is unavailable.

With wireless communications, however, it is common for the network to be unavailable to carry communications. With mobile devices, it is almost guaranteed that they will be out of range of the cellular system at some time. Intermittent communications even occurs for stationary devices since other relevant objects are moving – obstacles, interferers, and reflecting surfaces that create multi-path self-interference.

The TCP/IP protocol stack provides limited facilities to deal with the frequency and length of communication interruptions that commonly occur with wireless networks. It is incumbent on the application developer to build many of these facilities into the application. The mobile application has to determine whether the network is available by making direct status queries to the cellular radio, and the server application needs to query the cellular network directly to determine whether the mobile is registered and active. Messages that can not be delivered need to be stored locally – sometimes a very large number for a relatively long time – so that they can be forwarded on to their destination once wireless communications is established. The local application needs to be able to continue performing its basic functions without relying on communications to the remote component. It is difficult for a client/server application to function robustly if it does not implement some of the basic communications protocol functions needed to deal with the intermittent connections of the wireless network.

Dynamic IP Addressing

The Internet is a marvelous communications network in that generally any node on the Internet can connect to and communicate with any other node on the Internet, anywhere in the world. There is only one, unified address space for all Internet connected devices around the globe. All the initiating node needs to know is the IP address of the destination node in order to connect to it, and there is a worldwide network of directory servers to help initiators find the route to their destination node addresses.

Most mobile devices are assigned an IP address by the carrier for them to use for communicating over the Internet. Because the cellular industry paradigm is that mobile devices are subscriber devices and the subscriber initiates all communications, and because the cellular industry has needed to ration the IP address ranges that they have been allocated, the IP addresses are assigned temporarily or “dynamically” whenever the mobile device needs to communicate. When the mobile device is not actively communicating across an established session, then its temporarily assigned address is recovered and reused by the cellular network. Most of the time, a mobile device does not have an address assigned, and it can not be reached by a server application, even when the device is within cellular coverage.

Many cellular carriers do provide an option to assign a permanent, full-time IP address to a mobile device, which is called a “static” IP address. An external or server-based application can initiate a communications session with such a mobile device at any time, as long as it is within cellular coverage. The number of IP addresses available to carriers is still limited, however, and they charge extra for static IP addresses – sometimes significantly more.

Over cellular networks, applications can also always initiate communications with a mobile device using the Short Messaging Service (SMS) used for text messages, but this facility is extremely payload limited and entirely out-of-band from the familiar TCP/IP communications service.

A number of remote monitoring and control applications are architected under the assumption that the server is the “master” in the operation of the system, and that the central application controls communication to and from remote devices. This architecture is incompatible with a standard cellular service with dynamically assigned IP addresses for the mobile devices. Wireless applications need to be structured so that the mobile device initiates communications, either on schedule or on event. Even configuration commands and software updates for a device need to be held by a server application in a pending state until the target mobile device initiates a communications session with the server. Or the system needs to be designed so that server applications can send an SMS message to a mobile device to request it to initiate such a TCP/IP session on demand (the so-called “shoulder tap” method to get the mobile device’s attention).

Addressing Complexity

As stated previously, the Internet provides a wonderful facility of a single, unified address space that any Internet-connected node can use to communicate with any other Internet-connected node. Whether using IPv4 or IPv6, there is a one-to-one match between any physical device and its Internet address. Beneath its virtual IP address, every device also has a unique MAC address that is burned into its communications hardware, to further guarantee the unique identity of each connected physical device. The Internet infrastructure takes care of associating the virtual IP address with the physical MAC address. Everything is simple and harmonized.

In the cellular world, it really isn’t quite so simple. The cellular networks “support” IP-based communications, but they do not use IP addressing as the actual basis for communication like the Internet does (at least, not until true 4G networks become the predominant cellular network). IP addressing is actually overlaid on an entirely different cellular-based addressing universe. Rather than a MAC address, a cellular device has an International Mobile Equipment Identifier (IMEI). Devices that operate on GSM technology networks also require a separate Subscriber Identity Module (SIM), which in turn has its own unique International Mobile Subscriber Identity (IMSI) number. On top of these hard-coded physical addresses, cellular devices also have their own virtual address that is used for authentication and routing, the Mobile Subscriber Integrated Services Digital Network (MSISDN) number.

Mobile applications only need to use the virtual addressing of the Internet, the IP address, for mobile devices and central, server-based applications to communicate. However, most device and network management functions associated with the application will need to use cellular-specific addressing. Adding a new device to the application requires provisioning instructions to the cellular network, which can only be performed using the native addressing of the wireless industry. Similarly, most communication diagnostics must use cellular addressing rather than Internet addressing. Developing and deploying an application that communicates over the cellular wireless network will require use of the separate and extended addressing native to the wireless industry.

Multiple Carriers and Roaming

As stated earlier, the Internet is a marvelous communications network because any node on the Internet can connect to and communicate with any other node on the Internet, anywhere in the world. This communication is not dependent on knowing or dealing with the Internet Service Provider (ISP) of the other node. A node that connects to the Internet only needs to have commercial relationship with its own ISP. Once it has done so, the node can communicate with any other node that is obtaining service from any other ISP, because all ISPs provide reciprocal services and access to each other. An application on one node only needs to know the IP address of another node in order to communicate with it.

Once again, things are not so straightforward and simple with cellular wireless communications. Communicating with a mobile device is only “seemless” like the Internet if the device stays within the coverage area of the wireless carrier on whom the device is activated. But carrier licenses are limited to a single country, and no one carrier covers all of the geographic area in any particular country (especially the United States). In order to provide nearly ubiquitous service to subscribers, cellular carriers provide a form of reciprocal service to each other termed “roaming,” in which a device that has a commercial relationship with one carrier (the “home” carrier)  is allowed to operate on the network of another carrier (the “serving” carrier). The catch is that cellular carriers charge roaming fees for this reciprocal service privilege, and often these roaming are significantly higher than the normal usage-based charges imposed by the home carrier. Roaming enables a wireless application to be deployed using devices almost anywhere in the world, but there is a significant cost for that coverage, simplicity and flexibility.

Designing and deploying an application that communicates with devices in multiple countries always involves some complexity. When communicating over the wireline Internet, devices usually piggy-back on existing Internet connections, essentially for free. If that is not possible, local Internet service has to be established with an ISP that serves that market. Using the inter-carrier roaming relationships available with wireless applications can greatly simplify the worldwide deployment of an application. But the usually steep nature of roaming charges places an even greater incentive to design the application to minimize usage-based charges. Good design principles for wireless applications are more imperative when devices are expected to operate across national and even carrier boundaries.

Summary

Software engineers use a set of architectural and design principles to develop successful multi-node, client/server applications. Designing an application that is going to communicate over a wireless network, instead of a wireline one, adds a significant new set of considerations and constraints that the engineer must take into account. Developing a successful wireless application can not succeed just with “tweaks” or small modifications to traditional design practices. The entire application architecture must usually be rethought to produce an effective, commercially viable application.

Moving To Condition-Based Maintenance (CBM)

The Evolution of Maintenance

One of the major tenants of Reliability Centered Maintenance (RCM) is that enterprises should apply maintenance strategies to assets depending on the asset’s importance to the enterprise’s mission and its inherent reliability. Maintenance strategies have evolved over time as organizations have sought to assure high asset reliability and availability with a reasonable maintenance investment. A major challenge for any maintenance organization is to apply the appropriate maintenance strategy to each individual asset so that the organization’s overall goals and objectives can be attained at minimal cost.

First -- “Run-to-failure”. The most basic maintenance strategy available is “run to failure” in which an asset is operated until it fails or breaks. Then it is repaired with reactive or corrective maintenance which may involve repair or replacement. This is still an appropriate maintenance strategy for many non-critical assets.

Second -- “Preventive”. However, some asset failures have expensive and far-reaching consequences. These failures can shut down entire production lines, make buildings unusable, or even cause injuries or fatalities. Organizations place an imperative on avoiding these types of failures. Thus, a different maintenance strategy evolved to accomplish the objective of avoiding asset failures – preventive maintenance. The idea of preventive maintenance is look at the failure history of an asset, and to conduct maintenance to “fix” it before there is a meaningful probability of its failing in the first place. In this manner, a preventive maintenance strategy prevents an asset from failing.

Because the preventive maintenance program for each asset is different and all preventive maintenance needs to be performed on an exact schedule to be effective, Computerized Maintenance Management Systems (CMMS) were developed to help manage this complexity. Preventive maintenance is a core activity of many maintenance organizations today, and it does keep assets operating reliability and performing well.

Preventive maintenance works because it delivers high asset availability and minimizes unscheduled downtime. For those assets critical to operations, preventive maintenance avoids the severe consequences that asset failure can cause.

Unfortunately, the benefits of preventive maintenance come at a price. By its very nature, preventive maintenance means that maintenance is being performed more often than is necessary. Since maintenance consumes both labor and parts, this strategy has a measureable cost of “over-maintenance.” Additionally, preventive maintenance often requires that assets be taken off-line during servicing, incurring a cost to the organization for this downtime and lost capacity. Finally, more frequent maintenance involves more frequent intrusions into the equipment, which itself increases the chance of asset or system failures.

Finally, “Condition-based Maintenance”. Because preventive maintenance is expensive, and because enterprises are increasingly pressured to reduce their costs, organizations are developing a new type of maintenance strategy. Under this strategy, the condition of the asset is monitored regularly until it begins to give evidence of deteriorating performance or incipient failure. Maintenance is then performed “just-in-time” to prevent asset failure.
The promise of this new strategy – predictive maintenance or condition-based maintenance – is that the overall costs of maintenance can be reduced while providing the high asset availability and performance that preventive maintenance delivers. The current wave of innovation in asset maintenance today is developing predictive or condition-based maintenance strategies.

Condition-Based Maintenance Is Growing

Condition-based or predictive maintenance can help lower maintenance costs even compared to a sophisticated preventive maintenance approach. Condition-based maintenance uses real-time information on asset conditions to identify when maintenance is necessary, allowing maintenance to be deferred until needed. Savings comes not just from consuming less labor and parts in maintenance, but also from incurring less downtime and creating less frequent infant mortality.

There is an important but poorly defined difference between predictive maintenance and condition-based maintenance. Predictive maintenance is generally triggered by analysis of equipment condition data that is gathered periodically and manually. Most equipment vibration analysis and lubrication analysis, for example, is conducted on a scheduled basis to identify deteriorating conditions that require maintenance. This contrasts with condition-based maintenance in which equipment condition data is collected continuously and analyzed in real-time. Condition-based maintenance is still a relatively new approach, but is used more frequently on critical equipment in process industries such as refineries and power plants.

There are a number of factors that have limited the adoption of condition-based maintenance besides the fact that it is a relatively new strategy. Most of the equipment that could be subject to condition-based maintenance is not currently instrumented. Data on equipment condition cannot be collected without installing sensors on the equipment along with a means of collecting the sensor data. Even when equipment is properly instrumented to track operating parameters that could identify incipient failure, the sensors are not connected into a data collection network that allows real-time monitoring. These instruments or sensors usually provide local displays or store readings in data loggers, and data is collected from them by technicians that visit the equipment periodically. Such manual data collection is expensive, subject to error, and not always timely.

Even when equipment is instrumented and connected to a central monitoring point, this is often not sufficient for adopting condition-based maintenance. Usually equipment is monitored in this manner as part of a production, process or building control system. These automation systems track equipment and process parameters that are needed to monitor and control the equipment. These parameters are usually not the ones that monitor potential equipment failure modes and that identify a need for maintenance. For a pump driven by an electric motor, for instance, an automation system will usually track flow rates, upstream and downstream pressures, and motor RPMs. Condition-based maintenance would instead require monitoring bearing temperatures, vibration signatures, and motor current draw. Most automation systems do not track the necessary parameters for implementing condition-based maintenance.

Enabling Condition-Based Maintenance

The prospects for condition-based maintenance are improving rapidly, however. Condition-based maintenance is being enabled by several advances, but especially by advances in networking technology. Many business processes and employees have become much more productive and efficient over the last decade as they have become connected to information resources and each other by the spread of the Internet and related networking technologies. While people have become connected, machines and other assets have not yet been brought into networks.

But that is changing as the pervasive Internet is branching out to connect a wide range of equipment and devices. Because the cost of retrofitting wire to connect these devices is prohibitively expensive, wireless technologies are the growing method for making these connections. In particular, wireless sensor networks are a new technology that is connecting machines and other devices in a broad range of applications. This phenomenon is becoming a significant enabler of condition-based maintenance.

Wireless sensor networking is a relatively new technology that is designed to connect machines through the Internet the same way that WiFi has been broadly adopted to connect laptops and other computing devices. Aleier’s sister company, Cirronet, makes a wide range of wireless sensor networking equipment that differs in communication range, sensor connections, battery life and prices to address the requirements of many applications. This capability is becoming more broadly available as Cirronet and the other companies that provide wireless sensor networking solutions continue to refine and reduce the costs of their products.

Implementing Condition-Based Maintenance

Computerized Maintenance Management Systems, or CMMS’s, are the well-established application tool that has been used to plan and manage the maintenance function in organizations of all sizes. Over the past decade, Enterprise Asset Management (EAM) systems have been built on this maintenance foundation to help organizations manage all of the operational activities of managing assets over their complete life cycle, from their design, procurement and commissioning all the way through their retirement and disposal.

Enterprise Asset Management applications deliver a number of benefits to an organization when they are fully utilized. Of course, they help lower maintenance costs by making maintenance personnel and the parts inventory more productive. But they also help enterprises to improve the availability and performance of those assets, and to better achieve the primary mission those assets are intended to perform.

An Enterprise Asset Management application also helps reduce the need for asset investment in the long run. One of the ways that an EAM helps minimize long-term asset investment and improve maintenance productivity is by enabling enterprises to implement the correct maintenance strategy for each asset. The EAM system assists organizations in deciding which assets deserve the investment in condition-based maintenance; require the attention of preventive maintenance, and those that should be operated as “run to failure.” The EAM then implements and manages the appropriate strategy for each asset, including condition-based maintenance.

The Aleier FM1j Enterprise Asset Management application includes condition-based maintenance capabilities. FM1j collects and stores equipment condition data, regardless of how that data is captured. The system then analyzes the data as it is received, using an appropriate predictive algorithm or rule, to identify when the equipment requires maintenance. Finally FM1j creates an appropriate response, which usually means creating a workorder to perform the desired maintenance activity on the equipment.

A rule, or a set of rules, defines the triggers that determine a need for condition-based maintenance. Rules can be simple or complex, depending on the failure modes of the equipment. They can include exceeding a threshold value, exceeding that threshold for an extended time, exhibiting an excessive rate of change in a reading, reaching an excessive difference between the readings of two sensors, and so on. FM1j also allows a range of responses to be pre-defined, including sending alerts or automatically turning off equipment in addition to generating a traditional maintenance workorder. Aleier’s EAM has a rich set of capabilities to help organizations implement condition-based maintenance strategies across a broad spectrum of equipment.

The Future of Asset Management

Enterprises now have more options to assure the availability and continued performance of their assets while minimizing the costs to keep them in service. These organizations can choose the appropriate maintenance strategy for each asset, depending on how critical it is to operations, how frequently it fails, and its ability to be automatically and continuously monitored. New technologies are enabling enterprises to improve the management of their assets, including the ability to employ condition-based maintenance on more of their equipment. New technologies are a primary enabler of condition-based maintenance, which is the latest major innovation in the area of asset management.