AUTOSAR Methodology

By Dr Sapna PJ
•
Main working topics in AUTOSAR are
Architecture, Methodology, Application interfaces

Architecture provides a structured platform for H/W

independent software application with the help of
AUTOSAR Basic software stack (BSW)

Methodology defines the structured process and

standards that define how the data exchange between
various tools and components should occur

Specifically, it focuses on enabling a seamless

configuration process of the Basic Software (BSW) stack
during the integration of application software in the
ECU.
➢ This methodology is crucial for ensuring interoperability, efficiency, and consistency
across different stages of ECU development and integration

➢ Application interfaces: provides, standard specification of interfaces from all the

domains in terms of syntax and semantics

➢ The AUTOSAR methodology provides a framework about how software components,

basic software modules, and hardware components are designed, developed, and
integrated.

➢ It is particularly concerned with how data is exchanged between different layers (e.g.,
application software, BSW) and across various tools used in the development process.
 Data Exchange formats
➢ These are standardized formats for describing how the software and hardware
should be configured and integrated.

➢ This includes System descriptions, ECU descriptions, and configurations for

individual BSW modules.

➢ AUTOSAR provides predefined templates called Description Templates that are

used to describe the configuration and behaviour of various software and
hardware components.

➢ These templates ensure that data exchange between different stages of the
development process is smooth and standardized.
 System Description
➢ The system description contains a high-level view of the entire system,
including ECUs, communication buses, and software components.

➢ This description is generated early in the development process and is shared

across all development tools to ensure consistency.

➢The system description ensures that the integration of different components

follows a common understanding of the system’s architecture.
 ECU Description
❖The ECU description provides detailed information about a specific ECU,
including its hardware resources, communication interfaces, and how it
interacts with other ECUs in the system.

❖This description is used to configure the Basic Software (BSW) stack so that
it works seamlessly with the application software on a particular ECU.
 AUTOSAR XML (ARXML) Files
➢ In order to standardize the formal data exchange
AUTOSAR defines a standard templates called “AUTO_SAR Schema”
➢ These formal data description is based on XML file format
➢ In AUTOSAR terms these files are called “AUTOSAR_SAR XML” or ARXML

➢ In the entire design and development stages of ECU there are different kind of
ARXML files available with different set of information

➢ Example: An ARXML file could define how a specific Basic Software (BSW) module
(e.g., CAN driver) is configured, including its communication parameters,
memory usage, and timing constraints.
ARXML is a database that holds the information about
▪ System Constrains

▪ Software components

▪ ECU resources

System Constrains include

topology of the network in a vehicle
Details about different software modules present in final ECU
Grouping of software components that belongs to same functionality
Software Components include
details like data type of signals involved in the communication
Connection details between multiple software components

ECU resources include hardware specific details like processing units, memory
details, peripheral units and even contains the hardware pin details
 AUTOSAR Methodology
• It defines the work-product flow for developing an ECU software
• It also defines the dependencies between different activities on work-products
• Main activities that are involved in AUTOSAR based ECU development
• Work-product flow
▪ Abstract system design

▪ Virtual function Bus development

▪ System design

▪ Software component design

▪ Basic software modules configuration and ECU integration

 Abstract system design

❖ Abstract system design refers to the process of defining the architecture

and interactions of a system at a high level without focusing on the detailed
implementation specifics.

❖ The main goal of abstract system design is to outline the structure,

components, and behaviour of a system in a way that captures the essential
functionalities while remaining independent of the underlying technology
or specific implementations.
 Abstract system design
❖Key Elements of Abstract System Design:

1. Architecture Development Based on Functionality:

❖The design focuses on identifying all the functions the vehicle must perform,
such as lighting control, braking, steering, infotainment, etc., without the
implementation specifics or hardware configurations.

❖Functional Decomposition: Functions are broken down into smaller, more

manageable sub-functions or modules.

❖These are described in terms of their role in the vehicle and how they interact
with other functions or systems.
2. Abstract System Description:

