Page History

...

• Cloud WG has discussed the specification table in meeting yesterday (Jan 12th)
• Erik: Ulf from Ford has created proposal for for an API
• Adnan: We need to focus on core part first
• Adnan: Piotr- do you have any API spec from poC. Do you have any high level description you can share?
• Piotr: We could extract something.
• Adnan: Concerning ECH, We want to have some form of simulation env so non-AUTOSAR members can test/demonstrate it.
• Sami: ECH network adapter interface will not expose anything today covered by AUTOSAR licensing.
• Piotr: AUTOSAR Partners can use demonstrator for simulation. We could possibly make a stubbed implementation not using ara::com that gives same behavior.
• Adnan: Would there be legal problems?
• Sami: We need to consult AUTOSAR legal team.
• Adnan: How can we mimic AUTOSAR service runtime env to show full pipeline available for non-AUTOSAR partners.
• Piotr: We could possibly as part of PoC use Franca for internal southbound instead of ara::com so it can be be run outside AUTOSAR.
• Sami: This is more related to Data Mapper, have a different implementation not relying on AUTOSAR service
• Erik: I have based on comment from Stephen Lawrence
• Erik: If we are to implement an MQT ECH, dowe need to integrate a MQTT netw adapter
• Pawel: If we provide method, it can support both both MQTT and others
• Erik: You need to specify something, like topics
• Pawel: That is likely configuration
• Sami: An ECH may support multiple adapter,
• Pawel: Every API has access to a message queue. callbacks. All handled by configurations.
• Sami: So ECH are quite generic
• Erik: I assume there is need for a small glue layer somewhere been generic network adapter (e.g. MQTT stack)
• Erik: So it seems we are quite aligned on specs, next week we can hopefully discuss PoC and ref implementation contents
• Sami: We need legal guidance on how to collaborate for documents where AUTOSAR is responsible but COVESA to be consulted

...