AUTOSAR Cencept Roadmap

AUTOSAR Concept Roadmap

What is a concept?
A concept in terms of AUTOSAR is a set of documents which together describe a technical solution to extend the functionality covered by the AUTOSAR standard.
A concept consists of the following possible concept documents/items:
a concept document which describes the purpose, use cases and technical approach of an AUTOSAR extension branches of software or requirement specifications in maintenance mode which contain detailed changes required by the concept new documents in evolution mode which describe additional technical features or complementary explanations meta model replika which contains changes of the AUTOSAR methodology and templates

Release R24-11

Concept Number	Icon	Concept Name	Challenges Overview (link)	Benefit	Status	Platform
CONC 726.1		Vehicle Data Protocol (Protocol specification)	https://autosar.org/fileadmin/user_upload/ConceptNutshells/R24-11/AUTOSAR_Concept726-InANutshell.pdf	Enables reconfigurable data collection that supports the changing needs of deployed vehicles across their lifecycle		Valid
CONC 722.1		DdsProtocols	https://autosar.org/fileadmin/user_upload/ConceptNutshells/R24-11/AUTOSAR_Concept722-InANutshell.pdf	Improved interoperability for DDS based systems across AUTOSAR Classic, AUTOSAR Adaptive and non-AUTOSAR platforms		Valid
CONC 720.1		Adaptive Platform Machine Configuration	https://autosar.org/fileadmin/user_upload/ConceptNutshells/R24-11/AUTOSAR_Concept720-InANutshell.pdf	A good trade-off between quality, flexibility and standardization		Valid
CONC 718.1		I2CDriver	https://autosar.org/fileadmin/user_upload/ConceptNutshells/R24-11/AUTOSAR_Concept718-InANutshell.pdf	Improved support of I2C devices in the automotive industry		Valid
CONC 712.2		Safe API for hardware accelerators	https://autosar.org/fileadmin/user_upload/ConceptNutshells/R24-11/AUTOSAR_Concept712-InANutshell.pdf	Hardware agnostic support for high performance computing like ADAS		Valid
CONC 710.7+8		Deterministic Communication with TSN	https://autosar.org/fileadmin/user_upload/ConceptNutshells/R24-11/AUTOSAR_Concept710InANutshell.pdf	Standardized application APIs for e.g. audio / video streams (IEEE1722 streams) and support of zone connection (IEEE1722 tunneling)		Valid
CONC 705.1		FeatureGraph	https://autosar.org/fileadmin/user_upload/ConceptNutshells/R24-11/AUTOSAR_Concept705InANutshell.pdf	Improve planning capabilities, overview, and usability of the standard		Valid
CONC 703.1,2+3		Automotive API basic Funtions	https://autosar.org/fileadmin/user_upload/ConceptNutshells/R24-11/AUTOSAR_Concept703-InANutshell.pdf	Controlled access to vehicle data, based on standardized services enables cross OEMs reuse of software.		Valid
CONC 697.2		Charging Interface	https://autosar.org/fileadmin/user_upload/ConceptNutshells/R24-11/AUTOSAR_Concept697-InANutshell.pdf	Simplified handling of the charging process with automated payment directly tangible for the customer or driver		Valid

Release R25-11

Concept Number	Icon	Concept Name	Challenges Overview (link)	Benefit	Status	Platform
CONC 732.1	DMA Driver	Link	Improved reusablity for SW using Direct Memory Access (DMA)		Valid	CP
CONC 731.1	AP Crypto Rework	Link	Simpler and more robust use of ara::crypto		Valid	AP
CONC 730.1	PRS CAN Tsync	Link	Enables the use of the protocol specification under the Associate Partner Light License Reduces risks of having incompatible solutions for Tsync on CAN		Valid	CP,FO
CONC 729.1	CANsec	Link	Easy-to-use secure communication over CAN XL (10 Mbit range)		Valid	AP,CP,FO
CONC 728.1	RemotePersistency	Link	Support for global, highly flexible and controlled data management		Valid	AP
CONC 726.2	Vehicle Data Protocol (remote Control)	Link	Enables reconfigurable data collection that supports the changing needs of deployed vehicles across their lifecycle		Valid	CP,FO
CONC 715.1	COMHandler	Link	Improved reusability of application software, independency of specific deployment		Valid	CP,FO
CONC 713.1	Hardware test manager on AP	Link	Supports safety requirements for HW monitoring, while reducing costs by SW reuse		Valid	AP
CONC 712.3	Safe hardware acceleration API (Specification)	Link	Hardware agnostic support for high performance computing like ADAS		Valid	AP,FO
CONC 707.2+4	DDS Support for CP (SoA, dyn. Discovery)	Link	DDS SOA functionality enables compatibility with all other DDS system, particularly AP.		Valid	CP
CONC 705.3	Feature Graph (Tagging + Tooling)	Link	Improve planning capabilities, overview, and usability of the standard		Valid	AP,CP,FO
CONC 702.1	Suspend to RAM	Link	Low power Machine state and fast responsive Adaptive Applications after startup		Valid	AP

