| Most OR problems I've seen attempt to optimize allocation of a fixed
set of objects in a static environment. Here you've got a dynamic
environment. What's optimal on January may not bear any resemblance to
what's optimal in June. Classic OR would think nothing of rearranging
the objects. (Alternatively you could minimize the cost of rearranging
objects but not be able to control the overall cost of providing service).
This sounds like something a Genetic Algorithm could be built around.
Take the current configuration and evolve it over time according to
a variety of strategems and measure the costs. This would even permit
you to allow for changes in cost as time progresses; I'm sure a 4:1
compressor will be a lot cheaper in 5 years while labor costs might
rise over the same period. You'd want to account for that, too.
Since you project on a month-by-month basis it would seem that you might
recongfigure on a month-by-month basis. I.e., in August 1993 you upgrade
area 19 from a 4:1 to 2 of the 3:1 compressors, then in January 1994
upgrade one of the 3:1 compressors to a 4:1. There are costs associated
with each of these upgrades, and it might be that the right decision
would be to simply add in a 3:1 compressor in August 1993; having
unused capacity might be cheaper than having to upgrade twice.
It's an interesting problem.
John
|
| Eddie,
I haven't worked on this allocation problem, but I have worked in OR,
both with and without expert systems. (This is the explanation for my
VAXMAIL personal name, by the way.) Simplifying greatly, there are essentially
two reasons why an expert systems could be relevant for this kind of problem.
(1) multiple objective functions
It's rare that a single objective function can capture *all* the
desirable criteria for a design. We may want to minimize cost, but also
there are maybe characteristics (such as built-in redundance, upgradability,
adaptability in the face of unknown future demand, maintainability) which can be
well expressed in an rule-based form, that interacts with the main part of the
system.
(2) combinatorial complexity
Cornflakes settle down in a packet, but no-one needs to worry about
exactly how each cornflake will interact with it's neighbours. So it is in
many design problems: there is a lot of *irrelevant* complexity. With a
rule-based approach, we can focus immediately on the important features of
the design (that N cornflakes *will* fit into a rectangular box, with a certain
amount of room to spare) and later sort out the tedious details.
In the absence of more information about the system, I can't say for
sure why a network minimal cost model is regarded as inappropriate. It doesn't
surprise me at all. It sounds as if they are building their network as they
go along, which is much more complicated than finding the best flow through an
existing network. If you try to model each possible allocation of equipment
to a link by a different edge in the network, then you are rapidly going to
enter a combinatorially explosive situation. Rather, it sounds as if there is
a *design* element to the application, which is best treated by a rule-based
system (I'd say a forward-chaining system with objects is probably the answer.)
The second thing about this problem which makes me wary is the temporal
dependence. What's the interaction between next month's design and next
year's design. How do you integrate across time to get the total payoff?
Do we want lots of profit tomorrow at the cost of big problems three years from
now?
The third thing which concerns me is the question of uncertainty. Do
we take the expected demand as a given? Or do we need what-if analysis to look
at the impact if our market assumptions turn out to be wrong? Very often, a
rule-based approach is appropriate here.
There may also be telecom regulations or business objectives that we
don't know about, which would radically affect the solution method.
Anyway, that's all of the top of my head. If you want more
information, and if there's money for Digital at stake here, then please get in
touch.
Cheers,
Andrew.
|