Small computer boards have become very popular recently among hobbyists and makers; examples of these boards include: the Arduino, Raspberry Pi, and Beaglebone Black (BBB). These boards are small, inexpensive ranging in price from $35 to $45, but still very powerful. There are numerous examples that are easily found where these boards have been connected to a wide variety of sensors to realize sophisticated systems.
Can these boards be effectively used to realize Distributed Intelligence Sensor Systems (DISS's) in industrial applications? To help answer this question, two reference designs have been developed: the first design allows the BBB to be connected to four different sensors having digital interfaces; the second reference design converts a traditional industrial Wheatstone bridge sensor to have a digital output.
This article describes our experiences in developing these reference designs intended to be used with the BBB, describes the capabilities of this approach, and also gives a number of recommendations for others considering using a similar approach.
Advantages
Using DISS's for industrial automation offer advantages of secure encrypted communications and data transfer to a central and/or remote monitoring system. DISS's continuously check their status and health, which often includes power-supply voltages, temperature, and connectivity to the sensor and to the central monitor. Faults are immediately detected, the central monitor is informed, alarms are triggered, alarm e-mails are sent, and corrective action is quickly initiated to minimize plant down-time.
Other advantages include both distributed and central data logging, and digital communication links that are much less susceptible to electromagnetic interference (EMI) and noise. Historically, DISS's were prohibitively expensive, but recently the hardware costs have plummeted to be only a minor factor. For these reasons, new factories are being designed with DISS's in place and older legacy plants are being upgraded.
Risks
However, changing to a DISS-based plant is not without risk. A DISS is significantly more complex than a legacy analog-based sensor system and the distributed intelligent nodes are full-fledged computers. Unless properly set-up and maintained, the added complexity can potentially become a show stopper. If improperly designed, the system may never work and plant operation will be at risk.
There are three possible choices. First, keep the traditional, analog-output, non-networked, sensor system. Second, use a system from a large established sensor company such as GE Measurement and Control, Rockwell, Granite SemiCom, Siemens, or STMicroelectronics, etc. And third, install a new-generation DISS-based approach.
The first choice, however, may eventually leave the company non-competitive while choice two is a viable interim approach, but having the disadvantage that systems and maintenance can be very expensive, proprietary, and don't take advantage of most of the recent game-changing advances. The third choice, which this article focuses on, offers many advantages. But users must be prepared for on-ongoing custom development requirements and should not embark on such a development unless they are prepared to do it right.
DISS Architecture
The DISS system being investigated is shown in Fig. 1. It consists of a number of BBB computer boards interconnected using the IP/TCP Internet connections.
Fig 1: A Distributed Intelligence Sensor System (DISS) based on BeagleBone Black Computer Board with an I²C Expander Cape connected to Sensors Interfaces for Wheatstone Bridges.
Each board has a Cape added to it, which expands its digital interface capabilities. This includes a number of digital links to sensors plus an expanded number of GPIO input/outputs for applications such as controlling relays, or receiving digital signals from sensors such as proximity switches.
The sensors we are initially considering are based on Wheatstone bridges where the only electronics encapsulated in the sensor is our Sensor Interface Reference Design. Data logging of sensor outputs is primarily done by the BBB's into local files which are then periodically up-loaded into the central computer. This makes the non-real-time scheduling of the IP/TCP links a non-issue. It also ensures data integrity even if the local internet comes down.
Required Expertise
Designing DISS's into industrial plants requires a wide variety of expertise including analog-and digital-circuit design, computer programming, operating-system maintenance, GUI programming, secure encrypted Internet communication protocols, etc. Few service houses have capabilities in all of these disciplines.
Deciding on whether to install or convert to a DISS approach poses critical questions. Is the necessary expertise available from in-house engineers, a design-services company, or both? Does the business model support a working-together approach to get the job done?
Re-Inventing the Wheel
Another important question is do critical sensors and interfaces need to be designed from scratc, or can they be realized by modifying existing designs? In some cases, reference designs can be customized to meet customer needs with only minor fast turn-around changes. In these cases, custom designs can possibly be developed in only a few weeks.
Many, if not most, industrial sensor systems are highly custom in nature. By basing a solution on a generic pre-developed reference design, risk and development time are minimized while still meeting the customer's custom needs. In addition, features of the reference designs are evidence of capabilities, and allow customers to more easily assess the value of investing in a DISS approach.
Reference Designs
One of our first reference designs is the development of a Cape Board that is intended to be used with a BeagleBone Black intelligent node. The Cape is shown in Fig. 2. Very similar interface boards can also be used for other small-board computers such as the Arduino and the Raspberry Pi.
Fig 2: A Cape and Sensor Interface developed for the BeagleBone Black intended for digital sensor applications.
This Cape allows an inexpensive ($45) BBB computer to be used to interface to four independent digital output I²C serial buses where each bus can be connected to one or more sensors. The I²C serial bus is one of the most popular standards for interfacing to digital output sensors and is quickly gaining in popularity. For an example, visit http://sensing.honeywell.com.
The Cape can be modified for other industrial digital sensor interfaces such as the Modbus, Profibus, other Fieldbus standards, or the CAN Bus. The board includes eight general purpose input/output connections (GPIOs) that can drive relays or sense external digital signals, monitor its own power-supply voltage and temperature, and offers a programmable output voltage to support both 3.3V and 5V applications. It also includes an EEPROM for additional data logging and to give it black-box functionality.
A second reference design, also shown in Fig. 1 as the small round board, is used to convert traditional analog sensors to digital interface sensors. It is placed next to a Wheatstone-bridge based sensor and conditions the small sensor signal by amplifying it, eliminating offsets and non-linear events with very high accuracy and converting the conditioned signal to a digital output again based on the I²C standard.
This reference board is intended to be encapsulated directly into the sensor case. The Granite SemiCom sensor conditioner supports digital calibration of gain, offset, and non-linearity, which can all be dependent on the temperature at the sensor. This calibration approach is extended to support both calibration at the time of manufacture and updating/adapting the calibration coefficients in the field during actual operation.
An example of where this is desirable might be in measuring gas or liquid pressures, where the media being measured is changed, and it is desired to cover a different pressure range. It also allows a single product to be used in a wide variety of different applications minimizing inventory costs and complications.
Having a digital interface allows for all connections right up to the Wheatstone-bridge being continuously monitored. In addition, sensor interface power-supply voltage, Wheatstone-bridge excitation voltage, and temperature can all be read, to ensure system integrity and logged by the BBB computer board. If any component or communication link is lost, the data is still preserved as it is saved in non-volatile memory.
With the distributed intelligence, sensor operation continues even if the internet link comes down. When there is a problem right at the sensor, the fault is detected, and the alarm is immediately communicated to the head-office or optionally e-mailed or texted directly to maintenance personnel. The programming range of both gain and offset are large allowing one design to be used for a large variety of different applications.
Minimizing Costs
The hardware cost of retrofitting a legacy plant to a modern digital sensor solution is very close to actual component costs, and this cost is minimal. Labor costs can be much larger. They are minimized by basing custom designs on pre-developed reference designs. The customer pays for the time necessary for the customization necessary to meet their particular needs, for the time required for installation, and for desired maintenance, Customers do not pay for the previously-incurred development costs of producing the reference designs.
Software costs are minimized by initially installing a simple system to match current capabilities and then upgrading the system on a need-to-have basis. Also, by using a mature operating system for the BBB, such as Ubuntu, Debian, or Android, a wealth of existing software packages are available, which minimizes the amount of new software development necessary.
Networking
Current reference designs enable connecting I²C sensors to BBB computer boards that are networked using secure SSL encrypted communications over the ubiquitous 100-Mb/s Ethernet standard. The Ethernet links can be standard twisted pair (CAT-5e or 6), although shielded twisted-pair (CAT-6a or 7) is recommended for better electro-magnetic interference (EMI) rejection. Other alternatives are Power-Over-Ethernet (POE) cables and optical cables.
Optical cables are highly recommended for harsh environments with large EMI while plastic optical fiber (POF) connections are often preferred because of their low price, extended reach, small bending radii, light weight, and especially due to their ease of installation.
Board Comparison and Limitations
Our experiences in exercising the reference designs show the BBB board is robust and well-designed. Its additional capabilities are well worth the additional $10 cost compared to the Rasberry Pi.
The most valuable extended capabilities include the ability to run a much larger operating system from the SD card, larger RAM, expanded I/O capability, especially when interfaced through the "real-time" 32-bit PRU co-processors, and higher speeds. Also, the BBB runs much cooler than the Raspberry Pi, which simplifies putting it in an enclosure and could improve long-term reliability.
The major limitation regarding the board is the lack of a real-time clock chip. We are guessing that the real-time PRU's included in the Texas Instruments AM3359 chip were originally intended primarily to get data to and from a core DSP chip. Replacing one of the two PRU's by a DSP core, even a simple one, would be a substantial improvement.
Doing real-time signal processing using the PRU's, although possible, is exceedingly difficult due to the limited set of arithmetic op codes, i.e., it takes a lot of assembly instructions for operations that should be done in one step. This is a non-issue for accessing the reference designs for most industrial applications, but could be an issue in future applications.
Software Issues
The major difficulties in using the BBB to interface to the cape and sensor chip are software complexities coupled with poor documentation. The Angstrom operating system, which ships with the BBB, was chosen by the BBB manufacturer because of its light-weight and requires a relatively small amount of non-volatile storage; the BBB comes with 2-GB eMMC chip. Plus, it boots up fast and is easy to access for new users.
This operating system has a number of differences from more standard Linux versions that caused difficulties, and that coupled with poor documentation, were hard to surmount. Examples include a non-standard SSL implementation, and the use of conman for networking; both of these are problematic. Other operating-system choices are Debian and Ubuntu, which is based on and similar to Debian. Support and documentation for all choices is lacking as is Texas Instrument's support for the BBB, especially for BBB software.
After a number of hard-to-solve problems using Angstrom, we moved to Ubuntu, which in our opinion was superior. Ubuntu is supplied by Canonical, but their support for the BBB is also lacking, and there are reports that Ubuntu includes spyware which is problematic in secure industrial systems unless disabled. Can one ever be sure it is completely disabled? We intend to move to Debian in the near future for this reason and also due to the lack of support from Canonical.
Currently, using Android on the BBB is problematic because support is lacking and most current versions are based on the Linux 3.2 kernel rather than the 3.8 kernel, which has device tree support for accessing device drivers. This situation is changing, and using Android will be an option shortly, but may be experimental for some time.
There is no good documentation available for properly explaining the use of device trees on the BBB; most documentation was written in the days of the PowerPC. There are, however numerous examples that can be used as starting points.
Current Status
References designs are currently under-going tests and to date work very well, The measurement repeatability and low noise are excellent. There are low-level interface programs running on the BBB's for initializing the capes and sensors, and running both integrity and scheduled measurements with data-logging to files. They also are working well.
We are currently working on the GUI to control the sensors and we intend to run this directly on the BBBs from the central computer and we don't expect to have problems here based on previous similar designs. We have had problems with the device drivers, but have been successful to date in working our way through them.
Despite the problems, we have been successful in working though practically all the software issues to date, but this took considerable time and is a moving target as the operating systems are being continually upgraded and do not yet include long-term stable versions. We expect this situation to improve as time goes on. Our recommendation is to get to a good working OS image, and then stick with it until the time of the next major upgrade, which should be well tested prior to installation.
There is still much work to do. We are currently working on encapsulating our Sensor Interface using a high quality in-production Industrial Pressure Sensor to allow for field testing. We have not yet started on realizing the watchdog timers required for re-booting the BBBs in case of OS lock up or crashing issues.
We have also not yet started on alternative digital interfaces to the Sensors such as Hart, CAN, and Profibus; we expect to work on these as the need arises.
Conclusions
We recommend that a company planning on using the BBB for industrial applications work with a service provider that has already worked through most of the issues. Alternatively, one could use the much better supported and documented, but less powerful and high-running-temperature Raspberry Pi. We have worked through many of its issues with the BBB and recommend it as the preferred choice. We further recommend that plant upgrades initially be done on an incremental basis while the bugs are worked out as there will be issues that need resolving.
In summary, the advantages of converting to a digital DISS approach are many including early fault detection, improved EMI rejection, centralized and distributed data logging, and ease of control. The risks are also many and must be managed; this is best done by relying on proven excellence.
About the Author
Kenneth W. Martin was a Professor at UCLA from 1980 to 1991. He attained tenure (Associate Professor) in 1982, and became a Full Professor in 1987. In 1985, he founded the Integrated Circuits and Systems Laboratory (ICSL) and Major Field at UCLA, which became the incubator of many high-tech companies, including Broadcom. In 1991, Professor Martin returned to the University of Toronto to accept a position as an Endowed Professor, which he held until 2008, when he became an Adjunct Professor. He has also co-authored numerous other books, chapters, and well over 100 papers.