Optimization and the Slotting Problem | Configuration Workgroup

By Peter Illing, Integrity GmbH

The slotting problem is an ailment for many an application engineer, end customer, and sales engineer. There you are, your desk covered with electrical switches for controlling all the circuitry in a building under construction (virtually covered, you haven’t ordered them yet), but who can help you assemble them?

Introduction

Does this ever happen to you? With a catalog in one hand and a request for proposal in the other, you come up with a list of the exact 237 low and medium voltage switches you need to meet all your electrical needs. What you want to do next is place an order for a switchboard with all those switches nicely packed into it, all ready to be hooked up in the home, factory, stadium, or office-complex you are planning to build.

If you are in the business of power distribution and electrical protection, then you already know what comes next: switchboards. Switchboards are actually made up of cubicles – very modular – and those switches you’ve selected need to be fitted into cubicles. This is a necessary part of configuring and manufacturing in this very modular technology ... which doesn’t make it any less hard to do.

You have just been introduced to an example slotting problem, which we will examine in detail in a moment, but first think about this: as a product modeler, slotting problems are all around you. You will find them in the computer industry and in telephone exchanges. I’ll bet you can quickly come up with a few more examples.

Isn’t it interesting that the brief description we started with broke down into two work phases? The first is obviously configuration, combined with catalog selection, which is just a special case of configuration. The second phase is this “slotting” business. Is that configuration, too, or is it something else that is somehow related? How can we best handle it?

These are some of the questions I will be addressing in the course of this article, which has its seed in a question by Lawrence Matusek. After reading Doug Beverage’s article on the IPC Advanced Mode (in the last edition of the CWG Review), he asked:

Is he saying that the IPC Advanced Mode can be used to optimize the value of certain characteristics (similar to what TK Solver, linear programming, etc. can do)? Can you please elaborate on the “optimization” capabilities of IPC Advanced Mode?

This is interesting, because the slotting problem is a very concrete example of “optimization” and it comes up for discussion often by people who might be considered “insiders” at every CWG meeting. It’s not an insider topic, however, because as we said at the beginning, a lot of industries face this problem, either as manufacturers or as customers or both.

Lawrence’s question focuses on a particular goal, to “optimize the value of certain characteristics”. As we ponder how the accomplish that goal, some ideas come to mind.

One is to try out every possible combination, evaluate each in turn, and ultimately pick the best one ... like a chess program trying to pick the next move. This is a pretty brute force sort of thing to do, but computing power is cheap these days.

The other extreme is to do a lot of analysis, then select “the” optimal characteristic value, move on to the next, and so on. This description sounds different from the first ... but only the actual implementation will tell whether it really is.

There may be various in-between approaches, but one thing should be crystal clear by now: we are talking about a very procedural, algorithmic activity. That’s not configuration.

Configuration – as in sales configuration – is a very interactive activity. You don’t repeat, you home in, making the biggest decisions first. A good configurator – working with a good product model – is supposed to tell you what options remain to you for the minor decisions. This is a very declarative activity, which we will address in more detail during the following discussion.

We already know that slotting is frequently part of product configuration, so it should be no surprise that other optimization problems also crop up. Can the IPC do optimization in the manner of linear programming? The simple answer to this question is: no. Nor can it, out of the box, do slotting.

It would be a mistake to stop with these trivial answers, because it is quite possible to write IPC add-ons which do slotting, and it is possible to write add-ons that address other optimization problems. Even though optimization is not configuration, the two are frequently found joined at the hip.

In this article we are going to take a look at (no, we’re only going to superficially scratch the surface of) switchboard configuration; and in that context we’ll have a look at the slotting problem that comes up.

In looking at this example you may find yourself stimulated to think about what functionality is appropriate for a configurator, or for a configuration package. If you have unmet requirements – and who doesn’t – perhaps you will come away from this article with some ideas about how to fulfill them, and with ideas about where you would like the IPC to go.

Placing Switches