R2X-11 (backlog)
|Concept Number|Icon|Concept Name|Challenges Overview (link)|Benefit|Status|Platform
|CONC 710.5|Deterministic Communication with TSN (Network reconfiguration)|Link|Improves fleet management in particular in case of SW updates|||CP,FO
|CONC 719.1|SENT Driver|Link|Improved support of SENT devices in the automotive industry|||CP
|CONC 727.1|Security Event Extensions and Improvements|Link|Improved vehicle protection, better support by security operation centers for lower cost.|||AP,CP,FO

ChatGPT

What is the AUTOSAR meta model?

ChatGPT:

The AUTOSAR meta-model is the formal description of the concepts, rules, and relationships used to define all AUTOSAR software and system models.
Think of it as AUTOSAR’s “model of models”: it specifies what elements exist in AUTOSAR, how they can be combined, and what constraints apply, so that AUTOSAR tools and developers share a consistent, machine-readable structure.
Key Points about the AUTOSAR Meta-Model
Definition
It’s a meta-model expressed in UML (Unified Modeling Language).
Defines the language and semantics used in AUTOSAR models (e.g., software components, interfaces, communication, ECUs, networks).
Provides the foundation for exchanging AUTOSAR models in a tool-independent way.
Levels of Abstraction
The meta-model supports AUTOSAR descriptions at multiple levels:
Application Layer: software components, ports, runnables, interfaces.
System Layer: ECUs, networks, and topology.
Basic Software Layer: OS, communication stacks, services.
Rationale
AUTOSAR is used by many different vendors and tools; the meta-model ensures interoperability.
Guarantees that when one tool exports an AUTOSAR description (via ARXML, AUTOSAR XML), another tool can import it without loss of meaning.
Concrete Representation
The meta-model is the basis of ARXML schema (AUTOSAR XML).
Each AUTOSAR release (e.g., 4.4, 4.5, Adaptive Platform) has a corresponding meta-model that evolves with new features.
Meta-Model Layers (simplified)
M3 (MOF/Meta-Object Facility): generic meta-meta model (like UML standard).
M2 (AUTOSAR Meta-Model): AUTOSAR concepts (Component, Port, ECU, etc.).
M1 (AUTOSAR Models): concrete ECU or software models built by engineers.
M0 (Runtime Instances): the actual running system in the car.
✅ In short:
The AUTOSAR meta-model is the standardized UML-based description language of AUTOSAR. It defines all the building blocks (components, ports, ECUs, services) and how they interrelate, enabling consistent design, exchange, and implementation of automotive software architectures.
Would you like me to illustrate this with a layered diagram (M3 → M0) showing how the meta-model relates to actual AUTOSAR software components?

Yes, please.

import matplotlib.pyplot as plt
# Define layers
layers = ["M3: Meta-Meta Model (MOF/UML)\nDefines generic modeling concepts",
          "M2: AUTOSAR Meta-Model\nDefines AUTOSAR concepts (Components, Ports, ECUs, Interfaces)",
          "M1: AUTOSAR Models\nConcrete models built by engineers (specific ECUs, SWCs, systems)",
          "M0: Runtime Instances\nActual software running in the vehicle"]
# Plot
fig, ax = plt.subplots(figsize=(7, 6))
ax.set_xlim(0, 1)
ax.set_ylim(0, len(layers))
# Draw rectangles for each layer
for i, text in enumerate(layers):
    y = len(layers) - i - 1
    ax.add_patch(plt.Rectangle((0.1, y + 0.2), 0.8, 0.6, facecolor="#dce6f2", edgecolor="black"))
    ax.text(0.5, y + 0.5, text, ha="center", va="center", wrap=True, fontsize=10)
