The highlight of the visit was seeing the scale of Ford’s operation, and particularly the scale of its research and development organization. Prasad’s building is a half-mile into Ford’s vast research and engineering campus. It’s an endless grid of wet labs like you’d see at a university: test tubes and robots all over the place; separate labs for adhesives, textiles, vibration dampening; machines for evaluating what’s in reach for different-sized people.

Prasad explained that much of the R&D that goes into a car is conducted at suppliers–Ford might ask its steel supplier to come up with a lighter, stronger alloy, for instance–but Ford is responsible for integrative research: figuring out how to, say, bond its foam insulation onto that new alloy.

In our more fevered moments, we on the software side of things tend to foresee every problem being reduced to a generic software problem, solvable with brute-force computing and standard machinery. In that interpretation, a theoretical Google car operating system–one that would drive the car and provide Web-based services to passengers–could commoditize the mechanical aspects of the automobile. If you’re not driving, you don’t care much about how the car handles; you just want a comfortable seat, functional air conditioning, and Web connectivity for entertainment. A panel in the dashboard becomes the only substantive point of interaction between a car and its owner, and if every car is running Google’s software in that panel, then there’s not much left to distinguish different makes and models.

When’s the last time you heard much of a debate on Dell laptops versus HP? As long it’s running the software you want, and meets minimum criteria for performance and physical quality, there’s not much to distinguish laptop makers for the vast majority of users. The exception, perhaps, is Apple, which consumers do distinguish from other laptop makers for both its high-quality hardware and its unique software.

That’s how I start to think after a few days in Mountain View. A trip to Detroit pushes me in the other direction: the mechanical aspects of cars are enormously complex. Even incremental changes take vast re-engineering efforts. Changing the shape of a door sill to make a car easier to get into means changing a car’s aesthetics, its frame, the sheet metal that gets stamped to make it, the wires and sensors embedded in it, and the assembly process that puts it together. Everything from structural integrity to user experience needs to be carefully checked before a thousand replicates start driving out of Ford’s plants every day.

So, when it comes to value added, where will the balance between software and machines emerge? Software companies and industrial firms might both try to shift the balance by controlling the interfaces between software and machines: if OpenXC can demonstrate that it’s a better way to interact with Ford cars than any other interface, Ford will retain an advantage.

As physical things get networked and instrumented, software can make up a larger proportion of their value. I’m not sure exactly where that balance will arise, but I have a hard time believing in complete commoditization of the machines beneath the software.

See our free research report on the industrial internet for an overview of the ways that software and machines are coming together.

Some executives see prestige in quirky ticker symbols, or those that are just one letter long, and the exchanges take advantage of that to attract listings. It was rumored, for instance, that the New York Stock Exchange was reserving “M” and “I” for Microsoft and Intel, respectively, should they ever decide to ditch NASDAQ, and it finally gave up M in 2007 when Federated Department Stores re-listed itself as Macy’s. Since then, the exchanges have fallen over themselves to list tech companies, and NASDAQ and the New York Stock Exchange have handed over “Z” to Zillow and “P” to Pandora.

But the list of single-letter ticker symbols is strikingly Ozymandian. Two letters ahead of Zillow, and only about 43% larger by valuation, is United States Steel, the biggest corporation in the world at its founding by J.P. Morgan in 1901, but marginal enough 90 years later that it was removed from the Dow Jones Industrial Average.

At “Y” on the New York Stock Exchange is Alleghany Corp., today a smallish insurance firm, but at one time a swashbuckling holding company that controlled almost a fifth of the U.S. railway network, including the Chesapeake & Ohio and the New York Central, one of the country’s biggest, which it won in a dramatic proxy battle. It was a proto-conglomerate in the eventual mold of ITT and Gulf+Western, and in the middle of the 20th century it did as many railroad companies, and got the hell out of the railroad business. Its ancillary investments, after a few acquisitions and divestments, added up to an insurance business. (When, in 1970, Penn Central Transportation filed for the biggest bankruptcy to date, its parent company similarly survived and held an insurance business alongside some of the railroad’s real estate. Its successor company, American Premier Underwriters, continued to own New York’s Grand Central Terminal and the air rights above its tracks, leasing them to New York’s Metropolitan Transportation Authority, until 2006 when it sold them to a group of real-estate investors.)

I thought of closing this post by clarifying that I don’t wish the fate of U.S. Steel and Alleghany on Tableau and Zillow, but a century of existence for any company is a remarkable achievement, particularly for one that came about at a high point in investor enthusiasm for its industry.

Photo: Times Square – NASDAQ by luisvilla, on Flickr

Download this free report
(PDF, Mobi, EPUB)

The big machines that define modern life — cars, airplanes, furnaces, and so forth — have become exquisitely efficient, safe, and responsive over the last century through constant mechanical refinement. But mechanical refinement has its limits, and there are enormous improvements to be wrung out of the way that big machines are operated: an efficient furnace is still wasteful if it heats a building that no one is using; a safe car is still dangerous in the hands of a bad driver.

It is this challenge that the industrial internet promises to address by layering smart software on top of machines. The last few years have seen enormous advances in software and computing that can handle gushing streams of data and build nuanced models of complex systems. These have been used effectively in advertising and web commerce, where data is easy to gather and control is easy to exert, and marketers have rejoiced.

