Page tree
Skip to end of metadata
Go to start of metadata

(star) What is this?  → Please refer to the projects overview page for a quick introduction, then for more details, the Kickoff slides, and recording.

Webinar:  delivered twice on 24 & 25 September

Next GPRO weekly call - 8 October

Project pages (list)

Definitions

Generic Protocol (in this context):

“Network (*and d IPC) protocols acting primarily as a transparent data carrier, applicable to many different application domains, but including convenience features above that of a plain data stream (socket). For example: data encoding, segmenting, opaque target addressing, routing, peer authentication, delivery guarantee, data integrity and service-discovery.”

• In other words, we are concerned with OSI model levels 5-6 (approx.)
• To reduce scope – focused on segmented segmented, atomic, event/message event/message- based semantics more than “streaming data”
• *IPC needs to be in scope, because of shared parts (data encoding) similarity, and that network-transparency is often a design goal.

<Single "project" definition to be copied from GA slide deck and then edited.>

Project Goals

<to be copied from GA deck and then edited>


Use cases

Information about real-world functions (ideally from user perspective) to anchor the technical discussion.

FILL IN HERE!!!


Philippe C

NB: see the target architecture in the attached file

The vehicle position computed in the telematic box shall be provided to applications carried by the smartphone

  • the vehicle position is either raw (i.e. coming from the GNSS sensor) or estimated (i.e. computed by a dead reckoning algorithm)

Transmission of data shall be seamless

  • to avoid mismatch between data types
  • to reduce diversity of specifications by using a common format

Requirements: 

Evaluation criteria for GPRO technologies

Comparisons of different communication protocols/technologies

Feature Selection

  • We looked at the possibility to use feature-modeling tools (example:  Feature IDE) to encode a database (model) of possible protocol features.  Normal use of such tools is rather to define how a system can be configured, including all constraints, and then to present a UI to do that configuration  (I.e. selecting features rather than comparing solutions), but it could be useful.  
  • Feature Selection tooling is definitely useful for complex feature modeling, so it's worth knowing about it and documenting it.    See May 15, 2018 in the Minutes .


(blue star) The video is being recoded and combined into one.  New (smaller) version is coming soon:


Introduction slide:

pageaccueil (2).mp4

Presentation ((warning) file is still truncated, please look for an updated version soon).

Franca-ARA-model-to-model transformation-Webinar-24-25September.mp4


  • No labels