Manufacturing Control Systems

This forum contains all archives from the SD Mailing list (go to http://www.systemdynamics.org/forum/ for more information). This is here as a read-only resource, please post any SD related questions to the SD Discussion forum.
"Jay W. Forrester"
Senior Member
Posts: 63
Joined: Fri Mar 29, 2002 3:39 am

Manufacturing Control Systems

Post by "Jay W. Forrester" »

Perhaps the information below will be useful.

Information on System Dynamics
Jay W. Forrester
Information revised
October 6, 2001

System Dynamics Bibliography:

To order the system dynamics bibliography of over 4100 entries,
specify IBM type PC, or Macintosh

Send $35 in US$ drawn on a US bank to:

System Dynamics Society
Roberta Spencer, Executive Director
Milne 300--Rockefeller College
State University at Albany
Albany, NY 12222 USA

tel: 1-518-442-3865Ý
fax: 518-442-3398
email:
System.Dynamics@albany.edu

Three formats are available:

1. For Endnote, a very effective bibliography software available for
either Macintosh or PC from:

Niles & Associates, Inc
800 Jones St.
Berkeley, CA 94710 USA

Tel: 510-559-8592
Fax: 510-559-8683
Internet: nilesinc@well.sf.ca.us

I use Endnote and recommend it and use it to search for the references.

2. An exported version with field delimiters that presumably can be
loaded into some other kind of database.

3. A listing that one can look at in a word processor and do some
simple finding operations.

The bibliography can also be downloaded from:
http://www.vensim.com/sdmail/sdbib.html
-----------------------------------------------

Membership in the System Dynamics Society and subscription to the
System Dynamics Review are US$90 per year for regular members
and US$45 for students.
Send application to:

Sarah Stevens
Journals Administration Department
John Wiley & Sons Ltd
1 Oldlands Way
Bognor Regis
West Sussex PO22 9SA
United Kingdom

or

Subscription Department C
John Wiley & Sons Inc.
605 Third Avenue, New York,
NY 10158-0012, USA

or
contact the Society office

To contact the office of the System Dynamics Society and to order
copies of the "Beer Game" group simulation exercise: tel:
1-518-442-3865
fax: 518-442-3398
email: System.Dynamics@albany.edu


-------------------------------------
There is a system dynamics discussion group on the Internet. To join,
send email to: majordomo@world.std.com In the body of the message,
enter the following two lines:

Subscribe system-dynamics
End

------------------------------------
The next annual international conference of the System Dynamics
Society will be at the University of Oxford, England, July 25-29,
2004 . Write to the System Dynamics Society,

System Dynamics Society
Roberta Spencer, Executive Director
Milne 300--Rockefeller College
State University at Albany
Albany, NY 12222 USA
tel: 1-518-442-3865Ý
fax: 518-442-3398
email: System.Dynamics@albany.edu
----------------------------------------

The publisher for books in the following block has changed from
Productivity Press to Pegasus Communications.

Pegasus Communications, Inc.
One Moody Street
Waltham, MA 02453-5339

Within the U.S
tel:1-800-272-0945
fax: 1-800-701-7083
Outside the U.S.
tel: 781-398-9700
fax: 781-894-7175
Web page: www.pegasuscom.com

Alfeld, Louis Edward, and Alan K. Graham. 1976. Introduction to Urban
Dynamics. Waltham, MA: Pegasus Communications. 333 pp.

Forrester, Jay W. 1961. Industrial Dynamics. Waltham, MA: Pegasus
Communications. 464 pp.

Forrester, Jay W. 1968. Principles of Systems. (2nd ed.). Waltham,
MA: Pegasus Communications. 391 pp.

Forrester, Jay W. 1969. Urban Dynamics. Waltham, MA: Pegasus
Communications. 285 pp.

Forrester, Jay W. 1971. World Dynamics. (1973 second ed.). Waltham,
MA: Pegasus Communications. 144 pp. Second edition has an added
chapter on physical vs. social limits.

Forrester, Jay W. 1975. Collected Papers of Jay W. Forrester.
Waltham, MA: Pegasus Communications. 284 pp .

Forrester, Nathan B. 1973. The Life Cycle of Economic Development.
Waltham, MA: Pegasus Communications. 194 pp.

Goodman, Michael R. 1974. Study Notes in System Dynamics. Waltham,
MA: Pegasus Communications. 388 pp.

Lyneis, James M. 1980. Corporate Planning and Policy Design: A System
Dynamics Approach. Waltham, MA: Pegasus Communications. 520 pp.

Mass, Nathaniel J., ed., 1974. Readings in Urban Dynamics: Volume I,
Waltham, MA: Pegasus Communications, 303 pp.

Mass, Nathaniel J. 1975. Economic Cycles: An Analysis of Underlying
Causes. Waltham, MA: Pegasus Communications. 185 pp.

Meadows, Dennis L. 1970. Dynamics of Commodity Production Cycles.
Waltham, MA: Pegasus Communications. 104 pp.

Meadows, Dennis L., et al. 1974. Dynamics of Growth in a Finite
World. Waltham, MA: Pegasus Communications. 637 pp.

Meadows, Dennis L., and Donella H. Meadows, ed., 1973. Toward Global
Equilibrium: Collected Papers, Waltham, MA: Pegasus Communications,
358 pp.

Morecroft, John D. W., and John D. Sterman, ed., (1994). Modeling for
Learning Organizations, Waltham, MA: Pegasus Communications, 400 pp.

Randers, Jorgen, ed., 1980. Elements of the System Dynamics Method,
Waltham, MA: Pegasus Communications, 488 pp.

Richardson, George P., and Alexander L. Pugh III. 1981. Introduction
to System Dynamics Modeling with DYNAMO. Waltham, MA: Pegasus
Communications. 413 pp.

Roberts, Edward B. 1978. Managerial Applications of System Dynamics.
Waltham, MA: Pegasus Communications. 562 pp.

Roberts, Nancy, David Andersen, Ralph Deal, Michael Garet, William
Shaffer. 1983. Introduction to Computer Simulation: A System Dynamics
Modeling Approach. Waltham, MA: Pegasus Communications, 562 pages .

Schroeder, Walter W., III, Robert E. Sweeney, and Louis Edward
Alfeld, ed., 1975. Readings in Urban Dynamics: Volume 2, Waltham, MA:
Pegasus Communications, 305 pp.

---------------------------------------------------
Books from other publishers include:

Coyle, R. G., 1996. System Dynamics Modelling--A Practical Approach,
London: Chapman & Hall. 413 pp.

Fisher, Diana. M. (2001). Lessons in High School Mathematics: A
Dynamic Approach. Hanover, NH, High Performance Systems, Inc.

Ford, Andrew, 1999. Modeling the Environment: An Introduction to
System Dynamics Modeling of Environmental Systems, Washington, D.C.:
Island Press. 415 pp.

Mandinach, Ellen B., and Hugh F. Cline, 1994. Classroom Dynamics:
Implementing a Technology-Based Learning Environment, Hillsdale, NJ:
Lawrence Erlbaum Associates. 211 pp.

Richardson, George P., 1991. Feedback Thought in Social Science and
Systems Theory, Waltham, MA, Pegasus Communications. 374 pp.

Richardson, George P., 1996. Modelling for Management: Simulation in
Support of Systems Thinking, Brookfield, Vt.: Dartmouth Publishing.
493 & 447 pp.

Sterman, John D. (2000). Business Dynamics: Systems Thinking and
Modeling for a Complex World. New York: Irwin: McGraw-Hill. 982 pp.

----------------------------------
A self-study guide to system dynamics, called "Road Maps," is
available for downloading from:

http://sysdyn.clexchange.org

or in paper copy from:

Creative Learning Exchange
Ms. Lees Stuntz, Director
1 Keefe Road
Acton, MA 01720, USA
tel: 1-508-287-0070
fax: 1-508-287-0080
email: stuntzln@tiac.net
------------------------------------------------

For those wanting information on introducing system dynamics in
kindergarten through 12th grade education:

1. The Creative Learning Exchange is a nonprofit foundation that acts
as a clearinghouse to provide information on system dynamics in
precollege education and to help teachers share their experiences.
They can be reached at:

Creative Learning Exchange
Ms. Lees Stuntz, Director
1 Keefe Road
Acton, MA 01720, USA
tel: 1-978-287-0070
fax: 1-978-287-0080
email: stuntzln@tiac.net
web: http://www.clexchange.org

2. The System Dynamics in Education Project at MIT has transferred
its web page to the Creative Learning Exchange at
http://sysdyn.clexchange.org

3. An Internet discussion group on K-12 issues related to system
dynamics can be joined:
Contact: StuntzLN@CLEXCHANGE.ORG
To subscribe,
Please provide the following information:
First Name:
Last Name:
E-mail:
Title:
Organization:
Address:
City:
State or Province:
ZIP or Postal Code:
Country:
Day Phone Number:
Evening Phone Number:
Fax Number:

5. The summer 93 issue of the System Dynamics Review, vol 9 no. 2,
was a special issue on "Systems thinking in education" It contains
many interesting pieces including reports from the field by teachers.

----------------------------------------------

There are now three good software packages for system dynamics. You
can request information:
--------------------------------------------
STELLA for Macintosh or PC:

High Performance Systems
45 Lyme Road, Suite #300
Hanover, NH 03755, USA

Phone: 1-603-643-9636 customer support
tel: 1-800-332-1202 product inquiries
fax: 1-603-643-9502
email: support@hps-inc.com
http://www.hps-inc.com/

--------------------------------------
Powersim for PC:

Powersim Corporation
1175 Herndon Parkway Suite 600
Herndon, VA 20170
Phone: (703) 481-1270
Fax: (703) 481-1271
Email: powersim@powersim.com
http://www.powersim.com

Norway Address:
Powersim AS
PO Box 206
N-5100 Isdalstø
Phone: +47 56 34 24 00
Fax: +47 56 34 24 01
Email: powersim@powersim.no
http://www.powersim.no
-------------------------------------------

Vensim for PC or Macintosh:

Ventana Systems, Inc.
149 Waverley Street
Belmont, MA 02178, USA

tel: 1-617-489-5249
fax: 1-617-489-53316
email: vensim@world.std.com
http://www.vensim.com/

A "Personal Learning Edition" of Vensim and its manual can be
downloaded free from: http://www.vensim.com/ This downloadable
Vensim PLE is the one used for teaching system dynamics at MIT.
--
---------------------------------------------------------
Jay W. Forrester
Professor of Management
Sloan School
Massachusetts Institute of Technology
Room E60-156
Cambridge, MA 02139
"Ray on EV1"
Member
Posts: 29
Joined: Fri Mar 29, 2002 3:39 am

Manufacturing Control Systems

Post by "Ray on EV1" »

Roland,

Texas Instruments worked on such a project through the 90s and then sold
everything they had developed to Accenture (www.accenture.com/). The
fundamental problem TI had in this endeavor was to define the goal - the
objective function for the optimization.

The engineering team had concerns for how to address through put, cycle
time, work in progress, inventories, asset utilization, etc. but never could
determine just what to optimize. [More recently US Steel found that a key
driver for profitability was how long a piece of an order, work unit, was in
the shop.] Occasionally, the TI engineers and production managers would
send off questions to Accounting - the biggest problem was that they never
brought Accounting into the team.

This is a very common scenario, the younger industries feel the drive of
technology; "with sufficient technological advances I can win". If we look
back at the older industries such as steel, the accountants drive the train.
A change isnt made with out knowing the business impact. In the younger
tech firms, this always seems to be a stumbling block because the vast
majority of their tools are engineering tools, and there is not an easy
path to define the business impact of a change. So if a manager/comptroller
asks for a business case, the originator spends weeks, months,. . . too long
trying to identify the value chain. [Just another side line, the oil
industry is still immature, rather than relying on technology, it has been
relying on monopolies.]

The more mature industries (steel) have the accountants on the production
floor and there is an economic model of everything. A business case can be
qualified and quantified with risk assessment at almost a push of a button.

So let me put a stop to my rambling. The semiconductor industry may be in
need of a technological enhancement of its order entry/execution system but
its real need is cultural based. SD can provide the technology to help the
semiconductor industry change its culture to utilizing accounting based
decision support tools.

Raymond T. Joseph, PE
RTJoseph@ev1.net
"Jim Hines"
Senior Member
Posts: 88
Joined: Fri Mar 29, 2002 3:39 am

Manufacturing Control Systems

Post by "Jim Hines" »

Im intrigued by George Simpsons statement "The essential difference
[between the discrete event approach and the way SDers usually model] is
that what is flowing in discrete simulation carries information, which
can affect the flow itself."

George, how about laying down a challenge to the list? Pick a (small)
flow structure that is easy to model by taking a discrete event
approach, but which seemingly cannot be modeled or only modeled with
great difficulty using a "continuous event" (i.e. the more traditional
SD modeling) approach. The challenge is to see if anyone on the list
can come up with a simple, elegant way of representing the structure
using the "continuous event" approach.

To make it interesting, I bet you 50 Jim Hines points (which are every
bit as valuable as they sound) that someone will find a way of modeling
the structure nicely in a "continuous event" way. I hope youll follow
through -- because theres a good chance Im wrong, and so a good chance
that at least one member of the list will learn something.

Regards,

Jim Hines
MIT and WPI
jhines@mit.edu
jhines@wpi.edu
"John Gunkler"
Member
Posts: 31
Joined: Fri Mar 29, 2002 3:39 am

Manufacturing Control Systems

Post by "John Gunkler" »

Id like to risk being a voice crying in the wilderness here and suggest
that "having economic models of everything" and moving toward "accounting
based decision support tools" may NOT be progress. Rather than repeat the
argument here I would refer interested readers to Demings "Out of the
Crisis" and "The New Economics" for cogently stated reasons why the used of
accounting-based decisions has ruined many a company and made the U.S.
non-competitive in many industries. The very fact that one respondent to
this thread cited the U.S. steel industry as one positive (??) example of
the integration of accountants on the production floor should be a red flag
in itself.

The fundamental argument by Deming (and many others) is that
accounting-based decision making, uninformed by the total picture of what
produces "quality" for those who purchase your goods and services, leads to
short-sighted "fixes that fail." Deming quotes many examples of such
decisions (from companies that "saved money" by purchasing inferior tools,
to those whose AR departments got rid of all customers who were chronically
late in payments only to discover that they had then lost many of their most
important customers, to myriad cases of buying from the lowest bidder, etc.,
etc.)

Many people, and entire industries, have been blinded by next-quarter
"successes" only to find that their fundamental problems not only dont go
away but come back more viciously. The recent spate of layoffs is only the
most recent example of how companies, in order to "look good" in their
quarterly reports, have destroyed their ability to prosper in the upcoming
quarters -- while other companies, instead of throwing away some of their
most valuable assets, have taken this economic downturn as a time to build
and prepare for the future. These companies are poised to steal market
share from the rest of their industries, and some are already beginning to
do so.


From: "John Gunkler" <
jgunkler@sprintmail.com>
Bill Harris
Senior Member
Posts: 75
Joined: Fri Mar 29, 2002 3:39 am

Manufacturing Control Systems

Post by Bill Harris »

"Jim Hines" <jhines@MIT.EDU> writes:

> Im intrigued by George Simpsons statement "The essential difference
> [between the discrete event approach and the way SDers usually model] is
> that what is flowing in discrete simulation carries information, which
> can affect the flow itself."

While were at it, Ill suggest it might be helpful to be a bit more
precise with our terminology. (Weve covered this ground before.)

Theres nothing inherently continuous about system dynamics, at its
core. System dynamics is all about feedback and accumulations (and I
have a quote from John Sterman from the last time we went through this
debate substantiating this claim! :-).

Theres nothing inherent in discrete simulation that requires its
entities to carry information about themselves, either. For example, a
classic Petri Net (a Place/Transition or PT Net -- see, for example,
Kurt Jensens _Coloured Petri Nets_, Volume 1, Second Edition, section
1.1) has tokens that are merely black dots. They carry no information
beyond their presence; the state of the system is carried by the number
of tokens in each place. Thats obviously not true of Coloured Petri
Nets.

Continuous and discrete have to do with how models treat time, not how
they treat entities inside those models. That is a choice made by the
implementors of the various simulators.

Of course, the standard SD simulators are all continuous-time in
approach; I dont know of one based explicitly on difference equations
at the user layer. And, as Jims challenge implies, there are many ways
to represent parts of reality in a model without having to assign
properties to entities in a flow.

Nonetheless, I think that its important to use language correctly;
otherwise we imbue our writing and talking about one class of models
(continuous-time, for example) with those of another class (those that
dont track the properties of events in the flow, for example), and we
make it hard to write clearly in the future when those distinctions
might become more important.

For example, I could imagine a simulator for chemical engineering that
tracks the continuous flow of fluids and that separates the types of
fluid explicitly in the pipe without using the SD approach of co-flows
(multiple pipes). I think such a simulator would meet the criterion
laid down previously for discrete-event simulations, except that it
would be continuous-time in nature. Im not a chemist, so I neither
know if such exists already or is infeasible, but it seems reasonable.

> George, how about laying down a challenge to the list? Pick a (small)
> flow structure that is easy to model by taking a discrete event
> approach, but which seemingly cannot be modeled or only modeled with
> great difficulty using a "continuous event" (i.e. the more traditional
> SD modeling) approach. The challenge is to see if anyone on the list
> can come up with a simple, elegant way of representing the structure
> using the "continuous event" approach.

In this light, what is the specific challenge youre issuing? (I
realize you didnt start this, Jim.) Are you asking George to model
something in a discrete-time approach or in an approach in which the
entities contain information about themselves or both? With 50 Jim
Hines points at stake, we gotta keep this clean! :-)