Thanks to widespread sensors, pervasive networks, and standardized interfaces, similar software can interact with the physical world — harvesting data, analyzing it in context, and making adjustments in real-time. The same data-driven approach that gives us dynamic pricing on Amazon and customized recommendations on Foursquare has already started to make wind turbines more efficient and thermostats more responsive. It may soon obviate humans as drivers and help blast furnaces anticipate changes in electricity prices.

An electric furnace at the Allegheny Ludlum Steel Corp. in Brackenridge, Pa. Circa 1941.
Photo via: Wikimedia Commons.

Those networks and standardized interfaces also make the physical world broadly accessible to innovative people. In the same way that Google’s Geocoding API makes geolocation available to anyone with a bit of general programming knowledge, Ford’s OpenXC platform makes drive-train data from cars available in real-time to anyone who can write a few basic scripts. That model scales: Boeing’s 787 Dreamliner uses modular flight systems that communicate with each other over something like an Ethernet, with each component presenting an application programming interface (API) by which it can be controlled. Anyone with a brilliant idea for a new autopilot algorithm could (in theory) implement it without particular expertise in, say, jet engine operation.

For a complete description of the industrial internet, see our new research report on the topic. In short, we foresee that the industrial internet* will:

• Draw data from wide sensor networks and optimize systems in real-time.
• Replace both assets and labor with software intelligence.
• Bring the software industry’s rapid development and short upgrade cycles to big machines.
• Mask the underlying complexity of machines behind web-like APIs, making it possible for innovators without specialized training to contribute improvements to the way the physical world works.
• Create a valuable flow of data that makes decision making easier and more accurate for the operators of big machines as well as for their clients and suppliers.

Our report draws on interviews with industry experts and software innovators to articulate a vision for the coming-together of software and machines. Download the full report for free here, and also read O’Reilly’s ongoing coverage of the industrial internet at oreil.ly/industrial-internet.

* We have adapted our style over the course of our industrial internet investigation. We now use lowercase internet to refer generically to a group of interconnected networks, and uppercase Internet to refer to the public Internet, which includes the World Wide Web.

This is a post in our industrial internet series, an ongoing exploration of big machines and big data. The series is produced as part of a collaboration between O’Reilly and GE.

Comparing industrial Internet security to consumer and enterprise web security is difficult; requirements, challenges, and approaches differ significantly. In industrial systems, stability is crucial, and isolating an infected system — or adding an air gap as a preventative measure — can be enormously costly. Some tools that are difficult to apply to the unstructured web are effective in industry, though: since industrial systems usually have known, simplified network structures with highly regular traffic patterns, anomaly detection and other machine-learning techniques hold great promise as ways to find and stop attacks. The addition of more computing power at the network level as companies connect their industrial systems will make these approaches more powerful.

Back in October, Eugene Kaspersky announced that his security firm is developing an industrial operating system — a “highly-tailored system,” one that “by design won’t be able to carry out any behind-the-scenes, undeclared activity.” Last fall, I interviewed Roel Schouwenberg (@Schouw), a researcher at Kaspersky Lab who is working on the new industrial OS. What follows is a lightly-edited transcript of our wide-ranging conversation.

Tell me a bit about how the OS project came about — does it have its origins in Kaspersky’s Stuxnet research?

Roel Schouwenberg: Eugene [Kaspersky] and a few others started talking about this a decade ago, actually. Eugene’s idea was that the only way to solve the malware problem would be to build something that was constructed with security in mind — what he called secure OS. That was just a concept for a while, and then Stuxnet came along and it became increasingly clear that the secure OS implementation would be best suited for the industrial control world, where you have this very specific set of circumstances where it would just work best.

If you work on consumer machines and say, “here is this completely different operating system, have fun with that,” that obviously doesn’t work, but in the industrial control world there are different sets of requirements that place a big emphasis on security above all else.

Saudi Aramco was in the news recently saying that they very strongly believe that the goal of the Shamoon malware was to sabotage production of oil. That didn’t happen, obviously, but the company was crippled. They said the object of Shamoon was to actually mess with the oil production and hurt the company and the global economy that way. Shamoon doesn’t come close in any way, shape or form to Stuxnet, but I think that the significance of Shamoon cannot be understated. It was a relatively simple piece of malware with very silly programming errors that was still very effective in wiping all those machines. Even though it didn’t affect oil production itself, Saudi Aramco really struggled to recover from that attack. I think that was maybe the most significant event in that part of the cyber war this year.

So, it was a sabotage attempt, not an espionage attempt?

Roel Schouwenberg: Right, it was a sabotage attempt pretty much from the get-go. Shamoon wiped the data off of any computer that it infected. The goal — or the hope of the attackers — was that Shamoon would be able to bridge the air gap and get onto the industrial control network, and then wipe machines on that network, or any Windows machine on the network, at least.

A lot of industrial systems have been designed without Internet connectivity in mind. Now managers want to connect their systems to the Internet for remote monitoring and emergency control, and even if it’s through a VPN to some control center, it still multiplies the number of entry points and complicates security immensely, right?

