data, transform it into knowledge and understanding, and integrate it with practice has not kept pace. For example, most popular data analytics solutions, including those based on AI/ML, are cloudbased and require transporting data from often distant edge devices to a central location for processing. This limits the amount of data that we can process and our ability to analyze and transform this data into knowledge in a timely manner.

In our earlier work, we proposed the notion of a computing continuum based on the uid integration of resources at the edge, in the core, in the network, and along the data path to support dynamic and data-driven application workows [1]. Key research questions addressed by this prior work include: (1) how do we determine what, where, and when data gets collected and analyzed based on user objectives and user/system constraints; (2) how do we program services to respond to changes in application objectives, data availability and content; and (3) how does the application react during execution to events of interest and trigger appropriate actions.

Leveraging this vision of the computing continuum for urgent science requires novel application and algorithmic formulations, as well as a software stack that provides programming abstractions and runtime mechanisms for dynamically (and opportunistically) federating appropriate resources, and composing data-driven workows where workow composition and execution is dened by the content and location of the data. Furthermore, the execution must continually balance the computation or data movement's cost with the value of the operations to the application objectives.

In this paper, we build on our prior research and envisioned software stack presented in [1] and explore how the computing continuum can be leveraged to support a specic urgent science workow, i.e., the data-driven Earthquake Early Warning (EEW) application workow. This workow combines data streams from geo-distributed seismometers and high-precision GPS stations to detect large ground motions, which can lead to hazards such as tsunamis. Early warnings rely on a two-step ML algorithm that has been validated using real data. The presented software stack allows users to program reactive behaviors and orchestrate their execution across the continuum while balancing computational costs with the application's value.

The rest of this paper is organized as follows. Section 2 presents key research challenges in realizing urgent science and the EEW workow across the continuum. Section 3 introduces the concept of continuum computing and provides background and related work. Our unied framework is introduced in Section 4, and Section 5 illustrates how it is used to support the EEW workow. Finally, we discuss open research challenges in Section 6 and conclude the paper.

As available data increases in scale, heterogeneity, and richness, data-driven urgent workows are enabling new and transformative applications across many disciplines. These workows aim to process machine-generated data in a timely manner to identify context-sensitive features and events, and produce critical insights. For example, emerging urban mobility applications rely on trac sensors' processing large amounts of trac data in real-time to identify and alleviate trac congestion. Similarly, autonomous cars using sensors such as LiDAR and cameras are expected to gather and process, in a timely manner, many TB's of data per day [2]. Many of these workows involve complex models that are based on the ecient and time-constrained fusion of data from dierent domains.

Urgent science workows present additional requirements and constraints due to the nature and distribution of the data, the complexity of the models involved, the stringent error thresholds, and the strict time constraints. The execution of these workows has to balance the need for a large amount of computational power to reduce errors while ensuring the timely processing and assimilation of essential data streams [3,4].

Earthquakes are amongst the most destructive natural disasters. Networks of distributed seismic instruments on various scales are used for earthquake detection. When an earthquake occurs, a realtime network system installed to monitor seismic activity in a region can detect it. Typically, a centralized data collection and processing agency alerts relevant stakeholders. This centralized data collection and processing limit the amount of data that can be processed and how fast it can be processed. It motivates leveraging the computing continuum. The goal of distributing the processing is to speed-up detection while reducing data transfer costs (sending only aggregated data to the cloud), fault tolerance (avoid isolation of sensors), and better-utilizing resources (using resources at the edge and in-transit).

When an earthquake strikes, the energy released is sent out as seismic waves in all directions. The fastest waves, the waves that arrive rst, do not actually shake the ground in a damaging way. We cannot even feel these primary or P-waves, but sensors can. P-waves travel through Earth's crust around 1.7 times faster than secondary or shear waves (S-waves), propagating through Earth's interior and causing the ground to shake back and forth. Thus, there is a lag between these two types of waves, and using them together allows us to generate warning before the shaking starts and the resulting damage.

Earthquake Early Warning (EEW) systems aim to provide alerts before any damaging eects reach sensitive areas by detecting P-waves before the S-waves arrive. It gives communities, organizations, and governments a valuable time window to take protective actions. Warnings can be sent out to mobile phones, radio, and TV. They can stop trac and bridges, halt surgeries, and make decisions on critical infrastructures such as gas pipelines. EEW systems Earthquake Early Warning use-case (DMSEEW) [11]. Seismic sensors located in the Edge send measurements to gateways in the network which pre-process the data. Those preprocessed data are sent to cloud servers which complete the data processing and eventually broadcast earthquake alerts.