Or am I all wet? Being from the Puget Sound Region of the USA, thats
likely, especially today.

Bill
From: Bill Harris <bill_harris@facilitatedsystems.com>
--
Bill Harris 3217 102nd Place SE
Facilitated Systems Everett, WA 98208 USA
http://facilitatedsystems.com/ phone: +1 425 337-5541
"George A Simpson"
Junior Member
Posts: 5
Joined: Fri Mar 29, 2002 3:39 am

Manufacturing Control Systems

Post by "George A Simpson" »

OK Jim, heres the challenge: Business Process Management.

See
http://www.bpmi.org for background. I believe that this whole domain is one
in which discrete simulation is the tool of choice.

Business processes involve the transmission of messages and responses to
those messages - e.g., orders and deliveries.

The processes linking messages and responses depend on the content of the
messages themselves. E.g., did you order a prefab house or did you ask for
a custom build?

The processes have branching and merging logic (pi-calculus), where for
example a branch in the process flow may wait for another branch to arrive.
E.g., the "build walls" branch waits for both the "lay foundations" and
"install sewers" steps to complete.

A particular example Im interested in is modelling the response
characteristics of computer systems, where usage patterns and process logic
(described in swim-lane diagrams) generates load on servers and networks
and results in distributions of response time performance for users.