Roel Schouwenberg: There are a number of issues here. One of the issues is that actual air gaps really decrease productivity. A lot of people in the industrial world say their efficiency goes down by 20 or 30 percent if they really have no connectivity whatsoever. At that point, you have to employ sneakernets, and people are not so happy about that.

Actually, at one industrial control conference recently, people were telling me that it’s now possible to control certain systems with an app on your iPhone or on your iPad, which is obviously crazy when you think about it. The idea of managing a water or electrical facility with your smartphone is absolutely crazy, but from the fact that it’s now available, you can see that there’s demand for it.

It makes sense when you think about it. If there’s a huge blizzard or something like Sandy happens, you don’t want to go out into that kind of weather, and it would be safer and faster to do that kind of administration from home. But that obviously introduces very interesting security risks.

Is the security risk principally a malware risk introduced by the mobile device, or is it just a generic risk that comes from having more points of connection to the system?

Roel Schouwenberg: It’s both, really. The idea of somebody maybe even using their personal phone to manage critical infrastructure is obviously crazy, but it seems that’s becoming more or less mainstream. If all it takes to get access to that type of facility is to infect somebody’s smartphone, that will really be pretty easy because people don’t think about security on smartphones too much at this point. So, we expect more of these targeted attacks.

We have this situation where, as you pointed out, these systems were not designed with Internet connectivity in mind and now there should be connectivity, at least to the corporate network. I think that can be more or less manageable. But now, all of a sudden, these systems are Internet accessible — directly Internet accessible, and not even just that, but there are dedicated apps for it. That’s going to get messy real soon.

There’s a price to IT security in general. Right now, we have a security situation that is basically suboptimal. We’re at a reasonably stable place, but it’s not an easy fight, and all of a sudden you’re adding mobile and cloud and all of these convenience features into the equation and it becomes exponentially more complex.

As you’re working on the secure OS, what is the vision for that? Is it actually something like a SCADA or PLC operating system, or does it sit at a layer in the air gap?

Roel Schouwenberg: Right now, we’re not yet at a point where we can fully disclose what our implementation is going to be, but the idea is basically that the code is quote-unquote perfect. The level of quality that we need in the code is extremely high and is unlike anything that we’ve seen before. So, basically the goal really is for this OS to have no vulnerabilities, which is clearly a very, very high goal and very hard to achieve. The idea is basically to generically detect if some instruction or some command could be malicious, and to block it.

So, it would use machine learning in order to detect the baseline operation of something like a machine tool, and then understand when it’s been instructed to carry out an unusual operation?

Roel Schouwenberg: That would be one of the approaches that one would take for that, yes. But as I mentioned, I can’t go into any specifics at this point, as we are in the very early stage, and I think we are trying to approach some things from a very different perspective.

When we do have a finalized product, we will be sharing source code with whoever is interested. Obviously, we are talking about critical infrastructure here. The stakes could not be higher. We believe that transparency is extremely important, so we will share source code with governments so that they can confirm that the code is solid.

Big industrial firms are often very conservative in how they approach these things, and they have an old system that works. From what you hear, are they receptive to the idea of a completely new operating system?

Roel Schouwenberg: I think there’s been a lot of positive response, and a lot of people are interested. People really trust our expertise; they’ve read the articles that we’ve published in the last few years with regard to Stuxnet. I think many companies are interested in seeing what we’ll be able to come up with, and I think we’ll definitely be given a shot, if you will, especially if we’re sharing source code, and there will be true vetting of the code.

Do you imagine that it would take a generic enough form that a client could install it on its own?

Roel Schouwenberg: We are working with a number of partners to optimize integration. That is something that is needed, and we’re working on that right now.

What are the shortcomings in the industrial operating systems that are out there and being sold in new systems now?

Roel Schouwenberg: Basically, we are a security company. Everything we do and build is with security in mind, and in the industrial control world they are not there. It took Microsoft many years to become an acknowledged player in terms of security development and, and when you look at the types of vulnerabilities being discovered in SCADA and ICS software today, those are very basic issues. They’re basically at the same level that we saw 10 years ago for Windows. So, there is a very big gap between where most vendors are and where reality is, if you will.

How similar is an OS that runs in a railroad locomotive to an OS that runs in an automotive factory or an OS that runs in a dam? Do they all face the same problems at some generic level that you can approach the same way?

Roel Schouwenberg: I think most of the problems are generic enough that you can approach them in the same way.

Are there any generic approaches to this kind of security in place at the moment? Is there an industry standard that’s in use?

Roel Schouwenberg: There definitely are a number of rules and guidelines that we see, but they only have limited effects. Sometimes regulations make people jump through hoops that they really shouldn’t have to jump through. On the other hand, we see that there is a lot of leeway when it comes to the air gap. Sometimes air gap systems aren’t as air-gapped as they’re supposed to be, and that’s one of the challenges for these types of things.

You mentioned regulation. What are you facing in that respect?

Roel Schouwenberg: I’ve heard stories from some people in the field saying, “I don’t have a Windows environment, but because of regulations, all of a sudden I have to install a Windows virus scanner” or something along those lines. That’s just one example.

