Common issues of SSP portability

[pmai]

This issue collects common portability issues seen in the use of SSP, with a view to implementing useful checks/examples to avoid such implementation pitfalls in the future.

[r-heines]

An SSP compliance checker and/or validated SSP examples would be very beneficial to increasing SSP adoption. When troubleshooting SSP portability issues currently, it can be quite time consuming to determine whether it is the importing tool or the exporting tool that is at fault. Good examples to use as test cases would help a lot, a compliance checker would be even better.

There are a couple of related issues on ssp-standard-dev but it does not appear that they were moved to ssp-standard:

Make (validated) SSP Examples publicly available (Open)
🔗 modelica/ssp-standard-dev#102

SSP Compliance Checker (Closed by Pierre)
🔗 modelica/ssp-standard-dev#53

[r-heines]

Here are some examples of SSP portability issues that we have run into recently:

Example 1: Improper validation by importing tool

The importing tool complained about an invalid root element. The exported SSP validated against the schema but we wanted a stronger case to present to the tool supplier. In lieu of any official validated SSP files, we reproduced the problem using the DC-Motor.ssp example from EasySSP. Fortunately the supplier of the importing tool accepted our explanation and agreed that the issue was on their side.

Suggested improvement: Example SSP file. Since this was a basic mistake, even a very simple example would suffice.

Example 2: Incorrect handling of optional attribute by importing tool

The importing tool was incorrectly treating the "type" attribute of the Component element as required when it is defined as optional in the SSP schema. The error reported by the importing tool was "could not find a source container" and it took some time to realize what was actually happening. We again used the DC-Motor SSP to root cause this issue and convince the tool supplier that it was on their side.

Suggested improvement: Example SSP files with and without optional attributes

Example 3: Exporting tool generated incorrect SSB file name

The exporting tool created a very subtle typographic error in the SSB file name. The exported SSP file passed schema validation but the importing tool raised an error like "missing ssb file". After verifying that the SSB file was in fact present in the SSP, it took some time to figure out what was actually going on. We used the FMPy read_ssd() function to root cause the problem.

Suggested improvement: SSP compliance checker

[t-sommer]

@r-heines, can you share some SSPs to reproduce these examples?

[r-heines]

@t-sommer I need to go thru some internal approvals before I can post any files to the public repo, in the meantime here is some detail to create test SSP files for each example.

Examples 1 and 2 were reproduced using the DC-Motor example from EasySSP:

Example 1: We used DC-Motor.ssp with no modifications. The tooling supplier accepted this as proof the issue was on their side.

Example 2: We modified the SystemStructure.ssd file in DC-Motor.ssp by deleting 'type="application/x-fmu-sharedlibrary"' from one Component.

Example 3: our exporting tool was incorrectly appending '.ssb' to both the SignalDictionary source and name attributes:

  <SignalDictionary source="resources/SignalDictionary_SSPTest.ssb.ssb" name="SignalDictionary_SSPTest.ssb" />

The corrected text is:

  <SignalDictionary source="resources/SignalDictionary_SSPTest.ssb" name="SignalDictionary_SSPTest" />

To reproduce, you can use any SSP file that contains an SSB signal dictionary and modify the SignalDictionary element in the SSD file as shown.