Add link to VSC in the VSS documentation

[gunnarx]

Tom, Paul, myself and others discussed and it was recognized that the relationship between VSS and VSC tend to pop up, and also people seem to need an understanding of the scope limits of VSS.

Therefore, we propose to link to VSC early in the VSS documenation.

A brief sentence like: "VSS is intended for data exchange between system components (in-vehicle and/or cloud), although a few signals (actuators) may in principle trigger some action. For more advanced system interaction, service-definition, and remote-procedure-call semantics, we recommend looking at the sister-project VSC" (link)

[danielwilms]

In general I support the idea, but we have to find an answer on how those to projects are playing together. As long as we're redefining signals in VSC, I think it's too confusing and too early to link those two project officially.

[SebastianSchildt]

Yes, I would agree. In my personal view VSC only makes sense once it can integrate/connect all of VSS (by having a canonical way to wrap signals in to services/getter/setters/vsc input/output datatypes) and then of course offering modelling more complex services on top (that is what VSC is needed for).

Then we could also easily have a vss2vsc converter as a kickstart into VSC world and link it.

I am not very deep into VSC, but my understanding is, that currently it is not stabilised enough to even know, what kind of format a vss2vsc tooling might need to generate exactly? I may be wrong @gunnarx ? @erikbosch ?