HR001119S0053-Amendment-01.pdf

Broad Agency Announcement

LogX

STRATEGIC TECHNOLOGY OFFICE

HR001119S0053

June 12, 2019

Amendment 1

The purpose of this amendment is to make revisions to the language in the following sections, which are highlighted in yellow throughout the document:

1. PART II. FULL TEXT OF ANNOUNCEMENT; VIII. Other information; Proposer

Profile List submission instructions and deadline

TABLE OF CONTENTS

PART I: OVERVIEW INFORMATION

PART II: FULL TEXT OF ANNOUNCEMENT

I. Funding Opportunity Description

A. Program Overview

B. PROGRAM METRICS

II. Award Information

A. General Award Information

B. Fundamental Research

III. Eligibility Information

A. Eligible Applicants

B. Organizational Conflicts of Interest

C. Cost Sharing/Matching

D. Other Eligibility Criteria

IV. Application and Submission Information

A. Address to Request Application Package

B. Content and Form of Application Submission

V. Application Review Information

A. Evaluation Criteria

B. Review of Proposals

VI. Award Administration Information

A. Selection Notices and Notifications

B. Administrative and National Policy Requirements

C. Reporting

D. Electronic Systems

VII. Agency Contacts

VIII. Other Information

IX. APPENDIX 1: PROPOSAL ABSTRACT SLIDE SUMMARY

X. APPENDIX 2: VOLUME 1 COVER SHEET TEMPLATE

XI. APPENDIX 3: VOLUME 2 COVER SHEET, CHECKLIST AND SAMPLE

TEMPLATES

XII. APPENDIX 4: SECURITY CLASSIFICATION GUIDE REQUEST FORM

PART I: OVERVIEW INFORMATION

Federal Agency Name – Defense Advanced Research Projects Agency (DARPA), Strategic Technology Office (STO)

Funding Opportunity Title – LogX

Announcement Type – Initial Announcement

Funding Opportunity Number – HR001119S0053

Catalog of Federal Domestic Assistance Numbers (CFDA) – Not Applicable

Dates o Posting Date: June 6, 2019 o Proposers Day: June 11, 2019 o Questions Due Date: June 14, 2019, 5:00 PM (EDT) o Proposal Abstract Due Date: June 25, 2019, 5:00 PM (EDT) o Notification due to DARPA PSR if proposing any classified information – July 2, 2019, 5:00 PM (EDT) o Proposal Due Date: July 30, 2019, 5:00 PM (EDT)

Total amount anticipated to be awarded – Approximately $55M for multiple phases over 42 months

Anticipated individual awards – Multiple awards are anticipated.

Types of instruments that may be awarded -- Procurement contract or other transaction.

Agency contact o The BAA Coordinator for this effort can be reached at:

HR001119S0053@darpa.mil

DARPA/STO

ATTN: HR001119S0053

675 North Randolph Street Arlington, VA 22203-2114

PART II: FULL TEXT OF ANNOUNCEMENT

I. Funding Opportunity Description

This publication constitutes a Broad Agency Announcement (BAA) as contemplated in Federal

Acquisition Regulation (FAR) 6.102(d)(2) and 35.016 and 2 CFR § 200.203. Any resultant award negotiations will follow all pertinent law and regulation, and any negotiations and/or awards for procurement contracts will use procedures under FAR 15.4, Contract Pricing, as specified in the BAA.

The Defense Advanced Research Projects Agency (DARPA) is soliciting innovative proposals in logistics and supply chain automated reasoning and information fusion, real-time demand forecasting, and system resilience assessment. Proposed research should investigate innovative approaches that enable revolutionary advances in science, devices, or systems. Specifically excluded is research that primarily results in evolutionary improvements to the existing state of practice.

A. Program Overview

The Department of Defense (DoD)’s Joint Logistics Enterprise, which spans both supply chain and logistics operations, provides the means to muster, transport and sustain military power at a high level of readiness. In an increasingly contested global security environment, the logistics enterprise needs to change how it operates to achieve sufficient resilience and mission success.

While there are many changes required1 to the enterprise to ensure survivability, logistics information systems play a central role in the effective function of the enterprise and are currently both an operational limitation and potential vulnerability. LogX will develop and demonstrate a new paradigm for achieving logistics information awareness across the enterprise to enable responsive and resilient operations. This enhanced situational awareness will not only be of value to logisticians but also to operational elements whose tempo and effectiveness are ultimately dependent on survivable logistics support, critically so in future operating concepts.2

Problem Definition

The Joint Logistics Enterprise is immense: for the Air Force alone, the number of aircraft is equivalent to four commercial airline fleets and the supply chain inventory to sustain them is as large as multiple Fortune 500 companies combined.3 This scale is managed by partitioning, with separate organizations managing supply chains, distribution, and procurement, resulting in thousands of separate logistics information management systems across the DoD. The resulting

“open system of systems” is driven by business processes, with information systems ranging from 1970’s legacy mainframe software to modern enterprise resource planning packages.

