Knowledge Based Engineering

I was fond of saying, with regard to Rules Based Engineering (RBE) for a while, “If you’re not on the bus, you’re going to be under the bus”. By that I guess I meant that I thought RBE was going to be a big thing. It might be a big thing, for certain industries or specific product lines, For products that fit the Design To Order (DTO) scenario, it represents a huge savings in manpower and turn around time for quotes on orders, and even real engineering time. RBE might be considered an early precursor to the AI cross Design space.

When we talk about “SolidWorks needs a system” as we have in recent blog posts, ultimately, this is the kind of thing we are talking about. Not only do you theoretically have to make a model that can be changed predictably, but it has to actually change correctly for the range of values nd parameters you prescribe. RBE is kind of the ultimate extension of the idea of skeleton modeling. This is the time when your model and the functional design intent is an actual valuable product. The nice thing about it is that the functional range over which your model needs to work is often more tightly defined.

RBE has multiple levels. I don’t really intend to endorse any particular products here, these specific products are mentioned just because they are the ones I have experience with. Full blown RBE is really embodied by a product like Rule Stream, which is now owned by Siemens. It  takes a programmer and a CAD modeler, along with some input from sales and marketing, manufacturing, and a fair bit of time to set it up for an individual product line. I took training on this a long time ago now (probably 15-16 years), and was struck by the potential, although back then it seemed like there was a lot of technical input required to make it work. Your model had to work, your programming has to work, and your programming has to work with your model. On top of that, you have to be able t produce programmatically most everything the customer wants.

Setting up a model for RBE is the ultimate in best practice rules. Following the rules exactly is one of the factors in making sure the scenario works properly. There are a couple of schools of thought in setting up an RBE model, and I’m sure which you choose has a lot to do with which side of the fence you come from – programming or modeling.

If you come from the modeling side, you will probably want to put the intelligence in the model, in which case you may have equations and links all over the product. Shared sketches, in-context, maybe even master model ideas. You know you can drive all the changes with SolidWorks functionality, so you will want to do that.

If you come from the programming side, you will want to control everything with the tools you trust – programming tools. These people usually insist that you remove all relationships within the CAD model so you can drive everything programmatically. In fact, the providers of systems like Rule Stream often recommend a specific system for modeling parts and assemblies that maximizes programming control, and likely eliminates design intent in the CAD data.

This often sets up a huge conflict between the power CAD users who this would require to model counter to all of their training and instincts – just model dumb individual parts, and maybe not even any assemblies. Unfortunately, this is what the programmers need in order to have confidence in how they drive the product geometry. If you have a single person doing the programming and the models, this might be the best scenario, and probably actually happens from time to time.

The next level down is something like DriveWorks. DriveWorks I think is actually considered a “configurator”. It will do things it is preprogrammed to do, where Rule Stream is more of a programming language and environment. Think of DriveWorks as a very nice spreadsheet that you don’t have to set up yourself. It’s a nice front end to configuring a range of products. The modeling style required by DriveWorks is more forgiving, I think, and more in tune with the way that SolidWorks users are used to working.

Where do you draw the line between products like Rule Stream and DriveWorks? One easy way to do it is money. How much money are you willing to put into developing this system? Just as a rough estimate, if the number is say, $X0,000 or less, I’d recommend DriveWorks for you. Tools like Rule Stream probably take more in the ballpark of $250,000 to implement for your first product line. Subsequent model lines may take less, where you won’t require as much consulting/training assistance. Both ways, you will probably have to remodel any existing CAD data specifically for the process.

You can also do this kind of work with just a simple Excel link to SolidWorks or Solid Edge (while Rule Stream I think will work with Solid Edge, I don’t believe DriveWorks has a “DriveEdge” product yet). Excel has a lot of great functionality for decision making, if/then sort of stuff, or somewhat more complex.

The final level of what is available is a custom configurator. I’ve seen more companies go this route than you might expect. All you need is one reasonably competent programmer who understands how to link in to and control SolidWorks models, and a good plan for your design intent.

A long time ago, I worked at Goulds Pumps as an intern for a few months. I worked in the area with application engineers who would take information from customers, and help them select a particular pump for their application. Size a motor, number of stages, input and output specs, material to be pumped, explosion proof? Sealing requirements? Efficiency? Weight? Space? Mounting? Answers to some of these questions required an entirely different model line, while others, like the number of stages or drive type might just require a different number of parts, or swapping out one casing for another.

These are the kinds of things that a fancy configurator can do for you. Maybe a magnetic drive requires a certain material housing, which might be incompatible with certain fluids. You know those kinds of things that only some people in your office know? That so-called tribal knowledge? That’s the stuff that is hard to capture, but is really essential to specifying your product for actual use conditions. People are often protective of that kind of information if only because it may be the only value they offer for their employment.

There is no question that automation does replace humans. That is, after all, what it is meant to do. Employers need to be smart about how much of the company’s treasure trove of product data and overall knowledge they try to replace with automation, however. These people are probably right to protect that information and thus their job, but you need to find a way to make them part of the process – get them on the bus so they don’t fall under it. Folks of a certain age, as they say, tend to fall into this group, and being nearly that age myself, I can relate to the unfairness of guarding the company secret knowledge, then having some soulless computer punk reduce your contribution to the company to a couple lines of code. Wise product development managers find a way to incorporate these people. You need a range of skills and knowledge in your department. Punk ass kids will have to relearn all of the lessons more experienced folks have learned through mistakes. Programming is not a shortcut to wisdom.

The process that John Stoltzfus described seems like it was perfectly positioned for configurable design. He is right about the goal of his process: To make models that can be changed in several parameters to produce new products. Formalized RBE hard codes the range of what can be done, although it may result in thousands of permutations. Still, if you have unanticipated changes, it takes a human to drive the process.