The emphasis is towards embedded field equipment that needs to deliver data to the Argo Broker. This connectivity can be described as high value data over low bandwidth and high cost data circuits. This type of topology would include the delivery of event driven data over GEO and LEO VSAT systems as well as any dedicated remote communications link including CDPD cellular, radio, microwave, or leased phone lines.
Since the emphasis of this specification is for the purpose of a embedded
systems platform to deliver data to an Argo broker ( and ultimately MQSeries
) we should try to define the level of embedded resources that would be
required. IBM defines this platform as a Pervasive Computing Device (PCD)
and as such would devices such as palmtop and laptop type devices. This
specification would try to drive that definition even lower into an industrial
infrastructure to include the embedded end devices themselves. Arcom would
propose the following arbitrary minimum to support the communications API’s
defined within this document:
The prevalent network topologies available at this time were multi-drop configurations such as leased phone lines and radio networks. Initially leased phone line circuits were relatively inexpensive and radio frequencies were readily available. During the period between the late 1960’s and the early 1980’s the majority of the infrastructure that exists today was deployed using these readily available and affordable technologies.
Due to this topology, the data exchange was accomplished using poll/response type protocols. Since multi-drop topology networks can only support half-duplex traffic when more that two devices are on the network, poll/response protocols had to be implements to avoid data collisions if more that one slave device on the network tried to send data at the same time. Simple modulation techniques and low data rates basically precluded the use of any type of collision detection scheme.
Round robin polling schemes limited the rate at which critical event driven data can be processed. In a poll/response data communications scheme, each end device must be polled in sequence with each of the response packets being fully decoded before the next device can be polled. In many cases the actual round robin poll time meant that critical data from any one site could only be examined at the poll frequency.
To that end the end device manufactures, that is the manufactures of equipment that measure status, flowrate, temperature, level, kilowatts, etc. were driven to develop equipment that was based around a poll/response protocol. Technology, as always, was moving at an exponential pace and throughout the industry there was a lack of any type of data exchange standards. Therefore today we are left with a legacy of literally hundreds of proprietary poll/response protocols.
The Poll/Response protocol paradigm presents several problems in today’s modern business environment. Since data is not delivered until requested, the host computer must continually poll all end devices searching for any data that “MAY” have changed. In most applications this results in the same data values being returned hundred or thousands of times without ever having changed. So the very nature of a typical poll/response paradigm result in 100 percent available bandwidth consumption.
A poll/response protocol also ties the delivery of data to a single host computer device. If any other application requires the data it usually results in custom applications to extract the data from the original target host. This is also problematic when end devices are viewed as data producers that data consumers at the enterprise level need different levels of access to the data producers. In many case one piece of field equipment may be required to deliver data to a multitude of consumer applications and is not able to do that within the existing paradigm.
When leased phone line circuits were inexpensive and radio frequencies were available this was an acceptable arrangement. In most circumstances the data produced by the end devices in these systems was destined for a single host computer applications.
Currently leased phone lines are no longer an inexpensive communications topology and radio frequency availability is becoming limited and in some urban areas are non-existent. With the technology and network topologies available today, the old paradigm of not reporting data until a request comes from a central host computer is at the least very inefficient and at the most problematic in the exchange of critical field data through the enterprise. Proprietary poll/response protocols are difficult to implement and require a significant amount of development time. Since the number of poll/response protocols are so numerous, it is difficult if not impossible for a single solution platform to encompass all of the potential variations and permutations. The end customers are locked into a limited number of available options when it comes to host end interface equipment/software as well as the type of end devices that must be used and thereby limiting the amount of new technology that can be used.
BACK to index