Discrete Event Systems
There are many processes such as the flow of control through complex computer programmes (particularly if multiple CPUs are involved), flow of products and materials, orders and invoices through factories and businesses, movement of people through transport systems and so on which present problems of understanding and design in commmercial and industrial environments.
Typically these processes can be seen as a collection of discrete activities, each of which takes time, may require the use of shared resources, and which, on conclusion, trigger or permit another activity to start. The starting and stopping of the activities are seen as events. Their timing is typically irregular The ideas may be familiar in Gannt Charts, PERT digrams and critical path investigations. Here we are concerned with the dynamic behaviour of such systems while they operate.
If you don't want to read all this but just get to my simulation tool McSimAPN click this link.

Methods of Discrete Event Simulation.
Discrete events are modelled as taking place at instants of time and when they take place the model system instantaneously changes state.
For example:
a server (assistant) becomes busy with a customer.
a computer programme starts work on a procedure,
someone joins a group (set membership changes)
That state persists until a subsequent time when another event takes place to change it.
Examples:
In starting work the end time is defined,
Some event modifies the time at which another event will take place,

Event Chains
One way to represent such activities in a computable model is to keep a list of event times (called an event chain ) with their corresponding actions, keeping the list updated (sort by time order, next at top of list) whenever something happens to define a future event.
Such modelling systems can be very powerful (Simscript, Simula, ModSim and others are examples). They are special programming languages with a set theoretic basis and can handle entities that have complicated attibutes and set memberships. They require code to be written to define the events and and state changes. In their operation computed time moves by irregular leaps and bounds to the time of the next event.

Petri Net Approach
An alternative is a Petri-Net approach, in which Tokens move from one place (holder, container) to another when key events called transitions move them which when the tokens they need are ready (and perhaps other conditions are met. The listing of the tokens in the places is called a marking. The idea was formalized by Carl Adam Petri in the early 1960s.. You can find out more at the PetriNet website or from texts such as "Peterson, James L., Petri Net Theory and the modeling of systems, Prentice hall, 1982, ISBN 0-13-661983-5" .

Petri Net in McSimAPN
My choice of Petri Nets was somewhat accidental. I was trying to make a minimalist programme to compute the behaviour of an automated factory having found that the original model used by the builders was seriously deficient.
I concluded that to represent the multiple processes where product was mated with tools and worked on, passed along conveyors and put through inspections and batching, I needed modules that had at least two input and two output connections to link them to places where the products and tools could reside between the process operations. The programme worked OK.
A couple of years later a friend pointed out that what I had was really a Petri Net, and pointed out its use in the design and proving of computer programmes.

The McSim Petri Nets are timed, monochromatic PNs. It models the processes by connecting blocks. The simplest essential block type is the place or container (block type C) which in my version always has some maximum nominal capacity for tokens.
"Monochromatic" because the tokens are indistinguishable (and they can't simultaneously belong to more than one set or place). However, in practice their location (place, in a container [C-block] or in an A- B- or D-block) is implicitly definitive of their type and behaviour.
Conservation Law: If you make sure that all tokens are either in circulation in containers or at least never destroyed, then they can be counted at any time to verify the model at least has that right.
"Timed" because the key component, the Activity block type, has an input transition which takes tokens from places (containers) into its own internal places with a defined delay/residence time. The tokens leave by a second transition when the delay time is reached and if the next place (or places) have enough room available, otherwise the second transition can be blocked.
A conveyor belt can be modelled by a set of the activity blocks with shared (end) containers but more flexibility comes from making it a special unit.
I have added a diverter (originally envisioned as an inspector or test equipment), so the block types are:
A: Activity/Action: a process that takes time (but zero time is allowed)
B: Belt (conveyor): Moves tokens along at a chosen rate
C: Container (place): Passive, Stores tokens or provides a constant value
D: Diverter: randomly delivers tokens to either of two places (containers)
Individual A, B and D blocks look after their own timing, waiting till the independent time variable reaches their own next event time so no event chain is needed and the blocks can be used in conjunction with analogue computer blocks. The overall effect is that a network of blocks stands for a network of physical (or computational) processes and its behaviour in time is displayed in the movement and accumulation of tokens. They can be timed randomly or regularly and A- D-blocks can act instantaneously (zero time delay) to provide routing control.