"FMI2.0标准协议：模块仿真模型交换与共模式导入的工具独立标准"

需积分: 17 23 浏览量更新于2024-01-20 收藏 3.47MB PDF 举报

The FMI2.0标准协议 (Functional Mock-up Interface for Model Exchange and Co-Simulation)是一个用于模块仿真应用的标准协议，其英文版被定义为"FMI2标准协议英文版"。这个标准协议是用来支持动态模型的模型交换和共同仿真的，通过使用XML文件和C代码的组合来实现，该C代码可以编译为DLL/shared libraries或者源代码。本文档定义了FMI的版本2.0.2，这是一个维护版本，与FMI 2.0相比没有新的功能特性。FMI是一个与工具无关的标准，旨在支持使用不同工具的动态模型的模型交换和共同仿真。该标准的第一个版本是FMI 1.0。 FMI2.0标准协议的英文版包含了详细的规范和指南，以便开发人员和模型工程师能够遵循标准规范来实现模块仿真应用。该标准涵盖了模型交换和共同仿真两种主要的应用情况，并提供了适用于这两种情况的标准接口和数据结构。这使得不同工具和系统中的模型能够进行交换和共同仿真，同时保持模型之间的兼容性和一致性。 FMI2.0标准协议的英文版还包括了对XML文件和C代码的详细描述，以及与模型交换和共同仿真相关的数据格式和交互流程。这些信息对于开发支持FMI2.0标准的工具和系统非常重要，因为它们能够根据标准规范来实现与其他工具和系统之间的兼容性，并确保模型交换和共同仿真的正确执行。 FMI2.0标准协议的英文版还包括了对FMI 2.0.2版本的更新和修订的详细说明，以及适用于该版本的指南和最佳实践。这有助于开发者在实现FMI2.0标准时遵循最新的规范和要求，并确保他们的应用能够与最新版本的标准保持一致。总之，FMI2.0标准协议的英文版是一个重要的文档，它为开发支持模块仿真应用的工具和系统提供了规范和指导，并促进了不同工具和系统之间的模型交换和共同仿真。该标准的实施将有助于模型工程师和开发人员在他们的工作中更好地实现模块仿真应用，并为用户提供更好的仿真体验。

Functional Mock-up Interface 2.0.2

Dec 15

2020

Page 16 of 130

FMI function names as strings. The name of the library is MyModel.dll on Windows or MyModel.so on

Linux; in other words the “modelIdentifier” attribute is used as library name.

[An FMU can be optionally shipped so that it basically contains only the communication to another tool

(needsExecutionTool = true, see section 4.3.1). This is particularily common for co-simulation tasks.

In FMI 1.0, the function names are always prefixed with the model name and therefore a DLL/Shared

Object has to be generated for every model. FMI 2.0 improves this situation since model names are no

longer used as prefix in case of DLL/Shared Objects: Therefore one DLL/Shared Object can be used for

all models in case of tool coupling. If an FMU is imported into a simulation environment, this is usually

performed dynamically (based on the FMU name, the corresponding FMU is loaded durin g execution of

the simulation environment) and then it does not matter whether a model name is prefixed or not. ]

Since “modelIdentifier” is used as prefix of a C-function name it must fulfill the restrictions on C-

function names (only letters, digits and/or underscores are allowed). [For example, if modelName =

“A.B.C“, then modelIdentifier might be “A_B_C“.] Since “modelIdentifier” is also used as name in

a file system, it must also fulfill the restrictions of the targeted operating system. Basically, this means

that it should be short. For example, the Windows API only supports full path-names of a file up to 260

