search

vectorgrp / XCPlite

Simple implementation of the ASAM XCP on Ethernet protocol
MIT License
171 stars 93 forks source link

CPP_Demo.a2l with mixed types of STRUCTURE_COMPONENTs #56

Closed IgorGall closed 11 hours ago

IgorGall commented 2 weeks ago

Hey there! I am enjoying reading the ASAM MCD-2 MC v1.7.1. I read in the readme of this repository that it is supposed to work with ASAM MCD-2 MC v1.4. So there might be a problem of used specifications. I could not find the specifications for v.1.4 so I decided to raise a possible issue. In ASAM MCD-2 MC v1.7.1 for the description of "TYPEDEF_STRUCTURE", there is a note on the "STRUCTURE_COMPONENT". It says "_It is not allowed to mix up components which represent measure objects and components which represent adjustable objects inside one structure. That means a structure can contain either measure objects only (defined via TYPEDEF_MEASUREMENT) or adjustable objects only (defined via TYPEDEF_AXIS, TYPEDEF_CHARACTERISTIC or TYPEDEFBLOB)." The way I understand the CPP_Demo.a2l, there are measurement objects, this is "value" and adjustable objects, these are "par_ampl", "par_phase", and "par_offset". So there are object types mixed up.

Is it an issue?

RainerZ commented 14 hours ago

Hello,

Thanks for your feedback.

The ASAM Standards involved are MCD-1 MC XCP 1.4 and MCD-2 MC (ASAP2 / A2L) 1.71. As you pointed out, the A2L specification clearly states that objects with measurement and calibration semantics may not be mixed within a structure.

A calibration tool might want to read, modify and persist the value of a structure instance as a whole, by accessing the memory block at instance address with structure length. Fundamentally, an object with calibration semantics must never be mutated by the target software, but is allowed to be modified by the tool. When a structure contains components with measurement semantics, a tool might observe unexpected changes of the overall structure instance memory content.

So yes, this is a violation of the standard and might be an issue. We do not recommend this, to achieve maximum compatibility with any tool or future compatibility. And putting a mixed structure instance in an A2L memory segment would definitely be an issue.

There is no problem with CANape, as long as the structure instance memory area is not inside a memory segment. The XCPlite CCP_Demo does not create memory segments and CANape does not make any assumptions on the memory area of a structure instance. Note that CANape does not support the CONSISTENT_EXCHANGE keyword yet.

But this might be subject to change in future versions of CANape: Possible assumptions made on memory areas of calibration structure instances may be the same that are made on memory segments:

  1. The complete memory range is never mutated by the ECU.
  2. Writing the complete memory range does not cause undefined behavior (even if the A2L description of the memory area does not cover all bytes of the range).
  3. Writing the memory range may be done atomic (the concepts may be implementation specific, are not well defined by the standards, XCP and CANape have a few features to support this).
  4. The checksum of the area may be considered as a hash value to optimize caching.

The XCPlite CCP_Demo simply demonstrates a way how to address calibration objects in dynamically allocated memory in a thread safe way. To avoid possible issues, you could split measurements and calibrations into different objects.

Regards RainerZ

IgorGall commented 11 hours ago

I understand the big picture you were explaining. Thank you for the clarification.