I think that’s definitely one of the other major struggles. Governments are trying to see how they can help with this problem, but environments are different, and it’s tough for them to come up with something that’s generic enough that it actually helps everybody and doesn’t slow people down. But with that in mind, I do expect that in the course of next year [2013] there will be some developments from the U.S. government, or governments elsewhere, that talk more specifically about regulation in the ICS space that would encourage people to be more secure.

To be more secure in a productive way, you think, or is the approach in the case of U.S. regulation counterproductive?

Roel Schouwenberg: I think the U.S. government realizes that just pushing through regulations that aren’t going to help is not going to be productive. From what I’ve seen so far, they are definitely trying to come up with a balanced way, but it’s a very complicated field.

I think one of the things we may see is some stricter enforcement of air gaps, but that is a very complicated question, and as I mentioned, a lot of the people I talk to say their efficiency takes a serious hit between a partially air-gapped system and a full air gap. That’s a very tough question for the government. Would the government want to more strongly enforce full air gaps and take that productivity hit? I think that would be very highly debated, and I’m not sure we’re going to see an answer there soon because taking a 20 or 30 percent efficiency hit is obviously rather substantial.

Is there a set of industry guidelines today that you think is sensible?

Roel Schouwenberg: There is a lot of common sense in the NIST guidelines, but we do hear that there are some environment-specific issues that cannot be addressed in the broad-guideline kind of way. There are different challenges that you may face being a water utility versus an electric utility. Those situations are not mentioned. So, the question will be whether we’ll see more specific guidelines for that moving forward, or whether this will be something that remains untouched. Right now, I don’t have an answer for that.

In the balance between security and productivity, one of the difficult elements is the human who gets frustrated and circumvents his employer’s security systems. Do you have a sense of the approach you might take there? You see this all the time in consumer security.

Roel Schouwenberg: I think that’s human nature. I’ve heard crazy stories of people bringing in their own computers and connecting them to the control network. Maybe they were bored at night and wanted to play a game on the network, and that wasn’t good enough, so they put in another network card and hooked up that server to the Internet. So, all of a sudden, the control network was directly accessible from the Internet. That stuff happens.

There’s only so much you can do when it comes to that. Obviously, education is important — explaining to people, “Look, you’re putting things in serious jeopardy here.” I think some companies have said it’s grounds for immediate dismissal, and that generally gets the job done.

This is also where the generic security approach becomes important, right? Because the idea is that the software never trusts a particular security measure that’s taken. It’s not aware that there’s an air gap, so it doesn’t trust the air gap.

Roel Schouwenberg: Right. When you build something with security in mind, then that is basically synonymous with saying, “Trust no one, trust nothing.” You can argue that the cause of nearly every security vulnerability that we can see is that some code is assumed to be trusted. When you say, “What if somebody tries to do this or that?” the response should not be, “Why would they do that?”

This is where you see that the industrial control world is really different from the IT world. There are not enough people who know a lot about both worlds. Incidents such as Stuxnet and now Shamoon are obviously destructive, but they are major catalysts when it comes to educating people. More people really need to see proof of things going wrong before they say, “OK, I’ll wear a safety belt, I’ll wear a helmet,” and so on. Both fortunately and unfortunately, moving forward we’ll see more such bad events. Hopefully they will help people be more aware of security.

Industrial controls are headed for the consumer area in fairly short order. Cars today have Microsoft operating systems with cellular connectivity that control just the radio and navigation system, but in something like the Google driverless car, the same operating system is also controlling brakes and acceleration.

Roel Schouwenberg: All this hardware around us is becoming soft. It’s all software these days.

A few months ago, I was dropping off my car at the garage and they said, “We updated the software for your transmission.” It’s absolutely crazy. They’d have had to use a cable for that, but at the same time more and more people have apps on their phones that can remotely start their cars or unlock them.

That’s the bigger picture in today’s world. Everything is becoming wired or, rather, wireless. The field, the scope, the domain of potential software vulnerabilities is just growing and growing. Ten years ago it was just your desktop. Now we have smartphones, cars, you name it. That’s part of why Stuxnet was a landmark event. There was just a handful of people looking into that before, and now a lot of people are interested in it.

All these systems that were basically living in their own little world based on security ideas from the 1970s and 80s are inadequate in 2012.

A car is a lot like an industrial control in a power plant where the security assumption is that if you have access to a port, then you have the authority to be there — you’ve been admitted to the plant floor. And that’s changing when you make it wireless. What should the approach there be?

Roel Schouwenberg: Segregation is very important. On some planes, there is a common link between the flight deck and the entertainment system for the passengers, which is all sorts of crazy.

If you deny people access in the first place, that makes things a lot better. A few years ago, we heard that a malicious music file that you burned on a CD and put in a car would cause a denial of service, not just against the radio but against the car’s entire electrical system.

That’s very clearly a case of non-proper segregation. The radio should not touch the critical systems. Now you have these up-and-coming vehicles, like Tesla, that are really more software than anything else, and the big question is, how secure are they? Right now, I’m not sure that there’s anything to answer that question, really. Which is maybe the reason why I went for a relatively simple car; it doesn’t have any wireless options, even though I was offered the feature where you can turn on your car with your smart phone. Maybe I can expense that.

