...
BMW at Petuelring 130, 80809 Munich in Germany.
Timetable
Time | Day 1 |
|---|
09.00 | Agenda Review and introduction |
09:30 | Security design (-owner) - Vectors of attack (TBD)
- Access control and permissions (Stefan - TBC)
- How to verify permissions (TBD)
- report on CDD (Sachin - TBC)
- Build connection VSS to Android permissions model (Stefan)
- External service approach (Alexander - TBC)
- = which authentication methods exist
- Adaptive AUTOSAR Identity and Access management has a general philosophy, defined names and concepts. It is a basis for discussion because it describes a model around interaction between (not details or protocols).
- VSS Layers:
- concept could be used to put signals into access control groups (Gunnar)
- Different users could have different permissions? Or is this only controlled based on application identity? (TBD)
- For example audio zones... Some users should not be able to control the audio.
- But can this simply be built into the application?
- Use cases and general requirements (TBD)
- E.g. How fine grained must the permissions model be?
|
12.30 | Lunch, at BMW office |
13.30 | Technical proposals - further refinement - 1 External services e.g. VISS, REST (TBD)
- 2 External services e.g. SOME/IP (TBD)
- 3 Android internal service (Some signal-connecting library using VSS standard) (TBD)
- VSS to standard Vehicle HAL - detailed design - can be done right away.
- Focus on: "Easiest way" to expose data to Android applications
- Compatibility Android and non-Android systems - common solutions
- Tool chains: VSS (or Franca) to Android IDLs translation?
- Decision point: Which design to use (develop), or at least prioritize
- ....Decide how the application layer should be fusing the connection - direct socket connection or bound through android service
|
17:30 | end of Day 1 |
| Backlog topics |
| - how to use SOME/IP to communication with Adaptive AUTOSAR and/or Classic AUTOSAR ?
- how to use Adaptive AUTOSAR Identity & Access Management (IAM) ?
- Once we know direction, what parts are missing and need to be developed?
- signal-to-service specification in AR 19-11
|
Time | Day 2 |
|---|
08.30 | Start |
| 08:30-9:00 | Agenda bashing |
| Audio HAL - presentation of the work done by the HV project on the standard interfaces for the audio platform (Gunnar)
- review of the list of prioritarized topics (TBD)
- work on highest priority topics
- source management, networked audio devices (TBD)
- controlling audio effects / audio data transfer (TBD)
- multi-source management (TBD)
|
12.00 | Lunch |
13.00-13:30 | Agenda bashing |
13.30-16:00 | Vehicle HAL topics likely |
16:00 | End of Day 2 |
| Backlog topics |
Date Planning
Edit the table below to indicate your status with respect to the proposed dates for the F2F, entering one of the following:
...
Name | Attending | Arrival day; flight no and time | Departure day; flight no and time | Hotel | Notes | Car Parking? |
|---|
Timetable
Time | Day 1 |
|---|
09.00 | Agenda Review and introduction |
09:30 | Security design - Vectors of attack
- Access control and permissions
- How to verify permissions
- Build connection VSS to Android permissions model
- External service approach
- = which authentication methods exist
- Adaptive AUTOSAR Identity and Access management has a general philosophy, defined names and concepts. It is a basis for discussion because it describes a model around interaction between (not details or protocols).
- → @alexander.domin (contact Giovanni Vergine)
- VSS Layers:
- concept could be used to put signals into access control groups (Gunnar Andersson - but after the basic ideas have been defined)
- Different users could have different permissions? Or is this only controlled based on application identity?
- For example audio zones... Some users should not be able to control the audio.
- But can this simply be built into the application?
- Use cases and general requirements
- E.g. How fine grained must the permissions model be?
|
12.30 | Lunch, at BMW office |
13.30 | Technical proposals - further refinement - 1 External services e.g. VISS, REST
- 2 External services e.g. SOME/IP
- 3 Android internal service (Some signal-connecting library using VSS standard)
- VSS to standard Vehicle HAL - detailed design - can be done right away.
- Focus on: "Easiest way" to expose data to Android applications
- Compatibility Android and non-Android systems - common solutions
- Tool chains: VSS (or Franca) to Android IDLs translation?
- Decision point: Which design to use (develop), or at least prioritize
- ....Decide how the application layer should be fusing the connection - direct socket connection or bound through android service
|
17:30 | end of Day 1 |
Backlog topics | how to use SOME/IP to communication with Adaptive AUTOSAR and/or Classic AUTOSAR ? | how to use Adaptive AUTOSAR Identity & Access Management (IAM) ?Once we know direction, what parts are missing and need to be developed?signal-to-service speci
|---|
Time | Day 2 |
|---|
08.30 | Start |
| 08:30-9:00 | Agenda bashing |
Audio HAL - presentation of the work done by the HV project on the standard interfaces for the audio platform
- review of the list of prioritarized topics
- work on highest priority topics
- siurce management, networked audio devices
- controlling audio effects / audio data transfer
- multi-source management
| 12.00 | Lunch |
13.00-13:30 | Agenda bashing |
13.30-16:00 | Vehicle HAL topics likely |
16:00 | End of Day 2 |
Backlog topics |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Agenda backlog
...
Draft agenda planning here.
...
