3. Portfolio inventory and asset cataloging

A CAE portfolio is only as valuable as the speed at which an engineer can find a trustworthy model, reuse a validated load case, or retrieve a prior result set. Inventory and cataloging turn scattered solver decks, spreadsheets, and post-processing files into a governed, searchable repository. This chapter focuses on the practical construction of that repository: what to catalog, how to describe it, and how to make retrieval reliable across a large vehicle program.

What Constitutes a CAE Asset

Before building a catalog, the portfolio team must define the asset boundary. In automotive CAE, a single "asset" is rarely one file. It is a logical unit composed of several artifact types that must stay linked:

• Model assets — the discretized representation: mesh files, assembly definitions, material cards, connection (weld, adhesive, bolt) definitions, and solver input decks.
• Load case assets — boundary conditions and excitation definitions: constraint sets, load curves, acceleration profiles, thermal maps, and event definitions such as frontal impact, side pole, or durability block cycles.
• Result assets — solver output: displacement, stress, strain, energy, and derived metrics such as intrusion, HIC, or fatigue life.
• Metadata assets — the descriptive layer that makes the above searchable: version, author, solver, unit system, vehicle variant, and validation status.

The critical design decision is to treat metadata as a first-class asset, not an afterthought. A model without metadata is effectively invisible to the portfolio.

Designing the Catalog Schema

A searchable repository requires a consistent schema. The schema should be normalized enough to support queries but flexible enough to accommodate new solver types and vehicle programs. A practical schema for automotive CAE uses the following core entities and relationships:

Each entity carries a stable identifier. In practice, teams adopt a naming convention such as BIW_FRONT_IMPACT_50KPH_v03 where the segments encode body system, event, severity, and version. The convention must be enforced at ingestion; free-text naming destroys searchability.

Metadata Capture and Ingestion

Manual metadata entry does not scale. The repository should extract as much metadata as possible from the artifacts themselves. For a typical LS-DYNA or Abaqus deck, the following can be parsed automatically:

# Example extraction targets from a solver deck
*KEYWORD
*INCLUDE
model_biw_v03.k          # model reference
*MAT_ELASTIC
1, 210000.0, 0.3          # material: E, nu
*BOUNDARY_SPC_SET
100, 0, 1, 1, 1, 0, 0, 0  # constraint set ID
*LOAD_SEGMENT
200, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0  # load curve reference

An ingestion pipeline parses these keywords, maps them to schema fields, and writes a catalog record. The pipeline should also compute a content hash so that duplicate uploads are detected and version lineage is preserved. When a model is revised, the new version inherits the load case links but receives a new hash and version number.

Making the Repository Searchable

Searchability depends on three layers working together: structured fields, full-text indexing, and relationship traversal. Structured fields answer precise queries such as "all frontal impact load cases with severity 50 kph on BIW models." Full-text indexing covers comments, README files, and report text. Relationship traversal answers questions like "which results were produced from this model version?"

A practical query interface supports faceted search. The user selects a vehicle variant, an event type, and a validation status, and the repository returns matching load cases with their linked results. The following example shows a representative query expressed against the catalog:

SELECT lc.name, r.metric, r.value, r.unit
FROM load_case lc
JOIN result r ON r.loadcase_id = lc.loadcase_id
JOIN model m ON m.model_id = lc.model_id
WHERE m.vehicle_variant = 'SUV_X'
  AND lc.event_type = 'frontal_impact'
  AND lc.severity = '50kph'
  AND r.metric = 'intrusion_mm'
ORDER BY r.value ASC;

The result is a ranked list of intrusion values across load cases, which an engineer can use to identify the best-performing configuration or to spot outliers that require investigation.

Result Repository and Metric Extraction

Storing raw solver output for every run is expensive and rarely necessary. The repository should store a curated set of derived metrics plus a pointer to the full result files. Metric extraction is performed by a post-processing script that reads the solver output and writes normalized values into the catalog. For a frontal impact case, typical extracted metrics include:

• Maximum intrusion at the firewall and footwell (mm)
• Peak deceleration at the B-pillar (g)
• Energy absorbed by the front rail (kJ)
• HIC15 at the driver position

Each metric is stored with its unit, extraction timestamp, and solver version. This allows trend analysis across program phases and supports correlation studies when physical test data becomes available.

Governance and Lifecycle

A catalog without governance degrades quickly. The portfolio team should define lifecycle states for each asset: draft, reviewed, released, and archived. Only released assets are visible to the broader engineering community by default. Archived assets remain searchable but are flagged as superseded. Access control should be role-based: model owners can update metadata, while consumers have read-only access.

Visualizing the Catalog Structure

The following diagram shows the relationship between the core entities and the ingestion path from raw solver artifacts to a searchable catalog record. It illustrates how model, load case, and result assets are linked through stable identifiers and how metadata flows from parsing to query.

Practical Implementation Notes

When implementing the repository, start with a narrow but complete slice: one vehicle variant, one event type, and one solver. This proves the schema and ingestion pipeline before scaling. Use a relational database for structured metadata and an object store for large result files. Index the metadata fields that appear most often in queries: vehicle variant, event type, severity, and validation status.

Finally, measure retrieval success. Track how often engineers find the asset they need on the first query, and how often they fall back to asking colleagues. A catalog that is technically complete but practically unfindable has failed its purpose. The goal is not to store everything, but to make the right asset discoverable in seconds.