modelica / vehicleinterfaces

Free (standard conforming) library for interface definitions and architectures for vehicle system modeling

VehicleInterfaces Library

Free library from the Modelica Association for interface definitions and architectures for vehicle system modeling

Build status

Library description

This Modelica library provides standard interface definitions for automotive subsystems and vehicle models. These are designed to promote compatibility between the various automotive libraries and provide a flexible, powerful structure for vehicle modelling. The main focus of the library is on defining the interfaces for the individual subsystems and a number of vehicle model examples are included to demonstrate how they might be used.

For an automotive library to be compatible with other libraries based on this set of interface definitions they should extend the interface definition from within this library and following the naming convention for the signal bus.

This library also contains a proposal for a naming convention covering the whole model library and the developers of this library would recommend that this convention is followed by other developers to ensure a consistent naming convention across the whole set of automotive models.

Current release

Download VehicleInterfaces v2.0.1 (2022-03-15)

Older releases

Browse the Releases page in order to get access to older releases of the library.

License

Copyright © 2005-2013, Dassault Systémes, DLR and Modelon
Copyright © 2013-2022, Modelica Association

This Modelica package is free software and the use is completely at your own risk; it can be redistributed and/or modified under the terms of the Modelica License 1.1.

Development and contribution

The development is organised by individual members of the Modelica Association.

You may report any issues with using the Issues button.

Contributions in shape of Pull Requests are always welcome.

vehicleinterfaces's Issues

Hide usingMultiBodyXXX when the corresponding includeXXXBearing is set to true

The usingMultiBodyXXX parameters are always used in combination in an OR statement with their close friends includeXXXBearing.
Because of this, if the developer sets includeXXXBearing (that is protected) to true, automatically the user choice on usingMultiBodyXXX will make no difference: because of the OR statement the logical results will always be true.

Because of this, leaving usingMultiBodyXXX exposed to the user might mislead him to think that he can still disable the Bearings by setting usingMultiBodyXXX=false while he actually cannot.
Wouldn't be better to hide usingMultiBodyXXX using annotation(Dialog(enable=not includeXXXBearing))?

Remove revisions from VehicleInterfaces.UsersGuide.Contact

In order to simplify the maintenance of the library, I would suggest to delete the years range from the copyright information contained in 'Revisions' of VehicleInterfaces.UsersGuide.Contact. Or even better to delete that Revisions completely since the relevant piece of information is already given on the main page of the library, e.g. VehicleInterfaces.

Any suggestions?

MultiBodyEnd purpose

I would like to understand why MultiBodyEnd blocks are needed (for example, in the chassis of the FrontWheelDriveManualVehicle) since they just add zero force and torque... Were they intended to allow simulation of isolated components of models?

Remove uses of __Dymola_choicesFromPackage annotation

The tool-specific annotation __Dymola_choicesFromPackage is used in the classes VehicleInterfaces.DriverEnvironments.DriveByWireAutomatic and VehicleInterfaces.Drivers.MinimalDriver

Add milestones and labels

As proposed by @tobolar, add milestones and labels for VehicleInterfaces issues

Backward compatibility is not given

In my opinion, a backward compatibility is only given if there are no classes removed from a library.
But since Version 1.2.2, "...removal of Dymola specific visualization" applies and, thus, the backward compatibility is no more given.
I think a more user-friendly solution were to mark deleted classes as obsolete and delete them at the earliest in a non backward compatible version, i.e. 2.0.0.

Solution for now:

• either the library should have another version number (non backward compatible version) or
• a patch should be released including the particular classes deleted previously.

VehicleInterfaces.Drivers.MinimalDriver cannot be instantiated

Instantiating the VehicleInterfaces.Drivers.MinimalDriver should be possible, right?
Instead I get:

[VehicleInterfaces.Drivers: 183:5-188:31]: Failed to instantiate equation 
connect(brakePosition.flange_b, driverInterface.brakePedal) annotation(Text(string = "%second", index = 1, extent = {{6, 3}, {6, 3}}));.

The same happens also while running one of the examples with the VehicleInterfaces.Drivers.MinimalDriver e.g. VehicleInterfaces.Examples.ConventionalAutomaticVehicleExternalDriver

The issue arises both with OpenModelica v1.13.0 version of VehicleInterfaces and the GitHub VehicleInterfaces at commit be62651

Replace "fake" enumerations with enumerations in VehicleInterfaces.Types

The classes VehicleInterfaces.Types.GearMode and VehicleInterfaces.Types.IgnitionSetting use Integer constants and a choices annotation in order to behave like an enumeration. This is due to enumerations not being fully supported at the time of original development.

Enumerations are now generally supported in tools so these should be updated (at a major release).

Reintroduce the idea of expandable connectors for signal buses

The current approach with replaceable bus instances in models counteract the idea of expandable connectors.
Currently, signal bus connectors from VehicleInterfaces.<assembly>.Interfaces are always instantiated as replaceable in particular assembly models. This was introduced years ago. But actually this contradicts the idea of expandable connectors. Moreover, it makes problems in more complex vehicle architectures because then all bus connectors of an assembly should be of the same definition. This means to replace a plenty of connectors for a particular architecture.
The proper solution is to use "empty" bus connectors from VehicleInterfaces.Interfaces across the library as was the case in the early versions.