Chances are you got into this situation while configuring a switchboard. The next phase in the development of this ailment is a compulsive need to select switchboard cubicles and the making of many attempts to fit the switches into the cubicles. These symptoms are typically accompanied by time pressure, money pressure – “minimize the number of cubicles and try to use the cheaper ones” – and accuracy pressure ... “we had better be able to build it the way you design it”.

Luckily for you, your ailment has been identified, and it has a name: the slotting problem. Fellow-sufferers can be found throughout the electronics industry, at computer manufacturers, and among telephone and mobile telephone makers, just to give a few examples.

The good news is that you can be helped; the slotting problem can be solved. Unfortunately, you are not totally free in your choice of approach. The reality is that you have to work within the limits of the software tools available to you and within the framework of your company’s business.

Of one things we can be quite sure: the customer’s interest is focused almost entirely on the functionality provided by those 237 switches. True, some customers have physical constraints which make them interested in the cubicles from the very beginning, but they are the exception. The majority of their interest is in switches.

One of the things that distinguishes Switchboard manufacturers from Switchboard customers is the fact that customers take delivery. Switchboard manufacturers don’t. They see switchboards take shape in their factories – or on building sites – and they deal every day with the difficulties caused by little irregularities in this so highly modular product.

The biggest thing that distinguishes Switchboard manufacturers from Switchboard customers, however, is directly due to this fact: switches need a mounting.

Switchboard manufacturers need to mount the switches somewhere, and cubicles are the things they mount them in. Since cubicles provide slots for mounting switches, and since switchboards typically contain a number of cubicles, you can almost trivialize a Switchboard as a collection of mountings for switches.

But that’s only an aside. The real issue is that Switchboard manufacturer’s business makes them want to know as early as possible how many and what types of cubicles will be required, so they can give the customer a correct quote, and they want to make the cheapest selection of cubicles, which makes both them and the customer happy.

Even if you are not in the switchboard business, it will come as no surprise to you that configuring switchboards is one heckuva challenge. They usually have a lot of parts and a lot of combinations. Some customers – major contracting and building operations, for example – do their own configuration. The remaining switchboards usually fall to sales engineers to configure. Usually there is a guru somewhere in the environment who understands who everything fits together and the consequence of every decision. The others are all in a little bit over their heads.

Before anyone can actually sit down to configure a switchboard, however, some folks need to look at the assignment from a meta-level and put together an environment for configuring these beasts. This calls for expert, product modelers, well-versed in best practices and familiar with the tools available to them.

Figure 1: A 3-Cubicle Switchboard, with the Cover On.

To Configure a Switchboard

In the world of variant configuration, a switchboard, or a cubicle, or a switch is no more nor less than a KMAT: a configurable material to whose characteristics we assign values and whose bill of materials has positions at which we can instantiate sub-components.

Everything is nicely modular: you can have one cubicle, then add another and another, and you can keep on going until you run out of space or money. You can snap a switch into one of a number of places in a cubicle. Some places are better than others, but we will get to that in a while..

The structure of a switchboard configuration is so obvious – and so common – that we could almost think of it as a design pattern: we have a nested configuration with the overall “thing” at the top (the switchboard), the modules of which it consists at the second level (the cubicles), and the devices that provide the functionality at the third level (the switches). The devices are, again, just modules.

As a product modeler, you serve two masters: the switchboard manufacturer and the customers of the switchboard manufacturer.

In this case, the switchboard maufacturer would like to configure from the top down, because he has to issue production orders for cubicles; the customer, on the other hand, would like to configure from the bottom up, because, if he cares about the cubicles at all, then that is only secondarily.

He cares first about the switches, and the main thing he wants to know about the cubicles, normally, is that he’s getting the number he needs to give the switches a place to sit.

The slotting problem is an ailment because, in order to achieve an excellent solution, you need a way for the customer – or the sales engineer she is working with – to configure bottom up, while creating a configuration result which looks as if it had been configured top down.

