Connecting Tools Programmatically

The Integration Problem

Most engineering tools were built to be used by humans, not by other tools. A structural analyst opens the FEA software, imports geometry, applies boundary conditions, meshes, runs the solver, and post-processes results — all through a graphical interface. A requirements engineer writes and traces requirements through a GUI built for human navigation. A systems modeler builds diagrams interactively.

These tools are excellent at what they do. But they are silos. Getting data from one tool to another requires a human to export from one, transform the format, and import into another. Every step in that chain is a potential failure point: wrong export settings, format mismatches, missing data fields, version confusion.

An automated pipeline cannot click buttons in a GUI. It needs programmatic access — APIs, command-line interfaces, scripting hooks — to read data from tools, write data to tools, and trigger tool operations. The challenge is that most engineering tools provide limited, inconsistent, or proprietary programmatic interfaces.

API Wrappers: Normalizing Access

An API wrapper is a layer of code that sits between the pipeline and a specific tool's native interface. The wrapper translates the pipeline's standardized requests into the tool-specific API calls, and translates the tool's responses back into a standardized format.

Why wrappers matter. Without wrappers, the pipeline is coupled directly to every tool's proprietary API. Change the FEA tool and you rewrite the pipeline. Upgrade the requirements tool and the pipeline breaks. With wrappers, only the wrapper changes — the pipeline continues to speak its own standardized language.

What a wrapper does. It provides a consistent interface for common operations:

• Read: Extract data from the tool (model parameters, simulation results, requirement attributes)
• Write: Push data into the tool (updated parameters, configuration settings)
• Execute: Trigger a tool operation (run a simulation, generate a report, perform a check)
• Status: Query whether the tool is available, whether a job is running, whether results are ready

The wrapper pattern in practice. Each engineering tool gets its own wrapper that implements the same interface. The pipeline calls read_parameters(tool="thermal_sim", model="v3.2") and the thermal simulation wrapper knows how to extract parameters from that specific tool's data format. If the organization switches thermal simulation tools, only the wrapper is rewritten — every pipeline that uses it continues to work.

This is the same adapter pattern used in software engineering. It is not glamorous. It is the single most important architectural decision in an engineering automation infrastructure.

Data Transformation

Even with API access, tools disagree on how to represent the same physical reality. The pipeline must transform data between tool-native representations.

Unit Conversion

The structural tool reports stress in pascals. The legacy material database stores allowables in ksi. The thermal tool uses watts per meter-kelvin for conductivity. The systems model uses BTU per hour-foot-degree-Fahrenheit because that is what the customer specification uses. Every data handoff is a unit conversion opportunity — and a unit conversion error opportunity.

The pipeline must enforce explicit unit handling. Every numeric value that crosses a tool boundary carries its units. Conversions are performed by the pipeline's data transformation layer, not by the tool wrappers (which should report in native units) and not by the pipeline logic (which should not contain unit conversion factors embedded in business logic).

Format Translation

A CAD tool exports geometry as STEP. The mesh generator needs STL. The FEA solver needs its native mesh format. The results viewer needs VTK. Each translation is a potential data loss: STEP preserves topology and parametric information; STL preserves only triangulated surface geometry. The pipeline must know what information survives each translation and what is lost.

Naming and Identification

The requirements tool calls it "REQ-THERM-042." The thermal simulation tool calls it "max_junction_temp." The test database calls it "TC-117-measured-peak." These are all the same physical quantity — the maximum junction temperature — but every tool uses its own naming convention. The pipeline needs a mapping layer that translates between tool-specific identifiers and a canonical identifier used internally.

This mapping is tedious to build and critical to maintain. When a new parameter is added to any tool, the mapping must be updated. When an identifier changes (tool upgrade, reorganization), the mapping must be updated. Neglecting this mapping is one of the most common reasons engineering pipelines produce subtly wrong results — the pipeline runs successfully but connects the wrong parameters.

Standards-Based Integration

Two standards are particularly relevant for engineering tool integration:

OSLC (Open Services for Lifecycle Collaboration)

OSLC defines a set of web-based protocols for linking and sharing data across lifecycle tools. It was designed specifically for the problem of connecting requirements management, design, test, and project management tools without building point-to-point integrations.

