feature article
Subscribe Now

Software-Defined Manufacturing

Bright Machines Wants to Do to Mfg What’s Been Done to Radio, Networking

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

One thought on “Software-Defined Manufacturing”

Leave a Reply

featured blogs
Sep 28, 2022
Learn how our acquisition of FishTail Design Automation unifies end-to-end timing constraints generation and verification during the chip design process. The post Synopsys Acquires FishTail Design Automation, Unifying Constraints Handling for Enhanced Chip Design Process app...
Sep 28, 2022
You might think that hearing aids are a bit of a sleepy backwater. Indeed, the only time I can remember coming across them in my job at Cadence was at a CadenceLIVE Europe presentation that I never blogged about, or if I did, it was such a passing reference that Google cannot...
Sep 22, 2022
On Monday 26 September 2022, Earth and Jupiter will be only 365 million miles apart, which is around half of their worst-case separation....

featured video

PCIe Gen5 x16 Running on the Achronix VectorPath Accelerator Card

Sponsored by Achronix

In this demo, Achronix engineers show the VectorPath Accelerator Card successfully linking up to a PCIe Gen5 x16 host and write data to and read data from GDDR6 memory. The VectorPath accelerator card featuring the Speedster7t FPGA is one of the first FPGAs that can natively support this interface within its PCIe subsystem. Speedster7t FPGAs offer a revolutionary new architecture that Achronix developed to address the highest performance data acceleration challenges.

Click here for more information about the VectorPath Accelerator Card

featured paper

Algorithm Verification with FPGAs and ASICs

Sponsored by MathWorks

Developing new FPGA and ASIC designs involves implementing new algorithms, which presents challenges for verification for algorithm developers, hardware designers, and verification engineers. This eBook explores different aspects of hardware design verification and how you can use MATLAB and Simulink to reduce development effort and improve the quality of end products.

Click here to read more

featured chalk talk

High Voltage Charging Solution for Energy Storage & Backup Systems

Sponsored by Mouser Electronics and Analog Devices

Today there is growing demand for energy storage with more power, longer range, and longer run time. But the question remains: how can we increase our energy storage given the energy storage mediums on the market today? In this episode of Chalk Talk, Amelia Dalton chats with Anthony Huyhn from Analog Devices about the benefits of high voltage energy storage, why stacked battery cells are crucial to these kinds of systems, how high voltage energy storage systems can reduce conduction loss exponentially and what kind of high voltage charging solutions from Analog Devices are on the market today.

Click here for more information about the Maxim Integrated MAX17703 Li-Ion Battery Charger Controller