UGS SWG Charter Draft

UGS SWG Charter Draft

Draft UGS SWG CharterUNCLASSIFIED30 March 2011

Unattended Ground Sensor (UGS)
Standards Working Group (SWG)

Charter

Contents

1. Purpose ………………………………………………………………….…………………...... 3

2. Background …………………………………………………………………………….……....3

3. Authority ………………………………………………………………….…………………..…4

4. Vision and Objectives …………………………………………………………………….…4

5. Concept of Operations...……………………………………………………………..……..5

5.1 UGS SWS Membership ……………. ……………………………………………..…6

5.2 UGS SWG Roles and Responsibilities ………………………………………..…7

6. Ongoing Relationships………………………………………….………….……….……….9

6.1 DIA Initiatives……………………………………………….………………….10

6.2 US Community of Practice………………………………………………….11

Appendix A: Under Secretary of Defense for Intelligence Memorandum…….12

Appendix B: Terms of Reference….………………………..……………….………….…..13

Appendix C: Membership…….. ……………………………………………………………...14

Unattended Ground Sensor (UGS)

Standards Working Group (SWG)
Charter

1 Purpose

This charter documents the mission, vision, and purpose of the UGS SWG and presents the roadmap for how the SWG intends to operate. The charter also represents an agreement among members on how the group will work as an empowered partnership to address their objectives. This charter is intended to be a living document and will be revised as conditions warrant.

2 Background: Problems with Current UGS Systems

The UGS SWG defines the term UGS broadly. For the purposes of this group, UGS include intelligence, surveillance, and reconnaissance (ISR) sensors that provide a high-resolution, low-latency look at what is happening on the ground. They may be stationary, on ground vehicles, on people, and on low-flying unmanned aircraft systems (UAS).

The UGS SWG concept originated from the need to resolve the following issues:

  • Stovepiped architectures. Users have developed and fielded multiple stovepiped UGS systems to meet requirements. Each system has had its own training plan, communications path, mission planning/employment tools, and graphical user interface (GUI). Operators need to mix and match sensor components from different vendors to maximize flexibility and minimize the amount of equipment they have to bring to the field.
  • Vendor-proprietary hardware and software. Users needing to have new or additional sensors integrated into an existing UGS architecture have had to return to the original vendor for integration, resulting in increased costs and extended timelines.
  • Inflexible systems. Mission requirements are often not fully understood until operators are given specific missions in the field, at which point they must shift activities and related tools. Missions occur in which the selected equipment does not meet the mission requirements and must thus be adjusted or quickly integrated with whatever is to hand in the field.
  • Difficult insertion of new technologies. The lack of common interfaces, communication protocols, and payload formats make inserting new technologies into existing systems difficult, expensive, and time consuming.
  • Difficulty with processing, exploitation and dissemination (PED) activities. The mission of analysts and collection managers is difficult because of the disparate UGS GUIs, command and control structures, lack of the ability to redirect UGS behaviors after deployment, and the lack of ability to mix and match system components to optimize situational awareness capabilities.
  • Inability to achieve cross-service and coalition partner interoperability. Not only are there disparate systems within Services but the problem is exacerbated between Services and among coalition warfare partners.

In summary, UGS systems need to be interoperable, and require an UGS system architecture that allows the following:

  • Adjustment for varying mission needs
  • Plug-and-play sensor components from disparate vendors
  • Common, centralized UGS command and control capability
  • Standardized data/message formats and protocols
  • Common training procedures
  • Common GUIs
  • Importing files that define sensor capabilities, control, communication protocols, and payload formats

Interoperability among hardware components, Services, and coalition partners all need to be addressed. This requires a carefully considered approach to architecture development that does not stifle progress with unbounded expectations.

3 Authority

The Office of the Secretary of Defense (OSD), Deputy Under Secretary of Defense for Technical Collection & Analysis, issued a memorandum (see Appendix A), directing the establishment of an UGS SWG. Among the goals of this group are identifying standards and interfaces that will:

  • Promote interoperability of UGS among the Services
  • Promote cooperative UGS deployment across government agencies
  • Enable plug-and-play capability between UGS components and systems from disparate UGS vendors, allowing warfighters to use available ISR tools to provide the best situational awareness for a given mission.

4 Vision and Objectives

Most UGS systems are encumbered with proprietary designs and/or incompatibility of components and interfaces. Due to the lack of seamless interoperability of current UGS systems and components, DIA and other Services using UGS recognized the need to develop a common system architecture and a coordinated acquisition approach for Department of Defense (DoD) UGS.

The UGS SWG aims to make UGS components and systems interoperable so that acquisition is simpler and technology insertion is efficient. To that end, the UGS SWG comprises the entire UGS Community of Interest (COI), which includes the following stakeholder groups:

  • DoD acquisitions community
  • Requirements and user community, including COCOMS
  • The R&D community
  • Industry contractors and vendors

Working with industry is critical to the success of the SWG. The architecture and standards must be supportable by common business and production practices.

