You might say that it all started with radio. For most of us, “radio” means what you listen to in your car (where today it’s but one choice rather than the only choice it used to be). AM and FM were, and are, the main variants for that. Take TV into account, and you have VHF and UHF – if you’re receiving it over the airwaves.

Each of those types of radio has its own transmitter and receiver for what are, essentially, four different protocols. Not a huge burden for us home users, but others – in particular, the military and first responders – have had to deal with multiple bands and systems that have made it tough for everyone to talk to everyone else. What worked locally became unmanageable when globalized – and no one could count on one global “language.”

Software-Defined Stuff

And so we got software-defined radio (SDR), at least in concept – even if practicalities make it tough to implement all the way up and down the “stack.” Given fast-enough electronics, you can take your pick of frequencies and modulation schemes, have software implement them so that you’re no longer limited by the hardware, and have a single piece of equipment do what used to take a backpackful.

Key here is that, by intent, the whole radio is implemented in software, digitizing right at reception and analogizing (wow, spell-check is happy with that as a word!) right before transmission. Everything else is digital. The higher the frequency, of course, the harder it becomes. Heck, we’re figuring out how to handle the highest reaches of 5G, in the double-digit gigahertz range, for inexpensive equipment that will speak via 5G. All part of the practical limits of SDR (which move with time), but still encompassed in the concept.

From here we move to the next software-defined thing you may or may not have heard of: software-defined networking. Here we have a fundamental departure from the whole-stack approach that radio entails. Just listening to the name and going by analogy with radio would suggest that this lets a box talk by whatever physical protocol you want, all handled by software.

That could, in theory, be possible. But, at any given stage of semiconductor performance, we’re constantly behind the curve on the demand for network speed. This has given rise to a few architectural notions. We have the fast path, used by most typical easy-to-handle packets: move ‘em on as fast as you can, cuz there’s lots more coming. Anything unusual? Move them over to the slow path where they can be dealt with without slowing down the easy stuff.

The other division is the data plane, defining how packets (fast or slow) are received, analyzed, and transmitted, as distinct from the control plane, which handles decisions on what to do. The control path also handles configuration of networking boxes like routers and switches.

Here’s the thing: the data path – and, in particular, the fast path – is typically handled in hardware so that you can get the fastest operation possible. Companies like Cisco have invested a lot of money in their own ASICs trying to provide the most competitive speed. The slow path can be handled in software, and the control plane is definitely handled in software.

So if we take software-defined networking as being analogous to software-defined radio, then we’d want to make the whole thing – data plane (fast and slow) and control plane – configurable by software. The whole stack. As hard as companies work to goose every last bit of speed out of their ASICS, you know there’s no way that a software implementation could keep up with that. It’s the perennial tradeoff: software for flexibility vs. hardware for speed.

So, in this case, software-defined networking applies to the control plane only, not the data plane. It’s like an IT thing, where networking boxes can be reconfigured by software commands rather than by moving wires around and swapping boxes in and out. This is still extremely useful in cloud applications, where changes in traffic patterns – both into/out of the cloud as well as machine-to-machine within the cloud – mean reconfiguring things for optimal flow.

Taking Software to Manufacturing

All of which brings us to a notion that piqued my curiosity: software-defined manufacturing. I became aware of it through a conversation with Bright Machines, a company evangelizing the idea. So what does it mean? Is this a system by which you can have a single manufacturing box that can be programmed to do anything?

In our conversation, it became increasingly clear that that’s not the case. I focused many of my questions on the low-level aspects – the equivalent of the data plane. The fact that Bright Machines makes a modular robotic system helped to keep my attention there. Robots are, typically, rather custom devices focused on a single task. As Bright Machines tells it, a standard robot may take six months to develop – and it may last only a year. So, if we’re going to make the machines more flexible, I wanted to explore the boundaries of where general ended and custom started.

In my mind, there were two aspects to this: what a robot does and what the robot does it to. The first is a tool thing. If a robot’s job is to be a screwdriver, then you can program it to turn screws in lots of different positions. But it can’t be a hammer. (Unless you make it capable of turning the screwdriver part over and bashing something with the handle, in which case you also need a Dad robot to scold the junior robot for not using tools properly.)

As far as what the tools operate on, that gets to grapplers and shapes and such. Can you insert screws only into flat planes? Can it handle curves? What if the material is flexible, necessitating some delicacy?

It was this questioning that clarified for me that this really isn’t what software-defined manufacturing is about. Yeah, they make a more flexible robot called the Bright Robotic Cell, which is standardized for all applications as far as possible, until you get to the lowest-level tool and handling details. But the big payoff is in the manufacturing equivalent of the control plane. How do you allocate machines to do what? How do you configure the factory floor to operate most efficiently? How can you maximize the usage of everything on the floor? And, frankly, how can you reduce the amount of work done by actual humans?

It’s a meta thing: most of these manufacturing machines already have automation. This is about automating the automation. Control at a higher level. It operates in the machine-to-machine and machine-learning realms. Bright Machines has picked some early market targets: communications equipment, consumer electronics, and automotive electronics. And focus at the moment is on flat circuit boards; they’re not handling flexible or curvilinear items (not to say that they might not go there later).

Within those areas, they have three subcategories: assembly/inspection, production, and design. They’re trying to look across those areas holistically. You might not think of design as part of manufacturing, but it has a role. For example, at present, humans read a spec sheet and manually dial up settings in a machine. In the future, the machine could access the original CAD drawings to get that information electronically and, hopefully, in a less error-prone fashion.

Some of their machines need to be trained to deal with changing externals. For instance, can reflow paste be adjusted to compensate for the humidity at any given time? Bright Machines says that they can perform such machine learning – without training examples. And they’re not saying how they do it; it’s part of their secret sauce.

Such learning can also help them to transform from being reactive to being proactive. If the machines can anticipate a situation in advance, then they can be ready. Part of what the machine learning can help with.

So this is definitely a control-plane thing – in fact, it’s controlling the control planes. Certainly easier to do when you have robots that are your own semi-standardized models, but it’s not likely that factories will replace all of their equipment wholesale. So it has to be able to work with existing machinery too. There are also manufacturing realms – like making semiconductors – where the equipment functionality is anything but accessible, and further automation would be restricted to the highest levels.

Semiconductors are not one of Bright Machines’ targeted markets, but if software-defined manufacturing is really the way of the future for all equipment – not just something being pursued by one company, then there are lots of other areas to be explored by other companies. And, for each one, they’re likely to have to determine the boundaries between what can and can’t be done by software.

More info:

Bright Machines

Sourcing credit:

Brian Mathews, CTO Bright Machines