There’s a human security flaw, too, with some of these wireless services where there’s a giant call center somewhere with hundreds of people switching on cars remotely or downloading their diagnostic information. It’s an extremely complicated environment, and it’s exactly what we were talking about earlier where the connectivity takes these systems that used to have just a few entry points and increases the number of entry points exponentially.

Roel Schouwenberg: I was on a plane the summer before last, waiting for the restroom and I looked around, and I suddenly noticed right next to the console that flight attendants use to turn on and off the lighting that there was a USB port. I can only imagine what that USB port could bring me. It’s hiding in plain sight. Obviously, I did not do anything to it, but I’m very curious.

One of O’Reilly’s authors, Alasdair Allan, was staying in a hotel last fall and managed to download the access records for his room’s electronic lock. He only read it, but the lock also probably had APIs for reprogramming the lock, resetting it, and things like that. People seem not to have given a great deal of thought to what it means to provide these entry points.

Roel Schouwenberg: At offensive security conferences, there are some people who look into those sorts of things, and generally the findings are quite scary; these systems are easily infiltrated because nobody ever designed them with security in mind. All these systems are increasingly electronic, increasingly interoperable, and security is not high on their priority lists.

If you want to take another route, look at TV. If you buy a fancy new Samsung, it comes with Skype and whatnot that integrate into the TV. And underneath Skype is Android. So, you’re looking at a device that’s going to be connected to the Internet for the next five or maybe 10 years. When is it going to receive security updates? You’re looking at millions of peripheral electronics. Treadmills, even, run Android now and are going to be without security updates for a very, very long time.

The great thing about Android is that it’s open and you can basically plug it into any device. But it’s so easy that it’s showing up in all sorts of applications where people haven’t thought about its environment very carefully. On a TV, maybe the worst thing that happens is that you miss your favorite TV show for a week. But looking at it from more of a cyber crime perspective, there’s definitely use for cybercriminals there. It’s obviously not critical infrastructure, but it’s something to think about.

This is a post in our industrial Internet series, an ongoing exploration of big machines and big data. The series is produced as part of a collaboration between O’Reilly and GE. This interview was edited and condensed.

But Oostendorp, earlier a co-founder of Slashdot, was aiming to bring modern computer vision systems to heavy industry, where the Latinate name didn’t resonate. At his second meeting with a salty former auto executive who would become an advisor, Oostendorp says, “I told him we were going to call the company Ingenuitas, and he immediately said, ‘bronchitis, gingivitis, inginitis. Your company is a disease.’”

And so Sight Machine got its name — one so natural to Michigan’s manufacturers that, says CEO and co-founder Jon Sobel, visitors often say “I spent the afternoon down at Sight” in the same way they might say “down at Anderson” to refer to a tool-and-die shop called Anderson Machine.

Sight Machine is adapting the tools and formulations of the software industry to the much more conservative manufacturing sector. Changing its name was the first of several steps the company took to find cultural alignment with its clients — the demanding engineers who run giant factories that produce things like automotive bolts.

At its heart is something of a crossover group — programmers and designers who are comfortable with Silicon Valley-style fast innovation, but who have deep roots in Midwestern industry. Sight Machine’s founders quickly realized that they needed to sell their software as a simple, effective, and modular solution and downplay the stack of open-source and proprietary software, developed by young programmers working late hours, that might make tech observers take notice.

Sight Machine staff in the Ann Arbor warehouse where they built a full-scale mockup of an auto-plant quality-control station to test their system

“Nate saw these big bottlenecks in the way things were being done” in industrial computer vision, says Sobel. “There were no high-level frameworks like Ruby on Rails, and everything is set up to be pass-fail; there are no higher-level analytics.” Sight Machine set out to build what they hope will become “Rails for vision.”

Sight Machine’s co-founders built much of SimpleCV, an open-source computer vision library that’s designed to be accessible to people who aren’t experts in the field. (O’Reilly has published a book on SimpleCV, written by four of Sight Machine’s principals.)

Sight Machine’s software measures grain-flow characteristics in a fastener, using little more than a commercial flat-bed scanner.

Anthony Oliver, the company’s CTO and co-founder, worked on automation at a big car plant in Toledo, Ohio, before being laid off during the recession and deciding to switch tracks. “They had 200 cameras at the plant, but they were treating them like black boxes — after the picture was done, they’d throw it out. They weren’t collecting trending patterns, doing self-correction,” he says. The plant had bought computer vision systems from integrators that weren’t making much data available for higher-level analytics.

“There’s a huge disconnect [in heavy industry] from the Internet way of doing things,” says co-founder Kurt DeMaagd, also a Slashdot co-founder. “Process engineers are very data-driven, but they haven’t tried these new tools, and they’re not working in real-time.” Oliver says the goal was to build a system that would raise immediate flags, “as opposed to saying, ‘hey, a week ago we were having quality-control problems.’”

Their system puts a clear emphasis on the value of software rather than hardware (though a few of the industrial-quality components, in particular the CCD cameras they use, remain expensive). It can stand on its own as a module in an automated factory; no system integrator necessary. And, in the modern form, it emphasizes data retention and high-level analytics.

