Re: Aftermarket considerations

Hello, Ted, and thanks for an insightful post.

(Disclaimer - Nothing in this post pertains to JLR)

All indications I have point to OEMs moving toward a service architecture with a number of well-defined APIs for IVI, body control, battery management, etc.
Logical (VSS) signals will play a role here for status updates, command confirmations, etc.

Encrypted on-board networks are already happening in telematics and other IP-based systems, and I am sure that this will spread as OEMs move to protect systems against various Internet-based attack vectors.

This need for control and security, however, is in direct conflict with the quickly emerging transportation as a service market, where external fleet systems need deep vehicle integration to figure out if doors are shut, if the vehicle is being stolen, abused, etc. Onboard devices, such as aftermarket teleamtics units, remote diagnostics, etc, also need deep vehicle access to do their job.

For me the only visible route forward is a standardized, external API with authentication, authorization, service discovery, service invocation, and signal distribution, allowing a TaaS company to integrate with a mixed-manufacturer fleet at reasonable cost.  This standard API will receive, authenticate, authorize, and route incoming commands to the correct proprietary ECU (or service) in the vehicle, and report back the result.

At some point, governmental agencies will likely also step in and start mandating certain APIs, much like they did for OBD2, in order to facilitate ADAS <-> infrastructure integration, charging, right to repair, etc.

Again signals will play a significant role here, but the real meat is in the service definitions and, to some extent, the RPC implementation (SOME/IP, Nanomsg, etc, etc).

I am sure that there are ongoing industry efforts here, and my recommendation would be that we try to collaborate with these to create a solid standard for external vehicle integration.

/Magnus F.
mfeuer1@jaguarlandrover.com


From: Ted Guild <ted@w3.org>
Sent: Monday, June 3, 2019 12:39:08 PM
To: public-automotive
Subject: Aftermarket considerations

I would like us to give some more and explicit thought to aftermarket
considerations for Gen2 and underlying VSS. Before raising an issue
figured we can talk about it more, we did touch on it at the F2F but
should go further.

VSS is extensible so there is already some consideration but we are not
doing much to address pushing additional signals up to the Gen2 service
in the vehicle for any custom control units or sensors added to the
vehicle.

Not a straight forward topic as on one hand there is the question about
whether an OEM would even want to support this. They may rather a car's
control units stay the same. CAN et al should be replaced at some point
with signed messages if not an encrypted network instead of open
broadcast which would make it more difficult to allow for aftermarket
devices. Along those lines I could see why from a security perspective
why an OEM would be hesitant to support aftermarket in vehicle networks
or expose to applications in a Gen2 service.

On the other hand in North America at least there is 'right to repair'
laws that allow people to modify their vehicles. W3C has a strong
accessibility activity, the Web Accessibility Initiative. We had some
join us in the past as they are excited about the advances in
transportation. Having been in accessibility equipped vehicles on
several occasions, they are generally highly customized - aftermarket.
Besides any pertinent legislation like possibly the Americans
Disability Act (ADA), we should also consider the trend to usage based
models instead of individual ownership. Vehicles will have different
capabilities for different demographics and those will in many cases be
aftermarket customization.

https://www.w3.org/WAI/

There are also simpler aftermarket use cases such as tire replacement.
Tire pressure monitoring systems (tpms) was a simple start but tire
manufacturers are now working on additional sensors, in many cases
tuned to be brand specific being able to do various things such as read
vibrations. The raw data could be analyzed in-vehicle via Gen2 and used
to determine if for instance a tire is imbalanced, out of alignment (if
not used instruct the car to auto-tune), wearing unevenly and due for
rotation or reaching its wear marker. Those cheap little tpms are
likely to be replaced and paired with tires as they are installed.

VSS extensibility including at leaf level that we heard about will help
but we need to think about it in Gen2 as well. This could be related to
service discovery.

Gen2 is meant to support other things besides vehicle signals such as
notifications and media. For media there will obviously be changes to
media services and libraries over time.

--
Ted Guild <ted@w3.org>
W3C Automotive Lead
http://www.w3.org