usually use hundreds to thousands of sensors scattered in dierent geographical regions producing 3D time series, which indicates the direction of the P-wave ground-motion (east-west, north-south and up-down). At present, there are EEW systems operational in several countries [5]. The Japan Meteorological Agency (JMA) began operating a system in 2007 that consists of over 4,000 contributing stations, with a typical station interval of about 20 km and performed eciently when an earthquake hit Japan in 2011 [6]. Mexico implemented a seismic alert system in 1991, allowing for a warning time of 58 to 74 seconds [7]. Notable related eorts include novel algorithms recently developed to locate earthquakes and to calculate their magnitudes using P-and S-wave energy [8]. Recently, ShakeAlert proposed to detect and disseminate EEW alerts using smartphones, relying on the fact that they have become ubiquitous to the public [9,10].

The Distributed Multi-Sensor Earthquake Early Warning (DM-SEEW) used in this work is a two-step stacking ensemble method for earthquake detection [11]. It relies on the complementary nature of GPS sensors and seismometers to obtain a precise assessment of the magnitude. GPS sensors are better at characterizing high magnitude, while seismometers are better for low magnitude. It has two important data processing steps: a by-sensor time-series classication and a by-region combination of sensor predictions, as illustrated in Figure 1. This algorithm produces sensor-level class predictions (normal activity, medium earthquake, or large earthquake) based on the data gathered by each sensor. It then aggregates those sensor-level class predictions using a bag-of-words representation to calculate a nal prediction for the earthquake category. DMSEEW has been developed, evaluated, and validated using a real-world dataset in collaboration with geoscientists 1 . The ability to fuse data from GPS stations and seismometers dierentiate this work from existing methods to detect all the large earthquakes with a precision of 100%, which is critical for any EEW system.

The Computing Continuum represents a uid integration of the computational, storage, and network resources located the edges, in the cloud, and in-between [12]. The data is generated at the edges by sensors, scientic instruments, and personal devices. Edge devices are usually limited in computational power and storage; their principal function is to collect data and transmit them for analysis. In-transit nodes are then in charge of performing aggregation, ltering or preprocessing along the data path. Finally, far from the data, the cloud provides the abstraction of unlimited resources in well-provisioned datacenters. Figure 2 illustrates the key dimensions of the computing continuum.

Traditional solutions focus on one particular dimension at a time. Hence, most of the solutions are built on the premise that data ingestion, management, and processing can be done in the cloud, without the use of edge and in-transit tiers. Several edgebased middleware solutions exist in the literature; however, they often lack a uniform programming model framework for resource management, data processing, and application servicing between edge and cloud [13,14]. Edge resources have limited availability, are distributed geographically, and are often power constrained.

The in-transit tier brings value to applications by allowing quick data triaging and processing while moving the data between geographically distributed nodes. Our previous work integrates approximation and Software Dened Networks (SDN) to support tradeos and network management on federated resources. Approximate computing is used to optimize the balance between quality and resource usage. For example, data may be processed with lower accuracy to improve performance when appropriate [15]. SDN approaches enable programmable network management to provision and recongure in-transit resources. This exibility allows for a dynamic architecture for a better t to application logic and prevents bottlenecks [16].

The Cloud tier handles the heavy data processing using stream processing frameworks and supporting data management systems. Stream processing frameworks are responsible for data transformation, aggregation, and ltering using application logic. Management systems provide key enabling services such as data ingestion systems, key-value stores, or load-balancing and proxy servers. Despite the availability of well-provisioned computing resources in the cloud, the increasing amount of data puts considerable stress on the infrastructure. For example, limited network bandwidth can result in bottlenecks and underutilized cloud resources. Furthermore, cloud providers' current pricing models are based on the number of messages between the edge and the cloud. As a result, transporting all the data to the cloud is expensive (in terms of latency and costs) but may also be wasteful.

Leveraging the computing continuum to support application workows eectively requires novel solutions for federating infrastructure, programming applications and services, and composing dynamic workows, which are capable of reacting in real-time to unpredictable data sizes, availability, locations, and rates. Traversing the data path from the network edges, via intransit resources, to the core, resources typically increase in scale and processing capacity, but also imply increasing latency and data movement costs. Leveraging the continuum implies eectively using resources along this data path to balance timely processing with processing complexity and quality of results.

The Computing Continuum aggregates the architectural and algorithmic challenges of its subcomponents while presenting new challenges related to their integration and overall management [1,12].

As data analytics based on AI/ML techniques are becoming an increasingly important component of data-driven application workows, several studies have identied model optimization and ML inference as the main vectors driving the use of resources at the edge [17,18]. Furthermore, execution mechanisms that leverage data parallelism (partitioning data among units) and model parallelism (distributing the intelligence among units) have proven eective for processing data streams [19,20].

