Changes to "SIL ECU Profile"

[chrbertsch]

Move to "recommended":

• Store/Restore FMU State
• Source Code FMUs
• Binary FMUs for non-Desktop Platforms (e.g. HiL)
• Scheduled Execution Interface

[andreas-junghanns]

Move to "recommended":

• Resizable Input/Output Arrays: apart from few tools being able to change IO during runtime, what would be the use case?

[pmai]

Proposal from design meeting 2022-06-27:

• Downgrade scheduled execution to recommended

• Downgrade Store/Restore FMU State to recommended

• Remove resizable I/O arrays from all profiles for now

[MBlesken]

"New Integer Types" have to be supported anyway, we can remove this. (#44)

[MBlesken]

Why limit it to "SIL"? What's the difference for "HIL ECU profile"?

[MBlesken]

Actually if this is about " .. integration of multi-ECU networks" bus access should be supported (i.e. the ls-bus). And a ECU sw developer would most likely expect that he/she can access parameters via XCP service (-> ls-XCP) Do we refer to the layered standards?

[chrbertsch]

Discussion: Pierre: Perhaps Variable communication stepsize could be optional Pierre: We could drop the "ECU" part, SIL could require variable stepsize, Matthias: an ECU profile could support SIL/HIL Matthias: We could remove the platform stuff from the features Kaska: Are resizable parameter arrays necessary? Patrick: I agree Matthias: For an ECU profies you would need clocks Christian: Name: XiL profile? Mention ECU? Pierre: We could reserve this for more special use cases, e.g. requring certain layered standards.