ASAMCommander is a modular web application for ASAM ODS–based test data management systems, providing engineers, analysts, and administrators with a customizable platform. It offers flexible data exploration and visualization, convenient ODS client, Matlab and Python access, and server-side analysis automation.

With ASAMCommander 25.2, we are releasing a major update to the AC-Mainframe and platform foundation. The new version focuses on corporate identity, embedded applications, user and group integration, and more predictable deployments. Platform owners and administrators can now brand ASAMCommander to match their environment, integrate more tightly with existing corporate authentication systems, such as OAuth, and operate external modules in a controlled and configurable manner.

In many ASAM ODS environments, ASAMCommander is more than just a client – it is the central entry point into a larger measurement data ecosystem. If branding, user management, or deployment patterns do not align with corporate standards, adoption suffers and operational overhead increases. The 25.2 mainframe update strengthens ASAMCommander as a platform, enabling it to be branded like any other enterprise application and supporting external applications through a consistent deployment and configuration model. This gives platform teams more control while reducing friction for end users.

Mainframe - Corporate Identity and Embedded Applications

• AC-Mainframe favicon, browser tab title, and logo can now be configured instead of hard-coded, allowing platform teams to align ASAMCommander with their corporate branding.
• Key-value properties from the configuration are merged with module defaults and made available to the embedded app. This allows environment-specific settings (such as backend URLs) to be implemented without requiring code changes.
• Improved handling of MF4 files, ensuring that large measurement files are not treated as generic attachments.
• A footer-based version display has been added and refined so administrators can quickly see which version is running without affecting the layout of embedded applications

Catalogs Management - User & group integration

• The user element has been extended with additional attributes to better align the AC user model with the directory.
• The importer for user groups has been updated to prevent changes in group structure from breaking the import in some corner cases.

Deployment & external application integration

• External applications can be attached to AC-Commander using, for example, a Helm-based deployment pattern, so custom modules can be deployed and configured alongside ASAMCommander
• A work package stabilizes the overall deployment by providing a clearer directory structure for both successful and failed runs.

Logging and language polish

• Logging configuration is more robust against minor formatting issues, helping to avoid missing log entries in job monitoring views.
• Wording and translations have been harmonized across modules (Navigator, Catalog, Search, Export, Bookmarks, Merlin-related views, etc.) for more consistent terminology in both English and German.

• Operate a branded ASAMCommander in production or for your customers - AC-Mainframe favicon, browser tab title, and logo can now be configured instead of hard-coded, allowing platform teams to align ASAMCommander with their corporate branding.
• Integrate with enterprise directories - Align ASAMCommander’s user and group model with an OAuth directory so that user attributes and group memberships stay in sync and imports remain robust over time.
• Deploy external modules easily - Use Helm-based configuration to attach additional applications to AC-Commander and pass environment-specific properties without hard-coding them into the code.
• Reduce operational friction - Benefit from clearer job directory structures, better handling of MF4 files, and many small UX refinements that remove blockers discovered during intensive customer testing.

ASAMCommander 25.2 is available as an update for existing ASAMCommander installations. Customers can obtain the release via the usual delivery channels or on request. For installation support, upgrade planning, or questions about compatibility with your ASAM ODS environment, please contact your HighQSoft representative.

#ASAM #ODS #TestData #ASAMCOmmander #TDM #TestDataManagement #ASAMODS #HighQSoft

ASAM e.V. published a new version of the ASAM MDF standard - an ideal container file as input for ASAM ODS-based Test Data Management systems. ASAM MDF is a binary measurement file format that was first released in 1991. The two major versions in use are Version 3.x (2002-2009) and Version 4.x (2009-). The standard is backwards and forwards compatible (within a major version).

The following sections provide an overview of major MDF 4.3 features.

Dynamic Data

MDF is usually used to store data records of fixed size. For a sorted file (only one channel group per data group), this means one can jump to any desired record when reading. There is also support for storing signals of varying size e.g. strings. Each string may have a different length, so the variable length data is stored separately (e.g. in an SDBLOCK) and referenced from the channel block. Here, the fixed record stores an offset used to locate the string in the SDBLOCK.

MDF also supports arrays of fixed size (including multidimensional arrays) where each element is the same type of data. These strategies cannot handle more complex cases, where the number (or type) of signals changes with each record. This is dynamic data.

There are two main motivations for recording dynamic data:

• Recording an existing serialization protocol (e.g. SOME/IP, Protobuf) as-is.
• Recording events where the number of signals is strongly variable in time (e.g. RADAR/ LiDAR).

MDF 4.3 introduces the DSBLOCK that can be used to mark a channel as containing dynamic data. In both cases, the raw data itself can be stored using the existing mechanisms for variable length data (VLSD, MLSD), fixed data or the new VLSC format.

The point of the DSBLOCK is to prevent readers supporting older versions of MDF from accessing and misinterpreting the dynamic data content, while referencing the description for MDF 4.3 compatible readers.

Standardized MDF Content Descriptions

Features in Autonomous Driving or ADAS (advanced driver assistance system) are dependent on measurements of the environment made by sensors. A single item recorded by a sensor (e.g. a snapshot at a moment in time) is usually called a frame.

MDF extends the concept of a ‘frame’ to a sensor event: both the raw frame data and additional properties needed for interpretation (e.g. image dimensions).

MDF 4.x:

• Bus Logging (CAN, LIN, FlexRay, MOST, Ethernet)
• Classification Results

MDF 4.3

• Raw Sensor Logging (Video, RADAR and LiDAR)
• GNSS (Global Navigation Satellite System)
• SOC (Service-Orientated Communication, SOME/IP)

GNSS Data Storage

GNSS (Global Navigation Satellite System) is the generalisation of GPS. Previous versions of MDF didn’t provide a way to unambiguously recognize channels containing GNSS data. This made it difficult for readers to correctly interpret GNSS data (e.g. routes with latitude and longitude) in files written by third-party tools.

SOC (Service Orientated Communication)

The new associated standard (Data Logging of Service Oriented Communication) is specifically designed to specify how SOME/IP is stored in MDF.

SOME/IP is a format for control messages sent over ethernet, used in AUTOSAR. It focuses on allowing clients to discover and subscribe to ‘services’ provided by a server. For example, this can be used to allow displays and telematics units to access data from cameras and other devices.

The standard defines names, tags and channel structures to allow a data logger to be able to store the raw content of the SOC data, with the important parts of the message structure ‘annotated’ in the form of MDF channels and metadata.

VLSC (Variable Length Data with Size Channel)

Most of the new dynamic data features can be stored in MDF using the existing mechanism for variable length signal data (VLSD) or maximum length signal data (MLSD).

However, VLSD has the disadvantage that the length of the variable signal data is always with the data itself, even after the file is sorted for efficient reading. This is often redundant when storing protocol data, since protocols often include the ‚count‘ as an additional channel.

VLSC allows the variable channel to reference a separate MDF channel that determines the count.

The changes are anticipated in the ASAM ODS 6.3 release which is scheduled for 2026.

#ASAMMDF #TDM #TestDataManagement #ASAMODS #HighQSoft