Commit 1e85cc6a authored by Michael Kluge's avatar Michael Kluge
Browse files

Added first draft of feature set chapter.

parent 7dc19ef2
Pipeline #906 passed with stage
in 14 seconds
......@@ -26,6 +26,23 @@ Provide a detailed description, how the identified usecases, features or issues
The technical content description shall be understandable for readers with an engineering background, but with no specific domainexpertise. Consequently, a brief technical introduction may be needed.
==== Portability
Based on the presentation by Michael Kluge (dSPACE) from[ASAM OpenSCENARIO V2.0 - Proposal Workshop, Topic 6]. Please move chapter to suitable location if necessary.
The definition of a new standard/language OpenSCENARIO 2.0 should aim for a widest possible acceptance in its domain. This is true for every standard, but might be even hard to achieve because of the special circumstances. The support of the wide set of use cases and requeriments will result in an extremly capable language. This will allow the language to be used in many different projects, but comes with the trade off of limited portability/exchangeability. It will be very hard for players in simulation domain to state "We support OpenSCENARIO 2.0" as this support will very likely be limited to some parts of the language.
Car manufacturers for example will work with multiple different suppliers and would like to use OpenSCENARIO 2.0 as one of the exchange formats. The selection of those suppliers relies on their credible statement on how they support the standard e.g. in their simulation environment.
*The standardization project should enable partial support of the standard.* This on the one hand allows companies to step by step improve their compatibility to the standard and on the other hand enables proper selection of project partners.
image:../images/featureSets.png["Feature Sets Proposal"]
The __feature sets__ proposed in picture <<feature_sets_image>> might be an option for a segmentation of the standard to achieve optional partial support. It has still to be discussed how those __feature sets__ should be defined and how they can be integrated in the standard. If a separate working will be defined to tackle those questions, a close interaction with at least the domain model, the use cases and the language working groups is highly advisable. The definition of a __core feature set__ might be helpful to define a basis all supporting parties commit to.
Additionally the planned migration path from the already published[OpenSCENARIO 1.0 standard] has to be considered.
==== Domain Model
===== Entity Definition
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment