1. Introduction
Pursuit of societally relevant objectives such as resource security or sustainability presents a challenge for traditional systems engineering and design methods, because no single actor has complete knowledge of or control over all constituent systems. For example, consider the link between water and energy resources in infrastructure: despite energy-intensive processes for water desalination, distribution and treatment and water-intensive processes for energy extraction, refining and cooling, energy and water policies are largely developed independent of each other (Hussey & Pittock Reference Hussey and Pittock2012). Further interdependencies with other resources such as agriculture and food pose multilevel coordination challenges (Pahl-Wostl Reference Pahl-Wostl2019). Myopic decisions based on incomplete or inaccessible information can create significant and lasting harm to natural resources without malice or intent, leading to situations such as the current global groundwater crisis (Famiglietti Reference Famiglietti2014).
Given inherent human limits to knowledge aggregation and centralization of control, co-design frames design as a social process of ‘joint inquiry and imagination’ by integrating diverse viewpoints (Steen Reference Steen2013). Intertwined with related concepts such as participatory design, concurrent engineering (CE) and collaborative design, co-design places information exchange at the heart of problem exploration, definition and perception, well before conceiving of and evaluating potential solutions.
Information systems (ISs) facilitate interaction and information exchange between design actors in engineering design (McMahon, Lowe & Culley Reference McMahon, Lowe and Culley2004). While internet-enabled ISs have long been envisioned as a platform for co-design (Li, Fuh & Wong Reference Li, Fuh and Wong2004), comparatively few engineering design activities leverage ISs for innovative design processes today. For example, model-based systems engineering (MBSE) is perhaps the most widespread IS-enabled design process but is still in its early phases and runs largely parallel to traditional document-driven systems engineering (Madni & Sievers Reference Madni and Sievers2018).
Going beyond model exchange in MBSE, co-simulation is a modelling technique for dynamic information exchange that leverages distributed ISs to study a joint problem by composing constituent parts (Gomes et al. Reference Gomes, Thule, Broman, Larsen and Vangheluwe2018). Co-simulation provides a technical foundation for co-design activities on which participating organizations explore and define the problem from different perspectives. However, beyond modest adoption in defence, automotive and aerospace domains, co-simulation remains a novel technique lacking in supporting methods and processes to support engineering systems design activities at large scales. At the same time, existing gaming applications that blend participatory co-design and simulation activities do not leverage co-simulation techniques.
This paper discusses the design and evaluation of the Sustainable Infrastructure Planning Game (SIPG)Footnote 1 as a co-simulation artifact to support co-design studies (Grogan Reference Grogan2014). While based on generalizable constructs, SIPG formulates a strategic infrastructure planning scenario for resource security and sustainability goals with three role players that control agricultural, water and energy systems. SIPG provides a platform on which to conduct and observe co-design sessions and understand how co-simulation influences co-design activities.
This paper connects initial results of SIPG design sessions reported in Grogan & de Weck (Reference Grogan and de Weck2016) with broader discussion of co-design and co-simulation. Following a design science perspective (Hevner et al. Reference Hevner, March, Park and Ram2004), this work presents SIPG as a prototypical IS artifact that provides dynamic information exchange during co-design settings. A co-simulation modelling framework implemented by the High Level Architecture (HLA) standard enforces spatial–temporal resource interfaces while enabling decentralized control over role-specific simulations. Artifact evaluation collects data from an observational study of 15 co-design sessions to understand scenario-specific game dynamics and how information exchange enabled by co-simulation influences process and outcome variables across session variants with strong and weak adoption of co-simulation.
The remainder of this paper is structured as follows. Section 2 reviews background literature on co-design and co-simulation to refine research objectives. Section 3 describes the formulation and technical implementation of the SIPG co-simulation application. Section 4 constructs an observational study to investigate the SIPG game dynamics and how co-simulation influences collective outcomes. Section 5 presents results, statistical analysis and discussion. Finally, Section 6 concludes by revisiting the role of co-simulation in co-design.
2. Background literature
2.1. Perspectives on co-design
Co-design encompasses design activities and processes that generally exchange information across design roles. Similar to the broader topic of integrated assessment in environmental and sustainability literature (Rotmans Reference Rotmans1998), co-design has both analytical and participatory methods. From a technical perspective, analytical methods perform model, scenario and risk analyses to represent and structure scientific knowledge. From a social perspective, participatory methods such as expert panels, Delphi methods, gaming, policy exercises and focus groups draw on social sciences to involve a broad stakeholder set.
Technical co-design in literature refers to simultaneous decision-making across traditionally sequential disciplines enabled by a shared model (i.e., variables, objectives and constraints) as a type of multidisciplinary design optimization (MDO; Allison, Guo & Han Reference Allison, Guo and Han2014; Azad & Alexander-Ramos Reference Azad and Alexander-Ramos2020). Tighter coupling between decisions allows knowledge in one domain to more directly influence another without unnecessary constraints or delay from multiple iterations, resulting in a more desirable solution.
CE shares a technical perspective with co-design as an integrated method to coordinate design activities to achieve holistic objectives but also includes disciplinary human actors inside the system boundary (Holt & Barnes Reference Holt and Barnes2010). CE broadly encompasses the team (people), model (shared knowledge), tools, process and facility for a design activity (Knoll, Fortin & Golkar Reference Knoll, Fortin and Golkar2018). Alternative CE strategies seek either to decouple tasks to reduce time or increase coupling between tasks to improve quality (Eppinger Reference Eppinger1991). While there is generally no centralized optimizer as in MDO, CE shares a common understanding of the problem and objectives and relies on integrating roles such as systems engineering to facilitate activities.
In contrast to technical solution processes in MDO and CE, other perspectives view co-design as a negotiated solution process between different viewpoints (Détienne, Martin & Lavinge Reference Détienne, Martin and Lavinge2005). Social processes of imaginative creativity and mutual knowledge exchange build on more than 40 years of participatory design that link the designer with other design actors including customers (Sanders & Stappers Reference Sanders and Stappers2008) to broaden the set of stakeholders who influence design decisions (Carroll & Rosson Reference Carroll and Rosson2007). Framed as a ‘process of joint inquiry and imagination’, co-design connects individual practices, experiences and knowledge with collective communication, cooperation and change (Steen Reference Steen2013). Co-design activities seek to overcome barriers to shared understanding at individual, project and organizational levels (Kleinsmann & Valkenburg Reference Kleinsmann and Valkenburg2008).
Collaboration is at the heart of co-design activities; however, collaborative design activities can succumb to complexity if poorly structured (Suh Reference Suh2009). Research on collaborative engineering applies results from organization science, social cognition, social choice and decision science to engineering practice to work towards a common goal with limited resources or conflicting interests (Lu et al. Reference Lu, Elmaraghy, Schuh and Wilhelm2007). Proposed methods for engineering collaboration via negotiation outline a four-step process to manage social interactions, construct shared understanding, discourse preferences and finally attain agreement (Lu et al. Reference Lu, Elmaraghy, Schuh and Wilhelm2007). Mediation may benefit negotiation processes to achieve joint decisions among two or more parties while maximizing social welfare (Klein et al. Reference Klein, Faratin, Sayama and Bar-Yam2003).
2.2. Information systems and co-simulation
ISs are artifacts that extend human cognitive limits, exchange information, record mental efforts and mediate critique and negotiation in design settings (Arias et al. Reference Arias, Eden, Fischer, Gorman and Scharff2000). Research on computer-supported collaborative design combines broader fields of computer-supported cooperative work and human–computer interaction to study the use of computers in design activities (Shen, Hao & Li Reference Shen, Hao and Li2008). Typical computer-supported functions include visualization, cross-disciplinary information exchange and integrated life cycle analysis (Li & Qiu Reference Li and Qiu2006), and common challenges include interoperability, integration, facilitation and change management (Shen et al. Reference Shen, Hao, Mak, Neelamkavil, Xie, Dickinson, Thomas, Pardasani and Xue2010).
Model-driven or model-centric design activities leverage ISs to capture and exchange disciplinary knowledge across team members through a shared system model (Ramos, Ferreira & Barceló Reference Ramos, Ferreira and Barceló2012). Model creation helps facilitate learning by eliciting and formalizing knowledge, synthesizing new feedback loops to support or refute hypotheses and sharpening scientific (versus position-driven) solution skills (Sterman Reference Sterman1994; Vennix Reference Vennix1999). However, computer-based models can also pose barriers due to limited acceptance, insufficient time to complete a feedback loop, poor user-friendliness, high model complexity and inflexibility to incorporate issues of interest (de Kraker, Kroeze & Kirschner Reference de Kraker, Kroeze and Kirschner2011).
Alternative IS architectures balance centralized and distributed control over the design activity (Whitfield et al. Reference Whitfield, Duffy, Coates and Hills2002). Centralized control exerts strict requirements on modelling languages, interfaces or even model co-location, which permits more efficient or effective solution processes (i.e., MDO) but presents practical challenges in participatory settings, especially across organizational boundaries where cultural or even legal issues may limit ceding of control. Distributed control schemes push integration requirements to more abstract layers which brings additional challenges of higher network and processing requirements and added overall complexity.
Long-running efforts dating to the early phases of CE seek to improve distributed design by encapsulating, rather than standardizing or unifying, tool data and models (Cutkosky et al. Reference Cutkosky, Engelmore, Fikes, Genesereth, Gruber, Mark, Tenebaum and Weber1993). The broader topic of model interoperability describes the ability of ‘multiple separate entities to interact, collaborate or utilize each other to achieve higher-level goal or their own goals’ and can be applied at multiple levels ranging from technical interconnectivity to programmatic coordination (Mordecai, Orhof & Dori Reference Mordecai, Orhof and Dori2016). Increasing degrees of model interoperability enforce common information exchange protocols, syntax, semantics for static interactions and shared knowledge of methods, state changes and overall assumptions for dynamic interactions (Tolk, Daillo & Turnitsa Reference Tolk, Daillo and Turnitsa2007).
Co-simulation is a technique to couple the execution of multiple simulators to facilitate dynamic information exchange across disciplines, domains or organizations (Gomes et al. Reference Gomes, Thule, Broman, Larsen and Vangheluwe2018). Co-simulation methods range from acausal continuous time modelling languages which align constituent models through dynamic equations (Mattsson, Elmqvist & Otter Reference Mattsson, Elmqvist and Otter1998) to general discrete event frameworks which build on parallel and distributed simulations to synchronize state and maintain causality across multiple logical processes (Fujimoto Reference Fujimoto2000). Current standards include the Functional Mockup Interface (Modelica Association 2019) for continuous time simulation and HLA (IEEE 2010) for discrete event simulation.
Simulation-based methods for infrastructure systems still face difficulties with sharing models and data across organizational boundaries, considering both hard and soft infrastructure, exchanging mutual dependencies, and validation for novel or unexpected scenarios (Ouyang Reference Ouyang2014). Co-simulation must overcome differing timescales and resolutions or fidelity of component models (Pederson et al. Reference Pederson, Dudenhoeffer, Hartley and Permann2006). Each domain carries different assumptions, data dependencies and numerical requirements for time step sizes, scaling limits or computational algorithms that generally limit the adoption of existing domain-specific models (Rinaldi, Peerenboom & Kelly Reference Rinaldi, Peerenboom and Kelly2001). Applications of standards like HLA for co-simulation have thus far been limited due, in part, to industry focus on inexpensive, limited and disposable models using commercial off-the-shelf packages compared to the relatively expensive runtime infrastructure (RTI) licenses, general-purpose programming language, high complexity and limited community of experts for HLA (Boer, de Bruin & Verbraeck Reference Boer, de Bruin and Verbraeck2009). Alternative options study simpler service-oriented architectures for infrastructure modelling with centralized event processing and significantly reduced functionality (Tolone et al. Reference Tolone, Johnson, Lee, Xiang, Marsha, Yeager, Blackwell, Setola and Geretshuber2008).
2.3. Simulation gaming
Applications of simulation to co-design problems where participants role-play decision-making actors in an interactive design session can be described as simulation gaming or, simply, gaming (Grogan & Meijer Reference Grogan and Meijer2017). Simulation emphasizes technical system behaviour that can be represented with a computational model, whereas gaming emphasizes distinctly human and social behaviour such as cognitive bias, bounded rationality, culture, politics, strategy, ethics and morality. Compared to static dependencies in engineering co-design, simulation gaming exchanges dynamic dependencies over a simulated timeline. Repeated interactions between role players contribute to complex interdependencies and conflicts. Partly an exploratory device and partly an experimental platform games have been applied over a substantial history to study a wide range of collective decision-making problems spanning military tactics, supply chain logistics, international crises and urban planning (Mayer Reference Mayer2009).
A series of ‘infragames’ developed over the past two decades apply gaming methods to study infrastructure planning problems. While each game focuses on a different problem, common features emphasize collaborative decision-making and strategic behaviours. For example:
(i) The Urban Network Game seeks insights to opportunities and threats to developing urban networks of cities with good transportation connectivity (Mayer et al. Reference Mayer, Carton, de Jong, Leijten and Dammers2004);
(ii) Infrastratego studies strategic behaviour in a liberalizing Dutch electricity market and effectiveness of different regulatory regimes (Kuit, Mayer & de Jong Reference Kuit, Mayer and de Jong2005);
(iii) SprintCity studies the interrelations between rail infrastructure and urban development near stations (Mayer et al. Reference Mayer, Meijer, Nefs, Gerretsen and Dooghe2010; Nefs et al. Reference Nefs, Gerretsen, Dooghe, Mayer and Meijer2010); and
(iv) SimPort-MV2 demonstrates complexities of a large land reclamation project at the Port of Rotterdam in the Netherlands (Bekebrede, Lo & Lukosch Reference Bekebrede, Lo and Lukosch2015).
Each game uses simulation to a different degree to model technical infrastructure systems, but all focus on the participatory decisions to either generate insights about a domain-specific problem (e.g., strategic behaviours in electricity markets for Infrastratego) or develop generalizable knowledge for a class of problems (e.g., managing complex infrastructure for SimPort-MV2). Usually structured as an interactive simulation, role players input decisions to a simulation model which computes and disseminates results throughout a dynamic scenario. Not all games require high-tech ISs to achieve simulation objectives, and using simple physical props such as sponges to represent train positions can facilitate rapid system development and prototyping (Meijer Reference Meijer2015).
While a body of literature addresses design of simulation games as ‘design-in-the-small’ (see Klabbers Reference Klabbers2003), no comparable literature considers co-simulation, because, in most cases, a centralized IS satisfies all research goals and is easier to implement. Research principals, rather than participants, develop technical simulations for games like SimPort-MV2 and Infrastratego to focus studies on collaborative processes. Gaming applications of co-simulation only appear in domains with a precedent for co-simulation in practice such as defence and emergency response (Prasithsangaree et al. Reference Prasithsangaree, Manojlovich, Hughes and Lewis2004; Jain & McLean Reference Jain and McLean2008).
2.4. Research objectives
To synthesize preceding sections, Figure 1 illustrates the relationship between engineering co-design, simulation gaming and co-simulation (the diagram is not exhaustive of all methods in the two-dimensional space). Engineering co-design uses technical solution processes like MDO, MBSE and CE to solve a design problem by communicating static dependencies between design actors. Centralized IS architectures integrate all information in a single model, whereas a decentralized IS provides distributed control over constituent models. Simulation gaming draws on a broader set of negotiated solution processes to exchange dynamic dependencies between actors in a game session; however, existing gaming methods use centralized IS contributed by a principal rather than participants. Co-design with co-simulation seeks to exchange dynamic information dependencies within a collaborative process (like simulation gaming) while providing decentralized control over constituent models.
Figure 1. Co-design with co-simulation supports dynamic information dependency with decentralized control over constituent IS components (models).
Co-design with co-simulation spans both technical integration and social collaboration to build shared understanding of dynamic dependencies in large-scale engineering systems like infrastructure systems where there may be significant barriers to centralize technical components. However, there remains a gap to understand how co-simulation contributes to technical and negotiated solution activities. Within the context of a representative infrastructure planning scenario, this paper addresses the top-level research question:
How can co-simulation artifacts technically integrate and provide dynamic information exchange among design actors during co-design activities?
The response follows a design science research methodology (Hevner et al. Reference Hevner, March, Park and Ram2004) to create and evaluate the utility of a co-simulation IS artifact in a co-design setting. In other words, the equivalent research hypothesis is that co-simulation provides utility for co-design settings through dynamic information exchange.
The following sections develop a representative co-design scenario based on a 30-year strategic infrastructure planning activity for a fictional desert nation. Three role players control infrastructure systems with dynamic resource dependencies while pursuing individual and joint sustainability objectives. Technical details of a prototype co-simulation artifact explain how the HLA standard integrates constituent system models with decentralized control. Finally, an observational human subjects study evaluates the co-simulation artifact for co-design by investigating what game dynamics emerge between design actors and analysing how co-simulation features influence design processes and outcomes.
3. Sustainable Infrastructure Planning Game
This section discusses the design and implementation of the Sustainable Infrastructure Planning Game as a co-design scenario and co-simulation artifact that uses the HLA standard (IEEE 2010) to technically integrate constituent infrastructure system simulations. Although the underlying concepts are generalizable to any infrastructure system, SIPG draws on a specific design scenario for a fictional desert nation loosely based on contextual features of Saudi Arabia between 1950 and 2010. It defines three player roles who exert control over agricultural, water, and energy infrastructure systems with objectives based on multidimensional system attributes. Some objectives are aligned towards collective sustainability objectives, whereas others are in conflict between roles.
3.1. Co-design scenario
The SIPG co-design scenario is a strategic planning exercise to create a 30-year infrastructure development plan for Idas Abara, a fictional desert nation with a petroleum-based economy. The scenario takes place in the year 1980, as infrastructure pressures mount from resource demands of rapid population growth and urbanization. Urban, industrial and rural geographic regions illustrated in Figure 2 aggregate infrastructure, each with unique population dynamics and suitability for new infrastructure projects. The urban and industrial regions can access seawater for desalination, the industrial region has vast (but finite) oil reservoirs and the rural region has plentiful arable land.
Figure 2. Urban, rural and industrial regions of a fictional desert nation.
Viewing the scenario from the driver-pressure-state-impact-response framework (Tscherning et al. Reference Tscherning, Helming, Krippner, Sieber and Gomez y Paloma2012), driving forces are linked to a rapidly growing and urbanizing population. In addition to annual population growth rates exceeding 3%, urban lifestyles increase per-capita demands for food, water, oil and, most significantly, electricity (e.g., for air conditioning). Environmental pressures include withdrawals from nonrenewable ‘fossil’ water aquifers and oil reservoirs and increased emissions. The potential impacts of environment changes are wide-reaching and significant – depletion of water resources has dire consequences for society (broadly) but also limits efforts to diversify the economy through agriculture. Reduction of oil resources from reservoir depletion can also trigger a financial crisis, as oil exports currently sustain the national economy. While only a small piece of sustainability, the response considered in this scenario develops a strategic infrastructure plan to provide necessary resources while sustaining economic and environmental conditions.
The design scenario includes player roles for agricultural, water and energy (oil and electricity) sectors and a nonplayer role for all other societal activities such as commercial and residential demands. Players choose when and where to construct and operate new infrastructure elements within their sector to transform or transport resources to meet societal demands. Each infrastructure element consumes capital expenses during construction and operational expenses during its life cycle. A nationwide budget limit establishes a soft constraint on the capital expenses allowed each year. Plans that exceed the annual budget limit are permitted with notation of the overbudgeted period(s).
Co-design activities identify new capital projects to supplement existing infrastructure and simulate resource production and distribution over the 30-year planning period. Simulation outputs quantify several metrics to inform decision-making. Iterative design and evaluation helps to uncover coordination challenges in pursuit of four equally weighted joint sustainability objectives:
(i) Food security as the fraction of demands satisfied by domestic production;
(ii) Water security as the expected aquifer lifetime at current withdrawal rates;
(iii) Oil security as the expected reservoir lifetime at current withdrawal rates; and
(iv) Financial security as the net revenue of all infrastructure systems.
Design conflicts arise from three linked sources. First, interest to strengthen food security by increasing domestic food production puts additional demands for irrigation, greatly diminishing available water resources in nonrenewable aquifers. Subsequent efforts to increase desalination capacity greatly amplify pressures on power generation and domestic oil consumption, diminishing revenue from profitable oil export. Finally, efforts to increase renewable power generation require large capital expenses that compete with desalination projects for limited budget capacity.
3.2. Co-simulation platform and interfaces
This section formulates a co-simulation IS artifact to technically integrate role-specific constituent models and provide dynamic information exchange for the SIPG design scenario. Co-simulation requires an interface between each pair of dependent systems. To simplify the co-simulation architecture, this section adopts the infrastructure system-of-systems (ISoS) modelling framework (Grogan & de Weck Reference Grogan and de Weck2015) as a common interface among all constituent systems that can be implemented using the HLA (Grogan & de Weck Reference Grogan and de Weck2018). The ISoS framework defines contextual, structural and behavioural templates to guide constituent model development efforts. The interoperability interface defines a service contract for necessary start-up, synchronization and shut-down procedures to model resource exchanges across system boundaries.
The contextual template defines application-specific constructs for spatial and temporal boundaries. Nodes define geographic units of aggregation where resources can be freely exchanged. SIPG nodes represent the three regions (urban, industrial and rural). The time advancement strategy defines a common time step duration with several iteration periods to resolve dependencies. SIPG uses an aggregated 1-year time step with four iterative periods. Finally, a set of resource types describe the substances exchanged between systems. Key SIPG resources include water, electricity, oil, food and currency.
Structural templates define infrastructure elements as resource-conveying edges at or between nodes. Production and storage elements have the same origin and destination, whereas distribution elements have different origins and destinations. Elements assume a life cycle state that transitions between five sequential phases: empty (preinitiation), commissioning, operating, decommissioning and null (post-termination). Additional state variables set, for example, operational production, withdrawal or distribution levels during each time period.
Behavioural templates express four key infrastructure resource functions. Storing or retrieving functions add or remove resources from a stored stock or buffer. Transforming functions convert input resources at the source node to output resources at the destination node. Transporting functions move input resources at the source node to the destination node. Exchanging functions transfer resources from an origin in one system to a destination in another.
Co-simulation only disseminates resource exchanging behaviours across system boundaries. The HLA requires a shared federation object model (FOM) to describe the syntax and semantics of exchanged information and a federation agreement to document required activities during a simulation execution. As a component of the FOM, Table 1 describes key object attributes for constituent system elements (all inheriting from a base Element class). All attributes are aggregated to annual temporal scales and nodal spatial scales. Ideally, supply should meet demand for each resource type, for example, Food Out from the agricultural system should equal Food In for the co-located Societal System; however, an iterative convergence process driven by system controllers to optimize production under interdependency contributes small errors. Grogan & de Weck (Reference Grogan and de Weck2018) provide more details on the HLA implementation for interested readers.
Table 1. Key object attributes to exchange during co-simulation
Notes: Units: 
$ \S $: currency; GJ: gigajoule; MCM: million cubic metres; Mtoe: million tons oil equivalent; TWh: terawatt hour.
The resulting system-of-systems model in Figure 3 includes societal, agricultural, water and energy (electrical and petroleum) infrastructure systems at each node. Within each system, production elements transform raw to refined resources and distribution elements move resources between nodes. However, at the co-simulation level, dynamic interactions are characterized only by resource exchanges. Key resource flows supply water to the agricultural system for irrigation, electricity to the water and petroleum systems to power pumps, wells and desalination plants, and petroleum to the electricity system for thermal generation. The societal system consumes food, water, electricity and oil to satisfy demands and stores the net balance of currency.
Figure 3. Constituent infrastructure systems at each node dynamically exchange directed resources using interfaces defined by the co-simulation platform.
3.3. Constituent model implementation overview
The co-simulation interface defines directed resource exchanges between constituent models but not their internal state or behaviours which is private information for each role player. This section provides a brief overview of the objectives and available infrastructure models for agriculture, water and energy roles as examples of sensitive and domain-specific information that may not be shareable on a centralized IS platform. See Appendix A for detailed documentation of infrastructure models and Appendix B for formulation of objective metrics.
During a design session, each role player chooses the type, location and timing of new infrastructure projects during the planning horizon (1980–2010). Players have complete autonomy over infrastructure within their sector but have limited visibility of how their operations affect other sectors. A fixed set of project templates summarized in Table 2 (and detailed in Appendix A) defines available functional capabilities and capital costs for new elements. Infrastructure plans compose multiple projects within a sector and can be continuously revised during a design session. For example, a new desalination plant to be instantiated in the Urban region in 1990 can be modified to change the location (to meet demands elsewhere), timing (to meet annual budget limits) or cancelled altogether without penalty. Players can also schedule the early decommissioning of existing infrastructure projects, for example, halting operation of an oil well to decrease reservoir withdrawal rates. Co-simulation synthesizes infrastructure plans for all players and provides technical feedback about resource exchanges across sector boundaries (e.g., electricity consumption by desalination plants), capital expenses, operational revenue and individual and joint objective metrics.
Table 2. Available project templates for new infrastructure elements within each sector
Notes: Units: 
$ \S $: currency; EJ: exajoule; MCM: million cubic metres; Mtoe: million tons oil equiv.; TWh: terawatt hour.
The agricultural model controls land allocation for food production and roads to transport food between regions. Role-specific objectives are:
(i) Food security as the fraction of demands satisfied by domestic production;
(ii) Financial security as the net revenue of the agricultural system; and
(iii) Political power as the total capital allocated to the agricultural system.
Available infrastructure elements include small and large fields for production and small and large roads for distribution which are controlled at each time step to meet demands at minimum cost. Food production is constrained by arable land area and available workers as a fraction of population and requires water for irrigation. Regions export surplus food for a profit and import to meet deficits.
The water models controls desalination plants and nonrenewable (i.e., ‘fossil’) aquifer stocks. Role-specific objectives are:
(i) Aquifer security as the expected lifetime at current withdrawal rates;
(ii) Financial security as the net revenue of the water system; and
(iii) Political power as the total capital allocated to the water system.
Available infrastructure elements include small, large and huge desalination plants which are controlled at each time step to meet demands at minimum cost. Deficits in desalination supply require regions to lift water from aquifers and, when depleted, import at great expense. Both desalination and lifting require electricity. No transport of water is permitted between regions due to large pumping expenses.
The energy role composes both petroleum systems (oil wells and pipelines) and electrical systems (power plants) which are tightly coupled, because oil pumping requires electricity and thermal power generation requires oil as feed stock. Role-specific objectives are:
(i) Reservoir security as the expected lifetime at current withdrawal rates;
(ii) Financial security as the net revenue of the energy system; and
(iii) Political power as the total capital allocated to the energy system.
Available petroleum infrastructure include small and large well pumps for production and small and large pipelines for distribution. Available electricity infrastructure for generation include small and large thermal plants and small and large solar plants. All infrastructure elements are controlled at each time step to meet demands at minimum cost. Regions export surplus oil for profit, import oil to meet supply deficits and use low-efficiency ‘private’ thermal generation to meet electricity deficits.
3.4. Graphical user interface
A graphical user interface allows design actors to modify role-specific infrastructure systems, execute a co-simulation and view outputs. Inputs define a sector-specific infrastructure plan composing the type, location and time to build each new element. Outputs visualize key resource flows and quantify figures of merit associated with role objectives.
The input panel includes simulation controls and a list of existing elements. Simulation controls initialize and run a co-simulation execution. Figure 4a shows the current set of infrastructure elements, grouped by location. Players can add or edit new elements, choosing from a role-specific menu of templates in Figure 4b. Each infrastructure element displays key life cycle and operational information shown in Figure 4c such as capital cost, lifespan and resource production.
Figure 4. Input GUI components control simulation execution and edit infrastructure.
Simulation outputs are formatted in numerous plots and visualizations in Figure 5, which can be aggregated at the national level or separated by region. Common societal information such as sector-specific contributions to net revenue (Figure 5a) and capital expenditures compared to the annual budget limit (Figure 5b) are available to all players. Other sector-specific information such as net revenue breakdown by source (Figure 5c), resource sources and sinks (Figure 5d), state of natural stocks such as aquifers and reservoirs and quantified objectives are only visible to individual players.
Figure 5. Output GUI panels presents societal and sector-specific information for each player role.
3.5. Discussion and key limitations
The SIPG co-simulation artifact technically integrates constituent simulation models while providing decentralized control of constituent models and execution. The co-simulation interface prescribes the types of dynamic dependencies (directed resource exchanges in this scenario) but neither discloses the implementation details of any constituent model nor requires constituent models to be centrally located or shared for execution. These features help overcome legal, proprietary or simply organizational hurdles to co-design by allowing each design actor to manage and control a component of the technical simulation.
The SIPG scenario and underlying model have been purposefully simplified to facilitate short-duration interactive co-design sessions with nondomain experts. Although many of the underlying concepts are general and could accommodate more realistic or higher-fidelity models, the several key assumptions in Appendix A.5 limit the direct application of results to real-world planning.
Adopting the HLA co-simulation standard carries some technical limitations. First, all constituent members must use the same RTI implementation, and the most capable ones are commercially licensed. Furthermore, while there is no strict constraint on model implementation, most RTIs only provide Java and C/C++ language bindings. In addition, all constituent members must be connected to a common local- or wide-area network configured to allow RTI messages. Finally, any changes to the co-simulation interface, such as adding a new resource dependency, must be documented in the FOM and shared with all members.
The HLA is not the only viable IS architecture for co-design. A broader set of more modern service-oriented and event-driven IS architectures can capably support decentralized information exchange between constituent applications. However, simulation-specific features like time management prove challenging for general-purpose IS software which typically operate under real-time assumptions. Technical considerations of alternative IS architectures are outside the scope of this initial effort to evaluate co-design with co-simulation.
4. Observational co-design study
This section formulates an observational study to evaluate the utility of dynamic exchange of technical information provided by the SIPG co-simulation artifact in a co-design setting. Refined study objectives investigate what game dynamics emerge from interactions between design actors and how co-simulation features influence co-design processes and outcomes.
4.1. Study objectives
As reviewed in Section 2, prior literature identifies methods and processes to improve outcomes of engineering design through technical integration and social collaboration. The SIPG scenario exhibits two perspectives on desired outcomes. Each role objective is part of a multiattribute function where nondominated solutions form a Pareto-efficient frontier. However, perceived inequity and importance limits desirable solutions to a subset of the efficient frontier that emphasizes synergies across roles. The joint objective identifies synergistic components of individual role objectives that contribute to shared sustainability goals. While it can be conceived of as a holistic single-attribute objective function, in practice, the joint objective only provides effective weighting for role-specific objectives. Thus, from an observer’s perspective, desired SIPG outcomes maximize the joint objective, but, from a participant’s perspective, desired outcomes maximize role-specific and joint objectives as a multiattribute function with variable weightings from person to person.
To evaluate the SIPG co-simulation artifact’s ability to communicate dynamic dependencies using a decentralized IS architecture, this observational study pursues two refined research questions:
What game dynamics related to tensions between role-specific and joint objectives in the SIPG scenario emerge from player interactions?
How does dynamic information exchange provided by co-simulation influence technical exchange and pursuit of role-specific and joint objectives?
The first question characterizes the dynamical relationships between player roles to identify key information dependencies within the limiting SIPG co-design context. Key resource exchanges such as water for irrigation, electricity for desalination and currency for capital expenditures are hypothesized to generate conflict between player roles which must be addressed in co-design activities. Analysis of game dynamics compares intermediate and final role-specific and joint objectives to identify tensions in co-design sessions.
Reflecting on SIPG game dynamics that drive a need for co-design, the second question investigates how co-simulation technology influences design activities through dynamic information exchange. Co-simulation is hypothesized to support collective sense-making by communicating resource dependencies as the underlying source of role conflict, allowing role players to identify and manage technical problems within a negotiated solution processes. Analysis compares technical data exchange during design and resulting role-specific and joint outcomes across co-design sessions including variants structured to differentiate co-simulation features.
4.2. Study conditions
This study uses SIPG as the IS platform for a co-design activity. It is structured as a between-subjects study with a design session as the unit of analysis. Two major variants represent co-design environments with strong and weak adoption of co-simulation to probe the effectiveness of dynamic technical interactions. While representing distinct conditions, the study design is not a highly controlled experiment to understand specific effects of experimental variables on outcomes. Rather, it establishes an observational study to gather initial insights on use of co-simulation technology within a co-design process. The overall study includes 15 co-design sessions equally distributed across three total variants described below.
Variant 1 in Figure 6 models co-design with strong adoption of co-simulation to support dynamic technical interaction. It co-locates the three design stations at a central table and adopts a synchronous mode of information exchange where each participant controls local design inputs but all three must simultaneously run a simulation to update outputs. To trigger a simulation execution, a participant must first click the ‘Initialize’ button (loop icon at top left in Figure 4a). After all three participants complete initialization, the ‘Execute’ button (play icon at top right in Figure 4a) unlocks. After all three participants click the ‘Execute’ button, the simulation runs on all three design stations in approximately 10–20 seconds, populating analysis results and outputs in Figure 5.
Figure 6. Design station layout and operational activity diagram for Variant 1 which models strong adoption of co-simulation to support dynamic interaction with synchronous exchange and co-location.
A secondary inquiry into joint objectives disseminated in qualitative or quantitative form influenced the study design. The qualitative form (Variant 1B) identifies the four components of joint objectives (i.e., food, water, oil and financial security) in briefing materials. The quantitative form (Variant 1A) provides the joint objective in numeric form that is updated after each execution. Both variants receive role-specific objectives in a quantitative form.
Variant 2 in Figure 7 models co-design with weak adoption of co-simulation with mild barriers to dynamic interaction. It isolates design stations at tables several feet apart and adopts an asynchronous mode of information exchange based on importing and exporting static data files. Rather than performing dynamic data exchanges, resource flows at each time step can be saved in a data file and manually transferred between design stations using a shared network folder. Participants retain local control over imports, execution and exports, but moderate discrepancies may arise from out-of-date information. To trigger a new simulation execution after making design changes and/or importing external data, a participant clicks ‘Initialize’ and ‘Execute’ to immediately populate analysis results. Outputs can later be exported to file format for sharing.
Figure 7. Design station layout and operational activity diagram for Variant 2 which models weak adoption of co-simulation with asynchronous exchange and isolated design stations as barriers to dynamic interaction.
Study observations record intermediate data during the design activity and outcomes at the end of the design activity. Automatic computer logs record all intermediate design decisions and associated metainformation such as timestamps after each simulation execution. While participants are permitted to converse freely and move about the room, no audio or video is recorded. Postprocessing tabulates the time and frequency of data exchange actions as process variables, infrastructure plans as design inputs and objective metrics as design outputs. One data exchange corresponds to a joint simulation execution for Variant 1 and new data file export from all three roles for Variant 2.
4.3. Study procedure
Following an approved protocol (MIT #1302005518), the study recruited 15 groups of three participants from a convenience sample of engineering graduate students (multiple disciplines) without compensation. Table 3 summarizes subject demographics. Participants were majority male (64.4%) and 25–29 years of age (71.1%) with more college education than work experience. Most participants had never interacted with each other in the past (58.9% of pairs), although a subset (25.6%) interact on at least a weekly basis. Inspection yields no significant demographic differences between conditions, but the observed demographics may limit generalization of results beyond the sampling frame.
Table 3. Summary of participant demographics
Design sessions are scheduled when three volunteers are available to form ad hoc groups and are conducted in classrooms. Conditions are assigned in partially randomized order with the first eight randomly assigned Variant 1A or 1B and the last seven randomly assigned Variant 2 or 1B. At the start of the session, subjects receive a role and colour assignment (energy: red, agriculture: green, or water: blue) and sit on one side of a rectangular design station with the fourth seat reserved for the researcher. After introduction, subjects either remain at the central design station (Variant 1) or move to adjacent design stations (Variant 2).
Participants may exit the study at any point; however, no such events occurred. A 15-minute scripted presentation introduces the design context including the three regions (industrial, rural and urban), infrastructure within each sector, resource interdependencies, operational behaviours in the simulation model, other assumptions for price and cost, budget and time constraints and a description of joint objectives. Subjects also receive a confidential sheet describing individual objectives and an overview of key issues in their respective role. Participants may share the confidential information or keep it private. Next, a 15-minute tutorial introduces the subjects to the software tool including simulation inputs (existing elements and available templates), execution control buttons (initialize and run) and a walk-through of all output screens.
After completing addressing any related questions, subjects enter a 60-minute timed design period. Subjects are allowed to move about the room, converse freely with each other and share their display during the design session, but may not change the room layout. Subjects can also ask the researcher for additional information not displayed in the GUI, clarifications on model assumptions or other questions excluding advice on design decisions. The researcher updates the remaining time at several points during the session. At the end of the timed period, the researcher leads a debriefing session to explain the study objectives and probe experiences and observations from the design session.
4.4. Limitations and threats to validity
This study has several limitations which pose threats to the validity of results. First, it does not employ a highly controlled design to study context differences between variants. Rather, the two major variants (1 and 2) are only intended to characterize low and high adoption of co-simulation, and the two minor variants (1A and 1B) change visibility of joint objectives. More importantly, group processes are largely uncontrolled during design sessions. Subjects are not constrained to follow a particular process for design, nor are there limits on discussion or sharing of information. Furthermore, there are no imposed preferences for individual versus shared objectives. This lack of control introduces additional variation that limits the causal strength of conclusions.
This design does not fully leverage randomization of conditions for practical reasons. Groups are formed as participant schedules allow rather than completely randomly. Potential biases are partially mitigated by the nonpurposeful assignment of conditions to sessions which are randomly assigned except for Variant 2 which is limited to the second half of sessions. The ordering effect may bias results due to researcher maturation effects and is partially mitigated by adhering to a common scripted introduction and tutorial across all sessions.
Author participation in the design sessions introduces additional potential biases, especially as subjects are sampled from peer groups and the author is the developer of SIPG. Scripted introduction and tutorial materials and passive participation to only respond to direct questions mitigate some concerns; however, the possibility of additional biases must be acknowledged.
Several factors limit the generalizability of results beyond the design sessions considered. Previously discussed limitations in the SIPG model and scenario limit direct extensions to real-world cases. Similarly, the sampled population purple (engineering graduate students at a U.S. university) is not representative of infrastructure planners, although backgrounds in technical areas may be similar. There are also potential reactive effects of experimental arrangements. Participants work in ad hoc teams and are not required to have background experience with infrastructure systems. Design sessions are conducted in general-purpose classrooms using unfamiliar software tools that requires a large portion of the design time to simply comprehend the task. Finally, participants working in a finite, fictional session may not fully consider the implications of decisions having great socioeconomic impact in the real world.
5. Study results, analysis and discussion
This section reports results of the observational SIPG study to investigate the game dynamics and how co-simulation features support co-design activities. An overview first describes the collected data and overall features and relationships. Analysis of game dynamics characterizes the tensions between SIPG roles. Additional analysis evaluates how co-simulation features influence design processes and outcomes. Finally, discussion explains the analysis results within the context of SIPG and more broadly for co-design for engineering systems.
5.1. Overview of results
Data postprocessing aligns all design decisions on a single timeline to normalize asynchronous and synchronous sessions. Table 4 summarizes results at the end of the 60-minute design period for all 15 sessions sorted by variant. Six sessions violated annual budget constraints in one or more years. Inspection shows budget violations are small and isolated to a few years which could be alleviated by adjusting planning schedules to yield similar results. Thus, the final role-specific and joint objective metrics observed are characteristic of valid strategic plans.
Table 4. Summary of design conditions, demographic factors and outcomes by session
Notes: Demographics: 
$ {D}_1 $: num. Female; 
$ {D}_2 $: avg. age; 
$ {D}_3 $: avg. education; 
$ {D}_4 $: avg. work; 
$ {D}_5 $: avg. monthly interactions.
a Final plan exceeds budget limit in one or more years.
Preliminary analysis performs two-way analysis of variance with Python library statsmodels (v0.12.0) function anova_lm for each aggregate team demographic factor to check for significant effects on outcome observations. Multifactor effects are not considered due to multicolinearity effects and limited sample size, and a Jarque–Bera diagnostic test checks normality assumptions. Age (
$ {D}_2 $), education (
$ {D}_3 $) and work experience (
$ {D}_4 $) aggregated to average team values using lower bounds of item ranges have no significant effect on number of exchanges, role-specific objectives or joint objectives. Gender as the number of females (
$ {D}_1 $) shows a significant effect only on the energy objective (
$ F\left(1,13\right)=4.77,p=0.048 $) and team familiarity, as the average number of interactions with other participants per month (
$ {D}_5 $) shows a significant effect on the water (
$ F\left(1,13\right)=8.78,p=0.011 $) and energy (
$ F\left(1,13\right)=7.06,p=0.020 $) role objectives. Additional investigation is required to determine whether gender and team familiarity demographic differences are practically significant.
5.2. Analysis of game dynamics
As recorded observations are limited to computer logs from simulation executions, this section includes some qualitative observation remarks from the author to supplement quantitative analysis of recorded data. Note that analysis reports objective ranks (rank 1 is the smallest and rank 
$ N $ is the largest of 
$ N $ values) rather than scalar values to better represent objectives on an ordinal scale.
A time series of role-specific and joint objective ranks after each exchange (one synchronous co-simulation execution or asynchronous data export by all three roles) in Figure 8 with a locally weighted scatterplot smoothing (LOWESS) overlay visualizes temporal dynamics. Teams typically spend the opening minutes independently investigating the assigned individual and joint objectives, results of the baseline scenario and the space of alternative designs. The first exchange often does not occur until 10 or 15 minutes into the 60-minute session. Typical first design changes seek to establish causal understanding within each role. For example, the agriculture player adds food production elements to gauge the magnitude of effect on improving food security or irrigation water demands.
Figure 8. Time series of objective ranks by session variant with locally weighted scatterplot smoothing.
During the first 30 minutes, agriculture and energy role objectives rise, but water and joint objectives fall. Players typically follow three strategies during this period: (1) increase food production to improve domestic food security; (2) increase water desalination to improve aquifer security and (3) increase electricity generation to improve oil consumption efficiency and restore export revenue. Expanding food production improves agriculture and joint objectives but also leads to excess water demands that can reach several multiples of the baseline societal demand. Expanding water production with desalination plants can only satisfy a fraction of the irrigation demand, eventually leading to dire aquifer security consequences for water and joint objectives. Expanding electricity generation with efficient thermal and solar power plants boosts revenue by restoring oil export capacity, increasing the energy and joint objectives.
Activities during the last 30 minutes shift to mitigating huge financial burdens of importing water as the most severe consequences of aquifer depletion. The water player controls information about aquifer health which must be communicated to other players to diagnose and correct structural problems. In addition, merging plans for costly water and energy infrastructure often require rephasing to adjust the starting time of planned projects to fit within the annual capital budget limit. Other issues to be addressed during this period include: balancing food production constraints from a limited labour force, expanding food transport capacity between supply and demand regions, balancing revenue from oil export with reservoir security and expanding oil pipeline capacity between regions. Not all teams have sufficient time to address all issues, contributing to a wide distribution of role-specific and joint objectives.
To quantitatively visualize role relationships, Figure 9 shows a scatter plot matrix of role-specific and joint objective ranks for all 128 observed initial, intermediate and final designs. Final designs close to the Pareto frontier for each pair highlight active constraints as evidence of tension. For example, most final designs fall near the agriculture/water Pareto frontier, indicating a fundamental tension between the two roles linked to irrigation based on the narrative above. Inspection of the role-specific/joint Pareto frontiers shows substantial variability in active constraints across sessions and many dominated points, suggesting the allocated design time was insufficient to converge to a final plan.
Figure 9. Scatter plot matrix of objective ranks for all design iterations. Black circles annotate final selections.
Spearman rank sum correlation coefficients computed using Python library SciPy (v1.5.0) function spearmanr in Table 5 summarize role relationships across all 113 observed intermediate and final designs. Agriculture and water role objectives show negative correlations (
$ p=2.7\cdot {10}^{-3} $) attributed to irrigation demands on aquifers. Agriculture and energy roles show positive correlations (
$ p=4.1\cdot {10}^{-12} $) which is likely due to a confounding factor (i.e., both generally increase over time). Joint objectives show positive correlation with water (
$ p=0.030 $) and energy (
$ p=2.3\cdot {10}^{-5} $) role objectives.
Table 5. Spearman correlation coefficients for role-specific and joint objectives
* p < 0.05.
** p < 0.01.
*** p < 0.001.
5.3. Analysis of co-simulation features
This section evaluates the effect of co-simulation features on outcomes by comparing major session variants with strong (1) and weak (2) adoption of co-simulation and correlating process and outcome variables across all sessions. Process variables include the number of data exchanges, and outcome variables include role-specific and joint objectives.
Initial analysis inspects for differences in process or outcome factors between minor variants (1A and 1B) using a small-sample two-tailed Mann–Whitney U test computed by hand. Results show the minor variant has no statistical effect on data exchanges, role-specific objectives or joint objectives. Subsequently, observations from Variants 1A and 1B are pooled for further analysis.
Subsequent analysis inspects for differences in process or outcome factors between major variants (1 and 2) using a small-sample two-tailed Mann–Whitney U test computed by hand. Results show only a significant difference in number of data exchanges (
$ U=8,p=0.04 $) between the two variants.
Figure 10 compares the number of data exchanges with final objective rank across all sessions with a LOWESS overlay to visualize trends. The joint objective shows the strongest correlation with number of data exchanges, verified by a significant Spearman rank sum correlation coefficient (
$ r=0.534,\hskip0.5em p=0.036 $) computed using Python library SciPy (v1.5.0) function spearmanr.
Figure 10. Scatter plot of data exchanges and objective ranks with locally weighted scatterplot smoothing.
5.4. Discussion of study results
The first study question asked:
What game dynamics related to tensions between role-specific and joint objectives in the SIPG scenario emerge from player interactions?
Observations and analysis results show strongest tensions between agriculture and water roles driven by water demands for irrigation. A distinct temporal feature shows design actions to increase agricultural production early in a session negatively affect water and joint objectives. Later actions identify and mitigate the water resource problem to partly recover both water and joint objectives. This game dynamic is particularly challenging, because the water role player controls the critical information about aquifer state but has limited ability to independently address the problem by increasing desalination capacity. In contrast, the energy role has no similarly strong tensions. Design actions to expand energy infrastructure directly contribute to both role-specific and joint objectives. While desalination capacity contributes to electricity demand, there are no similar dependencies on energy resource flows for other roles.
The observed SIPG game dynamics share some similarities with the historical case of Saudi Arabia (DeNicola et al. Reference DeNicola, Aburizaiza, Siddique, Khwaja and Carpenter2015). Agricultural expansion in the 1980s significantly increased groundwater withdrawals from aquifers. Desalination projects, while largest in the world, only contribute a small fraction of total water demands. Policy efforts over the past decade have moved to reduce agricultural production and import water-intense products as a type of ‘virtual water’, but there remain significant challenges to sustain the rapidly growing and urbanizing population. Complicating the historical comparison, scientific knowledge about aquifers has improved dramatically since the 1980s, contributing to changing understanding of sustainability implications of their depletion. Nevertheless, parallels to water as a focal role with limited independent ability to change outcomes helps establish importance of dynamic information exchanges.
The second study question asked:
How does the dynamic information exchange provided by co-simulation influence technical exchange and role-specific and joint objectives?
Two major variants (1 and 2) modify co-design settings to represent strong and weak adoption of co-simulation. While both variants exchange dynamic resource dependencies using simulation, Variant 1 is synchronous and Variant 2 is asynchronous. From a practical perspective, Variant 1 simplifies data exchange by running a single co-simulation execution but also couples design iterations across roles by requiring group consensus to run. In contrast, Variant 2 simplifies simulation execution by decoupling role-specific design iterations but requires more steps to export and import static dependency files. Analysis results show Variant 1 sessions have a larger number of data exchanges than Variant 2; however, it cannot be determined whether this difference is driven by ease of use or simply because co-simulation is required to observe simulation results.
Looking across all design sessions, analysis results show technical data exchange is positively correlated with joint objective outcomes. While causation cannot be determined, it is plausible that data exchange helps to compute and identify the resource dependencies underlying tensions between roles. More frequent data exchange (up to a limit) may help identify sources of poor-performing designs and convene negotiation activities to propose alternatives. More detailed observational data, such as the activities of each role player during the session to see if social discussion follows co-simulation execution, would help evaluate this hypothesis. Synchronous co-simulation in Variant 1 facilitates technical data exchange but cannot statistically be linked to better joint objective outcomes, in part, due to small sample sizes and high outcome variability.
Table 6 inspects the number of simulations conducted for Variant 2 sessions to further investigate design activities without dynamic exchange from co-simulation. Figure 11 illustrates linear trends between simulations conducted and resulting objective ranks (note that rank sum correlations are large but not statistically significant due to small sample size). The ability to conduct independent simulations for roles like the agriculture player may indeed harm pursuit of joint objectives, because they obscure key insights (e.g., aquifer depletion) by referencing static dependencies and further delay its acquisition by expending effort on local objective maximization rather than coordination and data exchange. In contrast, decoupled simulation may help more independent roles like the energy player achieves individual and joint objectives.
Figure 11. Scatter plot of asynchronous simulations conducted and objective ranks for Variant 2 sessions with linear trend overlay and Spearman rank sum correlation annotation (with 
$ p $-value).
Table 6. Summary of role-specific simulation executions and objective ranks in asynchronous sessions
Finally, this discussion must mention the many limitations of above results. Similar to other research applications of simulation gaming, establishing highly controlled and large-sample human studies with rich contextual applications is challenging and often impossible. The discussion provided here balances quantitative conclusions (where possible) with observational insights to inform future work. Some of the most important limitations relate to unobserved or uncontrolled factors that contribute to large observed variation. For example, the recorded computer logs only contain a fraction of the communication between role players, and more complete records would capture conversations and movements about the room to observe collaborative activities. In addition, stronger controls on team demographic factors would help understand differential effects of domain knowledge, team familiarity, communication style and a myriad of other factors known to influence group work. The relatively high task complexity of the SIPG scenario and limited session duration may also benefit from estimates of cognitive workload to understand group-level differences in comprehension and control exerted over the design problem.
5.5. Implications for co-design with co-simulation
Beyond the SIPG scenario-specific questions above, the observational study evaluates co-simulation in a co-design setting to answer the top-level question:
How can co-simulation artifacts technically integrate and provide dynamic information exchange among design actors during co-design activities?
The technical design of the SIPG co-simulation artifact identifies directed resource flows as the primary dependency between design actors. Synchronous co-simulation exchanges dynamic resource dependencies and computes their effects on design outcomes as a precursor to negotiated solution processes. In contrast, co-design without co-simulation can adopt technical solution processes like local objective optimization in the absence of structured collaborative processes. Differences in co-design settings appear most important when roles exhibit strong conflicts or tensions, such as the agriculture and water roles in SIPG. The higher cost of co-simulation may only be beneficial in such settings where it exposes critical dependencies.
Quantitative conclusions of the observational study are limited due to high outcome variability and imperfect comparison cases to truly evaluate the effect of co-simulation. Results emphasize a process-oriented perspective by evaluating differences in the co-design activity like the number of data exchanges as a type of coordination behaviour associated with desired joint outcomes. Future studies should seek to provide additional evidence for causal links between process and outcome factors to focus IS development on supporting specific processes.
Finally, results from the SIPG scenario represent only a narrow perspective on co-design focused on engineering decision-making. Results may not generalize to other types of co-design settings with different types of game dynamics and tensions among player roles. Furthermore, other co-design applications such as participatory integrated assessment and simulation gaming frequently consider a broader set of design actors including policy-makers, consumers and community members who play different roles than decision-makers, yet also represent key constituents in infrastructure planning.
6. Conclusion
Co-design spans both technical integration and social negotiation perspectives important to address engineering systems challenges of societal significance. Co-simulation encompasses a type of supporting IS that permits dynamic information exchange between design actors. Co-design benefits from co-simulation as a source of technical information structured within in a social activity that can make visible issues of shared interest in pursuit of joint objectives.
This work demonstrates a co-simulation artifact for a strategic infrastructure planning co-design scenario that draws some parallels to Saudi Arabia between 1950 and 2010. Three player roles control agricultural, water and energy (electricity and petroleum) infrastructure to satisfy demands of a nonplayer societal role. The co-simulation artifact exchanges directed resource flows, as players design new infrastructure in pursuit of role-specific and joint objectives.
Co-simulation standards such as the HLA provide a technical means to couple simulation executions but also require technical coordination to align temporal and spatial scales across constituent models. The SIPG co-simulation artifact adopts a graph-based framework with nodes to aggregate spatial resources and annual time steps to aggregate temporal behaviours and iteration to resolve interdependencies. While generally applicable to resource infrastructure systems, this work does not fully address challenges of integrating disparate spatial or temporal scales and coping with high cost and complexity of co-simulation.
An observational study using the SIPG artifact conducted 15 1-hour design sessions. Two session variants model strong and weak adoption of co-simulation with synchronous and asynchronous modes of simulation execution, respectively. Observed game dynamics emphasize conflict and tension between agriculture and water players regarding irrigation resource demands while the energy player remains more independent. Analyses across sessions show that co-simulation variants exhibit more numerous data exchanges and, across all sessions, data exchange is positively correlated with higher achievement of joint objectives.
While the results of this study are limited by the prototypical nature of the SIPG artifact and limited sample size with nondomain experts, they provide initial support for co-simulation applied to a co-design setting. Follow-up studies coupled with audio and video observational data and coding could answer deeper questions about how co-simulation supports or augments design activities at individual, rather than aggregate, levels. In addition, future work should explore alternative IS implementations to support co-simulation with reduced cost and complexity compared to the HLA. Even at relatively low levels of fidelity or detail, co-simulation activities have the potential to anchor co-design sessions with exchange of technical data and contribute to the joint inquiry and imagination necessary to address critical contemporary issues facing society.
Financial Support
This work was supported in part by a National Defense Science and Engineering Graduate (NDSEG) fellowship with equipment support (computers and HLA RTI license) from the Center for Complex Engineering Systems at the Massachusetts Institute of Technology.
Appendix A. Model implementation details
This section provides details on the sector-specific infrastructure system models. The notation 
$ \mathrm{\mathcal{E}}(n) $ gives the set of infrastructure elements originating at node 
$ n\in \mathcal{N} $, and 
$ {\mathrm{\mathcal{E}}}^{\prime }(n) $ gives the set of elements terminating at node 
$ n\in \mathcal{N} $.
A.1. Societal system model
The nonplayer societal role generates regional demands for food, water, oil and electricity as a function of population. Table 7 defines societal model properties for each node, loosely selected to fit the historical context of Saudi Arabia (in aggregate) between 1950 and 2010.
Table 7. Societal system node properties
Notes: Units: kcal: kilocalorie (Calorie); kWh: kilowatt hour; L: litre; toe: ton of oil equivalent.
A logistic growth function models population growth in each region, parameterized by a datum population 
$ {P}_0 $ at time 
$ {t}_0 $, a maximum long-term population (carrying capacity) 
$ {P}_{max} $ and logistic growth rate 
$ {r}_p $. The population of region 
$ n $ in year 
$ t $ is given by
$$ P\left(n,t\right)=\frac{P_{max}(n)\cdot {P}_0(n)\cdot {e}^{r_p(n)\cdot \left(t-{t}_0(n)\right)}}{P_{max}(n)+{P}_0(n)\cdot \left({e}^{r_p(n)\cdot \left(t-{t}_0(n)\right)}-1\right)}. $$ A logistic function also models growth in per-capita resource demands, parameterized by a minimum demand 
$ {d}_{min} $, maximum demand 
$ {d}_{max} $, datum demand 
$ {d}_0 $ at time 
$ {t}_0 $ and logistic growth rate 
$ r $. The per-capita demands for resource of type 
$ \tau $ in region 
$ n $ at time 
$ t $ is given by
$$ {d}_{\tau}\left(n,t\right)={d}_{min}^{\tau }(n)+\frac{\left({d}_{max}^{\tau }(n)-{d}_{min}^{\tau }(n)\right)\cdot \left({d}_0^{\tau }(n)-{d}_{min}^{\tau }(n)\right)\cdot {e}^{r_{\tau }(n)\cdot \left(t-{t}_0^{\tau }(n)\right)}}{\left({d}_{max}^{\tau }(n)-{d}_{min}^{\tau }(n)\right)+\left({d}_0^{\tau }(n)\hskip-0.5mm -{d}_{min}^{\tau }(n)\right)\cdot \left({e}^{r_{\tau }(n)\cdot \left(t-{t}_0^{\tau }(n)\right)}\hskip-0.8mm -\hskip-0.2mm 1\hskip-0.5mm \right)}, $$such that the societal demand for resource 
$ \tau $ in region 
$ n $ at time 
$ t $ is 
$ {D}_{\tau}^{societal}(n)=P\left(n,t\right)\cdot {d}_{\tau}\left(n,t\right). $
In addition, the societal system aggregates net revenues from each of the other system models. Sector-specific revenues include domestic and export sales. Expenses include domestic and import purchases as well as capital and operations costs. The currency stock is updated at each time step using net revenues from each regional infrastructure:
$$ {Q}_{currency}\left(t+\Delta t\right)={Q}_{currency}(t)+\sum \limits_{n\in \mathcal{N}}\left({Q}_{currency}^{agricul}(n)+{Q}_{currency}^{water}(n)+{Q}_{currency}^{energy}(n)\right). $$A.2. Agricultural system model
Agricultural system properties in Table 8 define prices for domestic, imported and exported food resources and set the workforce participation and arable land area for each node. The rural region has the largest workforce fraction and arable land area, but its low population does not demand as much food as other regions, presenting a logistical challenge for distribution.
Table 8. Agricultural system node properties
Notes: Units: 
$ \S $: fictional currency; GJ: gigajoule; km: kilometre.
Agricultural system element properties in Table 9 define two sizes of fields to produce food and two sizes of roads to transport food between regions. Larger infrastructure benefit from slight economies of scale. Players instantiate infrastructure from these templates to design a strategic plan.
Table 9. Agricultural system element properties
Notes: Units: 
$ \S $: fictional currency; EJ: exajoule; GJ: gigajoule; MCM: million cubic metres; TJ: terajoule.
The agricultural system is coupled with societal and water systems. Regional food demand arises from the societal system, 
$ {D}_{food}(n)={D}_{food}^{societal}(n) $. Water resources required to satisfy the operational plan at each node total
$$ {D}_{water}^{agricul}(n)=\sum \limits_{e\in \mathrm{\mathcal{E}}(n)}{f}_{land}^{water}(e)\cdot {q}_{land}^{use}(e). $$The agricultural system controller sets food production and transport levels in constituent infrastructure elements and determines the quantity of food to import and export at each node by solving the following linear program:
Find:
$$ {q}_{land}^{use}(e),{q}_{food}^{transport}(e)\hskip0.5em \forall \hskip0.5em e\in \mathrm{\mathcal{E}}; $$
$$ {q}_{food}^{import}(n),{q}_{food}^{export}(n)\hskip0.5em \forall \hskip0.5em n\in \mathcal{N}; $$Minimize:
$$ {\displaystyle \begin{array}{l}\sum \limits_{e\in \mathrm{\mathcal{E}}}\left({f}_{land}^{currency}(e)+{f}_{land}^{water}(e)\cdot {\pi}_{water}^{local}\right)\cdot {q}_{land}^{use}(e)+{f}_{transport}^{currency}(e)\cdot {q}_{food}^{transport}(e)\\ {}+\sum \limits_{n\in \mathcal{N}}\left({\pi}_{food}^{import}\cdot {q}_{food}^{import}(n)-{\pi}_{food}^{export}\cdot {q}_{food}^{export}(n)\right);\end{array}} $$Subject to:
$$ {q}_{land}^{use}(e)\le {q}_{max}^{land}(e)\hskip0.5em \forall \hskip0.5em e\in \mathrm{\mathcal{E}}; $$
$$ {q}_{food}^{transport}(e)\le {q}_{max}^{transport}(e)\hskip0.5em \forall \hskip0.5em e\in \mathrm{\mathcal{E}}; $$
$$ \sum \limits_{e\in \mathrm{\mathcal{E}}(n)}{q}_{land}^{use}(e)\le {q}_{land}(n)\hskip0.5em \forall \hskip0.5em n\in \mathcal{N}; $$
$$ \sum \limits_{e\in \mathrm{\mathcal{E}}(n)}{f}_{land}^{labor}(e)\cdot {q}_{land}^{use}(e)\le {f}_{pop}^{labor}(n)\cdot P(n)\hskip0.5em \forall \hskip0.5em n\in \mathcal{N}; $$
$$ {\displaystyle \begin{array}{l}\sum \limits_{e\in \mathrm{\mathcal{E}}(n)}\left(\hskip-0.1em {f}_{food}^{land}(e)\cdot {q}_{land}^{use}(e)-{q}_{food}^{transport}(e)\right)+\sum \limits_{e\in {\mathrm{\mathcal{E}}}^{\prime }(n)}\eta (e)\cdot {q}_{food}^{transport}(e)\\ {}+{q}_{food}^{import}(n)-{q}_{food}^{export}(n)\ge {D}_{food}(n)\hskip0.5em \forall \hskip0.5em n\in \mathcal{N}.\end{array}} $$Net revenues accumulated by regional agricultural systems include revenue from local, regional distribution and export sales, resource expenses from regional distribution and import purchases and other expenses from capital, fixed and/or variable costs based on life cycle phase:
$$ {\displaystyle \begin{array}{l}{Q}_{currency}^{agricul}(n)={\pi}_{food}^{local}\cdot {D}_{food}(n)+\sum \limits_{e\in \mathrm{\mathcal{E}}(n)}\left({\pi}_{food}^{local}\cdot \eta (e)\cdot {q}_{food}^{transport}(e)\right)\\ {}\hskip8.8em +{\pi}_{food}^{export}\cdot {q}_{food}^{export}(n)-\sum \limits_{e\in {\mathrm{\mathcal{E}}}^{\prime }(n)}\left({\pi}_{food}^{local}\cdot \eta (e)\cdot {q}_{food}^{transport}(e)\right)\\ {}\hskip9em -{\pi}_{food}^{import}\cdot {q}_{food}^{import}(n)-\sum \limits_{e\in \mathrm{\mathcal{E}}(n)}\left({p}_{capital}(e)+{p}_{fixed}(e)+{p}_{variable}(e)\right),\end{array}} $$where variable costs include operating expenses and consumption of water resources
$$ {p}_{variable}(e)=\left(\hskip0.1em {f}_{land}^{currency}(e)+{\pi}_{water}^{local}\cdot {f}_{land}^{water}(e)\right)\cdot {q}_{land}^{use}(e)+{f}_{food}^{currency}(e)\cdot {q}_{food}^{transport}(e). $$A.3. Water system model
Water system properties in Table 10 define prices for domestic and imported, water resources, determine coastal access for desalination, set the initial stock in 1950 and recharge rate of aquifers and set resources required to lift water at each node. All three regions have small recharge rates relative to the initial volume, representative of largely nonrenewable sources. Although aquifers increase in salinity under heavy withdrawal, water quality is not considered in this model, and the aquifers are assumed to produce potable water until completely depleted.
Table 10. Water system node properties
Notes: Units: 
$ \S $: fictional currency; km: kilometre; kWh: kilowatt hour.
Water element properties in Table 11 define three sizes of desalination plants modelled based on reverse osmosis technology. This process is energy-intensive, requiring more than four times the electricity of comparatively simple aquifer lifting. Note that even the largest desalination capacity (0.6 km3/year) represents only a small fraction of the aquifer volume.
Table 11. Water system element properties
Notes: Units: 
$ \S $: fictional currency; kWh: kilowatt hours; MCM: million cubic metres.
The water system is coupled with the societal, agricultural and electrical systems. Regional water demand arises from the societal and agricultural systems, 
$ {D}_{water}(n)={D}_{water}^{societal}(n)+{D}_{water}^{agricul}(n) $. Electricity resources required to satisfy the operational plan at each node total
$$ {D}_{elect}^{water}(n)={f}_{water}^{elect}(n)\cdot {q}_{water}^{lift}(n)+\sum \limits_{e\in \mathrm{\mathcal{E}}(n)}{f}_{water}^{elect}(e)\cdot {q}_{water}^{produce}(e). $$At the end of each time step, the water system updates available aquifer stock based on withdrawals
$$ {Q}_{aquifer}\left(n,t+\Delta t\right)={Q}_{aquifer}\left(n,t\right)-{f}_{water}^{aquifer}\cdot {q}_{water}^{lift}(n). $$The water system controller sets water production (desalination) levels in constituent infrastructure elements and determines the quantity of water to lift (from aquifers) and import at each node by solving the following linear program:
Find:
$$ {q}_{water}^{produce}(e)\hskip0.5em \forall \hskip0.5em e\in \mathrm{\mathcal{E}}; $$
$$ {q}_{water}^{lift}(n),{q}_{water}^{import}(n)\hskip0.5em \forall \hskip0.5em n\in \mathcal{N}; $$Minimize:
$$ {\displaystyle \begin{array}{l}\sum \limits_{e\in \mathrm{\mathcal{E}}}\left(\hskip-0.1em {f}_{water}^{currency}(e)+{f}_{water}^{elect}(e)\cdot {\pi}_{elect}^{local}\right)\cdot {q}_{water}^{produce}(e)\\ {}+\sum \limits_{n\in \mathcal{N}}\left(C\cdot {q}_{water}^{lift}(n)+{\pi}_{water}^{import}\cdot {q}_{water}^{import}(n)\right),\\ {}\mathrm{where}\;\underset{e\in \mathrm{\mathcal{E}}}{\max}\left(\hskip-0.1em {f}_{water}^{currency}(e)+{f}_{water}^{elect}(e)\cdot {\pi}_{elect}^{local}\right)<C<{\pi}_{water}^{import};\end{array}} $$Subject to:
$$ {q}_{water}^{produce}(e)\le {q}_{max}^{produce}(e)\cdot {b}_{coastal}(n)\hskip0.5em \forall \hskip0.5em e\in \mathrm{\mathcal{E}}(n)\hskip0.5em \forall \hskip0.5em n\in \mathcal{N}; $$
$$ \sum \limits_{n\in \mathcal{N}}{f}_{water}^{aquifer}(n)\cdot {q}_{water}^{lift}(n)\le {Q}_{aquifer}(n)\hskip0.5em \forall \hskip0.5em n\in \mathcal{N}; $$
$$ \sum \limits_{e\in \mathrm{\mathcal{E}}(n)}{q}_{water}^{produce}(e)+{q}_{water}^{import}(n)+{q}_{water}^{lift}(n)\ge {D}_{water}(n)\hskip0.5em \forall \hskip0.5em n\in \mathcal{N}. $$Net revenue for the water system includes revenue from domestic water production (lifting water is assumed to generate no direct revenue) and expenses from electricity to lift aquifer and import water, and capital, fixed and variable costs based on life cycle phase:
$$ {\displaystyle \begin{array}{l}{Q}_{currency}^{water}(n)={\pi}_{water}^{local}\cdot \left({D}_{water}(n)-{q}_{water}^{lift}(n)\right)\\ {}\hskip9.2em -{\pi}_{elect}^{local}\cdot {f}_{water}^{elect}\cdot {q}_{water}^{lift}(n)-{\pi}_{water}^{import}\cdot {q}_{water}^{import}(n)\\ {}\hskip9.2em -\sum \limits_{e\in \mathrm{\mathcal{E}}(n)}\left({p}_{capital}(e)+{p}_{fixed}(e)+{p}_{variable}(e)\right),\end{array}} $$where variable costs include operating expenses and consumption of electricity resources:
$$ {p}_{variable}(e)=\left(\hskip-0.1em {f}_{water}^{currency}(e)+{\pi}_{elect}^{local}\cdot {f}_{water}^{elect}(e)\right)\cdot {q}_{water}^{produce}(e). $$A.4. Energy system model
Energy system properties in Table 12 define prices for domestic, imported and exported oil resources and domestic electricity, set the initial stock of oil reservoirs in 1950 and set resources required to generate electricity to meet shortfalls. Only the industrial region has an oil reservoir, and supply to the urban and rural regions must use pipelines.
Table 12. Energy system node properties
Notes: Units: 
$ \S $: fictional currency; toe: ton of oil equivalent; MWh: megawatt hour.
Petroleum element properties in Table 13 define two sizes of wells and two sizes of pipelines. Although oil refining typically includes numerous feed stock types and output products, this model assumes wells directly produce consumable oil at a one-to-one ratio from the reported reservoir stock. Despite large capital and operations expenses of associated infrastructure, oil production is very profitable due to high export prices.
Table 13. Petroleum system element properties
Notes: Units: 
$ \S $: fictional currency; kWh: kilowatt hour; toe: ton of oil equivalent.
Electrical element properties in Table 14 define two sizes of plants for thermal and renewable generation based on solar photovoltaic technology. No distribution elements are available to transport electricity between regions. Thermal generation consumes oil as the primary operational cost to create electricity and is up to twice as efficient as the default method used to satisfy insufficient supply. Solar generation has no variable operating expenses but incurs a large initial capital expense and larger fixed operations expenses compared to thermal generation.
Table 14. Electrical system element properties
Notes: Units: 
$ \S $: fictional currency; MWh: megawatt hour; toe: ton of oil equivalent; TWh: terawatt hour.
In addition to the internal mutual dependency, the energy system is coupled with societal and water systems. Regional oil demand arises from societal and electricity systems, 
$ {D}_{oil}(n)={D}_{oil}^{societal}(n)+{D}_{oil}^{elect}(n) $, and regional electricity demand arises from societal, water and oil systems, 
$ {D}_{elect}(n)={D}_{elect}^{societal}(n)+{D}_{elect}^{water}(n)+{D}_{elect}^{oil}(n) $. Electricity resources required to satisfy petroleum system operations at each node total
$$ {D}_{elect}^{petrol}(n)=\sum \limits_{e\in \mathrm{\mathcal{E}}(n)}{f}_{oil}^{elect}(e)\cdot {q}_{oil}^{transport}(e). $$Oil resources required to satisfy electricity system operations at each node total
$$ {D}_{oil}^{elect}(n)={f}_{elect}^{oil}(n)\cdot {q}_{elect}^{produce}(n)+\sum \limits_{e\in \mathrm{\mathcal{E}}(n)}{f}_{elect}^{oil}(e)\cdot {q}_{elect}^{produce}(e). $$At the end of each time step, the petroleum system updates available reservoir stock based on withdrawals:
$$ {Q}_{reservoir}\left(n,t+\Delta t\right)={Q}_{reservoir}\left(n,t\right)-\sum \limits_{e\in \mathrm{\mathcal{E}}(n)}{f}_{oil}^{reservoir}(e)\cdot {q}_{oil}^{produce}(e). $$ Net energy system revenue includes petroleum and electricity sources: 
$ {Q}_{currency}^{energy}(n)={q}_{currency}^{petrol}(n)+{q}_{currency}^{elect}(n). $
The petroleum system controller sets oil production (from reservoirs) and transport levels in constituent infrastructure elements and determines the quantity of oil to import and export at each node by solving the following linear program:
Find:
$$ {q}_{oil}^{produce}(e),{q}_{oil}^{transport}(e)\hskip0.5em \forall \hskip0.5em e\in \mathrm{\mathcal{E}}; $$
$$ {q}_{oil}^{import}(n),{q}_{oil}^{export}(n)\hskip0.5em \forall \hskip0.5em n\in \mathcal{N}; $$Minimize:
$$ {\displaystyle \begin{array}{l}\sum \limits_{e\in \mathrm{\mathcal{E}}}{f}_{oil}^{currency}(e)\cdot {q}_{oil}^{produce}(e)\\ {}+\sum \limits_{e\in \mathrm{\mathcal{E}}}\left(\hskip-0.1em {f}_{oil}^{currency}(e)+{f}_{oil}^{elect}(e)\cdot {\pi}_{elect}^{local}\right)\cdot {q}_{oil}^{transport}(e)\\ {}+\sum \limits_{n\in \mathcal{N}}\left({\pi}_{oil}^{import}\cdot {q}_{oil}^{import}(n)-{\pi}_{oil}^{export}\cdot {q}_{oil}^{export}(n)\right);\end{array}} $$Subject to:
$$ {q}_{oil}^{produce}(e)\le {q}_{max}^{produce}(e)\hskip0.5em \forall \hskip0.5em e\in \mathrm{\mathcal{E}}; $$
$$ {q}_{oil}^{transport}(e)\le {q}_{max}^{transport}(e)\hskip0.5em \forall \hskip0.5em e\in \mathrm{\mathcal{E}}; $$
$$ \sum \limits_{e\in \mathrm{\mathcal{E}}(n)}{f}_{oil}^{reservoir}(e)\cdot {q}_{oil}^{produce}(e)\le {Q}_{reservoir}(n)\hskip0.5em \forall \hskip0.5em n\in \mathcal{N}; $$
$$ {\displaystyle \begin{array}{l}\sum \limits_{e\in \mathrm{\mathcal{E}}(n)}\left({q}_{oil}^{produce}(e)-{q}_{oil}^{transport}(e)\right)+\sum \limits_{e\in {\mathrm{\mathcal{E}}}^{\prime }(n)}\eta (e)\cdot {q}_{oil}^{transport}(e)\\ {}+{q}_{oil}^{import}(n)-{q}_{oil}^{export}(n)\ge {D}_{oil}(n)\hskip0.5em \forall \hskip0.5em n\in \mathcal{N}.\end{array}} $$Petroleum system net revenue includes revenue from local, regional distribution and export sales, resource expenses from regional distribution and import purchases and other expenses from capital, fixed and/or variable costs based on life cycle phase:
$$ {\displaystyle \begin{array}{l}{q}_{currency}^{petrol}(n)={\pi}_{oil}^{local}\cdot {D}_{oil}(n)+\sum \limits_{e\in \mathrm{\mathcal{E}}(n)}\left({\pi}_{oil}^{local}\cdot \eta (e)\cdot {q}_{oil}^{transport}(e)\right)+{\pi}_{oil}^{export}\cdot {q}_{oil}^{export}(n)\\ {}\hskip9em -\sum \limits_{e\in {\mathrm{\mathcal{E}}}^{\prime }(n)}\left({\pi}_{oil}^{local}\cdot \eta (e)\cdot {q}_{oil}^{transport}(e)\right)-{\pi}_{oil}^{import}\cdot {q}_{oil}^{import}(n)\\ {}\hskip9em -\sum \limits_{e\in \mathrm{\mathcal{E}}(n)}\left({p}_{capital}(e)+{p}_{fixed}(e)+{p}_{variable}(e)\right),\end{array}} $$where variable costs include operating expenses and consumption of electricity resources
$$ {p}_{variable}(e)=\left(\hskip-0.1em {f}_{oil}^{currency}(e)+{\pi}_{elect}^{local}\cdot {f}_{oil}^{elect}(e)\right)\cdot \left({q}_{oil}^{produce}(e)+{q}_{oil}^{transport}(e)\right). $$The electricity system controller sets electricity generation levels in constituent infrastructure elements and determines the quantity of electricity to generate from low-efficiency methods at each node by solving the following linear program:
Find:
$$ {q}_{elect}^{produce}(e)\hskip0.5em \forall \hskip0.5em e\in \mathrm{\mathcal{E}}; $$
$$ {q}_{elect}^{private}(n)\hskip0.5em \forall \hskip0.5em n\in \mathcal{N}; $$Minimize:
$$ {\displaystyle \begin{array}{l}\sum \limits_{e\in \mathrm{\mathcal{E}}}\left(\hskip-0.1em {f}_{elect}^{currency}(e)+{f}_{elect}^{oil}(e)\cdot {\pi}_{oil}^{local}\right)\cdot {q}_{elect}^{produce}(e)+\sum \limits_{n\in \mathcal{N}}C\cdot {q}_{elect}^{produce}(n),\\ {}\mathrm{where}\;C>\underset{e\in \mathrm{\mathcal{E}}}{\max}\left(\hskip-0.1em {f}_{elect}^{currency}(e)+{f}_{elect}^{oil}(e)\cdot {\pi}_{oil}^{local}\right);\end{array}} $$Subject to:
$$ {q}_{elect}^{produce}(e)\le {q}_{max}^{produce}(e)\hskip0.5em \forall \hskip0.5em e\in \mathrm{\mathcal{E}}; $$
$$ \sum \limits_{e\in \mathrm{\mathcal{E}}(n)}{q}_{elect}^{produce}(e)+{q}_{elect}^{private}(n)\ge {D}_{elect}(n)\hskip0.5em \forall \hskip0.5em n\in \mathcal{N}. $$Electricity system net revenue includes revenue from domestic generation (private generation is assumed to generate no direct revenue) and expenses from oil for private generation and capital, fixed and variable costs based on life cycle phase:
$$ {\displaystyle \begin{array}{l}{q}_{currency}^{elect}(n)={\pi}_{elect}^{local}\cdot \left({D}_{elect}(n)-{q}_{elect}^{private}(n)\right)-{\pi}_{oil}^{local}\cdot {f}_{elect}^{oil}\cdot {q}_{elect}^{private}(n)\\ {}\hskip9em -\sum \limits_{e\in \mathrm{\mathcal{E}}(n)}\left({p}_{capital}(e)+{p}_{fixed}(e)+{p}_{variable}(e)\right),\end{array}} $$where variable costs include operating expenses and consumption of electricity resources:
$$ {p}_{variable}(e)=\left(\hskip-0.1em {f}_{elect}^{currency}(e)+{\pi}_{oil}^{local}\cdot {f}_{elect}^{oil}(e)\right)\cdot {q}_{elect}^{produce}(e). $$A.5. Key model assumptions and limitations
The driving forces from population and societal resource demand dynamics are fixed and exogenous to the model formulation. A more realistic population growth model would link growth rates to a measure of economic performance or environmental state to simulate the consequences of depleted resources or comparative prosperity of economic booms.
All resource prices are static, homogeneous across regions and exogeneous from the model formulation. Price points are approximately based on marginal costs of production. A more realistic (but much more complex) resource pricing model would establish market conditions based on supply capacity and demand to determine equilibrium price conditions at each time step where variation across regions could generate new pressures on infrastructure.
Available infrastructure projects include a fixed set of elements with static properties. While some properties are based on current technology and physical limits of transformation, others are fit to establish internal consistency (e.g., return on investment periods). A more detailed model would allow variable capacities with economies of scale and efficiency improvements or new technology options over time. For example, the past 30 years have observed tremendous improvements in renewable power generation technologies and agricultural yields.
The model assumes a centrally managed ‘nationalized’ infrastructure perspective that is an oversimplification of any economy. For example, the agricultural system is the sole source of domestic food and subsidizes imported food at the local price. Two exceptions include lifted water from aquifers and private electricity generation which both provide resources without infrastructure but do incur expenses from resource consumption (electricity and oil, respectively).
Finally, the model assumes deterministic dynamic behaviour aggregated to annual periods to mitigate logistical effects of delays and buffers. This assumes demands to be satisfied at some point during the year-long period, ignoring seasonal variation, and that constituent infrastructure can be operated efficiently without surplus resources that must be discarded. While a finer timescale and stochastic features exemplify real-world planning complexity, considering them would exceed available time and cognitive bandwidth for co-design sessions.
Appendix B. Objective metric formulation
This section provides details about the role-specific and joint objectives. Most objectives are expressed as a time average over the 30-year planning period to mitigate boundary effects.
B.6. Food security
Food security measures the average fraction of domestic food supply between 1980 and 
$ t>1980 $ compared to a desired value of 75%. It ranges between 0 for no domestic food production in all years and 1000 for at least 75% domestic food production in all years. It is computed for year 
$ t $ as follows:
$$ {J}_{food}( t)=\frac{1000}{t-1979}\sum \limits_{i=1980}^t F( i), $$where
$$ F(i)=\left\{\begin{array}{ll}1& \mathrm{if}\;S(i)/D(i)\ge 0.75,\\ {}0& \mathrm{if}\;S(i)/D(i)<0,\\ {}\frac{S(i)/D(i)}{0.75}& \mathrm{otherwise},\end{array}\right. $$
$$ S(i)=\sum \limits_{e\in \mathrm{\mathcal{E}}}{f}_{food}^{land}\left(e,i\right)\cdot {q}_{land}^{use}\left(e,i\right), $$
$$ D(i)=\sum \limits_{n\in \mathcal{N}}{D}_{food}\left(n,i\right). $$B.7. Aquifer security
Aquifer security measures the average expected lifetime of an aquifer between 1980 and 
$ t>1980 $ compared to a desired value of 200 years. It ranges between 0 for an expected lifetime less than 20 years in all years and 1000 if above 200 years in all years. It is computed for year 
$ t $ as follows:
$$ {J}_{a quifer}=\frac{1000}{t-1979}\sum \limits_{i=1980}^t{L}_a( i), $$where
$$ {L}_a(i)=\left\{\begin{array}{ll}1& \mathrm{if}\;{V}_a(i)/{W}_a(i)\ge 200,\\ {}0& \mathrm{if}\;{V}_a(i)/{W}_a(i)<20,\\ {}\frac{V_a(i)/{W}_a(i)-20}{200-20}& \mathrm{otherwise},\end{array}\right. $$
$$ {V}_a(i)=\sum \limits_{n\in \mathcal{N}}{Q}_{aquifer}\left(n,i\right), $$
$$ {W}_a(i)=\sum \limits_{n\in \mathcal{N}}{f}_{water}^{aquifer}\left(n,i\right)\cdot {q}_{water}^{lift}\left(n,i\right). $$B.8. Reservoir security
Reservoir security measures the average expected lifetime of an oil reservoir between 1980 and 
$ t>1980 $ compared to a desired value of 200 years. It ranges between 0 for no remaining lifetime in all years and 1000 for an expected lifetime above 200 years in all years. It is computed for year 
$ t $ as follows:
$$ {J}_{r eservoir}=\frac{1000}{t-1979}\sum \limits_{i=1980}^t{L}_r( i), $$where
$$ {L}_r(i)=\left\{\begin{array}{ll}1& \mathrm{if}\;{V}_r(i)/{W}_r(i)\ge 200,\\ {}0& \mathrm{if}\;{V}_r(i)/{W}_r(i)<0,\\ {}\frac{V_r(i)/{W}_r(i)}{200}& \mathrm{otherwise},\end{array}\right. $$
$$ {V}_r(i)=\sum \limits_{n\in \mathcal{N}}{Q}_r\left(n,i\right), $$
$$ {W}_r(i)=\sum \limits_{e\in \mathrm{\mathcal{E}}}{f}_{oil}^r\left(e,i\right)\cdot {q}_{oil}^{produce}\left(e,i\right). $$B.9. Financial security
Financial security measures the cumulative net revenue earned compared to a minimum and maximum desired values. It represents motivation of a player to operate profitable infrastructure and ranges between 0 if the lower bound is not achieved in all years and 1000 if the upper bound is achieved in all years. It is computed for year 
$ t $ as follows:
$$ {J}_{financial}=\{\begin{array}{ll}1000& \mathrm{i}\mathrm{f}\ R( t)>{R}_{max}( t),\\ {}0& \mathrm{i}\mathrm{f}\ R( t)<{R}_{min}( t),\\ {}\frac{R( t)-{R}_{min}( t)}{R_{max}( t)-{R}_{min}(t)}& \mathrm{o}\mathrm{t}\mathrm{h}\mathrm{e}\mathrm{r}\mathrm{w}\mathrm{i}\mathrm{s}\mathrm{e},\end{array}\operatorname{} $$where
$$ R(t)=\sum \limits_{i=1980}^t\sum \limits_{n\in \mathcal{N}}{Q}_{currency}^{sector}\left(n,i\right), $$
$$ {R}_{min}(t)={R}_{min}^{2010}\cdot \frac{{\left(1+{r}_R\right)}^{t-1940}-1}{{\left(1+{r}_R\right)}^{2010-1940}-1}, $$
$$ {R}_{max}(t)={R}_{max}^{2010}\cdot \frac{{\left(1+{r}_R\right)}^{t-1940}-1}{{\left(1+{r}_R\right)}^{2010-1940}-1}, $$using sector-specific model parameters 
$ {R}_{min}^{2010} $, 
$ {R}_{max}^{2010} $ and 
$ {r}_R $ in Table 15.
Table 15. Financial security and political power objective function parameters
B.10. Political power
Political power measures the cumulative capital expenses allocated to a sector compared to a minimum desired value. It represents the motivation of a player to acquire funds from a limited national budget and ranges between 0 if there is no cumulative capital investment up to year 
$ t $ and 1000 if the cumulative capital investment exceeds an upper bound. It is computed for year 
$ t $ as follows:
$$ {J}_{political}=\left\{\begin{array}{ll}1000& \mathrm{if}\;I(t)>{I}_{max}(t)\\ {}\frac{I(t)}{I_{max}(t)}& \mathrm{otherwise}\end{array}\right., $$where
$$ I(t)=\sum \limits_{i=1980}^t\sum \limits_{e\in \mathrm{\mathcal{E}}}{p}_{capital}\left(e,i\right), $$
$$ {I}_{max}(t)={I}_{2010}\cdot \frac{{\left(1+{r}_I\right)}^{t-1940}-1}{{\left(1+{r}_I\right)}^{2010-1940}-1}, $$using sector-specific model parameters 
$ {I}_{2010} $ and 
$ {r}_I $ in Table 15.
Open access