Sight Machine’s first client manufactures bolts — fasteners, as they’re called by industrial insiders — checking the integrity of their steel at the beginning and end of each batch by slicing one open and scanning it on a cheap flatbed scanner. Software discerns the dimensions of the steel’s grain (compression lines that form when the head of the bolt is pounded out) and provides an instantaneous quantitative measure of quality. The previous method had involved employees looking at bolts through microscopes.

Swarming in a tank at a fish farm. Sight Machine’s object: to signal the feeding system to stop putting food in the tank once the fish had eaten enough to be satisfied. Photo: courtesy Sight Machine.

Another client, a fish farm in Michigan, uses Sight Machine’s software to manage feeding — determining when the fish have had their fill by measuring changes in movement and switching off the farm’s auto feeders. Another proposal for an Ann Arbor-based deli and mail-order house would use Sight Machine software to watch for bunch-ups in the production line and tell managers to send help to, say, the jam-labeling station if the employee there is having trouble filling orders fast enough.

And in a live demonstration that I saw at the company’s industrial-park development space, Sight Machine software detected a misapplied badge on the back of an SUV. That’s a problem that could be corrected quickly and easily at an automaker’s quality-control checkpoint, but if a car that doesn’t have four-wheel drive makes it to a dealer’s lot with a chrome “4×4″ badge glued to the tailgate, the logistics and inventory costs of fixing the problem will be substantial.

Cameras photograph a car as it rolls through an inspection station, and signal in real-time whether trim features like badges, taillights, and rims are correct. Photo: Jon Bruner.

In addition to a real-time check like this one, Sight Machine’s software can also aggregate results for higher-level analysis. Engineers can, for instance, call up photos of every yellow car with a bent antenna.
Photo: courtesy Sight Machine.

Industrial firms tend to be conservative in adopting new systems, for a reason: the costs of a plant outage are huge (consider that a large auto assembly plant might produce more than 60 vehicles per hour — an outage of just one minute is equivalent to one car’s worth of lost production). They also tend to have enormous amounts of capital tied up in big, integrated production systems, making changes costly.

Sight Machine’s founders have approached both of those obstacles carefully. The company’s developers work in an industrial park in Ann Arbor, Mich., where they built a mockup of an auto-plant inspection station to test their software under factory conditions. Several of them have worked in heavy manufacturing, including automotive and defense, and the company has its roots at the decidedly machine-oriented Maker Works, a maker space across the street that offers Michigan’s industrial prototypers access to plasma cutters and CNC mills.

Early prototypes got some upgrades to meet the expectations of plant managers used to heavy-duty equipment. Sight Machine’s system uses costly CCD cameras instead of cheaper consumer-grade cameras. Design director Kyle Lawson says, to make the company’s first camera mount he “took a Logitech webcam stand, broke it down, and filled it with pennies to make it feel industrial.” (Now he fabricates heavy-duty camera mounts himself at Maker Works.)

As for the problem of weaving a new assembly line component into an old plant, Sight Machine’s software is free-standing and can be provided as a service or licensed to run locally — minimal integration with plant controls needed. That’s an important consideration for a cautious assembly-line manager who’s experimenting with a startup’s software.

Software and industry are inching closer; the industrial Internet will make it easier for innovators to turn physical-world problems into software problems, and then solve them using rich open-source tools and pervasive networks. Along the way, I think we’ll see lots of stories like Sight Machine’s.

This is a post in our industrial Internet series, an ongoing exploration of big machines and big data. The series is produced as part of a collaboration between O’Reilly and GE.

The Internet revolutionized the software-software interface; the industrial Internet will revolutionize the software-machine interface and, in doing so, will make machines more accessible. I’m using “access” very broadly here — interfaces will make machines accessible to innovators who aren’t necessarily experts in physical machinery, in the same way that the Google Maps API makes interactive mapping an accessible feature to developers who aren’t expert cartographers and front-end developers. And better access for people who write software means wider applications for those machines.

I’ve recently encountered a couple of widely different examples that illustrate this idea. These come from very different places — an aerospace manufacturer that has built strong linkages between airplanes and software, and an advanced enthusiast who has built new controllers for a pair of industrial robots — but they both involve the development of interfaces that make machines accessible.

The Centaur, built by Aurora Flight Sciences, is an optionally-piloted aircraft: it can be flown remotely, as a drone, or by a certified pilot sitting in the plane, which satisfies U.S. restrictions against domestic drone use. Customers include defense agencies and scientists, who might need a technician onboard to monitor equipment in some cases but in others send the plane on long trips well beyond a human’s comfort and safety limitations.

John Langford, Aurora’s founder, described his company’s work to me and in the process offered a terrific characterization of what the industrial Internet does: “We’re masking the complexity of the machine.”

The intelligence that Aurora layers onto its planes reduces the entire flight process to an API. The Centaur can even be flown from the pilot’s seat in the plane through the remote-operator control. In other words, Aurora has so comprehensively captured the mechanism of flight in its software that a pilot might as well fly the airplane he’s sitting in through the digital pipeline rather than directly through the flight deck’s physical links.

