1

Human/AutonomyCollaborationfortheAutomatedGenerationofIntelligenceProducts

PhilDiBona,JasonSchlachterLockheedMartin

AdvancedTechnologyLaboratories{phillip.j.dibona,jason.schlachter}@lmco.com

UgurKuter,RobertGoldmanSmartInformationFlowTechnology,Inc

{ukuter,rpgoldman}@sift.net

AbstractIntelligenceAnalysisremainsamanualprocessdespitetrendstowardautonomyininformationprocessing.Analystsneedagiledecision-supporttoolsthatcanadapttotheevolvinginformationneedsofthemission,allowingtheanalysttoposenovelanalyticquestions.OurresearchenablestheanalyststoonlyprovideaconstrainedEnglishspecificationofwhattheintelligenceproductshouldbe.UsingHTNplanning,theautonomydiscovers,decides,andgeneratesaworkflowofalgorithmstocreatetheintelligenceproduct.Therefore,theanalystcanquicklyandnaturallycommunicatetotheautonomywhatinformationproductisneeded,ratherthanhowtocreateit.

OperationalChallengesforIntelligenceAnalystsIntelligence analysts are responsible for the development of intelligence products inoperationalenvironments(OE)thatcontinuallyevolveduetomilitary,diplomatic,political,strategic, and tactical situations. The analysts in turn must maintain flexibility in theiranalytictradecraftandadapttheiranalysisandworkproductstothesedynamicsituations.Thisanalyticagility, oneof the tenPrinciplesof Joint Intelligence, is theability toquicklyshift focus and leverage skills and tools to address newproblems, employing automateddata handling and communications systems that are capable of responding to changingcircumstances[1] . Analysts, therefore,needagiledecision-supporttoolsthatcanadapttotheevolvinginformationneedsofthemission,suchasbyallowingtheanalysttoposenovelanalytic questions and to request automated monitoring for indicators & warnings onspecific situations. Yet existing automation support tools fail to provide this level ofsupport because they are often inflexible and cannot customize their execution tomeetcomplexornovel situations. Therefore, thenextgenerationof automation-support toolsneed tobedrivenby theanalyst,providing the flexibility to select and tailor capabilitiesbaseduponthenovelinformationneedsofthecurrentandanticipatedmissionstate.

ComposableAnalyticSystemsA viable solution to address the agile information needs of analysts is the use ofComposable Analytic Systems[2] (CAS). Composable software systems provide thecapability to select and assemble components in various combinations to meaningfullysatisfyspecificuserrequirements[3].Thegeneralgoalofacomposabledesignapproachisto allowsystemsengineers tomore rapidly investigateadaptingexisting technology toa

2

newmissionproblem[4]. It isthisflexibilitythatmakescomposabledesignsattractiveforintelligenceanalysissystems,allowingtheextantenterpriseservices,algorithms,anddatasourcestobecomposedtomeetnovelandemergingmissioninformationneeds.In many cases, composable systems are tools and environments that assist systemsengineers in the design and deployment of larger, aggregate systems. However, thepreferredcreatorofnovelanalyticqueriesandmission-informationneeds,theintelligenceanalystisourtargetend-userforCAS,notsystemsengineers.Therefore,ourinvestigationofCASformissionanalyticsfocusesonworkflowsystems,aparticularclassofcomposablesystems. Workflow systems allow end-users (often without formal programmingexperience or training) to specify and execute an ordered set of computational tasks orprocessesusuallyintheformofanintuitivedirectedacyclicgraph(DAG).ACAScapabilityallowsintelligenceanalyststoallocatecomplexanalysis,correlation,andfusion(ACF)taskstoautonomy,allowingthesystemtogenerateintelligenceproductsthatthehumananalystmayincorporateintotheirassessmentofhypotheses.

