Antitrust statement

Meeting Minutes

2026-04-07

Whitepaper review, will share draft at AMM, encourage input from participants and their colleagues including whether anyone can sign on. Will work with COVESA marketing to publish post AMM

Incident reports

Graph schemas started for generic and theft, do not have good viewer/editor to provide better tour/overview - Ted needs to get IT Security approval to install

Encouraging thinking on additional types of incidents besides unsafe driving, theft and accident. AV scoring in general, near accident and override. Evasive manuever. Breakdown (locked out, flat tire, overheat, engine failure, etc).

**We have not anything scoring location (city vs rural), time, road and traffic conditions etc - some in our Sensoris based work. GPS + timestamp can answer some offline/backend system lookup. Privacy considerations (clear consent) - AOSP could be the HMI for consent (reporting immutable or collect, can introduce Richard to AiDEN)

Ted needs to get Paul to put Sensoris topic on TST agenda - agreed but keeps being deferred

Will want to generate some mock incident data and use GraphQL server in COVESA Playground - Ted to talk to Stephen

2026-03-31

From VDM call: Provide information of the stating point: - List are the Entities of interest for the domain (e.g., CrashEvent) - List the properties assotiatied to that entities (e.g., CrashEvent.location) - List of competency questions: what do I want to be able to answer directly from my data? - Existing references: Are there standard vocabularies, taxonomies, data models?

Start with a generic incident event, apply to AV as well (eg remote takeover, human override)

Need to come up with concise crash reporting guidelines

• Input from VDM on sampling conventions

• Connected Safety data points of interest

• Subset from our insurance spreadsheet

  • different categories, ways to rate severity (accelerometer, speed, rate of deceleration, number of passengers and airbags deployed)

    • OEM algorithm (some have stopped due to poor results) and raw data points - both approaches

  • specific elements per incident type

• Generic and not AV specific for now - follow up

• Accident report Stefan provided previously

Data Guidelines for theft reporting

2026-03-24

• AOSP session at AMM, looking for guidance on insurance use cases - Stefan asked who from this call will be present and can attend. We should strengthen our collaboration with them, not just in person at AMM but more delegates to their recurring call

• VDM - services/APIs and access to data

  • another opportunity for insurance use case as well as potential for additional data modeling

• FMS call prep for tomorrow - VISS, give heads up on JasPAR work

• Continue review of whitepaper, proposed changes made and awaiting further input (stats and IPR concerns) requested of participants.

  • Next steps

    • announce draft at AMM and ahead of time more widely to COVESA members, ask OEM for input on section 5

    • request signatures from orgs

    • review with COVESA marketing team and publish

    • promote including sending to German Insurance Alliance and elsewhere UNECE

Pending is use of “standards”, posed it to generative AI:

❯ COVESA is not a formal standards body, it produces specifications and reluctant to define what it produces as standards. similar the world wide web consortium
(W3C) has the same hesitation and refers what it produces as technical reports and recommendations. we are debating whether to stick with "standards" for this
paper or perhaps use some other term. we want something stronger than specification or simply normalization of data. what do you recommend?

● Good question — this is a real tension in the standards-adjacent world. Here are a few options worth considering, in order of what I'd recommend:

1. "Open specifications" — This is probably the safest upgrade. It signals that the work is open, community-developed, and normative in intent without claiming
   formal standards body authority. OASIS and similar organizations use this comfortably.

2. "Normative specifications" — "Normative" is a term of art that means "establishing a norm" without claiming to be a standard. It carries real weight in
   regulatory and technical circles and signals that these are meant to be followed, not just informational. The GTR itself uses "normative" for its binding annexes.

3. "Consensus specifications" — Emphasizes that these emerged from multi-stakeholder agreement (OEMs, insurers, fleet operators), which is what gives them
   authority. This is the language IETF sometimes uses for its work.

4. "De facto standards" — This is arguably what VSS is becoming given Android Automotive VHAL adoption, but it's a claim that might be premature and could irritate
   people in formal standards bodies.

My recommendation would be "open specifications" as the primary term, with the paper occasionally using "common data definitions" or "open data vocabulary" where it
reads more naturally. "Open specifications" threads the needle — it's stronger than just "specifications" because "open" implies broad consensus and accessibility,
but it doesn't overreach into "standards" territory that would make COVESA or W3C uncomfortable.