I have tried from time to time to do computer system response time problems
with SD, but always failed. Perhaps someone has succeeded, and if so Id
like to hear about it.

Interestingly, I also need to model system availability, and here I have
applied an SD approach, using Monte Carlo sampling to get failures and
sample recovery times.

Here is a small but interesting challenge that illustrates a few of the
simpler features of business process management.

A computer system consists of four servers, four clients, and one
network.
The network capacity is a fixed number of bytes per second, and message
flows reduce that capacity.
Network latency is modelled as a queue and a fixed delay. The "subway"
model applies here:
each message to be transmitted flows into available space on the network
until the last byte is loaded, then theres a fixed delay until the last
byte arrives.
Servers process messages at a fixed rate that depends on the message
type.
The servers come in banks, two in each bank.
Each message arrives in a bank queue and waits until a server is
available.
The message flow through the system depends on the process, and there
are two processes.
Each process start at a client with the dispatch of a message of some
size.
The message goes across the network to an appropriate server bank, and a
different message, related to the first - say twice the size for
definiteness, returns to the client via the network.
Any client can launch any process.
Server bank 1 supports all processes, but server bank 2 only supports
process 2.
The load is time varying, and heavy enough to involve queues on the
network and servers.

Set your own parameters, and show that you can determine the distribution
of response times for messages of each type.

