Reintroduce the idea of expandable connectors for signal buses about vehicleinterfaces

[harmanpa]

Embarrassingly, I now realise that is how it is described in the original paper from 2006, of which I'm one of the authors!!

[harmanpa]

This change needs to be in v2.0.0 because it needs a conversion script to change instances of VehicleInterfaces.<assembly>.Internal.* or VehicleInterfaces.<assembly>.Interfaces.* to VehicleInterfaces.Interfaces.*.
I think we should release v1.2.5 now with recent changes, and then consider master to be v2.0.0 and make bigger changes.

[harmanpa]

Reducing/minimising the number of bus definitions would definitely be good. We need to ensure that it is still convenient for the user when building models - for the majority of cases it should be easy to connect to a signal in a bus without having to use dialogs to "add variable" or going into the source code.

[harmanpa]

It would be good for @mdempse1 to be part of this discussion as original developer and major user of the library

[tobolar]

IMO the proper usage is as follows:

1. There are defined empty control busses in VehicleInterfaces.Interfaces which should be instantiated in the components.
2. In the Internal subpackages of particular assemblies (e.g. Brakes.Internal), there are defined signals to be connected in the components. These signals are just dummies, there is generally no problem when not connected. These control busses shall not be instantiated. They are just used as predefined signals in an item list once a signal is connected to a bus in the Diagram.
3. That list of signals on a bus is composed from signals of all busses which currently extend from the concerned bus.

[harmanpa]

If the bus in Internal is not instantiated, does the bus that is instantiated extend from it?

[tobolar]

This is right an opposite case. The busses in Internal subpackages must all extend from a bus in VehicleInterfaces.Interfaces. Thus, a link is introduced between the busses when the list of signals is assembled in Diagram.

[harmanpa]

Understood, yes that is a tidy way of doing things.

[mdempse1]

I think the use of replaceable on the bus connectors within all the example models is unnecessary and it would clean things up to remove them. It wouldn't impact any of our libraries as we don't use these examples in the VeSyMA libraries.

If the user wants to extend the list of available signals then they could follow the design pattern established in VI and extend from the connector in VehicleInterfaces.Interface and add all the signals they need to use.

What are we losing, if anything, by making this change?

[tobolar]

To be sure we trigger no possible conflict in a user's model, signal bus connectors in VehicleInterfaces.<assembly>.Internal should include all signals of busses in VehicleInterfaces.<assembly>.Interfaces. May be this is fulfilled already but I will check.

But how to proceed in a best way? Should we reimplement this for comming v1.2.5 (which will be compatible to MSL v.3.2.3) or should we start non backward compatible v2.0.0 - which IMO is a safe way?