The software tools – we’ll be very concrete here and limit ourselves to the Variant Configurator and the SCE - provide very good support when configuration proceeds top down. They don’t help us much at all with bottom up configuration, however, unless we speak the words “advanced mode”. Nevertheless, and for the time being, we will refrain from uttering those words; we’ll see if we can get the job done with compliant mode alone.

A configuration always starts with a root node. There can only ever be one root KMAT in a configuration and every other component in the configuration must be either directly or indirectly attached to that root.

If you think in terms of the sales order which will result, then there is one item in that order which is a switchboard. Everything else needs to be part of it. A switch which is not part of that switchboard is a loose part. It has its own configuration, and it will only ever be friends with that switchboard if there is a kind local engineer who introduces them after the shipment arrives. If the switch is to be configured as part of the switchboard, then it must be attached to it at all times. There is only one root.

A sales order can, of course, have more than one Switchboard, but each Switchboard is the root of its own component hierarchy, all of whose cubicles and switches must at all times be attached to it.

Let’s start our design with a KMAT called Switchboard, which we use as the root of our configuration. Switchboard will have a bill of material with a number of positions whose type is Cubicle. We will also have a KMAT called Cubicle. Finally, our Cubicle KMAT will have a bill of materials with positions for Switches. (Again, there are many kinds of switches, and switches in turn are only a subset of the device types which can be slotted into a Cubicle).

It is worth noting here that a KMAT is a commercial data structure, which is not only configurable, the way we like it, but is useful for accessing plant, inventory, lead time, price, and lots of other good business stuff.

A KMAT is also, however, an object in a class hierarchy. We like to call this a “product object”. If you have ever been involved with object-oriented programming, object-oriented design, or Aristotle (the inventor of classes), then you have an idea about what classes and inheritance are all about.

KMATs are at the bottom of an object hierarchy. You can have 0 or many layers of classes above a KMAT. Since there are many kinds of Cubicles, we might choose to have multiple Cubicle KMATs, with different product numbers, all inheriting from a single Cubicle class. Or we might not, but you should be aware that there is a world of analysis and design here, which deserves a lot of attention ... in another article.

So here we go, let’s configure a switchboard: we start a new configuration with our Switchboard knowledge base, with a Switchboard KMAT as the root. We then proceed as follows: we grab a cubicle, we put some switches in it, we grab the next cubicle, we put some more switches in it, and we continue until we’re done. When we are done, we have a nicely specified, multi-level configuration, ready to be manufactured.

But wait, that isn’t the scenario the customer wanted, because we started with the cubicles, so here we go again: first we grab a switch, then we grab another switch, and we keep going until we have 237 switches, and then ... oops, we get the slotting problem.

We had it in the previous scenario, too, but you didn’t see it, because we forced the sales engineer to do the slotting by hand. And lest we forget, we can’t put those 237 Switches on the desktop while they are waiting for Cubicles; they must be attached to the root – directly or indirectly – at all times.

Otherwise they evaporate in an instant, like a dream.

Before we can address the slotting problem, therefore, we need to find a way to achieve the effect of putting the Switches in a pile on the desktop. Again we are tempted to speak of “advanced mode”, but it is still not time to utter those (potent) words.

Figure 2: The Same Switchboard with the Cover Off.

Of Systems and Solutions

What we need at this point is a new concept. We can’t configure in VC mode without going top down ... except with our new concept. We will configure in phases: first we will gather our switches in a pile. Then we will slot them. And finally, we will have a post-processing phase, which will allow us to generate the nice top down configuration required for downstream processing.

In effect, we will do two drafts. After we are finished slotting, we will – again, in effect – copy our work from the smeared up paper onto clean, new pages, and this brand new configuration is what we will submit as our result.

First we must introduce the “solution” concept. This is a dummy KMAT, which we will never produce. Solution has some very useful properties: it has a bill of materials with a position for a Switchboard, positions for Cubicles, and positions for Switches. It is the desktop we needed all along, and it provides an artificial configuration root. The concept is well known to advanced mode product modelers, but it can even be applied in VC mode. In the course of our exploration we will learn about its limitations.