Figure1:CASTemplatesprovideconfigurableprocessestogenerateproductsCASWorkflows,whichwerefertoasTemplates,specifyaconfigurableprocessintheformof a DAG (as shown in Figure 1), that is used to ingest one or more inputs (e.g., datasources, previously-generated intelligence products), execute a series of computationaloperationsoverthatdata,andgenerateanewproduct.Theoperationsinthetemplatesarecohesive, single-scope algorithms that perform a function across a wide breadth ofcapabilities,including:dataI/O,datatransformations,geospatialoperations,dataanalysis,correlation, and fusion. Operations are comprised of exactly one output, zero or moreinputs(fromotheroperations),andzeroormoreconfigurationparametersthatcontrolitsunderlyingalgorithm’sbehavior.OperationsmustalsoexposespecificmetadatatotheCASinfrastructure so that their name, description, and input/output specifications can be

3

understood by the end-users. The algorithm implementations managed within eachoperationmaybedeployedlocallywithintheCASexecutionengine,oritmaybearemoteenterprise service invoked by the CAS infrastructure. Having a large collection ofenterprise-enabledoperationsprovidestheend-userwithavirtual“toolbox”ofoperationsthatcanbecomposedintoamission-focusedtemplatetoexecutecomplexbehaviorsthatrapidlyproduceintelligenceproductsthatanswertheend-user’sanalyticquestions.

ExampleCASUseCaseAs an example, we shall discuss a fictitious scenario. Intelligence analysts have a time-criticalhypothesisthattheforcesofanadversarynation,Pacifica,willwanttodefendasetof bridges in their country to ensure shipments of missiles. The intelligence cell,unfortunately,doesnothaveanup-to-datedatabaseofPacifica’s infrastructure, includingbridges. The first task for the CAS automation support tool is to identify a set of likelybridge locations. Then a second CAS task will examine recent Intel Reports aboutsuspected adversarymovements alongmajor highway routes aswell as Intel Reports ofactivity in thevicinityof thosebridges, generating a list of likelybridgeswith adversaryactivity.Figure2showsasingleCASTemplatethatperformsthesetwoanalysesandhelpsthe analyst answer the mission-focused question of “Where could the adversary beprotecting missile routes?”. In the template’s first task, the analyst chose to find thegeospatial intersectionofbodiesofwaterwithroadways. In thesecondtask, theanalystcorrelated these likely bridge locations with suspected routes and a set of SignalsIntelligence(SIGINT)Reports,thencreateaheatmapoverlaythatvisualizesthelikelihoodofwhichbridgesmaybeprotectedformissilemovements.In this simple example, the template can quickly generate an intelligence product in theformofaKMLMapOverlay that identifiesand filtershundredsof likelybridge locationsthat are correlated with potential adversary activity. The rapid generation of anintelligence product frees analysts from manual geospatial analysis and can answermission-specificanalyticquestions.LM ATL has conducted several small-scale evaluations of using CAS for providingautomation support for Intelligence Preparation of the Operational Environment (IPOE)tasks. Qualitative feedback fromanalystshas indicated thatCASautomation capabilitiescan reduce the amount of data gathering, filtering, and correlation work that is oftenmanuallydonebyanalysts.By freeingupanalysts fromthesecomplexanddata-orientedtasks, they have more time for higher-level analysis of the generated products and foranalyticcollaborationwithpeers.Additionally,CASprovidesanalystswithaneasierwaytoconduct “what-if” analysis by repeatedly executing CAS templates with varyingconfigurations (e.g., resolution, areas of interest, changing features under analysis),providingawiderbreadthofanalysesagainstalternateandcompetinghypotheses.

4

Figure2:TheexampleCAStemplategeneratesaproductthatmayanswertheanalyst’smission-focusedquestion

OperationalChallengesforCASDespite these benefits, analysts cite specific challenges in adopting CAS into theiroperationalworkflow.CreatingCAStemplatesrequirethattheendusersbecomeexpertson instructing the autonomyhow to generate the desiredworkproducts. CAS templatescansometimesbeverylargeandcomplex,asshowninFigure2,andtheirsuccessreliesonensuringthecorrectnessofthespecificdetailsinthetemplates.Thesedetailsmayinclude(butarenotlimitedto)ensuringtransformsforincompatibledatatypesandmatchingthecorrect data reader for specific data repositories. Therefore, template creators mustspecifyhowthetemplatemustgeneratethefinalproducts.Poweruserswithintheanalysiscellcanservethisfunction,buttorealizetheCASvisionofanalyst-driven,mission-focusedautomation support, the individual analysts must be able to quickly and accuratelycomposetheirowntemplates.InourPacificascenario,theanalysthadtoconstructatemplatethatsetsearchlimitsontothe AOI of Pacifica, ingested specific geospatial data files (e.g., bodies of water, roadnetworks), filteredoutnon-majorhighways, ingestedIntelReports, filteredthosereportsfor recent SIGINT reports and adversary movements. Then the analyst instructed thetemplate to build a heat map-style geospatial overlay that shows the correlation ofinformation. Whileallof these tasksarecomposableandunderstandableby theanalyst,