1 For example, the Defense Science Board Task Force on Survivable Logistics Executive summary provides multiple recommendations: www.acq.osd.mil/dsb/reports/2010s/SurvLog_FinalReport_ExSumm.pdf 2 For example, DARPA’s Mosaic Warfare Concept and the Navy’s Distributed Lethality Concept:

https://www.public.navy.mil/surfor/Documents/Surface_Forces_Strategy.pdf 3 E.g., The USAF has more than 5000 aircraft; United Airlines has roughly 730. For supply chain see, https://www.afsc.af.mil/News/Article-Display/Article/1326617/escaping-todays-supply-chain-challenges/ https://www.public.navy.mil/surfor/Documents/Surface_Forces_Strategy.pdf https://www.afsc.af.mil/News/Article-Display/Article/1326617/escaping-todays-supply-chain-challenges/

Obtaining coherent and detailed understanding of the total logistics system, such that impacts of changes on one part of the system are understood by other parts, is extraordinarily difficult.4 The system is especially vulnerable to the ripple effect, in which disruptions cascade throughout the system and are amplified by the architecture of the enterprise, and the bullwhip effect, in which local decisions are made without regard to the state of the global enterprise, causing catastrophic swings in stock.5

Logistics planners and operations center staffs (e.g., J-3’s) must navigate dozens of information systems (IS’s) to address basic situational awareness and reactive planning queries. These systems frequently track attributes on a common weapons system, component or process, but the data in these systems may be latent, incorrect, or deliberately inaccurate to mitigate risk (e.g., hoarding or requesting spares beyond what is needed) as well as in a range of incompatible formats. Fusing this data to create a coherent picture of state is a laborious, human-driven process. Obtaining further insight to diagnose why certain states exist or predicting future states

(or prognosis) is frequently only possible following exhaustive analysis after the fact given the fractured and stove-piped nature of the enterprise.

In contrast to the DoD, the commercial sector has achieved a higher level of functionality in its information systems, but the nature of this problem is different: commercial systems are built on business processes that are largely demand-pull as opposed to planned supply push6, and the integration of business processes, information systems, and data across the supply chain in the most sophisticated corporate environments7 makes causal reasoning and forecasting considerably easier. The nature of military logistics in a contested environment8 places a higher value on resilience and distributed operations than is economically attractive for many commercial settings, leading to fundamentally different system architectures. However, there are guiding principles regarding system dynamics and information flow that the commercial sector has matured – for example, the use of dynamic staging, variable lot size and distribution systems for items with different demand uncertainty and inventory turn– that could apply to the military setting.

DARPA is exploring the flexibility of systems that can be composed by operators to meet varying mission needs as part of its Mosaic Warfare concept.9 This operational approach moves the enterprise from one that is “built to order” with long response time and low flexibility, to an “assemble to order” model. Such a shift will require profound changes in inventory management, positioning, and logistics information awareness beyond the obvious changes in weapons systems and tactics. As a result, the Mosaic Warfare concept puts further stresses on

4 An excellent overview of the logistics/supply chain system and associated challenges is provided in Peltz, Robbins and McGovern, “Integrating the Department of Defense Supply Chain,” RAND TR1274, www.rand.org 5 For discussion see Ivanov & Sokolov, “Ripple effect in the supply chain: an analysis and recent literature,”

International Journal of Production Research, Taylor & Francis, 2018, 56 (1-2), pp.414-430.

6 As noted in Peltz, et al, ibid, spare parts for equipment, expedient combat engineering, and some medical supplies are managed using stochastic demand and/or demand pull models.

7 See Simchi-Level, Operations Rules, MIT Press, 2010 for examples of IT integration with business processes 8 E.g., https://dod.defense.gov/Portals/1/Documents/pubs/2018-National-Defense-Strategy-Summary.pdf 9 Explained in the talk by Dr. Tim Grayson, Director of the Strategic Technology Office at DARPA’s D60 here:

https://www.youtube.com/watch?v=33VAnIEjDgk https://dod.defense.gov/Portals/1/Documents/pubs/2018-National-Defense-Strategy-Summary.pdf https://www.youtube.com/watch?v=33VAnIEjDgk the deficiencies of the current DoD logistics enterprise. A new logistics approach is required to viably compose and sustain a distributed or Mosaic fighting force, and information awareness is the critical enabler to enable that approach.

Program Scope

The goal of the LogX program is to develop and demonstrate software for real-time logistics and supply chain system situational awareness (diagnosis), future state prediction (prognosis) and resilience10 at unprecedented scale and speed. LogX will build a capability to work alongside existing logistics information systems that exploits the recent migration of logistics information to digital formats and cloud-based deployment.

LogX will address the core challenges of:

Obtaining, sharing, and understanding information across the Joint Logistics Enterprise regarding the current and future state (diagnosis and prognosis) of both logistics and supply chain systems;

Automated and scalable understanding of the complex business processes, information flows, data sources, uncertainties, and system models to identify relevant system state variables;

Automated and rapid estimation of current and future states (diagnosis and prognosis) based on the collection of logistics and supply chain data, which may be incomplete, incorrect and/or inconsistent.

