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
1
Outline
•
•
•
•
•
•
Background
Description of STANAG 4586 system
JAUS VSM Implementation Process
Difficulties & Successes Encountered
Results
Path Forward/ Future Harmonization
Approaches
• Conclusion
2
Who am I?
Mike Meakin- Background
• 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
3
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
4
Description of 4586 System Elements
• The 4CE Control Station© software is
our flag ship product
Payload
– Command, Control, Communication,
Coordination & Execution
– It is compliant with STANAG 4586
Interoperability standard
AV
VSM
CORE
UCS
CCI
CCISM
C4I
SYSTEM
HCI
DLI
• The Vehicle Specific Module (VSM)
is really a System Specific Module as
OPERATOR(S)
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
5
added as well
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:
6
JAUS VSM Implementation: Requirements
• 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
7
protocol with little to no aspirations as an architecture…
JAUS VSM Implementation: Requirements
• 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)8
this accounted for most of the unsupported system messages
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
9
Linux to be supported in parallel
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 STANAG4586
• 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
10
JAUS VSM Implementation: Test Execution
• 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
• Test Result
• Link to Design
Element (“use”)
• Test Step
• Test Case
• Links to Requirements
11
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.4made 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 12
understood by developers in first implementation
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 reusable code base that makes the futureVSM development much faster and
lower risk
13
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…
14
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...
15
4586 UAV Interoperability
Combined UAV Combat Operations
It’s useful for the soldier to know:
• There is a fire fight two blocks North
• A bridge is out three blocks East
• Etc.
•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…
Mixed assets:
•C7
•mortars and
•artillery
Likewise:
•micro/ small
•tactical and
•MALE UAVs
Need mixed assets
for different tasks
16
Interoperability with STANAG 4586
STANAG
4586
Core Msg
Vehicle
Specific
STANAG
4586
Core Msg
Vehicle
Specific
Vehicle
Specific
Module
STANAG 4586 Compliant
control station with no
Vehicle Specific Module
• Level of Interoperability
3/4 (~80% mission
capability after launch)
STANAG 4586 Compliant control
station with Vehicle Specific Module
• Level of Interoperability 5 (FULL)
17
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
18
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
19
STANAG 4586/ JAUS Interoperability
Use of domain agnostic control
and status interfaces is key to
allowing operator control of
different systems
STANAG
4586
Core Msg
JAUS
Core
Msg
Vehicle
Specific
JAUS
Experimental
Msg
Support for JAUS Core
message set allows
operation of most of a
mission even by operators
unfamiliar with the system
Vehicle
Specific
Module
JAUS
VSM
STANAG 4586 Compliant control
station with JAUS VSM
• Level of Interoperability 3/4 (~80%
20
of mission??)
STANAG 4586/ JAUS Interoperability
STANAG
4586
Core Msg
JAUS
Core
Msg
Vehicle
Specific
JAUS
Experimental
Msg
Vehicle
Specific
Module
JAUS
VSM
An additional plug-in
translates the JAUS Exp
Msg set to 4586 and VSM
GUI
Veh Spec
Module
STANAG 4586 Compliant control
station with JAUS VSM + Veh
specific tranlsation
21
• Level of Interoperability 5 (FULL)
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
22
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 domainagnostic control interfaces will allow interoperation
23
with low risk and very low training overhead
Questions?
24
Join us in November at the Unmanned
Systems Canada conference in Montreal
25