Next Article in Journal
Evaluation of Feature Selection Methods for Object-Based Land Cover Mapping of Unmanned Aerial Vehicle Imagery Using Random Forest and Support Vector Machine Classifiers
Next Article in Special Issue
Multi-Feature Joint Sparse Model for the Classification of Mangrove Remote Sensing Images
Previous Article in Journal
The Effects of Rural Settlement Evolution on the Surrounding Land Ecosystem Service Values: A Case Study in the Eco-Fragile Areas, China
Previous Article in Special Issue
Closing the Skill Gap of Cloud CRM Application Services in Cloud Computing for Evaluating Big Data Solutions

ISPRS Int. J. Geo-Inf. 2017, 6(2), 47; https://doi.org/10.3390/ijgi6020047

Article
A Formal Framework for Integrated Environment Modeling Systems
1
School of Physical Science and Technology, Lanzhou University, Lanzhou 730000, China
2
School of Information Science and Engineering, Lanzhou University, Lanzhou 730000, China
*
Author to whom correspondence should be addressed.
Academic Editors: Jason C. Hung, Yu-Wei Chan, Neil Y. Yen, Qingguo Zhou and Wolfgang Kainz
Received: 30 October 2016 / Accepted: 10 February 2017 / Published: 17 February 2017

Abstract

:
Integrated Environment Modeling (IEM) has become more and more important for environmental studies and applications. IEM systems have also been extended from scientific studies to much wider practical application situations. The quality and improved efficiency of IEM systems have therefore become increasingly critical. Although many advanced and creative technologies have been adopted to improve the quality of IEM systems, there is scarcely any formal method for evaluating and improving them. This paper is devoted to proposing a formal method to improve the quality and the developing efficiency of IEM systems. Two primary contributions are made. Firstly, a formal framework for IEM is proposed. The framework not only reflects the static and dynamic features of IEM but also covers different views from variant roles throughout the IEM lifecycle. Secondly, the formal operational semantics corresponding to the former model of the IEM is derived in detail; it can be used as the basis for aiding automated integrated modeling and verifying the integrated model.
Keywords:
Integrated Environment Modeling (IEM); formal method; operational semantics; unified view; Finite State Machine (FSM)

1. Introduction

Over the past 30 years, Integrated Environment Modeling (IEM) has become more and more important for environmental studies as it provides the ability to supply holistic views and solutions for environment science coupled with ecology, economy, and social activities [1,2,3,4]. Assisted by advanced computer science and technologies, many IEM systems have been developed to provide technical support for IEM.
IEM systems have undergone approximately three stages since the emergence of IEM. The earliest IEM systems, and even many new systems, are strictly integrated following to the classification proposed by Voinov and Shugart [5]. In such a system, the models, data, and analysis algorithms are tightly coupled together. Although most of these systems are effective and efficient, they are too tightly coupled to be reused for similar research, modeling, and analysis, which reduces our ability to efficiently develop new investigative paradigms. Therefore, the second stage focused on adopting modular technologies in system development. Modularized software models and analysis algorithms were developed, allowing for more loosely coupled systems. When new studies or applications are encountered, these modules can be abstracted from the original systems and integrated together into a new system with minimal adaptation. Thus, models and algorithms are more reusable and the development efficiency, as well as the quality, of the new system is promoted.
In the last 10–15 years, with the pressing need of environmental sustainable development, the IEM system has become the basis for applied uses as well as research [6]. This requires the IEM system to be developed more efficiently with much better quality; hence, IEM systems evolved into the third stage. Advanced technologies for software development have been adopted to support these requirements during this stage. Models and algorithms are developed as independent, self-contained software components, which are managed in a model or algorithm library. Each component offers one or more interfaces, through which different models and algorithms are woven together to simulate complex phenomena or processes. In this stage, the components of models and algorithms are developed independently. Achieving high reusability, loose coupling, and expandable structure of IEM systems is the main objective. At the same time, to make integration easier, more efficient, and more correct, some support tools have been specially developed. These tools aid IEM by helping build modular components and may be libraries or frameworks, such as MMS [7], OpenMI [8], OMS3 [9,10], ESMF [11], IWRMS [12], GMS/WMS/SMS BASINS [13], CSDMS [14], and SEAMLESS [15]. These tools try their best to relieve integrators from complicated software development techniques, allowing them to concentrate on the model’s interaction and connection and reflecting the relationships of corresponding physical objects in the real world.
The IEM system has continually and promptly adopted many of the latest and advanced computing models, architectures, and techniques. Recently, Multi-Agent System (MAS) [16,17], grid computing [18,19], Service-Oriented Architecture (SOA) [20,21], and cloud computing [10,22] have also become involved. These new techniques make the models less dependent on each other. It has also become possible for many models to be integrated together no matter where they are deployed.
Nevertheless, the growth of the number of models in one system also increases its complexity. More models lead to more interaction. In addition to the dataflow, there is the control flow, which functions to smooth the gaps across models’ semantics and implementation. Thus, the integrated model of IEM system development has a complex and even dynamic structure, which implies that the models and dataflow may themselves function as variables during the simulation. Consequently, it becomes difficult to precisely describe the structure of the integrated model.
Yet it is critical to correctly describe the structure of the model in order to reduce ambiguity, and ensure the model runs smoothly with its dynamic structure. We note that formal methods of developing computer systems use mathematically based techniques to describe system properties and can provide frameworks to specify, develop, and verify systems in a systematic manner [23]. Thus, research into defining formal developmental methods may help IEM as well; we focus on using some formal methods to enrich the IEM system in this paper.
Although there is little direct research on formal descriptions for developing IEMs, there have been many studies that enlighten our work. Argent [24] provided an overview of IEM that covered requirements, modeling, integration, development, frameworks, practice, and applications. Laniak et al. [6] summarized the landscape of IEM as containing four independent elements—applications, science, technology, and community—and proposed its roadmaps, which corresponded to each element. In addition, Argent et al. [25] also supplied an evaluation framework that includes conceptual ease, ease of development, support for model development, and run time features, etc. Voinov et al. [6,26] stressed the role of data in IEM and proposed that it is the data that link different models together and, most importantly, distinguish IEM from pure software composition. Rizzoli [27] focused on the semantics of the model interface link models together smoothly, while Schmitz et al. [28] focused in detail on cooperation between models with different temporal scales. Kragt et al. [29] emphasized the role of modelers and provided a framework through which environmental modelers can guide more successful integrative research programs. Lloyd et al. [30] used software engineering methods to illustrate that models with lower framework invasiveness tended to be smaller, less complex, and have less coupling. Our own practices of integrated modeling [31,32] also suggested that there should be some technologies to describe integration more precisely.
Inspired by these significant studies, this paper aims to construct a formal framework to improve the development efficiency of integrated model and IEM systems. Although there have been many formal methods designed to tackle the composition of components, services, and agents [33,34], there are few formal methods to describe the dynamics of the integrated models’ structure at the level of application. Thus, this paper proposes actor-oriented-like semantics with which the static and dynamic attributes of models, rather than those of the software components, services, and agents corresponding to the model, are defined.
Two main IEM views, different but related, are proposed to satisfy different objectives. Graph-based semantics are used to supply the visual semantics for integration, from the perspective of the integrators, and runtime control, from the perspective of the IEM system. The interaction among the models is represented by an intuitional multidigraph with ports, in which the dataflow itself is represented with the edge, models with vectors, and variables with ports.
For conceptual ease of reuse, another, unified, view of the model, based on a set of integrated algebra, is defined. Reuse is one important factor of IEMs: integrated models, as well as related knowledge, should be easily reused as this is the goal of integration. To simplify reuse of the integrated model, this paper proposes a hierarchical FSM (HFSM)-based integrated algebra for modeling the control flow of IEM, such that a unified view of both the simple model and integrated model is achieved in our semantic framework.
There have been some studies to tackle the hierarchal structure formal analysis, such as analyzing MAS with a hierarchal Petri-net [35] and model checking of a hierarchical FSM [36]. This implies that the complexity that arises from the unified view of the model is affordable. Some analogous studies have been conducted for decades. In the DSP (Digital Signal Processing) area, dataflow (DF) is combined with HFSM to improve the quality (such as static schedule) of the system [37]. In some science workflow systems (e.g., Kepler) and simulation frameworks (e.g., Ptolemy, which is Kepler’s kernel), models and the dataflow among the models are also delegated with composited actors [38].
Distinct from these pre-existing methods, the main contribution of this paper is to emphasize the dynamics of the model’s structure and the reusability of the integrated model. The former leads to more scalable model, while the latter leads to the unified representation of the model and decouples the model from other processes (such as input and output in Ptolemy) as well.
In the following sections, a use case as an example of IEM is given to explain problems encountered by modelers in IEM practice. The unified view of IEM is proposed and the corresponding operational semantics of the integration are carefully constructed. The multidigraphic view is then given and its uniformity with the unified view is also discussed. At the end of the paper, several conclusions of our research are given.