❖ An Abstract System Description is created that represents the entire vehicle's

functionality in a high-level, abstract view.

❖ This description does not deal with specific software components or hardware
(ECUs) at this stage, but rather the system’s overarching functions.

❖ System-Level View: It defines how different functions (e.g., transmission control,

stability control, driver assistance) are expected to interact in the vehicle,
without considering detailed software or hardware implementations.

❖ Vehicle Topology (Optional): In some cases, the abstract description may also
include details about the vehicle topology (i.e., how the vehicle’s systems and
ECUs are connected) and how specific vehicle functions are mapped to ECUs.
3. Output: Abstract System Description ARXML

• The output of this design stage is a structured AUTOSAR XML (ARXML) file
that describes the functional aspects of the vehicle.

• This ARXML file acts as an abstract representation of the system's

functionality and serves as a critical input for further design stages,
especially for the development of the Virtual Functional Bus (VFB).

4. Functional Mappings to ECUs:

• Although the focus is on functionality, the abstract design may optionally map
certain functions to specific ECUs in the vehicle.
• This mapping provides an early view of how functions will be distributed
across the hardware platform, helping engineers visualize the system’s
integration with the vehicle’s electronics.
Example: Abstract System Design for an Autonomous Driving Feature

Imagine a vehicle system with a driver assistance feature, such as lane-keeping

assistance (LKA). The goal is to capture this feature at a functional level during the
abstract system design stage.

1. Function Decomposition:

The LKA feature is broken down into its sub-functions:

➢ Lane Detection: Detecting lane markings using cameras.

➢ Steering Control: Adjusting the steering to keep the vehicle within the lane.

➢ Driver Warning: Issuing a warning if the system detects that the vehicle is leaving the lane
without the driver’s input.
2. Abstract System Description:

The abstract system description will define these functions and how they interact:
➢Lane Detection Function communicates the detected lane information to the Steering
Control Function.

➢Driver Warning Function is triggered by the Steering Control Function when the
system detects a lane departure.

• This abstract view does not yet specify which hardware (ECUs) will run these
functions, but it establishes the high-level interaction.

3. Mapping to ECUs (Optional):

• In some cases, the abstract system description will include preliminary mappings of
functions to ECUs:
•Lane Detection could be mapped to an ECU connected to the vehicle’s cameras.

•Steering Control might be mapped to the power steering ECU.

•Driver Warning could be linked to the vehicle’s central control ECU.

4. ARXML Output:

•The output of this stage would be an ARXML file that captures the high-level
description of the LKA functionality and how these functions are intended to
interact.

•This file is used as an input to further develop the VFB, which will facilitate
the communication between these functions as the design becomes more
detailed.
 Virtual Functional Bus [VFB]
➢ Itis an abstract communication concept that enables interaction between
different software components
➢ The VFB provides an abstraction layer that allows software components to
communicate through well-defined interfaces, irrespective of whether they
are on the same ECU or distributed across multiple ECUs.
➢ Software components communicate via the VFB using standardized ports. The
actual data flow is managed by the AUTOSAR Runtime Environment (RTE)
➢ VFB helps decouple the software architecture from the hardware
architecture. Developers can focus on designing software components without
worrying about the actual placement of components or network details.
➢ VFB in AUTOSAR is a key concept for managing communication in a modular,
hardware-independent way, ensuring portability and scalability across
different automotive systems.
Virtual Functional Bus [VFB] Design
✓ In case , if the abstract system design is not done. The development of the vehicle
system directly starts by defining the VFB.

✓ This concept allows the system engineer and software component engineer to model
the entire vehicle system by defining the software components (SWCs) and by
creating Virtual communication paths between the software components

✓ Software components is the simplest form of an application with certain functionality

Virtual Functional Bus [VFB] Design
✓ During VFB design, SWCs are connected through a common point of interaction
called Ports

✓ The port of a software component is associated with port interface and then the
port interface controls what can be communicated through ports

