*1.1. Research Objective*

There is an inherent contradiction in the term "systems science" that is not often honestly admitted to or described. To be a science is to be comprised of relations that can be and are tested. In fact, testing is of particular importance to practical engineering as well as the natural sciences. Engineering disciplines have established tools for examining their particular scale and type of system, but, in general

theories of systems, one is dealing with high-level abstractions of real systems. Most of the knowledge about how processes work or do not work to establish stable systems has come from comparison of real systems that have been elucidated via experimental testing. This knowledge may have been distilled from comparing many systems, but the comparisons are still abstractions often expressed in natural language, not formalized equations. To our knowledge, none of the many general theories of systems beyond those that are purely mathematical have been tested. This research aims to answer the question, "How do you truly test abstract models of system processes?" Achieving this "testability" would be a first for systems science with many downstream applications.

The MP framework for behavior modeling [10] is used to explore this research question because of its ability to express behaviors ranging from simple to complex at a high level of abstraction, and generate many different example instances of behavior from a single specification. We aim to model and simulate one well-studied system process—a cycle—at a very high level to test MP's potential application as a practical tool for advancing our understanding of system processes, like cycling, that manifest in many domains (Isomorphic System Processes, or ISPs) although they are often called by different domain-specific names (discipline-specific synonyms, or discinyms) [9]. Having a tool that enables the study of processes in terms of their domain-independent common properties would enable insights gained at the higher abstract level to be made available at the application level in every domain in which the process manifests. Such a capability would provide system scientists with a means to test their understanding of ISPs and further develop an ISP taxonomy with assistance from a formal reasoning tool. This article reports on the results of our experiment with cycle modeling, in which we applied MP to see if it could not only provide "mini-models"—small example instances of cycles—but also lead to significant new general knowledge about cycles using automated formal reasoning tools.

#### *1.2. Systems Processes Theory*

Circa 2010, the Systems Science Working Group (SSWG) of the International Council on Systems Engineering (INCOSE) officially started two ongoing research projects. Review of the available literature in the basic systems sciences indicated that there were many competing theories on systems but no unified or consensus theory. The SSWG recognized the importance of strengthening SE with a foundational theory of systems, but the existence of many fragmented theories, some not based on science, did not provide what was needed. Thus, the goal of the first project was to help unify that field by critiquing and expanding the SPT [1–3] as an integrated theory of "how systems work" for use in SE. The goal of the second project was to assemble and integrate complementary information on "how systems don't work." The lead for these two projects, Troncale, suggested that this second project should focus on recognizing and starting a new discipline called "Systems Pathology" [4–6] to identify, understand, document, and emphasize that there are common and repeating ways in which systems can fail to work. Subsequently, the INCOSE Foundation, in its first grants, provided seed funding to continue and extend both of these projects [7].

The SPT provided a strong, already developed, science-based general theory and candidate systems science to enable a jump-start for both projects. The natural system-based SPT claimed it provided the "prescriptive" part of systems approaches missing in most of the "systems thinking" and human-level approaches then popular in SE.

