Date post: | 02-Jan-2016 |
Category: |
Documents |
Upload: | laurence-alexander |
View: | 220 times |
Download: | 2 times |
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
President, InnUVative Systems
Prepared for: UVS Canada, Nov 2008
2
Outline
• Background
• Goals of Development Effort
• Implementation Process
• Difficulties & Successes Encountered
• Results
• Path Forward
3
Company Background• Canadian registered engineering and 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
Pilot Development Effort
• Best way to ensure that we had all the tools and practices necessary to support development was to embark on a pilot development effort
• Goals for pilot development:1. Identify and verify tools and practices needed for good
development;
2. Establish a re-usable code base that allows faster and lower risk development for customers;
3. Develop a significant capability that would be genuinely useful in real world applications.
5
First Goal: Development Process• In support of the first goal, the development process was
defined to include:– Requirements definition and analysis within a graphical
requirements environment using a SysML toolset (Enterprise Architect);
– High level and detailed software design continued within same tool set, allowing traceability through both the design and test development as well as on to test results (Enterprise Architect);
– OOD and reusable design practices followed to enhance software reliability and maintainability;
– Configuration management enforced from the start (SVN); – Test failures and bugs managed through an integrated problem
tracking tool (Mantis Bug Tracker); and– Clear tracking of effort (Time Slips).
6
Second Goal: Reusable Code Base• In support of the second goal, the following code
development approach was defined:– Use of gcc compiler to allow multi-platform support,
especially Windows and Linux;– Use of Virtual Machines for distribution of the
development environment to ensure good configuration control;
– Use of wxwidgets as a GUI building tool to support multi-platform as well as GUI extensibility;
– Use of industry recognized Object Oriented Design Patterns to abstract and encapsulate the code elements for reusability.
7
Third Goal: Significant Capability
• In support of the third goal, we decided to target VSM development:– Given STANAG 4586 prevalence within the UV
industry, development of a VSM seemed a logical capability to target
– For a VSM, we need a second protocol…• We could either generate a “manufactured” protocol
• Or we could use a publicly available protocol
– For the latter, the JAUS protocol was the natural fit as it would demonstrate a capability useful to all elements of the UV industry
8
Implementation: Requirements• The first stage of implementation was the requirements
analysis. This was done graphically within the Enterprise Architect (EA) environment
• While this drew heavily from the two ICDs, it allowed the developers to work separately from the ICD documents themselves – Explanations of various capabilities documented in a manner
better suited to their needs
• One of the primary goals of the requirements analysis was an evaluation of the feasibility of this effort.– Several papers have been written advocating the position that
JAUS and STANAG-4586 are inherently different so interoperability is not achievable…
9
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 designed with the goal of allowing intra-system “plug n
play” hardware as its goal 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…
10
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:
11
Implementation: Requirements
• The first stage of implementation was the definition of each protocol within the code
• Each message had embedded within it the requirements for each field of that message and each field requirement could be expanded to show the details of that field
• During this stage, it was identified that we would implement 100% support of STANAG but only a subset of JAUS- enough to control a datalink, vehicle and camera for proof of concept
12
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)- this accounted for most of the unsupported system messages
13
Implementation: Requirements• The second stage of implementation was the mapping of protocol parameters• 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
14
Implementation: Requirements
• One of the most difficult elements was the definition of the STANAG 4586 connection logic. This is described textually within the document but when trying to actually implement the description some ambiguity was found. With help from STANAG authorities, this was defined more precisely and documented as a sequence diagram with an accompanying Use Case for the developers to implement against
• State machines were also used to document important logic such LOI functionality
15
Implementation: Design
• Remaining within EA- 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
16
Implementation: Code Development
• The code development was conducted through distribution of Windows and Linux Virtual Machines (VMs) that ensured that all developers were using the exact same, configuration controlled development environment
• SVN was used for configuration control of all files through out development
17
Implementation: Code Development• The use of the gcc compiler allowed both Windows and Linux to be supported in parallel
• The use of wxwidgets also allowed concurrent Windows and Linux support
18
Implementation: Code Development
• As part of the code development we also needed to develop test tools against which unit and system level testing could be conducted
• These were developed independently from and in parallel to the VSM development in order to ensure that both ends of the interface were not developed by the same person or using the same code
• The opportunity to have the InnUVative Systems VSM used within a real system was pursued but did not come to fruition due to some additional complications identified within that target system at the end of our development
19
Implementation: Test Tool Development
• In support of this need for a STANAG test tool at one end of the VSM and JAUS test tool at the other end, requirements and design were also developed for these tools within EA
• These requirements and design were developed against the long term goal of full support for both STANAG-4586 and JAUS but implemented to support only the immediate needs for the current development
20
Implementation: Test Tool Development• A test tool was designed and constructed for
each of JAUS and STANAG-4586• These tools allowed comprehensive testing of
the protocols at each end of the VSM
21
Implementation: Test Development
• Utilizing the same SysML based tool (EA) as had been used for Requirements Analysis, the system level tests were also developed independently of and in parallel to the VSM
22
Implementation: Test Execution
• Test Case
• Test Step• Link to Design Element (“use”)
• Links to Requirements
• Test Result
23
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
24
Results
• With respect to the original goals, this development effort was a success:1. Our development tools and practices were validated
as sound;
2. At the completion of development, we had a complete code base for the STANAG-4586 message set, a significant code base for the JAUS protocol, a variety of base classes for widgets and two capable tools to allow independent testing;
3. The completion of a JAUS VSM holds the potential for interoperability between the two primary protocols within the UV industry.
25
Results
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 will make the next VSM development much faster and lower risk
26
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 STANAG half of this VSM for development of VSMs
for other protocols to enable other vehicle systems to become STANAG-4586 compliant
• 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
27
Questions?