**Table 4.** Profile of domain experts.

The tasks of the different teams are described briefly below:


Interviews with domain experts constitute the detailed task analysis step mentioned earlier.

*4.2. Phase-II: Task Ontology*

The task knowledge of ICS operations from a variety of sources such as the available literature and the interview with the domain experts was analyzed for the lexical level task ontology. The four ICS stages were denoted as: mitigation (A1), preparedness (A2), response (A3), and post-disaster reconstruction (A4). Due to the complexity and the dynamic nature of problem-solving methods for ICS and space limitations, only the results for emergency response (A3) of debris flow were chosen to serve as an example for presenting the TTIPP framework. Focusing only on the important concepts of task analysis, Table 5 partially illustrates the generic vocabulary for describing the structure of ICS knowledge classified into nouns, verbs, adjectives, adverbs, and constraints.


**Table 5.** Vocabulary list of the incident command system (partial).

## *4.3. Phase-III: IDEF0 Model*

At the modeling stage, an IDEF0 model was built for describing the function of the emergency response (A3). From a functional point of view, the present emergency response had six activities as shown in Figure 6. They were "Establish an advance command post"(A31), "Monitor any possible disaster locations"(A32), "Evacuate residents"(A33), "Urgent repair of structure"(A34), "Emergency rescue of people"(A35) and "Manage goods and materials" (A36). The ICOM of emergency response is presented in Table 6. For the purpose of making it simple to understand, the hierarchical decomposition of each activity into sub-activities was performed to reveal more detail at each level as shown in Figures 7–12.

**Figure 6.** The IDFE0 model of the "emergency response" (A3).





**Figure 7.** The IDFE0 model of the "Establish an advance command post" (A31).

**Figure 8.** The IDFE0 model of the ""Monitor any possible disaster locations" (A32).

**Figure 9.** The IDFE0 model of the "Evacuate of residents" (A33).

**Figure 10.** The IDFE0 model of the "Urgent repair of structure" (A34).

**Figure 11.** The IDFE0 model of the "Emergency rescue of people" (A35).

**Figure 12.** The IDFE0 model of the "Manage goods and materials" (A36).

"Monitor any possible disaster locations" (A32) was decomposed into five sub-activities, as shown in Figure 8: "Observe wild stream" (A321), "Patrol community" (A322), "Announce first level situation", (A323), "Announce second level situation" (A324), and "Establish guard" (A325), and its ICOM shown in Table 7. The different mechanisms support different sub-activities as shown in Figure 8. For example, the "Observe wild stream" (A321) and "Patrol community" (A322) were controlled by the "Weather information" (C1) and "Community emergency plan" (C2), while "Establish guard" (A325) was controlled by the "evacuation action completed" (C3). After obtaining the functional IDEF0 model, we then developed the Petri net model for behavior analysis at the next stage.


ofofdisasterlocation"

## *4.4. Phase-IV: Petri Net Model*

Based on the transformation rules, from static model into dynamic model as suggested by Santarek and Buseif [21], the PN model was constructed for A32 s five activities (A321, A322, A323, A324, and A325) built in the IDEF0 model at the previous stage (Figure 8), as shown in Figure 13. Following the Tr1 andTr2 transformation rules, the PN model generated the following places: P321, P322, P323, P324, P325, P32-C1, P32-C2, P32-C3, P32-O1-C, P32-O5-C and transitions: T321-1, T321-2, T322-1, T322-2, T323-1, T323-2, T324-1, T324-2, T325-1, and T325-2 described in Table 8. The transformation rule, Tr3 (1) and (2), was used for the mechanisms to produce places P32-MO1, P32-MO3, P32-MO4, and P32-ME2 (Table 8). The PN model for "Monitor any possible disaster locations" (A32) consisted of 14 places and 10 transitions (Table 8).

**Figure 13.** The Petri net (PN) model of the "Monitor any possible disaster locations" (A32).



After constructing the PN model, a DaNAMiCS software package was used to verify the behavioral properties of the developed Petri net model. The incidence matrix (D), P-invariants, and T-invariants are shown in Figure 14. The nonzero nonnegative integer entries in a P-invariant, such as [1,1,1,1,1,1,1,1,0,0,0,0,0], [0,0,0,0,1,0,0,0,1,0,0,0,0], [0,0,1,1,0,0,0,0,0,1,0,0,0], [1,0,1,1,0,0,0,0,0,0,1,0,0], [0,0,1,1,0,0,0,0,0,0,0,1,0], [0,0,1,1,0,0,0,0,0,0,0,0,1], revealed that the weights associated with the corresponding place as such that the weighted sum of tokens on these places was constant for all marking reachable from an initial marking. Similarly, for the purpose of avoiding deadlock, the nonzero nonnegative integer entries in a T-invariant, such as [0,0,1,1,0,0,0,0,0,0], [1,1,0,0,1,1,0,0,0,0], [1,1,0,0,0,0,1,1,1,1], represented not only the firing counts of the corresponding transitions that belonged to a firing sequence transforming a marking m0 back to m0, but also the number of times these transitions appeared in this sequence.

**Figure 14.** The places (P)-invariant and transition(T)-invariant values of A32.
