Commit b976ec21 authored by Sandeep Pendharkar's avatar Sandeep Pendharkar
Browse files

Merge branch 'master' into 'sandeep-updates-for-wp-up-transfer1x'

# Conflicts:
#   subchapters/2_technical-content.adoc
parents 3dbcbd27 dc81939b
Pipeline #1355 passed with stage
in 15 seconds
......@@ -50,29 +50,29 @@ Additionally, the planned migration path from the already published https://www.
==== Domain Model
OSC lies within the domain of closed-loop system testing for automotive functions. The Domain Model introduces domain-specific content to the otherwise generic Language Concept of OSC 2.0. The domain model provides the semantics, whereas the Language Concept delivers the syntax. Therefore, the Domain Model enables the preservation of semantics when scenario definitions are exchanged between different tools.
The OpenSCENARIO standards target the domain of closed-loop system testing for automotive functions. A Domain Model provides the semantics for the terms that are used in the Language component of OSC 2.0. In particular, an explicit specification of the Domain Model, e.g. in the form of a DL ontology, enables the preservation of semantics when scenario definitions are exchanged between different tools.
The <<Entity Definition>> builds the core of the Domain Model. This definition should cover all objects that are necessary to describe a wide range of relevant scenarios. The definitions of the identified entities should be unambiguous and should include the main properties and possible actions of each entity. The development of the entity definition will follow two tracks. First, the existing domain model of OSC 1.0 needs to be analyzed and transferred to OSC 2.0 to ensure compatibility between the two versions of the standard. Second, the already identified gaps in OSC 1.0 need to be closed by extending the Domain Model.
The <<Entity Definition>> work package provides the foundation of the Domain Model. This definition should cover all of the entities that are necessary to create scenarios according to the requirements identified in the concept document. The definitions must be unambiguous and include the characteristic properties and possible actions of each entity. The development of the entity definition will follow two tracks. First, the existing entity definitions of OSC 1.0 will be analyzed for migration to OSC 2.0 to ensure compatibility between the two versions of the standard. Second, the already identified gaps in OSC 1.0 will be closed by extending the Domain Model with additional entity definitions.
It will neither be possible nor meaningful to try to attempt to cover all possible scenarios and simulators with the entity definition of OSC 2.0. Therefore, a technical concept on a standard-conform <<Extensibility>> of the Domain Model needs to be developed.
It will neither be possible nor meaningful to try to attempt to cover all possible scenarios and simulators with the entity definition of OSC 2.0. Therefore, a technical concept on a standard-conform <<Extensibility>> of the Domain Model needs to be developed.
Another pillar of the Domain Model is the definition of the relationships between the entities with predicate logic. Such an <<Ontology>> will support an unambiguous formulation and categorization of scenarios as it enables inferrment with natural language.
As identified in the concept document, the Domain Model for OpenSCENARIO 2.0 should be specified using some form of predicate logic in order to achieve maximum clarity and portability. This is particularly important for defining the types of relationships that can hold between entities. The <<Ontology>> work package provides this formal specification of the Domain Model in the form of an ontology, possibly using one of the description logics supported by the W3C OWL standard. Having the Domain Model expressed as a formal ontology enables the use of reasoning software for classifying and matching scenario descriptions as well as providing a basis for computer inference that can assist human authors in creating scenario descriptions in natural language that are logically coherent and semantically valid.
===== Entity Definition
[NOTE]
Responsibles for filling this sub-chapter: J. Tscheak (maybe), M. Kluge, J.Kaths, F. Bock (maybe), S. Rosenberg (maybe)
Persons responsible for filling this sub-chapter: M. Kluge, S.Kraines
The definition of the domain model specific entities is essential as they build the vocabulary of the new language. A full support of the https://www.asam.net/standards/detail/openscenario/#[OpenSCENARIO 1.0 standard], which has already been released by ASAM, is one major requirement for OpenSCENARIO 2.0. This includes a full migration path from the 1.x versions to the language to be developed in this project, which directly leads to the first work packages for the domain model group:
Clear and unambiguous definitions of all of the key entities in the Domain Model are essential for providing the semantics for the vocabulary of the new domain specific language. One major requirement for OpenSCENARIO 2.0 given in the concept document is full support of the https://www.asam.net/standards/detail/openscenario/#[OpenSCENARIO 1.0 standard], which has already been released by ASAM. This includes a full migration path from the 1.x versions to the domain specific language to be developed in OpenSCENARIO 2.0, to be delivered by WP_DM1_Transfer1x.
*WP_DM1_Transfer1x*
The domain model, that has been defined in the https://www.asam.net/index.php?eID=dumpFile&t=f&f=3460&token=14e7c7fab9c9b75118bb4939c725738fa0521fe9[OpenSCENARIO 2.0 Concept Project], did not focus on the compatibility to OpenSCENARIO 1.0. However, OpenSCENARIO 1.0 already contains multiple domain model entities, for which possible deviations to the new model have to be identified. For each of those deviations it has to be defined how they should be handled in order to achieve compatibility. Inconsistent naming and terminology has to be resolved or, if this is not feasible, a mapping between entities in both models has to be defined. All entities in the 1.0 model must have a counterpart in 2.0.
The entity definitions given for the Domain Model in the concept document (https://www.asam.net/index.php?eID=dumpFile&t=f&f=3460&token=14e7c7fab9c9b75118bb4939c725738fa0521fe9[OpenSCENARIO 2.0 Concept Project]) did not address support for OpenSCENARIO 1.0. OpenSCENARIO 1.0 already contains multiple definitions for entities, which may not be compatible with the entity definitions given in the OpenSCENARIO 2.0 concept document. All entities in the 1.0 model must have a counterpart in 2.0. Inconsistencies in naming and scope must be resolved or, if this is not feasible, a mapping between entities in both models has to be defined.
[NOTE]
Identify entities and their actions / methods that are introduced by high-level description of OSC 2.0 (so not part of OSC 1.0) (maybe Florian Bock, Michael Kluge, Jakob Kaths, maybe Sharon Rosenberg)
*WP_DM2_Extend2x*
The need to extend the domain model of OSC 1.0 has been identified in the initiation phase of OSC 2.0. The model draft of the OSC 2.0 concept project provides an initial draft for such an extension. During the development of OSC 2.0, it needs to be refined and extended, as the result of the concept project focused on "most important properties, attributes, possible actions and interrelations.". New entities, their actions and attributes have to defined, for example to cover high-level scenario descriptions, which will be introduced in OpenSCENARIO 2.0. All different use cases for the scenario definition and contents from the 1.0 domain model have to be properly integrated in the final model for 2.0. As experienced in the OSC 2.0 concept project, a close working-level interaction and interrelation with the language group is essential for the success of this work package. This needs to be established already in the beginning of the project.
The need to extend the entity definitions of OSC 1.0 has been identified in the initiation phase of OSC 2.0. The OSC 2.0 concept document provides an initial draft for such an extension. This extension will be refined by focusing on "most important properties, attributes, possible actions and interrelations." All different use cases for the scenario definition in OSC 1.0 must be properly handled by the OSC 2.0 domain specific language. In addition, new entities must be defined, together with their actions and attributes, e.g. to cover the high-level scenario descriptions to be introduced in OpenSCENARIO 2.0. Drawing from experiences in the OSC 2.0 concept project, the team developing this work package will interact closely with the language group.
===== Extensibility
Responsibles for filling this sub-chapter: S. Rosenberg, H. Bothe (maybe)
......@@ -83,15 +83,29 @@ WP DM-Extensibility - Develop technical concept for extensibility of Domain Mode
* possibly introduce mandatory / optional
* align with WP modules, libraries, etc.
* Add an attribute to a standard actor, action or struct
* Add a user defined actor
* Add a user-defined action to a standard actor
* Add other needed entities
On top of addition extensions, user may want to ignore parts of the domain model which are not relevant may not be interesting for his ODD or project needs.
Later, these new extensions be efficiently leveraged for automated user-defined scenarios.
===== Ontology
Responsibles for filling this sub-chapter: F. Sanchez, I. Whiteside, P. Parekh, S. Kraines (maybe), M. Nieto (maybe)
WP DM-Ontology - Develop ontology to establish relations between entities
* synchronize with global ontology developed by ASAM
* what are the technical artifacts that come out of the ontology development
* Fran (FiveAI) can contribute, FiveAI developed own ontology for scenario description
* Iain Whiteside (FiveAI) can provide a presentation on practical usage of their ontology
* UK has developed a standard (or a PAS really) called 1883 for a driving ontology (Siddhartha could help here)
* possible input as well from Steven and Florian Bock (Audi)
[NOTE]
Persons responsible for filling this sub-chapter: S. Kraines, I. Whiteside
This work package will to leverage the outcomes of the OpenX Ontology project in order to provide a clear and unambiguous conceptual foundation for the OSC2.0 Domain Model. It is envisaged that some form of description logic will be applied and that lessons will be drawn from existing applications of ontologies in industry. Technologies to be evaluated in the work package include upper level ontologies, W3C standards, reasoning engines, and authoring tools.
Deliverables:
- definitions of main OSC2.0 terms using concepts and relationships from the OpenX Ontology
- guidelines for how to use semantic inference to classify and match scenario descriptions based on their meaning
- guidelines for how to implement computer reasoning to identify semantic errors in scenario definitions
- guidelines for how to use computer reasoning to assist people in creating abstract-level scenarios that are complete and logically coherent
==== Language Concepts
......
=== Work Packages
A breakdown of the project into individual work packages and the corresponding effort required to complete them. Effort should be given in man-hours.
==== Language Concepts
.LC-Syntax
.LC-BasicTypes
[cols="1,5",caption='WP {counter:wp1}: ']
|===
|*Description* | Syntax definition of the OpenSCENARIO 2.0 language
| *Responsibles* | R. Hadar
|*Deliverable* | Full syntax definition, including grammar, of the OpenSCENARIO 2.0 language. Basic building blocks are file organization, type definitions, compound type definitions and their internals, temporals, behavior description and expressions. Integration of the other WG syntax definition into a single syntactic entity that shares the same look and feel.
| *Effort* | 35 man-days
| *Service Provider* | Documentation of language syntax. ~25% of effort.
|*Description* | Basic data types for OpenSCENARIO 2.0
This WP will address the semantic description of the basic generic datatypes (integers, booleans, floats, enums), domain specific physical types (such as speed, distance and angle) with their corresponding units. We will talk about implicit and explicit type conversions.
| *Responsibles* | Sharon Rosenberg
|*Deliverable* | Semantic description of the definition of all basic, i.e. non-compound data types of the OpenSCENARIO 2.0 language. Input for LC-Syntax on syntax aspects of the basic data types.
| *Effort* | 100 man-days
| *Service Provider* | Documentation of basic types parts of the specification. ~25% of effort.
|===
.LC-CompoundTypes
......@@ -25,19 +29,6 @@ This WP will address the semantic description of the compound datatypes (structs
| *Service Provider* | Documentation of compound types parts of the specification. ~25% of effort.
|===
.LC-BasicTypes
[cols="1,5",caption='WP {counter:wp1}: ']
|===
|*Description* | Basic data types for OpenSCENARIO 2.0
This WP will address the semantic description of the basic generic datatypes (integers, booleans, floats, enums), domain specific physical types (such as speed, distance and angle) with their corresponding units. We will talk about implicit and explicit type conversions.
| *Responsibles* | Sharon Rosenberg
|*Deliverable* | Semantic description of the definition of all basic, i.e. non-compound data types of the OpenSCENARIO 2.0 language. Input for LC-Syntax on syntax aspects of the basic data types.
| *Effort* | 100 man-days
| *Service Provider* | Documentation of basic types parts of the specification. ~25% of effort.
|===
.LC-Expressions
[cols="1,5",caption='WP {counter:wp1}: ']
|===
......@@ -50,17 +41,38 @@ This comprises the generic parts of expressions (e.g. arithmetic, logic, etc.) b
| *Service Provider* | Documentation of expression language parts of the specification. ~25% of effort.
|===
.LC-Syntax
[cols="1,5",caption='WP {counter:wp1}: ']
|===
|*Description* | Syntax definition of the OpenSCENARIO 2.0 language
| *Responsibles* | R. Hadar
|*Deliverable* | Full syntax definition, including grammar, of the OpenSCENARIO 2.0 language. Basic building blocks are file organization, type definitions, compound type definitions and their internals, temporals, behavior description and expressions. Integration of the other WG syntax definition into a single syntactic entity that shares the same look and feel.
| *Effort* | 100 man-days
| *Service Provider* | Documentation of language syntax. ~25% of effort.
|===
.LC-Semantics
[cols="1,5",caption='WP {counter:wp1}: ']
|===
|*Description* a| A well-defined semantics for OpenSCENARIO 2.0.
As the levels of abstraction have been raised, so the effort and understanding needed for a simulation engine to implement support for this standard is raised. As such, the semantics of a scenario become more important: to give an unambiguous understand of a) whether that scenario could be executed at all; b) whether that scenario could be executed on a given map; c) how to execute that scenario unambigously.
| *Responsibles* | I. Whiteside, Y. Hollander (maybe), S. Rosenberg (maybe)
As the levels of abstraction have been raised, so the effort and understanding needed for a simulation engine to implement support for this standard is raised. As such, the semantics of a scenario become more important: to give an unambiguous understanding of a) whether that scenario could be executed at all; b) whether that scenario could be executed on a given map; c) how to execute that scenario unambiguously. #F.Bock will add description relevant to non-simulation/testing use cases (e.g. description for regulatory bodies).#
| *Responsibles* | I. Whiteside
|*Deliverable* | Semantic rules for the OpenSCENARIO 2.0 language.
| *Effort* | 100 man-days
|===
.LC-Coverage
[cols="1,5",caption='WP {counter:wp1}: ']
|===
|*Description* a| Language constructs for coverage, measurements and KPIs
| *Responsibles* | Rich Heidtman
|*Deliverable* |
| *Effort* |
|===
.LC-Libraries
[cols="1,5",caption='WP {counter:wp1}: ']
|===
......@@ -69,7 +81,7 @@ As the levels of abstraction have been raised, so the effort and understanding n
This WP will address the necessary ways of packaging functionality into libraries and modules in ways that foster re-use across users and implementations. Related namespacing problems are addressed. Relation to OpenSCENARIO 1.0 re-use concepts will be addressed.
| *Responsibles* | P. Mai, Y. Hollander
|*Deliverable* |Full semantic description of the library, modules, packaging and namespace aspects of the OpenSCENARIO 2.0 language. Input for LC-Syntax on syntax aspects of the libraries, modules, packaging and namespaces aspects.
| *Effort* | 50 man-days
| *Effort* | 50
| *Service Provider* | Documentation of library, modules, packaging and namespace parts of the specification. ~15% of effort.
|===
......@@ -79,37 +91,39 @@ This WP will address the necessary ways of packaging functionality into librarie
|*Description* | Additional features in OpenSCENARIO 2.0 to support OpenSCENARIO 1.0/1.x features not otherwise part of 2.0
| *Responsibles* | J. Krasser
|*Deliverable* | Semantic extensions to the OpenSCENARIO 2.0 language to support specific 1.0/1.x concepts not otherwise supported. This WP will monitor the featureset of both projects and provide recommendations accordingly. It will also coordinate with the corresponding WPs from OSC 1.x. Input for LC-Syntax on syntax aspects of these extensions. Semantic mapping (migration path) from the most recent OpenSCENARIO 1.x version to OpenSCENARIO 2.0
| *Effort* | 70 man-days
| *Effort* | 70
| *Service Provider* | Documentation of the additonal features and the semantic mapping from OpenSCENARIO 1.0 to OpenSCENARIO 2.0 (15% of effort)
|===
.DM-AbstractionRoads
==== Domain Model
.DM-Extend2x
[cols="1,5",caption='WP {counter:wp1}: ']
|===
|*Description* | Create road network domain model based on concept project proposal.
| *Responsibles* | M. Kluge, J.Kaths
|*Deliverable* | UML entity definition of the road network, which provides an intuitive way of addressing elements in the network. This for example will be used to define conditions in the behavior definition, e.g. "turn right at the second 4-way junction". An ID based access with detailed knowledge of the road network content must also be possible. The abstract road network domain model should allow the usage of different map sources like OpenDRIVE in OpenSCENARIO 1.0 or HD maps.
| *Effort* | 30 (Could not find the actual number from the meeting...)
|*Description* | Extend Entity Definition from Concept project and other working packages towards OSC 2.0
| *Responsibles* | J. Kaths, M. Kluge
|*Deliverable* | UML entity definition that extends the ones from OSC 2.0 Concept Project and from work package DM-Transfer1x with high level scenario descriptions (e.g. drive()) and other missing features. It will also incorporate the road model developed in work package DM-AbstractionRoads. The result is the full entity definition for OSC 2.0. Similar to the separation of DM-AbstractionRoads, this work package is likely to be split into further work packages as the project progresses.
| *Effort* | 40
| *Service Provider* | Finalization of the UML model draft (10%).
|===
.DM-Transfer1x
.DM-Ontology
[cols="1,5",caption='WP {counter:wp1}: ']
|===
|*Description* | Rework entity definition from concept project with regard to OpenSCENARIO 1.0.
| *Responsibles* | J. Tscheak (maybe), M. Kluge, J.Kaths
|*Deliverable* | Consolidated UML entity definition that covers existing features of OpenSCENARIO 1.0 standard. Differences between 1.0 and the concept project domain model should be identified, listed and resolved. Deviations should only be allowed when necessity is clearly identified and reasoned. This work package is a predecessor of DM-Extend2x and should be finished first.
| *Effort* | 30 (Could not find the actual number from the meeting...)
| *Service Provider* | Finalization of the UML model draft (10%).
|*Description* | Develop ontology to establish relations between entities
| *Responsibles* | S. Kraines, F. Sanchez, I. Whiteside, P. Parekh
|*Deliverable* | Extension of the entity definition delivered by WP DM-Extend2x with an ontology that describes relations between the entities to enable inferrment.
| *Effort* | 60
| *Service Provider* | Tasks to be performed by a service provider. Also estimate the % of total effort for this WP.
|===
.DM-Extend2x
.DM-AbstractionRoads
[cols="1,5",caption='WP {counter:wp1}: ']
|===
|*Description* | Extend Entity Definition from Concept project and other working packages towards OSC 2.0
| *Responsibles* | J. Kaths, M. Kluge
|*Deliverable* | UML entity definition that extends the ones from OSC 2.0 Concept Project and from work package DM-Transfer1x with high level scenario descriptions (e.g. drive()) and other missing features. It will also incorporate the road model developed in work package DM-AbstractionRoads. The result is the full entity definition for OSC 2.0. Similar to the separation of DM-AbstractionRoads, this work package is likely to be split into further work packages as the project progresses.
| *Effort* | 40 man-days
|*Description* | Create road network domain model based on concept project proposal.
| *Responsibles* | M. Kluge, J.Kaths
|*Deliverable* | UML entity definition of the road network, which provides an intuitive way of addressing elements in the network. This for example will be used to define conditions in the behavior definition, e.g. "turn right at the second 4-way junction". An ID based access with detailed knowledge of the road network content must also be possible. The abstract road network domain model should allow the usage of different map sources like OpenDRIVE in OpenSCENARIO 1.0 or HD maps.
| *Effort* | 30
| *Service Provider* | Finalization of the UML model draft (10%).
|===
......@@ -126,44 +140,46 @@ This WP will address the ability of adding and removing entities for the standar
| *Service Provider* | Documentation of the domain model extensibility chapter . ~15% of effort.
|===
.DM-Ontology
.DM-Transfer1x
[cols="1,5",caption='WP {counter:wp1}: ']
|===
|*Description* | Develop ontology to establish relations between entities
| *Responsibles* | S. Kraines, F. Sanchez, I. Whiteside, P. Parekh
|*Deliverable* | Extension of the entity definition delivered by WP DM-Extend2x with an ontology that describes relations between the entities to enable inferrment.
| *Effort* | 60 man-days
| *Service Provider* | Tasks to be performed by a service provider. Also estimate the % of total effort for this WP.
|*Description* | Rework entity definition from concept project with regard to OpenSCENARIO 1.0.
| *Responsibles* | J. Tscheak (maybe), M. Kluge, J.Kaths
|*Deliverable* | Consolidated UML entity definition that covers existing features of OpenSCENARIO 1.0 standard. Differences between 1.0 and the concept project domain model should be identified, listed and resolved. Deviations should only be allowed when necessity is clearly identified and reasoned. This work package is a predecessor of DM-Extend2x and should be finished first.
| *Effort* | 30 (Could not find the actual number from the meeting...)
| *Service Provider* | Finalization of the UML model draft (10%).
|===
.FS-FeatureSetsConcept
==== Usage & Pragmatics
.UP-ScenarioCreation
[cols="1,5",caption='WP {counter:wp1}: ']
|===
|*Description* | Create a concept for partial support of the standard
| *Responsibles* | M. Kluge
|*Deliverable* | Concept to fragment content of the standard into clusters (features sets). Has to contain the approach on how to cluster the content (e.g. on domain model level), a first draft of viable feature sets and an idea on how to check language files for feature set compatibility. Predeccesor for work packages FS-FeatureSetsDefinition.
| *Effort* | 30 man-days
| *Service Provider* | Not applicable.
| *Description* |
| *Responsibles* |
| *Deliverable* |
| *Effort* |
| *Service Provider* |
|===
.FS-FeatureSetsDefinition
.UP-ScenarioAbstraction
[cols="1,5",caption='WP {counter:wp1}: ']
|===
|*Description* | Define viable feature sets
| *Responsibles* | M. Kluge
|*Deliverable* | Definition and documentation of feature sets based on first draft provided by successor work package FS-FeatureSetsConcept. Might also contain the addition of new elements in the language to declare feature set compatibility. Predeccesor for work packages FS-FeatureSetsValidation.
| *Effort* | 30 man-days
| *Service Provider* | Language checks and possibly UML model finetuning (20%).
| *Description* |
| *Responsibles* |
| *Deliverable* |
| *Effort* |
| *Service Provider* |
|===
.FS-FeatureSetsValidation
.UP-SuccessCriteria
[cols="1,5",caption='WP {counter:wp1}: ']
|===
|*Description* | Define feature set validation method
| *Responsibles* | M. Kluge
|*Deliverable* | Definition, documentation and implementation of validation approach of language files against feature sets. Necessary for actual usage of usage of feature sets.
| *Effort* | 20 man-days
| *Service Provider* | Language checks and possibly UML model finetuning (20%).
| *Description* |
| *Responsibles* |
| *Deliverable* |
| *Effort* |
| *Service Provider* |
|===
.UP-TestDefinition
......@@ -174,10 +190,33 @@ This WP will address the ability of adding and removing entities for the standar
| *Deliverable* | Clarification of boundaries between test case & scenarios
Workflow guidelines (e.g. when integrated with a scenario vs. defined separately)
| *Effort* | 30 man-days
| *Effort* | 60
| *Service Provider* | Finalization and review (10%)
|===
.UP-Transfer1x
[cols="1,5",caption='WP {counter:wp1}: ']
|===
| *Description* |
| *Responsibles* | Sandeep Pendharkar
| *Deliverable* |
| *Effort* |
| *Service Provider* |
|===
==== Feature Set
.FS-FeatureSetsConcept
[cols="1,5",caption='WP {counter:wp1}: ']
|===
|*Description* | Create a concept for partial support of the standard. If viable, propose specific feature sets and guidelines/methodology for validating them.
| *Responsibles* | M. Kluge
|*Deliverable* | Concept to fragment content of the standard into clusters (features sets). Has to contain the approach on how to cluster the content (e.g. on domain model level), a first draft of viable feature sets and an idea on how to check language files for feature set compatibility. Definition and documentation of feature sets based on first draft provided by successor work package FS-FeatureSetsConcept. Might also contain the addition of new elements in the language to declare feature set compatibility. Definition, documentation and implementation of validation approach of language files against feature sets. Necessary for actual usage of usage of feature sets.
| *Effort* | 100 man-days
| *Service Provider* | Maybe language checks and possibly UML model finetuning (20%).
|===
.Total effort
[options="header", cols="1,2,2,2"]
|===
......
......@@ -14,10 +14,25 @@ Members of the CCB are project participants with the necessary permissions on th
.. Accept merge requests from other project members
.Change Control Board (CCB)
[options="header",cols="45,45,10",frame=topbot,grid=rows]
[options="header",cols="1,1",frame=topbot,grid=rows]
|===
|Participant contact details (name, phone, email)| Company (Name, Location)
|||
|Participant
| Company
a|mailto:pmai@pmsf.eu[Pierre Mai]
| PMSF, Germany
a|mailto:luca.costantino@ansys.com[Luca Costantino]
| ANSYS, France
a|mailto:fran.sanchez@five.ai[Fran Sanchez]
| FiveAI, UK
a|mailto:iain.whiteside@five.ai[Iain Whiteside]
| FiveAI, UK
a|mailto:mirko.bulaja@avl.com[Mirko Bulaja]
| AVL List GmbH, Austria
|===
......
......@@ -3,7 +3,7 @@ ANSYS,France,36,Luca Costantino; Bernhard Kaiser, luca.costantino@ansys.com; be
Applied Intuition,USA,15,Romain Kuntz,rk@applied.co,+49 157 357 09475
APTIV,USA,60,Rich Heidtman,rich.heidtman@aptiv.com, 810.599.8909
Audi,Germany,25,Florian Bock, florian1.bock@audi.de,
AVL List GmbH,Austria,25,Jürgen Krasser, juergen.krasser@avl.com,
AVL List GmbH,Austria,25,Jürgen Krasser; Mirko Bulaja, juergen.krasser@avl.com; mirko.bulaja@avl.com,
BMW AG,Germany,25,Andreas Rauschert,andreas.rb.rauschert@bmw.de, +49-89-382-61151
BTC Embedded Systems AG, Germany,37,Matthias Büker,matthias.bueker@btc-es.de,+49 441 - 969738 - 33
CATARC,China,30,Qidong Zhao; Chen Chen, zhaoqidong@catarc.ac.cn; chenchen2018@catarc.ac.cn, +86 13920081313; +86 17622956550
......@@ -14,7 +14,7 @@ Denso,Germany,25,Nicolas Ochoa Lleras, n.ochoa@denso-auto.de, (0)8165-944-440
DLR,,,,,
dSPACE,,,,,
Elektrobit,,,,,
FiveAI,UK,50,Iain Whiteside; Alex Heavens, iain.whiteside@five.ai; alex.heavens@five.ai,
FiveAI,UK,50,Iain Whiteside; Alex Heavens; Fran Sanchez, iain.whiteside@five.ai; alex.heavens@five.ai; fran.sanchez@five.ai,
Foretellix,Israel,70,Gil Amid; Sharon Rosenberg; Yoav Hollander; Ronen Hadar, gil.amid@foretellix.com; sharon.rosenberg@foretellix.com; yoav.hollander@foretellix.com; ronen.hadar@foretellix.com,
FZI,Germany,25,Thilo Braun; Barbara Schütt, braun@fzi.de; schuett@fzi.de, +49 721 9654-152; +49 30 7017337-336
Höchstleistungsrechenzentrum Stuttgart,Germany,28,Jutta Sauer, hpcfloh@hlrs.de,
......@@ -36,6 +36,7 @@ TU Dresden – IAD,Germany,20,Stefan Plaettner; Thomas Tüschen,stefan.plaettner
TÜV SÜD,Germany,25,Christoph Miethaner, Christoph.miethaner@tuev-sued.de,
Vayavya Labs,India,30,Sandeep Pendharkar,sandeep@vayavylabs.com,-9845444659
Vector Informatik GmbH,Germany,25,Jakob Kaths, jakob.kaths@vector.com,
Vicomtech,Spain,7,Oihana Otaegui,ootaegui@vicomtech.org,
Virtual Vehicle,Austria,21 days,Patrick Weissensteiner, patrick.weissensteiner@v2c2.at, +43 316 9707
WMG University of Warwick, UK,40,Dr Jason Zhang; Siddartha Khastgir, s.khastgir.1@warwick.ac.uk; Jason.Zhang@warwick.ac.uk,
ZF Friedrichshafen AG,Germany,,Jochen Köhler,jochen.koehler@zf.com,+49 151 62524621
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