This is the 7th day of my participation in the November Gwen Challenge. Check out the details: The last Gwen Challenge 2021

This article is from the FMI2.0 specification of chapter 4 co-simulation translation, based on computer translation and personal understanding.

A, opening

This paper defines the functional simulation interface (FMI) for joining two or more simulation models (FMI for common mode) in a co-simulation environment. Co-simulation is a fairly common method for simulating technical systems and related physical phenomena, with emphasis on time-dependent problems.

Coupling Simulation: The application of shared grid technology to solve the problem of multidisciplinary CAE view model coupling simulation in a digital environment.

Time-dependent: time-dependent

Co-simulation is designed to be coupled with multiple subsystem models, which have been exported as runnable code by their emulators and solvers. It can also be used for emulator coupling (emulator coupling, tool coupling).

In the case of tool coupling, the FMU implementation class provided by the emulation tool wraps calls to FMI functions as API calls (C-> other languages). In addition, simulation tools are required to co-simulate the FMU. Most commonly, co-simulation based on tool coupling implements different subsystems handled by different computers on distributed hardware, including different operating systems (cluster computers, computer farms, computers in different locations).

Data exchange and communication between subsystems is usually done using a network communication technology (such as MPI, TCP/IP). The definition of this communication layer is not part of the FMI standard, but it can be used to implement a distributed co-simulation scheme, as shown in the figure below

The host must implement a communication layer, and other parameters used to establish network communication (for example, the remote computer’s identity, port number, user account) will be set through the host’s GUI, and none of these data will be transmitted through the FMI API.

Second, mathematical description

1. The basic

Co-simulation takes advantage of the coupling problem (modular architecture) encountered at all stages of the simulation process, starting with the separate model setup and preprocessing of each subsystem for different simulation tools (which can be powerful emulators or simple C programs).

When time integration is carried out, data exchange between subsystems can only be carried out in discrete communication points TCI, and all subsystems can be independently simulated. For simulation coupling, the simulation tools in the subsystem independently perform visualization and post-processing of simulation data. In different contexts, communication point TCI, communication step tCI -> tCI +1 and total number of communication step hCI := tCI + 1-tCI are called sampling point (synchronization point), macro step and sampling rate respectively. The term “communication point” used in the FMI for co-simulation refers to the communication between the neutron systems in the co-simulation environment and should not be mixed with the output point for saving simulation results to a file,

Sampling: refers to the point in time of sampling

Macro step: Refers to the time interval between two Sampling. Sampling Rate refers to the frequency of Sampling of analog signals per second when analog/digital conversion is performed in the application of digital audio and video technology. For example, CD and MD have a sampling rate of 44.1kHz, representing 44,100 samples per second of analog audio signals. The higher the sampling rate is, the higher the conversion accuracy is, and the reemitted analog signal waveform is closer to the original analog signal waveform. The level of sampling rate. Determines the upper limit of the frequency of the analog signal that can be converted.

FMI provides an interface standard for co-simulation, providing a solution for time-dependent coupled systems consisting of subsystems that are time continuous (model components described by stationary difference equations) or time discrete (model components described by difference equations, such as discrete controllers). In the block representation of a coupled system, a subsystem is represented by blocks with (internal) state variables X (t) that are connected to modules of other coupled subsystems (modules) through subsystem inputs U (t) and subsystem outputs Y (t). In this framework, physical connections between subsystems are represented by mathematical coupling conditions between inputs U (t) and outputs Y (t) of all subsystems.

Difference equation: equation containing unknown functions of difference and independent variables. In the numerical solution of differential equation, the differential is often approximated by the corresponding difference, and the resulting equation is the difference equation. Finding approximate solutions of differential equations by solving difference equations is an example of discretization of continuous problems.

In order to do co-simulation, two basic groups of functions must be implemented:

  • Data exchange function between subsystems
  • Function for algorithm problems to synchronize simulation of all subsystems and perform communication step tCI -> tCI +1 from initial time TC0 := tstart to end time tcN:=tstop.

In the FMI for co-simulation, both functions are implemented in a single software component, the Co-simulation host (Master). Data exchange between the Slave subsystems is only through the master station, there is no direct communication between the Slave stations. The main function can be implemented through a special software tool (a separate emulation backplane) or one of the emulation tools involved. Most commonly, coupled systems can be simulated in a nested co-simulation environment, and the FMI for co-simulation applies to each level of the hierarchy.

