A view under the hood#

Component Definition#

../_images/component_definition.png

The V-API system uses the following characteristics:#

  • Components are compiled software modules in binary form

  • Components are linked dynamically during runtime

  • Components communicate using interfaces

  • Components can be used to build a dynamic framework

  • The functionality of a system is determined by the composition of components

  • Components are closed source and therefore can be written by 3rd parties

  • Components are language independent

  • Components are very close to a C++ class – performance is very high

  • Components can be used using direct calls within the same process

  • Components can be called in other processes using Remote Procedure Calls (RPC)

../_images/marshaling.png

Components implemented easily with C++:#

  • Interfaces are complex structures with only pure virtual functions

  • Function pointers are managed through the V-table

  • Components are classes deriving from interfaces

Binary components supported by OS:#

  • Most modern OSes support dynamic libraries (DLL or SO)

  • Library uses dynamic (late) binding (instead of static binding by the linker)

  • Type safety and error mitigation is responsibility of programmer (tooling)

../_images/dynamic_linking.png

Interface IDL#

Component interface language: OMG IDL (ISO/IEC 19516)#

  • OMG IDL is part of the CORBA specification

  • OMG IDL is used in DDS specification

  • OMG IDL can be used as stand-alone language without CORBA

  • OMG IDL is around since 1991 and still updated

  • OMG IDL 4.2 was standardized in 2018 and the latest contribution dates February 2021

  • OMG IDL license allows the implementation of software based on the (partial) specification

  • OMG IDL language is very close to the C++ language specification, therefore easy to learn

../_images/idl_file.png

The IDL compiler generates code for:

  • Header file to be used by caller and callee

  • Proxy implementation for marshalling and communication

  • Stub implementations for calling component functions and marshalling

Safety and Security#

There are several safety and security considerations:

  • Each interface receives a unique ID - allows access to the interface

  • No interface change of same ID, regardless of platform

  • Interface change of new ID, no mixing of old and new interfaces

  • Serialization/deserialization protected with CRC32C

  • Automatically detection of platform endianness + converting if necessary

  • Free spec interpretation of data types are fixed within V-API for all platforms (e.g. wchar, wstring, native and any).

  • Only specified exceptions are marshalled. No exception surprises. Other exceptions are caught and reported.

During the development of the VAPI Framework several safety and security considerations were considered:

  • Isolate complex services and applications (fault impact reduction)

  • Profile based feature accessibility

  • Prepared for the use of security roles

  • Connection stealing prevented with runtime-based connection identification

../_images/runtime.png

Inter-Process Communication (IPC)#

This chapter describes the internal IPC mechanisms used by the Open Vehicle API runtime to enable communication between components running in different processes, as well as integration with external applications.

The IPC layer is based on socket transports and exposes a unified interface model to user code, independent of operating system or transport type.

For the detailed transport and usage guide, see IPC Channels (UDS/WinSock) and Tunnel Transport in the advanced/reference section.