Monthly Archives: May 2010

Automation and Software in the Next Decade

2 Replies

The “low intellectual property” Fashion Industry as a model for innovation?

I have to agree. Since I’ve started getting involved in open source software, I can tell you that intellectual property laws are the biggest obstacle to innovation that I face. I can say that because I took the time to consult with intellectual property lawyers on everything from trademark to copyright to open source license to software patent. Here’s what I found out: you can’t write a single line of code without violating someone’s patent, somewhere. However, the only time that person will enforce their patent claim is if you’re really successful. The only defense is to pay tens or hundreds of thousands of dollars to build up a patent portfolio of your own so you can partake in a ludicrous arms-race deterrent. On top of that, your patent portfolio offers no defense against so-called “patent trolls”: companies that only own patents and don’t write software of their own. They’re the equivalent of a terrorist cell with nuclear weapons… your nukes are ineffective because you don’t have a city to target.

Copyright is under control, mostly because it’s so much weaker than patents, and it’s free. It stops whole-sale copying of your software, but allows someone to look at your source code, learn from it, and then write it themselves without violating copyright (if they’re careful). Plus, the wide adoption of open source licenses give us lots of material that we can freely copy or integrate.

The irony is that patents were supposed to speed up innovation, but they’ve done exactly the opposite in the software industry.

Do you want to know why none of this matters though? I’m going to make a bold prognostication here:

If the last decade (have we agreed on what to call it yet? The Oh’s?) was about more crap, then the next decade will be about customized crap. Seriously, we gorged ourselves on the mountain of crappage that is sold at Wal-mart and people are starting to wake up with a hangover. We’ve already seen the desires start to change from more to better but I think we’re going to see it change to mine. People are going to want unique stuff. Things that they had a hand in customizing. Something they can use to express themselves.

This has major implications for manufacturing, so it affects the automation industry, and I think it also affects software. Just like the fashion industry, where people use clothes to express themselves, we’re about to enter an age when all the crap you sell to consumers has to have a story, a personality, and be unique. Mass production will remain for your basic staples, and China is going to continue to provide us with that, but North America and Europe are going to have to start producing bespoke crap.

What does this mean for automation? We’re going to see a rise in the build-a-bear style build-your-own-product-on-a-website and have it manufactured and sent to your door the next day. Imagine the logistical changes that need to take place to make that happen. Internet merchandising companies like cafepress already have a leg up in this department. Their merchandise is manufactured after you order it. Now imagine a product with 10,000 or a million different variations, and the automation that has to support it. Imagine the automation required to manufacture products whose specifications change as fast as fashion trends.

On the software side, we’re going to see every major application support custom 3rd party add-ins so everyone can customize their software so it works for them. I think we’re also going to see a rise in “pseudo-programming languages” that let people who aren’t programmers actually customize their applications in ways that we’ve never let them do before. Platforms that give people the power to build solutions to their own needs are going to flourish, and one-size-fits-all solutions like word processors will fade into obscurity.

So I think we’ll have two options: the vast majority of us are going to spend our time building custom things for individuals or businesses. The successful ones will produce products that people can customize themselves.

A Bigger Picture of Automation

2 Replies

When you’re immersed in the world of industrial automation for a long time, you may start to think that PLCs, relays and valves are automation. That’s really not the case. Automation applies to doing anything automatically. Those little timers you plug your lights into when you go on vacation are automation. Automatically billing your customer as soon as product is scanned when it goes on the truck is automation.

To me, we’ve solved a lot of the excruciatingly difficult technical challenges, like motion control, because they can be boiled down to academic pursuits and packaged into a black box. The pain is in the integration. The tyranny of dry contact I/O and 4-20 mA analog signals is because they’re universal standards that nobody’s figured out how to patent yet (or the patents have lapsed). These universal standards make integration of components from various manufacturers possible, and it’s the backbone that supports the industrial automation industry.

The leap from the mechanical and electrical to the digital world should have made integration easier and more flexible. To some extent it has, but we now have these proprietary walls built between our solutions. I once wouldn’t hesitate to connect a valve from company A to a relay from company B, and those companies knew it, and the competition kept prices down and drove innovation forward every year. Now I have to make design decisions about which vendor’s hardware plays better with others before I can buy the first item on my bill of materials. What kind of valve bank do I buy? It depends on whether or not I need a ProfiBus or a DeviceNET communication module on it.

There’s no doubt that the digital alternatives are cheaper than hard wired solutions, and we have made progress on standard bus systems thanks to organizations like the ODVA, but what we really lack is a common open file format for storing our automation programs. As long as we’re stuck with the legacy traditional PLCs, then automation itself is stuck in the mud. But there are open automation systems right around the corner. Systems that aren’t going to be focused on industrial automation, and they’re going to tackle the integration problem in a way that proprietary systems just can’t do for us.