For extra points, design your model such that an arbitrary number of
servers, processes, and messages can be introduced via model parameters.

...george...

Dr. George Simpson, Principal Consultant, CSC
From: "George A Simpson" <gsimpso4@csc.com>
temporary address:
CSC House, Fleet, Hampshire GU51 2UY.
tel +44 1252 813930.

permanent address:
Royal Pavilion T3 floor 2, Wellesley Road, Aldershot, Hampshire GU11 1PZ
United Kingdom
office +44 (0)1252 536523, fax +44 (0)1252 534132, mobile 07814 623 518
"Tzur"
Newbie
Posts: 1
Joined: Fri Mar 29, 2002 3:39 am

Manufacturing Control Systems

Post by "Tzur" »

I believe Jim Hines will win the bet. I do not have a lot of experience in
the field, but all discrete models I looked into could be represented as
continuous flows. It seems to be only a question of playing with time-scales
and resolution.

A more subjective issue is that of the "elegance" of the model. Viewing
models as tools for learning, the continuous-discrete dispute is about
usability of models. Given a case where both methods sufficiently represent
reality, it is a challenge to determine which one yields clearer
understanding and deeper insight. I do not know how to evaluate it, but the
key seems to lie in consumers response rather than in the performance of
modelers.


---
Tzur Levin
levintzu@post.tau.ac.il
Jay Forrest
Junior Member
Posts: 12
Joined: Fri Mar 29, 2002 3:39 am

Manufacturing Control Systems

Post by Jay Forrest »

Well said, John.

I would add that in my experience the boundaries of the economic model
reinforces the mental boundaries of the users - either by inference (for
those who are aware of the model boundaries) or by implicit acceptance (by
those who dont know the model bounds and limits and merely accept that the
model is correct and complete). In either case, the users are generally I
think less likely to consider alternatives, externalities, and potential
unintended consequences.

Thanks!
Jay Forrest
From: Jay Forrest <jay@jayforrest.com>
John Sterman
Senior Member
Posts: 117
Joined: Fri Mar 29, 2002 3:39 am

Manufacturing Control Systems

Post by John Sterman »

George Simpsons challenge to Jim Hines includes modeling a process
such as a construction project in which

"The processes have branching and merging logic (pi-calculus), where for
example a branch in the process flow may wait for another branch to arrive.
E.g., the "build walls" branch waits for both the "lay foundations" and
"install sewers" steps to complete."

The dynamics of such precedence constraints have long been modeled
using traditional SD techniques. Examples are found in Business
Dynamics, Chapter 14, and in the case study of a pulp and paper mill
construction project (done with Jack Homer), described in Chapter
6.3.4. The primary literature describing the model structure to
capture these precedence constraints includes the following papers:

Homer, J. B., J. D. Sterman, et al. (1993). Delivery Time Reduction
in Pulp and Paper Mill Construction Projects: A Dynamic Analysis of
Alternatives. Proceedings of the 1993 International System Dynamics
Conference. E. Zepeda and J. Machuca. Cancún, Mexico, Monterrey
Institute of Technology: 212-221.

Describes the pulp and paper design and construction project
and model, including internal and external precedence gates.

Ford, D. N. and J. D. Sterman (1998). "Dynamic Modeling of Product
Development Processes." System Dynamics Review 14(1): 31-68.

Based on David Fords thesis at MIT, we present a generic
multi-phase project model with internal and external precedence
constraints, endogenous rework, and other features needed to model
projects.

Ford, D. and J. Sterman (1998). "Expert Knowledge Elicitation for
Improving Mental and Formal Models." System Dynamics Review 14(4):
309-340.

Describes a method for eliciting key relationships, including
precedence constraints, from the members of project team so that they
can be used to parameterize a project model. Case study in a
semiconductor firm applying the method.

Ford, D. and J. Sterman (2003). "Overcoming the 90% Syndrome:
Iteration Management in Concurrent Development Projects." Concurrent
Engineering: Research and Applications 11(3): 177-186.

Application of the Ford and Sterman (1998) model to
understanding the 90% syndrome - in which the last 10% of a project
often takes 50% of the total project time

Ford, D. and J. D. Sterman (2003). "The Liars Club: Concealing
Rework in Concurrent Development." Concurrent Engineering: Research
and Applications 11(3): 211-220.

The liars club results when members of a project team
conceal known problems. We use the Ford and Sterman (1998) model to
analyze the impact of deliberate concealment of rework requirements
and explore policies to limit the Liars club.

Reprints of the Ford and Sterman articles are available as pdfs from
David Ford.

John Sterman
From: John Sterman <jsterman@MIT.EDU>
"Jim Hines"
Senior Member
Posts: 88
Joined: Fri Mar 29, 2002 3:39 am

Manufacturing Control Systems

Post by "Jim Hines" »

Bill clarifies terminology and asks for more precision from me on what
challenge I wanted George Simpson to issue.

Precision is actually what Im hoping will come out of George Simpsons
challenge and the resulting responses. I really am intrigued by
Georges original statement, really dont know exactly what George
meant, and really am hoping that Ill learn something from the Challenge
and responses from folks on the list.

I can be a bit more precise in one area though: Bill Harris used the
terms "discrete-time / continuous-time" while I used the terms
"discrete-event / continuous event". Im pretty sure that Bill would
agree that in this thread we shouldnt confuse these two sets of terms.
George Simpsons Challenge is about discrete vs. continuous EVENT. Its
NOT about discrete vs. continuous TIME.