The logistics enterprise can be viewed as a three-layered “network of networks” system: the physical supply chain and logistics distribution networks, the information networks that connect understanding of demand to supply and distribution, and financial networks that resource the activity. LogX will consider the impact of information dynamics and networks on the state of the physical logistics and supply chain enterprise, to include both military and commercial elements.

The impact of financial instruments on information dynamics (e.g., contracts and commodity futures) will be considered as inputs in program-specified scenarios. Given this emphasis, concepts for communications systems, physical infrastructure, delivery platforms, robotics/drones, and other physical effectors are out of scope and excluded. Although information security is a key concern for LogX, concepts primarily focused on or dependent upon blockchain implementation are also explicitly excluded.

Within the information layer, LogX will provide the ability to accelerate and improve the effectiveness of logistics operations in contested environments through enhanced situational awareness of both logistics distribution and supply chain activity. The program will explore logistics information operations with some assumptions about how they are likely to evolve over the next ten years. That evolution is likely to involve a migration to cloud-based infrastructure and data centralization, but not necessarily implementation of modern software architecture s or extensive standardization, interoperability, or integration. However, proposers should assume

10 Such assessments might include, but are not limited to, readiness and demand assessment/forecasting, as well supply chain security/resilience.

that relevant data and/or information systems of interest will be accessible from within a cloud computing infrastructure.

LogX is predicated on the ability to achieve state estimation. In this framing, the logistics enterprise is considered to be a distributed, networked dynamical system, where the state is a complete description of the system at a point in time. The variables that provide this complete description are the state variables. The state variables for the logistics and supply chain systems include both information (e.g., business process status, part orders, cargo manifests) and physical distribution (e.g., inventory levels, aircraft flight tracking) quantities. Logistics and supply chain system state variables are generally discrete in time (e.g., the number of parts in an order is an integer quantity) but may be stochastic. Some state variables may not be directly observable since there are no sensors and may need to be inferred, and others may be redundant, incorrect, or incomplete. State estimation is the process by which an estimate of the underlying, partially observed system state is obtained. The methods of Filtering Theory are an examples of techniques11 to do so. Framed this way, data collection and fusion can be framed as an uncertainty minimization problem, providing a natural means to address the complexity of the logistics information awareness.

The state estimation will be both dynamic and distributed: dynamic because the underlying state variables may change in time (or cannot be approximated as steady state) and distributed because there is no central state estimator. Instead, there are multiple users across the Joint Logistics Enterprise (e.g., a DLA buyer, a USTC planner, or a Navy logistics officer) each obtaining state estimates that can be shared across the LogX system and combined to create an improved overall global system state12 estimate. By taking this approach, there are clear analogies to electrical power grid control and resilience as well as system health monitoring,13 with the important difference that for the logistics enterprise, limited mechanistic models14 exist for the combination of the information and physical systems. A mechanistic model is necessary to move beyond descriptive (“what is happening?”) and correlation-based diagnosis (“why did this happen?”) to causational diagnosis and prognosis (“what will happen and why?”). To construct and dynamically update such models, LogX will leverage a range of nascent innovations in automated reasoning and knowledge engineering for complex systems.15

11 Techniques such as extended information and Kalman filters may be applicable for certain mechanistic models;

see TA2 Track 2 discussion.

12 In the context of a single user, there is no distributed estimate but the problems of interest to the program entail at least 2 users; see Peltz et al for a bullwhip example.

13 For example, see Monticelli, “Electrical Power System State Estimation,” Proceedings of the IEEE, 2000, Xie et al, “Fully Distributed State Estimation for Wide-Area Monitoring Systems,” IEEE Transactions on Smart Grid, 2012, Yong et al, “Resilient State Estimation against Switching Attacks on Stochastic Cyber-Physical Systems,”

2015 IEEE 54th Annual Conference on Decision and Control.

14 See Cohen, “DARPA’s Big Mechanism program,” Phys. Biol., 12 (2015) 045008. As in Big Mechanism, “mechanistic” in LogX has to do with how the model is used as opposed to syntactic/semantic attributes – the goal is to explain how certain inputs give rise to outputs. In the logistics or supply chain setting, models of the physical distribution system are commonplace, and do include basic information network impacts in stylized settings.

15 Beyond the aforementioned Big Mechanism work, large-scale graph analytic approaches such as those explored in