Early eorts in distributed training at the edge proposed to train domain-specic models on devices, and only transmit the inferred knowledge for fast inference [21][22][23]. Collaborative approaches for inference leverage hybrid edge-to-cloud infrastructures to take the ooading decision based on constraints such as the size of input data, the model to be executed, and tradeos between the inference accuracy and network latency and bandwidth [24,25]. Other graphbased approaches track pipelines and map them to geographically distributed analytic engines ranging from small edge-based engines to powerful multi-node cloud-based engines [26,27].

Recent years have seen the availability of a growing number of cloud-based stream processing frameworks. These frameworks rely on data being moved to the cloud and are often agnostic to the specic characteristics and needs of particular data sources/devices [28]. Most of these works are application-specic and lack abstractions for expressing objective for time-critical operations. Our strategy for urgent science across the continuum aims for a general approach with little assumptions on the data and resources capabilities.

In this section, we describe a unied framework for continuum computing designed to enable data-driven workows. The framework provides the essential capabilities and services that are necessary for executing workows on infrastructure that integrates resources across the continuum. These services include resource discovery, mapping of computations to resources, and runtime management and control. Furthermore, at the application level, the framework enables developers to express requirements and constraints associated with stages of the workow. Finally the framework supports the autonomic management of workow execution, balancing performance, cost, and other metrics.

A schematic overview of the framework architecture is presented in Figure 3 and is described below.

Infrastructure Layer The infrastructure layer enables the discovery, selection, and monitoring of resources. Resources include data producers and streams (sensors, scientic instruments, IoT devices, etc.) and computing resources and services (cloud services, in-network services, cloudlets, etc.). This layer builds on the Associative Rendezvous (AR) interaction model [29] to enable discovery based on attributes rather than names. Using this model, data producers and services/resource providers use keyword-based proles to locally describe resources/services as well as availability and access constraints, and consumers use keywords and wildcards to discover and interact with relevant resources. Note that proles can be locally changed, impacting which resources (data streams, compute) are used.

Federation Layer The federation layer organizes selected resources and services as logical groups based on attributes such as performance and geographical location, and enables these resources to be used to execute the workow. The logical organization builds on structured peer-to-peer overlays and provides lookup and messaging services within the overlay. The federation layer supports the synthesis of agile execution environments for data-driven workows using relevant resources across the computing continuum leveraging software-dened environment concepts. These execution environments autonomically evolve to balance performance and costs as workow requirements as well as the state of the resource change.

Streaming Layer The streaming layer manages workow execution and the associated data processing. Data-driven workows may involve merging data from multiple sources, the deployment and conguration of steam processing engines, and the management of the data ow between these engines. The streaming layer provides programming abstractions to express which data streams should be processed and where they should be processed based on data content and using parameters such as available resources, network capacity or application requirements. It also provides runtime mechanisms to support these abstractions and enable workow execution.

Service Layer The service layer provides the interfaces that expose the services provided by the lower layers that can be used ). Each layer exposes operators provided by the building blocks and enabling technologies, to enables data-driven workows across the computing continuum.

to described and execute workow. It also provides access to external services such as services for longer-term data storage and management.

R-Pulsar is a programming system and edge-based middleware for enabling data-driven workows that span edge and cloud resources.

It supports the denition of data-processing requirements including what data should be process and where, as well as based on datacontent, the specication of tradeos between the quality and costs. R-Pulsar has been shown to improve metrics such as end-to-end latency, bandwidth consumption, and edge-to-cloud and cloud-toedge messaging cost for IoT-based workows [14,30].

The Virtual Data Collaboratory (VDC) is a data-intensive cyberinfrastructure focused on providing large-scale federated data management, analysis resources and tools for scientic applications [31]. VDC leverages regional data transfer notes (DTNs) and federated data resources to support data services and enable collaborative data-intensive workows.

CometCloud enables the dynamic composition of infrastructure services across multiple (academic and commercial) providers. It enables on-demand scale-up, scale-down and scale-out based on dynamic deadline-, budget-, and workload-based constraints in a multi-cloud environment [32,33].

Harnessing the Computing Continuum for Urgent Science DCC'20, June 08, 2020, Boston, MA

We use the EEW workow as a driving use case for urgent science. This model inference workow can be seen as composed of 3 key steps: data collection at the sensors, time-critical data processing close to the sensors, and time-constrained aggregation and processing of local results at a central computing facility. Early experiments have shown signicant variations in the latency measured for processing one seismic event. Performance varies depending on network technology and the mapping of functions to resources along the data path. This is a major challenge for urgent science workows such as the EEW workow, where only a couple of seconds can be crucial for people to protect themselves before a strong shaking of the ground [34]. This section describes how the framework presented in Section 4 can be used to increase control over performance and costs.

