Keywords

1 Introduction

Provenance is defined as a record that describes the people, institutions, entities, and activities involved in producing, influencing, or delivering a piece of data or thing [1]. Provenance explains more than what happened, but it also answers how data was manipulated, why, and who was involved in the process. Data Provenance explains the interactions of these concepts within a system and has the potential to aid the decision making process in a complex battlespace with many autonomous actors. The PROV Data Model, PROV-DM, is a generic data model for the standardized open provenance model described by W3C [2]. Fully recorded provenance will illuminate dependencies, responsibility flow, and explain why certain actions were made. Dependency and decision tracking is a critical piece of C2, especially within a battlespace of several autonomous actors, whether human or machine.

We investigate tracking decisions made and actions taken between the human and autonomy within a prototype centralized C2 system, the Intelligent Multi-UxV Planner with Adaptive Collaborative Control Technologies (IMPACT), using provenance. In this study, we seek to track provenance of decision makers, whether software agents or human operators, in order to derive responsibility flow within IMPACT. Afterwards, we describe ideas for future work and avenues to take with the information learned (Fig. 1).

Fig. 1.
figure 1

Visual representation of how data provenance is modeled. This figure showcases the three different views alongside the traditional PROV layout convention. Entities are represented as yellow ellipses, activities are blue rectangles, and agents are orange pentagon-houses. Used by permission of the author [1] (Color figure online)

Full size image

2 Provenance and Decision Making

Studies have mostly done assessments on provenance to determine quality, reliability, or trustworthiness of data using offline provenance, or provenance that is generated after applications have finished running. We are taking an approach to dynamically record and generate provenance during system runtime, or online provenance as defined by Sezavar Keshavarz et al. [3]. Further research with online provenance has shown that online provenance have aided online decision making and behavior recognition of crowdsourced activities were derivable [4]. Accountability is a critical piece of autonomy within C2; provenance has the ability to trace decisions that change information made by autonomous systems back to operators and vice versa.

Although Keshavarz’s study showcases online provenance for decision making for computational systems, the information derived from the methodology can be translated and passed on to human decision makers. Conversely, when a decision can be considered as the provenance of the selected course of action, it allows human decision management to be translated into a machine-understandable representation of decisions using provenance [5]. Provenance can provide both transparency of a system to a human while also allowing a machine to perform analytics based on the history of actions by humans.

The PROV Data Model allows for domain and application specific representations of provenance that was designed to be translated and interchanged between systems. Different heterogeneous systems can export their native provenance into the PROV-DM and the model allows for applications to make sense of the provenance and reason over it [2]. This is one of the strengths provided by PROV-DM that opens the doors to human-computer-collaboration.

3 Architecture

3.1 IMPACT

IMPACT is a C2 prototype platform for centralized supervised control of simulated autonomous unmanned vehicles [6]. The underlying goal of the IMPACT system is to allow an inversion of the unmanned vehicle staffing ratio. Currently, many operators are required to control a single unmanned vehicle [7]. IMPACT explores the use of higher platform and application level autonomy to grant a single operator control of teams of disparate unmanned vehicles. Through a “playbook” approach, an operator calls a “play” which tasks a vehicle or team of vehicles with mission objectives [8]. A play can involve multiple vehicles such as an overwatch play, where the vehicle being watched and the vehicle performing the watching can be of completely different types (e.g. an air vehicle watching a surface vehicle which is itself performing a point inspect play). Furthermore, operators can configure plays with constraints requiring certain payloads to accomplish the task and can be explicit or implicit (e.g. require a certain payload, or set environment constraints that implicitly require a certain payload).

Data driving this prototype flows through a centralized hub, where modules specializing in a certain function subscribe to messages required for their operation. An autonomous agent subscribes to and processes play requests to allocate resources and recommend assets based on the current state of all available assets combined with the constraints specified by the operator. An automated route planner ingests play requests and generates routes based on current vehicle, environment and mission requirements. There are three modules of interest residing within IMPACT that are suitable for Provenance instrumentation:

Fusion. The Fusion agent realizes visualization of the combined IMPACT modules. This Human Computer Interface (HCI) acts as the primary means of interaction between the human operator and simulated vehicles. Fusion presents a high-level C2 perspective with tools enabling play-calling, environment editing and interfaces for the various modules composing IMPACT. The “playbook” visually represents plays available for the operator and provides an interface to specify play constraints and asset allocation preferences. Upon calling a play, Fusion will display routes and task destinations for vehicles performing the play.

