Converting a discrete system model to a continuous system model

This page is published under the terms of the licence summarized in the footnote.

All free-to-read materials on the Avancier web site are paid for out of income from Avancier’s training courses and methods licences.

If you find them helpful, please spread the word and link to the site in whichever social media you use.


This is the third of three papers on discrete event-driven dynamics, continuous-variable dynamics, and how they are related.

This paper describes how to convert a model of event-driven dynamics to a model of continuous-variable dynamics of the kind in Forrester’s “system dynamics”.


Dynamical system theory. 1

Abstracting a system dynamics model from an event-driven system model 2

Appendix 1: Parallel processing of events. 3

Appendix 2: The trick for converting continuous change into discrete change (Ashby, 1956) 3


Dynamical system theory

“Dynamical systems theory is an area of mathematics used to describe the behavior of dynamical systems.

When difference equations are employed, the theory is called discrete dynamical systems.

When differential equations are employed, the theory is called continuous dynamical systems.” Wikipedia

But you don’t need to understand difference or differential equations here.


State (or adaptive) change is a change to the state of a system, within one system generation (it doesn't change the nature or identity of the system).

The term analogue is used to describe signals or data that vary continuously, as the hands on a clock face do.

The term digital used to describe signals that are chunked into discrete units, as you read from a clock that displays discrete numbers. 

The distinction between analogue and digital signals is related to the distinction between continuous state change and discrete state change.


In continuous dynamics, a system changes its state continually over time. E.g. a weather system, or bio-chemical system.

In discrete dynamics, a system changes its state in response to discrete events. E.g. a tennis score board, or any accounting system.

This paper is about converting a model of discrete dynamics system to a model of continuous dynamics.

Abstracting a system dynamics model from an event-driven system model

It is now common practice to convert continuous analogue signals into discrete digital signals, and vice versa.

How to convert a model of event-driven dynamics to a model of continuous-variable dynamics?

The starting point is to recognise that the quantities in continuous-variable dynamics are abstractions from the qualities in a discrete event-driven system.


A system dynamics model is deliberately limited to quantitative stock levels and flow rates.

A stock level is an abstraction from qualitative facts.

E.g. the number of wolves in a pack is derivable by counting every wolf currently in the "born and alive" state in their life history.

The model advances in time-unit events that each represents a bunch of discrete real-world events.

E.g. every time-unit event in our predator-prey system represents a batch of birth and death events, of wolves and sheep.


From continuous to discrete

It should be possible to forward engineer from a system dynamics model to a discrete event-driven system model.

Stock level variables become attributes of entities in a data model; flow rates become business rules applied to those entities when discrete events are processed.

However, it is hard to explain the necessary elaboration.

It is clearer and more instructive to do it the other way around.


From discrete to continuous

Abstraction by omission (reverse engineering) is much easier to do and to explain than elaboration (forward engineering).

The trick is to abstract aggregates from individuals, abstract quantities from qualities, and divide time into time units.

You then treat each unit as a discrete input event; so the time variable runs over a set of discrete intervals.


The process I designed to abstract a system dynamics model from a discrete event-driven system model is illustrated using graphics in my tutorial slides

The process can be summarised as:


1.      Model the discrete event-driven system at the level of individual entities as well as aggregates of entities.

a.       Model the events that affect entities (define their life histories or state machines).

b.      Annotate events with operations to maintain entity state (so complete the discrete event-driven system).


2.      Abstract the system dynamics model

a.       Remove individual detail entities, leaving only aggregate stock entities.

b.      Remove qualitative variables, leaving only quantities.

c.       Aggregate all “real world” events into time-unit events.

d.      Add a volume-per-time-unit variable (be it fixed or an expression).

e.       Make all variables global.


This method for turning a discrete event-driven system model into a system dynamics model looks reasonably generic.

Of course, you have to build a detailed the discrete event-driven system model in the first place.


(Enterprise architecture level models lack the necessary detail to apply the process above.

You could try to reverse-engineer a discrete event-driven system model from enterprise software itself, but that is difficult.)


Appendix 1: Parallel processing of events

Every software engineer knows that a digital system can simulate an analogue one.

When people run a (supposedly continuous) system dynamics model in a software application, the model actually runs as a discrete event-driven system.

The system processes only one event type (time unit), and processes only one time unit event instance at a time.

However, that time unit represents a batch of real-world events that may occur in parallel.


A system can detect two or more events in parallel if it has distributed/separate sensors or input channels.

It can process events in parallel if they affect different parts of the system’s state, and do not interfere with each other.

(The distribution of system state between subsystems and the parallel processing of events creates challenges for system designers.)

Appendix 2: The trick for converting continuous change into discrete change (Ashby, 1956)

“The most fundamental concept in cybernetics is that of "difference", either that two things are recognisably different or that one thing has changed with time.

Its range of application need not be described now, for the subsequent chapters will illustrate the range abundantly.

All the changes that may occur with time are naturally included, for when plants grow and planets age and machines move, some change from one state to another is implicit.

So our first task will be to develop this concept of "change", not only making it more precise but making it richer,

converting it to a form that experience has shown to be necessary if significant developments are to be made.


Often a change occurs continuously, that is, by infinitesimal steps, as when the earth moves through space, or a sunbather's skin darkens under exposure.

The consideration of steps that are infinitesimal, however, raises a number of purely mathematical difficulties, so we shall avoid their consideration entirely.


Instead, we shall assume in all cases that the changes occur by finite steps in time and that any difference is also finite.

We shall assume that the change occurs by a measurable jump, as the money in a bank account changes by at least a penny.”


EA treats the enterprise as a system in which all state changes are seen as discrete steps.

It assumes core business processes can “digitised”, that is, monitored or directed by digital information systems.


“Though this supposition may seem artificial in a world in which continuity is common, it has great advantages in an Introduction and is not as artificial as it seems.

When the differences are finite, all the important questions, as we shall see later, can be decided by simple counting, so that it is easy to be quite sure whether we are right or not.

Were we to consider continuous changes we would often have to compare infinitesimal against infinitesimal,

or to consider what we would have after adding together an infinite number of infinitesimals questions by no means easy to answer.


As a simple trick, the discrete can often be carried over into the continuous, in a way suitable for practical purposes, by making a graph of the discrete, with the values shown as separate points.

It is then easy to see the form that the changes will take if the points were to become infinitely numerous and close together.


In fact, however, by keeping the discussion to the case of the finite difference we lose nothing.

For having established with certainty what happens when the differences have a particular size we can consider the case when they are rather smaller.

When this case is known with certainty we can consider what happens when they are smaller still.

We can progress in this way, each step being well established, until we perceive the trend; then we can say what is the limit as the difference tends to zero.

This, in fact, is the method that the mathematician always does use if he wants to be really sure of what happens when the changes are continuous.


Thus, consideration of the case in which all differences are finite loses nothing; it gives a clear and simple foundation; and it can always be converted to the continuous form if that is desired.”



Footnote: Creative Commons Attribution-No Derivative Works Licence 2.0     23/12/2015 17:02

Attribution: You may copy, distribute and display this copyrighted work only if you clearly credit “Avancier Limited:” before the start and include this footnote at the end.

No Derivative Works: You may copy, distribute, display only complete and verbatim copies of this page, not derivative works based upon it.

For more information about the licence, see