5

the process of template construction is very detail-oriented and requires knowledge ofspecific data sources, mechanisms to filter data with respect to the data schemas, anddetails regarding overlay construction. While the composition of such templates arefeasible when created a priori, they are not readily composable during in-missionsituationswhenthenovelanalyticquestionsarehypothesized.ThischallengemotivatesourCASresearchtowardanewgoal,namelytoprovideanalystswith theability torapidlyspecify to thecomputersystemwhat intelligenceproduct theyneedduringmissions,ratherthanconstructingtemplatesthatspecifyhowtogeneratetheproductapriori.Tomakethisspecificationprocessmorenatural,quicker,andsimplerforthe analyst, we propose that the analyst specifies their product needs via a constrainedEnglish interface. Withthisuser interfacemodel,boththeanalystandtheautonomyarefocusedontheintelligenceproduct,withtheanalystspecifyingtheproductneeded,andtheautonomysatisfyingthatspecificationwiththetoolsanddataavailable.

TheSWOOPSystemComposableanalyticscanprovideseveralbenefitstoinformationandintelligenceanalysts,but the challenges in creating such orchestrations inhibit operational adoption. Wepropose a capability that seeks to provide a semi-automated method of CAS Templatecreationthatunburdenstheend-userfromdesigningtheorchestrationofCASoperationsto generate intelligence products, while maintaining the CAS agility to answer novelanalyticquestions from theuser. TheSHOP2WorkflowOrchestrationPlanner (SWOOP)allows analysts to specifywhat the desired intelligence product should contain using anatural constrained-English interface, rather than creating a DAG that instructs thecomputer on how to create the same product. Once the product information needs arespecified by the end-user using domain-specific terminology, SWOOP autonomouslygeneratesandexecutesaCASTemplatethatrealizesthatproductspecification.

SWOOP-enabledExampleIn our CAS example scenario, the analyst constructed two templates that (1) identifiedlikelybridge locations and (2) created a correlationof thosebridge locationswith likelymobilemissile routes and SIGINT reports in the formof a heatmap overlay. Using thissame scenario, SWOOPwill allow the end-user to generate the same products, but in amorenatural constrained-English format thatcanbecommunicatedquickly,as shown inFigure3.

definenewobjectDerivedBridgesfromintersectionofroads,waterwaysinAOIPacifica.createheatmapfromcorrelationofmissile-routes,sigint,DerivedBridgesinAOIPacifica.

Figure3:TheanalystnaturallyspecifieswhatproducttheywantviaaConstrainedEnglishinterface

6

Internally, SWOOP parses this text, extracting the high-level tasks and goals, andautomatically identifyingthenecessaryalgorithms/operationsandgeneratingaDAGthatistopologicallysimilarandfunctionallyequivalenttotheCAStemplatecreatedbytheuserinthepreviousexample. Afterpost-processing, theresultingDAGisprovidedtotheCASengine,generatingtheproductspecifiedbytheuser.TheDAGshowninFigure4illustratesaSWOOP-enabledCASTemplatethatissimilartothetemplateinFigure2.

Figure4:SWOOPgeneratesanoperationorchestrationplanthatisconvertedtoaCAStemplate