The paper could also frame it as: COVESA produces open specifications that support regulatory standards and enable interoperability — positioning the work as
essential infrastructure without claiming the formal designation.

2026-03-17

• Insurance AV data whitepaper

  • remove MOTER, VHAL? (and/or VISS)

  • intent to follow UNECE and other regulatory bodies

  • change turtle to limp or more PC

  • check EN_UK

  • add: need for harmonized data and continuous, remote access to assess AV performance/risk

  • Need for simpler accident report, ability to assess liability/blame

  • Reconsider “standard” - check thesaurus

  • On-board API argument

  • Check all acros are defined but link to resources/explanations

    • ODD? Operational Designed Domain - vehicle cannot operate in snow

  • Remove company names but allow/encourage “signing” if companies allow

    • make clear Commercial and Fleet Vehicle Expert Group paper

    • importance of researchers

  • Stats like 95% of accident caused by human error - stats in general will strengthen argument

2026-03-10

• Reports to publish

  • AV / Insurance

  • Data sampling importance to support use cases/different industry vertical needs

  • Specification view of guidelines (fleet, insurance, other - road safety, accident/incident report, vehicle theft, etc)

• AMM CV track (revised)

  • CV & CVIS update (20)

  • Demo on ACEA FMS (10-15, talk to Mike about “COVESA Hub” table at the showcase)

  • FMS based panel (45-50)

  • Working session and participant engagement (fallback if leftover time)

2026-03-03

AMM - agenda public, 1 1/2h on Wednesday afternoon starting at 2:05 to 3:30 for CV

• CV update - revised based on current work and maybe delve into a sub topic (AV signal access?) (Ted &?)

• FMS at 2:35 - 3 (Armin, Abdel, Ted, Mouham, Achim)

  • Bosch demo? (how long and who)