✓ Considered as a helpful test environment during architecture development phase

✓ In short VFB provides an abstract view of all the software components in the
final system and also enables the development of software
 Software component Design
❖Software components can be implemented according to the definitions
available in the VFB

❖Based on the external components connections defined in the VFB,

Internal behaviour elements of the software are defined to implement the
software

❖Internalbehaviour elements are used to define how the software

component will interact with the RTE during runtime.

❖InternalBehaviour elements: runnable entities, RTE events, Exclusive

areas, Data access definitions

❖The implementation of a software component can be done independent from

the configuration of the ECU
 AUTOSAR Methodology
• It defines the work-product flow for developing an ECU software
• It also defines the dependencies between different activities on work-products
• Main activities that are involved in AUTOSAR based ECU development
• Work-product flow
▪ Abstract system design

▪ Virtual function Bus development

▪ System design

▪ Software component design

▪ Basic software modules configuration and ECU integration

 System design
▪ In the system design phase of the AUTOSAR workflow, the VFB abstract design
is transformed into a detailed and deployable system architecture.

▪ This phase includes defining the ECU topology, Distributing software

components across multiple ECUs, and defining how these ECUs will
communicate through a network.

▪ ECU Topology Definition:

▪ This topology outlines how the different ECUs are physically and logically
connected, what their roles are, and how they communicate with each
other.
ECU Distribution: Software components developed during earlier stages (e.g., the
Lane Detection, Steering Control, and Driver Warning components from Lane
Keeping Assistance example) are assigned to specific ECUs based on their
function and hardware requirements

• The software components (SWCs) designed earlier are now deployed across
multiple ECUs. For example: The Lane Detection Component might be deployed
to the Vision Processing ECU.

• The Steering Control Component could be deployed to the Power Steering ECU.

• The Driver Warning Component could reside on a Central Control ECU.

• The deployment takes into account each ECU's capabilities, processing power,
and the communication interfaces needed to support the functionality.
A communication matrix is defined in the system design phase, which outlines how
different ECUs communicate with each other and exchange data. This matrix
contains critical details such as:

• Message Frames: The structure of the messages that will be transmitted between
ECUs. This includes the message IDs, the length of the data fields, and how often
these messages are sent.

• Participating Nodes/ECUs: Which ECUs are involved in the communication. For

example, the Vision Processing ECU might send lane data to the Power Steering
ECU.

• CAN PDUs: Protocol Data Units are the communication units used in CAN .Each PDU
represents a message or a set of data being transmitted between ECUs. The
communication matrix defines all the PDUs used in the system, specifying their
structure, content, and communication cycles.
• Source and Destination Nodes for PDUs: For each PDU, the matrix specifies which
ECU will generate (source) the data and which ECU will receive (destination) it.

• For example, the Lane Detection Component on the Vision Processing ECU is the
source of lane position data, and the Steering Control Component on the Power
Steering ECU is the destination.

• The output of this system design phase is the System Description ARXML file, which
acts as a blueprint for the next steps in development. This file contains
 Software Components Details: Information about the software components and
how they are deployed across the ECUs.
 Network Topology: The layout of ECUs and their communication paths, defining
how the ECUs are connected and the type of communication protocols used (e.g., CAN,
FlexRay, Ethernet).
 Communication Matrix: Details about the messages, PDUs, and communication
paths between the ECUs.
 BSW configuration and ECU integration
• AUTOSAR basic software consists of different dedicated software modules or software
stack that consists of different functionalities like

Communication Control
Memory Management
Mode Management
Diagnostics and Error Handling

• BSW modules are independent of software components[SWCs] and the BSW

module configuration can start once the network matrix for the specific ECU
is available
• From the system description ARXML which contains details about multiple ECUs
ECU extract of a specific ECU that is “[Link]” is given as
an input to start the ECU integration activities

• This Arxml file contains only information related to a single ECU

• Fig Shows the different types of arxml files that are involved in both system design
and ECU design phases

