1 / 24

Reconfigurable Communication Interface Between FASTER and RTSim

Reconfigurable Communication Interface Between FASTER and RTSim. Dec0907. Team Makeup. Team Members: Matthew McCollum Mark Krause Derek Keibler Tyler Gustafson Faculty Advisor: Dr. Steward Client: John Deere (Mark Klocke). 2. Problem. RTSim system was not easily configurable

ichapman
Download Presentation

Reconfigurable Communication Interface Between FASTER and RTSim

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Reconfigurable Communication Interface Between FASTER and RTSim Dec0907

  2. Team Makeup Team Members: Matthew McCollum Mark Krause Derek Keibler Tyler Gustafson Faculty Advisor: Dr. Steward Client: John Deere (Mark Klocke) 2

  3. Problem • RTSim system was not easily configurable • Each simulation’s inputs & outputs had to be hard coded • Existing modules were interfaced directly to the virtual reality module, limiting modularity • Difficult to create/setup different simulations • RTSim was not easily extendable to additional modules 3

  4. Solution/Deliverables • Create a new reconfigurable interface • To control a variable number of inputs & outputs of modules and CAN bus • To handle a variable number of modules • A way to create/save/load different configurations (RTSim CoCoA) • Modify existing modules to comply with new reconfigurable interface solutions • Create documentation for future module development 4

  5. Requirements • Interface shall have reconfigurable communication protocol between current and future modules • Interface shall conform to CAN standards (SAE J1939 and ISO 11783) • RTSim CoCoA shall allow users to: • load/filter a CAN database • load resource files • create connections between resource and CAN inputs/outputs • create configurations for the Reconfigurable Interface • save/load settings for various interface configurations and CAN input/output connections • Interface shall be able to interpret/use the configuration files 5

  6. Operating Environment • Windows environment with JRE 6 and the .NET framework • CAN-USB connection between Reconfigurable Interface and a CAN bus • TCP/IP network between Reconfigurable Interface and modules 6

  7. Project Schedule • Familiarized ourselves with the original system • Created ‘prototype’ to show our understanding • Updated old interface to read a speed CAN message • Updated old simulation model to use speed • Created operation process • Created “Resource” and “Config” file format • Created RTSim CoCoA • Attempted to update old interface • Created new interface • Tested entire system 7

  8. System Block Diagram 8

  9. Process Example Dev. A (VR Lab) VR Simulation Setup VR Resource File Model B VR Dynamic Simulation Module Dev. B (Dynamic Analyst) DSM Resource File 9

  10. Process Example Continued CAN Database User (e.g. PV&V) CAN Log VR Resource File Model B VR CoCoA DSM Resource File 10

  11. Process Example Continued User (e.g. PV&V) CoCoA Interface Config. File 11

  12. CoCoA User Interface 12

  13. Reconfigurable Interface Class Diagram 13

  14. I/O Specifications • Input configuration file is in XML • Socket connections: • have an unique port • send/receive byte arrays of a predefined size • output data on a specified interval • CAN messages: • sent on a 20ms interval • Received continually 14

  15. Test Plan • CoCoA will mainly be tested through Scenario Testing • Load/Filter a CAN database (view CAN messages in window) • Load a Resource file (view resource and packet info in window) • Make connections (view the connections in window) • Create a config file (look through output .xml file) • Modules will be tested with a simple server program • Confirm server accepts connection from the modules (view screen output) • Confirm server sends a set packet correctly (view screen output) • Confirm server data received from the module (view module output) • Confirm module sends a set packet correctly (view screen output) 15

  16. Test Plan Continued • Interface will be tested with simple modules • Configuration reading will be tested using various config files • Simple modules will have expected inputs • Simple modules will print out sent/received data • Compare expected with sent/received data • Complete system will be tested by combining the interface and all modules in order to run a VR simulation • View the VR monitor • Drive the tractor 16

  17. Implementation • CoCoA: • Java (Eclipse) • Swing controls for GUI creation • XML reading/writing • Some design patterns used: • Adapter/Wrapper • Observer • Iterator • Modules: • Dynamic Simulation Model - C (MatLAB) • Changed from server to client architecture • Integrated conversion logic of old interface • Steering Wheel Module - C++ (Visual Studio) • Integrated steering logic from old interface • Added client architecture 17

  18. Implementation Continued • Interface: • C# (Visual Studio) • Server component • Each module has its own ‘server’ thread • Configuration (XML) Reader • Uses LINQ (Language Integrated Query) • CAN component • Sends CAN messages onto the CAN bus • Receives and filters CAN messages from the CAN bus • Some design patterns used: • Adapter/Wrapper • Observer • Iterator • Scheduler 18

  19. Obstacles • Learning curve for CAN usage • Building on top of an existing project • Incompatible compiler versions • Bit manipulation in a high level environment 19

  20. Lessons Learned • Project scope can be difficult to define with few requirements • Vague project scope can lead to feature creep and create planning risks • Starting from scratch can be better than reusing existing projects • Broadened knowledge of different programming languages • Professional relationship with an industrial client 20

  21. Test Results • CoCoA testing: • Went through several iterations as Resource and Config file formats evolved • Config files were created correctly for given configuration setups • Module testing: • Performed client operations as expected • Interface testing: • Performed server type operations as expected • System testing: • A tractor was simulated and steerable • More extensive system testing is not possible with the resources available to us 21

  22. Future Work • What we have left: • Meet with John Deere to demonstrate • Deliver project to John Deere • Executables • Source code • Manual • Example/existing modules (if desired) • Possibility for future projects: • Resource file creator/viewer • Unit conversion for connections 22

  23. Summary • The RTSim CoCoA allows quick and simple creation of simulation configurations • Increased modularity of the Reconfigurable Interface design allows for easy addition modules • John Deere will now be able to easily create and run various simulations 23

  24. Questions 24

More Related