Ready.
This page is with ready responses, for these questions, about E-nets. Readers may ask yet other questions, too:
In 1972, Nutt's Ph.D. introduced E-nets, as an extension of Petri nets. Macro E-nets were introduced in 1973 (see, NN73). Da80 discusses E-nets, too.
An E-net is a seven-tuple in three-pieces: (E, M0, (xi, Psi)).
| E-net | what it is . . . |
|---|---|
| L | A location may contain a token. At most, a single token, at a time. It is a resource-path from a writer- to a reader-transition. |
| P | Tokens arrive/exit through the peripheral locations. The reader or writer, is the environment (a presumable adjacent net). |
| R | A resolution location is for an index-value, to prefer a path/location. If peripheral, it is set by a resolution-procedure [or, latched]. It informs its (adjacent) transition, for the input/output path preference. (See Da80:IV.E,too, for a formalization of it, through a two-level FSA.) |
| A | An E-net transition is/represents activity. As soon as it is (fully)
enabled, it starts, i.e: there is no wait-before-firing time, separate from the
transition-time. An E-net transition is an atomic subnet. i.e: It may take time, and it also enforces exclusive-action of a single path, at a time. i.e: The alternative path waits, until the busy finishes. |
| E-net | what it is . . . |
|---|---|
| xi | A token, may have token-attributes with it, employed as a vector (record) with
attributes (fields). The xi, is similar, but global. |
| Psi | Each (peripheral) resolution location is associated with a resolution procedure. |
There are five primitives.
| E-net | rivals | friends |
|---|---|---|
| 1-to-2 | Y-transition | F-transition |
| 2-to-1 | X-transition | J-transition |
The transitions with rival paths, must prefer a path. Each resource/path is with a different request (i.e: a transition procedure) for itself. For any path, a path may be with no-request, too. In that case, the transition-firing manages only a token-flow, without any transition-procedures to run.
The transitions with friend paths, must wait for each path to get ready. The (only) request refers to them altogether.
An E-net is interpreted as a token(s) travel. A token for a specific location, is an array of numeric-values, with a specific size. Its tokens are read/written by transitions. With the NN73 examples, those token-attributes are employed as what we know as a record/struct of numeric-values. With Da80, those token-attributes are interpreted as variant-records (union).
In an E-net formal-listing, if two transitions enlist the same location, that means they are adjacent transitions. The former writes, the latter reads. (The order is known from, whether that location is an input/output for that transition.) If for a location, there is only a single transition, that means it is a peripheral-location.
A Petri net is a non-interpreted model. There are two element types, both with unmodifiable responses, without any concern about the past, or about the overall state of the net. A Petri net place is a token-holder, with no feedback. It never rejects a token. A Petri net transition is fireable, when all of its inbound places have tokens. No other concern.
E-nets, in 1972, was an extension of Petri nets, interpreted with resources (data), and time. E-nets offer:
A transition procedure, by itself, is the same as the functions associatable with an (uninterpreted) Petri net model. That is, without any visible feedback to net.
It is with the resolution locations/procedures that, the new (interpreted) abstraction possibilities are introduced. Now, the modelers/programmers were able to extend the net-interpreter, with preferences/procedures they set/write themselves, to influence the process of the interpreter-run.
There is a possibility of time-based management, too. Resolution and time, work together. Resolution prefers a path instead of alternatives, whereas the time-for-transition (subnet) is good for priority-establishment, time-quotas, time-feedback, etc. (For example, alternative-paths may have different time-quotas, and the transitions in any path, may restrict their total-time to meet their quota.)
In Petri nets, rivalry (choice) is expressed with multiple arcs to/from places, whereas friendship (co-operation) is with multiple arcs to/from transitions. E-nets shift the rivalry/preference to the transitions, too.
The E-net locations are only token-relay paths. An E-net location may contain, at most, a single token, and it may precede and/or follow at most a single transition, each. i.e: Nothing to make a preference around it, any way.
E-nets model with time and resources. To do a reachability-test, there are a few ways:
The difference of the E-net primitives does not cause any problems, for a reachability-test. Each of the primitives get a single token from each/preferred input location, and set a single token at each/preferred output location. For each transition-firing, this is for a single time (non-repeated), and at a single moment (time-of(token-wipe-at-input) == time-of(token-visible-at-output)):
By contrast, the vagueness of copycat82, commits maximal complexity.
Although, for a reachability-test, the time-specifics are neglectable, the WATE policy is necessary. To ignore it, would change the model, away from what the modeler intended - with the rules of E-nets.
It is easy, any way. When a token arrives at a location, the next transition is fireable only if:
The E-net time-policy interprets Petri nets, as a tight-couple of a location with the next transition. The token stays at the location, while the transition is busy. An E-net transition starts immediately, when enabled. Its time is work-time, not wait-time. It waits-blocked, though, for-undefined-time, while there is a token at (any of) the target output location(s).
To verify an E-net without time, would not represent the fine-level of time-knowledge. The non-deterministic verifier would verify a lot of impossible cases, and it may generate a lot of spurious states/messages, thereby. i.e: With the modeler-assumptions, such states would never occur, but the verifier traces them. e.g: If two zero-wait transitions are enabled at the same time, there could not be a third transition, to fire in between the two, but the verifier would trace that path, too.
To make a(n exhaustive, non-deterministic) verifier feasible, extra work is needed, as with the works of the other researchers to reduce a net, for a reachibility-test. In other words, a first idea to do a reachibility-test, next, requires work to improve the performance of the verifier.