UMS Status Brief 6 29 06 Rev

Category: Education

Presentation Description

No description available.


Presentation Transcript

Safety of Unmanned Systems: Joint Government/Industry  Unmanned Systems Safety Workshop Sponsored by DSOC ATP TF Status Update: 

Safety of Unmanned Systems: Joint Government/Industry  Unmanned Systems Safety Workshop Sponsored by DSOC ATP TF Status Update 29 June 2006


Agenda Background Scope Task Objective Approach Schedule Progress Products Summary


Background Unmanned systems provide new capabilities to meet needs/mission requirements Numerous unmanned systems (UMS) are under development in each of the Military Services and other government agencies But, unmanned systems have unique challenges, e.g. Integrated operations System control and security Target identification/verification No unified system safety approach Unintended casualties could drastically impact design, development and use


Chronology for Safety of Unmanned Systems (UMS) Timeline International Systems Safety Conference August 05 Technical Brief/Panel Aug 05


Chronology for Safety of Unmanned Systems (UMS) Timeline Mar 06 Sep 05 Aug 05 OSD established a series of Meetings at Pentagon: Unmanned Systems Forums Oct 05


Unmanned Systems Challenges Industrial Base Treaty Legal Training Reliability Interoper - ability Payloads Weapons Inter - Agency Spectrum Data Sharing Scope: Slide from Mr. M. Schaeffer’s brief of 28 March 06 at Unmanned Systems Safety Workshop, Huntsville, AL Safety Battlespace Architect ure

UMS Safety Objectives: 

UMS Safety Objectives Focus the technical community on the System Safety needs for UMS Specifically Understand the safety concerns, including legal issues, associated with the rapid development and use of a diverse family of unmanned systems both within, and external to, the DoD. Establish and agree upon a standardized set of safety precepts to address the safety concerns associated with the design, operation, and programmatic oversight of all unmanned systems.   Develop safety guidance, such as design features, hazard controls and mitigators, for the design, development, and acquisition of unmanned systems.  


