Reintroduce the idea of expandable connectors for signal buses

[tobolar]

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).

[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.

[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!!

[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?

[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.