As a counterpoint to SPT, the existing state of awareness of systems in SE was characterized as focused solely on traditional systems thinking, which some argued was not systems science at all [29]. SE had a strong knowledge and use of systems thinking tools and system development programs, but the two projects suggested that this knowledge could and should be significantly extended by the strengths and extensive literature of the conventional sciences, just as chemical engineers study the fundamentals of chemistry as a foundation for their work or aeronautical engineers study math and physics. Furthermore, Comparative Anatomy, Comparative Physiology, Comparative Speciation, and Comparative Genomics were very successful because they compared across differences—an approach used by SPT in search of fundamental knowledge about systems that can only come from attempting to match and perceive commonalities across differences. SPT called this approach or method Comparative Systems Analysis (CSA). The SPT research of the INCOSE SSWG for the above purposes has expanded to some 20 collaborative projects [8], each involving cooperation between systems engineers and systems scientists to extend SE awareness of the results of the empirical sciences and distill them into *patterns* (how systems work) and *pathologies* (how systems don't work), common across all natural and human systems. One team is even establishing a new professional society, the International Society for Systems Pathology (ISSP) to help several currently isolated domains learn about each other's discoveries, share, and unify the knowledge base.

The SPT distills its insights from examination of a wide range of systems theories and natural science experiments [2]. Example experimental domains include physics, geology, astronomy, chemistry, biology, mathematics and computer science, and lately SPT has added comparisons of these natural phenomena with the engineering and human domains. Each domain contains system processes that are described in the language of its home domain. This research builds on the SPT premise that there exist *isomorphic* system processes (ISPs) [2] that remain constant across many domains, and that these ISPs can be expressed as domain-neutral concepts to reveal insights about how systems work in general. ISPs are termed "isomorphic" because they are found across many, if not all, mature systems and so they are iso- (same) and -morphic (form). (Note that this is quite a distinct use of the term from its use in mathematics). The term "systems" is used because ISPs are hypothesized to be the fundamental mechanisms by which the sustainability of systemness is achieved; that is, they are the minimal steps for maximal efficacy to achieve system function/purpose no matter what the scale or compositional parts of the system. ISPs are termed "processes" because they perform a similar function/purpose across all these systems by the same "process steps" or developments in an obligate sequence.

For the MP modeling test of concept, therefore, the team decided to select one widespread pattern, "Cycles", from 110 patterns available from the SPT body of work. Some patterns that appeared to be variants of cycling were part of the discussion that grouped the 110 proposed ISPs resulting in a more concise list of 55, since some of the initially considered system processes were essentially different instances of the same pattern [2]. This grouping came about by recognizing in many instances that some ISPs were actually discinyms, or discipline-specific synonyms, for the same process. Troncale argued on abstract grounds that aspects of cycling were shared by a very wide range of diverse phenomena in nature (and humans), in which different cases exhibited many of the same identifying features of cycles. These included phenomena such as oscillation, recycling, iteration/recursion, spin, solitons, waves, hypercycles, and lifecycles. However, at this stage of development of the SPT, only abstract reasoning, that is, comparisons across real natural systems from the results of their science experiments, expressed as informal linguistic-based representations informed the endless discussions and debates that ensued.

MP version 1 first became publicly available in 2015 on firebird.nps.edu, and was shortly thereafter noticed as a tool that could potentially inform these discussions in a more formal manner. Since cycles are present in literally hundreds of phenomena of the natural sciences at all scales and also found widely in human systems, any elucidation of cycles as an ISP using more formal models would significantly contribute both to engineering systems and to the theoretical knowledge of systems, so improve theory and praxis simultaneously.

Recent research by Quartuccio [28] has suggested that the presence of similar patterns and pathologies (the latter being sometimes called *anti-patterns* in systems and software engineering vernacular) in different domains (e.g., medical and aviation) can be identified, analyzed, and documented using MP. This work also contributed inspiration for potential practical applications of modeling SPT patterns or pathologies at a high level of abstraction in MP.

## *1.3. Monterey Phoenix*

While these SPT research projects were evolving in the INCOSE SSWG, a new formal approach and language for system and process behavior modeling known as Monterey Phoenix (MP) was also taking shape and circulating for peer review in the software engineering community. MP is a Navy-developed behavior modeling framework composed of a formal language, a lightweight formal methods approach, and an automated tool that generates a "scope-complete" set of possible event traces from a behavior model using each of the former. For MP, "scope-complete" means exhaustive up to a maximum number of event iterations specified by the user, a defining feature of the MP approach and formalism to make an otherwise infinite model finite for simulation, and therefore practical for testing behaviors up to a given scope. MP is used to define logical or physical objects in terms of their underlying behaviors. Behavior is defined as set of events with two fundamental relations: precedence (for event sequencing) and inclusion (for event decomposition). Behavior rules can be composed from these two basic relations using event grammar that allows for concurrent, alternate, optional, and iterating events, as shown in the upcoming examples.

MP was initially conceived and developed for modeling and assessing software architectures [11,12], but it captured the interest of systems engineers when it became clear that MP provides not only a framework for software modeling, but for systems in general, including humans, organizations, hardware, software, and environment behaviors [10,13–28]. MP provides for modeling high-level behaviors belonging to a range of system types from living to artificial and from natural to technological in nature. For example, we can model the behavior of cells, humans, animals, robotics, air and spacecraft, ground vehicles, information technology systems, environmental activity, etc., and interactions among these systems, in MP. We model systems as independent entities—defining each as a separate root event in MP—that interact through stated dependencies that are coordinated through codified natural law or design specifications. The MP event grammar provides a lightweight formal language for expressing behaviors at the level necessary to test the modeling of an ISP.

Using event grammar capable of describing anything that has behavior at a high level of abstraction, MP has been employed in thesis, dissertation, and sponsored research efforts to model behaviors for system architecture, software architecture, software-intensive systems architecture, business processes, human interactions, medical procedures, operational missions, and entertainment events [30–46]. The precise language enables humans to describe potentially infinite combinations of system behavior in a concise and finite model, and then generate a scope-complete set of example instances of behavior from that model. Once this set of behaviors (scenario instances in the form of event traces) is generated, each instance can be tested against behavior expectations through the use of manual inspection as well as automated queries and assertion checking [10], providing a scientific basis for reasoning about system behaviors, including refutation of claims about system behavior. What sets MP apart from other behavior modeling approaches is its foundation in lightweight formal methods as a basis for these queries, assertion checking, and reasoning about behavior models. In particular, the following section further describes and illustrates what model "scope" means, how defining a scope for behavior models is different from current behavior modeling approaches, and the advantages and limitations of modeling up to a scope.

#### *1.4. The Meaning of "Scope" in MP Behavior Modeling*

Model "scope" is a key feature of the lightweight formal methods upon which MP is based. Lightweight formal methods for scenario generation [47] came into being to make an alternative available to traditional heavyweight formal methods such as model checking and theorem proving. Lightweight and heavyweight formal methods differ in scope of completeness, usability, cost, and experience required. Heavyweight methods mathematically guarantee exhaustive scenario coverage, and so are functionally attractive for mission-critical system design. Traditional formal methods are comparatively expensive and require specialized skills. Lightweight formal methods, on the other hand, trade away the 100% completeness guarantee for greater usability (lower entrance barrier to use) and faster results, while providing increased coverage over popular informal methods. MP uses lightweight formal methods and the concept of scope to denote the boundary for the included behaviors. Scope in MP is the upper limit on how many times an event should repeat, if it is on a loop. Thus, all MP models are run *for a given scope*, which places an upper bound on the number of event iterations to repeat. For example, running at scope 1 will execute iterating events up to one time, running at scope 2 will execute iterating events up to two times, running at scope 3 will execute iterating events up to three times, etc. This scope limit enables an otherwise infinite model to execute in a finite amount of time, trading completeness for speed and ease of use.

#### *1.5. MP Modeling Environment and an Example Illustrating the Concept of Model Scope*

An MP modeling environment called MP-Firebird is available publicly at http://firebird.nps.edu. As seen in Figure 1, the upper left pane of MP-Firebird consists of a text editor for MP code, into which the user types a model or loads an existing model previously composed. The lower left pane is a console window that logs statistics about the trace generation process as the model is run. The center pane contains a large view of the selected event trace graph generated from the model, and the right pane contains a thumbnail list of all traces for the given schema at the given scope. Run scope in MP-Firebird is controlled by using the slider bar to the right of the Run button.

The model displayed in the figure is a pre-loaded example of a simple message flow, available from Import > Load example > Example\_01\_simple\_message\_flow. The MP code in the text editor describes two root events called Sender and Receiver, each performing its respective send or receive activity. The (\* ... \*) parentheses surrounding each event means that the contained event iterates zero or more times. The COORDINATE statement is a separate constraint on the events in each root to enforce a precedence relation to exist between events send and receive. (Without this constraint, no dependency would exist between send and receive events and send could occur without receive, and receive could occur without send).


**Figure 1.** The MP-Firebird modeling environment at http://firebird.nps.edu, showing the pre-loaded MP model Example01\_simple\_message\_flow run for scope 1.

When the model is run up to a scope limit of 1, two event traces (scenarios) are generated consistent with the MP code. In the graphs produced, green boxes are used for root events, blue boxes are used for atomic events, dashed arrows are used to depict inclusion relations, and solid arrows are used to depict precedence relations. In trace 1, both the Sender and Receiver are idle since neither send nor receive occur (shown in Figure 1 top thumbnail on the right), and in trace 2, the Sender includes one send event that precedes one receive event in the Receiver (shown in Figure 1 center pane).

When the same model is run up to a scope limit of 2, the same scenarios that were present at scope 1 are generated plus a third trace showing the additional possibility that the coordinated send–receive events occurs two times (Figure 2a). Running the model up to a scope limit of 3 results in all scenarios from scope 2 plus a fourth trace showing the send–receive events iterating three times (Figure 2b).

The model in Figure 1 was run for up to scope limits 1, 2, and 3 to demonstrate how scope limit works in MP models. It is conceivable to run MP models for higher scopes, but run time increases dramatically with increasing model complexity. In general, lower scope settings produce fewer scenarios in less time than higher scope settings. Shorter run times are preferable to longer ones so that the model can undergo iterative refinement many times without unreasonably long waiting periods for the event trace generator to return results. The requirement for reasonably short run times begs the sensible question: "What scope limit is high enough to include most of the behaviors of interest?" The next section addresses this question with a heuristic called the Small Scope Hypothesis [47].

**Figure 2.** Pre-loaded MP model Example01\_simple\_message\_flow scenarios from (**a**) scope 2, showing the scenario containing the new maximum of two iterations of send and receive (trace 3); (**b**) scope 3, showing the scenario containing the new maximum of three iterations of send and receive (trace 4).

#### *1.6. Use of the Small Scope Hypothesis*

Running the model at a low or small scope has advantages in speed, but are we missing important information by excluding examples from higher scopes? Our observations have been such that scenarios appearing at higher scopes are generally present in some shape at the lower scopes as well. These observations are consistent with Jackson's Small Scope Hypothesis, which states that most errors can be exposed in small examples [47]. Browsing at scope limits of 1, 2, or 3 has often resulted in very valuable and surprising observations about our modeled system, many of which we would have missed by using traditional methods alone; but browsing at scopes 4 and above produced more traces at the expense of longer generation times and more complex graphs, but no new insights than were already gathered at scopes 1–3. Discussion of the Cycles ISP model in the sections that follow therefore provides specific examples of general patterns that can be detected at low scopes of 1–3.

#### **2. Materials and Methods**

The SPT research products are rich in details and examples of both patterns and pathologies. SPT presents a minimum of 55 classes of candidate system processes condensed from an initial list of 110 individual and distinct system processes [2]. All need further evaluation and development. A set of 30 information categories for each ISP has been created to document, extend, and enable teaching and application of SPT-ISPs [5]. To simplify this initial "test of concept", this research examines just one of the 110 system processes using just four of the 30 information categories (Features, Functions, Processivity, and Measurables). We decided to use the MP formal behavior modeling language in order to determine if further research in this direction is warranted.

Source data for the Cycles ISP MP model came from the body of work on cycles in SPT research, in particular from [9]. From this source information, we created a simple but formal model of Cycle behavior using the MP event grammar. We conducted all experiments with this model using the publicly available MP behavior modeling tool, MP-Firebird, at http://firebird.nps.edu. MP-Firebird was used to compose, execute, and refine the Cycles ISP model to embody the identifying features of a cycle. Example outputs of this generation are illustrated and described in the sections that follow. The full set of model outputs can be reproduced by running the illustrated code on MP-Firebird.

#### *2.1. Cycles ISP Model, Version 1*

A basic MP model of the Cycles ISP was first composed as a sequence of one or more steps that move the cycle either forward or backward:

SCHEMA Cycle\_ISP\_v1 ROOT Cycle: (+ ( Step\_forward | Step\_backward ) +).

The SCHEMA declares the name of the model (Cycle\_ISP\_v1). The ROOT establishes a main event, in this case, a Cycle. The Cycle event includes one or more (+ ... +) repetitions of Step\_forward or Step\_backward (the "or" operation is denoted by | ).

Note that Step\_forward and Step\_backward may have synonyms such as Move\_up and Move\_down, Move\_in and Move\_out, and Increase and Decrease. The SPT research has demonstrated the existence of discipline-specific synonyms, or *discinyms*, which also may be used to name cycle movements according to a domain taxonomy.

#### 2.1.1. Cycles ISP Model, Version 1, Scope 1

Running this preliminary model on MP-Firebird at scope 1 illustrates two possible outcomes (as event traces) for cycle behavior: stepping forward, or stepping backward (Figure 3). Immediately, we can tell that these event traces do not fit the definition of a cycle, since there is no repetition or recurrence, as called for in the earlier presented definitions. The depicted scenarios do not contain any repetition, and so only represent a part of cycle behavior.

**Figure 3.** Initial event trace outputs of the Cycle\_ISP\_v1 model, run for scope 1: (**a**) Cycle steps forward; (**b**) Cycle steps backward. Neither scenario contains any repetition and therefore only represents part of a cycle's behavior.

To reject these event traces from the set of valid examples of a complete cycle, the following constraint is added to the model:

ENSURE #( Step\_forward | Step\_backward ) > 1.

Running the constrained model at scope 1 will now generate zero valid traces, having the intended effect of removing single-iteration behaviors from the Cycles ISP model.

#### 2.1.2. Cycles ISP Model, Version 1, Scope 2

Running the constrained model at scope 2 illustrates four possible outcomes for cycle behavior (Figure 4). The cycle may step forward twice, step forward then backward, step backward then forward, or step backward twice. Each scenario contains movement, then another movement, and so each is a valid, albeit general, example of a cycle.

**Figure 4.** Outputs from the constrained Cycle\_ISP\_v1 model, run for scope 2: (**a**) Cycle steps forward twice (trace 1); (**b**) Cycle steps forward then backward (trace 2); (**c**) Cycle steps backward then forward (trace 3); (**d**) Cycle steps backward twice (trace 4).

#### 2.1.3. Cycles ISP Model, Version 1, Scope 3

Figure 5 shows four of twelve scenarios that were generated at scope 3. The output was inspected by browsing the generated event traces one at a time in the MP-Firebird tool by scrolling down the navigation pane (shown on the right side of Figure 1) and clicking on each event trace to enlarge it in the center pane. Patterns started to become visible in the scenarios: Figure 5a positive reinforcement and Figure 5b negative reinforcement are clearly present in the consecutive repeating selection of step\_forward or step\_backward, respectively. The scenario in Figure 5c clearly illustrates a pattern of oscillation, with step\_forward followed by step\_backward followed by step\_forward again. The scenario in Figure 5d shows an instance where two patterns (positive reinforcement and oscillation) are present in the same scenario.

**Figure 5.** Example outputs from the constrained Cycle\_ISP\_v1 model, run for scope 3: (**a**) Cycle exhibits a positive reinforcement pattern (trace 5); (**b**) Cycle exhibits a negative reinforcement pattern (trace 12); (**c**) Cycle exhibits an oscillation pattern (trace 7); (**d**) Cycle steps forward twice then backward once (trace 6).

Once the modeler identified the presence of a pattern in a trace, a condition was written to automatically annotate every trace containing that pattern. The graphs in Figure 5 include comment boxes that were automatically placed on the pertinent scenarios.

To automate the graph annotations, conditions are added to the model. For example, the following condition annotates all traces containing positive reinforcement:

IF EXISTS DISJ \$a: Step\_forward, \$b: Step\_forward \$a PRECEDES \$b THEN SAY ( "Positive Reinforcement Detected" ); FI.

Likewise, graphs containing negative reinforcement are annotated using the following condition:

```
IF EXISTS DISJ $a: Step_backward, $b: Step_backward
      $a PRECEDES $b THEN
           SAY ( "Negative Reinforcement Detected" ); FI.
```
Finally, the following condition annotates all traces containing oscillation:

IF EXISTS DISJ \$a: Step\_forward, \$b: Step\_backward \$a PRECEDES \$b OR \$b PRECEDES \$a THEN SAY ( "Oscillation Detected" ); FI.

These annotation rules are also formal specifications for the definition of the respective pattern. They provide the means to discuss and debate the precise meaning of each pattern.

Recall that the inspection process is based on the premise that most behaviors of interest (patterns or pathologies, in the case of this research) can be exposed on small examples, which is based on Jackson's Small Scope Hypothesis [47]. If we run the model at a higher scope, we would see the possibilities of hundreds or even thousands of repetitions involving positive reinforcement, negative reinforcement, and oscillation. These small examples demonstrate that it is not necessary to run many repetitions (high scopes) to detect these patterns; scope 3 was sufficient to produce examples of these patterns.

#### *2.2. Cycles ISP Model, Version 2*

The model is further refined to explore additional possible cycle patterns. We added an initial condition prior to the repetition steps, and an end condition after the repetition steps. The initial and final conditions may also occur one or more (+ ... +) times. The entire Cycle\_ISP\_v2 model, along with annotation conditions (lines 30–53), is depicted in Figure 6.

#### 2.2.1. Cycles ISP Model, Version 2, Scope 2

As in version 1 of the model, version 2 has zero traces at scope 1 due to the ENSURE constraint (line 26 in Figure 6). Executing the model at scope 2 produces 40 possible scenarios, two of which are illustrated in Figure 7. Scenario (a) shows an example of a positive reinforcement pattern in the first lifecycle, and an oscillation pattern in the second lifecycle. Scenario (b) shows an example of a negative reinforcement pattern in the first lifecycle, and a positive reinforcement in the second lifecycle. Both scenarios are examples of recycling, in which one lifecycle concludes (first End\_condition) and another begins afterwards (second Initial\_condition). Both scenarios also contain patterns nested within other patterns. Thus, we see how a small, minimal MP model of a cycle can lead to potentially thousands of process combinations, before constraints are added to shape, govern, or otherwise bring order to a system's behavior.

#### **Figure 6.** The Cycle\_ISP\_v2 model.

**Figure 7.** Example event trace outputs of the Cycle\_ISP\_v2 model, run for scope 2: (**a**) Lifecycle 1 contains positive reinforcement and Lifecycle 2 contains an oscillation pattern (trace 20); (**b**) Lifecycle 1 contains negative reinforcement and Lifecycle 2 contains positive reinforcement (trace 37). Both scenarios contain the recycling pattern.

#### 2.2.2. Cycles ISP Model, Version 2, Scope 3

There are 2952 cycle instances generated at scope 3, revealing many more possible combinations of the identified patterns. Running the model at scope 3 increases the number of cycle movements within the patterns exposed at scope 2. As the number of scenarios increase into the thousands, manual inspection becomes impractical. MP has assertion checking and querying tools to check these large data sets for properties of interest, but the Small Scope Hypothesis affords us the convenience of exposing many patterns and pattern combinations on a small number of examples that are also present among the large number of examples.

#### *2.3. Example Applications of Cycles across Different Domains*

The main criterion for identifying a process as an ISP is testing for its isomorphic nature. This requires looking at many types of systems and scales of systems; otherwise, it would not fulfill the criteria for a general theory of how systems work. For SPT, this means examining the experimental results of many sciences and abstracting out similar, common, identical, alike structures, relationships, and patterns from the particulars of each discipline to more general descriptions (abstractions) of the steps in the process that are true of all of the specific systems. Abstraction followed by comparison is the key. Are the generalized steps the same even though the particulars going through the steps are not?

In his 90-min online InfoLab © lectures on 14 of the ISPs (for a graduate course, Intro to Systems Science for Systems Engineers, SE 510) for the purpose of providing more details on SPT, Troncale cites and describes numerous case studies from the conventional sciences for each ISP. Each case study is from a phenomenon experimentally elucidated by one of the sciences. These included case studies of real, proven phenomena from Astronomy, Cosmology, Physics, Chemistry, Geology, Biology, Mathematics, and Computer Science as reported in the reductionist science literature. Recently, these have been expanded by additional case studies from the various Human Sciences, Engineering, and a category entitled, "interdisciplinary".

Specifically for the ISP Cycles, the aforementioned SE 510 lecture cited 87 case studies of cycling occurring in the above named sciences. To test the application of the Cycles ISP MP model in different domains, we selected four case studies from [9] and substituted discipline-specific event names from the case studies for domain-independent event names in the Cycles ISP MP model (Table 1). The four case studies selected were cell division, human diurnal activity, geological activity, and a beating heart.


**Table 1.** Event discinyms for four example domain-specific types of cycles.

After making the event name substitutions shown in Table 1, we ran the domain-specific MP models and obtained the cycle model scenarios for each domain. Figure 8 shows four examples of oscillation from different domains, each of which map onto the same Cycle model.

Note once more the effect of limiting the scope, to 3 in this case: only three iterations occur in each example, but it is enough for the oscillation pattern to be quite visible. Additional types of cycles and variants are left for exploration in future work.

**Figure 8.** Example outputs from the constrained Cycle\_ISP\_v2 model (trace 7 in each case), with discinyms substituted for Move\_forward and Move\_backward, and run for scope 3: (**a**) process of cell division; (**b**) process of diurnal activity in humans; (**c**) process of geological activity; (**d**) process of a beating heart.