We start out by selecting and configuring the Switchboard KMAT, a surprise perhaps as you may have been expecting us to start right in with the 237. More than ever, though, the use of the term, solution, reminds us that we are configuring a system and not a quantity of individual Switches. The Switchboard is not only the top level KMAT of our target configuration. It also contains all the global and environment parameters which will apply to all Switches placed inside it.

Some of us have been known to hold forth at great length on the importance of a declarative approach to product modeling ... with good reason, as the point cannot be emphasized enough.

The main job of product modeling is describing relationships. Constraints describe relationships and most constraints should refer to tables which provide the legal values for instantiating those relationships. If our Switchboard is really a system and not just a bag of Cubicles and Switches, then there must be relationships between it and its components, relationships which can be expressed declaratively, relationships which will make the job of configuring the Switches easier, relationships which we must respect if we are to select the right Switches and get the desired system behavior.

A switchboard has basic electrical properties, such as a voltage rating and an interrupt rating, which are specified once and apply to all its components. It can be indoor or outdoor, the physical location of the input can vary, the customer can select aluminum or copper bus bars, there will be regional differences in what is allowed or proscribed, there may be a backup power source or not, and so on. And we can be certain that these environmental parameters (characteristics) are governed by numerous constraints which ensure that we only configure legal combinations.

These switchboard level characteristics will of course apply to each and every Switch. As an example, we’ll show here a constraint we could write to make sure that we only pick Switches whose voltage is appropriate for the Switchboard.

It ensures that Switches whose voltage is less than or equal to that of the Switchboard are the only ones we see:

OBJECTS:	?SOL is_a (300) Solution,
	?SB is_a (300) Switchboard,
	?SW is_a (300) Switch
	CONDITION:	part_of (?SB, ?SOL) and part_of (?SW, ?SOL)
	RESTRICTIONS:	?SW.Voltage GE ?SB.Voltage
	INFERENCES:	?SW.Voltage

Now we are ready to attack the Switches. For the purposes of this discussion we will pretend that there are no subcircuits: all Switches belong to one massive, main circuit.

The easiest scenario to model is the one in which the user tells us at the beginning the number of switches, 237. We can then instantiate them all at once, and then the user goes on to configure them.

But sometimes the User does not know at the outset how many Switches he might need. Since this is so, we might find ourselves needing to be able to instantiate more Switches on the fly. This will require help from PFunctions and it will, frankly, be not only somewhat difficult in the SCE in VC mode, it will be a major challenge in the Variant Configurator with ABAP.

Nevertheless, we proceed.

Since we have a single, flat bill of materials (on Solution), we need some way of linking the Cubicles – we’ll get to those in a minute – to the Switchboard, and the Switches to the Cubicles. We can’t use bill of material positions, yet, because they are all going to be placed next to each other, in parallel positions on the same bill of materials.

The technique is simple enough: we will use characteristics to link the components together. We could give each component an “id” characteristic – Switchboard_ID, Cubicle_ID, and Switch_ID; and then we can give each class a characteristic for the container class it will point to.

Switch will therefore get a Cubicle_ID characteristic, Cubicle will get a Switchboard_ID characteristic, and so on. If we want to point in the other direction, then Cubicle, for example, will need a multiple valued Switch_IDs characteristic.

All the characteristic values are integers, which we must assign, and we must in some way maintain a pool of available ID numbers.

It is possible, with some very skilled Java – or even ABAP – programming to manage these IDs, but we will need to be very, very careful about how this highly procedural functionality interacts with the basically declarative task of interactive sales configuration. Things are starting to look extremely complex.

Nevertheless, we still proceed.

We’ve figured out how to tie all the modular positions together. Now we need to make sure we have enough of them in our maximal BOM.

Let’s see: Switchboard might have anywhere between 1 and 50 Cubicles, so we need to create 50 separate Bill-of-Material Positions, for the Cubicles alone. Cubicles can contain anywhere from 2 to 100 Switches, so we could possibly put create a BOM with 100 different Switch Positions underneath the Cubicle, but then we’ve done away with our “desktop,” the pile of Switches the Customer wants to start with.

