This is a simple queueing system. People "appear" at the queue, can be "serve"d and can "depart" from the system. Only when a server is available, they can be "serve"d. We want a clock that does the following, in the given order: 1. A new customer may appear (non-deterministically). 2. A customer may depart (non-deterministically). 3. A customer must be served (deterministically). To create the clock, we add 3 phases: one for each action of the clock. Note that phase 1 and 2 have the possibility of not happening. We can use this knowledge to link the phases together already as shown. Next, we link the phases to the system, such that each phase can only happen if there is a token in the corresponding place. So, each of the three places gets an arc to the transition that starts the phase. Now, the phase may only begin if there is a token in the corresponding place. After the phase has ended, we should move to the next phase. This implies that we add an arc from the transition that ends the phase to the place that identifies the next phase. At the end, we link back to the beginning phase. For clarity reasons, we add a "phases_done" place that collects tokens to identify that all phases have been done. In this simple example, there will only be a single token here, but in complex scenarios, you may need to wait for multiple tokens to arrive here. Additionally, we add a "ticks" counter to the system. We add additional transitions to prevent deadlock when: (1) we want to serve someone, but no server. (2) we want to serve someone, but no customer. This system now has a clock that does the predefined micro-steps in a certain order.