Companies are constantly looking for ways to monitor and track their remote assets. They also need to understand the environments in which their devices reside. But why? The traditional method for remote device management is to send technicians to the installation sites to gather information. Here we take a modern view of remote device management and how this leads to an effective method of remote device management known as Drop-in Networking. Joel K. Young
IN BUSINESS, in order increase efficiency you must be able to identify the areas of inefficiency. Translated to the world of remote device management, the goal is to measure and control remote devices by enabling communication with a back-end application, thereby enabling new revenue sources and/or increasing efficiency.
Sounds easy. If the device is intelligent and networked, it is easy in general terms. However, if the device is something that is not easily connected because access to a network is not available, it doesn't generally matter how intelligent is the device or the application. The data isn't accessible from a central location.
What is a Drop-In Network?
So what does this mean in the world of industrial and commercial things? Advancements in wireless technology have caused the wired paradigm to fade. We can't always rely on the human presence to adjust for the number of bars or to initiate a new call. A Drop-in Network enables end-to-end wireless access to electronic devices in isolated, hard-to-reach locations to deliver smarter service solutions. This concept includes both hardware devices and software tools that allow customers to 'drop-in' customised wireless networks for monitoring and control applications across a broad range of vertical markets.
Key features of a Drop-in Network would typically include non-intrusive wireless media with power optimised operation. This usually means battery powered sleeping nodes brought back to life as needed.
Figure 1 illustrates the components of a Drop-in Network which generally includes a device connectivity component through a personal area network (PAN) and/or local area network (LAN) back to a programmable gateway aggregation point. Information is then sent over a WAN to a remote application.
Note that the goal of the PAN/LAN is to relay data between the devices and the on-site aggregation point. The gateway is used to move data from a low-level device view to a Web services based framework using conventional Web programming languages like Python.
Fig. 1. Components of a Drop-in Network
Creating the network
Creating a Drop-In network requires these guiding principles. To start with, define how the application should work. It is important to assess the end-to-end functionality, level of service, location of intelligence and level of security.
The question of functionality usually relates to whether the application is for logging, control, alarming or all of them. Level of service involves whether the data is mission-critical or best attempt. This helps to determine where intelligence should be placed. As a general rule mission-critical communication almost always requires intelligence at the end-device. Security should then be overlayed on top by evaluating the access and eavesdropping perspective.
Then choose the most effective connectivity technology. What's already in place? Evaluate what already exists. This includes whether there are any opportunities to use existing cabled communications and local power as well as the availability of wireless infrastructure like Wi- Fi and cellular signal strength.
Next assess the best ways to fill in the gaps. With the application needs determined and the available infrastructure evaluated, it is time to complete the puzzle. This now involves doing an environmental assessment, site survey and cost trade-offs for different deployment options. It is important to note here that choosing the wrong wireless connectivity will make the solution more expensive and harder to manage. Hence, you must understand data flow, latency needs, reliability needs, range, scalability and power availability.
Having assessed the environment, which technologies should you use? The following offers a few tips for WAN and PAN environments. For the WAN, the obvious first step is to check on access to a wired internet connection via Ethernet. Assuming that is not available, then the next best step is verifying if a WiFi connection is available for use. The good news is that typical WiFi connections, if available, are already connected out to the internet, solving the access problem. If WiFi is available for use, but out of range or poor signal quality, you can still use it with the addition of a range extender.
Of course, if WiFi and Ethernet are both unavailable, the next option would be cellular data transfer. The choice of a cellular technology is driven by three criteria: bandwidth requirement, available networks and cost, all of which tend to be closely related with a dependency on each other. With respect to bandwidth, practical choices are 2G/2.5G (GPRS/EDGE) and 3G/3.5G (UMTS/HSPA) which boils down to the question as to whether the application can get by with dial-up level bandwidth, i.e., less than 115Kbps or slower. If you can tolerate 2G/2.5G, you will be better off from cost and availability. Service availability and cost are next evaluated - if many networks are available, then you can boil it down to cost and who has the best data plans.
Now for the device connectivity itself. Assuming that there just doesn't seem to be wire where you need it, the wireless option then becomes a question of power. The available power will also largely determine factors such as bandwidth, latency, number of connection points, range, reliability and cost. The following table illustrates a comparison between several common wireless networking protocols. Note that there is always a tradeoff between throughput and power ¨C meaning that sleeping systems have longer latencies and can't transport as much data. There is also a trade-off between complexity and size.
Design the network and place the parts. Note that poor RF performance will make the solution cost ineffective, harder to manage and unreliable. Hence, it is important to understand RF barriers and constraints. Survey the area to work around obstacles if necessary. This will again require a site survey to help with placement of the network components in order to maximise data flow and meet the reliability requirements.
Data is only useful if it gets to and from the host application. This requires a decision on what data is critical and how the IT group will handle it in the long term. The best way to do this is to deliver the data in a standardised form consistent with off-the-shelf database constructs. This is best achieved by creating a data access service model using off the shelf Web services. Since remote locations may not use conventional IP routing, getting the data where it is wanted may require database conversion. Figure 2 illustrates this model with a gateway on the left forwarding data to a centralised XML based repository, accessible across the broader Internet via secure Web services queries.
Fig. 2. Data path from remote to enterprise
Summary
Given the value proposition of effective remote device management, we have defined a concept of a Drop-in Network to meet the needs where traditional wired connectivity does not exist or is not available. Using a combination of wireless technology and a structured data definition for the application at hand, a solution can be deployed using off the shelf Web services based applications. The key is to follow a well defined methodology of defining the needs, assessing the environment, choosing the best wireless technology, designing the network and then brining the data home.
Joel K. Young is senior vice president of research and development and CTO, Digi International
Source: Industrial Ethernet Book Issue 51:38
Articles Menu
|