2. A Use Case as an Example of IEM

In this section, we give a use case as an example of IEM. In the latest research, by using OMS3, Peña-Haro et al. [31] and Zhang et al. [32] integrated WOFOST, a crop growth and production model, with HYDRUS-1D, an unsaturated flow model, and MODFLOW, a saturated flow model, to simulate the interaction between crop growth and unsaturated-saturated flow processes. In the integration, the MODFLOW domain is divided into several zones according to similarities of crops, soil properties and groundwater depth. Only one WOFOST/HYDRUS-1D profile is assigned to each one of these zones, which is illustrated in Figure 1.
In this integrated model, the WOFOST provides HYDRUS with the Leaf Area Index (LAI), root depth (RD), and crop height (CH), while HYDRUS provides WOFOST with the water stress factor (the ratio of actual transpiration (vRoot) and potential transpiration (rRoot)). Meanwhile, the HYDRUS provides MODFLOW with recharge fluxes (vBot or recharge) at the water table, while MODFLOW provides HYDRUS with the pressure head value (Hb or H) that is used as the bottom boundary condition in HYDRUS-1D. Three models’ time steps are all adopted with one day. That is to say, three models simulate one day’s evolution of the crop growth, unsaturated flow, and groundwater flow, respectively. The relation can be illustrated as shown in Figure 2.
In practice, we encountered several difficulties. The first difficulty is that WOFOST has a different active period from HYDRUS1-D and MODFLOW. When there is no crop (Before sower and after maturation in Figure 2), WOFOST is deactivated and the input dataflow of HYDRUS-1D disappears. Should we integrate only Hydrus-1D and MODFLOW, or WOFOST, HYDRUS-1D and MODFLOW together? If we adopt the former, WOFOST has to be integrated in the “after sower” period, which leads to more effort for the new integration. Moreover, the integrated model in the whole simulation is not consistent. If we adopt the later, how deal with simulation without a crop? In our earlier study, we had to add extra codes to exam the state of the crop’s sower and growth and decide whether WOFOST should be triggered. At the same time, both the structure and the dataflow of the model are variable during the simulation, which makes the integrated model difficult to reuse.
The second difficulty is that the conceptually integrated model is difficult to be reuse during the instantiation. For different spatial discretizing schemas (such as Schema 1 with 2 zones and Schema 2 with 5 zones, shown in Figure 1), there are different model instances and different dataflow, so that many integrating codes have to be repeated for different schemas. Other problems will be encountered in different contexts, such as how to integrate models with different space dimensions or different time steps.

3. Unified View of the Model

The IEM support tool and runtime environment should be adaptable to different views from different users. The unified form of the model is provided to the end user by the platform to make the model easier to use. Each model’s static features (parameters, input variables, and output variables involved in whole simulation) are visible to users. However, all sub-models (i.e., the blocks used to construct the complex model) of the integrated model are managed by the runtime environment, including data transfer, the models’ schedules, and process control, which is transparent to the end user. During the simulation, the integrated model’s parameters, input variables, and output variables may vary in different time steps. For example, in the above WOFOST, HYDRUS and MODFLOW integrated model, when the model is in the “before sowing” and “after maturation” phases, the parameters, input variables, and output variables are not needed. Therefore, the dataflow related to the model changes too. The variations of the model, its dynamic features, should be represented carefully such that the runtime environment can detect and manage them. Although FSM, Petri-Nets, and other mechanisms [35,36,37] can all model the dynamic features, because of the simplicity and efficiency in dataflow management [37], we chose FSM to represent the dynamic features in our framework.
In the following section, a formal framework to support these mechanisms is discussed in detail.

3.1. Formal Definition of the Model

