1. 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. 2 Outline Background Goals of Development Effort Implementation Process Difficulties & Successes Encountered Results Path Forward

3. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 22 Implementation: Test Execution Test Case Test Step Link to Design Element (“use”) Links to Requirements Test Result

23. 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. 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. 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. 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. 27 Questions?