Heres the precision (and apologies for failing to make the following
interesting -- consider skipping it if youre easily bored. If youre
not easily bored, Id still consider skipping it.

EVENTS: In a model, a discrete event happens all at once, at a single
point in time. In contrast, a continuous event gets "smeared" over time
(smeared either over a duration or over a series of time points).

TIME: Discrete **time** doesnt talk about events but about how time
moves. Discrete time jumps from one time point to another, skipping the
"times" in between (e.g. time might be defined at points 0, 1, 2, but
not in between these points, say, not at 1.543). Continuous time hits
every single time point. Continuous time is like a continuous line.
Discrete time is like a row of marbles.

EXAMPLE: Consider a letter in the U.S. postal service. In a discrete
event model the letter will pop out of the system at a single time
point. In a continuous event model, the letter wont pop out at all, it
will ooze out.

If the postal model is discrete **time**, the discrete-event letter
could only pop out at one of the pre-defined time points (e.g. time 1 or
time 2 or ...), and the continuous-event letter would be delivered over
a (possibly infinite) series of time points -- say 25% at time 1,
34.56% at time 2, etc.

If the model is continuous **time**, the discrete-event letter can pop
out at any time (e.g. time 1.543 or 2.34577625245), and the
continuous-event letter will be the delivered over some (possibly
infinite) interval of time.

Once again, Georges challenge has to do with EVENTS (discrete vs
Continuous), not time. OK?

Oh, please no jeering from the peanut gallery about digital computers
always proceeding in discrete time steps. The model is one thing. And
the machine or technique used to figure out or approximate the models
behavior is quite another. Lets agree that the limitations of digital
computers are way off topic for this thread. OK?

Jim Hines
From: "Jim Hines" <jhines@mit.edu>
Bill Harris
Senior Member
Posts: 75
Joined: Fri Mar 29, 2002 3:39 am

Manufacturing Control Systems

Post by Bill Harris »

2

"Jim Hines" <
jhines@MIT.EDU> writes:

> I can be a bit more precise in one area though: Bill Harris used the
> terms "discrete-time / continuous-time" while I used the terms
> "discrete-event / continuous event". Im pretty sure that Bill would
> agree that in this thread we shouldnt confuse these two sets of terms.
> George Simpsons Challenge is about discrete vs. continuous EVENT. Its
> NOT about discrete vs. continuous TIME.

Jim,

You caught me not being as precise as I was encouraging us all to be.
Thanks; there is a difference between discrete-event and discrete-time
modeling, as you point out.

I think my point still holds; I conjecture there is yet another
dimension for which we dont currently have (or I dont currently know)
terminology: the dimension holding the property of whether objects in
the system carry with them identifying features. Without a vocabulary
for speaking of that dimension, I suspect we still confound issues. For
example, I, too, agree that Georges question is very interesting, but
Im not sure if hes thinking along the event dimension or this other
dimension.

By analogy to the Petri Net case, would it be appropriate to call models
in which entities inside the model carry information about themselves
"coloured" X models, those which dont "uncoloured" X models, and the
dimension the chromaticity of the model? Or does someone have a better
idea or pre-existing terminology?

For example, if someone created a system dynamics model in which each
part of the flow contained information about itself, wed call it a
"coloured system dynamics model"; wed refer to a conventional system
dynamics model either as that or, if the explicitness were required, as
an "uncoloured system dynamics model."

At least the "coloured" term is already well established in the modeling
realm.

I picked the British spelling because its a bit exotic for USians and
its probably more normal for everyone else.

I think this is what Steffen Bayer was suggesting, too.

> EXAMPLE: Consider a letter in the U.S. postal service. In a discrete
> event model the letter will pop out of the system at a single time
> point. In a continuous event model, the letter wont pop out at all, it
> will ooze out.

Youve made me never want to go to the mailbox again!

> Once again, Georges challenge has to do with EVENTS (discrete vs
> Continuous), not time. OK?

I had the impression he was referring to the models chromaticity.
George?

> Oh, please no jeering from the peanut gallery about digital computers
> always proceeding in discrete time steps. The model is one thing. And
> the machine or technique used to figure out or approximate the models
> behavior is quite another. Lets agree that the limitations of digital
> computers are way off topic for this thread. OK?

Agreed, certainly, except that I still remember the fun of programming
an old EAI computer. :-)

Bill
From: Bill Harris <bill_harris@facilitatedsystems.com>
--
Bill Harris 3217 102nd Place SE
Facilitated Systems Everett, WA 98208 USA
http://facilitatedsystems.com/ phone: +1 425 337-5541
"Ford, David"
Junior Member
Posts: 3
Joined: Fri Mar 29, 2002 3:39 am

Manufacturing Control Systems

Post by "Ford, David" »

4

John Sterman mentioned two papers that have recently been published that
extend and apply the modeling work in the two 1998 SDR papers he references.
The first of these recent papers is development process oriented and the
second is managerial behavior oriented. A bit more description might help
people determine if copies of the full papers would be of assistance in
their own work.

One of the important current questions for the designers and managers of
development processes is "How much concurrence is optimal? When are we not
concurrent enough or too concurrent?" Project failure often takes the form
of the 90% Syndrome. The problem is difficult partially because performance
is measured in multiple dimensions (typically 3 as a minimum). The first of
the two papers addresses the impacts of concurrence on project performance,
primarily through the effects of rework that is not identified where it is
generated and is passed "hidden" to downstream phases. The paper includes
graphs of the impacts of different amounts of concurrence on project
duration, work effort required (proxy for cost), and errors remaining when
the project is over. The graphs illustrate and the paper uses the model
structure to explain a clearly counter-intuitive impact of increased
concurrence. The bibliographic information and abstract are:

Ford, D. and Sterman, J., "Overcoming the 90% Syndrome: Iteration Management
in Concurrent Development Projects," in press at Concurrent Engineering
Research and Applications. Vol. 111, No. 3, pp 177-186, Sept., 2003.
Abstract
Successfully implementing concurrent development to reduce cycle time has
proven difficult due to unanticipated iterations. We develop a dynamic
project model that explicitly models these interactions to investigate the
causes of the "90% syndrome," a common form of schedule failure in
concurrent development. We find that increasing concurrence and common
managerial responses to schedule pressure aggravate the syndrome and degrade
schedule performance and project quality. We show how understanding of and
policies to avoid the 90% syndrome require integration of the technical
attributes of the project, the flows of information among participants, and
the behavioral decision-making heuristics participants use to respond to
unanticipated problems and perturbations.