A highly-evolved interface between airplane and its software means that the software can draw insight from the plane, reading control settings as well as sensors to improve its piloting performance. “An experienced human pilot might have [flown] 10,000 to 20,000 hours,” says Langford. “We already have operating systems that have hundreds of thousands of flying hours on them. Every anomaly gets built into the memory of the system. As the systems learn, you only have to see something once in order to know how to respond. The [unmanned aircraft] has flight experience that no human pilot will ever build up in his lifetime.”

The simplified interface between humans and the Centaur’s combined machinery and software might eventually make flight vastly more accessible. “What we think the robotic revolution really does is remove operating an air vehicle from the priesthood that it’s part of today, and makes it accessible to people with lower levels of training,” he says.

Trammell Hudson's PUMA robotic arm setup at NYC Resistor, with laptop running kinematics library, homemade controller stack, and robot.

“The arm itself has no smarts — just motors and quadrature encoders,” he says. (Even the arm’s current position is stored in the controller’s memory, not the robot’s.) Hudson had to write his own smarts for the robot, from scratch — intelligence that, when the robot was new, resided in purpose-built controllers the size of mini-fridges but that today can be built from open-source software libraries and run on an inexpensive microprocessor.

The robot’s kinematics — the spatial intelligence that decides how to get the robot’s hand from one place to another by repositioning six different joints — run on Hudson’s laptop. He’s interested in building those mathematical models directly into a controller that could be built from widely-available parts by anyone else with a similar robot, which could give second lives to thousands of high-quality industrial automation components by taking discarded machines and assigning new intelligence to them.

“The hardware itself is very durable,” Hudson told me. “The software is where the interesting things are happening, and the controllers age very rapidly.

Hudson’s remarkable feat of Saturday-afternoon electrical engineering was made possible by open-source microcontrollers, software libraries, and hardware interfaces (and, naturally, his own ingenuity). But he told me the most important factor in the success of his project was the rise of an online community that has an extraordinarily specialized and sophisticated understanding of electronics. “The ease of finding information now is incredible,” he said. “Some guy posted the correct voltage for releasing the arm’s brake, and I was able to find it in a few minutes and avoid damaging anything.”

“We went through a white-collar dark ages in the 1980s,” Hudson said. “People stopped building things. No one took shop class.” Now hardware components, abstracted and modularized, have become accessible to anyone with a technical mindset, who can improve the physical world by writing more intelligence onto it.

In an earlier reverse-engineering project, Hudson wrote his own firmware, which became Magic Lantern, for Canon’s 5D Mark II digital SLR camera. “I have a 4 by 5 [inch] camera from the 1890s — with my Canon 5D Mark II attached to the back,” he says. “The hardware on the old camera is still working fine, but the software on the 5D is way better than chemical film.”

This is a post in our industrial Internet series, an ongoing exploration of big machines and big data. The series is produced as part of a collaboration between O’Reilly and GE.

WellDone — Utilities in the developed world use remote monitoring widely to keep far-flung equipment running smoothly, but their model is tough to apply in places where communications infrastructure is thin, though. This initiative has adapted the philosophy of the industrial Internet to the infrastructure that’s available: SMS text messaging. WellDone is installing water-flow sensors at local wells that send flow data by SMS to a cloud database. The system will alert local technicians when it detects anomalies in water flows, and the information it gathers will inform future data-driven development projects.

Manufacturing’s Next Chapter (AtlanticLIVE) — I’m visiting this conference in Washington, D.C. today; it’s also being live-streamed at The Atlantic‘s Web site. At 2:35pm Eastern Time and at 3:25pm, panelists will talk about the effect of technology on industry and the rise of advanced manufacturing.

Electricity Data Browser (U.S. Energy Information Administration) — The EIA has made its vast database of detailed electricity statistics available through an integrated interactive portal. The EIA has also built an API that opens more than 400,000 data series available to developers and analysts.

This is a post in our industrial Internet series, an ongoing exploration of big machines and big data. The series is produced as part of a collaboration between O’Reilly and GE.

NIST is looking for two fellows — one with a background in information technology and the other from physical engineering — reflecting the convergence of those fields in the industrial Internet, where challenges move fluidly back and forth between software and hardware.

Shyam Sunder, director of the engineering laboratory at NIST, proposed the fellowships as a way to coordinate the broad public and private research efforts that are going into the industrial Internet. The President’s Council of Advisors on Science and Technology had identified cyber-physical systems as a national priority for federal research and development in 2007 and 2010, and the field was part of the mandate of the Advanced Manufacturing Partnership announced in 2011.

At the same time, private-sector work on the industrial Internet has accelerated in domains like automotive technology, manufacturing, utilities and logistics, says Sunder. “They all have, as their core, networking and information technology being integrated within engineered physical systems. They all have a strong emphasis on sensors, controls and processors that are networked and somehow have to be organized.”

Those domains are blurring, with many functions that used to be handled by specialized hardware now handled in more generically-build software. “This convergence is what motivates our work,” says Sunder. “There’s value to looking at these in a coherent fashion.”

NIST has been collaborating with industry and academics for a year now, staging a workshop in March 2012 and an executive round-table in June. Last fall NIST broadened the group of agencies working on industrial Internet development to include, among others, the National Science Foundation.