• These are the main steps that are involved in the AUTOSAR methodology
that helps the development partners to forsee all support activities, usage of
different description files, use of tools in Autosar

•
System Design and Feature Definition

define the features

identify the software components (SWCs)

Map each of these software components to different

ECUs
 Design Flow
The process of designing a vehicle and managing the ECU architecture, particularly in
an AUTOSAR-based system, includes:

1. System Design and Feature Definition

• When designing a vehicle, the first step is to define the features you require (e.g.,
ADAS, infotainment, power management).

• After feature selection, identify the software components (SWCs) that will fulfil
these features. These are specific functional blocks like sensor control, data
processing, and actuation.

• The next step is to map each of these software components to different ECUs . ECUs
are the hardware controllers that run these software components.
• Multiple ECUs in a Simple Network
• For simplicity, imagine a network where all the ECUs are interconnected, forming a
network of vehicle subsystems.
• Each ECU contains various software layers: Basic Software (BSW), Runtime
Environment (RTE), and the Application Layer.
• Communicating the Architecture

• When an OEM develops this system architecture, it needs to communicate the design
effectively to the development teams.

• Drawing or visualizing the system is not sufficient for understanding the

complexities of the interactions between ECUs, SWCs, and other system
components.
 Extracting into an ARXML file

The system design is captured using AUTOSAR

Authoring Tools

These tools enable model-based development

The system can be designed, defining the software

architecture
• Communicating the Architecture

• When an OEM develops this system architecture, it needs to communicate the design
effectively to the development teams.

• Drawing or visualizing the system is not sufficient for understanding the

complexities of the interactions between ECUs, SWCs, and other system
components.

• System Design Tools

• To convey the architecture more accurately, the system design is captured using AUTOSAR
Authoring Tools such as AUTOSAR Builder or System Desk by D-Space.

• These tools enable model-based development. The system can be designed, defining the
software architecture and extracting it into an ARXML file.

• Even MATLAB can be used as an authoring tool to model the system and generate ARXML,
•ARXML files contain crucial information for designing the system, such as:
Hardware topology (how different hardware elements like ECUs are connected).
Software components in each ECU.
Communication matrix, that defines the data exchange between different ECUs.

•This ARXML is a system description that holds the entire system's information.
• ECU-Level Description

• At the ECU level, each ECU has multiple software components (SWCs). For example, an
ECU might have two SWCs, A and B.

• Each SWC will have its own interfaces with other software layers (e.g., RTE) or with
hardware via the BSW.

• The Software Component Description defines the behaviour, interfaces, and

configuration of each software component in the system. This information is also stored in
ARXML format.
ECU-Level Description