SWOOPArchitectureSWOOP is comprised of several components and intermediate data items that enable itsability to auto-orchestrate algorithms and network services to generate intelligenceproductsforitsusers,asshowninFigure5.TheSWOOPprocessbeginswiththeMissionContextdata,anontologythatrepresentstheinformation needed to bootstrap both the conversation with the user (e.g., IntelligenceAnalyst)aswellastheplanningsubsystem. Fortheuser’sconversation,MissionContextprovidesthesetofnounsandverbsavailabletotheConstrainedEnglishforthisparticularinstallationofSWOOP.ThenounsaretheAreasofInterest,units,anddatasourcesusedtosupport the missions, while the verbs are mapped from the algorithms and enterpriseservices accessible by the CAS Engine. Additionally, the Mission Context provides theplanningsubsystemwithaconcepttaxonomyspecifyingthebreakdownoftermsprovidedby the user and theirmappings to core data types. The SWOOPMission Context data isencodedinamulti-worksheetExcelspreadsheetforeasymaintenance.TheConstrainedEnglishProcessor(CEP)isthecomponentthatinteractswiththeuserviaaconstrained natural language interface. CEP accepts the user’s constrained naturallanguage description of what the final Intelligence Product should be, then provides avalidatedsetofproductspecificationstotheMissionContextPreprocessor(MCP).TheMCPaccepts the specification as well as the mission context then produces the lisp-stylepredicatesrequiredbytheplannertogenerateasetofworkflowplans.

7

Figure5:TheSWOOPArchitectureusesanalystandmissioncontexttogenerateintelligenceproducts

SWOOP uses the Simple Hierarchical Ordered Planner (SHOP2) domain-configurableautomatedplanning system to generate a set of draft plans for theproduct specificationprovidedby theuser through theCEP andMCP. Theseplans are already in the formofdirected acyclic graphs, but SHOP2mayproducemultiple planswith small variations oralternateplansbasedonambiguitiesofthemissioncontextorproductspecification. TheTemplate Translator’s (TT) role is to accept these draft plans fromSHOP2, validate theircorrectness,chooseone,andtransformit(syntactically)intoaCASTemplate.OnceintheformofaCASTemplate, theCASEnginewill instantiateandexecute theorchestrationofoperationslaidoutintheSHOP2plan,resultinginanintelligenceproductfortheuser.

TheSWOOPOntologyTheSWOOPontology (illustrated inFigure6)containsallof thegoals that represent thespecifications of the user’s desired intelligence product, as well as the contextualinformation thatCEPneeds tounderstand theverbsandnounsof thedomainaswell asinformationthatSHOP2needstogenerateworkflowsfortheuser.TheConceptsarethehierarchicaldomainandmission-specifictermsthattheuserwilluse.These may include: “transportation network” (and its sub-concepts “roads,” “rails,” and“airways”), “area of interest,” “report” (and its sub-concepts “SIGINT”, “HUMINT”, etc).Concepts are abstract terms that represent information content, but are not directlyindicative of any kind of data type or schema. The ontology allows for concepts to bemapped toTypes. For example, the concept “road”wouldbemapped to a type of “line”indicatingthatroadsarecomposedofasetoflinestrings.Justasconceptsarehierarchical,

8

so are types. For instance, specific types of “line,” “point,” and “polygon” are alldescendantsofagenerictypecalled“geospatial.”Athirdclass,DataFormat,identifiesthevariousschemasofinformationthatthesystemcanaccess/parse.Thiscanincludespecificwell-defined schemas such asOpen StreetMap (OSM)Textual Format[5], Geonames[6], orKeyholeMarkupLanguage(KML)[7].DataFormatsshouldbeasspecificaspossiblesothatSWOOPcanmatcha“reader”operationtoaschema.HavingaDataFormatof“XML”wouldbemeaninglesstothesystemwithoutknowingtheXSDorDTDthatspecifiesthedatabeingmodeled. Therefore,DataFormatsshould identifyaspecificdataschemawhenpossible.DataSources are theontological instances that tellSWOOPexactlywhatdata isavailableforuse in theworkflow,by specifyinga location (e.g.,URI, filepath,database locator)ofdata that is of type Data Type and models a specific Concept, and constrained in timeand/or space by zero ormoreConstraints. This is used to identify specific data sourcesavailabletothesystemsuchas:afilepathforroadnetworksinOSMformatforthecountryof Pacifica and anHTTPURI for roadnetworks inKML for only the southernportion ofPacifica.Betweendatasourcesandconcepts,thisontologycanprovideasetofnounsforusebytheCEPwheninteractingwiththeuser.TheontologyalsoidentifiestheavailableOperations(i.e.,softwarealgorithmsandservices)that comprise the tasks in CAS Templates and can be executed by the CAS Engine.Operationinstancescanbeoneoftwoflavors:DataSourceOperationsorDataTransformOperations. DataSourceoperationsare thesoftwarealgorithms thatunderstandhowtoread/parse/querytheaforementionedDataFormatsandoutputdataintoaCASType.DataTransformOperationsarethosesoftwarealgorithmsthatingestonemoreInputs(Outputsof otheroperations)of specificCASTypes, andgenerateanewormodifieddata setof aspecificCASTypeusingthealgorithmitwraps.TheoperationsprovideasetofverbsthatareavailableforuseintheCEPforinteractionswiththeuser.ForSHOP2toplananorchestrationofoperationsthatsatisfytheuser’sspecificationofanintelligenceproduct,theontologymustalsobeabletomodelthatspecificationintheformofplanninggoals. TheGoals of aplanning scenariodescribe thedesired concept(s), anyspatio-temporal constraints that scope the goals, aswell as any explicitmethods (in theformoftailoredoperations)thatmustbeusedinthegenerationoftheproduct.Withtheinformation modeled in this ontology, SHOP2 can generate a workflow of configuredoperationsto:fetchrawdata,transformdataviaselectalgorithms,andgenerateaproductthatsatisfytheuser’sinformationneeds.