I’m building one of these next-generation systems right now. It’s an automation platform. It’s open. It’s free. It’s not a PLC.

Beckhoff in the Kitchen

Leave a reply

I was a little surprised when I read about Industrial PC Technology in High End Kitchens in Beckhoff’s PC Control magazine. The entire kitchen is integrated together using industrial PC technology:

SieMatic’s self-developed software for the selection menu and the control functions forms the heart of the SieMatic Grid. The basis is a
modularly structured Beckhoff Embedded PC equipped with a Windows XP Embedded operating system as well as a .Net framework. Via RS232, the Beckhoff PC controls the T+A components as well as managing all functions that they do not take care of. Above all, these naturally include all the typical PC tasks, such as Internet access, e-mail access and data services (such as weather forecast or newsfeeds), but also entertainment programs, such as slide shows. All Miele@home appliances are also integrated via the Ethernet interface of the Embedded system.

The most important functions, however, run invisibly in the background, because the Beckhoff PC works almost like a mediator between different worlds: for example, a television broadcast can be interrupted for messages from the Miele system – that the dishwasher program has finished, for instance – if the user so desires. The integration of other systems – for example, the picture from an IP monitoring camera – is easy to accomplish using Beckhoff hardware. It was clear from the outset to SieMatic project manager Thorsten Pawelczyk that the SieMatic Grid would be a constantly growing and changing system: “The fact that the Beckhoff automation system hardly sets any limits regarding the integration of other systems comes just at the right time.”

I question the logic of putting industrial technology in a consumer kitchen, but I must admit I’m impressed and envious. I think the real question is, does it have the “hackability” we’ve come to expect from industrial control systems? Can I connect to it with TwinCAT PLC and modify the functions, extend it, or tie in new systems? Somehow I doubt it. The article mentions it runs a .NET application, so in this case they’re probably only using the hardware, not the Beckhoff control software.

How Many Times Must I Tell You, “Don’t Repeat Yourself”?

Leave a reply

I spend a significant amount of my time these days doing PC programming (as opposed to PLC programming) and I’d say the most time consuming part of my job is following the DRY Principle, aka “Don’t Repeat Yourself”.

The naive interpretation of the DRY principle is that it’s about minimizing the amount of code you write. While this may sometimes be a side effect, this isn’t the point of DRY at all. What we’re trying to do is structure the program so that there’s just one place for everything, and everything is in it’s one place. This is a lot harder than it sounds because no matter how you segment your program into modules, classes, or layers there’s always something that cuts across those boundaries.

Take logging for instance. Every part of the application needs to log things to the same log file. The naive implementation of opening a file, writing a line, and closing it is short but doesn’t follow the DRY principle because we’re repeating this simple sequence of steps all over the place. The danger is that if we change our logging strategy, we now have to change multiple places in every file.

There are probably two ways that the “logging strategy” could change:

  1. We change where (or if) we want to log the data, like to a database instead of a file
  2. We change the kinds of stuff we want to log

We can handle the first case easily by moving the logging logic into a global subroutine, or if you’re more advanced you would use something like a logging service with the service locator pattern. That would let us change where we log the data, and if we include a severity level with the logging interface, we could filter our logging by severity.

The second case is really hard to solve. We have to choose each spot in the code where we want to log information. Maybe every time I catch an error in a try/catch block, but that means every time I write a try/catch block I have to add a call to my logging service. This case violates the DRY principle because the idea is just “every time I catch an error in a try/catch block”. That idea needs to be codified in one place. Ideally I should be able to extend the try/catch block of the language and say, “any time you execute a catch I also want you to do this”. That’s not possible with .NET, that I know of anyway.

Likewise, maybe I want to know every time a user carries out any action that might affect the underlying data in the database, and I’ll have to add logging code at each of those places too. If you have all of your database access going through a single layer in your application, at least you can confine the logging to that layer, but it may consist of dozens of classes representing dozens of database tables. That’s where we need something like the ADO.NET entity framework, and have all of our database entities derive from a single base class, and then we might be able to tie our logging rules in there.

The problem is that these architectural solutions are hard. They take a lot of effort, and when you just need to add logging, it’s too easy to just go through your code and add logging wherever you need it, and you’ve created a maintenance nightmare. It’s the extremely low cost of copy and paste vs. architecture that creates this problem. If you had to pay $1 every time you copied and pasted code, I bet you’d write more maintainable software.