Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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:00Agenda 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

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
  • Backlog topics

    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

    ?

    Time

    Day 2

    08.30

    Start

    08:30-9:00Agenda 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





































    Agenda backlog

    ...

    Draft agenda planning here.

    ...