9

Figure6:TheSWOOPontologyfacilitateshuman/computercollaborationbymodelingboththemissionand

computingdomains

ConstrainedEnglishProcessorADomain Specific language (DSL) is a computer language designed for use in a specificdomain so that an expert may specify data models and processing instructions usingfamiliar domain specific terminology and a simplified syntax. Amajor reasonwhy DSLsmay be preferred over a general-purpose programming language is they allow domainexperts to develop, understand, andmanage datamodels or processing steps directly. ADSL isdefinedby a grammar specification language,mayhavea customsyntax/contextaware text editor, as well as several other components, such as a parser, linker,typechecker, and compiler used to automatically translate the domain experts’ programintogeneralpurposeexecutablecodesuchasJava.WedesignedaprototypeDSLthatallowsananalysttodeclarethattemplateoutputscanbeidentifiedasnewdatatypesandfeaturesusingstructurednaturallanguagewithouthavingtospecifydetailsonhowtheywillbecreatedandfromwhatdata.Theanalyst’sdeclarativespecificationisthenparsedintoadatastructurerepresentingagoalstateforourplannerwhichfiguresoutthehow.

See Figure 3 for an example specification of a new data type, DerivedBridges. Here wedefine a bridge object anytime we find in our dataset an intersection of a groundtransportationroute(road,rail,etc.)andawaterway(river, lake,etc.)wherethereisnotalready a structure labeledBridges.We also impose additional constraints, such limiting

10

oursearch toaparticularAreaof Interest (AOI),asdone inFigure3,wherewe limit thedefinition to Pacifica. This specification will be converted into executable code by ourcustom-built parser, linker, typechecker, and compiler, and passed off to our planner sothatitmayfindtherightsequenceofactionstotaketocreatethesetypesofobjects.

WeleverageXtext[8],anopensourcelanguagespecificationframeworkthatprovidesaDSLgrammarandallowsforeasycreationofacontextawareIDEaswellastheparser,linker,typechecker, and compiler.Ultimately, Xtext builds an internal data structurebyparsingtheDSLspecificationandexecutescodewehavecreatedtoquerythatdatastructureandtowritenewcodebasedonthatstructure.Inourcase,wecreateagoalstatespecificationtopassintoourplanningalgorithms.

MissionContextPre-processorThepurposeoftheMissionContextPre-processoristoprovideaScenario(asspecifiedinthe SWOOP ontology) in the form of planning predicates, to the SHOP2 planner. Thisscenario is a self-contained set of planning goals from the user and the context thatincludesallknowndatasources,concepts,andCASoperations.MCPreceivesthescenariogoalsfromCEP,aggregatesthisScenarioinstancefromvariousstaticanddynamicsources,validates the scenario, and then generates the lisp-style input to SHOP2. A subset of anexamplescenarioisshowninFigure7.

