Capturing and Exploiting Sensory Data

A growing trend is the automated capture of  "sensory" data, and in the business systems context this data can be used as either a complement to or a replacement for "forms" data - information people key.

Typically, enterprise business systems rely on users (or machines) to supply transactions as "forms" (e.g., inventory balance reports, purchase requisitions). These are collected via screen input, or via an electronic feed expressed  in some document  standard (e.g., ANSI x12, cXML).

“Sensory" data relates directly to some physical phenomenon - e.g., cameras capture light patterns to record a rainbow, oscilloscopes capture wave forms. The sensory data regarding process plant performance might be comprised of a stream of 100 measurements per second for monitoring
(and perhaps more for remote control).

As a specific example, to implement 100% monitoring of a power feed
modulated at  60 cycles per second, the sensing process might be
configured to capture 100 bytes per cycle. At 100% sampling,  monitoring
would generate 21.6 million bytes of information per operating hour and
an aggregate of 189 gigabytes per 365-day year. If transported realtime,
the data would stream across the network at about 48 kbs (roughly 3%
of an industrial  medium-speed Internet connection).

Not  many years ago collecting, moving and storing 200 gigabytes of data
per year  would have been presented formidable technical and monetary
problems. However, with today's "brute force"  levels of computing and
networking performance, a stream of sensory data can piggyback on the company's internal intranet (typically Ethernet and wireless intranet extensions) and on the Internet. It is in fact preferable to stream the data to its ultimate destination, because networks behave better with steady flows rather than herky-jerky lumps of data.

Clearly, there is a lot of sensory data available for capture, as almost every device becomes "intelligent" and networkable. To what extent it is worthwhile to capture sensory data depends in part on whether that data can displace more costly "forms" data.

For example, a power-consuming industrial company may have people doing meter-reading and acting as "human telemetry" devices - keying the readings into some system (or worse still, writing it down for someone else to enter). At today's prices, the very limited data from "forms" input might cost several times as much as automated, fine-grain sensory data capture.

With respect to exploiting new data feeds, the substitution for forms input might  be a straightforward computation process - e.g., sum the raw data from 24 hours of sensor  measurements to report daily consumption.

In other cases, it may take something more sophisticated - e.g., under "vendor managed inventory," the stream of inventory withdrawal measurements can be used to determine at what point the inventory needs to be replenished, with that
estimate also incorporating sensory data from vehicles, seller production rates, etc. VMI eliminates ordinary form-based creation of requisitions, POs, and sales orders.

There is the risk that even though sensory data is captured, obsolescent forms-oriented data input will continue as well, duplicating effort and creating reconciliation problems. Companies often are split into two cultures - the traditional business systems culture (not just the business systems people configuring the ERP, but the cost accountants, safety administrators, etc.) and the process management culture (plant operations, plant maintenance). That gap may be the root cause of by splits in the companies' databases and data management strategy.

There are other "change control" matters to address. Sensory data capture may be caught  in conflict,  because the data is so useful as to be “too” useful. As an example, people who drive vehicles (including I presume most readers of this text) might see in general the value of "sensory" data, but might not want the sensory data from their own vehicle "captured" (speed, rate of acceleration, sounds of metal bending, etc.).

Nevertheless, it seems clear that an important "future" for enterprise business systems application architectures is the graceful blending of classic transaction data with sensory data.