Common vehicle interfaces provide standardized interfaces that enable interoperability with vehicle systems and between vehicle systems and external devices. Here are some of the use cases that are enabled by having common vehicle interfaces:

• Use case 1. Telematics Integration: common vehicles interfaces enable vehicle data collection.
  • Note: This is partially enabled by VSS which provide the data model. VISS complements that by providing APIs but its scope seems skewed towards web access (MQTT, HTTP, web sockets)
• Use case 2. On Android, Common Vehicle Interfaces can be used as a default implementation for Android VHAL and Car Properties
• Use case 3. On Android and non-Android systems, Vehicle Interfaces can be provided as an SDK for integration by Application developers. This can provide a richer access and control over vehicle capabilities compared to the standard VHAL properties, and can be used on non-Android systems (QNX, Linux, .. etc).
• Use case 4. AUTOSAR can provide ARXML description that conforms to the common vehicle interfaces, and Tier1 suppliers can provide a solution that is ready out of box for integration with multiple OEMs as long as everyone conforms to these standardized vehicle interfaces.

Profile/Identity

Use cases from a services/interfaces perspective for individual profiles, identity management. Intent is to provide initial and continued input on identity needs to influence a data model. The Data Expert Group will determine where the work takes place. It will likely be a separate model than VSS but with relationships between them needing to be defined and may be worth including in that call.

• Use case 1. Identity should be supported in multiple platforms including but not limited to AOSP. Some services that would be extended to individuals might not necessarily have all interactions go through AOSP on head unit but some may. A profile will need to be linked to an AOSP user account. 
• Use case 2. The individual or entity may have different roles with respect to one or more vehicles at a given time and subject to change. Roles include: owner (individual or company for eg shared mobility), manager (if a third party helps manage vehicle), operator (driver), passenger, recipient of digital key issues (may be passenger or actual operator), being key roles.
• Use case 3. Profile needs an associated identity comprised of legal name, nickname or shareable identifier that masks name for privacy considerations, various other characteristics of the entity, preferences for HVAC, seat position, digital service subscriptions, identity provider for authentication, digital wallet for various automotive payment use cases (request input from that group in COVESA).