TheSimpleHierarchicalOrderedPlanner(SHOP2)SHOP2,ageneral-purposehierarchicaltasknetwork(HTN)planner[9][10]thattakesmissionspecifications in terms of goals, mission context, and priorities, and refines them intodetailedplans.Unlikestillactively-usedHTNplanners[11][12][13][14][15][16],SHOP2canoperateeither wholly autonomously, or as part of a mixed-initiative human/automation team.When running fully automated, SHOP2 can autonomously choosemethods for achievingtasks and subtasks, and assign resources to those tasks and subtasks. Alternatively, thehuman operator can “dive down” into the hierarchical structure of the play to offerincreasingly specific instructions about exactly how a given taskmust be performed, orwhichresourcesmustbeassignedtoit.LikeotherHTNplanners, andunlike first-principlesplanners, SHOP2 searches top-downfrom a task specification or a network of tasks, rather than chaining together primitiveactions.SHOP2reasonsaboutprioritiestogenerateaplan,re-planningwheneverthegoalsandprioritiesevolveorthesituationchanges.SHOP2decomposescomplexmissiontasksinto more primitive tasks and sub-tasks (methods), thus building a plan tree thatterminates at leaves corresponding to primitive “actions” (operators). Methods describehow to perform complex tasks. A method definition associates a task with a set ofpreconditions and a task network. When the preconditions are satisfied, a task thatmatches the method definition can be decomposed to the given task network. Tasknetworks areworkflows of tasks thatmay be constrained to be ordered, or that can beexecuted in any order (unordered). For example, theHTNmethod shown in Figure8 iswrittenforCAStemplatesinSWOOP.

11

Figure7:TheSWOOPscenarioprovidesmissioncontexttotheautomatedplanner

SHOP2isaplanningsystemthat“fillsinthedetails”ofthegivenmissionspecificationandintent, computing plans to accomplish tasks within specified constraints. SHOP2 takesprocedural and operational descriptions of missions, analyst heuristics, commander’sintent, and planning knowledge, and refines them into detailed plans. Plans can containhierarchically defined sub-goals that are assigned to lower-level units and trigger local,context-sensitiveplanningandexecutionbehaviorsbasedonlocal,possiblyincompleteoruncertain information. This ispossiblebecauseSHOP2performs taskdecompositions in

;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; Type Hierarchy (subtype-of geospatial lines) (subtype-of geospatial polygons) (subtype-of geospatial points) (subtype-of geospatial cells ;; ... ;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; Concept Hierarchy (subconcept-of transportation roads) (subconcept-of transportation airways) (subconcept-of usmtf-report sigint-report) ;; ... ;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; Concept-Type Maps (concept-type-map roads lines) (concept-type-map nais polygons) (concept-type-map heatmap cells) ;; ... ;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; Goal(s) ( (find ( ;; Task #1: (intersect (:aoi pacifica) (:concept (roads waterways)) (:as DerivedBridges) ) ;; Task #2: (fuzzy-and (:aoi pacifica)

(:concept (missile-routes DerivedBridges sigint)) (:as heatmap) ) ) ) )

12

theorderthosetaskswillbeexecutedintheCASengine.Asaresult,SHOP2knowsthestateoftheworldatalltimesusingthisforward-chainingsearchparadigm;itenablesSHOP2toperform axiomatic inference, arbitrary numeric computations, incorporate optimizationduringplanning,callarbitraryexternalfunctionsandprograms.Forinstance,intheaboveexample, it is possible to configure INTERSECT because SHOP2 already know AOIinformation and target concepts from the evolution of the planning state through othercomputationsandplanningactionsuntilwhenthismethodisused.

ConfigurabilityoftheHTNmethodsinSHOP2isnotonlyovertheinputsandoutputsofthesubtasks.SHOP2alsoallowsHTNmethodstobewrittenabstractlyandconfigurableforthesubtasksthatwillaccomplish.Forexample,inSWOOP,theinputDSLcouldspecifydifferentworkflow taskswith different configurations. Fromknowledge-engineering and usabilityperspectives, it is not reasonable to encode every possible workflow task and itsconfigurationthatcanbespecifiedbytheuserasanHTNmethod.Instead,theHTNmethodshowninFigure9controlsthisabstractinputanditspotentialconfigurations.ThismethodtakesthetasksthattheFINDdirectivefromtheuserasaninput,asopposedtohard-codingeverycombinationtheminthesubtasks.Thefirstandthirdsubtasksofthemethodcreatesandcloses theXMLdocumentwhosecontentwill encode theworkflowgeneratedby theplanning process. The subtask ACHIEVE-TASK iteratively walks over the configurationpreferencesintheparameter?TASKSandaccomplisheachofthemasitstichesthesolutionworkflow.