The Switches need to be underneath the Switchboard, since that’s how the Customer cares about them. This means we need an additional 5,000 individually configurable Switch Positions on our Switchboard BOM.

And suddenly we realize that things have gotten way, way out of hand. It’s at this point that we give up our attempt to somehow force Variant Configurator to do a job that is too hard for it.

It is time to switch our attention to “Advanced mode,” which will instantly make us more powerful in two very important ways. Firstly, we now have multi-instantiable bill of material positions. We don’t need to guess at the maximum possible number of Cubicles or Switches and provide that many positions. Modeling 100 BOM positions in order to handle 1 – 100 Cubicles is annoying. If you were modeling a mobile telephone network which might have thousands of base stations you would find it absolutely impossible. That problem is now solved.

Furthermore we will find it much easier to instantiate instances as needed at the bill of material positions. We will still use Solution as the top level KMAT and put all the configuration instances on the bill of material of Solution, but we only need one bill of material position for Switchboard, one for Cubicles, and one for Switches. That is a nice, manageable bill of materials.

The other great virtue of Advanced mode is that it gives us ADTs (abstract data types), which are quite simply characteristics which are pointers to other instances. We no longer need to assign each Cubicle an ID and make sure that Switch 57 knows the ID of Cubicle 14. We just assign the object, Cubicle_14, as the value of the My_Cubicle characteristic of Switch_57.

But wait, you ask, how did we get our hands on Cubicle_14? Ah, well that’s slotting, which we are now getting to.

The slotting problem takes its name from computers, which have slots into which cards are placed. Telephone exchanges have drawers with slots for cards. Electrical switchboards, which control the distribution of power to homes, offices, and factories, are particularly illustrative, because they can show us this problem in several dimensions.

Switchboards are made up of cubicles, which are interchangeable, and a switchboard can be infinitely extended by adding more cubicles. How easy the job of switchboard configuration would be if these two statements were completely true.

In fact, the number of cubicles is restricted by factors such as the available physical space and the cost of the cubicles. The selection of cubicles is complicated by the fact that there are various cubicle types, with differences in the types and numbers of switches that can be mounted in them.

What we want, in other words, is that the system figures out for us the optimal number of Cubicles, accounting for available space, cost, and all sorts of other factors.

And that brings us immediately to the realization that what we’ve been describing all along as “the slotting of Switches in Cubicles” is nothing more than an optimization problem; and similarly, to the realization that we will encounter the very same issues in other industries where the slotting problem comes up.

The product modeling task – again – is to optimize the use of cubicles, using fewer if possible, using preferred (read: less expensive) ones where possible.

Up to this point, the configuration environment was very declarative. We have set characteristic values by choosing from the legal values presented to us by the SCE. Regardless of which characteristics we started with, in other words, the list of values of the later characteristics was restricted to contain only those values still allowed by our earlier choices. Here is an example of the types of constraints which have guided us in configuring switches:

OBJECTS:	?SW is_a (300) Switch
	RESTRICTIONS:	TABLE SWITCH_VOLT_IR (
	INTERRUPT_RATING = ?SW.domain INTERRUPT_RATING,
	VOLTAGE          = ?SW.domain VOLTAGE,
	SWITCH_TYPE      = ?SW.domain SWITCH_TYPE)
	INFERENCES:	?SW.domain INTERRUPT_RATING,
	?SW.domain VOLTAGE,
	?SW.domain SWITCH_TYPE.

This is a trivial, little constraint, which says that the interrupt rating, the voltage, and the switch type are mutually dependent on one another. There is a table which gives the the domain of legal combinations of values. And the constraints says that no matter which one you set first, your choices for the others will be restricted.

We like to write lots of these trivial, little constraints. it is possible to achieve brilliant results with these (apparently) trivial constraints. Their brilliance lies in their simplicity, because you “declare” the relationships you want to enforce, and you say absolutely nothing about “how” this behavior is to be implemented.

Slotting, Done Right

