Resources |
◎ COVESA Events |
Join/Sign Up |
◎ Join COVESA |
Meeting notes from Joint meetings
2022-01-27:
Participants: Gerald, Ramona, Steve Crumb, Bernd Mattner, Erik, Sami, Jan, Stephen
Topics:
(Currently not published here, potentially confidential)
2022-01-20:
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
Way forward:
AUTOSAR WG Cloud has next meeting Thu 19th - PoC/ref Impl to be discussed
Pavel to prepare presentation how existing PoC/Demo exists, to be discussed first in AUTOSAR Cloud WG
Next joined meeting Fri 20th
2022-12-19
Participants: Sami, Paul, Erik
Quick notes
Alignment on what was agreed in last steering board meeting
Protocol mentions both 31st and 23/24th
We will aim to have something ready for 23rd/24th
Updates of charter - ok to merge comments
Erik to merge comments
Who does what going forward
Sami
next Cloud WG 12th
Then sessions with other WGs needed
We can have understanding of deliverables without knowing details
Sami back from from vacation about Jan 4th
Erik add draft component/deliverable proposal, intended to be ready before Jan 4th, then Sami can do a quick review
Add disclaimer, everything can be changed
Next meeting
Sync meeting Friday 13th+20th (15.00-16.00 CET)
Erik to invite Sami, Paul, Adnan, Erik
Sami will check if more will join from Cloud WG
2022-12-09
Quick notes, please reply if changes are needed. They shall be considered as informal notes only, not a formal protocol
Participants: Nadym, Adnan, Sami, Erik
Scope of project was discussed, - are parts where no collaboration is needed (like AUTOSAR Data Mapper) to be considered as part of project?
We need in the charter to state something about responsibilities and collaboration model for the various components
Erik: Licensing of components needs to be synched with Legal working group
Sami: We call upper part adapter, we assume Linux contains VISS server, possibly use VISS as Vehicle API
Erik: There can be things in VISS that are too complex for us now, like subscription filters, token
Adnan: Want lightweight between AUTOSAR/Linux
Adnan: Could possibly consider defining API in OpenAPI
Sami: What is meant by the statement that methods is to be supported fist in a later increment? Don’t we need methods in the API
Erik: We need methods for read/write/subscribe, but no need to support custom-specified methods to access functions in AUTOSAR
Sami: Assisting marketing and training may be out of scope
Sami: Developing technical API is main focus, assisting marketing/training
Erik: But we may need to support setup of PoC and Demoas
Decision: Add “may” in text
Sami: CLA discussion on AUTOSAR side in progress
Sami: We will have next internal AUTOSAR meeting on Thursday, we may add more comments to charter
Adnan: If you already have your ideas on charter you could send it to us and we can align/merge them
Erik:Then rough plan is that on COVESA-AUTOSAR meeting Dec 16th we (ie COVESA) present the Charter and you (i.e. AUTOSAR) present their comments
How to progress
Erik: How often to meet
Sami: Joint meeting every second week might be sufficient, we have internal every week
Erik: Current charter says at least every second week, we can have it more frequent
Erik: Do we need a kickoff (online or insite) next year? Half-day?
Agreement: Present idea on kick off in steering committee next Friday
Erik: Good if you (Sami) could participate dec 16th