Task Manager. The Task Manager (TM) aids the operator by helping to manage workload. Previous work has investigated the use of autonomous task management in order to balance operator attention with situational awareness in the unmanned vehicle domain [8]. Certain events in IMPACT trigger the generation of tasks within the TM for the operator to perform. In addition to events, chat conversations are parsed for relevant content that may lead to the generation of new tasks. As tasks are generated in TM, operator-configured working agreements allocate tasks based on what the operator has decided the autonomy is allowed to do. This helps the operator achieve more control and builds trust in the autonomy as it guides the behavior of the autonomy towards operator expectations. Additionally, some generated tasks are pre-configured to map directly to certain plays, with the parameters necessary to accomplish the play pre-filled by the TM with the goal of increasing the speed of the play-calling process (Fig. 2).

Fig. 2.
figure 2

The Task Manager is populated with predicted tasks based on chat messages.

Full size image

Plan Monitor. The Plan Monitor (PM) observes ongoing missions and relays plan health evaluation to the operator. The PM generates a formal network model of entities and components in IMPACT within the Rainbow Autonomics Framework [6]. This model is primed with thresholds and constraints ensuring mission plan requirements and vehicle status are within specifications. In addition to mission plan health, constraints on vehicle properties ensure vehicle status is monitored. Evaluation of the model happens near real time and adaptation strategies are triggered upon model constraint violations. Plan health is represented in the PM tile within the Fusion interface and is color coded to visually depict mission plan quality. Vehicle status is communicated through alert messages presented as a text overlay. Finally, PM interacts with a policy checking module, described below, that allows it to directly and autonomously modify ongoing plans under specific conditions.

Fig. 3.
figure 3

The Plan Monitor displays plan health for active plays based on several criteria such as vehicle energy and time to destination.

Full size image

3.2 COMPACT

The Configurable Operating Model Policy Automation for Control of Tasks (COMPACT) system is a C2 policy compliance checking system for unmanned air vehicles (Fig. 3). COMPACT performs policy compliance information checks and sends the information to IMPACT in order for the application level autonomy to reroute ongoing missions, update new restricted or keep-in zones, and call plays to maintain policy compliance. This autonomous reroute play calling is achieved under specific conditions and through communication with a trio of modules: COMPACT, PM and TM. Upon detection of an air vehicle projected to enter a restricted zone, COMPACT publishes a predicted air space violation alert which is ingested by PM. PM updates its model and triggers an adaptation strategy to publish a task generation message which is received by TM. Finally, TM generates a reroute mission task notifying the operator that a vehicle is predicted to enter a restricted area. If a TM working agreement is configured such that the autonomy is allowed to reroute plans, the task is executed immediately.

3.3 MAPLE

The Maritime Autonomous PLatform Exploitation (MAPLE) framework is a Ground Control Station (GCS) with several modules used for remote control of unmanned vehicles. Systems within the MAPLE framework allow operators and pilots to fly actual vehicle assets, which allows IMPACT to cross the boundary between simulated and live unmanned vehicles. Human approval on the MAPLE side is required for all missions planned by IMPACT. MAPLE also introduces Goal-Based Mission Planner for IMPACT to autonomously act upon.

4 Provenance Tracking

4.1 Dynamically Generated Provenance

Runtime generation of provenance typically requires applications to be instrumented accordingly [9]. Instrumenting applications and generating provenance at the same time can be cumbersome from a software engineering perspective [10]. To overcome this, we instrument the IMPACT system by treating it like a black-box and avoid including invasive code into the several services and bridges. All the services within IMPACT communicate using the ZeroMQ Distributed Messaging Framework to subscribe and process messages published by a data hub within IMPACT. These messages contain data about the scenario such as telemetry, vehicle task details, restricted zones, mission related events, etc. [6]. All messages being sent to and from the entire system goes through a data hub.

ProvPy is the Python implementation of the PROV-DM data model [11]. We use this toolkit to create a memory representation of provenance and serialize it [10]. ProvPy allows system provenance to be serialized into XML and JSON; it also provides capabilities to export the provenance to a graphical representation. The graphical representation of PROV-DM is a directed graph, which allows for common network metrics and analytics to be applied. We developed an IMPACT-Provenance service which subscribes to the data hub and listens to the entirety of the message traffic, generating provenance for messages of interest. The service dynamically converts IMPACT hub messages into the PROV-DM format.

4.2 Human Play Calling in IMPACT

An IMPACT operator calls a play by using a play workbook to accomplish different missions and tasks. The Fusion agent generates a set of solutions to potentially accomplish the tasks; by default, the most optimized solution is presented to be engaged, but the operator has the freedom to select other, less optimal solutions. The provenance service captures the interaction between the operator and the Fusion agent and generates provenance based on solutions and assets involved with the mission. Alternatively, an automatically generated play with pre-set parameters can be called from the TM to accomplish tasks at an even faster rate.

Fig. 4.
figure 4

Example of the Provenance of a Regular Play Call. The Play Call itself is an activity that generates the mission entity. The mission entity was derived from a set of solutions determined by the fusion agent and is attributed to the C2 operator and Falcon-41 unmanned air vehicle.

Full size image

4.3 COMPACT Bridge Interactions

The COMPACT system communicates with IMPACT through a message bridge that acts as a service connected to the data hub. While air vehicles are accomplishing missions, COMPACT monitors their vehicle states and notifies IMPACT of policy violations when a vehicle leaves the communications range or enters a newly discovered restricted zone. Automated plays are then called with the collaboration of the PM and TM. When a vehicle is about to enter a restricted fly zone, the PM receives the warning from COMPACT (Fig. 4). Fusion will create a new restricted zone within IMPACT and attempt to reroute the vehicle. When a vehicle has violated a communications range policy, the PM receives the warning from COMPACT and requests a communications relay play, which the TM then executes (Fig. 5).

Fig. 5.
figure 5

Example of rerouted provenance. The policy checker agent represents COMPACT and detects that Falcon-42 is approaching a NO FLY zone and generates a policy violation. Plan monitor consequently does a rerouting activity for the operator.

Full size image
Fig. 6.
figure 6

Example of communications Relay Provenance. The Policy Checker (COMPACT) detects that Falcon-42 is about to fly outside of communications range and generates a policy violation. Plan monitor then requests a communications relay play and task manager responds by creating a play to provide communications support.

Full size image

4.4 MAPLE Bridge Interactions

Although the MAPLE framework allows IMPACT to communicate with live assets, provenance tracking cares more about the goal based missions it provides (Fig. 6). Some plays are enacted because of an overall mission being accomplished, such as base protection. In a scenario where an operator receives critical information regarding the location of hostile forces, the goal is to send assets to the location for reconnaissance. If that information turns out to be false, the asset needs to be dismissed from the mission in order to be reassigned to a new mission or to follow other leads to determine the initial reason for the assumption of hostile forces in the area. Provenance creates the relationships between the data in order to detect when plays have been invalidated and to notify the operator to free these assets. Furthermore, root cause analysis can be used on provenance data of a large scenario and can determine responsibility of false information or potential reasons as to why the information has been invalidated [12].

Fig. 7.
figure 7

Example of a goal based mission being invalidated and the initial Play being cancelled.

Full size image

5 Transparency

Complexity increases dramatically in an ever-changing battlespace; situational awareness is difficult to maintain in these endeavors. Introducing provenance into adaptive systems is a critical step for system transparency and explanation. One of the key components for achieving algorithmic transparency is data provenance [13].

The data model provides a natural way to determine how data has evolved and been manipulated, which agents were responsible for different actions, and the processes involved. Systems should provide explanations regarding both the procedures followed by autonomy and the specific decisions that are made. We believe that if provenance is able to provide this form of transparency, explanation, and accountability will allow autonomous systems to be better incorporated into human decision making (Fig. 7).

6 Future Work

6.1 Provenance-Based Decision Making Aids

Provenance has been used in the past to predict the quality of data. We would like to experiment with different provenance network analytics to develop a predictive model for plans. The Plan Monitor will determine the labels of failed and successful plans after they are called; classifying these plans alongside their respective provenance using machine learning will build predictive models for plan quality. An effort to increase the granularity of provenance recording must be accomplished for more features.

6.2 Resource Reallocation for Optimization

Due to the unknown nature of a battlespace, resources may be allocated in a certain way to fulfill constraints based on time and current availability. Missions that are ongoing may have a better-suited vehicle candidate. Because provenance can keep track of all dependencies and constraints, it can be a useful tool to reallocate resources in order to optimize constraints as the battlespace continues to change.

7 Summary

Data Provenance is a growing research fields with several applications. This preliminary paper touched on some of the ways provenance was used to instrument the interactions between a human and a prototype autonomous C2 system. Provenance can track the actions of an autonomous agent to provide operators with data lineage and process flow in order to enhance decision making and situational awareness. Similarly, the actions of human operators are also tracked to either provide responsibility flow or root cause reasoning.

We believe that accountability, transparency, and thus trust can be enhanced through the proper employment of provenance tracking. Provenance introduces a potential data model to bring explanation and transparency through different analytics techniques. This paper discussed a very small scale use of provenance, but opens the idea of using different analytic techniques to interface humans and machines using the data model.