1 Land, Sea and Air : The Application of JAUS and STANAG 4586 for Cross-Domain Unmanned Vehicle Control Mike Meakin, B. Sc., PMP President, InnUVative.

Slides:



Advertisements
Similar presentations
Testing Relational Database
Advertisements

ATML Readiness For Use Phase II. Phase II Readiness For Use The ATML: Phase II will build on the Core phases, adding additional ATML components and features.
Human Views for MODAF Dr Anne Bruseberg Systems Engineering & Assessment Ltd, UK on behalf of the Human Factors Integration Defence Technology Centre.
User Driven Modelling and Systematic Interaction for End-User Programming Modelling for Engineering Processes Peter Hale UWE.
Mike Meakin, B. Sc., PMP President, InnUVative Systems
JOINT ARCHITECTURE FOR UNMANNED SYSTEMS January 29, 2011 Presented by Daniel Barber University of Central Florida Institute for Simulation and Training.
Panel 5: The Latest in OA Innovation and C4ISR 4 November, 2014 Mike Rice President / Senior Systems Engineer R2E Inc.
Building an Operational Enterprise Architecture and Service Oriented Architecture Best Practices Presented by: Ajay Budhraja Copyright 2006 Ajay Budhraja,
Force XXI Battle Command Brigade and Below (FBCB2) Communications System
1 The NIAG - “Supporting Alliance Capability Development and Enhancing Interoperability” AFCEA Europe – June 2010 “Interoperability Revisited” “NATO Industrial.
Systems Engineering in a System of Systems Context
Enterprise Architecture. 2 Agenda What is Enterprise Architecture (EA)? Roles in EA? Why is EA Important? Tangible Benefits from EA? What Do We Need to.
OASIS Reference Model for Service Oriented Architecture 1.0
© Lethbridge/Laganière 2001 Chapter 7: Focusing on Users and Their Tasks1 7.1 User Centred Design (UCD) Software development should focus on the needs.
1 Computer Systems & Architecture Lesson 1 1. The Architecture Business Cycle.
Software Issues Derived from Dr. Fawcett’s Slides Phil Pratt-Szeliga Fall 2009.
University of Jyväskylä – Department of Mathematical Information Technology Computer Science Teacher Education ICNEE 2004 Topic Case Driven Approach for.
Enterprise Architecture
The Re-engineering and Reuse of Software
An Intelligent Tutoring System (ITS) for Future Combat Systems (FCS) Robotic Vehicle Command I/ITSEC 2003 Presented by:Randy Jensen
4586 For The Rest of Us: Mike Meakin
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 18 Slide 1 Software Reuse 2.
a Service Oriented Architecture
The Pursuit for Efficient S/C Design The Stanford Small Sat Challenge: –Learn system engineering processes –Design, build, test, and fly a CubeSat project.
JWST Integrated Modeling Environment James Webb Space Telescope.
Software Engineering Muhammad Fahad Khan
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 18 Slide 1 Software Reuse.
Information Integration in Construction. Construction information In construction, architects, engineers, planners, contractors, facility managers....
Chapter 6 System Engineering - Computer-based system - System engineering process - “Business process” engineering - Product engineering (Source: Pressman,
University of Palestine software engineering department Testing of Software Systems Fundamentals of testing instructor: Tasneem Darwish.
JAUS Architecture Overview. Why did we need JAUS? “Stove-Pipe” Design Subsystems common to all Unmanned Systems (US) were previously built from scratch.
Assessing the Suitability of UML for Modeling Software Architectures Nenad Medvidovic Computer Science Department University of Southern California Los.
Ranga Rodrigo. The purpose of software engineering is to find ways of building quality software.
Building Tools by Model Transformations in Eclipse Oskars Vilitis, Audris Kalnins, Edgars Celms, Elina Kalnina, Agris Sostaks, Janis Barzdins Institute.
OOI CI LCA REVIEW August 2010 Ocean Observatories Initiative OOI Cyberinfrastructure Architecture Overview Michael Meisinger Life Cycle Architecture Review.
1 Land, Sea and Air : Development of a STANAG-4586 Compliant VSM for the Joint Architecture for Unmanned Systems (JAUS) Protocol Mike Meakin, B. Sc., PMP.
 Architecture and Description Of Module Architecture and Description Of Module  KNOWLEDGE BASE KNOWLEDGE BASE  PRODUCTION RULES PRODUCTION RULES 
University of Southern California Center for Systems and Software Engineering Model-Based Software Engineering Supannika Koolmanojwong Spring 2013.
Component Technology. Challenges Facing the Software Industry Today’s applications are large & complex – time consuming to develop, difficult and costly.
IPSec IPSec provides the capability to secure communications across a LAN, across private and public wide area networks (WANs) and across the Internet.
Web Services Based on SOA: Concepts, Technology, Design by Thomas Erl MIS 181.9: Service Oriented Architecture 2 nd Semester,
© 2012 xtUML.org Bill Chown – Mentor Graphics Model Driven Engineering.
Abstract We present two Model Driven Engineering (MDE) tools, namely the Eclipse Modeling Framework (EMF) and Umple. We identify the structure and characteristic.
11 Soldier Systems Briefing 10 March This presentation is subject to the conditions of the proprietary notice on slide 2 Proprietary Notice This.
COBXXXX EXPERIMENTAL FRAMEWORK FOR EVALUATION OF GUIDANCE AND CONTROL ALGORITHMS FOR UAVS Sérgio Ronaldo Barros dos Santos,
XML The “E-Lance Economy” or “Digital Economy” is a new challenge for interacting over networks. XML was developed by the World Wide Web Consortium (W3C)
WS-I Submission W3C XML Schema User Experiences Workshop June 2005 Redwood Shores, CA, USA Erik Johnson, Epicor Software.
8:15 AM Tuesday September 15, 2009 Karl Frank, Point of Contact for Constellation Projects Validating Integration Requirements Diagrams for illustrative.
March 2004 At A Glance NASA’s GSFC GMSEC architecture provides a scalable, extensible ground and flight system approach for future missions. Benefits Simplifies.
Project Deliverables CEN Engineering of Software 2.
Design and Implementation of a Rationale-Based Analysis Tool (RAT) Diploma thesis from Timo Wolf Design and Realization of a Tool for Linking Source Code.
11 STANAG 4586 Working Group Jan 2010 Mike Meakin.
The mandate of this working group is to facilitate effective service interoperability utilizing SIP in heterogeneous network environments as noted below.
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
SOFTWARE ENGINEERING. Objectives Have a basic understanding of the origins of Software development, in particular the problems faced in the Software Crisis.
Lecture 13.  Failure mode: when team understands requirements but is unable to meet them.  To ensure that you are building the right system Continually.
Software Quality Assurance SOFTWARE DEFECT. Defect Repair Defect Repair is a process of repairing the defective part or replacing it, as needed. For example,
PROPRIETARY —Do not distribute Presented to: Date: OPTIMIZING DATA LINK PERFORMANCE FOR UNMANNED SYSTEM PAYLOADS C4 Robot Platforms & Sensors Exposition.
UNCLASSIFIED 1 United States Joint Forces Command Joint Warfighting Center United States Joint Forces Command Joint Warfighting Center LTC John Janiszewski.
Introduction to Software Engineering 1. Software Engineering Failures – Complexity – Change 2. What is Software Engineering? – Using engineering approaches.
Systems Engineering Concept Model (SECM) Status 03/17/2016 John Watson.
LECTURE 5 Nangwonvuma M/ Byansi D. Components, interfaces and integration Infrastructure, Middleware and Platforms Techniques – Data warehouses, extending.
CHESS Methodology and Tool Federico Ciccozzi MBEES Meeting Sälen, January 2011 January 2011.
Software Design Process. What is software? mid-1970s executable binary code ‘source code’ and the resulting binary code 1990s development of the Internet.
What is Wrong with Models?
Design and realization of Payload Operation and Application system of China’s Space Station Wang HongFei 首页.
Deploying CIM to Bridge the Modeling Gap Between Operations and Planning Mike usa.siemens.com/digitalgrid unrestricted © Siemens AG 2017.
BPMN - Business Process Modeling Notations
Analysis models and design models
AN INEXPENSIVE ROBOTIC KIT FOR CHILDREN EDUCATION
Presentation transcript:

1 Land, Sea and Air : The Application of JAUS and STANAG 4586 for Cross-Domain Unmanned Vehicle Control Mike Meakin, B. Sc., PMP President, InnUVative Systems Prepared for: SAE AS-4 JAUS Working Group, April 2010

2 Outline Background Description of STANAG 4586 system JAUS VSM Implementation Process Difficulties & Successes Encountered Results Path Forward/ Future Harmonization Approaches Conclusion

3 Who am I? 8 years as a Naval Combat Systems Engineering Officer 6 years as Project Lead on the US Army Tactical Unmanned Air Vehicle (TUAV) Shadow 200 control station software –From initial stages of competing in and winning the US Army fly-off, –To fielding this system to Iraq (now over 450,000 combat flying hours) –Also during this period led the development of : The US Army Remote Viewing Terminal (also fielded in Iraq); Integrated the Tactical Common Data Link (TCDL); Extended the Shadow 200 control station software to control a Shadow 400 maritime UAV system; and Led the integration of the US Army Hunter UAV into the existing TUAV control station. Have served on board of directors of Canadian UV organization since 2006 Mike Meakin- Background

4 Company Background Software development company founded in January 2007 by three individuals with more than 19 years experience in the UAV software development industry Specifically targeted at the unmanned vehicles industry –Specializing in UV software development Using well recognized engineering practices within an established and controlled development environment –Follow fundamental project management principles as recognized by the Project Management Institute

5 Description of 4586 System Elements The 4CE Control Station© software is our flag ship product –Command, Control, Communication, Coordination & Execution –It is compliant with STANAG 4586 Interoperability standard The Vehicle Specific Module (VSM) is really a System Specific Module as it applies to sensors, datalinks and other systems as well –STANAG 4586 is a complex standard and is still undergoing changes so specialist knowledge is necessary –Likewise JAUS for ground vehicles CCISM is less specialized but will be added as well VSM CORE UCS CCISM HCI OPERATOR(S) DLI CCI AV C4I SYSTEM Payload

6 JAUS VSM Implementation: Requirements The SysML approach allowed the two ICDs to be placed into the same format for increased ease in mapping of ICD elements, despite the fact that the two ICDs were constructed in totally different manners:

7 Reviewing the two ICDs side-by-side certainly highlights the differences between the two: –JAUS assumed commands such as iris and gain settings and location wrt CofG for a camera that STANAG does not include as part of its basic message set –JAUS assumes information such as the platform boundaries, platform geometry, turn radius, static rollover limit, etc. would be important –STANAG assumes barometric pressure is important information to be exchanged Each protocol clearly reflected it’s heritage… The JAUS protocol was well-suited to supporting intra-system “plug n play” hardware and utilizes protocol extensibility via use of “experimental” messages to achieve this STANAG protocol is designed with inter-system interoperability as its explicit goal and uses abstraction via the use of standard graphical interfaces to achieve this The conclusion was that JAUS is truly a well thought out architecture with a protocol that is extensible while STANAG is a truly well thought out protocol with little to no aspirations as an architecture… JAUS VSM Implementation: Requirements

8 The original intent was to make this exercise as challenging to a VSM implementation as possible: –Identified specific datalink, vehicle and manipulator messages to support Opportunity arose with a vehicle manufacturer who was interested in using our VSM for a sea vehicle demo –Modified version of STANAG from 2.1 to 2.4 and JAUS from 3-2 to 3-3 –Also changed manipulator messages for camera messages Set of JAUS messages supported (uplink and downlink): –10 of 23 system messages; –4 of 8 datalink messages (start/ stop, hi/ low power, point, etc. supported); –10 of 41 vehicle messages (steering, attitude, engine and waypoint supported); –6 of 18 camera messages (pointing, zoom, focus, etc. supported) –Zero manipulator messages No support for service connections (just queried periodically)- this accounted for most of the unsupported system messages

9 JAUS VSM Implementation: Design The mappings themselves were able to be made explicitly within the tool, showing which fields mapped to which and explicitly defining any conversions required for the developer Remaining within the SysML and UML compliant tool used for requirements analysis, the high level and detailed design could be documented, such as the VSM GUI with mappings The use of the gcc compiler and wx widgets allowed both Windows and Linux to be supported in parallel

10 JAUS VSM Implementation: Test Tool Devt As part of the code development we also needed to develop test tools against which unit and system level testing could be conducted A test tool was designed and constructed for each of JAUS and STANAG These were developed independently from and in parallel to the VSM development These tools allowed comprehensive testing of the protocols at each end of the VSM

11 JAUS VSM Implementation: Test Execution Test Case Test Step Link to Design Element (“use”) Links to Requirements Test Result Still utilizing the SysML based tool that had been used for Requirements Analysis, the system level tests were also developed independently of and in parallel to the VSM, providing full traceability

12 Difficulties & Successes Encountered Change to STANAG 4586 version and modification to target messages for JAUS –The lack of backwards compatibility- even from STANAG 2.1 to 2.4- made this kind of switch non-trivial –Use of the SysML approach to requirements shielded the developers from these issues Ambiguity in ICDs –Vehicle_ID_Update: “This is the vehicle ID that will be replace the current Vehicle ID”  this was corrected but is an example of the issues found when actually implementing an ICD for real STANAG Connection Logic –Need sequence diagram and use cases to explain –Intent of virtual vehicles may not be needed in real life… SVN proved very capable of rolling back code when needed Support for Presence Vector within JAUS was not clearly understood by developers in first implementation

13 Results of JAUS VSM Implementation As a measure of the VSM capability itself, we had: A total of 321 tests were developed and executed for the VSM, with only12 failures (only minor functionality) for a 96.3% pass rate The EA tool allowed explicit checks of traceability to ensure that all requirements have both a “Realization” link and a “Test” link The level of effort expended for this development effort was approximately one person year –This yielded not only a functional JAUS VSM but also two test tools and a re- usable code base that makes the futureVSM development much faster and lower risk

14 Path Forward There are several paths forward that are being pursued: Integration of this VSM into a STANAG CUCS for basic control of JAUS-compliant datalinks, vehicles and payloads; Extension and use of either or both of these test tools for testing purposes on other systems; Extension of this VSM to the full JAUS message set, including Service Connections and Manipulators; Utilization of the JAUS half of this VSM for development of translation modules to enable other vehicle systems to become JAUS compliant Potentially, develop the “reverse VSM” that allows control of STANAG vehicles from a JAUS control station… …all moving towards harmonization of JAUS and STANAG 4586…

15 The Future of Interoperability Based on our experience of developing this System Specific Module for JAUS, InnUVative Systems has developed an approach to interoperability between the two standards that allows a high degree of supported functionality between units, even in the absence of specific training on a given vehicle or system...

UAV Interoperability Combined UAV Combat Operations Giving the soldier an organic air capability is important Allowing that organic air capability to leverage off wide area surveillance platforms allows him to put what he sees into context with the wider battle… It’s useful for the soldier to know: There is a fire fight two blocks North A bridge is out three blocks East Etc. Mixed assets: C7 mortars and artillery Likewise: micro/ small tactical and MALE UAVs Need mixed assets for different tasks

17 Interoperability with STANAG 4586 STANAG 4586 Compliant control station with Vehicle Specific Module Level of Interoperability 5 (FULL) STANAG 4586 Core Msg Vehicle Specific STANAG 4586 Core Msg Vehicle Specific Module STANAG 4586 Compliant control station with no Vehicle Specific Module Level of Interoperability 3/4 (~80% mission capability after launch)

18 Interoperability It is important to note that the common protocol solution is only one part of the interoperability problem 1.Need common waveform solution (STANAG 7085 TCDL, STANAG 4660 Common C2 link, etc.) 2.For given control station, features supported by common protocol are presented as the same user interface across all systems Allows operators untrained on specific systems to safely take control knowing system will behave as expected Greatly reduces delta training as new UV systems are added

19 Cross Domain Interoperability Combined UGV/ UAV Combat Operations Giving the soldier the ability to see what threats are around the corner has been extremely important The next step is to relieve the soldier of having to be first around the corner to address the threat Some systems have already anticipated the push to arm UGVs Integration of armed UGVs- via JAUS or native protocol- into STANAG 4586 allows the combined operations goal identified in the UAS Roadmap from OSD

20 STANAG 4586/ JAUS Interoperability STANAG 4586 Compliant control station with JAUS VSM Level of Interoperability 3/4 (~80% of mission??) STANAG 4586 Core Msg Vehicle Specific JAUS Core Msg JAUS Experimental Msg Vehicle Specific Module Support for JAUS Core message set allows operation of most of a mission even by operators unfamiliar with the system JAUS VSM Use of domain agnostic control and status interfaces is key to allowing operator control of different systems

21 STANAG 4586/ JAUS Interoperability STANAG 4586 Compliant control station with JAUS VSM + Veh specific tranlsation Level of Interoperability 5 (FULL) STANAG 4586 Core Msg Vehicle Specific JAUS Core Msg JAUS Experimental Msg Vehicle Specific Module An additional plug-in translates the JAUS Exp Msg set to 4586 and VSM GUI JAUS VSM Veh Spec Module

22 Harmonization of 4586 & JAUS Not surprisingly, there is a large overlap between the two core message sets already Coordination between the two standards authorities could further increase this overlap, thus improving interoperability between systems, even in the absence of vehicle-specific support JAUS Message Set 4586 Message Set

23 Conclusions Interoperability between STANAG 4586 and JAUS is possible to a significant degree right now Greater interoperability is inevitable in the future The two standards do not have to be treated as competitive but can instead be complementary Coordination between the two standards bodies could define a largely common core message set that supports the “~80% mission” via the core message sets only –This then supports many of the inter-unit and international interoperability goals Use of a common control station supporting domain- agnostic control interfaces will allow interoperation with low risk and very low training overhead

24 Questions?

25 Join us in November at the Unmanned Systems Canada conference in Montreal