# Arrows
for i in range(len(layers)-1):
    ax.arrow(0.5, len(layers)-i-0.2, 0, -0.4, head_width=0.05, head_length=0.08, fc="black", ec="black")
# Cleanup
ax.axis("off")
plt.title("AUTOSAR Meta-Model Layered View", fontsize=14)
plt.show()

What is the AUTOSAR ARXML meta model?

ChatGPT:

Great follow-up 👌
Let’s carefully separate AUTOSAR meta-model and the ARXML meta-model:

1. AUTOSAR Meta-Model (M2)
   Defined in UML by AUTOSAR consortium.
   Abstract description of all AUTOSAR concepts:
   SoftwareComponent, Port, Runnable, ECU, Communication Cluster, Service, etc.
   Tool-independent: exists as the standard definition (M2 layer in MOF 4-layer architecture).
2. ARXML Meta-Model
   AUTOSAR uses ARXML (AUTOSAR XML) as the exchange format for models.
   The ARXML schema (XSD) is generated automatically from the UML meta-model.
   So, the ARXML meta-model is the XML Schema (XSD) representation of the AUTOSAR meta-model.
   It makes the abstract UML definitions concrete so that tools can:
   Serialize AUTOSAR models into .arxml files.
   Validate models against the schema.
   Exchange models between different AUTOSAR tools/vendors.
3. Example Flow
   M2 (UML Meta-Model):
   Defines ApplicationSwComponentType with attributes (ports, runnables).
   ARXML Meta-Model (XSD):
   Defines how APPLICATION-SW-COMPONENT-TYPE looks in XML.
   M1 (ARXML Models):
   A concrete .arxml file describing a specific ECU’s software component.
   M0 (Runtime):
   The compiled and running software component in the vehicle.
4. Example Snippet
   From ARXML (derived from meta-model):

<AUTOSAR>
  <AR-PACKAGES>
    <AR-PACKAGE>
      <SHORT-NAME>MyComponents</SHORT-NAME>
      <ELEMENTS>
        <APPLICATION-SW-COMPONENT-TYPE>
          <SHORT-NAME>EngineCtrl</SHORT-NAME>
          <PORTS>
            <P-PORT-PROTOTYPE>
              <SHORT-NAME>EngineDataOut</SHORT-NAME>
            </P-PORT-PROTOTYPE>
          </PORTS>
        </APPLICATION-SW-COMPONENT-TYPE>
      </ELEMENTS>
    </AR-PACKAGE>
  </AR-PACKAGES>
</AUTOSAR>

Here:
APPLICATION-SW-COMPONENT-TYPE comes from the UML meta-model (M2).
Its allowed XML structure comes from the ARXML XSD meta-model.
The actual component EngineCtrl is a model instance (M1).
✅ In short:
The AUTOSAR ARXML meta-model is the XML Schema (XSD) representation of the AUTOSAR UML meta-model, which defines how AUTOSAR models are serialized into .arxml files for exchange and tool interoperability.
Would you like me to draw the relation between UML meta-model ↔ ARXML schema ↔ ARXML instance in the same layered diagram style I showed before?

Do you know the meaning of config-class ARXML tag?

ChatGPT:

Yes — the tag in AUTOSAR ARXML belongs to the configuration part of the meta-model (mostly for Basic Software (BSW) modules).
🔹 Meaning of CONFIG-CLASS
CONFIG-CLASS describes how a particular AUTOSAR element can be configured.
It indicates whether the configuration data is pre-compile time, link-time, or post-build.
This controls when and how configuration values can be changed during the ECU software lifecycle.
🔹 Typical Values of CONFIG-CLASS
In AUTOSAR specifications, you’ll see three standard values:
PRE-COMPILE
Configurable only at pre-compile time.
Affects generated C code directly.
Changing requires recompilation of the software.
LINK
Configurable at link time.
Values can be set without recompiling each source file, but still require re-linking.
POST-BUILD
Configurable after the ECU software is built.
Typically stored in configuration files or NVM (non-volatile memory).
Allows maximum flexibility — values can be changed for different ECU instances without recompiling or linking the software.
🔹 Example in ARXML
Here’s how you might see it:

<ECUC-MODULE-DEF>
  <SHORT-NAME>Com</SHORT-NAME>
  <PARAM-CONF-CONTAINER-DEF>
    <SHORT-NAME>ComConfig</SHORT-NAME>
    <CONFIG-CLASS>POST-BUILD</CONFIG-CLASS>
  </PARAM-CONF-CONTAINER-DEF>
</ECUC-MODULE-DEF>

Here, the Com (Communication) module has a configuration container ComConfig.
Because its CONFIG-CLASS is POST-BUILD, you can adjust ComConfig parameters after building the ECU software.
🔹 Why it matters
Flexibility vs Performance:
Pre-compile gives efficiency but less flexibility.
Post-build allows flexible product variants (same binary, different configs).
ECU Variants: Many OEMs rely on post-build configuration to adapt one ECU software build to multiple vehicle variants.
✅ In summary:
The CONFIG-CLASS ARXML tag specifies when a configuration parameter or container can be set (pre-compile, link-time, or post-build), defining the configurability and flexibility of AUTOSAR BSW modules.
Would you like me to also make a comparison table showing pros/cons of each CONFIG-CLASS (pre-compile, link, post-build) from a developer and OEM perspective?

What is the relationship between and ?

ChatGPT:

Excellent question 👍 — because and often appear close in ARXML, and they both deal with configurability. But they are not the same thing — they work at different levels of the AUTOSAR meta-model.
🔹 1. CONFIG-CLASS
Belongs to the ECUC meta-model (M2).
Defined in module definitions ( or ).
Specifies at what lifecycle stage a parameter/container/module can be configured.
Possible values:
PRE-COMPILE
LINK
POST-BUILD
👉 Think of it as: "When is this element configurable?"
🔹 2. CONFIG-VARIANT
Belongs to the ECUC description (M1), i.e. actual module instances in ARXML.
Appears in module configuration values ( or ).
Specifies which kind of configuration is actually used in a given project/instance.
Possible values:
VARIANT-PRE-COMPILE
VARIANT-LINK
VARIANT-POST-BUILD
👉 Think of it as: "How is this module configured in this ECU?"
🔹 3. Relationship Between Them
CONFIG-CLASS = capability (what is allowed) defined in the module’s meta-model (M2).
CONFIG-VARIANT = choice (what is actually used) in a concrete ECU configuration (M1).
⚙️ Rule of thumb:
CONFIG-VARIANT must comply with the CONFIG-CLASS.
If a module definition says CONFIG-CLASS = PRE-COMPILE, then its instance must use CONFIG-VARIANT = VARIANT-PRE-COMPILE.
You cannot set a POST-BUILD variant if the module was defined as PRE-COMPILE.
🔹 4. Example
Module Definition (Meta-model, M2)

<ECUC-MODULE-DEF>
  <SHORT-NAME>Com</SHORT-NAME>
  <PARAM-CONF-CONTAINER-DEF>
    <SHORT-NAME>ComConfig</SHORT-NAME>
    <CONFIG-CLASS>POST-BUILD</CONFIG-CLASS>
  </PARAM-CONF-CONTAINER-DEF>
</ECUC-MODULE-DEF>

ECU Configuration (Concrete model, M1)

<ECUC-MODULE-CONFIGURATION-VALUES>
  <SHORT-NAME>ComConfigValues</SHORT-NAME>
  <DEFINITION-REF DEST="ECUC-MODULE-DEF">/Com</DEFINITION-REF>
  <IMPLEMENTATION-CONFIG-VARIANT>VARIANT-POST-BUILD</IMPLEMENTATION-CONFIG-VARIANT>
</ECUC-MODULE-CONFIGURATION-VALUES>

Here:
Definition (CONFIG-CLASS = POST-BUILD) says Com can be configured post-build.
Instance (CONFIG-VARIANT = VARIANT-POST-BUILD) selects that option for this ECU.
✅ In summary:
CONFIG-CLASS: capability defined in the AUTOSAR module definition (M2).
CONFIG-VARIANT: actual choice used in the ECU configuration (M1).
They must be consistent: the variant is constrained by the class.
Would you like me to also prepare a side-by-side table (CONFIG-CLASS vs CONFIG-VARIANT) so it’s easy to see the difference at a glance?

ChatGPT の回答は必ずしも正しいとは限りません。重要な情報は確認するようにしてください。