A Petri net represents the structure of a system, in terms of events and conditions. In a Petri net, events and conditions are interleaved. (i.e: It is a bipartite-graph.)
The conditions, in Petri net terminology, are called places, the event occurrences are called transitions, and the arrows show the relationships among the places and transitions.
The tokens flow in the directions shown by the arrows, according to the Petri net transition firing rule which lets a transition to take tokens from the place(s) pointing at itself, and put into the place(s) which it points at. The firing of an enabled transition need not occur immediately. e.g: Even if dinner is ready, a person may wait before eating, or he/she may altogether skip that meal.
Two conditions (places) may both co-operate for an event, if that event needs both of them. (i.e: pre-requisites for it.) e.g: Many recipes require flour, sugar, etc. With only flour, no cake would realize.
When two events are both enabled by the same condition, it is a conflict (or, choice). In a real-world example, that may represent friendly acts, just as it may represent hostility, too. For example, at the table, there may exist the meal, but if (some of) the kids do not eat, the mom may simply take away the dishes, after some time. It is your interpretation to judge it "sympathetic" or "hostile."
Alternatively, if it were without any such choice, mom would insist that, the kid must eat his/her meal. In that case, the token may reside there, until the kid invokes the event to eat-his/her-meal.
Any Petri net (model) may contain any amount of choice and/or cooperative acts.
A Petri net is an abstraction, for visual modeling, to inform others, about what we think, about (the regularities of) the events in a system. e.g: First, people buy tickets, next they get on a train. This is a regular order of events for many people. As an alternative, though, some people may pay monthly-fees. The system-view for train-payments, would represent both cases, in the event-flow model, i.e: the Petri net.
Petri nets are for modeling systems where multiple activities may occur at the same time, around the model. For example, in a house, two brothers may do different things in most of their times, but they may both eat together - if that is the house-policy.
As far as a(n abstracted) model is accurate, it is preferrable to test real-world cases, with computers. In some cases, it is not even possible to run real-world cases, and we may exclusively depend on our modeling ability. e.g: The aftermath of a nuclear-leak at a reactor, is not available for regular "real-life" tests. We must plan with modeled abstractions. (e.g: See Le87.) When we have modeled a system as a Petri net, we may run tests on it. The reachability-test, lists the possibilities. (See Pe77, for a few ideas, with Petri nets.)
It is a tool with some standing, and a lot of ideas have found applications with Petri nets. Practically, if some older study had started with a problem of current interest, that solution may be re-used. This is the same for any tool that has some history.
For researchers, and for others who need new solutions, there are basically two directions. First, notice that Petri nets, in its pure form, is simple yet quite capable. You may compare its status and fate with programming languages like, C or Lisp. There appears to be mainly two class of activities with them, except the re-using of existing solutions.
Subclasses. The first is the discovering of new ways for making use of it in its pure form, or maybe even concentrate on some more restricted form, to achieve some particular goals. You may compare this to writing some new kind of software with C, or writing for a newly developed hardware. The tool remains the same, but some new possibilities with it are discovered.
Extension. The other is to add new features, to make it more fitting for some or most of the application areas. The E-nets we discuss later, is such an extension of the basic Petri nets, with also some restrictions. This compares to deriving other languages from C and Lisp. For example, C++, Java, Concurrent-C are C look-alikes, some more so than others. Lisp has also led to a few languages, still associated with it.
For example, E-nets (or, Macro E-nets, NN73) and VD78 are both extensions of Petri nets with data, although both of them interpret/restrict some uses of Petri net control-flow. This resembles, for example, the more stringent type-enforcement in C++, although there are more features than C.