Primary working group objectives include:

  • Establishing a workable architecture, standards, and interfaces, with buy-in from the entire UGS COI
  • Maintaining an open architecture approach for plug-and-play UGS components for intelligence collection that
  • Provides flexible operational capability for behavior-modifiable sensor systems to support varying mission environments
  • Minimizes system integration and acquisition costs
  • Maximizes flexibility/adaptability for capability delivery and technology insertion
  • Characterizes potential/proposed architectural concepts/approaches through research & development, prototyping efforts, and validation activities
  • Identifying, developing, or modifying specific standards, interfaces, data formats and protocols that enable UGS interoperability
  • Providing guidance to UGS acquisition efforts to facilitate implementing an open architecture approach across the DoD
  • Gaining acceptance through outreach efforts
  • Maintaining interoperability with legacy UGS to whatever extent is practical
  • Establishing overarching guidance for UGS development (not performance requirements)
  • Establishing an UGS taxonomy that defines functional and operational terms for UGS architectures, components, interfaces, formats, and protocols
  • Establishing an UGS SWG web-based portal
  • Facilitating collaboration and knowledge sharing across the UGS COI

5 UGS SWG Concept of Operations

The approach to the UGS architecture development, validation, and maintenance is based on the following:

  • Defining open architecture guidance and identifying applicable standards through development, implementation, and analysis efforts
  • Developing a reference architecture specification and associated artifacts
  • Defining architectural compliance, developing supporting compliance test tools (as applicable), and developing associated guidance for applying compliance requirements
  • Establishing a collaborative configuration control process that supports maintaining and evolving the architecture

The UGS SWG will examine current UGS architectures and designs, as well as current development/acquisition approaches. The SWG will help develop a coordinated, open architecture approach, with plug-and-play components that will provide an increased level of compatibility, interoperability, and flexibility for the warfighter.

The working group will maintain an awareness and understanding of how this primary objective will affect, and be affected by, the operational, policy-making, security, training, processing, exploitation, and dissemination areas of UGS.

The UGS SWG leadership will define specific milestones and working group products necessary to achieve the objectives and goals. Technical Focus Groups will be established as necessary to focus resources, develop prototype/validation efforts, and conduct analyses.

5.1 UGS SWG Membership

The UGS SWG Deputy Chair determines membership and attendance, in cooperation with UGS COI stakeholders. New nominations for standing members of the main governing body will be adjudicated by the SWG Deputy Chair.

All participating organizations will provide input on their specific requirements, operational impacts, and concerns. The Deputy Chair will establish procedures to ensure that all stakeholders are represented and all issues and concerns are addressed and adjudicated. Standing members are from government organizations, but some meetings will be open to industry vendors.

The UGS SWG governance structure looks like this:

5.2 Roles and Responsibilities

5.2.1 Chairman

  • Oversees and directs the Main Governing Body (MGB) to establish binding UGS standards
  • Facilitates required cross-agency interactions

5.2.2 UGS SWG Deputy Chair

  • Coordinates all activities
  • Sponsors community groups, meetings, and document development
  • Facilitates specific Technical Focus Groups
  • Establishes Configuration Management Board
  • Serves as decision authority for the SWG; oversees process to enable government acceptance of newly introduced standards and their incorporation into existing and planned systems

5.2.3 Executive Steering and Planning Committee

  • Supports the Chair, Deputy Chair, and Main Governing Body administratively
  • Maintains an updated list of SWG members, participants, stakeholders, and POCs
  • Guides acquisition and user communities to facilitate and coordinate actions required to achieve UGS SWG goals and objectives
  • Publicizes deadlines for the submission of requests, discussion topics, briefings, and other agenda items for UGS SWG meetings
  • Makes meeting agendas and supporting material available to the UGS SWG members prior to meetings
  • Prepares and makes available read-aheads and results of all SWG meetings, including agenda, list of attendees, summary of discussions, conclusions reached, comments of members, and assigned action items
  • Generates correspondence as required; ensures that correspondence is transmitted to recipients and copies are made available to the SWG members
  • Plans, implements, maintains an UGS SWG portal that
  • Posts public-release guidance, documentation, standards, and best practices to those developing or using UGS
  • Hosts a restricted code repository under configuration control
  • Makes online community collaboration possible

5.2.5 Main Governing Body

The main body of the UGS SWG comprises senior leadership from all the participating government organizations, including users, requirements and technology organizations, and acquisitions organizations. Industry vendors may be invited to meetings as deemed appropriate. The body shall:

  • Have decision authority and oversee management of the SWG
  • Define and manage the number, topics, and activities of Technical Focus Groups
  • Sponsor community groups, meetings, and document development to support unified efforts
  • Oversee the process to enable government acceptance and incorporation of newly introduced standards
  • Maintain configuration management for SWG artifacts
  • Support development and maintenance of a USD(I) UGS portfolio to be used during the budget process
  • Provide oversight and collaborative direction to those developing or using UGS in order to avoid vendor-proprietary systems.
  • Collect Requests for Support and After Action Reports to be added to a standard DoD baseline UGS CONOPS and for future programs
  • Respond to USD(I) requested metrics on community MIP-funded efforts
  • Recommend centers of excellence to the USD(I) to remedy specific capability gaps
  • Guide the vendor community on acceptable interface upgrades and UGS component enhancements