(:method (intersect ?template-id ?inputs ?output ?output-concept) ;; Preconditions ((task-constraint ?template-id :aoi ?user-aoi) (task-constraint ?template-id :concept ?user-concept-list) (task-constraint ?template-id :as ?user-target-concept) (map-to ?user-concept-list nil ?user-types) ) ;; Subtasks: ( (intersect-inputs ?user-concept-list ?user-aoi ?user-types 0 nil ?input-triples) (intersect-output ?intersect-id ?input-triples ?output ?output-type ?user-target-concept) ))

Figure8:HTNmethodsassociateataskwithpreconditionsandatasknetwork

13

TemplateTranslator(TT)SHOP2producesasetofpredicates thatrepresentadirectedacyclicgraph(DAG)ofCASoperations.ThisDAGprovidesenoughdetailstoensurethattheoutputsofoperationsareroutedtothecorrectinputportsofdownstreamoperations(asshownintheedgelabelsinFigure4)aswellastheconfigurationparametersfortheoperations(numberedtextinsidenodes) based on the scenario predicates provided by the MCP. Because the DAG planproducedbySHOP2isfunctionallyequivalenttoaCASTemplate,translatingtheoutputisatrivialstep.However,beforetheDAGcanbetranslated,theTemplateTranslator(TT)hasthe important taskofchoosingtheoutputplanto translate. SHOP2canprovidemultipleplansbasedon thespecificityof theplanninggoalsandalso theHTNmethods thatwereused in the creationof theplans. TT first confirms that theDAGsare indeedvalid, thenremovesfromconsiderationanythatmayhaveerroneousormissingcomponents.SWOOPwillemployoneoftwostrategiestoselecttheDAGforconversiontoaCASTemplate:MostConfident and Smallest Depth. SHOP2 provides its results in descending order ofconfidence, and TT can select the first valid DAG. Typically, however, we have foundthroughtestingvariousscenariosthatchoosingtheDAGwiththesmallesttreedepthgivestheDAGthatclosest tooptimal. For futurework,weplantoresearchothermethods forDAGselection,includingplancritiquemethodsandmachinelearningapproaches.

ConclusionsWehave created aprototypeof the SWOOPcapability, buildinguponour experiences inCAS and automated HTN planning. We envision that SWOOP can be used effectively inenvironmentswhereinformationanalystsacquire,filter,transform,analyze,correlate,andfuselargequantitiesofMulti-INTorheterogeneousdata,suchasintelligenceanalysisandProcessing,Exploitation,andDissemination(PED)cellswithintheIntelligenceCommunity.

(:method (find ?tasks) ((template-header ?xmlns ?xmlns2 ?xmlns3 ?exec-interval ?exec-iter ?user-template ?user-id ?user-name ?template-id ?template-name ?template-descr ?template-catID)) ( (!!start-xml-template ?xmlns ?xmlns2 ?xmlns3 ?exec-interval ?exec-iter ?user-template ?user-id ?user-name ?template-id ?template-name ?template-descr ?template-catID) (achieve-task ?tasks ?template-id) (!!close-xml-template ?template-id ?template-name) ))

Figure9:ConfigurabilityofHTNmethodsallowforgeneralizationacrossawiderangeoftasks

14