In our framework, a unified view represents all models, no matter whether they are basic or integrated. Here the basic model implies that the model is not integrated from other models. The model is formally and abstractly defined with a 5-tuple, which is based on the concept of the actor, as
M: = < P, I, O, F, A>
In this framework, P, I, and O are three tuples of the parameters, input variables, and output variables, respectively. They are the interfaces of the model, used to interact with the external environment. The framework defines them similarly as follows:
P = Ø or P = {p1, p2, …}
I = Ø or I = {i1, i2, …}
and
O = Ø or O = {o1, o2, …}
F is the tuples of the functions of the model, which is defined as
F = {f1, f2, …}.
The framework defines the state of the model as
S: = < Pe, Ie, Oe, fe >
where feF, and
fe: Pe × IeOe
or
(oe1, oe2, …, oen`) = fe (pe1, pe2, …, pel`, ie1, ie2, …, iem`)
where PeP, IeI, OeO, en`, el`, em`∈N, and el`, em` ≥ 0. Pe, Ie, Oe, and fe are the effective parameters set, effective input variables set, effective output variables set, and effective function under the specific state, respectively.
When the model is under a specific state (such as before sowing in the example), it will have the same effective parameters set, effective input variables set, effective output variables set, and effective function set. When the new inputs are coming and they all satisfy the constraints, the model will be fired. Once Pe, Ie, Oe, or fe changes (such as from before sowing to after sowing), the model will change to a new state, which can be represented by the Finite States Machine (FSM).
A is a FSM of the model, which is defined as
A: = <S, s0, T>,
where S is the finite set of states of the model. T: SS is the state transition function, which means that, while the parameter Pe and input variable Ie are valuated, the model will transit to a new state, coinciding with Pe and Ie, and fe will be fired while Oe is obtained. In the framework, the initial state s0 = < Ø, Ø, Ø, fØ > means that the model has been activated, where s0S and fØ denotes that there is nothing to do except await new input.
In the definition, P, I, O, and F are used to represent the static structure properties of the model. At the same time, the dynamic characteristics of the model are described with the FSM A, which represents the transition of the structure of the model. We use the block diagram as shown in Figure 3 to represent the model. In the figure, the model m = < P, I, O, F, A >, P = {p1, p2}, I = {i1, i2, i3}, O = {o1, o2}, F = {f1, f2}, A = <S, s0, T >, S = { s0, s1, s2}, and T = {(s0, s1), (s0, s2), (s1, s1), (s2, s2),( s1, s2), (s2, s1)}. In addition, s1 = <Pe1, Ie1, Oe1, f1>, s2 = <Pe2, Ie2, Oe2, f2>, Pe1 = Pe2 = {p1, p2}, Ie1 = {i1, i2}, Ie2 = {i1, i3}, Oe1 = {o1}, and Oe2 = {o2}. The transition is illustrated in the figure.
A basic model is represented in Figure 4, where m = < P, I, O, F, A>, F = { f }, A = <S, s0, T>, S = {s0, s1}, and T = { (s0, s1), (s1, s1)}. Additionally, s1 = <Pe, Ie, Oe, f>, Pe = P, Ie = I, and Oe = O.

3.2. Algebra for Integrating Models

To obtain the unified view of the model in integrated modeling, we present algebra like that in the works of Hamadi and Benatallah [33] to model the control flow of IM, which allows the creation of new models using the existing ones as building blocks. With this algebra, the new model also satisfies the unified definition of the model.
We describe below the syntax and informal semantics of the model algebra operators. The constructs are chosen to allow common and advanced model integration. The set of models can be defined by the following grammar in BNF-like notation:
M:: = ɛ | X | MM | MM | MM | MM | μM
ɛ represents an empty model, i.e., a model that performs no operation.
X represents a model constant, used as a basic model in this context.
M1M2 represents an integrated model that performs the model M1 followed by the model M2, i.e., → is an operator of sequence.
M1M2 represents an integrated model where the next stage of model M1 must be performed after the current stage of model M2, i.e., ← is the feedback operator.
M1M2 represents an integrated model that behaves as either model M1 or model M2. Once one of them executes its first operation, the second model is discarded; thus, ◊ is the select operator.
M1M2 represents a model in which M1 and M2 can execute simultaneously. There is no interaction between M1 and M2, i.e., ↑ represents a parallel operator.
μM represents a model that performs the model M a certain number of times, i.e., μ represents an iterate operator.

4. Formal Operational Semantics of Integrated Modeling

In the framework, the formal operational semantics are presented to represent and implement the algebra calculators for integration.

4.1. Connector

The models interact with each other through the dataflow among them. However, because the models may be developed in different scenarios for different purpose by different developers, there can be potential gaps between models that impede them from connecting smoothly. The barriers mainly involve the different dimensions, different scales, and even different semantics between the variables that will be connected during integration.
The framework defines the connector to ‘glue’ the models together such that it fills in the gap. The connector is a simple and single functionality computing unit. The data from the output variable of the model is collected by the connector. A new datum is computed with those input data and sent to the input variable of another model or to the outputting model itself.
Each connector can be represented as a 5-tuple, similar to the basic model:
C: = <P, I, O, F, A>.
Compared to the basic model’s definition, the only difference is that O = {o}, i.e., the connector always has only one output variable. To distinguish from the model, we use the box with a triangle to represent the connector in the block diagram, as seen in Figure 5. The value of the output variable of the first model can sometimes be transferred to the input variable of the second model directly; the connector may then be simpler, i.e., P = Ø, I = {i}, and f is o = f(i) = i.

4.2. Semantics for the Algebraic Operator

4.2.1. Empty Model

For technical and theoretical reasons, a model that performs no operation is defined as an empty model ɛ.
ɛ = < P, I, O, F, A>
where P = Ø, I = Ø, O = Ø, F = Ø, A = <S, s0, T>, S = {s0}, and T = Ø.

4.2.2. Parallel

The parallel operator indicates that two or more models can be parallel in the same cycle. Paralleled models do not depend on each other’s according to the dataflow. But if one model fails, the integrated model based on the control will fail too. For example,in schema 1 of Figure 1, HYDRUS 1 and HYDRUS 2 should be integrated with the parallel operator. Given two models: m1 = <P1, I1, O1, F1, A1>, m2= <P2, I2, O2, F2, A2>, A1 = <S1, s10, T1>, and A2 = <S2, s20, T2>, let m = m1m2 and m = <P, I, O, F, A>.
Therefore, P = P1P2, I = I1I2, and O = O1 O2, where implies that all output variables of the different models are different. The integration of the function can be represented with F = F1F2, where ☉ implies F = {f=( f1f2)| f1F1, f2F2} and f = f1f2 implies that f executes exactly if both f1 and f2 execute exactly and simultaneously. In accordance with FSM, the initial state of the model is s0 = <s10, s20>, where s10 and s20 refer to the initial states of m1 and m2, respectively, which means that m1 and m2 are in initial states simultaneously. S = {s0} ∪ (S1\{s10} × S2\{s20}), where S\{s} = (S − {s}). The transition T is also the combination of T1 and T2. We define T = T1×T2s10• − s20•, where T1 × T2 = {(s1is2l, s1js2m)| (s1i, s1j) ∈T1, (s2l, s2m)∈T2, i, j, l, m ≥ 0}, s10• = {(s10s2l, s1js2m)∈T1 × T2|, j > 0, l, m ≥ 0}, and s20• = {(s1is20, s1js2m)∈T1 × T2|, I > 0, l, m ≥ 0}. If si = (s1j, s2k), Pei = Pe1jPe2k, Iei = Ie1jIe2k, Oei = Oe1jOe2k, i ≠ 0, and fe = (fe1↑fe2), which means fe1 and fe2 are performed simultaneously. The parallel operation is illustrated in Figure 6.
It is obvious that we can obtain m = m1m2= m2m1 and m = m1m2m3= (m1m2)↑m3 = m1↑(m2m3).

4.2.3. Sequence

The sequence operator is the most familiar operation during integration. It indicates that m1 must have finished its action before m2 can be activated in the same cycle, which is generally caused by the dataflow. If the data of one or more input variables of m2 are from the output variables of m1, then there is a sequence m1m2. Usually, there is one or more connectors between m1 and m2; we denote this as m1→(c1↑…↑ck)→m2, where c1,…, and ck are parallel.
Suppose there are two models m1 = <P1, I1, O1, F1, A1>, m2 = <P2, I2, O2, F2, A2>, A1 = <S1, s10, T1>, and A2 = <S2, s20, T2>. If m = <P, I, O, F, A> and m = m1m2 = m1→(c1↑…↑ck)→m2, then, according to parallel operation, we can define cm = c1↑…↑ck, and cm = <Pc, Ic, Oc, Fc, Ac>, Ac = <Sc, sc0, Tc>, Sc = {sc0, sc1}, and Tc = {<sc0, sc1>, <sc1, sc1>}.
As a result, we can obtain P = P1PcP3, O = O1 Oc O3, and I = I1IcI2Ic^1I2^c, where Ia^b = {iIa|oOb, mb.o = ma.i>} is the set of mb’s inputs that have been occupied by ma’s outputs.
The integration of the function can be represented with F = F1 × Fc × F2, and f = (f1fcf2) ∈ F, which means that f1F1, fcFc, and f2F2 are performed in sequence. According to FSM, A = A1×Ac×A2, and the initial state of the model is s0 = <s10, sc0, s20>, which means that m1, c and m2 are in initial states simultaneously. In addition, S = {s0} ∪ (S1\{s10} × Sc\{sc0} × S2\{s20}). The transition T is also the combination of T1, Tc and T2. We define T = T1 × Tc × T2s10•− sc0•− s20•. If si = (s1j, scl, s2k), then Pei = Pe1jPeclPe2k, Iei = Iej1IeclIe2kIecl^e1jIe2kl^ecl, Oei = Oe1j Oecl Oe2k, i ≠ 0, fe = (fe1fecfe2). The sequence operation is illustrated in Figure 7.
We can also obtain m = m1m2m3 = (m1m2)→m3 = m1→(m2m3). In our example model, WOFOST to HYDRUS-1D and HYDRUS-1D to MODFLOW are sequence relations, which can be represented as WOFOST → HYDRUS-1D and HYDRUS-1D → MODFLOW, respectively. Together these are equal to WOFOST → HYDRUS-1D → MODFLOW. The parameters of the integrated model are the union of three sub-models’ parameters. The input variables should be the union of three sub-models’ variables except LAI, RD, CH (three HYDRUS-1D’s input variables) and Hb (a WOFOST’s input variable). The output variables are the union of three models’ output variables. The function of the integrated model is the combination of three sub-models. In the model, there are only two states: s0 = (s10, s20, s30) (initial states) and s1 = (s11, s21, s31).
Sometimes, there may be no explicit dataflow between two models. In a cycle, the successor models can begin to run if and only if the predecessor models have finished. The empty connector cɛ, which is similar to the empty model, can be used to imply these sequences.

4.2.4. Feedback

A feedback operation occurs across two cycles of the model. It may act on one model or on two different models, denoted with m1m1 or m1m2. This implies that the data are transferred from an output variable of the later model in the previous cycle to the input variable of the former at the next cycle through a connector, c. The second type of feedback operation cannot exist on its own. Generally, it will be based on a sequence or parallel operation in a single cycle. Additionally, it is obvious that m1 and m2 can be understood as a model m’s different components, such that m1m2 is equivalent to mm. Thus, we need only to discuss the semantics of m1m1 or (cm1)←m1.
Suppose m1 = <P1, I1, O1, F1, A1>, A1 = <S1, s10, T1>, c = <Pc, Ic, O1, Fc, Ac>, Ac = <Sc, sc0, Tc>. Let m = (cm1)←m1 and m = <P, I, O, F, A>, A = <S, s0, T>.
We can thus obtain the following conclusions. P = P1Pc, I = I1Ic, O = O1 Oc, F = Fc × F1 = {fc} × F1, and A = Ac × A1. Further, s0 = (sc0, s10), S = {s0} ∪ Sc\{sc0S1\{s10} and T= {(sc0, s10), (sc0, s11)} ∪ sc1•. If t∈{(sc0, s10), (sc0, s11)}, then the corresponding target state st = <Pe, Ie, Oe, fe>, Pest = PecPe1, Iest = IecIe1, Oest = Oec Oe1, fe = fcf1. Otherwise, the formulae are the same as before, except that Iest = IecIe1 - {i'}, where i' is transferred from the last cycle’s output. The feedback operation is illustrated in Figure 8. For our example model, WOFOST ← HYDRUS-1D and HYDRUS-1D ← MODFLOW are the feedback relation. They also can be represented as cascade formation WOFOST ← HYDRUS-1D ← MODFLOW. The detail of this feedback is omitted.

4.2.5. Select

The Select operation makes choosing between different sub-models or sub-model groups possible. These sub-models or sub-model groups may have similar functions and different implementation methods, or face different initial or boundary conditions. For example, in the integration of HYDRUS and WOFOST, before the crop sprouts and after the crop harvests, WOFOST need not work all the time.
Suppose m1 = <P1, I1, O1, F1, A1>, m2 = <P2, I2, O2, F2, A2>, A1 = <S1, s10, T1>, and A2 = <S2, s20, T2>. If m = <P, I, O, F, A> and m = m1m2, this implies that if the guard expression g1 is satisfied, then m1 is performed, or if g2 is satisfied, then m2 is performed. In Select operation, each guard expression has a parameter set Pg, input variable set Ig, and output variable set Og. We can define P = P1P2Pg1P g2, I = I1I2Ig1Ig2, O = O1 O2 Og1 Og2, and F = {g1, g2} × F1 ∪ {g1, g2} × F2. For the FSM A, S = {s10} × S2S1 × {s20}, s0 = {s10, s20}, and T = ∪ki=0(T1 × T2i0) ∪ (∪ki=0 (T1i0 × T2)), where T1i0 and T2i0 are not existing transitions that imply (s1i, s10) for model m1 and (s2i, s20) for model m2, and where s1i and s2i stand for arbitrary states of m1 and m2, respectively. Suppose si = <Pe, Ie, Oe, fe>. If si = (s1j, s20), then Pe = Pe1jPg1P g2, Ie = Ie1jIg1I g2, Oe = Oe1jOg1Og2, fe = (fg1, f g2) & fe1j. If si = (s10, s2j), then Pe = Pe2jPg1Pg2, Ie = Ie2jIg1I g2, Oe = Oe2j Og1 O g2, fe = (g1, g2) & fe2j. The select operation is illustrated in Figure 9.
Similarly, we can obtain m = m1m2 = m2m1 and m = m1m2m3 = (m1m2) ◊ m3 = m1 ◊ (m2m3). In the example, WOFOST is integrated with select operation WOFOST ◊ ɛ.

4.2.6. Iterate

In environmental simulations, different time steps must be permitted, such as, for example, from hourly simulation (e.g., to simulate a fungal infestation) up to several decades for sustainability studies.
Although most models work iteratively, the framework only defines the iterate operation that is used when the model needs to perform many cycles while other models that will be integrated only perform one cycle. The typical scenario is when models with different time steps are to be integrated: the model with the shorter time step should iterate many times while the other model only executes once. In integrated algebra, we use μm to denote a model’s iteration.
Consider the model m1 = <P1, I1, O1, F1, A1> and A1 = <S1, s10, T1>. If m = <P, I, O, F, A> and m = μm1, which imply m1 is performed until the guard expression g is not satisfied (g has parameter set Pg, input variable set Ig, and output variable set Og), then we can obtain P = PgP1, I = IgI1, O = Og O1, and F = {g} × F1 ∪ {g} × {fɛ}.
For the FSM A = <S, s0, T>, we define s0 = s10. For convenience when integrating with other operations, the running state of the model is extended to comprise three types of states: the first running state sfSf, where sf = {Pef, Ief, Oef, fef}; the iterative running state Sit; and the state of end iteration se, such that S = {s0, se}∪SfSit and the transitions according to these states are Tf, Tit, and Te, respectively. If (s10, s1i)∈Tf, then (s10, s1i)∈T1. Let s1i = <Pe1i, Ie1i, Oe1i, fe1i >; then Pef = Pe1iPg, Ief = Ie1iIg, Oef = Oe1i Og, and fef = g × fe1i. For each (s1i, s1j)∈T1, I ≠ 0, (s1i, s1j) ∈ Tit. Let sit = <Peit, Ieit, Oeit, feit >; then, Peit = Pe1jPg, Ieit = Ie1jIg, Oeit = Oe1j Og, and feit = g × fe1j. For the end iteration state, let se = < Pee, Iee, Oee, fee >, Pee = Pg, Iee = Ig, Oee = Og, and fee = g. Then, Te = {(si, se)| siSfSit}. Figure 10 illustrates the iterate operation of the model.

4.2.7. Combine Iterate with Other Operators

Because the iterate operation should not be used alone, it is combined with the parallel, sequence, feedback, and select operations. The framework uses MμM, MμM, μMM, μMM, MμM, and MμM to denote these combinations.
MμM represents a model that parallels an iteration of another model. Let m = m1μm2, i.e., model m1 parallels an iteration of model m2. Obviously, if the iteration is performed n times, then it can be extended to n cycles in which m1m2 is only performed in one cycle, while in any other cycles, ɛm2 is performed, such that P = P1Pm2, I = I1Im2, O = O1 Om2, and F = F1Fm2. For FSM A, S = {s0, sf, sf’, sit, s’it, se}, s0 = (s10, s20), sf = (s10, s2f), sf’ = (s11, s2f), sit = (s10, s2it), s’it = (s11, s2it), snf se = (s11, s2e). T = T1 × T2 − {((s10, s2f), (s11, s2f)), ((s10, s2it),(s10, s2e))}. Additionally, from state (s10, s20) to state (s11, s2e), m1 should execute only once and m2 should execute once at least. The integration is illustrated in Figure 11.
MμM and μMM imply that a model’s iteration performs with another model in sequence. They can also be extended as what is defined in the combination of parallel and iteration. The former is extended to a sequence MM in the first cycle and a series of cycles involving ɛM. Similarly, the latter is extended to a series of cycles involving ɛM first and then a sequence MM in the last cycle. The integration is illustrated in Figure 12.
The combination of feedback with iteration is similar to the sequence. The combination of select with iteration is simple as well. Thus, these combinations are omitted in this paper.

5. Complex Integrated Model

5.1. Model Graph

With these basic operators, a complex model can be integrated from simpler models, even basic models. A result of an Iterate operation or Select operation is taken as a sub-model in the frame. From the perspective of the integrator, many sub-models can be synthetized together with connectors and corresponding message transferring channels. These sub-models may involve both basic models and integrated models, such that the sub-models and channels compose a graph called a model graph. The model graph can be illustrated as in Figure 13, which is a simple example.

5.2. Formal Semantics of Model Graph

Given three finite alphabets ΣM, ΣC, and ΣVar as the available labels for the models, connectors and variables, respectively, the integration of the models is defined with a labeled multidigraph with ports, as follows:
GM: = <M, C, L, PVa, IVar, OVar, s, t, ι, lM, lC, lVar>.
M and C are two finite sets of vertices that denote models and connectors, respectively. M includes basic models and pre-existing integrated models.
L ⊆ (M × OVar) × (C × IVar) ∪ (C × OVar) × (M × IVar) is a set of direct edges, which indicates the dataflow among the sub-models and connectors. The edge set includes both sequence and feedback related dataflow. To distinguish them, we use the label ls for sequence edge and lb for feedback edge, and L = LsLb.
P, I, and O are the set of parameters, input variables, and output variables, respectively, and Var = PIO.
ι = ιMιC. ιM = (ιp, ιi, ιo): M →PVar × IVar × OVar assigns a parameter variable (port) set, an input variable (port) set and an output variable (port) set to each model, with ιp(M) = PM, ιi(M) = IM, ιo(M) = OM, and ι(M) = (PM, IM, OM).
Similarly, ιC = (ιp, ιi, ιo): C PVar × IVar × OVar assigns a parameter variable (port) set, an input variable (port) set and an output variable (port) set to each connector, with ιp(C) = PC, ιi(C) = IC, ιo(C) = OC, and ι(C) = (PC, IC, OC).
s: L → M × OVarC × OVar and t: L → M × IVarC × IVar are two maps indicating the source and target model/connector of an edge. A map n: M × OVarC × OVarM × OVarC × OVar→{0} ∪ N is defined for the source and target of the edge to indicate the produce rate and consumption rate, respectively.
lM: M ΣM, lC: C ΣC and lVar: L ΣVar are three maps describing the labeling of the models, connectors and variables.

5.3. Construct Complex Integrated Model

The model graph is intuitive, such that the integrator can use it easily to represent the interaction of integrated models. At the same time, the IEM tools can use the properties of the graph to check the integrated schema. In running time, the structure of the graph can be used to monitor the procedure of the simulation. Once errors occur, the IEM tool can locate them with the graph as well.
In the graph model, there are two types of relations between any two sub-models. The first is the partial ordering relation, which is based on the sequence operator. If there is a path between two sub-models mh and mt such that mh→m1, m1→m2, , mi→mt, we can say that mh →→ mt and call it order. It is obvious that mt begins to perform after mh has finished in one cycle. Another type is called noninterference, i.e., two sub-models perform in parallel without mutual interference.
As a result, we can obtain a width first search algorithm to construct a model from a model graph. The algorithm can be seen in the following graph (Figure 14).
From the algorithm, we know that the integration of many sub-models can also be taken as a model.

6. Results

Although there are few formal frameworks for IEM being studied specially, each IEM platform has its own potential formalist basis. We compare our formal framework with several platforms or standards to illustrate our framework’s characteristics (in Table 1). The selected platforms are OMS3 [39], OpenMI [8] and ESMF [40].
From the comparison, we can see that there are some advantages embedded in our framework. The formal framework can be used as the semantic basis of an IEM Domain Specific Language (DSL) with which the complicated model can be integrated from pre-existing models. Based on the framework, a light weighted IEM DSL named irDSL (integration-reusable Domain Specific Language) has been developed in our recent work. In Appendix A, some code snippet with irDSL for the integrated model in Figure 1 is listed. The additional details of irDSL will be discussed in another paper.

7. Conclusions and Future Work

In this paper, a formal framework for the IEM system is proposed. In the framework, the features of the model are divided into two parts, i.e., the static and dynamic features. The static features include the traditional parameters, input variables, output variables, and functions of the model. The dynamic feature is the transformation of the static features during the simulation and is represented as an FSM, which adapts the integrated model to dynamic application scenarios. Based on the framework, a unified definition of the model is proposed that makes the integrated model more manageable and reusable, as are the simple models. The integration is also represented as a multidigraph with port. An algorithm is used to explore its sufficiency such that there is a unified representation for a multidigraph.
Our proposed definition can also be used as the interface between specification and formal verification. Based on the framework, it supports integration verification at a specified time (similar to [34,41]) such that the integration specification can be proven to be correct before its implementation; thus, an iterative cycle between the implementation and the specification can be avoided. At the same time, global understanding of the integration is increased, which makes the application easy to understand and, therefore, easy to maintain. Future work should address the enhancement of this tool by supporting the proposed methodology with additional automation features.

Acknowledgments

The authors are grateful to Professor Honggang Luo for his suggestion. We also thank J. Zhou and Peña-Haro for helpful discusses and suggestions. This work was supported by National Natural Science Foundation of China under Grant No. 61402210 and 60973137, Program for New Century Excellent Talents in University under Grant No. NCET-12-0250, Major Project of High Resolution Earth Observation System with Grant No. 30-Y20A34-9010-15/17, “Strategic Priority Research Program” of the Chinese Academy of Sciences with Grant No. XDA03030100, Gansu Sci.&Tech. Program under Grant No. 1104GKCA049, 1204GKCA061 and 1304GKCA018, The Fundamental Research Funds for the Central Universities under Grant No. lzujbky-2016-140, Gansu Telecom Cuiying Research Fund under Grant No. lzudxcy-2013-4, Google Research Awards and Google Faculty Award, China.

Author Contributions

Gaofeng Zhang and Qingguo Zhou designed the framework. Yan Li, Chong Chen, Rui Zhou and Dan Chen tested the design.

Conflicts of Interest

The authors declare no conflict of interest.

Appendix A. Some Code Snippet with irDSL for the Integrated Model in Figure 1.

The following is a code snippet with irDSL for the integrated model in Figure 1. The conceptual integrated model is not bound to any concrete application and can be reused easily.
In a concrete simulation, just as in Peña-Haro’s example [31], a hypothetical simplified two-dimensional-vertical flow system with a height of 20 m and a length of 200 m is used. Two different spatial discretizing schemas (such as Schema 1 with 2 zones and Schema 2 with 5 zones) are intended to be adopted, for comparison with traditional integration. Qualitatively, it can be seen that instantiation of the model needs relative few codes based on the conceptual integrated model.
  //Conceptual integrated model named WOHYMO;
  model WOHYMO{
      model WOFOST(“path_WO”);
      //import basic WOFOST model;
      // path_WO: the path of jar file including the POJO of WOFOST;
      model HYDRUS_1D(“path_HY”); //Ditto;
      model MODFLOW(“path_MO”);  //Ditto;
      //A select control for WOFOST used to specify that the WOFOST
      // begins to run after the crop germinates.
      select is_WOFOST_RUN {     //Control flow
          if (!before_Emergence)
              WOFOST;  // WOFOST doesn’t run until a crop emergency
      }
      //A connector for LAI (Leaf Area Index) which is produced by WOFOST
      // and consumed by HYDRUS as its one boundary condition.
      connector LAI_WO_HY{     // the ordinary connector;
          in lai1;  out lai2;    //input and output;
          expr expr(lai2=lai1);   //indicates ordinary connector;
      }
      //simplified link for ordinary connector, implying a sequence operator;
      forward link_LAI_WO_HY{
          source WOFOST.lai;
          target HYDRUS_1Dconn1.lai;
      }
      //A connector for vBot in HYDRUS (or recharge in MODFLOW) which represents
      // the water flows from unsaturated zone to saturated zone, which is produced by
      // HYDRUS and consumed by MODFLOW as its boundary condition.
      connector vBot_HY_MO{      // the recharge from HYDRUS to MODFLOW;
          in vBot;          //input, weak typing, will be taken as an array;
          out recharge;       //output;
          expr expr(recharge = vBot));     // has same recharge in a zone;
      }
      forward link_ vBot_HY_conn {
          source HYDRUS_1D.vBot;
          target vBot_HY_MO.vBot;
      }
      forward link_ recharge_conn_HY {
          source vBot_HY_MO.recharge;
          targetMODFLOW.recharge;
      }
      //A connector for Hb (pressure head) from MODFLOW to HYDRUS H or Hb is
      // produced by MODFLOW and transferred to HYDRUS-1D as its boundary
      // condition.
      connector Hb_MO_HY {      // the H or Hb from MODFLOW to HYDRUS;
          in H;            //input, weak typing, ;
          out Hb;          //output, weak typing, will be taken as an array;
          expr expr(Hb = H);
      }
      backward link_Hb_MO_conn {      //implying a feedback operator;
          sourceMODFLOW.H;
          targetHb_MO_HY.H;
      }
      forwardlink_ Hb_conn_HY {
          sourceHb_MO_HY.Hb;
          targetHYDRUS_1D.Hb;
      }
      relation m2o <HYDRUS_1D,MODFLOW>; //m2o relation, for extendability;
      relation o2m < MODFLOW, HYDRUS_1D >; //o2m relation;
      //other codes are omitted due to space limitations.
  }
  //Instance of WOHYMO with the 5 zones
  model WOHYMO WOHOMO_5 {    //instance definition;
      model WOFOST inst_WOFOST [5];    //5 instances of WOFOST;
      model HYDRUS inst_HYDRUS [5];       //5 instances of HYDRUS;
      model MODFLOW inst_MODFLOW;    //1 instances of MODFLOW;
      for i in [1..5]               //o2o relation;
             inst_WOFOST [i] ->inst_ HYDRUS [i];
      inst_HYDRUS [1..5] ->inst_ MODFLOW;
      //5 inst_HYDRUSes relates to 1 inst_MODFLOW;
      inst_MODFLOW ->inst_HYDRUS [1..5];
      //1 inst_MODFLOW relates to 5 inst_HYDRUSes;
  }
  //instance of ex16_WOHYMO with the 2 zones
  model WOHYMO WOHOMO_2 {    //instance definition;
      model WOFOST inst_WOFOST [2];    //2 instances of WOFOST;
      model HYDRUS inst_HYDRUS [2];     //2 instances of HYDRUS;
      model MODFLOW inst_MODFLOW;    //1 instances of MODFLOW;
      for i in [1..2]               //o2o relation;
             inst_WOFOST [i] ->inst_ HYDRUS [i];
      inst_HYDRUS [1..2] ->inst_ MODFLOW;
       //2 inst_ HYDRUSes relates to 1 inst_ MODFLOW;
      inst_MODFLOW ->inst_HYDRUS [1..2];
       //1 inst_MODFLOW relates to 2 inst_HYDRUSes;
  }

References

  1. Bailey, G.W.; Mulkey, L.A.; Swank, R.R. Environmental implications of conservation tillage: A system approach. In A System Approach to Conservation Tillage; D’Itri, F.M., Ed.; Lewis Publishers Inc.: Chelsea, MI, USA, 1985; pp. 239–265. [Google Scholar]
  2. Cohen, Y. Pollutants in a Multimedia Environmental; Plenum Press: New York, NY, USA, 1986. [Google Scholar]
  3. Mackay, D. Multimedia Environmental Models: The Fugacity Approach; Lewis Publishers: Michigan, MI, USA, 1991. [Google Scholar]
  4. Walters, C.J. Adaptive Management of Renewable Resources; Macmillan Publishing Co.: New York, NY, USA, 1986. [Google Scholar]
  5. Voinov, A.; Shugart, H. ‘Integronsters’, integral and integrated modelling. Environ. Model. Softw. 2013, 39, 149–158. [Google Scholar] [CrossRef]
  6. Laniak, G.F.; Olchin, G.; Goodall, J.; Voinov, A.; Hill, M.; Glynn, P.; Whelan, G.; Geller, G.; Quinn, N.; Blind, M.; et al. Integrated environmental modelling: a vision and roadmap for future. Environ. Model. Softw. 2013, 39, 3–23. [Google Scholar] [CrossRef][Green Version]
  7. Leavesley, G.H.; Markstrom, S.L.; Brewer, M.S.; Viger, R.J. The Modular Modelling System (MMS)—The physical process modelling component of a database-centered decision support system for water and power management. Water Air Soil Pollut. 1996, 90, 303–311. [Google Scholar] [CrossRef]
  8. OpenMI. The OpenMI Open Midel Interface Project. 2016. Available online: https://publicwiki.deltares.nl/display /OPENMI/Version+2.0 (accessed on 24 December 2016).
  9. David, O.; Markstrom, S.L.; Rojas, K.W.; Ahuja, L.R.; Schneider, W. The object modelling system. In Agricultural System Models in Field Research and Technology Transfer; Ahuja, L.R., Ma, L., Howell, T.A., Eds.; Lewis Publishers: Boca Raton, FL, USA, 2002; pp. 317–344. [Google Scholar]
  10. David, O.; Ascough, J.C., II; Lloyd, W.; Green, T.R.; Rojas, K.W.; Leavesley, G.H.; Ahuja, L.R. A software engineering perspective on environmental modelling framework design: The object modelling system. Environ. Model. Softw. 2013, 39, 201–213. [Google Scholar] [CrossRef]
  11. Hill, C.; DeLuca, C.; Balaji, V.; Suarez, M.; da Silva, A. The architecture of the earth system modelling framework. Comput. Sci. Eng. 2004, 6, 18–28. [Google Scholar] [CrossRef]
  12. Thurman, D.A.; Cowell, A.J.; Taira, R.Y.; Frodge, J. Designing a collaborative problem solving environment for integrated water resource modelling. In Brownfields: Multimedia Modelling and Assessment; Whelan, G., Ed.; WIT Press: Southampton, UK, 2004. [Google Scholar]
  13. Aquaveo. Water Modelling Solutions; Aquaveo: Provo, UT, USA, 2012; Available online: http://www.aquaveo.com/ (accessed on 8 December 2013).
  14. Peckham, S.D. Evaluation of model coupling frameworks for use by the Community Surface Dynamics Modelling System (CSDMS). In Proceedings of the MODFLOW and MORE, Golden, CO, USA, 18 May 2008.
  15. van Ittersum, M.K.; Ewert, F.; Heckelei, T.; Wery, J.; Olsson, J.A.; Andersen, E.; Bezlepkina, I.; Brouwer, F.; Donatelli, M.; Flichman, G.; et al. Integrated assessment of agricultural systems e a component-based framework for the European Union (SEAMLESS). Agric. Syst. 2008, 96, 150–165. [Google Scholar] [CrossRef]
  16. Parker, D.; Manson, S.; Janssen, M.; Hoffmann, M.; Deadman, P. Multi-agent systems for the simulation of land-use and land-cover change: A review. Ann. Assoc. Am. Geogr. 2003, 93, 314–337. [Google Scholar] [CrossRef]
  17. Zhao, J.; Cai, X.; Wang, Z. Comparing administered and market-based water allocation systems through a consistent agent-based modelling framework. J. Environ. Manag. 2013, 123, 120–130. [Google Scholar] [CrossRef] [PubMed]
  18. Zhao, G.; Bryan, B.A.; King, D.; Luo, Z.; Wang, E.; Bende-Michlc, U.; Song, X.; Yu, Q. Largescale, high-resolution agricultural systems modelling using a hybrid approach combining grid computing and parallel processing. Environ. Model. Softw. 2013, 41, 231–238. [Google Scholar] [CrossRef]
  19. Yalew, S.; van Griensven, A.; Ray, N.; Kokoszkiewicz, L.; Betrie, G.D. Distributed computation of large scale SWAT models on the Grid. Environ. Model. Softw. 2013, 41, 223–230. [Google Scholar] [CrossRef]
  20. Granell, C.; Díaz, L.; Gould, M. Service-oriented applications for environmental models: Reusable geospatial services. Environ. Model. Softw. 2010, 25, 182–198. [Google Scholar] [CrossRef]
  21. Goodall, J.L.; Robinson, B.F.; Castronova, A.M. Modelling water resource systems using a service-oriented computing paradigm. Environ. Model. Softw. 2011, 26, 573–582. [Google Scholar] [CrossRef]
  22. Bastin, L.; Cornford, D.; Jones, R.; Heuvelink, G.B.M.; Pebesma, E.; Stasch, C.; Nativi, S.; Mazzetti, P.; Williams, M. Managing uncertainty in integrated environmental modelling: The UncertWeb framework. Environ. Model. Softw. 2013, 39, 116–134. [Google Scholar] [CrossRef]
  23. Wing, J.M. A specifier’s introduction to formal methods. Computer 1990, 23, 8–24. [Google Scholar] [CrossRef]
  24. Argent, R.M. An overview of model integration for environmental applications-components, frameworks and semantics. Environ. Model. Softw. 2004, 19, 219–234. [Google Scholar] [CrossRef]
  25. Argent, R.M.; Voinov, A.; Maxwell, T.; Cuddy, S.M.; Rahman, J.M.; Seaton, S.; Vertessy, R.A.; Braddock, R.D. Comparing modelling frameworks: A workshop approach. Environ. Model. Softw. 2006, 21, 895–910. [Google Scholar] [CrossRef]
  26. Voinov, A.; Cerco, C. Model integration and the role of data. Environ. Model. Softw. 2006, 25, 965–969. [Google Scholar] [CrossRef]
  27. Rizzoli, A.E.; Donatelli, M.; Athanasiadis, I.N.; Villa, F.; Huber, D. Semantic links in integrated modelling frameworks. Math. Comput. Simul. 2007, 78, 412–423. [Google Scholar] [CrossRef]
  28. Schmitz, O.; Karssebnerg, D.; de Jong, K.; de Kok, J.-L. Constructing integrated models: A scheduler to execute coupled components. In Proceedings of the AGILE 2011, the 14th AGILE International Conference on Geographic Information Science, Advancing Geoinformation Science for a Changing World, Utrecht, The Netherlands, 18 April 2011.
  29. Kragt, M.E.; Robson, B.J.; Macleod, C.J.A. Modellers roles in Structuring integrative research projects. Environ. Model. Softw. 2013, 39, 322–330. [Google Scholar] [CrossRef][Green Version]
  30. Lloyd, W.; David, O.; Ascough, J.C., II; Rojas, K.W.; Carlson, J.R.; Leavesley, G.H.; Krause, P.; Green, T.R.; Ahuja, L.R. Environmental modelling framework invasiveness: Analysis and implications. Environ. Model. Softw. 2011, 26, 1240–1250. [Google Scholar] [CrossRef]
  31. Peña-Haro, S.; Zhou, J.; Zhang, G.; Chen, C.; Stauffer, F.; Kinzelbach, W. A multi-approach framework to couple independent models for simulating the interaction between crop growth and unsaturated-saturated flow processes. In Proceedings of the International Environmental Modelling and Software Society (iEMSs) 2012 International Congress on Environmental Modelling and Software: Managing Resources of a Limited Planet: Pathways and Visions under Uncertainty, Sixth Biennial Meeting (iEMSs 2012), Leipzig, Germany, 1 July 2012; pp. 1224–1231.
  32. Zhang, G.; Zhou, J.; Zhou, Q.; Cheng, G.; Li, X. Integrated Eco-hydrological modelling by a combination of coupled-model and algorithm using OMS3. In Proceedings of the International Environmental Modelling and Software Society (iEMSs) 2012 International Congress on Environmental Modelling and Software: Managing Resources of a Limited Planet: Pathways and Visions under Uncertainty, Sixth Biennial Meeting (iEMSs 2012), Leipzig, Germany, 1 July 2012; pp. 1201–1207.
  33. Hamadi, R.; Benatallah, B. A Petri net-based model for web service composition. In Proceedings of the ADC '03 14th Australasian database conference of CRPIT, Adelaide, Australia, 1 February 2003; Volume 17.
  34. Dumez, C.; Bakhouya, M.; Gaber, J.; Wack, M.; Lorenz, P. Model-driven approach supporting formal verification for web service composition protocols. J. Netw. Comput. Appl. 2013, 36, 1102–1115. [Google Scholar] [CrossRef]
  35. Lomazova, I. Nested Petri nets—A formalism for specification and verification of multi-agent distributed systems. Fundam. Inf. 2000, 43, 195–214. [Google Scholar]
  36. Alur, R.; Yannakakis, M. Model checking of hierarchical state machines. In Proceedings of the Sixth ACM FSE, Orlando, FL, USA, 1 November 1998.
  37. Girault, A.; Lee, B.; Lee, E.A. Hierarchical finite state machines with multiple concurrency models. IEEE Trans. Comput.-Aided Design Integr. Circuits Syst. 1999, 18, 742–760. [Google Scholar] [CrossRef]
  38. Lee, E.A.; Tripakis, S. Modal models in Ptolemy. In Proceedings of the 3rd International Workshop on Equation-Based Object-Oriented Modelling Languages and Tools (EOOLT), Oslo, Norway, 3 October 2010; Volume 47, pp. 11–21.
  39. OMS3. The OMS3 Doc Website. 2011. Available online: http://nrrc.ars.usda.gov/ModelFrameworks/ObjectModeling System/Documentation.aspx (accessed on 20 September 2016). [Google Scholar]
  40. ESMF. The ESMF User Doc. 2014. Available online: http://www.earthsystemmodeling.org/esmf_releases/ public/last/ESMF_usrdoc/ESMF_usrdoc.html (accessed on 20 January 2017).
  41. Dustdar, S.; Zdun, U. Model-driven and pattern-based integration of process-driven SOA Models. Int. J. Bus. Process Integr. Manag. 2006, 2, 109–119. [Google Scholar]
Figure 1. The conceptual model and a 2-D hypothetical simplified scenario with two spatial discretizing schemas.
Figure 1. The conceptual model and a 2-D hypothetical simplified scenario with two spatial discretizing schemas.
Ijgi 06 00047 g001
Figure 2. The process of the integrated model’s simulation.
Figure 2. The process of the integrated model’s simulation.
Ijgi 06 00047 g002
Figure 3. The diagram definition of the model.
Figure 3. The diagram definition of the model.
Ijgi 06 00047 g003
Figure 4. The diagram definition of the basic model.
Figure 4. The diagram definition of the basic model.
Ijgi 06 00047 g004
Figure 5. The diagram definition of the connector.
Figure 5. The diagram definition of the connector.
Ijgi 06 00047 g005
Figure 6. The diagram definition of the Parallel operator.
Figure 6. The diagram definition of the Parallel operator.
Ijgi 06 00047 g006
Figure 7. The diagram definition of the Sequence operator.
Figure 7. The diagram definition of the Sequence operator.
Ijgi 06 00047 g007
Figure 8. The diagram definition of the Feedback operator.
Figure 8. The diagram definition of the Feedback operator.
Ijgi 06 00047 g008
Figure 9. The diagram definition of the Select operator. (a) S1 = {s10, s11}, S2 = {s20, s21}; (b) S1 = {s10, s11, s12}, S2 = {s20, s21, s22}.
Figure 9. The diagram definition of the Select operator. (a) S1 = {s10, s11}, S2 = {s20, s21}; (b) S1 = {s10, s11, s12}, S2 = {s20, s21, s22}.
Ijgi 06 00047 g009
Figure 10. The diagram definition of the Iterate operator.
Figure 10. The diagram definition of the Iterate operator.
Ijgi 06 00047 g010
Figure 11. The diagram definition of MμM.
Figure 11. The diagram definition of MμM.
Ijgi 06 00047 g011
Figure 12. The diagram definition of MμM. (a) MΜm; (b) μMM.
Figure 12. The diagram definition of MμM. (a) MΜm; (b) μMM.
Ijgi 06 00047 g012
Figure 13. The example of a model graph. (a) The example of a model graph; (b) The unified view of an integrated model based on a.
Figure 13. The example of a model graph. (a) The example of a model graph; (b) The unified view of an integrated model based on a.
Ijgi 06 00047 g013
Figure 14. The algorithm for constructing a unified view of the integrated model from a model graph.
Figure 14. The algorithm for constructing a unified view of the integrated model from a model graph.
Ijgi 06 00047 g014
Table 1. The comparison with other platforms.
Table 1. The comparison with other platforms.
Our FrameworkOMS3OpenMIESMF
Technological Basis/Object-Oriented Component-Based
/DSL + POJO + AnnotationInterface-BasedMediator Pattern
Dataflowyesyesyesyes
sequenceyesyesyesyes
Formalismfeedbackyesyesyesyes
selectyesnoextra codesextra codes
iterateyesnoextra codesextra codes
Integration reusableeasydifficultdifficultdifficult
Back to TopTop