search

ihedvall / mdflib

Implementation of the ASAM MDF data file.
https://ihedvall.github.io/mdflib/
MIT License
75 stars 31 forks source link

Requirement Bus Logger MDF writer #21

Closed ihedvall closed 12 months ago

ihedvall commented 1 year ago

Introduction

Currently the Basic MDF writer exist. It is a general MDF logger which maybe would have been a better name. It assumes that signal (channel) values are received from some source, with some sort of periodic. Time is the common period.

When logging a communication buses, the MDF standard have some common design. The file doesn't contains any signal values. Instead is the data frames (raw bytes) saved. It's 99% CAN buses that use this so initial implementation should target CAN frames.

The main issue with these types of loggers is that output is just raw data bytes. For automotive, the Vector DBC file can be used to translate the raw bytes to scaled engineering values. I have made a DBC parser for that purpose. FIBEX is the ASAM standard replacement for DBC files.

The XCP protocol uses one or more A2L files instead. An A2L file describe an ECU functionality/memory in detail.

Requirements

The Bus logger shall primarily only handle CAN (FD) messages.

The Bus logger shall store data frames (CAN messages) according to the ASAM standard.

The user shall configure a new data group and which channel groups to use. A channel group is identical to a CAN message. This defines which messages to log.

The user doesn't need to define the channels as this should be according to the MDF standard.

The user may however define so-called sub-channels to the frame channel. These channels reference the frame data bytes not the channel group sample bytes (frame bytes). The channel byte size and offset is typically find in the DBC file.

Simplxss commented 1 year ago

I think we can automatically add the channels(in cn_composition) when finding cn_flags contains Bus event flag, because the structure is fixed and needn't to be defined by the user, but there would be a problem that how to add the SI or CC information to the subchannels. When writing datas, it's a good choice to make a structure CanData and add a function WriteAsCanData(CanData&) to channel.h. Just some suggestions, I just know a little about it.

ihedvall commented 1 year ago

Normally is the CAN loggers running in tiny embedded devices, The only information is what message ID (CAN ID) to store. The draw-back is that the logger has no information about the CAN channel values or its conversion.

The channel configuration as well as the message ID, is defined in a Vector DBC file (or a FlexRay file). So if the DBC file is known, the channel composition and its CC conversion can be automatic created. Still the message ID needs to be defined. I think the SI information may be in the DBC file but I take a rain check on that. The DBC repository (ihedvall/dbclib) can be used for this purpose. The DBC repository includes the mdflib so maybe the the bus logger source files should be here? Multiplexed channels may be a problem!

The next level is to capture XCP data. This data is more complex as it reference an A2L file which is a little bit of a monster to parse. There is a project and repository (ihedvall/a2llib) for this but I just started this project.

The write CAN Data function should be on the channel group (is equal to a CAN message) so it's just a twist of the SaveSample() function today.

  1. The "just save message bytes" works for both XCP and CAN solutions with optional DBC/A2L file attachment. Disadvantage comes when reading the MDF file later as the raw bytes to channel/engineering values has to be done later. The DBC lib has this functionallity (see DBC Viewer).
  2. If the DBC file is available, the composition channel can be used but multiplexed channels need some solution (SI ?).
ihedvall commented 1 year ago

FYI

There is 3 basic problems with CAN message vs channel values.

  1. CAN may only hold 8 bytes of data. Some CAN protocols as J1939 may define a message with more than 8 bytes so to get a complete channel value, several messages needs to be "merged". Just to make it worse all CAN protocol have its own sequence number handling.
  2. There exist multiplexed channel i.e. a channel value is dependent on another channel value. To make it worse. Vector added an extended multiplexed channel definition used in OBD2 diagnostic. It is a little bit confusing.
  3. CAN loggers are normally running on embedded hardware where threads may be missing. The current writer uses threads for caching but can be removed. I guess a file system is needed.
ihedvall commented 12 months ago

Finalized the new Bus Logging functionality.