Net connections require backup plan
Imagine a house filled with smart appliances that incorporate information and services available on the Internet. They are more efficient, reliable and packed with features, and you think, "that makes sense." A microwave that uses bar-code information to set the cook times, a furnace that alerts you when the filter is dirty, and a hot tub that can be turned on with your cell phone are all viable applications for smart appliances that promise us greater convenience.
Before you check for an advertisement warning at the top of the page, let us assure you that we are engineers in the real world too. In fact, we have been working in the real world so long that our imagination is filled with an entirely different vision. We imagine a house filled with chaos:
Smart appliances that are susceptible to every slight modification and format change in information that they were programmed to rely on; information and services that are sporadically maintained and often slow, out of date, or just plain wrong; a microwave that displays a message, "please wait while cook times are downloaded . . . 40 of 10 kbytes." Someone else in the world has a dirty filter in a furnace that is continually spamming us with increasingly desperate pleas for attention. We are faced with a hot tub whose remote manipulation has somehow become a hacker rite of passage.
The gee-whiz days of embedded Internet connectivity are over. We know that devices can be connected, so now the engineering time has to be spent figuring out how to make them work really well. In this article we point out some potential pitfalls associated with linked embedded applications to current Internet technology and how to avoid them.
But first, let's consider some simple reasons why introducing networking to embedded devices makes sense. One reason is that the device may be used in a distributed control system, so the networking capability provides communication between two or more embedded devices that, as a group, implement some desired behavior. Another reason is that the capabilities of, or information in, the device may be made available to client applications on the Internet or intranet, thus implementing a remote-control or monitoring system.
A third reason may be to use services or information available on the Internet as part of the embedded application. A simple example is a sprinkler controller that integrates weather reports to implement water conservation. The controller would delay watering if rain is in the forecast, and use the actual precipitation values to check if it really did rain. With the explosive growth in the number of embedded devices and the pervasiveness of the Internet, the integration of embedded applications with Internet systems will grow exponentially.
Connectivity can either be used to expose the device to the Internet or expose the Internet to the device. On one hand, the device can be manipulated and status information obtained. On the other hand, the device can retrieve information to control its behavior or use external services to off-load or augment its tasks. When the device is exposed to the Internet, it essentially gains a virtual control panel that may be operated anywhere.
The character and function of the device is not altered by this remote accessibility. When an application is enhanced with access to information or network-resident services, the behavior of the device is altered, sometimes significantly. Those significant changes may be important to the user of the device. Either way, special attention must be given to device/Internet interactions.
When information from the network is incorporated into the product, the reliability of the network becomes a design issue. The delays and occasional unavailability of wide-area networks must be taken into account in regard to how the device will behave.
When the information crosses several different service providers (phone company, ISP and local Web server), the service is only as reliable as the weakest link. Design of fallback behavior and redundant path for data retrieval must be considered. In the sprinkler example, there is a reasonable fallback behavior of going open loop and maintaining a fixed schedule.
Using network services and information means making a long-term commitment to maintain the information and the method of accessing it for the life of the product. Whoever provides the device to the consumer also inherits this responsibility. The means of accessing the information is coded into the device, so the IP address of the server and the format of the information being served must be constant.
Buffer overflow
Simple, seemingly backward-compatible changes to the data format may have undesirable consequences, such as overfilling an input buffer. A responsible policy might be to maintain the output data format exactly as it was when the product was initially tested. With that policy, each new product revision that required a different or enhanced set of data would need to have a specific means of accessing the unique data appropriate for that product. You need a network process to alert you if something goes wrong.
If a company ships a product that continually accesses information on the Web, then it would be prudent to have an automatic watchdog program that would insure this information is still maintained and accessible to the devices. Such a program would use the same means of access available to the device and alert someone that the network configuration has broken this access. It wouldn't be surprising to get an alert after several years of satisfied consumer use that says a system administration change has subtly disturbed the means of access to a service. That type of alert would need to be backed up with an information resource that could tell the receiver what is needed compared with what is happening.
It would be pretty foolish to just start shipping product that used a server such as Weather.com to implement a sprinkler. Although the Web is essentially free to users, remember that embedded devices outnumber us by at least an order of magnitude. When an embedded system uses a server, a burden is placed on that server. If the organization paying for the server is not compensated for that burden and it becomes onerous, the server will likely implement those undesirable access changes described above. If the device needs the service, then either the service would be best provided by the manufacturer or by a third party with some sort of service agreement. Distribution may be in order if your product ships in large quantities.
Consider a global customer base and the bandwidth issues that arise if a single location is servicing all the devices.
This type of scenario cries out for some redundancy and distribution of machines, if only to speed access for those remote locations. Having the embedded target "know" about several alternatives in the server would greatly increase its reliability.
Internet cloud
If your device is calling into a generic ISP, or logging in through the Internet from somewhere in the big Internet cloud, then you need to be careful. In the Web world we are all familiar with, a system is immediately updated with enhanced security if a hacker has tried to break into the system and find some flaw.
In the embedded-system world, devices are vulnerable to sniffing. A determined embedded hacker could figure out how to access your system. Using that knowledge, a denial-of-service attack can be brought against your server. The traditional means of protecting against this attack, including changing the means of server access, yields exactly the same results as the attack itself-the devices no longer have access to the server.
Assuming all of the above is taken care of with an in-house, super-reliable, good-for-decades, Y3K OK box, you may not be done. If devices can access a server over the Internet, then can clone devices from other companies access it too? If your company pays for the server, then make sure nobody else's devices can access it. Since your devices can disassemble in the field and be sniffed, anyone might learn the mechanics of accessing your server.
After considering those points, you will design a system where truly nothing can go wrong. However, if something does go wrong, at least for debugging and QA purposes, how will you know? At EmWare, we make software that allows devices to originate messages and use services as well as software that allows the developer to remotely access the device via client-user interfaces. The normal data-collecting and network service system can be diagnosed by a connection-oriented, remote-control system.
Loading comments... Write a comment