|
There are pros and cons associated with any potential solution. This article presents justifications for a dedicated IO-EVENT SERVER versus a custom Single-Board Computer to monitor, log, and trigger events in a real-time manufacturing process. The specific client-example monitors items passing through an oven at random intervals on a conveyor belt. Client requires temperature monitoring, logging, and emergency notification if the temperature changes too rapidly within any given period of time. Client will be using a dedicated infrared temperature sensor to scan items as they pass a predetermined point in the oven. Temperature refresh rate is 165ms. While the client does not want all data reading stored all the time, there is a requirement to back-log data readings for several seconds/minutes before an extreme change-in-temperature event occurs. Our proposed solution would buffer all readings for the client’s backlog period (say, 15 minutes) and continue to overwrite UNLESS an event occurs, in which case the back-log data will be stored in the permanent log.
Start-up & Recovery time: The Interceptor-2500 IO-Event Server has a start-up and recovery time of ~3s. This includes internal error-checking routines, and DHCP recovery (in a DHCP network). Program state and memory are immediately restored. In case of power loss, an internal/dedicated battery can save current state for days, weeks, months, or years (depending upon battery size). A Single Board Computer (SBC) will require from approx 30s to several minutes to perform reboot. This does not include state-restore condition, which varies depending upon operating system, custom programming, etc. CPU Overhead: The Interceptor-2500 IO-Event Server is programmed with an optimized, configurable instruction set, yet it has no operating system, in the common meaning of the term. This means that it is highly efficient and 100% of system resources (CPU, etc.) are dedicated to the task at hand (current event). A SBC will require a significant amount of available resources just to manage the SBC itself, plus all its subsidiary operations, and will need to keep available resources in reserve. This means that the SBC is performing millions of tasks that are not directly related to event monitoring. Any errors, bugs, corrections, or reallocation of resources for any of those supporting operations will negatively impact the primary task, as defined by the user (in this case temperature monitoring and logging). Put another way, the primary task of any SBC is to manage its own operations. The primary requirement as defined by the user must always be a secondary priority to the SBC.
Data Storage, Seek, & Recovery Time: The Interceptor-2500 IO-Event Server conducts all memory operations in real-time. That means that as an event occurs, logging, storage, and monitoring occur simultaneously in real-time (there is an infinitesimally small time delay related to the amount of time required to propagate an electrical impulse throughout the circuitry). A SBC must perform several discrete operations to log and store events. Each event must be “threaded,”, cached, and stored. It is true that these operations are performed very quickly. Using increasingly powerful CPU’s will further improve performance.
Power Consumption: The Interceptor-2500 IO-Event Server consumes very little power (<1W). Typical SBC1 for this type of application consumes 10-25W.
Thermal Runaway: Related to Item- above. Very low power consumption also means that the Interceptor-2500 IO-Event Server does not get “hot,” is completely enclosed, and requires no ventilation. Its proven performance in industrial environments up to +70°C further means that operators do not need to take extra precautions to protect data reading errors from Thermal Runaway conditions. Since A SBC will consume more power, it also means that it is subject to hyperbolic growth in it’s temperature gradient, which also means that it will often require additional ventilation to maintain operating temperatures. In addition, it will dissipate a significant amount of heat, which may affect other data acquisition equipment and/or readings.
Future proofing: The Interceptor 2500 IO-Event Monitor comes pre-configured with a versatile embedded event monitoring application. Programming, “hooks,” and new applications are easy to set up with a moderate amount of programming knowledge. The interface is based upon open source software standards, which means that anyone has the ability to reprogram the application to fit their needs. Further, it is very easy to take the existing application and tie-in data readings in real-time to any computer, using a few, freely available, open-source tools2. A SBC would require an entire custom programming job to perform the same function. It would then become a completely dedicated system with only one function. Reprogramming would mean taking the system off-line and installing another entirely custom software package.
Time-to-Deploy: The Interceptor-2500 IO-Event Server is an existing product and can be deployed immediately, subject to current stocking levels. Rolling out the SBC solution would require specifying the SBC, all components, like DAQ, HDD, memory, casing, power supply, user interface, touch-screen, etc.. Then there would be a series of program-test-reprogram phases. Time-to-deployment is only limited by the amount of time, energy, and money the client is willing to spend.
Cost: Custom programming time notwithstanding, the Interceptor-2500 IO-Event Server is extremely cost-effective, especially when compared with the cost of SBC & DAQ solutions. When the cost of custom programming the SBC is taken into account, the difference in costs can easily be several orders of magnitude.
|