See also comments in #19 (and #17).

Incorporate FlangeWithBearingAdaptor in models with FlangeWithBearing

The Modelica.Mechanics.MultiBody.Interfaces.FlangeWithBearingAdaptor should be used if possible to connect Modelica.Mechanics.MultiBody.Interfaces.FlangeWithBearing with 1D flange or multi-body frames.
Following models are possible candidates:

• VehicleInterfaces.Brakes.MinimalBrakes
• VehicleInterfaces.Brakes.MinimalBrakesUsingPedal
• VehicleInterfaces.Chassis.MinimalChassis3

Illegal inheritance in VehicleInterfaces\Icons.mo

The Modelica class of VehicleInterfaces.Icons.VariantLibrary (class) and its base class Modelica.Icons.VariantsPackage (package) are not compatible.

The Modelica class of VehicleInterfaces.Icons.BaseClassPackage (class) and its base class Modelica.Icons.BasesPackage (package) are not compatible.

See, e.g., MarekMatejak/Physiolibrary#8 for how to fix this issue.

Remove duplicated variable "currentGear" from Interface.TransmissionControlBus

As discussed in #17, the integer variable currentGear should be deleted from VehicleInterfaces.Interfaces.TransmissionControlBus in the next major version. It is defined in VehicleInterfaces.Transmissions.Interfaces.StandardControlBusas well which is actually the right place according to the library standards.

Error in VehicleInterfaces.Mechanics.NormalisedTranslational.Interfaces.Flange documentation

From documentation check:
Error: The class Modelica.Mechanics.Translational.Interfaces.flange_a is referenced in the URL modelica://Modelica.Mechanics.Translational.Interfaces.flange_a but could not be found

Rename connector motorFlange in BaseTwoInputTransmission

Based on the comment of christiankral in Modelica Standard Library issue 340, the electric drive connector motorFlange in VehicleInterfaces.Transmissions.Interfaces.BaseTwoInputTransmission should be better renamed to machineFlange or electricDriveFlange.

Roads.Interfaces.Base functions are not constrained to be of the type declared in Roads.Interfaces

I have a doubt that, if you confirm, can be an issue.

Look at Roads.Interfaces.Base. There are 5 variables (position, trackOffset, etc...).
These 5 variables are of type replaceable function thus can be replaced by any class that extends function.

The question is: is this the intended behaviour? Shouldn't these variable be constrained to be of type Roads.Interfaces.positionBase instead of the more general function?
Shouldn't they be declared as
replaceable VehicleInterfaces.Roads.Interfaces.positionBase position;
for example?

Split library into single files

Following the decission done in modelica/ModelicaStandardLibrary#2975, packages in VI shall be splitted into single files for each model.

Units error (or incompatibiity?) in VehicleInterfaces\Engines\MinimalEngine.mo: r/min vs 1/min

I'm a new user of Modelica and the VehicleInterfaces package.

I'm using OpenModelica v1.18.0 (64bit) and VehicleInterfaces v2.0.0 on Windows 10.

When trying to simulate the VehicleInterfaces\Examples\SeriesHybrid.mo model, there is an error related to the "r/min" displayUnit (line 10).

I edited the file manually and changed this to "1/min" and it now works for me.

I've no idea whether this is a typo or whether it's a version incompatibility, but hopefully it'll help someone else even if the latter.

UsersGuide.DriverInteractionBus have misleading engineSpeed and vehicleSpeed descriptions

In the UsersGuide.DriverInteractionBus's naming convention table the measurement units for engineSpeed and vehicleSpeed have ambiguous descriptions.

engineSpeed | rad/s | Engine speed in rpm
vehicleSpeed | m/s | Vehicle speed in km/h

in both Drivers.Internal.StandardDriverInterfaceFor<Manual|Automatic>Transmission and Engines.MinimalEngine the engine angular speed is considered as rad/s.

Anyway, I think it's worth to make things to match. And probably, to the user interface rpm is actually the preferred choice.

CheckContactCalculation and other Roads.Internal models fail in OpenModelica

Models contained inside Roads.Internal suggest that something is not working properly.
Any Check_____ function report the following error:

[1] 11:08:04 Translation Warning
[VehicleInterfaces.Roads: 479:7-479:57]: No corresponding 'inner' declaration found for component .VehicleInterfaces.Roads.Interfaces.Base road.roadShape.road declared as 'outer '.
  The existing 'inner' components are:
    .Modelica.Mechanics.MultiBody.World$world world; defined in scope: VehicleInterfaces.Roads.Internal.CheckContactCalculation. Referenced by 'outer' components: {road.world}
  Check if you have not misspelled the 'outer' component name.
  Please declare an 'inner' component with the same name in the top scope.
  Continuing flattening by only considering the 'outer' component declaration.