• Joint working session (open to discussion

  • Enum, API and data sampling metadata

  • Other?

German insurance association - intro and outreach

AV draft report on need for regulations mandating signal access

2026-02-24

Introductions

Endava Fleet proposal

Ulf’s Cloud Based Tree Idea for insurance domain

Insurance signals for AV - largely completed review from spreadsheet, leverage AI to draft a whitepaper for circulation and potential input to UNECE

2026-02-10 / 17 - Insurance signals for AV

2026-02-03

Autonomous driving data points (fundamental, not ADAS)

Blackbox (rolling 10 second window under law for conventional vehicles, may be more required for AV - even 6 months?), needs to be operational for AV to be enabled. It would be preferred to be able to collect this data on a continuous basis, not just after an accident.

Access of data:

• Current regulations prohibit remote data access.

  • EU Data Act

  • EU AI Act? potentially unrelated, liability portion scraped for now

  • Insurance coverage - reluctance to insure AV without data access

• Data can be used to exonnerate or assign [partial or full] liability. Also considered IP

  • https://techcrunch.com/2026/01/21/lemonade-launches-an-insurance-product-for-tesla-full-self-driving-customers/

  • Tesla offers self insurance as well

• Consent clearly required in many regions

• Specific data

  • Include vehicle’s perspective of surroundings (eg Sensoris, camera, sensor and on-board AI based object detection ) eg lane detection, obstacles, other vehicles and tragectories

  • data driven AV decisions - why did the vehicle brake, swerve etc? OEM unlikely to share

    • Proprietary, protected IP. Algorithm that makes decision will not be shared, specific data points that contribute to decision will also be reluctant

    • collect, evaluate on-board and send off for feedback loop, learning

  • Generalized set of signals to provide portrait of surroundings (Ted to ask Sensoris if they know uptake across industry, regardless of supplier - other than HERE) and vehicle behavior - not necessarily what vehicle AI used

    • started in spreadsheet, please contribute there

    • example: car overtaking (passing) another vehicle and clearly decides not to, brakes

    • miles driven, evasion manuevers made, safety critical incident (emergency braking), minimum risk manuevers, enters safe mode

https://unece.org/sites/default/files/2023-12/R157e.pdf

https://unece.org/sites/default/files/2025-06/GRVA-22-23e.pdf

Predictive Maintenance Guidelines

2026-01-27

Introductions

• Fleet based routing using RFMS

updates: Karmak, CA DMV, pinged Chaitanya (Ford) on sampling conventions - will time out and go with ours otherwise

Predictive Maintenance Guidelines: sensor data eg voltage or oil temp to collect to make available to vehicle owner (individual, fleet) or their mechanic. Interested orgs (Karmak, Cox, Geotab)

Other candidates interested in predictive maintenance - obvious interest to insurance as is inspection

Outreach: Samsara (Paul intro), Allison (Priyaa - interest in diagnostics)

Diagnostic Trouble Codes (DTC): (no longer available in VSS since deprecating OBDII branch) and PIDs

• Not harmonized at present across OEM, meaning behind a light on dash or OEM specific diagnostics code are not necessarily consistent

  • OEM consider diagnostics codes, tools, logic their IP (license)

  • OEM specific knowledge for their data points useful for properly assessing (some have reverse engineered - understand based on historic data indicators of problems before they occur)

• Aging, adverse conditions or driving behavior contributing (coaching and/or reduce warranty coverage if not corrected) to component failure

•  

2026-01-20

2026 plans

• Draft blog article

• ACEA FMS collaboration

• More coordination with Connected Safety, VDM?, AOSP App Framework (insurance use cases)

• Package up data guidelines (fleet, insurance) and supportive, promoting materials

  • Explainer

  • Light wrapper on YAML based guidelines, produce specification

  • Seeking collection metadata from Ford

  • Outline of additional data collection guidelines

    • ADAS insurance guidelines and autonomous

      • Topic to TST - how far to go with Sensoris (more external/environmental variables) ADAS data points (paused in the meantime)

    • Vehicle theft reporting - have basics but not written in VSS YAML with collection convention metadata. Meed to engage various companies like LoJack (Ted can get intros) for short term engagement on guideline definition.

    • Basic accident report (airbags deployed, rollover, seatbelt, # of passengers, severity rating, etc) - in collaboration with Connected Safety BoF, leveraging their emergency services report format and see if there is an insurance industry equivalent

      • example accident report in EU

      • Unlikely to get full accident reconstruction data - the “blackbox” in many makes/models usually only accessible by law enforcement or under subpoena. Could define in CV group basic report - guidelines of data to collect and keep in buffer, send if possible to insurance backend

    • Inspection (w/ CA DMV) cf TÜV in Germany, Dekra - annual or bi-annual inspection follow government specified requirements, varies by country in EU, same in US. We would seek to establish a baseline that can be extended for regional differences.

      • May be some gaps - notably tire tread (Michelin)

    • Static information (vehicle registration, proof of insurance - Link to FNOL portal and agreed VSS backed reporting. current example statement)

    • Current driver

• Outreach (conferences, associations, etc)

  • Geotab Connect event - panel on standards and research (February)

  • ATA TMC - speaking slot to present ACEA FMS work, Commerical Vehicle activity and COVESA more broadly (March)

  • COVESA AMM in Porto, Portugal - call for participation, send presentation proposals (April 22, 23)

  • Insurance focused? Insurtech Insights Europe | Europe's Largest Insurtech Conference

• Engage new members with commercial vehicle focus

  • Cox, Cummins, Karmak (dealer management systems, diagnostics), Samsara, Volvo Group (CVIS, and ACEA FMS, trying to get into VDM) same with Scania, Sonatus?, Allison transmissions

    • Diagnostic Codes at TST - ASAM SOVD (passenger car), UDS, we deprecated OBDII branch including diagnoistics CAN messages

      • Ted to work with Paul on timing for TST agenda and encourage stakeholders (Cummins, Allison, Karmak, Bosch, BMW, Volvo Group, Cox**…) **has VSS extension for diagnostics

• Potential GraphQL based project of fleet (may be able to do basic insurance guidelines as well) data

2025-12-02

• Materials for release:

  • Driving Progress in Commercial Vehicle Connectivity blog.docxPreview

  • Packaged fleet and insurance data guidelines, with explainer that reads more like a specification not just yaml

  • updated business case: OEM focus but include data consumers needs (which increases demand for OEM data) combining earlier, Stefan’s AOSP spreadsheet, study and press release from Allianz and involve our communications colleagues (Florian at Allianz, Kim at Geotab and Tina at COVESA)

    • Ted to start a draft: feed materials into GPT, review and share for input

  • Timeline: want to advance materials by EOY and discuss timing. Want data collection metadata conventions from Ford, pinged

• Updates:

  • California interested in discussing emissions/inspection

  • Hazardous materials and trailer signal extensions being discussed in CVIS

  • ACEA FMS advancing

  • Pinged Chaitanya from Ford on data collection metadata so we can publish our fleet/insurance guidelines using them

• Stefan shares use/business cases for OEM supporting insurance that has come out of AOSP discussion - shared screen of spreadsheet and AOSP group wiki and Allianz Motor Day | 2025: Autonomous Safety & Insurance

2025-11-25

• MDS debrief, plan going forward

  • Getting the word out on our efforts, other trade associations

• Emissions and inspection - early possibility, exploring

• Connected Safety reaction

  • Link to CS BoF’s minimal data set, compare to EU and VEDS: Location, fire, seatbelt, color, make/model, rollover…

  • Vehicle Theft - need to establish dialog companies like LoJack

  • FNOL - some data points already in our insurance signals list

    • In EU - since 2018 all OEM need to provide specific set of data

    • Vehicle Emergency Data Set in US

    • Commercial Vehicle cargo - hazardous materials

• Holiday schedule

  • Off 16, 23 and 30 December resume on 6 January 2026

2025-11-18

• Announcements / updates

  • Mobility Data Space (MDS) interested in talking about collaboration with COVESA

• COVESA Connected Safety BoF collaboration

  • Introductions

  • Brief overview of activities

    • Journey Map

  • Emergency Reporting Systems

    • define data collection campaign, map to existing reporting formats

    • insurance notification, less urgent than first responders but early FNOL important in overall response to victims

      • different privacy/consent considerations

    • Vehicle theft reporting - has correlation to vehicle accidents

  • Other areas of potential mutual interest

  • CA DMV - collaboration not definitive and not public

    • EU Decentralized Identification (DID), a proprietary service based onISO 18013-5 MDL may prevail

    • Driver health information to have as part of driver record, important to share to first responders

  • Next steps, assignments, resources and communication channels

Vehicle Emergency Data Set (VEDS) - common model to align with/map to VSS

Similar but different in EU

Extrication guides - Vehicle architecture - first responders want to know where not to put “jaws of life” - risk of triggering undeployed airbags while trying to extract injured parties, same with EV circuit breakers, fire retardant application

2025-11-11 Cancelled

2025-10-28

• AMM debrief

  • Interest in aligning with Road Safety group on producing VSS based signals report for emergency (accident) reporting and vehicle theft reporting along with tracking aspects if available.

    • some OEMs already collect that in a proprietary way

      • airbags deployed, number of occupants, severity of the crash (accelerometer), etc - ask Melanie for input

    • Ted to try to setup meeting with this group and include Bosch per Stefan’s suggestion

    • Richard NHTSA trying to standardize a crash severity report, see also eSafety (eCall) - ITS Standards

    • Stefan similar effort in EU from Emergency Number Association (EENA)

  • Interest in moving CCC/COVESA Digital Key signals forward, potentially going to be slow based on CCC process (Ecosystem WG, Use Cases WG then to their board?)

    • Fleet and insurance use cases to support

  • 2026 AMM - Porto, Portugal in April and Tokyo, Japan in October

  • Volvo Group North America interested in work with ACEA, Cox Automotive

  • In-vehicle payments moving forward - UBI

  • RTI presented may propose DDS for serializing and off-boarding VSS

  • Microsoft will be proposing an activity for vehicle edge AI based on VSS

• California DMV meeting with COVESA this week to discuss bringing their vehicle registration and driver’s license data models here for standardization - of interest to Vehicle Data Modelling activity as it is seeking additional domains beyond VSS

  • EU effort to normalize this as well to align with

• Use Cases and Datasets

  • Data Architecture Group wants to work on Use Cases for the playground - show how VSS can be used. Welcome collaboration and involvement instead of just taking your use cases, get more implementation details, privacy concerns (or leave aside for experimentation). Also would want some useful datasets.

    • Start a wiki planning page to contribute to

  • Willingness from the group to support, go over use cases in detail, give preferences on which to prioritize or useful to demo - human facing

  • Can keep it simple, leave to vehicle edge AI until later

  • Datasets - PIVOT Project - Colorado State University CAN Logger project going into “production”, generated (Bosch from Kai’s Fleet Management Data Guidelines demo - Berlin 2025 AMM, Eclipse SDV Blueprint) or provided (Geotab shared some with Bosch for benchmarking)

    • Workshop #4 (Nov 2025) - Google DrivePreview

• No longer staring at a blank page for our explainer/specification for data collection guidelines but not ready to share

• Input requested on COVESA draft blog on CV

• Encourage review of Motion Management pull request

2025-10-14

• Input on anti-theft data campaign

• AMM prep

• Paul: we need to make clearer what the group deliverables are

  • Deliverables for CV group

    • ACEA FMS (signals in VSS) and onboard API (VISS) - expect by EOY

    • Take the YAML overlays for fleet and insurance derived from spreadsheets and produce a human readable specification with links to YAML and JSON-Schema (insurance basic and fleet basic) similar to VISS spec

      • Privacy - yet make clear consent management should be followed and link to data exchange project wiki and mention eg IETF GNAP & EU Data and nearby acts

2025-10-07

• AMM spots open for commercial and fleet

• Getting review and input on data points of interest for vehicle theft reporting and recovery

• Reached out to Chitanya as I started going through Ford’s data collection and transmission conventions from their proposed VSS extensions (moved for VDM but not advanced)

• Sketching out our guidelines specification sections, quick review

• Insurance use cases?

• Thoughts on outreach?

• Review COVESA draft blog on CV

2025-09-23

• Updates

  • Volvo Group joined, Enterprise applied, Cummins moving forward, Samsara and others lingering

  • MDS EU Data Act workshop

  • VDM onboarding meeting - this Thursday at 6/9/3pm on community calendar

• COVESA marketing team - assist with messaging plan to update landing page, blog press release and social media promotion

  • met with them last week, provided TST CV Overview and Update slides, OEM Business Case for FMD and CV landing page

  • Need to have a significant release of deliverables, more realistically post AMM

  • Still looking for assistance in promoting more widely - input on materials from your marketing teams, conferences or orgs - start list and outreach owners

    • CCC

    • MDS

    • Eclipse SDV - via Bosch on their Fleet Blueprint project

    • ATA

• Commercial and Fleet Vehicles deliverables

  • ACEA FMS in VSS

  • Insurance and fleet data campaigns in YAML, JSON (Schema) and specification format

    • conventions for prescriptive on how it should be collected and descriptive for collected data

    • specification components: explainer of terminology, how YAML or JSON could be used for configuration or code generation, conventions, concrete examples if not all data points - inclined to do all and have a cross referenced use cases section

    • ReSpec example VISS3 - TOC, anchors, editors (Tom Sawyer analogy), status of doc, copyright/licensing, explainer with links to external references, normalized references etc

    • Terminology

      • “campaign” - metadata describing how data should be collected, have variant for how data was collected

      • “commercial vehicle” - poor choice in retrospect

      • review use cases terms, sampling conventions, event triggers, Hz

2025-09-16

• Insurance use cases - noticed activity on the sheets, review, discuss and accept

  • Need better workflow - now have four versions of our spreadsheet - agreement to use Google Sheets V3

    • Ted updated the first one in V3 "official version" as an example. I identified two use cases and put my initials in parenthesis (TG). Numbering to be confirmed later. Welcome wording improvements or alternative suggestions for us to review and agree 

2025-09-09

• Data points for car theft reporting https://docs.google.com/document/d/17ON447TCqevrx73_oYfM9xJXgeBz-zASY-3qzVag3qg/edit?tab=t.0

• Messaging and outreach - continued conversation with Toyota Connect EU - more B2B pressure would help

• Insurance use cases review

• ADAS https://github.com/COVESA/commercial-vehicles/tree/main/tmp/scratch

  • Review Video in VSS https://github.com/COVESA/vehicle_signal_specification/issues/816

2025-09-02

•  Car Connectivity Consortium (CCC) Digital Key (DK) Ecosystem Working Group meeting last week to discuss potential alignment with COVESA, principally to get DK data points into VSS which are of interest to commercial fleets and insurance.

• COVESA Technical Steering Team (TST) call last week, presented an update of this activity.

The principal need we have is increasing awareness, specifically promotion with wider insurance and telematics companies.

COVESA's marketing has already reached out to schedule a meeting. If anyone is interested in participating in our messaging and promotion with them directly, please let me know. We will also discuss on our regular call your ideas for how we get this to appropriate audiences.

Some hesitation on trying to cover so many ADAS signals in VSS on TST call, need to bring our Sensors work to TST for further discussion before making PR and discuss in VSS call

•  ACEA FMS progress
  Gomplate template to generate FMS in VSS

• All Member Meeting

  • clean up and package our existing data collection definitions (campaigns). For insurance I want to focus on our basic campaign