As we move on to slotting, we move from a declarative to a procedural world. The configuration we have done up to this point was not algorithmic, but slotting is. Here is a procedure for slotting switches in cubicles.

Selection:
Out of the pile of switches in front of us we need to select the next switch to be slotted. To do this we will apply an algorithm which will look at all the switches and decide which one to select. In the case of switchboards, we know that we should place the bigger (in amperage) first, because it is easier to fit the smaller switches in afterwards, so we might start by sorting the switches according to amperage. Our algorithm ultimately returns a switch and we move on to the next step.
Find or create a cubicle:

Of the available cubicles, find one that has room for the switch we are currently trying to place. If there are multiple cubicles available, apply an algorithm to select the best cubicle for the current switch. If there is no cubicle with room, create a new cubicle. Since there are various cubicle types, each time we create a new cubicle we have another choice to make about the cubicle type. Obviously there are opportunities for backtracking here, too, and the warnings about backtracking and its effect on performance apply here, too.
Find or create a cubicle:

Of the available cubicles, find one that has room for the switch we are currently trying to place. If there are multiple cubicles available, apply an algorithm to select the best cubicle for the current switch. If there is no cubicle with room, create a new cubicle. Since there are various cubicle types, each time we create a new cubicle we have another choice to make about the cubicle type. Obviously there are opportunities for backtracking here, too, and the warnings about backtracking and its effect on performance apply here, too.

Our experience suggests that optimal results are not achieved by allowing an algorithm to run for nearly infinite amounts of time, mindlessly trying out nearly infinite combinations. Rather, it is better to put the time and intellectual work into analyzing the problem space.

When we analyzed the problem of optimally placing switches into cubicles at one switchboard manufacturer, for example, we found that it was better to have the slotting software first analyze the set of switches, calculating the number of and types of cubicles which would be required. The next phase of slotting was then to fill all the cubicles in parallel from bottom to top (or sometimes from top to bottom). On rare occasions, it could happen that because of packing limitations one extra cubicle would be needed, and it would be better to accept that extra cubicle than to attempt to backtrack in the (probably futile) hope of optimizing it away.

Limitations

The slotting procedure we have just described cannot be implemented using the dependencies available for declarative knowledge base development for the SCE, but it can be implemented as an add-on. The SCE provides a host of Java APIs for accessing and modifiying the configuration. The dependency language itself allows us to call PFunctions, which are Java methods which must conform to certain conventions, but which we can bend to our needs. Finally, there is (almost) always, a UI, which provides us with a starting point for triggering any program code we like. With these tools we can augment the SCE with all the add-ons we want.

Way back in the introduction we said that the SCE does not support optimization – according to Lawrence’s definition. The reason it does not and cannot is because it is focused on declarative product modeling (except when it falls into the wrong hands).

Optimization is procedural by its very nature. You achieve it by trying out various combinations, evaluating them, and picking the best. Or, you can optimize by carrying out a a series of analyses, which is about as algorithmic as you can get.

We have just gone through an excercise in slotting, which is a very important problem in the configuration world. Lo and behold! We discovered that slotting is also very procedural and that we needed to write some add-ons to the SCE in order to succeed at it.

Perhaps we will find that some of what applies to the slotting problem specifically also applies to optimization problems in general.

What, exactly, is a Configurator?

It is worth thinking about the definition of a configurator: what is it? what do we expect one to do? We have been discussing interactive, sales configuration, and we will assert over and over again that this is a declarative world.

It is a world in which there is a knowledge base of (class) product objects, arranged in a class hierarchy, and described by their characteristics. There are relationships between the product objects and their characteristics, relationships which in many cases are best described by tables, in other cases by simple math. Constraints provide us with the mechanism for enforcing and finding legal combinations of characteristic values.

It is a world in which the user creates a configuration, which consists of (instance) product objects, by setting the values of their characteristics within the limitations imposed by relationships specified in the knowledge base.