5.2.6 Technical Focus Groups

The number and types of Technical Focus Groups (TFG) will vary depending on current requirements. The TFGs will comprise people from participating organizations and vendors who are technically familiar with the UGS technology for each specific TFG. Each TFG will select a lead. The responsibility of the TFGs is to analyze relevant problems sets and recommend actions for consideration by the Main Governing Body (MGB). The first three TFGs will be:

Architecture Development. This TFG will develop a flexible UGS system architecture that adjusts to mission needs; allows for plug-and-play sensor components; enables centralized command and control and common training procedures; and minimizes overall deployment time for UGS equipment (e.g., by requiring less training, equipment in the field, and development-to-deployment timelines). The TFG will provide interface standards identification and definition for current and future UGS systems

Wired/Wireless Interface Development. This TFG will assess required wired and wireless communications requirements for UGS systems and develop recommendations on communications solutions and associated protocols and standards.

Data Control Payload Formats. [check Mike Kolodny’s version to see if he wrote specs for this group]

5.2.7 Industry Participants

Working with industry is critical to the success of the SWG. The architecture and standards must be supportable by common business and production practices.

Industry roles thus include the following:

  • Provide industry perspective to working group activities and recommend ways to ensure usability/applicability of SWG products to industry development and implementation of UGS systems
  • Designate appropriate participants for inclusion into the UGS SWG
  • Nominate technologies and standards that should be instituted as UGS community standards
  • Seek technologies, standards, and programs that increase interoperability and mission effectiveness, utility, and other factors of importance to the DoD
  • Participate in Technical Focus Groups as appropriate
  • Participate in sub-working groups as appropriate to support concerns about interface standards definitions that may have broader implications (e.g., security, emplacement, policy, training, dissemination)

6 Ongoing Relationships

In order to achieve its objectives, the UGS SWG must maintain active relationships with the following communities:

6.1 DIA Initiatives

In early 2009, DIA began developing an open architecture UGS controller as part of a three-phase effort. During Phase 1, contractors competed and were selected for the opportunity to conduct technical market research, trade studies and initial design activities to specify a notional architecture for Phase 2. Fabricating a prototype based on the Phase 1 architecture was the focus of Phase 2. Phase 3 efforts focus on correcting the architectural deficiencies discovered during the Phase 2 prototype testing and validation effort. The end of Phase 3a, completed in October 2010, was marked by a demonstration of the production controller with an expanded set of sensors and communications components. Based on these results, DIA, in cooperation with the Army Research Laboratory (ARL) and industry participants, is currently formulating an UGS architecture framework to be used as a starting point for achieving the UGS SWG objectives.

6.2 US Community of Practice

[Insert Section—from where? Have pasted in what we have on USCOP conference in July, and have also drafted some words to go with them, in green]

As part of its outreach efforts, the UGS SWG will work within the larger UGS community of practice to broaden its own awareness and to focus awareness on ground sensors.

USCOP plans for its July conference

Vision: Broaden awareness and open dialogue among users and developers of unattended sensors

Mission: Provide a forum to identify, discuss, and facilitate resolutions to challenges and issues related to the acquisition, development, and employment of unattended sensors

Objectives:

  • Raise awareness of the roles and importance of unattended sensors in warfare, homeland defense and security.
  • Create a comprehensive catalog of unattended sensors from among DoD, IC and Law Enforcement organizations and continually populate an online data base to share the information.
  • Promote the integration of unattended sensor data into DoD, IC and Law Enforcement Intelligence architectures.
  • Create a lexicon for the acquisition and operational use of unattended sensors.
  • Share a lessons learned; Tactics, Techniques, and Procedures / Concept of Operations.
  • Provide a venue for the exchange of existing and emerging technologies as well as the presentation and publication of research papers.
  • Provide a clearing house for the posting of conference, working groups, papers, policies, standards and information of interest to unattended sensors community of practice (USCOP) members.

Appendix A: Under Secretary of Defense for Intelligence Memorandum


Appendix B: Terms of Reference

[next iteration will include more terms]

Reference Architecture: A high-level, conceptual model for a technology system that provides interoperability among diverse systems, component standards, specifications, products and their interrelationships; provides developers with design and implementation guidance

Reference Implementation: A working model derived from the architecture, with these attributes:

  • It is developed along with technical specifications and the test suite
  • It enables independent verification and validation of the test suite
  • It helps clarify the intent of the specifications in the event that conformance tests fail
  • It serves as the standard against which other implementations can be measured (Curran, P. Conformance Testing: An Industry Perspective. Sun Microsystems. Available: http://www.nist.gov/itl/vote/upload/6-Curran.pdf (2003).

Unattended Ground Sensors: For the purposes of this group, UGS include intelligence, surveillance, and reconnaissance (ISR) sensors that provide a high-resolution, low-latency look at what is happening on the ground. They may be stationary, on ground vehicles, on people, and on low-flying unmanned aircraft systems (UAS).