Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AUTOSAR-COVESA Collaboration #2

Open
erikbosch opened this issue Dec 15, 2022 · 5 comments
Open

AUTOSAR-COVESA Collaboration #2

erikbosch opened this issue Dec 15, 2022 · 5 comments
Assignees

Comments

@erikbosch
Copy link
Collaborator

AUTOSAR-COVESA meeting was held Nov 21 st
Next meeting Dec 16th
Erik trying to get in contact with AUTOSAR WG Cloud lead

Decisions 2022-12-01:

  • Have a weekly COVESA meeting
  • COVESA shall propose a draft for the C-A Vehicle API technical Track meeting
  • Erik can invite
  • Suggested slot after VSS meeting
  • Invited: All COVESA people start of autosar call. For now only people active in the area
  • Schedule 2022-12-06 +2022-12-13+2022-12-20, then we can see how to continue, skip a few weeks for christmas?
  • Paul to arrange with webex link

2022-12-08:

  • First meeting last Tuesday
  • Charter draft updated, will be discussed by Paul/Adnan/Erik today
  • Meeting with Adnan, Erik, Sami tomorrow - Paul to send out invite.
@erikbosch erikbosch self-assigned this Dec 15, 2022
@erikbosch
Copy link
Collaborator Author

@erikbosch
Copy link
Collaborator Author

Charter updated with possible deliveries, info from Sami:

_Hi Erik, Adnan, Paul,
Happy New Year to you all.

Thanks Erik for your edits to the charter doc. The deliverables are an area that our WG-CLD has not yet addressed but it will be a topic of discussion next week when all members are back from their Christmas breaks. In general in AUTOSAR, like in any standards organization we are interested in interface specs (APIs). That’s where the interoperability happens. Consequently I assume the Vehicle API Core spec and its MQTT transport are fine also for us in AUTOSAR. After all, that is in essence what the Vehicle API is all about 😊

I cannot yet give any commitment on External Connection Handler as a deliverable as we may not have clearly described it in WG-CLD to know if there is anything else than implementation specifics there. The ECH exposes the “thin API” to the Network Adapter for it to communicate with the DM. Apart from the Vehicle API itself (covered by other deliverables) I don’t know if there is much to specify there?

Regarding the Data Mapper, it may not involve any APIs as the “code bindings” between thin API and AUTOSAR service defs are likely something like “application configuration”. Our view in WG-CLD has been to describe the methodology of how to construct the mapping between the two sides. It may include some restrictions also, like not allowing certain operation on one side to be mapped to a certain operation on the other side. So it seems this deliverable wont be any interface spec but maybe a TR type of explanation only.

I don’t yet have a view on the Network Adapter specification other than that it is in the open domain. AUTOSAR likely won’t be active there.

I hope I have given some idea of our thinking in WG-CLD on what needs to be standardized in Vehicle API. By Friday next week I try to get a more consolidated view of our group to our synch call.

With regards,
Sami_

@erikbosch
Copy link
Collaborator Author

Tech charter almost complete for meeting w AUTOSAR Fed 3rd.
COVESA may continue on our own with nortbound interface

@erikbosch
Copy link
Collaborator Author

Not much to do, or?

@erikbosch
Copy link
Collaborator Author

Status update:

  • Concept development (and gateway requirements) ongoing AUTOSAR WG Cloud
  • Erik participates now and then
  • Occasional meetings with AUTOSAR, some parts of SDV Alliance

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: 🏗 In progress
Development

No branches or pull requests

1 participant