2022-06-29 CIECA CAPIS vehicle Meeting Minutes

🔓 Public Page

Agenda

• Antitrust

• Committee Welcome/Networking

• Introduction of CAPIS

  • CAPIS Guidelines and Best Practices

• Excel Comparisions of BMS to CAPIS

• GitHub

  • capisCodeListsSchema.json

  • capisSimpleTypesSchema.json

  • capisVehicleCommonAggregatesSchema.json

  • capisVehicleMessageSchema.json

Meeting Minutes

• Antitrust Accepted

• Welcome/Networking

• Introduction of CAPIS

  • Introduced members of the Architecture Committee that were in attendance that have been helping create the CAPIS standards. Dan Webster, the Architecture Committee Chair, Jeff Schroder, Mike Hastings, Andy Bober, Chrisa Hickey, has laryngitis and not able to speak.

  • capis guidelines (cieca.com)

    • The Capis Guidelines and Best Practices web page can be found under Standards/Products if you are signed in.

    • This document goes over the Guidelines, Style Guide and covers the Process the Architecture is working through to prove the Proof of concept.

    • The Process the Architecture committee is working through is recommended for anyone to follow that is currently developing API’s before the CAPIS Standards are published.

• Compare BMS VehicleInfo to CAPIS vehicle in excel document

• The BMS Aggregates that are in Purple were seen as unnecessary levels of hierarchy and removed and any necessary properties that were below the aggregate was moved up.

• The Red Lines are BMS Aggregates that were removed due to the examples that were provided for analysis and the test instances in CIECA, did not use these properties and they were felt that they were remaining due to backward compatibility. If there are any red lines that you use, please inform Paulette and provide some examples of how the data is used. The architecture team will review the examples and add back if necessary and make sure the examples are included in test instances.

• The Green lines are new fields that are not in the BMS and seen as being needed for the hybrid and EV vehicle fleet.

• The Blue lines are fields that were removed by the Architecture committee and determined in this meeting to be needed. The members of this meeting will provide the examples of use.

• Specific Review Notes

  • Manufacturer property example would be ‘General Motors’ or ‘Toyota’ and would be used to tie into the interchange.

  • LicensePlateRegistrationDate and LicensePlateExpirationDate is used in salvage with a vehicle in total loss to determine the remainder of the Registration is owed to the consumer.

    • The Architecture Committee Concept is to start with zero base budgeting and everyone to ask to add it back if it is still needed. The Architecture members look forward to everyone’s participation and happy to see so many people in attendance and providing feedback.

    • For Global Licensing, should we change the name from License Plate to License Registration?

      • The Architecture Committee would not be making those changes, the rename of a property would need to go through the CIECA Product Committee(s) and a proposal made to the Architecture team.

    • The largest change to vehicle is the changes that were made to set up for the hybird and EV vehicles. In the BMS we had VehicleOptions that was a CIECA Option Code List and Description. The Option Code List includes Accessories, lights, bumper (Vehicle Options), along with Engine and Transmission Options.

      • CAPIS has vehicleOptions that is using a CIECA vehicle options code list and a detailedVehicleOptions that is an open code that can be used for OEM repair procedures are really any vehicle options you need for your message.

      • BMS Powertrain was an optional aggregate that had Engine and Transmission. To align with hybrid vehicles and EV, CAPIS Powertrain will be repeating and have an EngineOptions and detailedEngineOptions, TransmissionOptions and detailedTransmissionOptions and configuration.

        • The Engine/transmission options are set up the same way as vehicleOptions, however, they will have a specific code list.

        • The BMS code list will not be changed at this time.

        • The EV battery, could that be a category of vehicle, or would it be a new property?

          • It could be both, if we want to add battery without making changes to this structure, we can add it to the code list.

          • If it makes more sense to have its own code list validation, we have a structure in place that we can add battery under powertrain and set it up like Engine and Transmission.

          • This will be left up to a CIECA committee that can identify the data needed for battery, possibly the new EV committee.

    • OdometerReadingCode that uses a Code List to allow the message to say the reading is actual was reviewed, we know there is a business reason that we have this property and code list but will verify if there are any BMS messages using it.

    • Package is needed due to the number of levels and options an OEM can tie to a package.

    • Parts was questioned to be used with Total Loss and Salvage of a vehicle.

      • The Parts are seen to be many and its own property. It can be used in an API message with Vehicle, with Vehicle being singular and Parts being repeating, however, it is not seen that it needs to be a level of vehicle at this time.

      • PartInfo will be reviewed at the Architecture Committee Face to Face meeting and hopefully an example of this can be provided.

    • drivableInd is part of Vehicle, should Total Loss be part of Vehicle?

      • In the BMS TotalLoss is part of LossInfo, which is part of a claim, we will be reviewing ClaimInfo and PolicyInfo as well in the in-person meeting.

• Custom Fields are not needed as part of vehicle because we are allowing expandability and we hope this provides everyone with the flexibility that is needed to add fields that are not part of the CIECA CAPIS standards.

👥 I would like to thank the Architecture Committee for all of the hard work and dedication they have been providing and thank each of you for the great feedback and direction provided today.

Action items

Decisions