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
Apr 14, 2021
Hybrid Cloud architecture enables innovation in AI chip design; learn how our partnership with IBM combines the best in EDA & HPC to improve AI performance. The post Synopsys and IBM Research: Driving Real Progress in Large-Scale AI Silicon and Implementing a Hybrid Clou...
Apr 13, 2021
The human brain is very good at understanding the world around us.  An everyday example can be found when driving a car.  An experienced driver will be able to judge how large their car is, and how close they can approach an obstacle.  The driver does not need ...
Apr 13, 2021
If a picture is worth a thousand words, a video tells you the entire story. Cadence's subsystem SoC silicon for PCI Express (PCIe) 5.0 demo video shows you how we put together the latest... [[ Click on the title to access the full blog on the Cadence Community site. ]]...
Apr 12, 2021
The Semiconductor Ecosystem- It is the definition of '€œHigh Tech'€, but it isn'€™t just about… The post Calibre and the Semiconductor Ecosystem appeared first on Design with Calibre....

featured video

Meeting Cloud Data Bandwidth Requirements with HPC IP

Sponsored by Synopsys

As people continue to work remotely, demands on cloud data centers have never been higher. Chip designers for high-performance computing (HPC) SoCs are looking to new and innovative IP to meet their bandwidth, capacity, and security needs.

Click here for more information

featured paper

Understanding the Foundations of Quiescent Current in Linear Power Systems

Sponsored by Texas Instruments

Minimizing power consumption is an important design consideration, especially in battery-powered systems that utilize linear regulators or low-dropout regulators (LDOs). Read this new whitepaper to learn the fundamentals of IQ in linear-power systems, how to predict behavior in dropout conditions, and maintain minimal disturbance during the load transient response.

Click here to download the whitepaper

Featured Chalk Talk

Nano Pulse Control Clears Issues in the Automotive and Industrial Markets

Sponsored by Mouser Electronics and ROHM Semiconductor

In EV and industrial applications, converting from high voltages on the power side to low voltages on the electronics side poses a big challenge. In order to convert big voltage drops efficiently, you need very narrow pulse widths. In this episode of Chalk Talk, Amelia Dalton chats with Satya Dixit from ROHM about new Nano Pulse Control technology that changes the game in DC to DC conversion.

More information about ROHM Semiconductor BD9V10xMUF Buck Converters