The FMI for co-simulation defines the interface rules for communication between the host and all slave machines (subsystems) in a co-simulation environment. The most common master station algorithm is to stop the simulation of all slave stations (time integral) at each communication point TCI, collect the output Y of all subsystems (TCI), adjust the subsystem input U (TCI) and assign these subsystem inputs to slave stations, Then proceed to the (collaborative) simulation with the next interaction step tc I -> TC I +1 = TC I + HC, the interaction step is a fixed parameter HC. In each slave station, the appropriate solver should be used to integrate one of the subsystems given the interaction step tCI -> TCI +1. The simplest co-simulation algorithm approximates the (unknown) subsystem input u(t) of TCI ≤t < tCI + 1 by freezing the data u(TCI),(t> tCI). FMI for co-simulation supports this classical brute force solution as well as more complex master algorithms, aiming to support a class of very general master algorithms, but it does not define a master algorithm itself.

The ability of slave stations to support more complex master algorithms includes a set of capability Flags in the SLAVE XML description. The classic example is

  • Has processing variable communication step hciThe ability to
  • TCS with rejected communication step size repeated with reduced communication step sizeiT < or less tci+ 1 ability
  • Provides the derivative of output time to support interpolation
  • The ability to provide jacobian determinants

FMI for co-simulation is limited to slave stations with the following properties:

  • All computed parameter values v(t) are at predefined time intervals (tstart <= t <= tstop) (fmi2SetupExperiment, stopTimeDefined=fmi2True)
  • In general, all calculations (simulations) are made over time. The current timetFrom tstartTo the tstopStep by step. Slave algorithms may have attributes in [tstart, tstop] The simulation is repeated throughout or in part of an interval.
  • You can provide a time value tc for the slave stationi(tstart <= tci <= tstop)
  • When the time reaches TCi, the slave station can interrupt the simulation
  • During interrupt simulation, the slave (independent solver) can be transferred from the input U (TC)i) gets the value and sends the value to output Y (tci).
  • Whenever the simulation in the slave station is interrupted, the new time value is TCi+1(tci <= tci+1 <= tstop) can give a time subinterval (tci < t <= tci+1)
  • Subinterval length HCiIs the length of the i-th communication step (the communication step must be greater than zero) : hci=tci+1-tci

The FMI process for co-simulation is as follows

  • The process starts with instantiation and initialization (getting all slave devices ready for computation, establishing communication links)
  • Then simulate (force slave device to simulate communication STEP)
  • Finally close when finished

2. Mathematical model

This section contains the formal mathematical model of the co-simulation FMU, which can make the following basic assumptions:

  • The slave emulator is treated as a pure sampling data system by the master emulator and can be

    • “Real” sampled data systems (discrete controllers; The inputs and outputs can be Real, Integer, Boolean, String, or enumerated types. Such variables are defined as variability = “discrete”; The minimum FMU externally accessible sampling period is defined by the attribute stepSize in DefaultExperiment.)
    • Hybrid Odes are integrated between communication points (sampling access to time-continuous systems) in which internal events may occur and be processed, but not seen outside the FMU. Assume here that all inputs and all outputs of this hybrid ODE are real signals (defined as variability = “continuous”)
    • A combination of the above systems

  • Communication between master and slave stations takes place only at a set of discrete moments called communication points.

Description of relevant variables of FMI co-simulation model:

  • T: Independent variable time∈ℝ (Causality = “independent” defined variable); The ith communication point is represented by t= TCi, the communication step is expressed as HCi = tci+1 – tci
  • V: vectors of all exposed variables
  • P: constant parameter during simulation
  • A reference to p without a subscript indicates an independent parameter (Causality = “parameter”);
  • Variable parameter Pcalculated(Causality = “calculatedParameter”)
  • Adjustable parameter ptune(Causality = “parameter”, variability= “tunable”)
  • u(tci) : Input variable
  • y(tci) : Output variable
  • w(tci) : local variables of FMU that cannot be used for FMU connections, defined by Causality = “local”
  • xc(t) : Represent continuous time state by vector of actual continuous time variable
  • xd(t) : discrete time variable
  • .xd(t) : the last discrete time variable