In the EEW workow, a large number of geographically distributed seismometers and GPS sensors continuously produce data in the form of a 3D time series streamed or queried on demand. For example, in our experimental scenario, we emulate 1,000 sensors deployed on 25 host machines. Each set of 20 sensors composes a geographical region and is connected to one of the 50 Fog Gateway. Each sensor produces 1,200 messages at a frequency of 100Hz, resulting in 12,000,000 messages that have to be processed. This sensor data is then selectively processed close to the sensor location for initial classication, which in our implementation is a Data Transfer Nodes (DTN) located in the network. The data collection step uses R-Pulsar to program query and store operations on sensor data. Every sensor and computational resource executes an R-Pulsar runtime instance that exposes a semantic prole associated with the data and/or resources. Specically, sensors declare an advertising prole with the type, frequency, and precision of data they can produce, and requests to be notied when a resource is interested in such data. DTNs declare their interests in terms of the type of sensor data and the region of interest for the rst step of classication. The matching of proles happens dynamically, allowing DTNs to received data streams and trigger data processing either locally or in the cloud.

The EEW workow classication step relies on window-based processing to gather measurements streamed by each sensor, and performing classication on this streamed data. Specically, the DTNs run the WEASEL-MUSE library for Multivariate Time Series classication [35] and Apache Flink for parallel stream processing [36].

Window-based processing stores a nite amount of data at the intransit resources, to which computations can be applied based on the time that the event occurred on the device producing the data (i.e., Event time). As it is only possible to wait for a nite period to gather events within a particular window, Event time processing incurs some latency while waiting for out-of-order events 2 .

2 https://ci.apache.org/projects/ink/ink-docs-stable/dev/event_time.html

Our design for fast-decision making relies on an estimation of data processing cost and accuracy to dynamically adjust the mapping of computations. CometCloud aggregates time, estimated accuracy and energy consumption metrics, and interacts with VDC to congure and manage the connectivity between data processing engines.

The prediction step lters the data streams by regions and predicts the magnitude of eventual seismic events. This step is typically executed at a central computing facility and relies on Apache Kafka for data ingestion and Apache Flink for data processing. It uses tumbling windows of 1 second to gather predictions from a given region and calculate the nal prediction. Similar to in-transit resources, CometCloud acts with help from VDC services, manages the conguration of stream processing engines (Apache Kafka servers, Flink job managers and Zookeeper) and collects relevant performance metrics. The application's endto-end performance is tracked for each prediction in a distributed knowledge base, along with associated provenance information. The nal predictions are available to the users as well as downstream decision-making systems.

Extreme heterogeneity and uncertainty. The continuum represents extreme heterogeneity in the capabilities and capacities of systems and services. This heterogeneity is furthered coupled with extreme uncertainty arising from variabilities in the availability and quality of data, resources, and services. Addressing this heterogeneity requires application formulations and programming abstractions that allow developers to expose natural exibilities and tradeos and dene policies and mechanisms that can drive runtime adaptions. For example, the integration of dynamic partial reconguration, such as provided by Field Programmable Gate Arrays (FPGAs), requires analysis and understanding of factors that aect usability (overheads, constraints, energy consumption) to benet and facilitate the creation of ad-hoc clusters in the continuum.

Balancing requirements and expectation with constraints and cost. Mapping user expectations and constraints in terms of response time, solution quality, data resolution, cost, energy, etc. With what is possible in a dynamic computation and communication environment, satisfying these requirements/constraints during execution warrants the design of an autonomic control plane. Such a control plan must be able to address cost/benet tradeos at runtime in a cross-layer manner and drive the autonomic reconguration of applications, resources, and services, including, for example, provisioning new resources and services, adapting scheduling strategies, selecting appropriate systems services, and/or adjusting application parameters as necessary.

Ensuring end-to-end guarantees. While the seamless and ephemeral composition of data, resources, and services towards enabling novel and impactful application is compelling, it also makes providing end-to-end guarantees critical and challenging. Translating (often heterogeneous) local mechanisms for authentication, privacy, provenance, etc., into end-to-end guarantees essential for enabling applications to take action requires new research and new solutions.

The proliferation of digital data sources coupled with pervasive access to non-trivial computing capabilities has the potential for enabling new classes of near real-time, data-driven applications and support urgent science.

However, harnessing the computing continuum for urgent science workows requires understanding the computing resources' capabilities along the continuum, the dynamic application requirements, and desired quality and performance objectives in an integrated manner. In this paper, we presented a conceptual framework for enabling urgent science workows across the computing continuum. Building on our prior work, we also presented an implementation architecture that includes infrastructure services that automate the discovery of resources, programming abstractions to enable developers to express what data to process, where to process it, and how to manage resources along the data path. We use the early earthquake warning urgent science use case to illustrate the operation of the framework.

As for future work, an interesting direction is to design a general model for balancing computational costs with the value provided to the application in terms of solution accuracy to achieve timely completion of operations.