The second paper addresses the behavior of practicing managers in concurrent
development and how it can degrade project performance. We describe "The
Liars Club" as a clear example of well-intentioned qualified managers
caught in a disfunctional system and model the impacts of their game-playing
behavior on project performance with relatively small changes to the model
used in the first paper. Graphs show the impacts of concealing known rework
requirements on project duration, work effort required (proxy for cost), and
errors remaining when the project is over, and the impacts of different
amounts of concurrence on those results. In this paper we discuss the single
most difficult aspect of improving concurrent development: that both
processes and behaviors and their interactions must be addressed
simultaneously for significant improvement. SD can make major contributions
in this area due to its unique ability to accurately model both processes
and behaviors. The bibliographic information and abstract are:

Ford, D. and Sterman, J., "The Liars Club: Impacts of Concealment in
Concurrent Development Projects," Concurrent Engineering Research and
Applications. Vol. 111, No. 3, pp 211-219, Sept., 2003.
Abstract
Successfully implementing concurrent development has proven difficult for
many organizations. However, many theories addressing concurrent development
treat either technical aspects of the development process (e.g., precedence
relationships) or behavioral issues (e.g., creating effective
cross-functional teams), but not their linkages. We argue that much of the
complexity of concurrent development-and the implementation failures that
plague many organizations-arises from interactions between the technical and
behavioral dimensions. We use a dynamic project model that explicitly
represents these interactions to investigate how a "Liars Club"-concealing
known rework requirements from managers and colleagues-can aggravate the
"90% syndrome," a common form of schedule failure, and disproportionately
degrade schedule performance and project quality. We discuss the role of the
incentives on and behavior of engineers and managers in concurrent
development failure and explore policies to improve project performance.


I would be glad to send you copies of either of these papers, and would be
interested in hearing about any related work.

Dave Ford
From: "Ford, David" <
dford@civilmail.tamu.edu>

**************************
David N. Ford, Ph.D., P.E.
Department of Civil Engineering
Texas A&M University
Voice: (979) 845-3759
Fax: (979) 845-6554
Email: DavidFord@tamu.edu
"George A Simpson"
Junior Member
Posts: 5
Joined: Fri Mar 29, 2002 3:39 am

Manufacturing Control Systems

Post by "George A Simpson" »

9


Thanks to all those contributing to this thread - Im learning a lot.

In response to some of the points raised:

John Sterman:
I appreciate that precedence constraints can be readily handled in an SD
context. I have requested the articles mentioned from David Ford, to see
if I can understand whether what I think is different about business
process management - that the constraint may be varied during the
execution of the process ( i.e., in an ad-hoc way) is as crucial as I
think.

Bill Harris:
Continuous event vs continuous time - It is the event that matters to me.

The "coloured" property seems to be part of the reason, but there is more,
as Geoff Coyle expressed nicely in his reply "Discrete Event vs. DiffEq
Models (SD4506)".

The heart of this seems to be that within the flow, there can be categories
or labels that relate to decision rules.

On the other hand, some of the other features Geoff mentions (numbers of
machines and queues) are conveniently handled in either formalism.

I certainly agree with him that the ability to use either technology in the
appropriate role is a must for practitioners.

My friend Geoff Hook from Lanner mentions the following as an additional
dimension of discrimination between the two technologies.

"a scenario which is common in the problems we address is one of
specifics.... what I mean is similar to your point about information
attached to the entities... a possible scenario is the call centre where
you have language skills... the language skills are spread between real
people... i.e the guy who speaks german also speaks italian.... you cant
just express the resources available in terms of FTEs."

In summary,

I have taken the position that for business process management, i.e., where
one needs to understand the merits of various pathway alternatives,
discrete simulation is the technology of choice. This seems to be working
out for me in practice, but I continue to be interested in the possibility
of a more unified approach.

I would offer this thought - that the gulf between the two communities is
rather artificial, and perhaps is more of academic importance than
practical.

I view process (discrete) and business (dynamic) simulation as
complementary parts of a whole.

Im sorry I dont have the bandwidth to respond to the points raised by
others, but again thank you to each contributor to this thread; its really
helping sharpen what has been for me a rather vague and intuitive
distinction.

...george...
From: "George A Simpson" <
gsimpso4@csc.com>

Dr. George Simpson, Principal Consultant, CSC
temporary address:
CSC House, Fleet, Hampshire GU51 2UY.
tel +44 1252 813930.

permanent address:
Royal Pavilion T3 floor 2, Wellesley Road, Aldershot, Hampshire GU11 1PZ
United Kingdom
office +44 (0)1252 536523, fax +44 (0)1252 534132, mobile 07814 623 518
Bill Harris
Senior Member
Posts: 75
Joined: Fri Mar 29, 2002 3:39 am

Manufacturing Control Systems

Post by Bill Harris »

1

"George A Simpson" <
gsimpso4@csc.com> writes:

> I have taken the position that for business process management, i.e., where
> one needs to understand the merits of various pathway alternatives,
> discrete simulation is the technology of choice. This seems to be working
> out for me in practice, but I continue to be interested in the possibility
> of a more unified approach.

I just got back from presenting a workshop on systems thinking where we
introduced three disparate approaches -- system dynamics, soft systems
methodology, and complex adaptive systems -- in the course of a day.

One of the lessons people there seemed to find attractive was that there
isnt one tool for all situations. Each tool has its area of desired
application, and each has areas where its not the tool of choice, and
there are still _many_ more tools we didnt even mention.

In some ways, its like the law of requisite variety. Crudely, we have
a slotted screwdriver for this screw, a Posidrive screwdriver for that
screw, and a hex driver for that other one. When someone brings out a
Torx fastener, we simply go to the store and buy a Torx screwdriver.
Any particular task may involve one, some, or all of these tools.

The same is true of the problems we encounter.

> I would offer this thought - that the gulf between the two communities is
> rather artificial, and perhaps is more of academic importance than
> practical.

I conjecture that there are enough technical difficulties in any one of
these approaches that its hard to be competent at a wide range of
them.

In addition, the concepts of feedback in system dynamics are so
pervasive that its attractive as an approach to a wide range of
problems. That said, its not necessarily the _best_ approach to all
situations. Im beginning to blend ideas from various approaches so
that, for example, concepts from soft systems may influence how I
approach an issue I address primarily through system dynamics.

