Skip to content

Home

Jump to bottom
Armin Kassemi Langroodi edited this page Aug 22, 2023 · 35 revisions

Welcome to the Adaptive Runtime AUTOSAR Linux Simulator wiki! The project wiki consists of sections related to the project goal, the project scope and its alignment with the AUTOSAR Adaptive standard, and the project timeline. The aim of this project is to provide students/researchers in the automotive engineering a big picture of Adaptive Runtime AUTOSAR and an overview about how its interfaces should be implemented. This repository does not rely on any hardware requirement (e.g., an ECU emulator), but it is able to interact with some hardware interfaces (i.e., CAN bus and Ethernet).

Project scope

The project does not cover fully the AUTOSAR Adaptive standard. Following table indicates the different domains of the standard, and the project compatibility with each domain:

User Application
Communication Management RESTful Time Synchronization Diagnostics State Management
Persistency Platform Health Management Log & Trace Network Management
Core Types Execution Management Identity Access Management Cryptography Update and Configuration Management
Operating System Interface
(Virtual) Machine / Container / Hardware

User Application

An Adaptive Application to interact with Extended Vehicle RESTful API is part of the scope.

Communication Management

Partially implemented based on R20-11 and R22-11:

  • E2E communication protection (ara::com::e2e) is limited to Profile11 based on R22-11.

  • Raw data streaming (ara::com::raw) is out of scope.

  • Communication Group (ara::com::cg) is not fully implemented yet.

  • Network binding is limited to SOME/IP (Signal-Based and DDS network bindings are out of scope):

    • SOME/IP Service Discovery (SD) only supports IPv4 endpoints.

    • Network link status change is not simulated in the SD finite state machine (FSM).

    • SD Client Requested_but_not_read state is removed from the FSM.

    • The ara::com::someip::sd and ara::com::someip::pubsub namespaces and their sub-namespaces are not part of the official standard.

  • Secure Onboard Communication (ara::com::secoc) is out of scope.

RESTful

Out of scope (Obsolete in R21-11)

Time Synchronization

Out of scope

Diagnostics

Interfaces are partially defined based on R21-11 and the functional cluster (DM) is able to communicate with OBD-II, UDS, and DoIP.

State Management

The scope of the State Management (SM) is limited to the initialization of the Machine Function Group (Machine FG). The State Management development is based on R21-11.

Persistency

Out of scope

Platform Health Management

Partially implemented based on R22-11:

  • Alive Supervision is implemented.

  • Deadline Supervision is implemented.

  • Logical Supervision is out of scope.

Log & Trace

The Log & Trace is mostly implemented based on R20-11:

  • Log sinks are limited to console and file sinks (network sink is out of scope).

  • The ara::log::sink namespace is not part of the official standard.

  • Current implementation does not support hexadecimal format, binary format, and ClientState logging.

Network Management

Out of scope

Core Types

It is barely implemented partly based on R21-11 and partly based on R20-11. The implementation scope is as follows:

Data type Implementation revision Compatibility Replaced alternative
ErrorDomain R21-11 Lacking SupportData -
ErrorCode R21-11 Lacking SupportData -
Exception - - std::exception
Result R20-11 Incompatible noexcept specifiers, dedicated specialized global (in)equality operator, and lacking non-member swap method -
Future - - std::future and std::shared_future
Promise - - std::promise
Array - - std::array
Vector - - std::vector
Map - - std::map
Optional C++17 Some constructor overloads are missing -
Variant - - Out of scope
StringView - - std::string
String - - std::string
Span - - Out of scope
SteadyClock - - std::chrono::steady_clock
InstanceSpecifier R21-11 Replacing ara::core::StringView with std::string -
ScaleLinearAndTexttable - - Out of scope
Byte - - uint8_t

Execution Management

The development is in progress based on R21-11:

  • Execution Error Event struct:

    • In contrast with the standard, the structure keeps pointer to the Function Group in Undefined State instead of the Function Group itself.

  • Execution Client class:

    • There is no default constructor same as the standard and the object owner should pass the Instance Identifier and the Communication Layer (for remote procedure calling).

  • Deterministic Client class:

    • noexcept specifiers are not aligned with the standard.

  • Function Group class:

    • noexcept specifiers are not aligned with the standard.
    • No ARXML meta-model validation mechanism is implemented.
    • GetInstance method is not aligned with the standard.

  • Function Group State class:

    • noexcept specifiers are not aligned with the standard.
    • No ARXML meta-model validation mechanism is implemented.
    • GetFunctionGroup and GetState methods are not aligned with the standard.

  • Exec Exception class:

    • MakeErrorCode method does not consider manufacture specific SupportData.

  • State Client class:

    • The class constructor takes IPC abstraction layer as well which is not aligned with the standard.
    • noexcept and const specifiers are not aligned with the standard.
    • Undefined Function Group State concept is not implemented.

Identity Access Management

Out of scope

Cryptography

Out of scope

Update and Configuration Management

Out of scope

Operating System Interface

Currently, there is a wrapper interface around BSD sockets to enable functional clusters (e.g., Communication Management) for interacting via TCP/IP protocol.

Project milestones and timeline

Following is the project timeline and its specified milestones within 4 years:

Milestone Start date End date Status
Studying R19-11 January 2020 December 2020 Done
Updating to R20-11 January 2021 May 2021 Done
Launching the repository May 2021 June 2021 Done
Doxygenizing September 2021 September 2021 Done
Integrating with Async-BSD-Socket-Lib October 2021 October 2021 Done
Implementing SOME/IP October 2021 December 2021 Done
Implementing EM and SM December 2021 January 2022 Done
Developing CAN OBD-II Linux Driver January 2022 February 2022 Done
Implementing DoIP and UDS within DM February 2022 August 2022 Done
Integrating SM with EM via Execution Manifest September 2022 January 2023 Done
Finalizing EM, SM, and DM integration via ara::com January 2023 February 2023 Done
Finalizing DoIP and UDS within DM February 2023 March 2023 Done
Finalizing Volvo Extended Vehicle API Adaptive Application March 2023 April 2023 Done
Implementing PHM April 2023 May 2023 Done
Developing E2E communication protection library May 2023 June 2023 Done
Clone this wiki locally