Test Data Automation | Page: 3 of 4 | Previous: Page 2: ASAM ODS Data Validation as a Job | Next: Page 4: From Script to ASAM ODS Analysis Job

Merlin Analysis Server automates the check and the analyses behind it. Merlin runs both as jobs, the check behind the import and the analyses behind the check, so ASAM ODS analysis automation covers the chain from stored measurement to result. Merlin is an analysis orchestrator comparable to Apache Airflow, defined by two properties. It integrates with the ASAM ODS data layer and is technology-agnostic. Engineers keep their Python, MATLAB, or Spark algorithms. Merlin orchestrates the jobs at scale, and the one thing it produces that matters most is a record of every run, so results stay traceable, reproducible, and comparable. Merlin runs thousands of analysis jobs daily at major OEMs.

Each technology gets a binding. Your team does not have to agree on a language. Merlin creates a binding for each technology that executes it through a common API. Whichever binding runs a job, one queue and one monitor cover the MATLAB job and the Spark job alike. The next technology a team brings gets a binding, not a parallel system. The current bindings cover the technologies a test data estate typically contains.

Analysis jobs follow the check. They compute derived values and channels, detect events, compute KPIs over time-bounded intervals, label events and segments repeatably, and generate reports and plots as artifacts. Upstream job completion is one of the events that trigger a job, so an analysis job placed behind the check starts when the check finishes, with nobody to launch it. Like the verdict, its results are parametersets, with KPIs and statistics as parameters and reports or plots as attachments. Analysis often involves exploration, cross-campaign comparisons, and questions that change; parts of it will always require a human. The engineer exploring the data starts a registered job on demand from the Merlin UI, and the run leaves the same record as a triggered one.

Stages and jobs are written once. A stage serves every job that needs it, so one job's HQL read stage and store stage are building blocks of the next. A whole registered job can run as a stage of another, so "import, then validate" is assembled from an importer job and a check job, not programmed. A report job retargets to a different application model by swapping its HQL query and a configuration file, so the evaluation written for one program serves the next. Templates are versioned, so each new job is built from pieces the last one proved. The gain counts per job, not per language, and the worked example on page 4 walks one pipeline stage by stage.

The Merlin UI shows every job in one place. It is now available as a module of ASAMCommander. Engineers start jobs directly from ASAMCommander, where their data lives, bookmark their own jobs to re-run them and return to prior results, and review generated artifacts, result payloads, logs and notifications together. Administrators define standardized workflows as job templates with versioning and activation control, monitor every job system-wide by status and time, and restart, pause or dismiss jobs from the same screen.

The layer carries what teams would otherwise code. A Merlin job begins with an HQL selection stage that asks the data layer a question instead of walking a file share. A predefined store stage writes every result back, linked to its measurement, so no team maintains a results store of its own. Logging, job versioning, parameter capture, retries and isolation between jobs come from the layer, so one failed job does not take down the queue. Existing scripts reach the same governed data without leaving their language, because pyHQL and the ASAM ODS Toolbox for MATLAB give Python and MATLAB code the same HQL selection the stages use. Each piece arrives with the first job and serves every job after it.

Access control, retention and availability are supported. Application-level access control reaches the instance level, with role and group based control and corporate identity integration, as one layer in a TISAX-compliant architecture. Regulated test data typically carries minimum retention of 10 years for data not used in certification, 20 for certification data and 30 for safety-relevant data. The importer records a deletion date, so each measurement shows a retention clock; deletion runs by review list or automatically on expiry; archiving moves aging data to cheaper storage without losing its provenance. Redundancy and scale-out by adding AReS Libertas instances, with health monitoring, support 24/7 operation. The platform provides the record an ISO 26262 traceability argument needs; it does not deliver compliance.

Every measurement is checked on arrival, as volume grows. In an ASAM ODS test data automation chain, the verdict comes from the job that follows the import, in the same form for every measurement, so results are available automatically rather than when an engineer next has time. The analyses behind the check run the same way. Analysis jobs run without manual intervention; data is imported, jobs are triggered automatically or on schedule, and results flow into dashboards and reports. More stands, more sites and more runs add jobs, not manual checks, so a growing program no longer falls back to checking a sample. Re-run decisions are made while the rig is still set up, and the test stands stop waiting on one person's availability.

Every campaign is checked the same way. One job version replaces every personal copy of the check, and its thresholds are parameters recorded with every run. When a threshold changes, nobody updates a copy on every workstation, and the record shows which runs were checked under which value and which job version. Variation between engineers no longer hides in private copies; where two runs were checked differently, the record shows how. The analysis behind the check inherits the same property, so a comparison across campaigns compares numbers computed the same way from data checked the same way.

Results compare across stands, sites and campaigns. Every verdict of a job is a parameterset with the same named parameters, so verdicts from different stands, sites and weeks sit side by side in one query, and so do the KPIs computed behind them. Each result also carries a free-form label the team chooses, and a consistent labelling convention turns "every validation result in this campaign" into a single query instead of a folder crawl. Because a parameterset is an ASAM ODS instance, every conformant tool can read it, including tools from other vendors.

Every number can be explained. Data lineage records how each result came to be, as data in ASAM ODS linked to the measurement. Every result carries the job and its version, the parameters it ran under, the catalog version in force and when it ran, back through the importer and its mapping to the original file. Catalog mapping versions lock on use, so signal definitions hold still. A program review asks which job version produced a released KPI; the record names it. A faulty component is traced to every measurement it touched. The same job version with the same parameters on the same data gives the same verdict, so every check is repeatable and a questioned result is re-run, not argued about.