The following definitions exist:

  • At the communication point, the master station provides a common input to the slave station
  • The slave machine provides a common output to the host
  • Initialization: The slave station is a system of sampled data whose internal state (whether continuous time or discrete time) needs to be initialized to t= TC0. This is done through helper functions [the relationship is defined in the XML file below]. Calculating the solution of the FMI co-simulation model means dividing the solution process into two stages, and using a different method of equation solution in each stage. Stages can be classified according to the following pattern
    • Initialization Mode: Iterate over the FMU equation if the slave is connected to other models in a loop. In this mode, algebraic equations are solved
    • Step Mode: This Mode is used to compute the values of all (real) continuous and discrete time variables at the communication point by performing numerical solutions to ordinary differential, algebraic, and discrete equations. Iteration of the FMU equation is not possible if the slave station is connected to other models in a loop

The functions used in the following table, fmi2SetXXX, are short for fmi2SetReal, fmi2SetBoolean, fmi2SetInteger, and fmi2SetString. The function fmi2GetXXX is an abbreviation of the functions fmi2GetReal, fmi2GetBoolean, fmi2GetInteger, and fmi2GetString

The equation is FMI function
The equation before initializing the schema (” instantiation “in the state machine)
Set I =0 and set tc of the argumenti fmi2SetupExperiment
Set variable vinitial=exactAnd vinitial=approx fmi2SetXXX
The equation after initializing the schema
At t = t0Enter initialization mode (activation initialization, discrete time and continuous time equations) fmi2EnterInitializationMode
Set variable vinitial=exact(Including initial value xc,initial=exactIndependent parameter P and continuous time state) fmi2SetXXX
Set continuous time and discrete time input uc+d(tc0) and an input u that optionally sets the continuous time derivativecj(tc0) Fmi2SetXXX, fmi2SetRealInputDerivative
vInitialUnknows:=finit(uc,ud,t0,vinitial=exact) Fmi2GetXXX, fmi2GetDirectionalDerivativ
Exit initialization mode (deactivate the initialization equation) fmi2ExitInitializationMode
Equations in Step mode (” Step Complete “, “stepInProgress” in state machine)
Set the independent tunable parameter ptuneDo not set other parameters pother) fmi2SetXXX
Set parameters continuous time and discrete time input Uc+d(tci) and the optional continuous time input uc(j)(tci) the derivative of Fmi2SetXXX, fmi2SetRealInputDerivative
tci+1:=tci+hci

(yc+d,yc(j),wc+d)tci+1 := fdoStep(uc+d,uc(j),tci,hci,ptune,pother)tci

tci:=tci+1

The fdoStepIt’s also a function of the internal variable		 fmi2DoStep

fmi2GetXXX

fmi2GetRealOutputDerivatives

fmi2GetDirectionalDerivative

FMI application programming interface

This section contains an interface description for accessing input/output data and status information from a co-emulation slave station from a C program.

1. Transmission of input/output values and parameters

Input variables, output variables, and variables are transferred through the fmi2GetXXX and fmi2SetXXX functions defined in this section.

In order to enable the slave machine to use continuous real numbers as input interpolation between the communication steps, the derivative of the input with respect to time can be provided. Higher order derivatives can also be set to allow higher order interpolation. Whether a slave machine can interpolate is given by the function canInterpolateInputs. (If the input is speed, then the derivative of speed with respect to time is given. So between two points in time, we can use speed * time t to find the speed at time t). Here are the relevant functions:

Fmi2SetRealInputDerivatives:

- the set of real Numbers input variable in the derivative of the NTH time points fmi2Status fmi2SetRealInputDerivatives (fmi2Component c, constfmi2ValueReference vr [], size_t NVR, Constfmi2Integer ORDER [], constfmi2Real Value []) "VR" : vector containing the value of the variable, which defines the variable whose derivative needs to be set. "NVR" : vector dimension "ORDER []" : order of the derivative (1 indicates the first derivative, 0 is not allowed). "Value []" : vector of derivativeCopy the code

The restrictions for using this function are the same as for the fmi2SetReal function. The input and its derivatives are set at the beginning of the communication time step. To allow the actual output variable to be interpolated/approximated between communication steps as other slave inputs, the derivative of the output with respect to time can be read. Whether a slave can provide an output derivative is determined by the function flag MaxOutputDerivativeOrder(unsigned integer type); It defines the order of the output derivative. If the actual order is low (because of the low order of the integration algorithm), the retrieved value is 0. For example, if the internal polynomial is of order 1 and the host requests the second derivative of the output variable, the slave returns zero.

Fmi2GetRealOutputDerivatives:

- retrieve the output value of the NTH derivative fmi2Status fmi2GetRealOutputDerivatives (fmi2Component c, constfmi2ValueReference vr [], size_t NVR, constfmi2Integer order[], fmi2Real value[]); "Vr" : the vector containing the value of the variable, which defines the variable whose derivative needs to be set. "NVR" : vector dimension "Order []" : the order of the derivative (1 indicates the first derivative, 0 is not allowed). "Value []" : vector of derivativeCopy the code

The output variable returned corresponds to the current slave time, such as the end of the communication time step after the successful execution of fmi2DoStep.

2. Calculate

2.1 fmi2DoStep

The time step calculation is controlled by the following functions

	fmi2Status fmi2DoStep(fmi2Component c, 
	fmi2Real currentCommunicationPoint, 
	fmi2Real communicationStepSize, 
	fmi2Boolean noSetFMUStatePriorToCurrentPoint)
Copy the code

, this function is used to calculate the time step parameter currentCommunicationPoint represent the current communication point (tci) of the host, parameter communicationStepSize said communication step length (hci > 0.0). The slave station must be integrated until TCI +1 = TCI + hCI. The calling environment defines the communication points, and fmi2DoStep must evaluate the integral precisely to TCI + hCI to synchronize with these points. It is up to fmi2DoStep to achieve this goal.

After the call fmi2ExitInitializationMode function, the first call fmiDoStep, parameter currentCommunicationPoint must be equal to the fmi2SetupExperiment startTime parameter Settings. 【 currentCommunicationPoint will not be officially used parameters, define it in order to solve the master node and slave nodes between FMU state does not match the question: By the previous fmi2DoStep or fmi2SetFMUStatecall the parameters of the function definition currentCommunicationPoint, from the FMU node status must be consistent with each other)

For example, if the slave node does not use the update formula (tCI +1 = tCI + hCI) for the independent variable as required above, but uses its own update formula internally, for example, TCS, I +1 = TCS, I + HCS, I (fmi2DoStep function, Tci = currentCommunicationPoint); The slave node can use time increment HCS, I :=(tCI-tcs, I)+ hCI (instead of HCS, I := hCI) to avoid excessive deviation between master node time TCI +1 and slave node internal time TCS, I +1.

In the simulation run, if between currentCommunicationPoint to preset time no longer call fmi2SetFMUState function, The set parameters noSetFMUStatePriorToCurrentPoint = “fmi2True” [from the node can use this logo to refresh the result buffer].

Function return value:

  • fmi2OKEach substep is computed successfully until the end of the communication step (master time step).
  • fmi2Discard— The slave node successfully calculates only part of the communication step interval, and the master node can call the correspondingfmi2GetXXXStatusFunction to get more information. If possible, the master node should repeat the simulation with a shorter communication step. Only functionfmi2GetFMUStateThe step size can be repeated only if the FMU status is recorded at the beginning of the current (failed) step. This is done by callingfmi2SetFMUStateAnd then use new onescommunicationStepSizecallfmi2DoStepTo achieve.
  • fmi2Error— FMU encountered an error. The FMU instance cannot continue to be simulated. If one of the functions returns fmi2Error, you can try calling itfmi2SetFMUstateRestart the emulation from the previously stored FMU state.
  • fmi2Fatal— Model computations of all FMU instances cannot be fixed (for example, due to access conflicts or runtime exceptions such as integer divided by zero during the execution of fMI functions)
  • fmi2Pending— Execute asynchronously from the node, that is, return immediately when execution begins. If this state is returned from the node, the master node must call the functionfmi2GetStatus(... ,fmi2DoStep,...)To determine whether the slave node is complete; The alternative is to wait for the slave to invoke the callback functionfmi2StepFinished; And call the functionfmi2CancelStepYou can cancel the current calculation. If this value is returned, infmi2DoStepNo other functions are allowed to be called during execution.

If fmi2DoStep returns fmi2Pending, the fmi2CancelStep function can be called to stop the current asynchronous execution.

fmi2Status fmi2CancelStep(fmi2Component c);
Copy the code

If the user or one of the slave nodes stops running the co-emulation, the primary node calls the secondary function. After that, only fmi2Reset or fmi2FreeInstance can be called.

3. Obtain the status information of the secondary node

Feedback the current status information of the slave node to the master node through the following functions:

fmi2Status fmi2GetStatus(fmi2Component c,const fmi2StatusKind s, fmi2Status* value); fmi2Status fmi2GetRealStatus (fmi2Component c, const fmi2StatusKind s,fmi2Real* value); fmi2Status fmi2GetIntegerStatus(fmi2Component c, const fmi2StatusKind s, fmi2Integer* value); fmi2Status fmi2GetBooleanStatus(fmi2Component c, const fmi2StatusKind s, fmi2Boolean* value); fmi2Status fmi2GetStringStatus (fmi2Component c, const fmi2StatusKind s, fmi2String* value); -- Notify the master node, Typedefenum {fmi2DoStepStatus, fmi2PendingStatus, fmi2LastSuccessfulTime, fmi2Terminated } fmi2StatusKind; // fmi2Warning, // Warning fmi2Discard, // fmi2Error was successfully calculated from the node. Fmi2Pending // async} fmi2Status; fmi2Pending; fmi2Pending;Copy the code

Notify the master node about the actual state of the simulation run, with the fmi2StatusKind parameter determining the state information to return. What state information slave nodes can provide depends on the slave node’s capabilities. If you need a state that cannot be retrieved from the node, it returns the state fmi2Discard.

The fmi2StatusKind structure contains the following states:

state type describe
fmi2DoStepStatus fmi2Status Called when fmi2DoStep returns fmi2Pending. This function provides fmi2Pending if the calculation is not complete. Otherwise, the function returns the result of the fmi2DoStep call that was executed asynchronously.
fmi2PendingStatus fmi2String Called when fmi2DoStep returns fmi2Pending. This function provides a string that tells you the status of the asynchronous fmi2DoStep calculation that is currently running
fmi2LastSuccessfulTime fmi2Real Returns the end time of the last communication step that completed successfully. This can be done in fmi2DoStep (…) Called after returning fmi2Discard.
fmi2Terminate fmi2Boolean Returns true if the slave node wishes to terminate the emulation. This can be done in fmi2DoStep (…) Called after returning fmi2Discard. Use fmi2LastSuccessfulTime to determine when the slave node terminates

4. State machines that call the order from the master node to the slave node

The following state machine defines the sequence of calls supported by the FMI specification

Each state of the state machine corresponds to a specific phase of the simulation, as follows:

  • Instantiated: From this state, you can set start and estimate values (variable attribute initial = “exact” or “approx.”), set derivatives, and set simulation conditions

  • Initialization Mode: In this state, The equation can be used to determine that all the output (and other optional variables everywhere in the export tool) is in an XML file that you can call with fmi2GetXXX Variables defined (Causality =”output”), variables that can be set initial=”exact”, and variables with variability=”input”

  • SlaveInitialized (initialized from node) : In this state, the slave node is initialized and the co-simulation is performed; Use the function “fmi2DoStep” to perform the calculation until the next communication point. Slave nodes are in different states depending on the return value

    • step complete
    • step failed
    • step canceled

  • Terminated: This state is used to obtain the solution at the last moment of simulation.

Note: in initialization mode, the ModelStructure can be defined according to the elements

,