[2] 11:08:04 Translation Error
[VehicleInterfaces.Roads: 173:5-231:13]: Illegal to instantiate partial class Base.

[3] 11:08:04 Translation Error
Error occurred while flattening model VehicleInterfaces.Roads.Internal.CheckContactCalculation

It seems that those components (such as DummyTyre) that require an inner declaration of road are not connecting to the inner declaration that is actually found in Check______ models.

But here is the thing: I suppose that probably the error is in Internal.VisualizeSimpleRoads @480 at the line outer VehicleInterfaces.Roads.Interfaces.Base road;.

Commenting it, everything works fine.

I didn't make a Pull Request, because I'm not sure of the solution.

Restructure examples in Roads

The examples collected in Roads.Internal (CheckContactCalculation, etc.) shall be moved into a particular package Roads.Examples. As a consequence, model Roads.Internal.DummyTyrehas to be moved into Roads.Examples.Utilities.

I have a question.

I am new to OpenModelica and was looking for OpenModelica car models and found this site.
I would like to simulate getting the following data, is it possible?
・Speed of a car
・Acceleration performance of a car
・Deceleration performance of a car
・Fuel consumption of a car,etc.
I could not find an appropriate place to ask this question, so I asked it here.
If there is another appropriate place, please let me know and I will move it.

Relicense under BSD 3-clause?

VI is currently under the Modelica License 1.1 with the MA as copyright holder. The MSL switched its license since 3.2.3 to BSD 3-Clause which is almost identical with the not so well known and outdated Modelica License 1.1.
I think it would be a clean solution to have the next major version be published under the same BSD 3-Clause license as the MSL.

Delete obsolete classes

Classes being marked obsolete in v1.2.5 can be removed now:

• Blocks.RealPassThrough
• Blocks.IntegerPassThrough
• Blocks.BooleanPassThrough
• Icons.VariantLibrary
• Icons.BaseClassPackage

Modify conversion script accordingly.

Change Greek parameter name 'mue' to 'mu'

Spell Greek letter for m (µ) correctly: mu instead of mue. See similar issue modelica/ModelicaStandardLibrary#194.

Rename includeAccessoriesBearing

Similar to PR #46, protected parameter includeAccessoriesBearing in Accessories.Interfaces.Base shall be renamed to includeEngineBearing.

Load torque parameter description misleading

Hi, in vehicle interfaces there is a model with path: VehicleInterfaces.Accessories.MinimalAccessories

The parameter

parameter Modelica.SIunits.Torque accessoriesLoad=2
"Total effective torque load due to the accessories (constant)

implies that you should provide a positive torque for the load. Within the model the torque sign should be made negative when used in the torque actuator otherwise this model actually converts a torque load to a torque gain.

It is my suggestion that the torque actuator should reference -accessoriesLoad rather than accessoriesLoad.

Many thanks,
Alex

Layout of road functions in Roads.Interfaces.Base

The VehicleInterfaces.Roads.Interfaces.Base is used as the base for many roads. These roads add in many other parameters and replaceable functions so it would be good to group the road functions in Base into a Tab to tidy up the layout of these functions. The description strings could also be improved and I think adding choicesAllMatching makes modifying these replaceable functions easier.

So I would like to propose that the road functions in Base be replaced with the following code.

  replaceable function position = VehicleInterfaces.Roads.Interfaces.positionBase
    "Function to get position at a road position" annotation (
    choicesAllMatching=true,
    Dialog(tab="Functions"),
    Documentation(info="<html>
<p>
The road position function returns the world location of the road location (s,w).
</p>
</html>"));
  replaceable function trackOffset = VehicleInterfaces.Roads.Interfaces.trackOffsetBase
    "Function to get position at a driving line position" annotation (
    choicesAllMatching=true,
    Dialog(tab="Functions"),
    Documentation(info="<html>
<p>
The track offset function returns the location of the driving line location (s,w).  This location can either be relative to the road centre line or in world coordinates.
</p>
</html>"));

  replaceable function normal = VehicleInterfaces.Roads.Interfaces.normalBase
    "Function to get road normal at a road position" annotation (
    choicesAllMatching=true,
    Dialog(tab="Functions"),
    Documentation(info="<html>
<p>
The normal function returns the normal of the road surface at (s,w).
</p>
</html>"));

  replaceable function headingDirection = VehicleInterfaces.Roads.Interfaces.headingDirectionBase
    "Function to get heading direction at a road position" annotation (
    choicesAllMatching=true,
    Dialog(tab="Functions"),
    Documentation(info="<html>
<p>
The heading direction function returns the direction in which the road is going at (s,w).
</p>
</html>"));

  replaceable function frictionCoefficient = VehicleInterfaces.Roads.Interfaces.frictionCoefficientBase
    "Function to get friction coefficient at road position" annotation (
    choicesAllMatching=true,
    Dialog(tab="Functions"),
    Documentation(info="<html>
<p>
The frictionCoefficient function returns the friction coefficient of the road at (s,w).
</p>
</html>"));