The call for fellows is broad. “We have cast a wide net for two kinds of people that I think are crucial here,” says Sunder. “One brings the networking and IT perspective in things like interoperability, cybersecurity, and systems integration; and then, of course, the other one brings the physical systems perspective in areas such as controls and sensing.”

And, says Sunder, the environment in which the fellows will work is specialized and will require careful coordination with industry. “Industrial control systems traditionally have been very tightly controlled, tightly-coupled systems. So when you deal with the challenge of the industrial Internet, even though stacks might look similar [to those used in the open Internet], the details of those stacks can be incredibly challenging to define because you have to balance the openness and the security aspects in very interesting and clever ways. Industry is on the front line of these challenges, and by bringing bridges with industry, we can help elucidate what those frameworks might be in all these areas.”

The standards-setting deals with what Sunder calls an “open connection layer,” which sits on top of proprietary intelligence and contains communications between machines—cars exchanging information between each other, for example, or with highway infrastructure. “It’s the non-proprietary interactions that you have to manage for,” he says. “The economic potential and the public safety potential and the public benefit potential of these new technologies will depend on the ability to deal with non-proprietary interaction.”

This is a post in our industrial Internet series, an ongoing exploration of big machines and big data. The series is produced as part of a collaboration between O’Reilly and GE.

Robot Army (NYC Resistor) — A pair of robotic arms, stripped from their previous application with wire cutters, makes its way across the Manhattan Bridge on a bicycle and into the capable hands of NYC Resistor, a hardware-hacker collective in Brooklyn. There, Trammell Hudson installed new microcontrollers and brought them back into working condition.

The Next Wave of Manufacturing (MIT Technology Review) — This month’s TR special feature is on manufacturing, with special mention of the industrial Internet and its application in factories, as well as a worthwhile interview with the head of the Reshoring Initiative.

At Disney Parks, a Bracelet Meant to Build Loyalty (and Sales) (The New York Times) — A little outside the immediate industrial Internet area, but relevant nevertheless to the practice of measuring every component of an enormous system to look for things that can be improved. In this case, those components are Disney theme park visitors, who will soon use RFID wristbands to pay for concessions, open hotel doors, and get into short lines for amusement rides. Disney will use the resulting data to model consumer behavior in its parks.

This is a post in our industrial Internet series, an ongoing exploration of big machines and big data. The series is produced as part of a collaboration between O’Reilly and GE.

Imagine a not-implausible situation: you are driving down a brisk road at 30 mph with a car heading towards you in the other lane at approximately the same speed. A large ball rolls out into the street, too close for you to brake. You, the human, knows that the ball is likely to be followed, in seconds, by a small child; you slam on the brakes (perhaps giving yourself whiplash) or swerve, at considerable risk of hitting the other car.

What should a self-driving car do?  More to the point, if you hit the kid, or the other car, who gets sued?

The lawyer could go after you, with your piddling $250,000 liability policy and approximately 83 cents worth of equity in your home. Or he could go after the automaker, which has billions in cash, and the ultimate responsibility for whatever decision the car made. What do you think is going to happen?

The implication is that the problem of concentrated liability might make automakers reluctant to take the risk of introducing driverless cars.

I think McArdle is taking a bit too much of a leap here. Automakers are accustomed to having the deepest pockets within view of any accident scene. Liability questions raised by this new kind of intelligence will have to be worked out — maybe by forcing drivers to take on the liability for their cars’ performance via their insurance companies, and insurance companies in turn certifying types of technology that they’ll insure. By the time driverless cars become a reality they’ll probably be substantially safer than human drivers, so the insurance companies might be willing to accept the tradeoff and everyone will benefit.

(Incidentally, I’m told by people who have taken rides in Google’s car that the most unnerving part of it is that it drives like your driver’s ed teacher told you to — at exactly the speed limit, with full stops at stop signs and conservative behavior at yellow lights.)

But we’ll probably get the basic liability testing out of the way before a car like Google’s hits the road in large numbers. First will come a wave of machine vision-based driver-assist technologies like automatic cruise control on highways (similar to some kinds of technology that have been around for years). These features present liability issues similar to those in a fully driverless car — can an automaker’s driving judgment be faulted in an accident? — but in a somewhat less fraught context.

The interesting question to me is how the legal system might handle liability for software that effectively drives a car better than any human possibly could. In the kind of scenario that McArdle outlines, a human driver would take intuitive action to avoid an accident — action that will certainly be at least a little bit sub-optimal. Sophisticated driving software could do a much better job at taking the entire context of the situation into account, evaluating several maneuvers, and choosing the one that maximizes survival rates through a coldly rational model.

That doesn’t solve the problem of liability chasing deep pockets, of course, but that’s a problem with the legal system, not the premise of a driverless car. One benefit that carmakers might enjoy is that driverless cars could store black box-type recordings, with detailed data on the context in which every decision was made, in order to show in court that the car’s software acted as well as it possibly could have.

In that case, driverless cars might present a liability problem for anyone who doesn’t own one — a human driver who crashes into a driverless car will find it nearly impossible to show he’s not at fault.

This is a post in our industrial Internet series, an ongoing exploration of big machines and big data. The series is produced as part of a collaboration between O’Reilly and GE.