Generic Communication Protocols Evaluation
Next call: Tuesday 20 August 2019 - 11:15am CET
- FARA tool testing
- SomeIP on Android
- Register in advance for this meeting: Registration link (to be updated)
- Meeting link: https://zoom.us/j/741931761
- Zoom Meeting Number: 741 931 761
Meeting Minutes ← use link
Presentations Materials ← use link
Project pages (list)
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 .