characters (see: http://msdn.microsoft.com/en-us/library/aa365247%28VS.85%29.aspx).

2.1.2 Platform Dependent Definitions (fmi2TypesPlatform.h)

To simplify porting, no C types are used in the function interfaces, but the alias types are defined in this

section. All definitions in this section are provided in the header file “fmi2TypesPlatform.h”.

#define fmi2TypesPlatform "default"

A definition that can be inquired with fmi2GetTypesPlatform. It is used to uniquely identify the

header file used for compilation of a binary. [The “default” definition below is suitable for most

common platforms. It is recommended to use this “default” definition for all binary FMUs. Only

for source code FMUs, a change might be useful in some cases.]:

fmi2Component : an opaque object pointer

fmi2ComponentEnvironment: an opaque object pointer

fmi2FMUstate : an opaque object pointer

fmi2ValueReference : value handle type

fmi2Real : real data type

fmi2Integer : integer data type

fmi2Boolean : datatype to be used with fmi2True and

fmi2False

fmi2Char : character data type (size of one character)

fmi2String : pointer to a vector of fmi2Char characters

('\0' terminated, UTF-8 encoded)

fmi2Byte : smallest addressable unit of the machine

(typically one byte)

typedef void* fmi2Component;

This is a pointer to an FMU specific data structure that contains the information needed to

process the model equations or to process the co-simulation of the respective slave. This data

structure is implemented by the environment that provides the FMU; in other words, the calling

environment does not know its content, and the code to process it must be provided by the FMU

generation environment and must be shipped with the FMU.

typedef void* fmi2ComponentEnvironment;

This is a pointer to a data structure in the simulation environment that calls the FMU. Using this

pointer, data from the modelDescription.xml file [(for example, mapping of valueReferences to

Functional Mock-up Interface 2.0.2

Dec 15

2020

Page 17 of 130

variable names)] can be transferred between the simulation environment and the logger function

(see section 2.1.5).

typedef void* fmi2FMUstate;

This is a pointer to a data structure in the FMU that saves the internal FMU state of the actual or

a previous time instant. This allows to restart a simulation from a previous FMU state (see

section 2.1.8).

typedef unsigned int fmi2ValueReference;

This is a handle to a (base type) variable value of the model. Handle and base type (such as

fmi2Real) uniquely identify the value of a variable. Variables of the same base type that have

the same handle, always have identical values, but other parts of the variable definition might be

different [(for example, min/max attributes)].

All structured entities, such as records or arrays, are “flattened” into a set of scalar values of

type fmi2Real, fmi2Integer, etc. An fmi2ValueReference references one such scalar. The

coding of fmi2ValueReference is a “secret” of the environment that generated the FMU. The

interface to the equations only provides access to variables via this handle. Extracting concrete

information about a variable is specific to the used environment that reads the Model

Description File in which the value handles are defined.

If a function in the following sections is called with a wrong “fmi2ValueReference” value

[(for example, setting a constant with a fmi2SetReal(..) function call)], then the function has

to return with an error (fmi2Status = fmi2Error, see section 2.1.3).

typedef double fmi2Real ; // Data type for floating point real

numbers

typedef int fmi2Integer; // Data type for signed integer numbers

typedef int fmi2Boolean; // Data type for Boolean numbers

// (only two values: fmi2False, fmi2True)

typedef char fmi2Char; // Data type for one character

typedef const fmi2Char* fmi2String; // Data type for character strings

// (′\0′ terminated, UTF-8 encoded)

typedef char fmi2Byte; // Data type for the smallest addressable

// unit, typically one byte

#define fmi2True 1

#define fmi2False 0

These are the basic data types used in the interfaces of the C functions. More data types might

be included in future versions of the interface. In order to keep flexibility, especially for

embedded systems or for high performance computers, the exact data types or the word length

of a number are not standardized. Instead, the precise definition (in other words, the header file

“fmi2TypesPlatform.h”) is provided by the environment where the FMU shall be used. In

most cases, the definition above will be used. If the target environment has different definitions

and the FMU is distributed in binary format, it must be newly compiled and linked with this target

header file.

If an fmi2String variable is passed as input argument to an FMI function and the FMU needs

to use the string later, the FMI function must copy the string before it returns and store it in the

internal FMU memory, because there is no guarantee for the lifetime of the string after the function

has returned.

If an fmi2String variable is passed as output argument from an FMI function and the string

shall be used in the target environment, the target environment must copy the whole string (not

only the pointer). The memory of this string may be deallocated by the next call to any of the FMI

interface functions. (The string memory might also be just a buffer that is reused.)

Functional Mock-up Interface 2.0.2

Dec 15

2020

Page 18 of 130

2.1.3 Status Returned by Functions

This section defines the “status” flag (an enumeration of type fmi2Status defined in file

“fmi2FunctionTypes.h”) that is returned by all functions to indicate the success of the function call:

typedef enum { fmi2OK,

fmi2Warning,

fmi2Discard,

fmi2Error,

fmi2Fatal,

fmi2Pending } fmi2Status;

Status returned by functions. The status has the following meaning

fmi2OK – all well

fmi2Warning – things are not quite right, but the computation can continue. Function “logger” was

called in the model (see below), and it is expected that this function has shown the prepared

information message to the user.

fmi2Discard – this return status is only possible if explicitly defined for the corresponding function

(ModelExchange: fmi2SetReal, fmi2SetInteger, fmi2SetBoolean, fmi2SetString,

fmi2SetContinuousStates, fmi2GetReal, fmi2GetDerivatives,

fmi2GetContinuousStates, fmi2GetEventIndicators;

CoSimulation: fmi2SetReal, fmi2SetInteger, fmi2SetBoolean, fmi2SetString,

fmi2DoStep, fmiGetXXXStatus):

For “model exchange”: It is recommended to perform a smaller step size and evaluate the model

equations again, for example because an iterative solver in the model did not converge or because

a function is outside of its domain (for example sqrt(<negative number>)). If this is not possible, the

simulation has to be terminated.

For “co-simulation”: fmi2Discard is returned also if the slave is not able to return the required

status information. The master has to decide if the simulation run can be continued.

In both cases, function “logger” was called in the FMU (see below) and it is expected that this

function has shown the prepared information message to the user if the FMU was called in debug

mode (loggingOn = fmi2True). Otherwise, “logger” should not show a message.

fmi2Error – the FMU encountered an error. The simulation cannot be continued with this FMU

instance. If one of the functions returns fmi2Error, it can be tried to restart the simulation from a

formerly stored FMU state by calling fmi2SetFMUstate. This can be done if the capability flag

canGetAndSetFMUstate is true and fmi2GetFMUstate was called before in non-erroneous state.

If not, the simulation cannot be continued and fmi2FreeInstance or fmi2Reset must be called

afterwards.

Further processing is possible after this call; especially other FMU instances are not affected.

Function “logger” was called in the FMU (see below), and it is expected that this function has

shown the prepared information message to the user.

fmi2Fatal – the model computations are irreparably corrupted for all FMU instances. [For example,

due to a run-time exception such as access violation or integer division by zero during the execution

Functions fmi2SetXXX do not usually perform calculations but just store the values that are passed in internal buffers. The

actual calculation is performed by fmi2GetXXX functions. Still fmi2SetXXX functions could check whether the input arguments

are in their validity range. If not, these functions could return with fmi2Discard.

Typically, fmi2Error return is for non-numerical reasons, like “disk full”. There might be cases where the environment can

fix such errors (eventually with the help of the user), and then simulation can continue at the last consistent state defined with

fmi2SetFMUstate.

Functional Mock-up Interface 2.0.2

Dec 15

2020

Page 19 of 130

of an fmi function]. Function “logger” was called in the FMU (see below), and it is expected that this

function has shown the prepared information message to the user. It is not possible to call any other

function for any of the FMU instances.

fmi2Pending – this status is returned only from the co-simulation interface, if the slave executes the

function in an asynchronous way. That means the slave starts to compute but returns immediately.

The master has to call fmi2GetStatus(..., fmi2DoStepStatus) to determine if the slave has

finished the computation. Can be returned only by fmi2DoStep and by fmi2GetStatus (see

section 4.2.3).

2.1.4 Inquire Platform and Version Number of Header Files

This section documents functions to inquire information about the header files used to compile its

functions.

const char* fmi2GetTypesPlatform(void);

Returns the string to uniquely identify the “fmi2TypesPlatform.h” header file used for

compilation of the functions of the FMU. The function returns a pointer to a static string specified

by “fmi2TypesPlatform” defined in this header file. The standard header file, as documented

in this specification, has fmi2TypesPlatform set to “default” (so this function usually returns

“default”).

const char* fmi2GetVersion(void);

Returns the version of the “fmi2Functions.h” header file which was used to compile the

functions of the FMU. The function returns “fmiVersion” which is defined in this header file.

The standard header file as documented in this specification has version “2.0” (so this function

usually returns “2.0”).

2.1.5 Creation, Destruction and Logging of FMU Instances

This section documents functions that deal with instantiation, destruction and logging of FMUs.

fmi2Component fmi2Instantiate(fmi2String instanceName,

fmi2Type fmuType,

fmi2String fmuGUID,

fmi2String fmuResourceLocation,

const fmi2CallbackFunctions* functions,

fmi2Boolean visible,

fmi2Boolean loggingOn);

typedef enum {fmi2ModelExchange,

fmi2CoSimulation

}fmi2Type;

The function returns a new instance of an FMU. If a null pointer is returned, then instantiation

failed. In that case, “functions->logger” is called with detailed information about the

reason. An FMU can be instantiated many times (provided capability flag

canBeInstantiatedOnlyOncePerProcess = false).

This function must be called successfully before any of the following functions can be called.

For co-simulation, this function call has to perform all actions of a slave which are necessary

before a simulation run starts (for example, loading the model file, compilation...).

Argument instanceName is a unique identifier for the FMU instance. It is used to name the

instance, for example, in error or information messages generated by one of the fmi2XXX

Functional Mock-up Interface 2.0.2

Dec 15

2020

Page 20 of 130

functions. It is not allowed to provide a null pointer and this string must be non-empty (in

other words, must have at least one character that is no white space). [If only one FMU is

simulated, as instanceName attribute modelName or <ModelExchange/CoSimulation

modelIdentifier=”..”> from the XML schema fmiModelDescription might be used.]

Argument fmuType defines the type of the FMU:

 = fmi2ModelExchange: FMU with initialization and events; between events simulation

of continuous systems is performed with external integrators from the environment

(see section 3).

 = fmi2CoSimulation: Black box interface for co-simulation (see section 4).

Argument fmuGUID is used to check that the modelDescription.xml file (see section 2.3) is

compatible with the C code of the FMU. It is a vendor specific globally unique identifier of the

XML file (for example, it is a “fingerprint” of the relevant information stored in the XML file). It

is stored in the XML file as attribute “guid” (see section 0) and has to be passed to the

fmi2Instantiate function via argument fmuGUID. It must be identical to the one stored

inside the fmi2Instantiate function; otherwise the C code and the XML file of the FMU

are not consistent with each other. This argument cannot be null.

Argument fmuResourceLocation is a URI according to the IETF RFC3986 syntax to

indicate the location to the “resources” directory of the unzipped FMU archive. The

following schemes must be understood by the FMU:

Mandatory: “file” with absolute path (either including or omitting the authority component)

 Optional: “http”, “https”, “ftp”

 Reserved: “fmi2” for FMI for PLM.

[Example: An FMU is unzipped in directory “C:\temp\MyFMU”, then

fmuResourceLocation = “file:///C:/temp/MyFMU/resources” or

“file:/C:/temp/MyFMU/resources”. Function fmi2Instantiate is then able to read all

needed resources from this directory, for example maps or tables used by the FMU.]

Argument functions provides callback functions to be used from the FMU functions to

utilize resources from the environment (see type fmi2CallbackFunctions below).

Argument visible = fmi2False defines that the interaction with the user should be

reduced to a minimum (no application window, no plotting, no animation, etc.). In other

words, the FMU is executed in batch mode. If visible = fmi2True, the FMU is executed

in interactive mode, and the FMU might require to explicitly acknowledge start of simulation /

instantiation / initialization (acknowledgment is non-blocking).

If loggingOn = fmi2True, debug logging is enabled. If loggingOn = fmi2False, debug

logging is disabled. [The FMU enable/disables LogCategories which are useful for

debugging according to this argument. Which LogCategories the FMU sets is unspecified.]

typedef struct {

void (*logger)(fmi2ComponentEnvironment componentEnvironment,

fmi2String instanceName,

fmi2Status status,

fmi2String category,

fmi2String message, ...);

void* (*allocateMemory)(size_t nobj, size_t size);

void (*freeMemory) (void* obj);

void (*stepFinished) (fmi2ComponentEnvironment componentEnvironment,

fmi2Status status);

剩余129页未读，继续阅读

ciguozi12138

粉丝: 0
资源: 1

"FMI2.0标准协议：模块仿真模型交换与共模式导入的工具独立标准"

系统仿真技术：FMI、SSP与DCP标准解析

商用车CAN总线通讯协议-应用层诊断与故障码解析

CAN总线技术解析：基于J1939的诊断协议与应用

zadanie_fmi:网络服务

FMI、SSP、DCP简介

The FMI++ Library:基于FMI的软件开发的高级实用程序包-开源

Physio.FmiRestService:FMI 的 REST 服务包装器

中文版的DICOM标准

J1939中诊断协议通讯方法

Dicom3.0标准中文

最新资源