The SWOOP capability focuses on our proactive human/autonomy collaborationapproach[17] where both the human and the autonomy contribute to the same workproduct.Inthiscase,theworkproductisanintelligenceproductspecifiedbytheanalyst,where the autonomy acquires, filters, correlates, and fuses information for that product,facilitatingthehumanuserinmaximizinghertimeanalyzinganddrawingconclusionsfromthe autonomy-provided information. By allowing the analyst to specify the informationneeds via a natural language interface using domain-specific terminology, SWOOPminimizesadverseeffectsontheanalyst’sworkflow.WehaveidentifiedasetofareasinwhichSWOOPcanbeimprovedwherefurtherresearchcanimproveitseffectivenessinoperationalenvironments.Firstly,theSHOP2plannercanprovide multiple plans from a single user product specification. The accuracy of theSWOOP-generated CAS templates will benefit from amore robust method of validating,critiquing,andselecting thebestplan thatmeets theuser’s informationneeds. Anotherareaforcontinuedresearchisautomatedlearningand/orgenerationoftheHTNmethodsused by SHOP2. Currently, prior to use, someHTNmethods require that a human useridentifiesandencodescommonCAStemplatedesignpatternsbeforetheycanbeusedbyanalysts in theirnatural languageproduct specification. Byautomating thisprocessviamachinelearningwouldprovidegreaterflexibilityoftheSWOOPcapability.

References[1] “JointPublication2-0,JointIntelligence”.DefenseTechnicalInformationCenter(DTIC).Departmentof

Defense.22October2013.pp.II:10-11.RetrievedJanuary16,2017.

[2] P.DiBona,,J.Llinas,,andK.Barry.“ComposableAnalyticSystemsfornext-generationintelligenceanalysis”,Proc.SPIE9499,Next-GenerationAnalystIII,94990N(May15,2015);doi:10.1117/12.2184177;http://dx.doi.org/10.1117/12.2184177

[3] Davis,PaulandCommitteeonModelingandSimulationforDefenseTransformation,NationalResearchCouncil.DefenseModeling,Simulation,andAnalysis:MeetingtheChallenge.Washington,D.C.:NationalAcademiesPress,2006.

[4] Oster,Christopher,Wade,Jon,EcosystemRequirementsforComposabiltyandReuse.

[5] OpenStreetMap.OSMFileFormats.RetrievedonFebruary22,2017fromhttp://wiki.openstreetmap.org/wiki/OSM_file_formats

[6] Geonamesworldwidedataset.RetrievedonFebruary22,2017fromhttp://geonames.org,ThisworkislicensedunderaCreativeCommonsAttribution3.0License.

[7] OpenGeospatialConsortium.KeyholeMarkupLangaugespecification.RetrievedonFebruary22,2017fromhttp://opengeospatial.org/standards/kml

[8] TheEclipseFoundation.Xtext.RetrievedonFebruary22,2017fromhttp://www.eclipse.org/Xtext/documentation/index.html

[9] T.-C.Au,U.KuterandD.Nau.2005.WebServiceCompositionwithVolatileInformation.ProceedingsoftheISWC-05.

15

[10] D.Nau,T.-C.Au,O.Ilghami,U.Kuter,H.Munoz,W.Murdock,D.Wu,andF.Yaman,2005.ApplicationsofSHOPandSHOP2.IEEEIntelligentSystems.20(2):34-41.

[11] Tate,A.(1977).Generatingprojectnetworks.InIJCAI-77,pp.888–893.

[12] Tate,A.,Drabble,B.,&Kirby,R.(1994).O-Plan2:AnArchitectureforCommand,PlanningandControl.MorganKaufmann.

[13] D.E.Wilkins,PracticalPlanning:ExtendingtheClassicalAIPlanningParadigm,MorganKaufmann,SanMateo,CA,1988.

[14] Erol,K.,Nau,D.,&Hendler,J.(1994).HTNplanning:Complexityandexpressivity.InAAAI-94.

[15] Erol,K.,Hendler,J.,&Nau,D.(1996).ComplexityresultsforHierarchicalTask-Networkplanning.AnnalsofMathematicsandArtificialIntelligence,18,69–93.

[16] Sohrabi,Shirin,andSheilaA.McIlraith.“OnplanningwithpreferencesinHTN.”Proc.ofthe12thInt’lWorkshoponNon-MonotonicReasoning(NMR).2008.

[17] P.DiBona;A.ShillidayandK.Barry "Proactivehuman-computercollaborationforinformationdiscovery“,Proc.SPIE9851,Next-GenerationAnalystIV,985102(May12,2016);doi:10.1117/12.2222805;http://dx.doi.org/10.1117/12.2222805