R3** P&P Task List
The version of the browser you are using is no longer supported. Please upgrade to a supported browser.Dismiss

View only
WBSTypeIterationTaskDescriptionOutcome of task (deliverables)Risk (COs)R3I1-PPR3E1-PPR3E2-PPJira Task#PriorityWork daysAssigneeSupport RolesDescription Page URLQuestions and CommentsStatus
2 & ProsecutionThe Planning & Prosecution services leverages the capabilities of the consistent integrated network of sensing, modeling and control resources and services supporting resource nesting and resource autonomy. This subsystem provides generalized resource planning and control activities that will be applied to plan, schedule, and prosecute multi-objective observational programs. It also provides support to control autonomous parts of the system, such as AUVS and disconnected moorings.
ITR3I1Review and revise architectureReview the service architecture and the cross-subsystem interfaces and dependencies. Approve all interfaces as cross-subsystem dependencies. For each service group and service component, revise the descriptions in the architecture specification on Confluence. With the architect, revise the EA specification for the architecture if needed. Add detailed diagrams where important to understand component design.High Level Design and updated architecture documentation in both Confluence and EA.X53mmeisinger
ITR3I1Revise subsystem use casesUpdate the subsystem use cases, adding necessary level of detail. Include developers, architects and UX participants. Review all system level use cases for impacts on this subsystem.Updated subsystem use cases.X52mmeisinger
ITR3I1Review subsystem Release Construction Plan and propose revisionsReview the Release Construction Plan for this subsystem and mark all changes to use cases, service groups and service components. Prepare ECR for all changed items of the schedule and communicate all changed descriptions to their primary locationUpdated construction plan and any ECRs for requested changes.X41mmeisinger
ITR3I1Review and revise technology list, subsystem risks, and risk mitigation planRevise technology list, subsystem risks, and subsystem risk mitigation plan, based on feedback from design and prototyping. Updated technology list, risk list, and subsystem risk mitigation plan.X41mmeisinger
ITR3I1Author elaboration plan and Elaboration iteration 1 task listDefine the main activities and integration points with other subsystems as schedule with dependencies. Coordinate with other subsystems. Assign the activities to the iterations in elaboration, paying attention to cross-subsystem dependencies and providing slack for unforseen delays. Break down the elaboration plan for elaboration iteration 1 with candidate tasks described enough so that they are ready to be handed over to the developers.Identified dependencies for each activity in subsystem. Subsystem activities divided across elaboration periods according to dependencies. Clearly defined set of elaboration 1 tasks.X51mmeisinger
8 Observatory FacilityBuilding on the capabilities of the Marine Observatory Facility, provides the services to design, assemble, and operate configurations of resources from across the OOI into unique systems for planning, testing and prosecuting observation requests, leveraging the nested and autonomous capabilities of the fully integrated network of sensing, modeling, and control resources.
9 observatory facilitySpecialization of the COI federated facility. Governs the resources associated with an interactive observatory. Has an affiliation as member with the ION facility and can negotiate other agreements with individuals and organizations. Provides the services to compose observational misssions using a quantity of resources and their behaviors
ITR3I1Name and identify design interfacesDefine initial list of interfaces between platform autonomy components (MOOS based), platform-based planner components (CASPER), platform side agents, shore-side planner components (CASPER/ASPEN based), ION services (primarily SA and PP) and ION user interfaces with descriptions of each. Use MOOS as exemplar system, provide training to CI team on MIT simulation and interface environment. Define implementation plan to satisfy MOOS interface.Training materials on MOOS environment. Initial list of services and descriptions. Initial implementation plan.X52arjunabhschmidt, mmeisingerInitial training Fri 9/14, meeting 9/21 in DC
ITPrototype ASPEN with IONCreate a prototype of a standalone, interactive ASPEN that is connected to the Integrated Observatorychien
12 observatory facility policy modelDefine the policy structure applicable to the the interactive observatory facility. Define roles, resources, actions and other elements of the facility contract and commitment model.
13 observatory policy definitionCapabilities related to the definition of interactive observatory policy, resource use etc. Extends and aggregates the policy definition for the marine observatory, virtual observatory, laboratory and federated facility policy
14 observatory validationProvides services to validate observational mission workflows
15 observatory resource managementProvides the services to govern resources utilzed in an observational mission according to policy
16 observatory prosecutionProvides the services to execute an observational mission by cueing disparate and potentially autonomous resources based on their behaviors
17 observatory resource discoveryProvides services to identify resources according to specified attributes to perform collaborative tasks
18 ResponseProvides services for policy and behavior based reconfiguration of tasks and observational programs. Provides a nested communication, command, and control architecture that enables and supports the deployment and prosecution, fully autonomously or under operator control, of new missions, processes and behaviors, in parallel to and without interruption of prior platform objectives.
19 response resource and metadata modelSpecification of event response workflows as resources and associations, with provenance, versioning and metadata attributes
20 response modelDefines a nested communication, command and control architecture for event response
ITPrototype event detection and response workflowPrototype an event detection and adaptive response workflow, ideally using the Integrated Observatory and its generic workflow capabilitychien
22 response transformation processesProvides the services to transform published events into mission tasks utilizing resource behavior models
23 response reconfiguration processesProvides the services to reconfigure observational missions utilizing defined mission tasks
24 response operator supportProvides the services for operator interactive control of event response
25 Control Software (Part 1)Provides a portable, platform-generic higher-level control software package that can run on fixed observatory assets, gliders, and AUVs operated in the observatory. The software provides a standard communication, command, and control connectivity with the overall OOI CI, and a standard NMEA interface to natively control software on the platforms.
26 behavior definitionProvides services to define and the behaviors of fixed and mobile observatory assets to be executed within the portable control software. Behaviors include navigation behaviors, such as loiter, go-to-waypoint and follow thermocline
27 behavior executionCapabilities that translate defined behaviors into low-level commands to resources
28 executiveProvides capabilities to autonomously execute complex mission plans within frames of constrains and the ability to compensate for anticipated and unanticipated events. The smart executive translates mission plans into continous events
29 compensatorProvides capabilities to monitor autonomous resources and smart executive commands and evaluate for failure conditions. Compensates by providing compensating commands to the smart executive.
30 software integrationIntegration of an emedded autonomy package, such as MIT MOOS-DB. This should be a package ready for deployment on CI supported embedded environments.
ITR3I1Design refinement on use of Goby and uFields to integrate MOOS with ION on platformArchitects meet with Goby designer (Toby) to determine usability of Goby as a generic interfacing mechanism between ION agents and MOOS communities. Look at uFields routing model and evaluate its applicabilityCandidate design descriptionX42arjunabToby
ITR3I1Set up MOOS simulation environment using ION virtualizationSet up a simulation environment for one full vehicle MOOS community within a suitable ION virtual machine (e.g. Gumstix compatible), such that a MOOS community can be executing plus components needed for the simulation environment. Work towards interfacing with ION services and agents to control this environment (e.g. data flows, service calls, resource registry)Repeatable MOOS simulation setup in ION VM, available to teamX57arjunabAlon
ITR3I1Set up ocean coverage model with simulation environmentGet recording from ROMS integrated into simulator, using a dynamic data set modeled/recorded over a time period.MOOS coverage prototypeX22arjunabWayne
ITR3I1Demonstrate MOOS asset in simulated environmentDemonstrate operation of one autonomous MOOS-controlled asset in simulation environment. Asset should be inspired by what OOI Endurance array uses. Demo should be inspired by operational use cases of OOI Endurance assetsMOOS operational assets prototypeX42arjunabHenrik
ITR3I1Work on MOOS iSensor module to support simulatorsWork on the implementation of the iSensor module, such that simulation environments can be readily supported without need to change the sensor module or the MOOS community setup. Simulation vs. real-deployment should be a change of a startup flagRefined iSensor codeX33arjunabStephanie
ITConnect MOOS sensors to IONObtain data from, exchange messages with, and control MOOS IvP sensors using Integrated Observatory.Integrated ION-MOOS prototypeXarjunab
ITAccess ocean coverage model via IONProvide MOOS environmental coverage model via ION.XActually an A&S task? (Matt A's suggestion.)
38 navigation software integrationIntegration of an off-the-shelf autonomous navigation software package, such as MOOS-IvP, the public domain MOOS mission control software into a portable control software package that operates with the CI
39 smart executive software integrationIntegration of off-the-shelf smart executive software, such as JPL CASPER for discrete mission plan execution and control of behavior oriented autonomy software.
ITCASPER-MOOS IvP AUV control prototypeBuild refined prototype in which CASPER and MOOS-IvP are integrated to perform embedded control of AUVs.
41 control managementProvides services to configure and manage the portable control software
42 Plan ManagementProvides and maintains platform specifications, planning elements, and plan and behavior modules for a variety of multi-objective ocean observation missions, such as the capture of a coastal upwelling event. A representative set of plan and behavior modules that adhere to a flexible precondition language for generically-conditioned autonomy actions will be introduced.
43 behavior modelDefinition of a model to capture the behaviors of fixed and mobile assets and associated metadata
44 plan modelDefinition of a model to capture observational plans and associated metadata
45 behavior specificationProvides services to specify the behaviors of taskable resources and persist them in the mission catalog
46 plan definitionCapabilities to author and test observation plans
47 plan registrationProvides services to register observation plans and their constituent elements
48 plan search and retrievalProvides services to present catalogs for observation plans and their constituent elements
49 plan associationProvides services to associate a given observational plan with other plans according to a specified set of attributes
50 Planning (Part 1)Provides software tools and user interfaces for the scientist defining a set of states for each fixed or mobile node involved in a planned experiment or observation campaign, and to design the associated, conditional state transitions, forming the basis for defining the behavior algebra (language) necessary to complete a predetermined, as well as autonomously adaptive sensing task.
51 workflow modelSpecification of planning and control workflows as a resource, with provenance, versioning and metadata attributes. Specialization of the generic workflows
52 workflow templateDefinition of template workflow for planning and control, based on the generic workflow services and capabilities. Includes the definition of intermediate steps, data formats, event types, command sets, interactive steps, visualization options, etc such that it can be specialized by parametrization or customization for most of the necessary planning and control workflows
53 workflow definitionCapabilities to define planning and control workflows and to describe them, based on the planning and control workflow template or based on the generic workflow. Capabilities to define planning and control workflow templates. Capabilities to compose planning and control workflows out of existing workflows.
54 workflow schedulingProvides the services to parametrize, configure and schedule planning and control workflows based on workflow definitions
55 workflow managementProvides services to monitor and modify scheduled and executing planning and control workflows subject to policy
56 workflow toolsetProvide a defined, user approved set of commands, policy templates, decision trees, failure compensation behaviors, situational analysis and awareness tools for typical planning and control workflows. Users sign off on the list of workflow items at LCO for this release.
57 behavior algebra frameworkDefines the behavior framework for implementing the planning services
58 specification modelProvides services to define the states and state transitions for taskable resources
59 specification supportProvides services to specify environmental parameters from historic data or models and persist them in the mission catalog
60 planner integration frameworkProvides a framework with service frontent for the integration of resource planners and constraint solvers. Connected to planning and control workflows with input and output data streams.
61 resource planner software integrationIntegrate and interactive resource planner, such as the ASPEN planner software