1 / 11

Administrative issues

Administrative issues. Lab 5 Friday, Feb. 10 th 13:00-15:00 (and 15:00-17:00) Registration (mandatory!): os-lab@deeds.informatik.tu-darmstadt.de. Assessing AUTOSAR: Inside future automotive software Part of the lecture “OS Dependability and Fault Tolerance”. AUTOSAR Architecture.

mervyn
Download Presentation

Administrative issues

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Administrative issues Lab 5 Friday, Feb. 10th 13:00-15:00 (and 15:00-17:00) Registration (mandatory!): os-lab@deeds.informatik.tu-darmstadt.de

  2. Assessing AUTOSAR:Inside future automotive softwarePart of the lecture“OS Dependability and Fault Tolerance”

  3. AUTOSAR Architecture AUTOSAR is • Standardized software architecture • Layered • Component- / composition-based

  4. AUTOSAR Architecture AUTOSAR is • Standardized software architecture • Layered • Component- / composition-based

  5. Areas of Research Motivation: AUTOSAR / automotive systems are • Safety-relevant • Security-relevant • Robustness Evaluation • Fault injection • Error propagation analysis • Security Testing • Robustness and Security Enhancers • Run-time monitoring  Flexible instrumentation with injectors and detectors required

  6. Instrumentation of AUTOSAR Components Interface wrappers • Clone original interface • Hide original interface • Implement added functionality in clone • Call original interface from clone Example AUTOSAR model

  7. Instrumentation of AUTOSAR Components AUTOSAR model • AUTOSAR implementation: • Varied data flow paths • Mixed black-box and white-box components

  8. Challenges • Flexibility • Different locations in SW stack • Variety of applications (FI, monitoring, etc.) • Grey-box system, mixes • Black-box components • White-box components • Systematic and automatic • Tool-independent • Vendor-independent

  9. Student Projects • Instrumentation Framework (Paul Manns) • AUTOSAR model (ARXML) as input • Configuration on the model level (vs. implementation level) • Supports Application and RTE layers • Instrumentation of .c-files, .h-files, .o-files (black-box, grey-box, white-box) • Instrumenting BSW components (Manuel Pütz) • BSW description not part of ARXML • Different granularity • Monitor and inject (sub-)system-wide

  10. Student Projects • Fault Injection Framework (Michael Tretter) • Development of a generic, adaptive FI framework • High degree of abstraction • Wide variety of fault-models • Proof-of-concept for AUTOSAR • Security Testing (Jannik Kappes) • Vulnerability analysis and classification • Current approaches (Koscher’10, Checkoway’11) target external attack surfaces  complex, undirected • Testing at component level allows for finer granularity

  11. Outlook Assessment of AUTOSAR 4 safety features: • Mixed criticality systems • Memory partitioning / protection • User- / supervisor-modes • Deterministic timing of SW components • Detect and control timing violations • Prevent their propagation • Control-flow monitoring • Based on Watchdog and checkpoints  We offer seminar and thesis works in these areas

More Related