What OSLC provides. A standard way to expose tool data as web resources with defined schemas. Tools that implement OSLC can link their artifacts: a requirement in a requirements tool links to a test case in a test management tool via an OSLC link. The link is live — follow it and you get the current state of the linked artifact, not a stale copy.

Where OSLC works well. Linking requirements to design to test across tools from different vendors. IBM tools (DOORS, Rhapsody, RTC) have mature OSLC support. The standard is strong for traceability links and lifecycle artifact relationships.

Where OSLC has limitations. It is primarily a linking and metadata protocol, not a bulk data transfer mechanism. Transferring large simulation datasets or CAD geometry through OSLC is impractical. The standard also has uneven adoption — many engineering tools (particularly simulation tools) have limited or no OSLC support. Implementation quality varies significantly between vendors.

FMI (Functional Mock-up Interface)

FMI defines a standard interface for exchanging simulation models between tools. A simulation model packaged as an FMU (Functional Mock-up Unit) can be imported into any FMI-compliant co-simulation environment, regardless of which tool created it.

What FMI provides. A standardized way to package a simulation model with its solver (Model Exchange) or as a callable component for co-simulation (Co-Simulation). Variables are exposed with defined types, units, and causality (input, output, parameter). Multiple FMUs can be connected in a co-simulation to model system-level behavior from domain-specific components.

Where FMI works well. Multi-domain system simulation: connecting a thermal model from one tool, a structural model from another, and a control model from a third into a single co-simulation. FMI has broad support across simulation tools — Simulink, Dymola, ANSYS, GT-SUITE, and many others export and import FMUs.

Where FMI has limitations. The standard defines the interface, not the solver behavior. Numerical stability in co-simulation depends on step size coordination, which FMI supports but does not guarantee. Large-scale models with many variables can have performance issues. And FMI is a simulation-specific standard — it does not address the broader lifecycle integration that OSLC targets.

Error Handling

Automated pipelines must handle failures gracefully. Engineering tool failures are more varied and more difficult to diagnose than software build failures.

License Unavailable

Commercial engineering tools require licenses. A simulation that runs at 2 AM may fail because all licenses are checked out. The pipeline must detect license failures (distinct from simulation failures), implement retry logic with backoff, and escalate if the license remains unavailable after a defined period. This is an infrastructure failure, not an engineering failure — the pipeline should not report it as a simulation problem.

Model Locked

In a collaborative environment, the model file may be locked by another user or process. The pipeline must detect lock conflicts, wait or queue, and log the delay. Long lock times may indicate a process problem (someone checked out the model and went on vacation) that requires human intervention.

Simulation Diverged

A simulation that fails to converge is an engineering problem, not an infrastructure problem. The pipeline must distinguish between "the solver crashed" (infrastructure — retry), "the solver did not converge within the allowed iterations" (engineering — the model may be ill-conditioned), and "the solver converged but the results violate physical constraints" (engineering — the input data may be wrong).

Each failure type requires a different response. Infrastructure failures retry. Engineering failures notify the responsible engineer with diagnostic information. The pipeline's error classification logic is as important as its happy-path execution logic.

Timeout

Simulations have expected runtimes. A thermal simulation that normally completes in 20 minutes but has been running for 3 hours is probably stuck — not running a harder problem. The pipeline should set timeouts based on historical runtimes, kill hung processes, and report the timeout as a specific failure mode with enough context (which model version, which parameters were unusual) to help diagnose the cause.

The Integration Architecture

Putting these pieces together, a well-designed tool integration architecture has three layers:

Tool layer. The engineering tools themselves, each with their native APIs, data formats, and operational characteristics. The pipeline does not touch this layer directly.

Wrapper layer. One wrapper per tool, implementing the standardized interface (read, write, execute, status). Each wrapper handles the specifics of its tool's API, authentication, file formats, and error codes. Wrappers are maintained by the teams that know the tools best.

Pipeline layer. The orchestration logic that sequences stages, manages data flow between wrappers, handles errors, and reports results. The pipeline layer knows nothing about specific tools — it knows only about the standardized interface that wrappers provide.

This separation is not just good software architecture. It is the key to a sustainable automation infrastructure. Tools change — vendors release new versions, organizations switch products, APIs evolve. When the tool changes, only the wrapper changes. The pipeline survives.

Assessment