in the XML file, the input variables can be set using fmi2SetXXX, and the output variables can be obtained using fmi2GetXXX. [for example, if an output y1 depends on two input u1, u2, you must first set up the two input, and then you can get y1. If additional output y2 u3 depends on the input, you can set u3, and then obtain y2; by using the appropriate numerical algorithm to process the initialization mode of the connection on the FMU artificial or “real” algebraic loop. 】

An additional limitation of the “slaveInitialized” state is that the fmi2GetXXX function is not allowed to be called after the fmi2SetXXX function without the fmi2DoStep call.

In contrast to the model swap type OF FMI, the fmi2DoStep function of the co-emulation performs the actual calculation rather than using the fmi2GetXXX function to avoid different interpretations of the cache. Therefore, the sequence of fmi2GetXXX and fmi2SetXXX invoked during model exchange cannot process the virtual algebraic ring at the communication point.

Iv. FMU CoSimulation

1. Label definition

The label definition of the co-simulation function in the model description file is as follows:

Related structures are as follows:

  • CoSimulation
    • ModelIdentifier: Abbreviation of the class name
    • NeedsExecution: Decide whether an external tool is needed to execute the model
    • CanHandleVariableCommunicationStepSize: from the node can process variable step length of communication. For each calibration, the communicationStepSize (the argument communicationStepSize of the fmi2DoStep function) need not be fixed with each call
    • CanInterpolateInputs: Interpolates continuous inputs from nodes
    • MaxOutputDerivativeOrder: Output derivatives of the largest order that can be provided from a node
    • CanRunAsynchronuously: asynchronous
    • CanBeInstantiatedOnlyOncePerProcess: single FMU single instance (if it requires multiple instances must be in the process of different instantiation FMU)
    • CanNotUseMemoryManagementFunctions: if it is true, is from the function of node to use their own memory allocation and release; Ignore the callback functions allocateMemory and freeMemory given in fmi2Instantiate
    • CanGetAndSetFMUstate: if it is true, then the simulation environment can query and restoring the state of internal FMU (namely support fmi2GetFMUstate, fmi2SetFMUstate, fmi2FreeFMUstate)
    • CanSerializeFMUstate: If it is true, then the simulation environment can serialize internal FMU state, namely the FMU support fmi2SerializedFMUstateSize fmi2SerializeFMUstate, fmi2DeSerializeFMUstate. If this is the case, the flag canGetAndSetFMUstate must also be true.
    • ProvidesDirectionalDerivative: if it is true, can use when communication point fmi2GetDirectionalDerivative (..) Compute the directional derivative of the equation.
    • SourceFiles: resource file

Example 2.

<? The XML version = "1.0" encoding = "UTF8"? > < fmiModelDescription fmiVersion = "2.0" modelName = "MyLibrary. SpringMassDamper" Guid ="{8C4E810F-3DF3-4A00-8276-176FA3C9F9E0}" Description ="Rotational Spring Mass Damper System" version="1.0" generationDateAndTime="2011-09-23T16:57:33Z" variableNamingConvention="structured"> <CoSimulation modelIdentifier="MyLibrary_SpringMassDamper" canHandleVariableCommunicationStepSize="true" canInterpolateInputs="true"/> < unitName > <Unit name="rad"> <BaseUnit rad="1"/> <DisplayUnit name="deg" factor="57.2957795130823"/> </Unit> <Unit name="rad/s"> <BaseUnit s="-1" rad="1"/> </Unit> <Unit name="kg.m2"> <BaseUnit kg="1" m="2"/> </Unit> </UnitDefinitions> <TypeDefinitions> <SimpleType name="Modelica.SIunits.Inertia"> <Real quantity="MomentOfInertia" Unit ="kg.m2" min="0.0"/> </SimpleType> <SimpleType name=" modelica.siunits. Torque"> <Real quantity="Torque" unit="N.m"/> </SimpleType> <SimpleType name="Modelica.SIunits.AngularVelocity"> <Real quantity="AngularVelocity" unit="rad/s"/> </SimpleType> <SimpleType name="Modelica.SIunits.Angle"> <Real quantity="Angle" unit="rad"/> </SimpleType> </TypeDefinitions> <DefaultExperiment startTime="0.0" stopTime="3.0" tolerance="0.0001"/> <ModelVariables> <ScalarVariable name="inertia1.J" valueReference="1073741824" description="Moment of load inertia" causality="parameter"  variability="fixed"> <Real declaredType="Modelica.SIunits.Inertia" start="1"/> </ScalarVariable> <ScalarVariable name="torque.tau" valueReference="536870912" description="Accelerating torque acting at flange (= -flange.tau)" causality="input"> <Real declaredType="Modelica.SIunits.Torque" start="0"/> </ScalarVariable> <ScalarVariable name="inertia1.phi" valueReference="805306368" description="Absolute rotation angle of component" causality="output"> <Real declaredType="Modelica.SIunits.Angle" /> </ScalarVariable> <ScalarVariable name="inertia1.w" valueReference="805306369" description="Absolute angular velocity of component (= der(phi))" causality="output"> <Real declaredType="Modelica.SIunits.AngularVelocity" /> </ScalarVariable> </ModelVariables> <ModelStructure> <Outputs> <Unknown index="3"/> <Unknown index="4"/> </Outputs> <InitialUnknowns> <Unknown index="3"/> <Unknown index="4"/> </InitialUnknowns> </ModelStructure> </fmiModelDescription>Copy the code

Five, the conclusion

Model exchange refers to a portable and callable mathematical model library generated by a simulation instance (in line with the definition of FMI interface) in the same simulation environment. Co-simulation means that the input and output of different simulation environments (distributed or cross-tool) are defined according to FMI standards, and data is transmitted through Master Algorithm (SSP, DCP) for collaborative calculation.

Functional Mock-up Interface forModel Exchange and Co-simulation V2.0