Page History

...

Participants: Sami, Pawel, Piotr, Adnan, Erik, Paul, Stephen

Topics:

• Charter Status
  • MQTT adapter
    • SAMI: We need one, AUTOSAR will do it
    • Piotr: legal group must discuss how MQTT Adapter can be published
  • ECH is transport agnostic
  • Data mapper
    • to be generated, so scope is instead tool chain which generate data mapper
  • Simulate API
  • PoC- licenses
    • Sami: Focus is to use MIT-based licenses.
    • Sami: How to handle licenses questions
    • Paul: Send to Steve Crumb or Michael
    • Piotr: Where to store questions related to licenses?
    • Paul: Wherever you find most useful
• AUTOSAR Classic
  • Stephen: COVESA interest in classic, mentioned in charter, both for spec and poC. A bit worrying if in spec but not tested. Renesas also interested in Classic.
  • Stephen: Have you in AUTOSAR discussed Classic for Vehicle API
  • Sami: Classic is on the Radar. Should come at some point. But pushing first for adaptive.
  • Stephen: May be some interest to get some guidance on how to implement in Classic
  • Sami: We intend to be able to read data from classic in adaptive, but you mean implementing on classsic?
  • Sami: We have not considered implementing gateway on classic
• https://github.com/langroodi/Adaptive-AUTOSAR
  • Adnan: Could it possibly be used for simulation, some seem to use it?
  • Adnan: Could we possibly use it to emulate AUTOSAR env?
  • Pawel: Require some checks on our side
  • Adnan: Sami needs to give some feedback, is what they are doing fine from license perspective
  • Stephen: What are dependencies? In-house?
  • Sami to contact Michael (AUTOSAR legal) on if this repo can be used, anyway need to consult team
• Next steps
  • What to discuss next week in sync, what is left for meeting 3rd?
  • What to do after steering body meeting Feb 3rd
    • Format charter outside google, generate PDF to have something fixed to review?
  • Collaboration structure after next steering group
    • Erik: Shall we continue with this slot also after 3rd feb?
    • Paul: Seems good
    • Sami: Once concluded with charter, we hopefully also have license agreement in place as we may need to discuss more
    • Stephen: Ask Steve/Niclas how collaboration can be set up, we need to sync on legal check
  • Discussion
    • Adnan: we proposed a draft, circulate a few days in advance, include what Tieto presented at CES
      • Pawel: Will check, can provide something beginning of next week
    • Stephen: Get statement on license, highlight open topics
      • Erik: Shall we send to license group for questions
      • Paul: Yes
      • Sami: Could we have next call with them, charter say we shall align with legal group, invite them to next Friday
  • Action Points
    • Erik: Integrate latest comments, cleanup of doc
    • Erik: Ask Legal team (Steve Crumb, Niclas Höret) if they can join next week, send them charter. Also ask for meeting legal framework.
    • Pawel: Provide material from (or link to info on) Tieto CES PoC
    • Erik: Paul to create meeting link for continued meeting series (after Feb 3rd)

2022-01-13:

Participants: Sami, Pawel, Piotr, Adnan, Erik

Quick notes:

• 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

...