Bill
From: Bill Harris <bill_harris@facilitatedsystems.com>
--
Bill Harris 3217 102nd Place SE
Facilitated Systems Everett, WA 98208 USA
http://facilitatedsystems.com/ phone: +1 425 337-5541
"Jim Hines"
Senior Member
Posts: 88
Joined: Fri Mar 29, 2002 3:39 am

Manufacturing Control Systems

Post by "Jim Hines" »

6

Yaman Barlas writes:

>I would either call [a "continuous event"] a series of
>discrete events (in the discrete-time case) or something like
>a process in the continuous-time.

The important thing to me is to have a **single** name that contrasts
with the term "discrete event". Calling that other thing "a series of
discrete events" in one case and a "process" in another case doesnt do
it for me. Yaman, can you find a single name that works for either
discrete-time or continuous-time?

Jim
From: "Jim Hines" <jhines@mit.edu>
Yaman Barlas
Member
Posts: 44
Joined: Fri Mar 29, 2002 3:39 am

Manufacturing Control Systems

Post by Yaman Barlas »

2

I mostly agree with Jim Hines explanation of events vs. time.
The only part I have diffculty adopting is a continuous event. I
would either call it a series of discrete events ( in the
discrete-time case) or something like a process in the
continuous-time.
-----
In any case, the other part of the original question had to do with
...what is flowing in discrete simulation carries information..."
What is meant by this in practice of discrete simulation is the that
entities (say customers) can carry with them some relevant
information (like their special service requirements, how big they
are or how many times they have been in the service before). So, when
each entity is about to be processed, this info (attibute info) is
first checked. This is NOT automatically done in all discrete event
simulations. It is done when it is needed, by defining attributes
for entities. Now in SD simulation it is NOT very difficult to build
models where entities arrive or depart one by one (i.e discrete
event simulation). All flows would have to be 0 or 1, representing
the movement of a single entity and time could be discrete or
continuous. But what would be REALLY DIFFICULT in SD
simulation/modeling(whether continuous or discrete in time doesnt
matter) would be to assign each entity certain attributes, assign
them dynamically and randomly during the simulation and have each
entity carry this information with them as they travel and branch
from stock to stock through the system...so to speak. (Or is it
easy Jim?) I will submit that if such micro, indiividual entity
tracing, discrete events being dependent on entity attibutes is
improtant, our problem IS a discrete event simulation problem and it
is much more conveniently handled by discrete event simulation
conventions, methods and software. Can it still be an interesting
feedback dynamics problem? You bet, if there are feedback structures.
So it could be a systemic dynamic feedback problem, best handled by
discrete event simulation (conventions, methods and software). In
these exceptional situations, distinguishing
software-techniques-tools from approach-conceptualization-philosophy
becomes more subtle and critical. (The latter group is the ultimate
definition of SD, not the former one).

Best to all
(And the real use of this message is to let you all know that we are
in good health in Istanbul after all the bombings!)
Yaman Barlas
From: yaman barlas <
ybarlas@boun.edu.tr>
>>
--
---------------------------------------------------------------------------
Yaman Barlas, Ph.D.
Professor, Industrial Engineering Dept.
Bogazici University,
34342 Bebek, Istanbul, TURKEY
Fax. +90-212-265 1800. Tel. +90-212-358 1540; ext.2073
http://www.ie.boun.edu.tr/~barlas
SESDYN Group: http://www.ie.boun.edu.tr/labs/sesdyn/
-----------------------------------------------------------------------------
"JEAN-JACQUES LAUBLE"
Junior Member
Posts: 5
Joined: Fri Mar 29, 2002 3:39 am

Manufacturing Control Systems

Post by "JEAN-JACQUES LAUBLE" »

5

Hi Mister Barlas and everybody

It seems that the SD community considers differently the difference
between continuous and discrete modeling as to what
can be done with them. Could anybody find
the simpler problem that can be solved by a discrete software
and not by any current SD continuous software?
It that simpler problem is solved with SD modeling,
then it will be necessary to find a more complicate one and so on.
Then we could find when continuous SD modeling is not working
any more or eventually at an unreasonable economical cost.

If I use SD with discrete events, I do two things to adjust SD.
1. First to manage attributes, I uses classes.

For example: for the size of a customer, I can consider three classes of
customers:
little, middle and big ones. And so on for any attribute.
I then use subscripted variables; each subscript representing one attribut
and the value of the subscript the class in the attribute.

This way the initial information is kept throughout the model and can be
used
for any further calculation.

Generating randomly the number of events, and the class of each subscript is
not
a problem as long one knows the respective distribution laws in current SD
software.

One of the problem is to find a sufficiently small period ot time, to order
the arrival
of events. The order of arrival is always important in discrete simulation.
This is generally not a problem unless the distribution of the arrival has
severe
point of accumulations.

The period of time should be settled so that in 10 period of time, there is
no more then
3 events occuring.
If by hasard there is more then one event in one period, one can choose
randomly the first one,
the second, etc... leave only the first one in the period, and push the
second
one in the next period. It does not change anything in the result, as long
as one considers the
general aim of SD, finding a general policy and not an exact result.
There are probably a lot of other trick to solve that problem.
Of course if the model is big, shortening the period of time, increases the
number of periods
and the time of simulation. But in discrete simulation the length of time is
not so long.

This way I can solve my discrete problems without leaving current SD.
I went recently on two discrete software web site, mentionned recently on
this list.
I am absolutely not sure, that these software will resolve more easily my
problems
if they can resolve them at all. I did not see any reference at any
programming, everything
seems automatic, and I am not sure to solve my very peculiar problems.
Regards to everybody

J.J. Laublé
From: "JEAN-JACQUES LAUBLE" <
JEAN-JACQUES.LAUBLE@WANADOO.FR>
"Ray on EV1"
Member
Posts: 29
Joined: Fri Mar 29, 2002 3:39 am

Manufacturing Control Systems

Post by "Ray on EV1" »

8

JEAN-JACQUES,

I thought it would be fun to address two points of your posting:

1) "One of the problem is to find a sufficiently small period ot time, to
order the arrival
of events. The order of arrival is always important in discrete simulation.
This is generally not a problem unless the distribution of the arrival has
severe point of accumulations."

The concern that "the order of arrival is always important " is too severe.
Lets say we are looking at the events of objects arriving at a queue in a
system. It probably is not relevant of the specific arrival time of an
object if there is another equal object already waiting in the queue.
This would be the case if we are looking at a bolt arriving on a conveyor
pending insertion into a nut. It may be significant if it were a heated
bolt with a limited lifetime or if it was a person arriving at a store.