Approach Involve technical community Six Teams Approximately 60 technical experts Government, Industry, Academia Maximize Community Awareness March Workshop 300 attendees International Systems Safety Conference (ISSC) AUVSI NDIA Systems Engineering Conference Obtain Feedback Web Page ( Tech Panels ISSC (31 July - 4 Aug 2006) AUVSI (29 – 31 Aug 2006) NDIA Systems Engineering (23 – 26 Oct 2006)

March Workshop Accomplishments: 

March Workshop Accomplishments Generated DRAFT OSD-wide UMS Safety Guidance Established process to refine OSD-wide UM Systems Safety guidance Developed POA&M for issuance of OSD Systems Safety guidance Enhanced communications at all levels Service PMs Service technical and safety communities Service safety boards Between Services and industry reps Established web page (


POA&M for DSOC ATP TF Unmanned Systems Safety Initiative


Progress Held Three Workshops March 2006, Huntsville May 2006, Crystal City June 2006, Crystal City Developed Draft Safety Precepts Programmatic safety precepts Operational safety precepts Design safety precepts Developing design safety “best practices” Weapons control Situational Awareness


Progam Safety Precept (PSP) = Program Management Principles & Guidance that will help insure safety is adequately addressed throughout the lifecycle process. Operational Safety Precept (OSP) = Operational Guidelines that should be adhered to during system operation. They guide system design for operation use and provide the basis for design safety precept and more detail system safety design requirements. Design Safety Precepts (DSP) = General Design Guidance intended to facilitate safety of the system and minimize hazards. Safety design precepts are intended to influence, but not dictate, specific design solutions. UMS Safety Precept Definitions

Workshop Organization: 

Workshop Organization Six Workgroups 1. Precepts 2. Weapons Control 3. Situational Awareness Human-Machine Interface Machine-Machine Interface 4. Command and Control 5. States and Modes 6. Definitions/Common Taxonomy


Safety Precepts for UMS Provide program managers with appropriate safety guidelines and best practices, while maintaining PM’s design flexibility

Safety Design Guidelines: 

Safety Design Guidelines Manned Systems Safety Design “Best Practices” MILSTDS STANAGS Handbooks Unmanned Systems Safety Design “Best Practices” Unmanned Manned Common To Both

Discussion of Products: 

Discussion of Products Workgroup Moderators Precepts: Mr. Josh McNeil (Army) Process for developing precepts Discussion of selected precepts, as examples, including rationale for the precept Weapons Control: Mr. Bill Pottratz (Army) Situational Awareness: Dr. Tom English (Navy) C2: Mr. Steve Mattern (Apogen Technologies) States and Modes: Mr. Bob Schmedake (Boeing) Definitions: Mr. Danny Brunson (EG&G Inc)

Precepts Work Group 1 Status: 

Precepts Work Group 1 Status Josh McNeil Army/SED

Weapons Control Work Group 2 Status: 

Weapons Control Work Group 2 Status Bill Pottratz AMCOM Safety

Group 2: Weapon Control: 

Group 2: Weapon Control Participants Air Force Preston Parker Mark Handrop John Deep Army Chris Janow Mike Zecca Dave Magidson Chris Olson Navy Jack Waller Mary Ellen Caro John Filo Industry Bill Blake

Group 2: Weapon Control: 

Group 2: Weapon Control Purpose Develop safety guidelines, that can be endorsed by various boards, for certification of unmanned system platforms and weapon interfaces Issues Addressed Precepts Safety Certification Design Guidelines


Assumptions Workgroup recognizes the sufficiency of existing STANAG and MIL-STD’s for weapon systems. Functional contribution of other UMS subsystems to weapon safety system constitutes a distributed safety system. These contributing UMS subcomponents may be safety critical and must be designed, developed and maintained appropriately. Top level guidelines apply to all types of weapons – missiles, bombs, guns, directed energy devices, non-lethal systems

Precept 22: 

Precept 22 The UMS platform shall be designed to incorporate a minimum of 2 independent safety features, each of which will prevent subsequent commanded (or uncommanded) launch/release/firing/arm enable of the weapon. The removal of each safety feature shall require a unique verified message generated as a consequence of a distinct authorized entity action (e.g. messages shall not originate within the UMS platform). The messages shall be sent in the proper sequence and acted upon only after being recognized as being in the proper sequence.

Associated Guidelines: 

Associated Guidelines • UMS subsystems shall not subvert or compromise the independence of weapon safety features. • Each weapon/platform shall have unique identifier and shall respond only to commands with its identifier in the command. • The UMS platform shall be designed to monitor and validate content and sequence of messages, and the response of the system to the messages, and take appropriate safing and notification actions.

Precept 29: 

Precept 29 The unmanned systems shall provide safety design features to ensure safe recovery of all unmanned system equipment to include the platform and equipment. Issue: Definition of UMS drives the scope of requirements. Proposal: We recommend that scope be limited to systems that are designed to be returned or recoverable

Associated Guidelines: 

Associated Guidelines • All commands that initiate hazardous activities shall be self-terminating, and upon termination the UMS shall return to a known safe state. • UMS shall provide weapon safety status to the authorized entity The UMS platform shall be capable of being returned to the original safe state or an equivalent level of safety.

Situational Awareness Work Group 3 Status: 

Situational Awareness Work Group 3 Status Dr. Tom English NSWC Panama City

WG 3 Technical Products: 

WG 3 Technical Products Revised DSP-4 Developed supporting design safety guidance Created proposed UGV safety design guidance document Obtained proposed UUV safety design guidance document


Remote control Fully autonomous Human Human-equivalent Autonomous control levels Awareness Challenge - Addressing the Spectrum Tele-operations Semi-autonomous


Current DSP-4: The unmanned system shall be designed to provide control and situational awareness adequate to support safe operations. Revised DSP-4: The unmanned system shall be designed to provide information, intelligence, and method of control (I2C) to support safe operations.

WG 3 Issues Products: 

WG 3 Issues Products Situational awareness and precepts Spectrum of autonomy linked to situational awareness A framework for standardizing UMS human performance A framework for UMS situational awareness


Issue: No standard framework to analyze UMS unique human performance factors Human-robot interaction ratio Ability to interact with multiple vehicle/types of systems Number of missions that can be supervised/monitored Various environmental stimuli Related Precepts: OSP-2: The unmanned system shall not execute any operation without commensurate situational awareness. DSP-2: The unmanned system shall be designed to only respond to fulfill valid commands from the authorized entity(s) DSP-6: The unmanned system shall be designed to prevent release/firing of weapons into unmanned system structure or other weapons. DSP-19: The unmanned system shall provide safety design measures to identify the weapon being released/fired Issue: Machine Situational Awareness has never been characterized Formal characterization of machine situational awareness Establishment of Machine SA evaluation criteria Establishment of Machine SA evaluation techniques Characterization of Machine SA effect on System Safety Related Precepts: DSP-4: The unmanned system shall provide control and situational awareness feedback adequate to support safe operations. DSP-15: The unmanned system shall be designed to minimize exposure of personnel, ordnance, and equipment to hazards generated/created by the unmanned system equipment. DSP-10: The unmanned system shall safely change states and modes.


1 – Human Control 5 – Allocated Control 10 –Machine Control Human Control Machine Control Spectrum of Autonomy Linked to SA Denotes individual safety-critical actions for which adequate SA must be defined. i.e. arm the machine gun, steer to avoid obstructions, discriminate target, … Position shows whether machine or human must have this SA. Human SA requires Performance Measurement Criteria to evaluate. Machine SA requires an original characterization since it is not currently defined. 6 – Allocated Control 9 – Allocated Control 7 – Allocated Control 8 – Allocated Control 4 – Allocated Control 3 – Allocated Control 2 – Allocated Control

A Framework for Standardizing UMS Human Performance: 

A Framework for Standardizing UMS Human Performance Framework Human Performance (HP) Study Establishment of Evaluation Criteria Evaluation of System with Regard to HP Where we are today Human Performance Measurement Tools to measure: a. Human-robot interaction ratio b. Ability to interact with multiple vehicle/types of systems c. Number of missions that can be supervised/monitored d. Measuring SA – Validated and repeatable measurement tools e. Various environmental stimuli Establish HRI Ratio White Paper Finished Products

A Framework for UMS SA: 

A Framework for UMS SA Develop a Framework UMS SA Performance Study Establishment of Evaluation Criteria Evaluation of System with Regard to UMS SA Today, SA measurement criteria are insufficient for evaluating human & UMS interactions Validated and repeatable tools to evaluate: a. UMS SA across UMS systems types b. UMS SA across various levels of automation c. UMS SA effect on human interaction d. UMS SA effect on system safety White Paper Finished Products Characterize UMS Machine SA




Definitions: Information: Knowledge or data necessary for the safe operation of a UMS; obtained from the process of recognizing and interpreting data in the environment, memory and recall of facts, and/or communication. Intelligence: The capacity of a UMS to acquire, comprehend, and apply information. Method of control: The means or manner in which an operator interacts, influences, or directs an unmanned system; a function of three non-exclusive system attributes: Mode of control Level of authority Level of control


Definitions (cont): Mode of control: The means by which a UMS receives instructions governing its actions and feeds back information. Remote control Teleoperation Semi-autonomous Fully autonomous


Definitions (cont): Level of authority: The degree to which an entity is invested with the power to access the control and functions of a UMS. Level I – Reception and transmission of secondary imagery or data Level II - Reception of imagery or data directly from the UMS Level III - Control of the UMS payload Level IV - Full control of the UMS excluding deployment and recovery Level V – Full control of the UMS including deployment and recovery


Definitions (cont): Level of control: Locus at which a controlling entity interacts, influences, or directs a UMS(s). Actuator Primitive Subsystem Vehicle Group of vehicles System of systems

Method of Control: 

Method of Control Remote control Tele-operation Semi-autonomous Fully autonomous Actuator Primitive Vehicle Subsystem Group System of systems Level of Control (LOC) Mode of Control II IV III I Level of Authority (LOA) V

Command and Control Work Group 5 Status: 

Command and Control Work Group 5 Status Steve Mattern Apogen Technologies

WG Membership: 

WG Membership Work Group Members Steve Mattern (Apogen Technologies) Moderator Billy Arnold (General Dynamics) Ed Spratt (Navy) John Canning (Navy) Michael Dunn (Army) Eugene Gonzales (Navy) Martha Meek (Army) Helmut Portmann (Navy) Ron Price (Army) Mike Zemore (Navy) Rachael Fabyanic (Navy) Frank Albert (Navy) Steve Castelin (Navy)


COMMAND AND CONTROL WORK GROUP #5 Focused on the Command and Control Issues Involved with Unmanned System The Command and Control Issues Tended to be Functionally Linked With Other Work Groups…So the Issues Became Nearly All Inclusive (e.g., Weapons, Modes & States, Situational Awareness, etc.) Three Work Group Sessions…with Reviews/Discussions Between Sessions Started with Safety “Issues”…and, Worked Toward Program or Design Safety Guidance Precepts Mapped to Safety Issues Concluded with “Rationale” to Support Program and Design Safety Guidance


COMMAND AND CONTROL WORKING GROUP PSP’s DSP’s OSP’s PROVIDED PRECEPTS Program Precepts Design Precepts Operational Precepts Issue Identification Issue Categorization Targeting On-Board Weapons Personnel Safety Operator Battlefield Environment System System Safety Program C2 GROUP ACTIVITY Session #1 Feedback Loops Develop Guidance Mid-Session Activity Refine Safety Guidance Refine Safety Precepts for C2 Refine Safety Issues for C2 Supporting Rationale C2 GROUP ACTIVITY Session #2 Input to C2 From Other Groups C2 GROUP ACTIVITY Session #3 Out-Side Input And Documents Historical Artifacts Historical Artifacts

Definitions/Common Taxonomy Work Group 7 Status: 

Definitions/Common Taxonomy Work Group 7 Status Danny Brunson EG&G (540) 775-7870

WG Membership: 

WG Membership Work Group Members Danny Brunson (EG&G), Moderator Scottie Allred (MARCORSYSCOM) Mary Ellen Caro (NOSSA) Brad Cobb (NSWCDD) Bill Christian (SED/L3) Clif Ericson (EG&G) Randy Mann (SED/L3) Steve Mattern (Apogen Technologies)


Progress Identified Pertinent References Compiled Relevant Definitions Identified Needed Definitions Reviewed Definitions Prioritized List Cat 1 - 4 Selected most appropriate definitions Prepared Draft Definitions

Pertinent References: 

Pertinent References MIL-STD-882C MIL-STD-882D Joint Publication 1-02, DoD Definitions ( ANSI/RIA R 15.06-1999 STANAG 4586, Standard Interfaces of UAV Control System (UCS) for NATO UAV Interoperability INCOSE Systems Engineering Handbook JSSSH, Joint Software System Safety Handbook Joint Robotic Program Master Plan FY2005 Army Regulation 385-16, System Safety Engineering and Management FAA System Safety Handbook USAF System Safety Handbook, 2000 SAE ARP 4761, Aerospace Recommended Practice, Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment SAE ARP 4754, Aerospace Recommended Practice, Certification Considerations for Highly-Integrated or Complex Aircraft Systems MIL-HDB-764 AAP-6 (V) modified version 2, NATO Terms and Definitions MIL-STD-1316E, Fuzes MIL-STD-1910A MIL-STD-1901A IEEE 1228 EIA SEB-6A DOE M 4401 NASA-GB-8719.13 AOP 38 DAU Glossary 11th Edition Defense Acquisition Guidebook MILSTD 2105 MILSTD 464 MILSTD 882E (draft) NIST Special Publication 1011




Plans Ground Rules If there is an official definition for a term from a recognized source we will use that definition without modification. If multiple recognized sources have different definitions we will select the most appropriate. If there is not an official definition from a recognized source we will propose a definition for adjudication. If an official definition is not satisfactory we will provide an additional alternate definition for adjudication.


Plans Complete Workgroup Review Establish baseline definitions Category 1 and 2 Provide recommended baseline for ISSC Begin process of resolving differences with other organizations after ISSC


Summary Held three workshops Government/industry/academia teams developed draft safety precepts, rationale & design guidance All Services and numerous program reps participating Preparing for ISSC panel discussion on 2 August 2006, Albuquerque Next events: AUVSI (29 – 31 Aug 2006) NDIA Systems Engineering (23 – 26 Oct 2006) Will continue to refine precepts and safety design guidance after each event in preparation for publication

authorStream Live Help