Volkswagen V-Charge Collaboration: Driverless Valet Parking
Technology Category
- Application Infrastructure & Middleware - Data Exchange & Integration
The Customer
V-Charge
About The 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 co
The Challenge
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.
The 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.
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.
Operational Impact
Case Study missing?
Start adding your own!
Register with your work email and create a new case study profile for your business.