This is a passive world. It does not offer up configurations, but rather provides a framework within which a user can create configurations. A declarative knowledge base answers questions. It guides the user, depending on what the product modeler has done, either by preventing illegal combinations or by flagging them when they crop up; but first the user has to ask the questions.

We cannot ask this sort of system to suddenly become active and generate an optimized slotting solution for us. This task requires a separate piece of functionality, which in the world of the SCE can be provided as a PFunction, which is implemented in Java, or even as an unvarnished Java method which is called by the user interface as a result of selecting the “Run Slotting” menu item.

It is worth asking whether slotting is generic enough that we might expect this sort of add-on to be part of the package which makes up a configurator such as the SCE.

What we are absolutely certain of is that the slotting algorithm cannot be allowed to operate independently of the declarative configuration world. Although we wouldn’t expect constraints to loop through the switches and attempt to place them in cubicles, we can very well expect that our product modeler has written constraints which will check whether Switch_53 is compatible with Cubicle_14. As the slotting algorithm attempts to find a cubicle for Switch_53, it must respect any constraints that apply, and it may well trigger others.

Suppose that Switch has an Amperage characteristic. Then we might write this constraint:

	OBJECTS:   ?SW is_a (300) Switch,
	?CU is_a(300) Cubicle
	CONDITION:	?SW.MY_CUBICLE = ?CU
	RESTRICTIONS: TABLE CU_EXTRA_DEPTH (
	AMPERAGE    = ?SW.domain AMPERAGE,
	EXTRA_DEPTH = ?CU.domain EXTRA_DEPTH)
	INFERENCES:   ?CU.domain EXTRA_DEPTH
	?SW.domain AMPERAGE.

Note the two lines in the INFERENCES section. With only the first line, we would allow a Switch to influence how much extra depth a cubicle gets. Given the way we are going to fill the cubicles, that is probably all we want. To make the constraint more illustrative we have added the second inference, which says that, whatever the domain of possible values for extra depth for a cubicle is at any time, they restrict the possible amperages for any additional Switch to be placed in the Cubicle, and thus indirectly they restrict as well the possible Switches which can still be added to the Cubicle.

Cubicle will need a characteristic to keep track of the totals provided by its contained Switches: total amperage, total height, etc. We could write rules (like constraints but subtly different) to maintain the totals. This is a choice, though, and for performance reasons we might find ourselves encouraged to use procedural, Java code, to do this bookkeeping.

The same applies to evaluation of the configuration. We could use constraints to evaluate the quality of the slotting. There is, however, some instinct that says that constraints should evaluate correctness, while procedures – again, code – should carry out statistical evaluations, e.g. what is the fill percentage of a Cubicle. It is worth stating, however, that this instinct is based on experience with performance. Constraints can certainly perform calculations, as long as they are declarative and not algorithmic, e.g.

	RESTRICTIONS: ?CU.PERCENT_FILLED =
	?CU.NUMBER_OF_SWITCHES / ?CU.CAPACITY

This dependency snippet begs the question: who is keeping track of the NUMBER_OF_SWITCHES. One could well imagine constraint syntax that would provide the modeler a declarative way to do this, e.g.

		?CU.NUMBER_OF_SWITCHES = ?CU.count_of MY_SWITCHES

This is, of course, not real syntax, just an idea. The activity is, of course, very procedural, but then so is everything else we ask the computer to do. If we have a way to state what we want as a relationship, then it is declarative, because the language we are using provides us declarative syntax for that relationship.

Moving it Downstream

The configuration we wind up with cannot, of course, be processed as part of a sales order in SAP SD or CRM. The bill of materials is all wrong. We don’t sell a product called “Solution.” We sell, instead, a product called “Switchboard.”

The consequence is that this scenario needs a postprocessing step, which copies the configuration contents into a new configuration, with a Switchboard at the root. Since we now know exactly how many and which kinds of Cubicles we require,it is easy for the postprocessing step to go top down, in the constructive manner, to put together a configuration which can be processed as part of a sales order.

This requirement for a second, postprocessing, phase, is not really a result of slotting or optimization. It is because the downstream processes cannot – yet – handle that strange but powerful thing we’ve already alluded to as ”advanced mode” (see Doug Beverage’s article in the previous issue).