Each ECU has multiple software components (SWCs

Each SWC will have its own interfaces with other
software layers (e.g., RTE) or with hardware via the
BSW.

The Software Component Description defines

 the ARXML file can be imported into EB Tresos, which understands the
system and generates the necessary ports and interfaces to connect the
RTE to the application software.

Configuration of Basic Software (BSW)

MCAL drivers, Communication stack (ComStack),

Memory stack (MemStack), etc.

To configure the BSW, tools like EB Tresos Studio are

used

EB Tresos uses its own formats, such as .xdm or .epc files.

• Configuration of Basic Software (BSW)

• The next step is configuring the Basic Software (BSW), which includes the
MCAL drivers, communication stack (ComStack), memory stack
(MemStack), etc.

• To configure the BSW, tools like EB Tresos Studio are used. In AUTOSAR, the
configuration is stored in ARXML, but EB Tresos uses its own formats, such as
.xdm or .epc files.

• Although system design is done in other tools, the ARXML file can be imported into
EB Tresos, which understands the system and generates the necessary ports and
interfaces to connect the RTE to the application software.
• Bringing it All Together

• Once the BSW and SWCs are configured, EB Tresos Studio ensures that all the
necessary configurations are made to compile both the application software
and the BSW together.

• Tresos will also derive all the required interfaces between the layers (BSW,
RTE, and application) so that the entire system operates seamlessly.
 Summary:
• Define features and map software components to ECUs.

• Use System design tools (AUTOSAR Builder, SystemDesk, MATLAB) to model the
system and generate ARXML.

• The ARXML file contains system-level information, which is key to system

description and software component description.

• Configure the BSW using tools like EB Tresos, which supports ARXML and manages all
configurations.

• Compile the BSW and application together to create a working ECU system.

• This systematic approach ensures that the design, configuration, and development of
ECUs and their interactions within the network are efficient and AUTOSAR-
compliant.
 System Configuration
• System Description vs. ECU Configuration

• When developing a vehicle system with multiple ECUs (for example, 200 ECUs), the
OEM (Original Equipment Manufacturer) creates a System Description file.

• This System Description file contains information about the entire system,
including the hardware topology, software components (SWCs), and
communication matrices for all ECUs in the vehicle.

• However, not every vendor or supplier (like Continental, Bosch, EB) working
on a specific ECU needs access to the entire vehicle's system description.
Instead, they only require information related to the specific ECU they are
working on.
• 2. Extracting ECU-Specific Information

• To ensure that vendors only receive relevant information, the OEM will extract the
details of the particular ECU from the System Description.

• This extracted file, called an ECU Extract, contains only the information needed
for that particular ECU, such as:
 The software components (SWCs) allocated to the ECU.

 The communication interfaces (e.g., what other ECUs it communicates with).

 The hardware resources it will use.

• 3. ECU Extract to ECU Configuration Description

• The ECU Extract is then fed into an AUTOSAR configuration tool (like EB
Tresos Studio).

• The tool uses the ECU Extract to generate an ECU Configuration Description.
This configuration description includes all the detailed configurations for that
specific ECU, such as:
 BSW (Basic Software) configurations (e.g., MCAL drivers, ComStack, MemStack).

 RTE (Runtime Environment) configurations.

• This file becomes the basis for configuring how the ECU will interact with the
rest of the system and execute its assigned tasks.
Tool-Driven Configuration and Code Generation

• Using the ECU Configuration Description, the AUTOSAR tool (e.g., EB Tresos)
can now generate all necessary configurations for the ECU, including:
 RTE generation, which defines the connections between the SWCs and the basic
software, managing communication between different components.

 BSW generation, which handles the low-level drivers and software required to
control the hardware of the ECU.
Tool-Driven Configuration and Code Generation

➢ This process of generating the configuration from the ECU description is handled by
a code generator within the tool.

➢ The generated code ensures that the software components, RTE, and BSW
all work together seamlessly on the ECU.
• Distribution of Work Among Vendors

• In large vehicle development projects, different vendors may be responsible for

different ECUs:
 Continental might handle the powertrain ECU.

 Bosch might develop the ADAS ECU.

 EB could be working on the infotainment ECU.

• Each of these vendors only receives the ECU Extract specific to their assigned
ECU, rather than the whole vehicle's system description. This reduces complexity
and protects sensitive information.
• Summary of Process Flow

• System Description Creation: The OEM designs the entire vehicle system and captures
it in a System Description file.

• ECU Extract: For each ECU, a relevant ECU Extract is generated from the system
description, containing the necessary details for that specific ECU.

• ECU Configuration: The ECU Extract is imported into an AUTOSAR configuration tool,
where it is used to create an ECU Configuration Description.

• Code Generation: The tool generates the RTE and BSW configurations and code based
on the ECU Configuration Description, which ensures the ECU operates correctly within
the overall vehicle system.

• Vendor-Specific Development: Each vendor (e.g., Continental, Bosch, EB) receives only
the relevant ECU information they need to develop and configure their assigned ECUs.
Migration and Integration
strategies
➢Conformance Class 1 represents the simplest level of functionality for a given BSW
module.
➢It supports basic operations that are required to make the module functional in an
AUTOSAR-compliant system.
➢For example, in communication modules like CAN, LIN, or FlexRay, CC1 provides
fundamental features like message transmission, reception, and basic network
management.
➢CC1 focuses on a basic and standardized configuration. It may not support advanced
features like diagnostics, fault tolerance, or scalability across complex networks.
It's ideal for systems that require minimal configuration and a simple ECU setup.
some stacks or modules of autosar are integrated
• There are some stacks or modules of autosar which are already integrated some
base software modules plus RTE and application which are autosar compliant

• It can be a complete stack ( because no point in adding one module)

• For migration we will start intoducing one by one stack

• Conformance class 3 is the complete stack. i.e fully autosar compliant. The use of
complex device drivers must be very less
Conformance class 3 is the complete stack
• In software development, the lifecycle of creating executable software from source code
involves multiple phases: pre-compile time, link time, and post-build time.

• Each phase handles specific tasks and configurations that ultimately result in a
fully operational embedded system

• Pre-Compile Time refers to the phase before the actual compilation of the
source code. This is when configuration options, constants, or conditional inclusions
are defined.

• The AUTOSAR configuration tools generate files that define system-specific

parameters (such as communication matrix, memory layout, etc.).
 Example:
➢ Configuring a CAN driver in AUTOSAR. During the pre-compile time, configuration
files are generated using a tool like EB Tresos or Vector DaVinci, and these files
contain:

➢ CAN message IDs.

➢ Memory buffer sizes.

➢ Whether the ECU uses CANFD (CAN with Flexible Data rate) or regular CAN.

➢ The compiler has not started yet, but these configurations determine which
features are included
• Link Time occurs after the code has been compiled into object files (.o or .obj)
but before it is made into an executable.

• The linker takes these compiled files and combines them into one cohesive
program.

• The linker resolves external references (e.g., one module calling a function in
another module).

• It allocates memory and ensures that functions and data are located in
appropriate memory areas (RAM, ROM, Flash, etc.).

• Library linking happens at this stage. Standard libraries, runtime libraries, or

AUTOSAR BSW libraries are linked to the compiled code.
• Example:

In an AUTOSAR system, after compiling the ECU software components (like a CAN
driver, diagnostic services, or memory management), the linker:

• Links the CAN driver object files with the rest of the BSW and application code.

• Places different segments of the code (e.g., bootloader in Flash, data buffers in RAM).

• Resolves references to hardware registers, linking specific memory addresses

where peripherals (like CAN controllers) are located.

• For instance, if the CAN driver object file references certain CAN controller
hardware registers, the linker assigns those references to actual memory addresses based
on the ECU's memory map.
• Post-Build Time occurs after the final executable has been generated.

• During this stage, the system is often configured for deployment, and some settings
can be adjusted without recompiling the source code.

• This phase involves creating downloadable images or configuration data that can be
updated after the build process without modifying the core application code.

• Configuration files or parameters that can be adjusted after the build, often
stored in non-volatile memory (EEPROM, Flash).

• Memory initialization files can be generated at this stage to preload certain data
into the system.

• Settings related to ECU calibration, variant coding, or debugging information

may be configured here.
• Example:

• In an AUTOSAR context, Post-Build Time allows certain configurations to be

adjusted after the executable is built.

• For example, if the CAN message IDs or ECU IDs change during production,
they can be updated without recompiling the code.

• These settings are typically stored in Flash memory or EEPROM and are read
by the application during runtime.

• For instance: The CAN driver may use default message IDs during the build
process, but these IDs can be changed post-build to reflect different production
variants.

• Diagnostic parameters or calibration data for engine control may be

adjusted without changing the entire firmware.
• Summary of the Three Phases:

• Pre-Compile Time:
 Configures system behavior before compilation.

 Example: Defining CAN message IDs, enabling/disabling features via macros.

• Link Time:
 Combines compiled object files into an executable.

 Example: Linking CAN driver code with other software modules and placing functions into
Flash or RAM.

• Post-Build Time:
 Modifies configurations and settings after the build process.

 Example: Changing CAN message IDs or diagnostic parameters stored in EEPROM without
recompiling the software.
 EB Tresos
• EB Tresos Studio is a widely used tool in the automotive industry for configuring
and generating AUTOSAR Basic Software (BSW) modules, as well as for
configuring the ECU (Electronic Control Unit) software.

• It simplifies the process of integrating and configuring various

components of an AUTOSAR-compliant system.
We can import the files received from OEM. which can be Configuring the modules or stack
and then generating the source code in the form of .c and .h
➢ In EB Tresos Studio, .xdm files (XML Description Model) are used to store system
configuration data, related to the AUTOSAR configuration.

➢ These files contain metadata about various components of the AUTOSAR system, such as
ECU configuration, system settings, and communication protocols.

➢ Configuration Data: These files include configuration information for the ECU or the
entire system. They define how different modules interact with each other.

➢ AUTOSAR Project Structure: .xdm files help in managing the hierarchical structure of
the AUTOSAR project, enabling easy navigation of configuration parameters.

➢ Integration with Other Tools: .xdm files are often generated or consumed by other tools,
such as Vector DaVinci, allowing for seamless integration across the AUTOSAR
toolchain.

➢ Customization: These files can be customized and loaded into EB Tresos Studio to reflect
specific configurations required for your system design.
System description files can be imported into tresos studio
as tdb (tresos DB file) files into the System model .

It stores all the software component descriptions ,

system descriptions and some of the legacy formats,
BSWMD,

When tool requests some information via configuration

tdb files will provide information
There are some specialized editors like Rte editor,
connection and composition editor, system editor

The moment we create some module it will be stored in

ECU configuration i.e xdm files
• system description files can be imported into tresos studio as tdb (tresos DB file) files
into the System model .
• It is literally a database. It stores all the software component descriptions , system
descriptions and some of the legacy formats, BSWMD,
• Tdb files will have sql tables to hold the information
• The information will be provided to the tool
• When tool requests some information via configuration tdb files will provide
information
• There are some specialized editors like rte editor, connection and composition editor,
system editor where you can do some specialised jobs
• the moment we create some module it will be stored in ECU configuration i.e xdm
files
Graphical user interface(GUI)
and basic configuration features
 Assistants and Wizards
• "Assistant" and "Wizards" in EB Tresos Studio refer to guided workflows or automation
features that help users configure complex systems more easily and accurately.

• These features streamline the process of setting up AUTOSAR configurations, reducing

the chances of errors and improving efficiency

• The assistant feature in EB Tresos Studio acts as a step-by-step guide that helps users
configure certain aspects of their AUTOSAR environment.

• It provides real-time suggestions and validations based on the current state of the
configuration.

• Usage: If you're configuring a particular module (e.g., ComStack or MemStack), the assistant
will prompt you with configuration options, highlight potential errors or
inconsistencies, and suggest best practices according to AUTOSAR standards.
 Wizards in EB Tresos Studio
• Wizards are specialized tools within EB Tresos that automate certain tasks.

• They are designed to simplify the configuration process by pre-filling or

guiding the user through commonly required settings, such as setting up the
Basic Software (BSW) or RTE (Runtime Environment) layers.

• For example, when creating a new project in EB Tresos, the wizard can guide you
through the process of selecting the AUTOSAR version, defining ECU-specific
parameters, and configuring the required Basic Software modules.
 Allows users to visually define how different software
components are composed within the system

Specifies which components interact with each other and

how they are organized hierarchically.
Facilitates the creation and management of connections
between components, such as data flows, service calls,
and event notifications.
 AUTOSAR allows software components (SWCs) to be organized in a
hierarchical structure. This means that certain components can be
nested within others.

These hierarchical relationships are useful for

organizing complex systems but becomes difficult to
manage when generating configurations like RTE or
ECU extracts.
In a flat representation, the nested (or hierarchical)
relationships are removed, and the software components
are represented as a simple list.

So instead of SWCs being contained within one

another, they are all treated as individual, standalone
components