[From Bill Powers (980923.0935 MDT)]
Bob Eberlein (19980922.1500 EDT)--
You were right that the model I sent was a pretty abstract one. I have taken
the model you sent back an changed some things - many of which are just
cosmetic. The model I am attaching is not quite the same, but it is similar.
It seems to behave the same, which is the bottom line, I guess.
The cosmetic changes relate to the use of flows that flow into stocks -
sort of
standard system dynamics notation. You had some flows that were just
added up
to another value.
I don't quite understand what you're modeling in some of these details. For
example, you have a basic production flow, which enters Goods Produced. But
a fraction, 10%, of the production flow also goes into Goods with
Undiscovered Defects, which actually duplicates some of the goods in Goods
Produced. So we have the same physical objects appearing in two different
parts of the model at the same time.
I think I understand what you're getting at here: the inspection process
that declares some goods as defective doesn't discover all bad goods, so in
the final output some of the goods still carry undiscovered defects and are
sold that way. But I think it's counterintuitive to allow the same goods to
appear twice in the diagram at the same time, when physically they can only
exist once. How do you coordinate the two separate pathways so the same
goods are treated in EXACTLY the same way, as they must be? There has to be
a way to express the condition you're trying to describe without such risky
duplications.
I think what we need is something like this:
goods produced ---> stockpile of goods ---> fraction actually bad ---->
fraction discovered to be bad ---> sent for reworking ---> etc.
In this way, we have a given item appearing only once at any stage of the
process. The items accepted as good (but actually bad) during inspection
are "undiscovered defects" and remain in the output. Only the _discovered_
defects are sent for reworking, where they can be discarded as hopeless or
returned for re-inspection. So an item with an undiscovered defect on the
first pass through the process ends up in the output bin and is sold.
The more interesting thing is the whole concept of undiscovered defects.
These
are things that exist in nature but, because they are undetected, cannot be
acted upon. This model, like the original, has the property that things may
lurk that would require you to go back and do more work. If you make gain
bigger you can get this to happen in a significant way (you need to make
SAVEPER=TIME STEP to really see it).
If you do that, you're in danger of inducing artifacts, oscillations that
are caused by using too large a value of dt (TIME STEP) for the loop gain
(or vice versa -- too large a loop gain for the existing value of dt). No
phenomenon that depends on the size of the time step can be considered
real, in the sense that it's a proper aspect of the simulation. What is
required is a small enough value of dt that reducing it further makes no
discernible difference in the behavior of the model. Then you know that
there are no artifacts due to trying to represent a continuous process on a
digital machine.
Another thing to watch out for is the existence of two or more integrations
in a closed loop. This can easily lead to instabilities even though the
feedback is nominally negative. Of course if the real system is designed
that way, it _will_ be prone to instabilities, so you should model it that
way. But if you're looking for a workable design, you want to keep the
"level" variables down to one per closed loop.
This is why I stayed with auxiliary variables in my model through the
production and inspection phases -- effectively saying that inspection was
happening in real time. Each auxiliary variable depended on a rate
variable, and so still represented a rate or flow. The only actual
integrations occured in the places where the final output was being
accumulated, and where goods to be reworked accumulated. I think that if
you terminate every flow with a Level variable, from which the next flow
departs, you run the risk of producing oscillations by having too many
integrations in one loop. Again, this is OK if there are actually these
accumulations appearing in the real system, but if you're designing a
system to work as well as possible they have to be treated with care.
In this reformulation two interesting things jump out. The first is "defect
discovery," where does this come from?
It happens either during inspection, or when the customer returns the goods
under warrantee. Otherwise, it seems to me that the defects simply go
undiscovered, forever.
There is a mechanical formula for it
but it is not clear what this means. In parallel to this is "rate of fixing"
- this is more of a conscious decision since there is a tradeoff between
fixing
and building. I did not put that tradeoff in - capacity still only impact
rate
of production - but we can. When we do we need to decide how to allocate the
resources between the two activities. Is this another control system?
Yes, I think it is. After all, MOST of the processes in this system have to
be carried out by control systems -- workers and managers. We're just
taking some of them for granted, such as the production line.
Somebody must perceive the rate at which good items are being produced and
the rate at which defects are being discovered, and try to allocate enough
manpower to repairing defective items to keep the backlog from increasing
"too much", whatever that is. The more manpower that is allocated to
repairing defects, the lower the productive capacity is. In effect, the
time to repair depends on the number of people assigned to repairing, while
the rate of production of defective (discovered) goods depends on the
number of people working the production line.
One way to handle the repair rate problem is to set a reference level
(goal) for the repair backlog. This could be a one-way control system: the
backlog is not to exceed N items, and if it does, enough workers are
allocated to repairing items to keep the backlog close to N. If the backlog
falls below N, workers are sent back to production, with some minimum
number staying in the repair department.
Do you want to take the next hack, or shall I?
Best,
Bill P.