There are various possible results of this postprocessing phase which can then run through SAP’s downstream processes. There are also business scenarios where the advanced mode configuration solution is not a collection of ready-to-go sales order line items, but rather an input to another business process which will, in fact, output a sales order.

The point of this section is not so much to address sales order processing issues as to draw your attention to the fact that there are issues with handling advanced mode or “solution”-based configurations.

The point is also that slotting – and by extension optimization – tests the borders of the IPC, because it forces us to use non-vanilla techniques; and as a consequence we cannot assume vanilla sales order processing.

Conclusion

Because slotting is hard and complex, it is easier to find a solution than to find a good solution. Companies that do slotting care a lot about finding optimized solutions – as do their customers – because better solutions save everybody money. Try to come up with a few businesses that do slotting ... it won’t take you very long. You will see that a lot of them – like switchboard manufacturers – are in mature markets, where small differences in price determine sales; and where small differences in product cost determine whether there will be a profit margin.

These businesses do have opportunities for large profit margins, namely when they sell large systems, but only if they can configure accurately. Otherwise they will overbid and lose the contract, or underbid and wish they had lost the contract.

Amongst the membership of the CWG there are quite a few who suffer from the slotting problem. If this article has given you a few ideas and helped you to see how you can handle it better, that would be great.

The slotting problem gave us a way of seeing where optimization issues might crop up during interactive configuration. The IPC as delivered is not a tool that applies linear programming techniques to try out various characteristic settings and come up with the best. Suppose you had a Prolog-based configurator that made it easy to do optimization via backtracking. It is still not all clear that you would want an interactive, sales configurator to do that, because you might wait a long time for an answer.

We know that declarative solutions are the way to go in configuration, because they are powerful and elegant and maintainable; but we also know that some tasks simply are procedural. There are jobs which require master modelers and jobs that require master hackers. The division of labor between the two is in part inherent in the slotting problem.

Characteristic optimization is not a core capability of an interactive configurator, because this sort of optimization is not appropriate in an interactive environment, but it is a requirement that turns up in association with a lot of configuration environments.

One example is the configuration of large drives, which requires the adjustment of parameters – characteristic values – to achieve the desired performance curves. This task is very definitely part of the assignment of configuring a motor, and companies write add-ons to do this task, usually as some kind of math library. The IPC allows addons to be implemented as PFunctions; or as Java methods which are part of the UI; either of which may make calls to external libraries.

Let’s summarize now what we’ve done:

We have answered the simple question - can do the IPC do characteristic optimization – with “no”, but what we have seen in our short survey is that at least one specific optimization problem – namely slotting – can very well be solved in an IPC-based environment, by using the IPC to provide the configuration framework, by using the IPC to provide support for slotting, and by writing an external bolt-on to fit into that framework.

Last but not least, we have learned that we can analyze the configuration space and divide it into several problem classes; complex ones like slotting are simply easier to handle with the extra power of advanced mode. We have learned that advanced mode has downstream issues, but again, there are techniques for working around those issues.

The Author

Peter Illing is a product configuration specialist and IPC gym rat of long standing. He learned a lot about switchboards – some of which seeped through into his article – while wearing a Siemens stamp on his forehead in Germany, Canada, and the US.

Peter was trained in artificial intelligence and spent years working on intelligent systems with KEE, the cadillac or expert systems shells.

In his next life, he became a born-again product modeler, whose favorite theme is that doing product modeling right is a huge step in the direction of getting your business right.

As if to prove his versatility and to display his hands-on approach, however, he is currently doing pricing with the IPC for HP.

Peter is a Director of Integrity GmbH - product modeling central, as we like to call it - with one eye on the Semantic Web and his nose into the wind of the future.

On the weekends, he can be found riding his horse, Rusty, through the nearby fields and forests.

Contact:

Peter Illing
Integrity GmbH
tel: +49 172 89 59 250
email: peter.illing@integrity.vc