Add `obsolete` or `warning` attributes to scalar variables about fmi-standard HOT 10 CLOSED

The expiration date should be stored in the model internally, so that we can return fmi2status = fmi2warning when calling fmi2SetupExperiment from an expired FMU

Couldn't you do this already now? The FMU could inquire the system time and return fmi2status = fmi2warning if it considers itself obsolete. Explanations of this behavior can be stored in the FMUs documentation.

What would be the benefit of standardizing an obsolete attribute?

from fmi-standard.

As a side note, there are efforts underway in the SmartSE project, and other places, to standardize a set of model meta data (using the SRMD format from SSP Traceability, or alternatively other formats). Embedding this kind of meta data into an FMU is one of the approaches of using it. I think that additional information like release status, obsoleteness, etc. should be handled in these kinds of standards, and not the core FMI standard.

from fmi-standard.

I understand we have interface definition stuff like protobuf or SSP, but it involves more communication sometimes.

from fmi-standard.

It is found that variable names (especially IOs and parameters) are very difficult to modify once we distribute the first functioning version of an FMU to the users. Updating IOs usually involves a lot of communication and meetings with different teams and users in a large organization or across different suppliers. I am sure it is a pain point for a lot of FMU users. It would be great if we can solve this in future fmi standards.

Maybe like the proposal in #1817?

from fmi-standard.

Yeah, I think the proposal should be able to fix the issue. However, personally speaking, I think a dynamic FMU might be an overkill, and sometimes people want to be able to unzip the fmu and browse through the modelDescription.xml to understand what's actually inside the model.

Or maybe add attributes like an expirationDate or maintenancePeriod to the fmu itself would be great too, we can have LTS (long term support) FMUs and we can have experimental FMUs. Just like food, it is the buyers' (fmu importers) opinion if consuming expired food (fmu) is healthy or not.

from fmi-standard.

The expiration date should be stored in the model internally, so that we can return fmi2status = fmi2warning when calling fmi2SetupExperiment from an expired FMU

from fmi-standard.

@hyumo : Could you please explain the use-case and the semantics of the proposed "obsolete" attribute for variables? To be honest, I don't really understand the intention.

from fmi-standard.

The expiration date should be stored in the model internally, so that we can return fmi2status = fmi2warning when calling fmi2SetupExperiment from an expired FMU

Couldn't you do this already now? The FMU could inquire the system time and return fmi2status = fmi2warning if it considers itself obsolete. Explanations of this behavior can be stored in the FMUs documentation.

What would be the benefit of standardizing an obsolete attribute?

Sorry, I was jumping roles between an importer and an exporter, and this idea is for sure not very ripe. I want to tell the user story a bit more in detail below.

As a user/importer, I might want to get a fmi2warning if the FMU is expired, and I also want to know the reason for the warning. It could be logged to the console if logging is enabled. However, as a user I don't want to get this warning as a surprise, it would be great if the FMU expiration information is stored in the modelDescription.xml so that a good import tool can choose to warn e.g. 1 month ahead of the expiration date. Just like Dymola, it warns its user that the license expires in 1 month in the graphics viewer, it is annoying, but its existence is to annoy people

As an FMU exporter, yes, I can definitely embed this time bomb information into an FMU, but this information is only stored internally in the FMU binary, it might surprise my user if they don't have too much knowledge about the FMU suddenly become "broken" (user yelling: why the FMU was returning fmi2success for the last 10 months, but now it always returns fmi2warning).

from fmi-standard.

I propose to use existing mechanisms like fmi2warning in combination with a information provided in the FMUs documentation, or use addetional meta-information e.g. from the SSP Tracebility information for your purpose, and not extend the FMI standard with this information.

from fmi-standard.

FMI design meeting:

Pierre: meta-data should handled by SSP traceability or other layered standards.
Attribute per variable: This would be a separate issue.
Expiration can be handled inside the binary and documented in the FMU documentation.

from fmi-standard.