Public Page

2022-05-17 Architecture Meeting Minutes

Public Page

Date: May 17, 2022

 

 

 

ANTITRUST STATEMENT

As participants in this meeting, we need to be mindful of the constraints of antitrust laws. There shall be no discussions of agreements or concerted actions that may restrain competition. This prohibition includes the exchange of information concerning individual prices, rates, coverages, market practices, claims settlement practices, or any other competitive aspect of an individual company’s operation. Each participant is obligated to speak up immediately for the purpose of preventing any discussion falling outside these bounds.

Agenda

  • Antitrust

  • Committee Welcome

  • Meeting Minutes Review

  • Review the BMS examples of vehicle to determine the powertrain aggregates of engine and transmission.

  • Review analysis on valuation fields.

Meeting Minutes

  • Antitrust Accepted

  • Welcome

    • Jeff Mueller, Jody Prather and Joanna Cohen all joined as they have been working with vehicle data and can provide details.

  • Meeting Minutes Reviewed and Accepted

  • Option Codes

    • There is a CIECA option code and an OEM Option code for parts

    • Vehicle has Option Codes, plural. This could be 50+

    • Sometimes partners can share OEM option codes and then other times they may not have permission to share OEM.

    • Moving to JSON do we do Open Enum and Closed Enum or just have strings.

    • Options is a paired from Code and Description

      • The concept of paired codes may have come from the EMS

    • Codes would be added to Open Code list and then proposed to CIECA to be added to the CIECA Code List.

    • Would we need a code, description and code Type? A triplet

      • Code Option Type

        • OEM

        • CIECA

        • OEM Part Option Codes

        • OEM Vehicle Option Codes

    • Its outside the scope of CIECA to come up with these codes, the trading partners can share with CIECA on request.

    • Mike shared the example

      • VehicleOptions: [

        • {

        • OptionCode: “AC”

        • OptionDesc: “Air Conditioning”

        • OptionCodeType: “CIECA Option Code”

        • }

        • {

        • OptionCode: “286”

        • OptionDesc: “Turbocharged”

        • OptionCodeType: “Manufacurer Option Code”

        • }

    • Mikes example has Option Code Type as a new code list with the below values

      • CIECA Option Code

      • Manufacturer Option Code

      • Manufacturer Part Platform Code

      • Manufacturer Part ID Code

      • Other

    • Vehicle Option Code

      • Manufactures have codes for Vehicles for attributes of the vehicle. Example would be Truck with gear ratio and positive traction. The gear ratio and positive traction would both have a code to reflect how a vehicle is equipped.

      • Manufacturers part platform code transmission for the manufacturer has a name and code that will reflect what transmission they used. And each transmission can have different variations, which could add for more option code.

    • The Powertrain, Engine and Transmission, would this go away and we just have option codes

      • This would be Powertrain as an array

        • Each powertrain would have 1 Engine and 1 Transmission

      • We keep the existing BMS aggregates, just use the same option Code.

      • We want to keep Powertrain because we know there can be more than 1 powertrain for the hybrid.

    • Architecture Committee is not looking to add new Aggregates for the EV, that would be other committee that would bring the values to be approved. The architecture structure proposed would allow it to be easily added.

      • Current BMS does not handle the hybrid. Would we need to add this structure to the BMS?

        • We need to keep it backward compatible

    • In XML we have XQuery and other tools that allows you to query your markup to look for option code = CIECA Option Code

      • IN JSON it has predicate that does not work the same way.

    • Multiple Engine options found in real life was just a handful

    • CIECA Code List for Options have 1000s or values

      • If we cannot have OEM options, this would make implementations more difficult if people are adding those value if they can share them.

      • We could add new properties for CIECA Option Code, CIECA Option Description

      • In the Conversion tool we have a series of codes that need to be validated

      • If we get rid of the code list we cannot validate

    • An Array does not have all entries of the same type. There are ways to validate when they are similar but different and different code list can be used. Not sure this is best way but it is possible.

      • CIECA vehicle options can be validated

      • Non CIECA options would not be validated

  • Next week

    • Examples of CIECA Option Codes and Manufacture Option Codes

    • Another example is an Address with State and Country code. If they choose Canada how do we validate Providence is from Canada.

    • Have proposal of how options work and we can look at all the proposals and come up with the correct architecture.

Great Meeting Everyone!

Up Next

  • Antitrust

  • Committee Welcome

  • Meeting Minutes Review

Action items

Decisions

Participants

  • Paulette Reed

  • Jody Prather

  • Jeff Schroder

  • Paul Barry

  • Mike Hastings

  • Jeff Mueller

  • Dan Webster

  • Joanna Cohen

  • Andy Bober

Participants in the meetings are noted for your information.  If you have questions on the committee’s activities, please contact a recent attendee. Architecture Committee