2) "The period of time should be settled so that in 10 period of time,
there is no more then 3 events occurring."

Actually, this goes along with item 1) above on timing. For continuous time
systems, the timing can be addressed in terms of system sampling rate and
input bandwidth - all falling under the direct supervision of Nyquist. In
order not to add inadvertent noise to a measurement, a system must sample
its input streams greater than twice as fast as the highest frequency
component in the input stream. Of course we must be careful here, if we try
to say that the system sees a discrete event, this implies an instantaneous
change which has unbounded bandwidth - and we cant sample fast enough. A
truly square wave has infinite bandwidth and we can not sample at twice
that rate!

Of course what we all want is the answer; which is better discrete event or
continuous time models? And, of course, the answer is yes! Anything you
may choose to model with one method could be model with the other. But I
dont think that we are really asking that question. Our concern probably
more closely leans to: If I have this type of problem and I want to
determine that kind of information, then modeling method X will be the most
cost effective method to achieve the result. As usual, the answer is
problem dependant. It is not linear, stationary.

Raymond T. Joseph, PE
RTJoseph@ev1.net

Aarden Control Engineering and Science
Bill Braun
Senior Member
Posts: 73
Joined: Fri Mar 29, 2002 3:39 am

Manufacturing Control Systems

Post by Bill Braun »

9

At 12:10 PM 11/27/2003 -0500, you wrote:
>The important thing to me is to have a **single** name that contrasts
>with the term "discrete event". Calling that other thing "a series of
>discrete events" in one case and a "process" in another case doesnt do
>it for me. Yaman, can you find a single name that works for either
>discrete-time or continuous-time?

Jim,

If a precise term does not yet exist (an assumption from responses thus
far) could not a term that suits you be presented to the SD community as
the term of choice, and we all proceed from there? This may be a moment in
which we select a term and give meaning to it in the context of SD and make
it a part of the SD lexicon.

Bill Braun
From: Bill Braun <medprac@hlthsys.com>
"Jim Hines"
Senior Member
Posts: 88
Joined: Fri Mar 29, 2002 3:39 am

Manufacturing Control Systems

Post by "Jim Hines" »

Bill Braun asks me to choose a term for what I was calling "continuous
event", a term to which Yaman Barlas objected.

I think the term should be chosen by someone who cares. Id be happy
though to throw out a few terms that I think would do nicely (and which
I think Yaman would also be happy with):

"extended event"
"prolonged event"
"neighborhood event"

The following are second best, except for the fact that they sound like
"continuous" and so might contrast more obviously with "discrete event":

"continuing event"
"contiguous event"

Someone should choose. The only thing I care about is having a **single
term** for an event that gets spread over a number of neighboring time
points. If no one wants to choose, I suggest that Jim Thompson choose.
He has a flair for the bon mot.

Jim Hines
jhines@mit.edu
jhines@wpi.edu
=?ISO-8859-9?Q?Jean-Jacques_Laub
Newbie
Posts: 1
Joined: Fri Mar 29, 2002 3:39 am

Manufacturing Control Systems

Post by =?ISO-8859-9?Q?Jean-Jacques_Laub »

Ray

About the first question.
What I meant about always important is if you use an SD software like I do.
If the events are undifferentiated I will aggregate them.
The fact is that they are not, and every event has a different impact on
the calculation
and the result will have an impact on the way the next event will be
calculated.

About the second question.
The reason I choose a period of time so that there are no more
then three events occuring, is that I do not want that in a period
too many events happen, because I have to randomly choose
which one will be treated in that period, and I have to postpone
the treatment of the others to the next period. By having an average of
30% event in a period, the probability of many events occuring in the
same period is small and the result of the simulation will not be very much
changed if the distribution law is relatively common.
Another thing is that I cannot afford to use a discrete and continuous
environment at the same time. I found that discrete environments do not take
generally well into account feed backs and there is a good distant learning
course about SD
that I am actually taking.
I tested by example a software who works in a continuous or discrete
way as you choose it.
I do not want to mention it, but the documentation does not
mention any feedback loops. It probably can calculate some sort of
feedbacks, but it does not seem important to this software.
There are other discrete software web site that I consulted and
they do not insist on feedback.
Maybe in a continuous system it is more easy to calculate the influence of a
variable on an other
due to the fixed period of time and then the feed backs.
In discrete time software there is often no mention of programming language
unless
you go to langages like GPSS.
Thank you about answering my questions that were not
mailed for fun, but are important to my business.

J.J. Laublé
From: =?ISO-8859-9?Q?Jean-Jacques_Laubl=E9?= <JEAN-JACQUES.LAUBLE@WANADOO.FR>
"Ray on EV1"
Member
Posts: 29
Joined: Fri Mar 29, 2002 3:39 am

Manufacturing Control Systems

Post by "Ray on EV1" »

Lets make sure we are talking about the same thing. Below, I see:
"Yaman, can you find a single name that works for either discrete-time or
continuous-time?"

But I believe the discussion was more along the lines of discrete-event
systems and continuous-process systems.

If we pursue "discrete time" systems, we will inevitably get caught in the
dilemma of modeling systems in on a digital computer where we must sample
the time stream as opposed to the real system which runs in the continuous
flow of time. This could be addressed with an existing set of definitions
at:
http://uhaweb.hartford.edu/godbout/ee341/ee341001.html
"Continuous-Time System: A system for which the inputs, outputs, and state
are all functions of a continuous real variable, t.

Discrete-Time System: A system for which the inputs, outputs, and state are
only defined at the discrete instants of time t = kT, for k = 0, 1, 2,...,
where T is referred to as the sampling interval of the system."

We were very close when we saw the envelope ooze out of the mail slot.

In general, we have systems which are collections of processes. Processes
convert inputs to outputs. If a process converts a single object at a time,
it is a discrete-event process. If the process works on a continuous
stream, it is a continuous process. If a system is composed of one or more
discrete-event processes, it must be a discrete-event system. If a system
is composed of one or more continuous processes, it must be a continuous
system. If a system is composed of one or more discrete-event processes and
one or more continuous processes, it must be a mixed system.

Raymond T. Joseph, PE
RTJoseph@ev1.net

Aarden Control Engineering and Science

Sites with definitions which I didnt find any help on this subject:
http://iihm.imag.fr/amodeusglossary/
Locked