Take, for example, the Gleason 600HTL Turbo Lapper, whose controller was designed by Viewpoint Systems in Rochester, N.Y. Basically, it laps beveled gears (that is, polishes them by grinding an abrasive slurry between them) until they mesh so perfectly they purr rather than clatter -- an attribute important to the car makers that use the beveled gears in car differentials, explains John Campbell, vice president at Viewpoint.
The two gears being polished mesh against each other at right angles while spinning as fast as 3,100 rpm, passing the same point of contact about 52 times per second. But Viewpoint was able to incorporate into the controller a real-time computing system from National Instruments (NI) that can analyze the response of the gears about 20 times faster than that, or about a thousand times per second.
"By looking at variations in the rotation speeds, we were able to detect high and low spots in the gears, and drive a secondary motor to adjust the torque, pushing harder on high spots, backing off on low spots," explains Campbell. Therefore it can correct a problem spot as that spot is identified, while the spinning gears are still meshed at that spot.
"In the end we were able to improve lapping time by 30%," since the machine knows exactly when it's finished polishing a gear, rather than relying on averages, Campbell adds.
But while the results were positive, a frequency of a thousand times a second is hardly noteworthy in this age of gigahertz processors. As it turns out, however, real-time computing is not about speed.
"When people talk about real-time computing there are certain common misconceptions, especially that reacting in microseconds or nanoseconds makes the system real-time, and taking five minutes means it is not real-time," says Prashant Dubal, senior director of product management at Wind River Systems, a subsidiary of Intel and maker of the VxWorks real-time operating system. "But real-time means that the system reliably takes the same amount of time every time it does a certain thing. Duration does not matter."
"If the system's highest priority is blinking a red LED, it always honors that priority, and no matter what else is happening, when the light needs to blink it leaves everything aside to do that, and do it quickly," Dubal explains.
"Traditionally real-time was measured from the perspective of human patience, and if you pushed a button and got information within a second that was real-time," agrees David Barnett, vice president of Real-Time Innovations, a systems integrator in Sunnyvale, Calif. "But a real-time system is one that behaves deterministically, responding predictably to inputs or changes in the environment. Typically these are cyber-physical systems, used to manage a physical process.
"Observers often confuse real-time computing with high-speed computing, such as financial trading or sports betting," adds Barnett. "The difference between high-speed computing and real-time computing is that with high-speed computing you are talking about averages -- you can say on average an operation takes a millisecond. But one time in a thousand it takes much longer. With real-time computing you are confident the operation took place within the deadline, or you know it didn't happen."
Deterministic responses are not accidental, and require a real-time operating system (RTOS), of which there are several dozen on the market -- although, as with many established industries, there are three leaders.
"Wind River with VxWorks is the overall leader," says Barnett, "and then there's Green Hills Software with Integrity, popular in aerospace and defense; and QNX from QNX Software Systems, owned by BlackBerry, popular in automotive and healthcare." Wind River also has a real-time version of Linux.
"Determinism must be baked in; you will not see it on a desktop," says Grant Courville, director of product management at QNX. "You have to care about every CPU cycle and every microsecond. It has to be designed for consistency."
While NI was able to make a real-time version of Linux (NI Linux Real-Time), the effort involved was not trivial, notes Jamie Smith, NI's director of product marketing for embedded systems. "We did an evaluation at the kernel level, dug in and did extensive modifications and testing. The team was fairly large. But this brings real-time computing to the hands of engineers who are not embedded software engineers."
Of course, there will be variations between the time it takes the system to perform the same task at separate moments, and this tolerance is called jitter.
"It determines how good an RTOS is, but it is also very hardware dependent," says Dubal. "Ours is usually two-digit nanoseconds."
Barnett says that with modern processors, jitter is usually measured in microseconds, which is good enough for most applications.
Jitter is not worth talking about with general-purpose programming environments like Java, since they are optimized around a typical case, Barnett adds. "If it is out of memory and needs to do garbage collection to free up memory, it stops to do that, and blocks out all other processing. In real-time computing you devote a little extra work to things like that on every cycle, to avoid longer delays later."
"The jitter on something like (standard) Linux is hundreds of milliseconds," adds Dubal. (NI product literature says the jitter for NI Linux Real-Time is comparable to that for other NI real-time environments.)
But the big trend, sources agree, is that (as with the rest of the computer industry), prices are coming down while systems are becoming more powerful. In the case of real-time systems, that means inexpensive and powerful controllers, optimized for machines interfacing with other machines, are arriving just as the Internet of Things begins to need them.
"The cost of computing and connectivity hardware has dropped by roughly a factor of five in the last 10 years," Viewpoint's Campbell notes, largely driven by the consumerization of smartphone components.
He compares the potential results to that of inexpensive PCs in the early 1980s, which revolutionized office work. Likewise, the combination of data acquisition, local analysis and control hardware could revolutionize manufacturing industries, Campbell says.
Customer expectations have also risen. "Years ago they came for the operating system and the drivers," says QNX's Courville. "Now they want the operating system, middleware, the drivers, applications and connectivity. And they want all the attributes they are used to in a real-time environment, and want it to work as expected at all times."
Shaun Kirby, chief technology officer for Cisco's Internet of Things consulting service, refers to the new environment as a "brave new world" where "tools are making systems more accessible to non-professionals, and you don't need years of training to hack something together. Anyone with a good idea can do an Internet of Things solution."
Indeed, the gear lapper mentioned earlier went from concept to beta testing in six months, thanks to availability of powerful off-the-shelf systems, notes Campbell. Chiefly, the firm relied on a NI CompactRIO, which includes a controller, a field-programmable gate array, an RTOS, real-time programming languages (NI's LabVIEW), a selection of I/O modules for interfacing to other devices and an expansion chassis.
Generally, the application software on a real-time device is highly customized by the integrator, explains Real-Time's Barnett, and some high-end systems like an airplane or an MRI machine might have millions of lines of code. However, these days, above the application there is often another layer that presents a graphical user interface, and it's usually based on off-the-shelf packages, he adds.
But there will be roadblocks on the way to the revolution, notes Richard Soley, executive director of the Industrial Internet Consortium. The first is lack of interface standards.
"Programmable logic controllers speak about two dozen protocols; every manufacturer did their own," Soley says. His organization is working on interoperability standards, but the process has barely begun, he explains.
But once they do get connected, another problem arises -- security. "The real-time vendors are worried about someone hijacking turbines, so they're working on security," notes Kristian Steenstrup, analyst for Gartner.
"I have a lot of confidence in the IT space, but no one has it all figured out yet," adds Smith at NI. "Security is the biggest challenge we have in front of us, and it is being treated as such."
"There is no firmly established practice for the secure development and deployment of embedded systems," complains Chris Rommel, analyst at VDC Research. "Seventy percent of the engineers we surveyed recently said their projects had security requirements, but only 30% said that their organizations were doing anything different in terms of security. The two factors that got in the way were cost and time-to-market constraints."
Dan O'Dowd, founder and CEO of Green Hills Software, boasts that his firm's RTOS, Integrity, has never been hacked and has no known vulnerabilities. "But we spent a thousand dollars per line to develop the security-relevant portions. First we make it secure and then we make everything else, while others make it cool, add features, and then try to make it secure -- and that never works," he says.
"Everyone is afraid of being hacked, and, yes, they are right to be afraid," adds Campbell. "Of course, the easiest way to remain secure is to not connect the machine to anything." (And even that tactic isn't as failproof as it used to be, as researchers are learning.) Barring that, private networks unconnected to the public Internet will probably be popular with corporate users of the Internet of Things systems, he predicts.
With assured security or without, sources agree that the confluence of powerful yet inexpensive real-time components makes the Internet of Things an inevitability -- some are calling it the Internet of Everything.
"The most important thing to realize is that this is the future," says Soley. "We want to get there in a reasonable amount of time, so we need interoperability and we need standards -- and so we need to collaborate."