Log File Changes (schemaVersion=4)

The changes documented in this wiki page were prompted by the following Jira tickets:

• ODE-689: .h files from Lear needs to be updated
• ODE-690: Incorrect BSM transmit validation signature
• ODE-685: Adding fields for host and remote vehicles for BSMs

These changes are are prompted by schemaVersion=4

ODE-689: .h files from Lear needs to be updated

Lear documentation had an error regarding the securityResultCode in their previous .h file that defines the log file record structures and valid values. The change is how messages are validated for signatures. Previously success was defined as 1 and failure as 0. Now, 0 represents success and any other non-zero value represents a status code indicating why the signature validation failed. It is assumed that the validSignature parameter is populated with value from securityResultCode enum.

To address this change and report complete information to the end user, the existing validSignature boolean field in the ODE metadata was replaced with a new securityResultCode enum field that would translate to a string value when converted to JSON. The valid values for securityResultCode are as follows.

    success = 0,
    unknown = 1,
    inconsistentInputParameters = 2,
    spduParsingInvalidInput = 3,
    spduParsingUnsupportedCriticalInformationField = 4,
    spduParsingCertificateNotFound = 5,
    spduParsingGenerationTimeNotAvailable = 6,
    spduParsingGenerationLocationNotAvailable = 7,
    spduCertificateChainNotEnoughInformationToConstructChain = 8,
    spduCertificateChainChainEndedAtUntrustedRoot = 9,
    spduCertificateChainChainWasTooLongForImplementation = 10,
    spduCertificateChainCertificateRevoked = 11,
    spduCertificateChainOverdueCRL = 12,
    spduCertificateChainInconsistentExpiryTimes = 13,
    spduCertificateChainInconsistentStartTimes = 14,
    spduCertificateChainInconsistentChainPermissions = 15,
    spduCryptoVerificationFailure = 16,
    spduConsistencyFutureCertificateAtGenerationTime = 17,
    spduConsistencyExpiredCertificateAtGenerationTime = 18,
    spduConsistencyExpiryDateTooEarly = 19,
    spduConsistencyExpiryDateTooLate = 20,
    spduConsistencyGenerationLocationOutsideValidityRegion = 21,
    spduConsistencyNoGenerationLocation = 22,
    spduConsistencyUnauthorizedPSID = 23,
    spduInternalConsistencyExpiryTimeBeforeGenerationTime = 24,
    spduInternalConsistencyextDataHashDoesntMatch = 25,
    spduInternalConsistencynoExtDataHashProvided = 26,
    spduInternalConsistencynoExtDataHashPresent = 27,
    spduLocalConsistencyPSIDsDontMatch = 28,
    spduLocalConsistencyChainWasTooLongForSDEE = 29,
    spduRelevanceGenerationTimeTooFarInPast = 30,
    spduRelevanceGenerationTimeTooFarInFuture = 31,
    spduRelevanceExpiryTimeInPast = 32,
    spduRelevanceGenerationLocationTooDistant = 33,
    spduRelevanceReplayedSpdu = 34,
    spduCertificateExpired = 35

Since the new .h file does not specify any value for 1, we use that ordinal value to specify unknown security status. Upon this change, all archived records containing the validSignature= true must be updated to include a new field securityResultCode = unknown and all records with validSignature = false to be translated into securityResultCode = success.

ODE-690: Incorrect BSM transmit validation signature

On BSM transmit records, Lear does not include verification status (you will see this in the _bsmTxRecord of the .h file). ODE previously handled this missing information as valid signature and set the validSignature = true. The new requirement is to treat missing validSignatureas an unknown value in the securityResultCode, i.e. value of 1. Therefore, all BSM Transmit records that contain validSignature = true must be changed to securityResultCode = unknown and validSignature field removed entirely from those records.

ODE-685: Adding fields for host and remote vehicles for BSMs

BSM TX and BSM RX records have a value for the host vehicle (EV or 0) and for a remote vehicle (RV or 1) in the direction field. These values must be propagated to the ODE metadata so that the EV and RV records can be differentiated by applications that need it.

To address this issue, ODE added a new field bsmSource to the metadata component of all BSM data. BSM Transmit records (bsmTx RecordType) will always have bsmSource = EV. BSM records received during an event(bsmLogDuringEvent RecordType) will have the bsmSource field set to EV or RV according to the value contained in the log record. BSM records contained in a Received Message file (rxMsg RecordType) will always have bsmSource = RV by default.

Since this is a new field in the metadata, previously archived records must be modified to contain the following:

* bsmTx => bsmSource = EV
* bsmRx => bsmSource = RV
* bsmLogDuringEvent => bsmSource = unknown (because there is no practical way to determine the bsmSource)

[Sample output](files/bsmSourceTesting.json) with new metadata version can be found [here](files/bsmSourceTesting.json).

It is recommended that the applications receving the data handle the old schema and the new schema dynamically according to the schemaVersion and apply the above transformation rules appropriately and according to the schema acceptable by the application.