Next GPRO weekly call - January, 21st 2020
- Link to Zoom meeting: https://zoom.us/j/741931761
ID de réunion : 741 931 761
For local dial-in, visit : https://zoom.us/u/aeDLu354w5
- Data & interfaces modeling (continuation of last week's discussion)
- FARACON: wki page and linkedin post for dissemination
Webinar: delivered twice on 24 & 25 September
Title: Franca / ARA::COM Interoperability - Establishing interoperability of Linux-based systems and Adaptive AUTOSAR systems by model-to-model transformations
- latest release (v0.9) of the transformation tool: franca_ara_tools/wiki/FARACON-Developer-Guide#how-to-build-the-command-line-tool-from-source repository
Meeting Minutes ← use link
Presentations Materials ← use link
Project pages (list)
- [GPRO] REST/HTTP
- AMM informal GPRO poll
- Bench-marking of different protocols & technologies
- CommonAPI overview
- Evaluation criteria for GPRO technologies
- Franca/ARA::COM Demo
- Franca-ARA Stage 2 Project
- GPRO Meeting Minutes
- GPRO - Presentations Materials
- GPRO Whitepaper
- List of relevant technologies
- Overview of a few communication protocols/technologies
- Poll - Your favorite protocols
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.>
<to be copied from GA deck and then edited>
Information about real-world functions (ideally from user perspective) to anchor the technical discussion.
FILL IN HERE!!!
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
List of relevant technologies ← use link
Comparisons of different communication protocols/technologies
- Overview Page containing one-paragraph summaries of REST/JSON/XML/SOAP.
- When survey/knowledge sharing phase winds down, the Evaluation Criteria page should be extended, evntually leading to comparisons and possibly recommendation.
- 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 .
The video is being recoded and combined into one. New (smaller) version is coming soon:
Presentation ( file is still truncated, please look for an updated version soon).