DARPA Modeling Adversarial Activity (MAA) (https://www.darpa.mil/attachments/MAAbriefing-

ProposersDay20160926verB2.pptx), automated reasoning such as that explored in DARPA’s Active Interpretation of Disparate Alternatives (AIDA) (https://www.darpa.mil/attachments/AIDA%20Proposers%20Day%20v7.pdf) and https://www.darpa.mil/attachments/MAAbriefing-ProposersDay20160926verB2.pptx https://www.darpa.mil/attachments/MAAbriefing-ProposersDay20160926verB2.pptx https://www.darpa.mil/attachments/AIDA%20Proposers%20Day%20v7.pdf

Program Description and Structure

The user-facing software product of the LogX program will be a mission-centered applications service (hereafter apps service) to provide situational awareness and estimates of future state that can be deployed across the Joint Logistics Enterprise. The mission-centered applications will not be a static single-function software capability, but an “insight-as-a-service” capability that provides personalized, timely information to make sound decisions in the context of the user’s mission. This capability will be deployed from the cloud-based computing environments the military and commercial logistics and supply chain communities are migrating to. Proposers should plan for the apps service to be accessible from any number of platforms (tablet, smartphone or computer). The apps service will utilize a microservices architecture to provide scalable and powerful system understanding and foresight as a service to a range of potential users. This microservices-based software architecture has been matured and utilized at scale by commercial entities16 to provide personalized services on demand to users, and the goal of LogX is to do so for logistics/supply chain diagnosis and prognosis.

The apps service will ingest diagnostic or prognostic user queries (or hypotheses) regarding the logistics system or supply chain. Given a specific query (or hypothesis), the apps service will employ composition services (see Figure 1) to dynamically combine, or compose, microservices for data collection, reasoning, learning and state estimation in response. These cloud-based microservices are functionally modular programs that have clearly defined purposes. The LogX microservices stack will ensure that the knowledge required to answer a query or test a hypothesis is maintained separately from the services that collect data, assemble it into a model and reason on it, as well as from the data itself, providing flexibility, security, and a natural path to scaling. Finally, the apps service will instantiate a mission-specific user interface (UI) application to provide the resulting insight to the user.

A schematic of the program structure is shown in Figure 1. The LogX program will have two technical areas (TAs): the Mission-Centered Applications Service (TA1) and Cloud-Based

Microservices (TA2), which will have two tracks: automated knowledge engineering and dynamic/distributed state estimation. Proposers may submit responses that address TA1 only, TA2 only to include either or both tracks, or fully integrated teams including a TA1 with both

TA2 tracks.

causal model construction techniques from Causal Exploration

(https://www.darpa.mil/attachments/CausalExplorat ionProposersDayPMBriefing20161219.pdf) programs may be relevant but will require significant adaptation to the goals of LogX. More details are provided in the Technical

Area 2 discussion.

16 E.g., see (Amazon) https://docs.aws.amazon.com/aws-technical-content/latest/microservices-on-aws/microservices-on-aws.pdf?icmpid=link_from_whitepapers_page, (Uber) https://eng.uber.com/building-tincup/, and (Netflix; also the Netflix Tech Blog) https://medium.com/refraction-tech-everything/how-netflix-works-the-hugely-simplified-complex-stuff-that-happens-every-time-you-hit-play-3a40c9be254b https://www.darpa.mil/attachments/CausalExplorationProposersDayPMBriefing20161219.pdf https://docs.aws.amazon.com/aws-technical-content/latest/microservices-on-aws/microservices-on-aws.pdf?icmpid=link_from_whitepapers_page https://docs.aws.amazon.com/aws-technical-content/latest/microservices-on-aws/microservices-on-aws.pdf?icmpid=link_from_whitepapers_page https://eng.uber.com/building-tincup/ https://medium.com/refraction-tech-everything/how-netflix-works-the-hugely-simplified-complex-stuff-that-happens-every-time-you-hit-play-3a40c9be254b https://medium.com/refraction-tech-everything/how-netflix-works-the-hugely-simplified-complex-stuff-that-happens-every-time-you-hit-play-3a40c9be254b

Figure 1: Program structure and notional LogX architecture example.

Note that although Defense Logistics Agency (DLA) and United States Transportation Command (USTC) queries are shown in this notional stack, LogX will serve a larger number of users and potential queries. Also not shown is the integration of overall system state from the individual queries.

These technical areas will be complemented by a Government-side test and evaluation (T&E) team that will provide data, ground truth adjudication, and an elastic compute environment for software development. The Government T&E team plays a critical role in the overall conduct of the program. The T&E team will define test scenarios for each sprint (see Program Schedule) and provide a range of data as Government Furnished Information (GFI) for both causal model and state estimate construction that will be bounded by the test scenarios in the program.

Representative data may include, but are not limited to:

DoD logistics doctrine and process publications;

Defense Logistics Agency (DLA), Combatant Command (COCOM), or Military Service business process documentation;

System interaction diagrams (SV-6)17;

Case studies on logistics process execution;

17 See https://dodcio.defense.gov/Library/DoD-Architecture-Framework/DoDAF20_sv6/ https://dodcio.defense.gov/Library/DoD-Architecture-Framework/DoDAF20_sv6/

Historical data from logistics information or enterprise resource planning (ERP) systems from DLA, United States Transportation Command (USTC), Military service18, and commercial sources (ranging from information in SAP and/or Oracle data formats to legacy structured data);

Electronic Data Interchange forms19;

Commercial shipping manifests; and

DLA Automatic Addressing System (DAAS)20.

The T&E team will also provide ground truth models for process and system state estimation assessment, and conduct test evaluations. A flexible cloud-based elastic computing development environment for the program will be provided and administered by this team as Government Furnished Equipment (GFE) and will be available at the kickoff. A GFI data corpus for proof of concept testing and an Application Programming Interface (API) for accessing this corpus from the program cloud will be provided at the program kickoff.

The program will utilize an adaptive, agile approach to software development. The apps service and underlying microservices will be demonstrated through a series of sprints to progressively address more difficult logistics/supply chain diagnostic/prognostic queries. The program will leverage historical data available from military and commercial settings as ground truth to build confidence in the validity of the resulting analysis. Proposers should plan for a sequence for

"macroscale" strategic supply chain problems, "microscale" operational and tactical logistics and distribution problems, or combinations of the two every 8-12 weeks as part of the technology development plan.

These problems will be focused on the core program goals of enhanced system awareness, scale and speed, and resilience, defined as (see Program Metrics for additional details):

System awareness: The Joint Logistics Enterprise contains more processes, elements, and relationships, each with its own range of current and future states, than humanly comprehensible. In the spirit of DARPA’s Big Mechanism program,21 LogX will build and demonstrate a machine-assisted capability to extract fragments of process and system mechanistic understanding from policy, doctrine, and data, assemble these fragments into mechanisms, and use these mechanisms to provide both current and future state estimation across the enterprise. System awareness for diagnosis (“why did this happen?”) will be defined using an uncertainty metric relative to a ground truth benchmark (e.g., accuracy of order state or inventory), while prognosis (“what will happen?”) will use a forecasting metric: (Forecast horizon, days) x (% certainty in global state over that horizon) compared to a ground truth benchmark.

18 See for example, Bitto, “Adding Big Data Analytics to GCSS-MC”, Naval Postgraduate School, 2014

(https://apps.dtic.mil/docs/citations/ADA620863) for details on the nature of the data, and https://www.ustranscom.mil/dtr/part-iii/dtr_part_iii_app_i.pdf on some of the information systems from which data may be obtained and provided.

19 For example, EDI 511R, 940R and 858 formats are used in parts requisition. See for example:

https://www.ustranscom.mil/cmd/associated/dteb/files/transportationics/Dt858a35.pdf 20 Description at www.dla.mil/HQ/Informat ionOperations/DAAS/Mission/ 21 See Cohen, “DARPA’s Big Mechanism program,” Phys. Biol., 12 (2015) 045008 https://apps.dtic.mil/docs/citations/ADA620863 https://www.ustranscom.mil/dtr/part-iii/dtr_part_iii_app_i.pdf https://www.ustranscom.mil/cmd/associated/dteb/files/transportationics/Dt858a35.pdf http://www.dla.mil/HQ/InformationOperations/DAAS/Mission/

Scale and Speed: Given the scale of the Joint Logistics Enterprise, achieving understanding of even fragments of the enterprise today is a laborious, manual effort.

Conventional approaches to fuse data in order to obtain system diagnosis or prognosis involves identification and querying of multiple data sources to identify both business process logic and associated data and curation of that data, including cleaning and data schema reconciliation, followed by hand-crafted analysis and/or modeling. This process scales poorly and takes weeks to months or more to complete. In contrast, LogX will apply a hybrid human-machine team approach to this problem to radically accelerate this process. The measure of performance for this attribute is defined as:

(Number of system indicators) * (Number of information systems) / (Total analysis time, hours).

An indicator in this context is a quantity that is either a state variable or can be used to infer a state variable, such as inventory or shipment dates.

Resilience: The Joint Logistics Enterprise is not adequately resilient to disruption resulting from lack of system awareness (the “bullwhip effect”) or unforeseen events (“the ripple effect”).22 The enhanced information awareness provided by LogX will provide means to reduce or mitigate these effects and improve system resilience.

Resilience in this context is measured by the ratio of the time to recover from a disruption (Time to Recover, TTR) to the time to sustain operations for a specified number of days at a fixed level of cost and/or risk (Time to Survive, or TTS).23 While it is trivial to ensure a robust TTS with large safety stock, such an approach is not realistic in distributed and risk/cost-constrained military environments.

Technical Area One: Mission-Centered Applications Service

The Technical Area One (TA1) performers will develop the user-facing solution that composes TA2 microservices to provide answers to queries or hypotheses by drawing on Government T&E team-provided system and process data. TA1 performers will conduct the following tasks, with metrics and schedule as defined in Program Schedule and Milestones (below):

Develop and demonstrate cloud-based, mission-centric applications to provide logistics and supply chain situational awareness;

Develop and demonstrate a versatile and scalable human-machine interface for a range of potential user personas to make superior decisions enabling distributed, resilient operations;

22 See Ivanov and Sokolov, ibid. and Peltz, et al., ibid 23 See Simchi-Levi et al, “Identifying Risks and Mitigating Disruptions in the Automotive Supply Chain,”

Interfaces, 2015, and Gao, Sarah Yini and Simchi-Levi, David and Teo, Chung-Piaw and Yan, Zhenzhen, Disruption Risk Mitigation in Supply Chains - The Risk Exposure Index Revisited (November 25, 2016). Available at SSRN: https://ssrn.com/abstract=2875596

Develop and apply a human-machine team approach to build and dynamically update logistics and supply chain system understanding by calling on the appropriate TA2 microservices;

Develop and demonstrate an approach to provide distributed, secure construction and update of the service composition logic and associated state estimates; and

Define the API and architectural structure to compose the cloud-based data microservices.

TA1 proposers will likely integrate a range of technical innovations spanning human-machine interface, dynamic data visualization, and distributed/collaborative software design.

Conventional enterprise data fusion and operations research/supply chain analysis approaches are explicitly not of interest.

Given the complexity and scale of the problems, the mission-centered applications service will likely need to employ a hybrid human-intelligent machine architecture to accelerate the construction of and continuously update the understanding of the logistics system. This approach will require the repeated application of TA2 automated knowledge engineering and state estimation microservices: in the creation of the initial models of processes and data collection, in query response, in construction of global state updates from local queries and responses, and in learning from feedback or refinement to queries to improve results. TA1 proposers should clearly define their workflows for both development and execution of these processes. Purely human-driven or fully automated approaches are unlikely to achieve the program metrics (see Metrics) and are thus excluded.

The mission-centered applications service will need to support a range of potential users that have different needs for supporting their decision making. For example a supply chain manager has different business processes, data streams, and visualizations than an operational logistics planner at USTC. 24 Proposers should illustrate a clear understanding of the types of data, queries, and visualizations required for a range of operational users and define a strategy to create and personalize these interfaces in an automated and scalable way.

TA1 proposers should address the following topics in their technical narrative:

System architecture & development approach: While the program is structured using a commonly implemented layered microservices architecture, the details of how to achieve robust and flexible performance are critical and unique to the program. Proposers should explain how their architecture will support distributed and secure system understanding at scale, with dynamic updating, across a broad range of mechanistic models and workflows. Although there are examples25 of dynamic centralized synthesis of multiple user inputs to provide a global state estimate for all users, LogX TA1 proposers should discuss the necessary architectural innovations to both provide distributed, dynamic, and timely updating of both mechanistic models and state estimates across the system, as well

24 See Peltz, et al, ibid.

25 Perhaps the best known example is the Waze app, which takes traffic reports from many users and fuses them to provide real-time routing.

as computationally scalable privacy and security measures26 to protect these distributed, dynamic models and estimates.

User Experience/User Interface: The user interface will need to provide useful, intuitive, and powerful workflows and affordances to users to define/curate, refine, and use process and system models to accelerate decision making. TA1 proposers should define representative user personas (e.g., DLA, USTC, COCOM J-4, and Marine Battalion S-4), workflows, information displays, and affordances that will accelerate understanding of the logistics and supply chain systems at both the microscale/tactical and macroscale/strategic level. Proposers should discuss both the initial process/system model construction and model refinement use cases. For construction, clear explanation of the modality and scale at which users can define rules, causal relationships, and/or information flows is necessary. For refinement, there should be discussion of how particular rules or causal factors in need of update are identified and mediated through composition of TA2 microservices. Finally, proposers should also discuss the resulting output of the applications for various users and how it is used in hypothetical cases of distributed diagnosis and prognosis to enable realization of program metrics.

Composition Service Approach: Specific queries have associated sub-tasks or functions that will drive composition of TA2 microservices (see Figure 1). For example, the query “How many repair parts should be ordered to maintain mission-capable inventory?”

requires understanding of both transportation and operational states: the former to estimate how many parts need to be ordered, and the latter to understand demand signal.

To address the query, potentially different compositions of microservices for collection of data, mechanistic model instantiation, and state estimation may be required. However, systematic means for mapping a query into composition of microservices has not been codified. Proposers should discuss how they intend to define and update this composition logic in a scalable, resilient manner across the range of logistics/supply chain diagnosis and prognosis challenges in the program.

Application Programming Interface (API): A TA1 system will be incapable of realizing useful function without thoughtfully designed interfaces to TA2. Given the microservices approach employed in the program, API definition and management is especially critical.

This API should be explicitly defined and discussed by proposers, with explanation of underlying knowledge representation and data ontology/semantics and an explanation of why it is sufficiently full- featured to capture all salient aspects of the system(s) being represented. TA1 is responsible for enumerating, describing and constructing the API for each of the enabling services expected to be provided by TA2 to include both inputs and expected products in return. Proposers should discuss expected performance (e.g., 26 For example, such measures could include graph-based or structured encryption schemes in which computations or modifications do not require de-encryption; such approaches will require careful consideration of the structure of the microservices composition and underlying models/approaches. For examples, see Meng et al, “GRECS: Graph

Encryption for Approximate Shortest Distance Queries”, available at https://privacytools.seas.harvard.edu/files/privacytools/files/grecs.pdf and Chase and Kamara, “Structured

Encryption and Controlled Disclosure”, https://link.springer.com/content/pdf/10.1007/978-3-642-17373-8_33.pdf https://privacytools.seas.harvard.edu/files/privacytools/files/grecs.pdf https://link.springer.com/content/pdf/10.1007/978-3-642-17373-8_33.pdf latency), security properties, expectations/plans of any middleware, and treatment of state (e.g., REST vs SOAP)27. Finally, proposers should discuss how their architecture enables incremental inclusion of additional TA2 capabilities without necessitating a complete API redesign, scalability, and version control. See Program Schedule for software integration details and schedule.

Technical Area Two (TA2): Cloud-Based Microservices

The Technical Area Two Cloud-Based Microservices are a critical component of LogX since they provide the means to construct situational awareness and understanding of the logistics supply chain system. These microservices are also the critical difference between the LogX approach and more conventional cloud-based enterprise database systems. There are two tracks for the associated microservices: Track 1, Automated Knowledge Engineering and Track 2, Distributed/Dynamic State Estimation. Given the centrality of the state estimation approach to the program concept, conventional approaches based on agent-based modeling, standard operations research modeling approaches, and enterprise data fusion are explicitly excluded. A microservices approach, in which each function is modularized and autonomous to the highest degree possible, is strongly encouraged.

TA2 performers will develop and demonstrate sophisticated automated reasoning tools for logistics and supply chain systems. Lacking a domain-specific language for logistics or supply chain modeling, such a task may appear to be intractable. There are, however, some simplifications to scope that make progress plausible. First, structural features are well-known:

logistics systems are networks that are optimized for economy and efficiency and exhibit common motifs like hub-and-spoke architectures in physical space and placement of warehouses for optimal delivery time. Supply chains are less straightforward because of competitive supplier relationships. However, an emerging body of research28 has highlighted the use of graph analytics methods to discern common structural motifs. Second, the semantics for the problem space is not entirely undefined: for example, the Supply Chain Operations Reference (SCOR) model29 provides basic ontological elements and a rich range of metrics. SCOR is necessary but not sufficient; DoD business processes, information systems, and their connectivity are unique and especially complex. The LogX Government T&E team will provide materials (manuals, system diagrams) as GFI for the program demonstrations. Finally, logistics information systems are largely static: there is a large switching cost to migrate business processes from one information system to another, so once connectivity and data formats are established, full reconstruction of a mechanistic model is unlikely to be needed.

27 REST: Representational State Transfer, SOAP: Simple Object Access Protocol 28 E.g., Shao et al, “A data analytics approach to identifying hidden critical suppliers in supply networks:

Development of nexus supplier index”, Decision Support Systems, 2018; Kim et al, “Structural investigation of supply networks: A social network analysis approach”, J. Ops Mgmt, 2011; Brintrup et al., “Predicting hidden links in Supply Networks”, Complexity, 2018 29 See: https://en.wikipedia.org/wiki/Supply_chain_operations_reference https://en.wikipedia.org/wiki/Supply_chain_operations_reference

Track 1: Automated Knowledge Engineering

TA2, Track 1, Automated Knowledge Engineering will:

Develop methods to automatically extract information "with the model in mind"30 and assign uncertainty to information from a range of data sources;

Develop the means to combine this information into explanatory mechanistic models that allow reasoning over processes or system state;

Develop learning algorithms to dynamically improve, update, and automatically curate/mediate models and/or sub-models (or knowledge fragments); and

Develop and demonstrate software services to instantiate these capabilities in a scalable manner.

There are multiple uses for the capabilities to be developed by TA2 Track 1 in the LogX workflow:

Model initialization: Given a query (or set of queries), TA2 Track 1 services will need to extract information on causal mechanisms from various data sources and assemble these into executable models of increasing scale and fidelity. These data sources will be provided by the government T&E team as appropriate for the problem/query of interest and may include information for determination of state that is wrong, incomplete, or latent. Uncertainties may be provided by human subject matter experts through the TA1 interface, or automatically assigned and updated, or both depending on approach.

Depending on the context these models may range from qualitative to quantitative31 and are expected to be compositional: outputs of one model component can be used as inputs to another, and components could be built from each other.

Query response: Model exercise will utilize inputs from TA1 and services from TA2 Track 2 (Distributed State estimation), but Track 1 proposers may have a role in query response depending on the approach. For example, a multi-hypothesis or template-based model will utilize multiple state estimates that will collapse to a single most likely template or hypothesis as a result of query-driven data collection and state estimation.

Given the distributed state estimation approach central to LogX, there may be multiple subsystem models that will need combination and updating as the system is used.

Model management: It is anticipated that as the program progresses, the underlying mechanistic system models will grow in scale and complexity. Given the various layers of the system and potential range of levels of abstraction, it is envisioned that multiple microservices will be used to curate models as well as reason over and/or combine qualitative and quantitative models.

Given this context, TA2 Track 1 proposers should address the following topics in their technical narrative:

30 See Cohen, 2015, ibid 31 In analogy to DARPA’s Big Mechanism program, business processes are similar to interaction maps in cancer biology since they capture “who talks with whom” and qualitative dynamics, while for resilience or distribution problems, more quantitative models of underlying information or distribution networks can & should be constructed.

Architecture/Design Patterns: Proposers should discuss their architectural approach.

Given the goals of the program, services should seek to balance the desire for an appropriate level of generality such that relatively few instances of TA2 architectures are needed to address a wide range of TA1 queries or hypotheses while also maintaining the modularity and separation of concerns that microservices provide.32

Knowledge Representation: While both physical and information systems in logistics are easily represented as graphs, integration of these systems into broader, probabilistic, mechanistic models may require more expressive constructs. Proposers should discuss how their choice of representation facilitates the required degree of expressiveness, computability, and model reasoning to achieve the goals of LogX. Proposers should discuss how their approach to representation enables rapid state estimation after knowledge extraction.

Knowledge extraction: While the majority of logistics and supply chain data are structured text, in some instances this information may be complemented by other forms of data (e.g. weather radar, financial indicators). Proposers should discuss how their approach will facilitate, with TA2 Track 2, integration of mostly structured data with some unstructured data to rapidly construct state estimates. See “Test and Evaluation of Microservices” in Program Metrics for expected performance characterization for this attribute.

Model Construction, Updating and Management: Proposers should discuss what data are required to construct a model from available knowledge and how this construction process is achieved. Depending on the approach, proposers may use a mix of deductive, inductive, and/or abductive reasoning in concert with state estimation; proposers should discuss how these reasoning modes are utilized and the associated computational complexity. Proposers should discuss how observations are mapped to the model (or templates), models are updated and managed, and what learning strategies are employed to improve model quality.33 Proposers should clearly identify a strategy to support model updating resulting from distributed state estimation. Proposers should discuss their approach to meeting the accuracy, model adaptation and computational scalability performance metrics discussed in the “Test and Evaluation of Microservices” section of Program Metrics.

API: Proposers should discuss their API requirements and approach, to include data input/output format and performance expectations, expectations of middleware, state

(e.g., REST vs SOAP34), and security performance. See Program Schedule for software integration details and schedule.

32 For very basic examples of what is meant by architecture: http://blog.arungupta.me/microservice-design-patterns/ 33 Approaches of interest here might include combinations of logical, semantic reasoning and deep learning (e.g., https://www.sri.com/work/projects/deep-adaptive-semantic-logic-dasl) or Qualitative reasoning and Model Based

Diagnosis approaches 34 REST: Representational State Transfer, SOAP: Simple Object Access Protocol http://blog.arungupta.me/microservice-design-patterns/ https://www.sri.com/work/projects/deep-adaptive-semantic-logic-dasl

Track 2: Dynamic/Distributed State Estimation

TA2, Track 2, Dynamic/Distributed State Estimation will:

Develop methods to combine distributed heterogeneous, incomplete, and potentially incorrect information to obtain system diagnosis or estimate of current state;

Develop methods to combine distributed heterogeneous, incomplete, and potentially incorrect information to obtain system prognosis or estimate of future state; and

Develop and demonstrate software services to instantiate these capabilities in a scalable manner.

The capabilities in TA2 Track 2 are central to the LogX workflow. Given a system mechanistic model and range of possible data sources, TA2 Track 2 performers will provide a means to orchestrate information collection and automatically estimate and predict system state. The system is distributed, stochastic, and only partially observable. Effective state estimation approaches will vary with the characteristics of the process of interest and the underlying mechanistic model and proposers should provide clear justification for how their ensemble of approaches will address program objectives and the range of potential state models. For example, dynamic Bayesian networks as well as hidden and/or hierarchical hidden Markov models may be needed for certain types of more qualitative models for business processes. Graph theoretic methods that are well-suited to the multi-network coupling problems in LogX might use templates to identify relevant processes or activity; these models have a state space characterized by the edge space of the graph with the state estimate being the probabilistic variation of activity on these edges. More traditional methods from model predictive control or techniques such as

Kalman and particle filtering may be employed in some limited instances where data or sensor feeds are amenable to these formulations. Since the goal of LogX is to address a range of potential mechanistic models, TA2 Track 2 proposers should have a broad strategy to employ the

“right” state estimation approaches for a range of potential model formulations, and single-formulation approaches (e.g. model predictive control, particle filter approaches, hidden

Markov models) are explicitly not of interest.

Given this context, TA2 Track 2 proposers should address the following topics in their technical narrative:

Architecture/Design Patterns: As with TA2 Track 1, proposers should discuss their architectural approach. Given the goals of the program, services should seek to balance the desire for an appropriate level of generality such that relatively few instances of TA2 architectures are needed to address a wide range of TA1 queries or hypotheses while also maintaining the modularity and separation of concerns that microservices provide.

State Estimation: TA2 Track 2 will be tasked with application of a specific state estimation approach to optimize the collection of data to minimize uncertainty (which is an optimization of information collection). The choice of state estimation approach is thus a “meta-optimization” that determines the most effective state estimation technique to answer a query or to test a hypothesis. Proposers should discuss their approach for accomplishing this objective in an efficient and flexible manner. Proposers should discuss how their approach can, given an ensemble of mechanistic models, incorporate data from various modalities, statistically characterize the current state of knowledge, and continuously/incrementally update the quality of the estimated state. Proposers should also discuss how to incorporate new sources of information or deal with missing data.

Proposers should also discuss how state estimates can be updated if data change and how prior state estimates can be exploited, particularly in the context of distributed estimate construction.

Model Exercise: Models must ultimately answer queries or assess hypotheses regarding causal factors or future states in dynamic and distributed contexts. Proposers should discuss how their approaches can support a range of potential queries and future state hypotheses including prediction of future state, dynamic “what if” scenarios, “how to” queries, sensitivity analyses, weakest link assessment, and system and/or process failure probabilities using specific data and examples when possible.