Neptune 3 UI uses QtIvi, its autogenerator tools, QtIviVehicleFunctions, and QtIviMedia to implement Middleware APIs in an automotive UI context. There are two such APIs that Neptune 3 UI implements and utilizes: RemoteSettings and DriveData.

Neptune 3 UI connects to their corresponding remote services: remotesettings-server and the drivedata-simulation-server. In this case, a remote service refers to an independent process, possibly running on a different host. For an introduction to QtIvi's middleware services, see Qt IVI Inter-Process Communication Integration.

Why use Middleware

The apps running within Neptune 3 UI and the System UI share common settings, such as language and night/day mode. The remotesettings-server maintains this interface.

The drivedata-simulation-server provides an interface to the instrument cluster's gauge and telltale values, as well as a simulator. Having these backends as separate networked processes, makes it possible to access common information and functionality in a uniform manner from all of the frontend points: be it built-in apps, the System UI, or a separate application.

These separate networked processes also make it possible to run the instrument cluster and the center console display on separate hosts, while still having smooth and synchronous changes to the language, theme, or UI modes.

Both of these APIs are further utilized by the Neptune 3 UI Companion App, that lets the passenger change settings and view vehicle data on a mobile device.

Start the Middleware Services

By default, Neptune 3 UI starts the middleware services automatically. You can also run the remotesettings-server or drivedata-simulation-server executables respectively, if necessary. The executables are built and installed along with Neptune 3 UI. The servers require a server.conf file, which is a shared settings file to set up the connection. This settings file is shipped with Neptune 3 UI and is located in the root directory. The same settings file is also read by the backend plugin instances loaded by built-in apps.

Implementation

The middleware architecture is based on QtIVI and its ivigenerator tool. Neptune 3 UI's built-in apps, the companion app, and System UI all connect to the remote services through auto-generated components. Communication between the middleware services and frontends is achieved with QtRemoteObjects. This is done transparently; you can replace this communication with other messaging mechanisms, without changing the APIs.

QtIvi-based middleware is described in .qface files; for each file, the QtIVI autogenerator generates these distinct components: frontend, backend plugin, and a separate service executable.

In the case of the drivedata-simulation-server, the server also contains generated simulation code. These generated components are divided into separate projects.

Let's take the settings-service as an example. The server itself and all the necessary components are located in src/remotesettings, where we find the following files or projects:

• app
• backend
• backend_simulation
• frontend
• qml_plugin
• remotesettings_server
• other files/remotesettings.qface

As discussed above, the remotesettings.qface file is the interface description that the ivigenerator takes as input. The frontend is a shared library containing a C++ implementation of our middleware and the interface to implement a backend for it. Whether the middleware service is remote or not, is hidden from the code that uses the frontend (opaque). For example, all methods in the frontend's interface are asynchronous. For convenience, the frontend is further wrapped into a qml_plugin, so that we can use the functionality straight from the QML code.

To connect to the actual middleware service, the frontend loads one of the backend plugins, produced by the backend and backend_simulation projects. The plugin compiled by the backend project is the one that connects to the remote service, implemented in the remotesettings_server project and is considered a production backend.

The remotesettings_server project produces the actual server executable and contains some generated code as well as the manually written business logic for the service.

The backend_simulation project produces an alternative backend plugin that provides a generated simulator.

The app project contains the implementation of the Neptune 3 UI Companion App.

Because of the opaque frontend and the interchangeable backend plugins, the service could also be implemented in an entirely different manner. For example, if Neptune 3 UI is run in single-process mode, the remotesettings-server wouldn't have to be remote, but could run in-process instead.

To modify the simulation values and default data in Neptune 3 UI, you can update the simulation.qml and the drive-data.yaml files. These files are located in the drivedata folder. When you have made the changes you would like, you need to rebuild Neptune 3 UI for these changes to take effect.

Related Information

• See Qt IVI Inter-Process Communication Integration and Generate QtRemoteObjects based backends with the Qt IVI Generator for a more detailed explanation and a walkthrough on generating middleware services.
• See Qt IVI Simulation System for more info about simulations.
• See Develop a Parking App