Volkswagen V-Charge Collaboration: Driverless Valet Parking

In research programs, the compute intensity of any specific module cannot be determined ahead of time and is subject to continuous change; the ability of one compute engine to manage its load cannot be determined until runtime. The infrastructure needs to provide clear feedback when communication deadlines are not being met by
connected modules. This requires the ability to rapidly and easily reallocate modules to networked nodes. In other words, modules should be able to be reorganized around the distributed architecture without the time and effort of reconfiguring the underlying network integration. This way, researchers can stay focused on application level issues rather than dealing with system architecture problems created by changes in systems integration.

more...
DOWNLOAD FULL CASE STUDY PDF

Please submit your business email to receive the full RTI case study in your inbox:

Download
  • VENDOR
  • CUSTOMER
  • Researchers at ETH Zurich and the universities of Braunschweig, Oxford and Parma recently embarked on a cooperative research program called V-Charge with industrial partners Bosch and Volkswagen AG. To work together effectively, they decided that every collaborator should be able to use the computers, operating systems and software they were most comfortable and experienced with. No one should be forced to change their tools, because that would impose unfair costs on some collaborators.
  • SOLUTION
  • DDS enables the decoupling of the applications from the underlying communication infrastructure. This means that any process or module can be moved around the network completely unchanged. DDS discovers the modules new location at boot time and routes communication as needed. No IP reconfiguration or network
    interface changes are required by the application.

    DDS includes a Quality of Service (QoS) capability that ensures that the data needs of each and every communicating process and module are being met. If they are not, the discrepancy between publisher and subscriber is noted and both applications are informed. No application module needs to know about any other – it just needs to know it requires specific data within certain timing and delivery constraints and to know when those constraints are not being met.
  • DATA COLLECTED
  • OPERATIONAL IMPACT
  • Impact #1
    Creates a focused team that can get more research development done in less time. Gives researchers freedom to change their minds or alter their systems configuration as interim research results indicate alternative or superior approaches.
  • QUANTITATIVE BENEFIT
  • SOFTWARE
  • INDUSTRIES
  • Automotive
  • FUNCTIONS
  • Product Development
  • ENABLED CAPABILITIES
  • Data Acquisition & Management
    Remote Access & Control
  • CONNECTIVITY PROTOCOLS
  • Ethernet
    Other frequency
  • RELATED CASE STUDIES
View Desktop Version
© 2019 IoT ONE