1
.
Introduction to
AUTOSAR
The software in the field of automotive electronics mainly belongs to embedded software. Therefore, its development stage is similar to that of other embedded systems
software development. Due to the lack of resources of embedded hardware itself, various hardware products have a wide variety and their differences,
As well as the gradual development of the overall embedded system software, the initial software design and development is mainly closed. This helps to open
Develop a software system specifically designed for a specific hardware body and fully optimize the use of resources. Such a software system is aimed at
Designed for specific hardware and specific applications, its full use of hardware resources and the execution efficiency of the software itself are undoubtedly
is very high.
However, with the gradual development of the hardware itself, its available resources are already quite sufficient. On the other hand, the field of automotive electronics
Application requirements are becoming more complex, and the software itself is becoming more complex. Therefore, both automakers and component manufacturers feel soft
standardization issues. Issues of software manageability, reusability, tailorability, and quality assurance were raised
on the agenda.
The proposal of AUTOSAR
is based on the requirements of the above software development.
and component suppliers, including
BWM, DaimlerChrysler, Ford Motor, PSA Peugeot,
Toyota Motor, Volkswagen AG, Bosch, Continental, Siemens VDO
等。
AUTOSAR
is an open software structure proposed for the specific field of automotive electronics. its main idea
The idea is to make software design and development easier to manage, software systems easier to transplant, tailor, and better maintainability and quality
ensure.
The goals proposed by the
AUTOSAR organization and the functional areas it focuses on are listed in the table below:
In order to achieve the above project goals,
AUTOSAR
adopts
The solutions used and their benefits can be outlined as follows:
2
.
AUTOSAR
software structure
2.1
Composition and layering of AUTOSAR software
The software components of AUTOSAR
can be represented by the following diagram:
For some of the components shown in the above figure, they can be layered according to their functions and interrelationships, as shown in the following figure:
·
Microcontroller Abstraction Layer
This layer is the lowest layer in the base software. It contains drivers, which are software modules for
the μC
Internal devices and memory mapped
μC
external devices are accessed.
·
ECU
abstraction layer
This layer interfaces with the microcontroller abstraction layer. It also contains drivers for external devices. It provides access to peripheral
APIs
are provided
regardless of the location of these peripherals
(
inside or outside the μC
)
or their
connection to
the μC
( port
pin, interface type
)
.
·
The service layer
is the highest layer in the basic software, and it is related to the application software: when the access to the
I/O
signal
When included in
the ECU
abstraction layer, the service layer provides:
Operating system function
Vehicle
network communication and management services
Storage management (
NVRAM
management)
Diagnostic
service (including
UDS
communication and error memory)
ECU
status management
2.2 RTE
The runtime environment
RTE
is the core component of
the AUTOSAR ECU
architecture.
RTE
is
AUTOSAR
virtual
Virtual Function Bus (
Virtual Function Bus
,
VFB
) interface (for a specific
ECU
) implementation, therefore,
It provides basic services for communication between application software components and also facilitates access to the
basic software comprising
the OS
components.
Application software components contain system software independent of
the CPU
and location. This means that, in order to satisfy the
With some restrictions made by the system designer, application components can be mapped to any valid
ECU during system configuration
.
RTE
is responsible for ensuring that these components can communicate.
RTE
and
OS, AUTOSAR COM
and other basic software modules (
BSW
) are
VFB
(
Virtual Functional
Bus
) implementation of the concept.
RTE
implements the interface of
the AUTOSAR VFB
and thus the
AUTOSAR
software components
communication between.
RTE
is the core of
the AUTOSAR ECU
system
,
which provides
the basic service for communication between
AUTOSAR software components.
services, which act as methods through which
AUROSAR
software components can access including
OS
and communication services
basic software modules.
2.3
System Services
A system service is a set of modules and functions that can be used by all hierarchical modules. e.g. real-time operating system, error management
and library functions. Provides basic services for applications and basic software modules. It contains the functions shown in the figure below:
2.3.1 AUTOSING THE
AUTOSAR OS
provides all basic services for real-time applications, namely interrupt handling, scheduling, system time and clock
Synchronization, local message handling, and error detection mechanisms. All services are hidden behind a well-defined
API
. application
The connection to
OS
and communication layer is only through
API
.
The basic features of AUTOSAR OS
include:
·
static configuration
·
Ability to infer real-time system performance
·
Provides priority-based scheduling policies
·
Provides runtime protection functions (storage, timing, etc.)
·
Can be hosted on low-end controllers and requires no additional resources
It includes the following aspects:
·
real-time operating system
A real-time operating system in an embedded automotive
ECU
forms the basis for the dynamic behavior of the software. it manages tasks and
Scheduling of software, data flow between different tasks, and provide monitoring and error handling functions.
However, in automotive systems, the need for operating systems is focused on specific areas. The operating system used must
Runs efficiently and takes up little storage space.
In multimedia and telematics applications, the feature set provided by the operating system and the available computing resources vary widely.
different.
On top of
pure task management,
complex data processing (e.g. streaming, fast file
system, etc.), storage management and even a graphical user interface.
The typical domain of an automotive
OS
covers the core features of scheduling and synchronization. In
AUTOSAR
, discussed above
The additional features of are outside the scope of
the OS and
are covered by
other
WP4.2.2.1
working packages (eg
SPAL ).
Under
the architectural constraints of
AUTOSAR it is not possible to integrate other
OS (for example, QNX , VxWorks and
The feature set of Windows CE,
etc.) is integrated into the overall
OS/
communication
/
driver structure. Therefore,
AUTOSAR OS
Only core features are considered.
·
core operating system
The OSEK/VDK
operating system is widely used in the automotive industry and has proven
There are
ECU
types used.
The concepts introduced by OSEK OS
are widely understood, and the automotive industry is designing based on
OSEK OS
system has many years of experience.
OSEK OS
is an event-triggered operating system. This paves the way for the design and maintenance of
AUTOSAR- based
systems
protection provides a high degree of flexibility. Event firing enables the freedom to choose which events drive scheduling at runtime, e.g.
Corner inversion, local time sources, global time sources, error occurrences, and more.
For these reasons, the core functions of
AUTOSAR OS
must be based on
OSEK OS
.
OSEK OS
Special
The following features are provided to support
AUTOSAR
:
Fixed priority-based scheduling
Interrupt handling function
Only interrupts have higher priority than tasks
Some protective measures against misuse of
OS
services
StartOS()
and
StartupHook
startup interface
ShutdownOS()
and
ShutdownHook
shutdown interface
AUTOSAR OS
is based on
OSEK OS
meaning applications are backward compatible.
Written for
OSEK OS
The applications can run on
AUTOSAR OS
. However, with
some
new
Feature requirements restrict the use of existing
OSEK OS features.
Example: Implementing timing and
Memory protection efficiency will be very low. In addition,
AUTOSAR OS
extends some existing features, such as direct communication
The overtimer drives the counter.
The API
provided by
AUTOSAR OS is backward compatible with the API of OSEK OS . New requirements as functional extensions
to integrate.
The API of AUTOSAR OS
to
OSEK OS
extension
is as follows:
·
statically defined schedule
In many applications it is necessary to statically define the activities of a set of interrelated tasks. This is used in stream-based
Data consistency is ensured in the design, synchronization with time-triggered networks ensures correct runtime phasing, and more.
Time-triggered operating systems are often used as a solution to this problem. Time, however, is simply an event,
So any event-triggered
OS
, including
OSEK OS
, will implement a static
A scheduler for scheduling real-time software.
·
monitoring function
Monitoring functions detect errors at the appropriate stage of execution, not at the moment they occur. Therefore, the monitoring function is
Catching failures at runtime, not preventing failures.
·
Protective function
The AUTOSAR concept requires
OS applications
from multiple sources
to coexist on the same processor. To prevent these OS should
Unexpected interactions between users need to provide protection mechanisms.
·
Timer Service
The Timer Service provides software timers for applications and base software.
The core of the timing mechanism is already provided by
OSEK OS
' counters and alarm clocks. If you want to provide a general-purpose software
At this time, some supplementary features need to be added to
AUTOSAR OS
.
·
time-triggered operating system
A time-triggered operating system implements a scheduler for statically scheduled real-time software in automotive electronic control units
device.
In addition, the operating system provides all the basic services for real-time applications, namely interrupt handling, scheduling, system time and
Clock synchronization, local message handling, and error detection mechanisms.
All services are hidden behind a well-defined
API
. The connection between the application and
the OS
and the communication layer is only through
the API
.
For a particular application, the operating system can be configured to include only the services required by that application. Therefore the operating system's
Resource requirements are kept to a minimum.
2.3.2 BSW
Scheduler
The BSW
scheduler is part of system services, so it provides services to all modules at all levels. However, with
Unlike other
BSW
modules,
the BSW
scheduler provides
integrated
concepts and services.
The BSW
scheduler provides methods to:
Embed the implementation of the
BSW
module into
the AUTOSAR OS
context
Trigger
the main processing functions of the
BSW module
Apply
the data consistency mechanism of the
BSW module
The task of the integrator is
to apply
the given method ( provided by
AUTOSAR OS
) in a specific project environment with good
A defined and efficient way to assemble
BSW
modules.
This also means that
BSW
scheduler just
uses
AUTOSAR OS
. It does not conflict with the
AUTOSAR OS
scheduler
sudden.
The implementation of the BSW
scheduler is based on:
BSW
module description
of
BSW module
BSW
scheduler configuration
2.3.3
Mode Management
The schema management cluster consists of three basic software modules:
·
ECU
state manager, which controls
the startup phase of the
AUTOSAR BSW module, including the startup of
the OS ;
·
Communication manager, responsible for network resource management;
·
The watchdog manager triggers the watchdog based on the live state of the application software.
2.3.3.1 ECU
State Manager
The ECU
State Manager is a basic software module that manages the state of
the ECU
(
OFF
,
RUN
,
SLEEP
) to
and transitions between these states (transitional states:
STARTUP
,
WAKEUP
,
SHUTDOWN
). In detail,
ECU
State Manager:
·
Responsible for initialization and
de-initialization
of all basic software modules, including
OS
and
RTE
;
·
shutting down the ECU
when required in cooperation with so-called resource managers (e.g. communication managers)
;
·
Manages all wake-up events and configures the ECU
to
SLEEP
state when required .
To accomplish all these tasks,
the ECU
State Manager provides some important protocols:
·
RUN
request protocol to adjust whether
the ECU
is kept active or ready to shut down,
·
A wake-up confirmation protocol to distinguish "real" wake-up events from "erratic" wake-up events,
·
Time Triggered Increased Inoperation Protocol (
Time Triggered Increased Inoperation - TTII
),
Allows
the ECU
to enter more power-saving sleep states.
The ECU
state manager must support independent preprocessing actions and transitions to start
the ECU
or transition it to low power
state (e.g. hibernate
/
standby). By making good use of the features and capabilities of the
ECU
State Manager, this module
Can be used to enforce predefined policies for power consumption, thus providing
efficient energy management of
the ECU .
Features and benefits of the ECU
State Manager include:
·
Initializes and closes basic software modules.
·
Standardized definition of ECU
main states.
·
More non-working states triggered by time.
2.3.3.2
Watchdog Manager
The watchdog manager is
a basic software module of the standardized basic software architecture of
AUTOSAR (Service Hierarchy).
It monitors the reliability of application execution relative to timing constraints.
A layered architectural approach enables the separation of application timing constraints and watchdog hardware timing constraints. Based on this, the watchdog manages
The timer provides liveness monitoring for some individual applications while triggering the watchdog hardware.
The Watchdog Manager provides the following features:
·
Supervise multiple individual applications residing in
the ECU
that have independent timing constraints and require special supervision
Behavior and survival status at runtime.
·
Each individual monitored entity has a failure response mechanism.
·
Supervision can be turned off for individual applications without violating watchdog triggers (eg for forbidden applications).
·
Trigger internal or external, standard or window, watchdog via watchdog driver. (
internal or external,
standard or window, watchdog
) access to the internal or external watchdog is handled by the watchdog interface.
·
Select watchdog mode ( Off Mode, Slow Mode, Fast Mode ) according to
ECU status and hardware performance.
2.3.3.3
Communication manager
The communication manager collects and coordinates access requests from communication requesters (users).
The purpose of the Communication Manager is to:
·
Simplifies the use of communication protocol stacks. Including the initialization of the communication stack, and simple network management.
·
Adjust
the availability of the communication stack (allowing to send and receive messages) of several independent software components on
the ECU .
·
Temporarily inhibits sending messages to prevent
the ECU from
(actively) waking up the physical channel.
·
Multiple physical channels of
an ECU
are controlled by implementing a state machine for each physical channel .
·
It is possible to force
the ECU
to keep the physical channel in "
silent
communication" mode.
·
Allocate all resources required by the requested communication mode, simplifying resource management.
The communication manager defines a "communication mode", which indicates whether a particular physical channel is available to the application, and if
How to use (send
/
receive, receive only, neither send nor receive).
2.4
Diagnostic service
2.4.1
Diagnostic Event Manager
Diagnostic Event Manager
DEM
(
Diagnostic Event Manager
) is a subcomponent, like
AUTOSAR
Diagnostic Communications Manager (
DCM
) and Functional Inhibition Manager (
FIM
) within the diagnostic module. It is responsible for processing and storing diagnostics
Events (errors) and associated
FreezeFrame
data.
DEM
further provides fault information to
DCM
(e.g. engaged in
Read all stored
DTCs
(
Diagnostic Trouble Code
) from the hardware memory.
DEM
to application layer,
DCM
and
FIM
Provide an interface. Defines optional filtering services.
2.4.2
Feature Disable Manager
Function Inhibition Manager
FIM
(
Function Inhibition Manager
) is responsible for providing software components and software component functions
capable control mechanism. A function consists of one, several or some
executable entities with the same permission
/ prohibition conditions.
by
FIM
method, the prohibition of these functions can be configured or even modified. Therefore, the adaptability of functions in the new system environment is greatly improved.
Responsiveness.
Functions in the sense of FIM
are distinct and separate types from executable entities. Executable entities are mainly determined by scheduling requirements
distinguish. In contrast, functions are classified by prohibition conditions.
The FIM
service focuses on the functions of
the SW-C
, but does not
limited to this.
The function of BSW
can also use
FIM
service.
A function is assigned an identifier (
FID – function identifier
), and the prohibition conditions for that specific identifier.
Functions obtain their respective permission states before execution. If a prohibition condition is applied to a particular identifier, the corresponding function will
No longer executed.
FIM is closely related
to
DEM
because diagnostic events and their status information are provided to
FIM as inhibiting conditions
.
If a failure is detected and the event is reported to
the DEM
,
the FIM
disables
the FID
and corresponding functions.
In order to handle the relationship between functions and associated events, function identifiers and prohibition conditions must be introduced into the
SW-C
template
(equivalent to
BSW
), and construct data structures during configuration to handle the sensitivity of identifiers to specific events. this
These relationships
are unique within each
FIM .
There is no functional link between RTE
and
FIM .
In
AUTOSAR
,
RTE
is handled according to the interface and scheduling requirements
SW-C
. In contrast,
FIM
handles inhibit conditions and
provides support mechanisms for control functions via identifiers (
FID ).
Therefore,
the FIM
concept and
the RTE
concept do not interfere with each other.
2.4.3
Developing a bug tracker
Development Error Tracker
DET
(
Development Error Tracer
) is mainly used to track and record errors during development
error.
The API
parameters give the trace source and error type:
The module where the error is located
The function where the error is located
Error type
It is up to software developers and software integrators to choose the optimal strategy for
API functionality
under specific application and test environments .
Can
Can include the following functions:
Setting debugger breakpoints within
the error reporting
API
Calculation of reported errors
Record calls and passed parameters in
RAM
cache
Send reported errors to an external log via the communication interface
DET
is only an aid to
SW
development and integration, and does not have to be included in the product code.
API
has been defined,
But functionality is chosen / implemented
by the developer based on specific needs
.
2.4.4
Diagnostic Communications Manager
Diagnostic Communication Manager
DCM
(
Diagnostic Communication Manager
) ensures diagnostic data flow, and
Manage diagnostic state, specifically diagnostic sessions and security state. Additionally,
DCM
checks if the diagnostic service request is supported,
And judge whether the service can be executed in the current session according to the diagnosis status.
DCM provides an interface to
AUTOSAR-RTE
for all diagnostic services
. Additionally DCM also handles some basic diagnostics
Serve.
In
the AUTOSAR
architecture, the diagnostic communication manager (
DCM
) is in the communication service (service layer).
DCM
Is an intermediate between the application and the vehicle network communication ( CAN , LIN , FlexRay and MOST ) encapsulated by the
PDU router
layer.
There is an interface between the DCM
and the
PDU
router. In the communication process,
DCM
from
PDU
(
Protocol Data Unit
)
The router receives diagnostic messages.
DCM
internally processes, checks diagnostic messages and passes the messages to
AUTOSAR SW
components for further processing.
Depending on the diagnostic service
ID
, the corresponding call in the application layer will be executed.
DCM
must be network-independent, so protocols and messages are configured at the lower layer of
DCM
. This needs to be connected to
the PDU
way
The network independent interface of the router.
DCM
consists of the following functional blocks:
DSP - Diagnostic Service Processing
The DSP
mainly contains fully implemented diagnostic services that are common among different applications (for example,
access to fault data), so it does not need to be implemented by the application.
DSD-Diagnostic Service Dispatcher
The purpose of the DSD
is to handle diagnostic data streams. Processing here means:
Receive new diagnostic requests over the network and send to the data processor.
Transmission of diagnostic responses over the network when triggered by the application (
AUTOSAR SW-Component
or
DSP
).
DSL-Diagnostic Session Layer
DSL
guarantees data flow related to diagnostic requests and responses.
The DSL
also monitors and ensures diagnostic protocol timing. further,
The DSL
manages diagnostic status.
2.5
Storage stack
2.5.1
Storage service
The storage service consists of an
NVRAM
manager module, responsible for managing non-volatile data (from different storage drives
read
/
write). It requires a
RAM
image as a data interface for applications to read quickly.
The task of the storage service is to provide non-volatile data to applications in a uniform manner. This abstracts storage locations and attributes. carry
Provides non-volatile data management mechanisms such as saving, loading, checksum protection and verification, reliable storage, etc.
2.5.1.1
Addressing Scheme for Storage Hardware Abstraction
The memory abstraction interface and underlying flash
EEPROM
emulation and
EEPROM
abstraction layer provide to the
NVRAM
manager
Virtual linear
32
-bit address space. These logical
32-
bit addresses consist of a
16
-bit logical block number and
a 16
-bit block address offset.
So
the NVRAM
manager (theoretically) can have
65536
logical blocks, and each logical block (theoretically) can have
64Kbytes
。
The NVRAM
manager further divides
the 16
-bit logical block number into the following parts:
·
(
16-NVM_DATASET_SELECTION_BITS
) bit block identifier
·
NVM_DATASET_SELECTION_BITS
bit data index, each
NVRAM
block can have at most
256
datasets
2.5.1.2 NVRAM
Manager
The Non-Volatile
RAM
Manager (
NVRAM Manager
) manages the storage of all data in non-volatile memory.
The NVRAM
manager itself has nothing to do with hardware, all functions that directly access hardware, such as internal or external
EEPROM , emulated
EEPROM
in internal or external flash,
etc., packaged in the lower layers of the base SW . in the car ring
In the environment, the
NVRAM
manager provides services to ensure data storage and
maintenance of
NV data according to the needs of individual data.
The NVRAM
manager must be able to manage the
NV data of
EEPROM
and
/
or
FLASH EEPROM
emulation devices
. NVRAM
The manager
provides the required synchronous / asynchronous services (initialization / reading / writing / control) for the management and maintenance of
NV data.
NVRAM
Managers handle parallel access to nonvolatile data and provide reliability mechanisms, such as checksum protection, for individual data elements.
In order to be applicable to all areas of automotive systems,
NVRAM
managers need to be highly scalable (e.g. defining request queues
number and size, support for different block management types,
EEPROM
emulation, etc.).
2.5.1.3
Basic Storage Objects
NV
block:
The NV
block represents
the storage area composed of
NV
user data and
CRC value (optional);
RAM
block:
The RAM
block represents the area consisting of
user data and CRC value (optional) in
RAM ;
ROM
block:
The ROM
block resides in
ROM
(flash memory) and is used to provide default data in case
the NV
block is empty or corrupted;
Management block:
The management block is in
RAM
and contains
the block index associated with
the Dataset NV block.
In addition, it also contains the corresponding
Attribute / error / status information for NVRAM
blocks .
2.5.1.4
Block management type
The following
NVRAM
storage types shall be supported by the
NVRAM
manager and consist of the following basic storage objects:
Native NVRAM
blocks are the simplest type of block management.
Store /
retrieve
NV
store
with minimal overhead .
Native
An NVRAM
block consists of a single
NV
block,
a RAM
block, and a management block.
Redundant NVRAM
blocks have higher fault tolerance, reliability and availability, and resistance to data corruption.
The Redundant NVRAM
block consists of two
NV
blocks, a
RAM
block, and a management block.
A Dataset NVRAM
block is an array of data blocks (
NV/RAM
) of the same size. An application can only access one of the
one.
Dataset NVRAM
block is managed by multiple
NV
user data and (optional)
CRC
areas, a
RAM
block and
block composition.
2.5.1.5 API Configuration Types of NVRAM
Manager
In order to make the
NVRAM
manager suitable for limited hardware resources,
3
different
API
configuration types are defined:
·
API
Configuration Type
3
:
All specified
API
calls are available. Supports maximum functionality.
·
API
configuration type
2
:
An intermediate set of API
calls is available.
·
API
Configuration Type
1
:
Especially for systems with very limited resources, this
API
configuration type only provides the required
API
calls
minimal set.
2.5.2
Storage Hardware Abstraction
Storage hardware abstraction is a set of modules that abstracts the location of peripheral storage devices (on-chip or on-board) and
ECU
hardware layout.
For example: on-chip
EEPROM
and external
EEPROM
devices should be accessible through the same mechanism.
Access to storage drivers through memory-specific abstraction
/
emulation modules (e.g.
EEPROM
abstraction). by simulation
EEPROM
interface and flash hardware unit, you can access these two types of hardware through the storage abstraction interface.
The task of storage hardware abstraction is to provide access to internal (on-chip) and external (on-board) storage devices and storage hardware types
(
EEPROM
, Flash) the same mechanism.
2.5.2.1 EEPROM
abstraction
The EEPROM
abstraction layer (
EA
) extends
the EEPROM
driver to provide virtual segmentation on the linear address space to the upper layer
and "practically unlimited" erase
/
write cycles. Besides that, it should provide
the same functionality as
EEPROM driver
able.
2.5.2.2
Flash
EEPROM
emulation
Flash
EEPROM
Emulation (
FEE ) emulates the behavior of
the EEPROM abstraction layer
following Flash technology .
so it matches with
The EEPROM
abstraction layer has the same functionality and
API
, and gives a similar configuration to the underlying flash drives and flash devices.
2.5.2.3
Memory abstraction interface
The memory abstraction interface (
MemIf
) allows the
NVRAM
manager to access multiple memory abstraction modules (
FEE
or
EA
modules).
The memory abstraction interface abstracts the number of FEE
and
EA
modules in the lower layer , and provides a unified linear address space to the upper layer
virtual segment.
2.5.3
Storage driver
2.5.3.1 EEPROM
driver
The EEPROM driver provides
services for
reading, writing, and erasing
EEPROM .
Also provided for comparison
to
EEPROM
Services for data blocks and in-memory data blocks. These services are asynchronous. There are two types of
EEPROM
drivers:
·
Internal
EEPROM
driver
·
External
EEPROM
driver
The internal
EEPROM
driver directly accesses the microcontroller hardware and is positioned at the microcontroller abstraction layer. external
EEPROM
drivers use handlers
or
drivers to access external
EEPROM
devices. It locates in
the ECU
abstraction layer.
The functional requirements and functional scope are the same for both types of drivers. So
the API
is semantically the same.
2.5.3.2
Flash Drive
If supported by the underlying hardware, the flash driver provides services for reading, writing, and erasing flash memory, as well as setting write
/
erase
Protected configuration interface. The flash driver provides a built-in loader to load the flash access code into
RAM
, and in
Perform write /
erase operations when needed .
In
ECU
application mode, the flash drive is only used to write data to the flash
EEPROM
emulation module. in application mode
Program code is not written to flash memory. This should be handled by the launch mode, which is out of the scope of
AUTOSAR
.
There are two types of flash drives:
·
internal flash drive
·
external flash drive
The drivers for the internal flash memory directly access the microcontroller hardware and are located at the microcontroller abstraction layer. External flash memory is usually
connected via the microcontroller data
/
address bus, then the flash driver uses the bus handler
/
driver to access the external flash device
prepare. The driver of the external flash device is positioned at
the ECU
abstraction layer. The functional requirements and functional scope of both types of drivers are
identical. So
the API
is semantically the same.
2.6
Communication stack
The overview of the AUTOSAR
communication stack is as follows:
The communication stack in AUTOSAR consists of the following parts:
2.6.1 CAN
·
AUTOSAR CAN
The AUTOSAR CAN
model is as follows:
·
CAN
driver
The CAN
driver provides a unified interface -
CAN
interface for the upper layer users.
CAN
drivers are hidden as much as reasonably possible
The hardware specificity of the relevant
CAN controller is eliminated.
The CAN
driver is a part of the bottom layer, which implements hardware access and provides hardware-independent
API for the upper layer
. upper layer
The only thing that can access
the CAN
driver is
the CAN
interface.
If several
CAN
controllers belong to the same
CAN
hardware unit, they can be
controlled by
a CAN driver.
A
CAN
controller is always associated with a physical channel. It is allowed to connect with the physical channel on the bus,
Whether or not
the CAN
interface treats the associated
CAN
controller separately.
·
CAN
interface (hardware abstraction)
The CAN
interface provides a standardized interface to support communication through
the ECU
's
CAN
bus system. Its
API
and dedicated
The CAN
controller and its access via
the CAN
driver layer are irrelevant.
The CAN
interface enables access to one or
Multiple
CAN
drivers.
The CAN
interface can only be used for
CAN
communication, and is specially designed to operate one or more low-level
CAN
drivers.
Several CAN driver modules covering different
CAN hardware units
are connected by a common interface specified in the CAN driver specification
express.
Protocols other than
CAN
(that is,
LIN ) are not supported.
·
CAN
transport layer
The CAN
transport layer is a module located between
the PDU
routing and
CAN
interface modules. Its main role is to split and merge
CAN I-PDU larger than
8
bytes
.
According to
the AUTOSAR
basic software architecture,
the services provided by the
CAN transport layer are:
Data segmentation in the sending direction;
Data merging in the receiving direction;
Data
flow control;
Error
detection during split period.
The AUTOSAR
architecture defines each specific transport layer of the communication system (
CanTp
,
LinTp
including
LinIf
,
FlexRayTp
). Therefore,
the CAN
transport layer only covers the details of
the CAN
transport protocol.
The CAN
transport layer has an interface that connects a single lower
CAN
interface layer and a single upper layer
PDU Router
module.
According to
the plan released by
AUTOSAR , the
CAN transport layer specification contains the following restrictions:
- CAN
transport layer only runs in event-triggered mode,
-
No send
/
receive undo.
·
CAN
Transceiver Driver
The CAN
transceiver driver is responsible for handling
the CAN transceiver on
the ECU , based
on the current state of the entire ECU .
Status of the bus-specific NM
that is off
.
The goal of the CAN
transceiver device driver: The abstraction of
the CAN
transceiver device driver uses the hardware chip of the
CAN
transceiver device. it
Provides a hardware-independent interface to higher layers. It can also
be abstracted from the ECU design through the API of
the MCAL layer, accessing
CAN
transceiver hardware.
The CAN
transceiver hardware must provide functions and interfaces to map to
the AUTOSAR CAN
transceiver driver's
run mode on the model.
The API used by the lower layer drivers (
SPI
and
DIO )
must be synchronized. Implementations of lower-level drivers that do not support synchronous behavior cannot
Used with
CAN transceiver device drivers.
2.6.2 COM
·
AUTOSAR COM
AUTOSAR COM
layer is located between
RTE
and
PDU
router. It is derived from the
OSEK_COM
standard.
AUTOSAR COM
provides signal gateway function.
The dependencies between COM and other modules are shown in the figure below:
·
COM Manager
COM Manager
(
COM
Manager) is a component of
Basic Software
(
BSW
). it is
Resource management that encompasses the control of the underlying communication services.
The Basic Software Module (
BSW ) controlled by
COM Manager
is related to communication, not to software components or transportable
Row entity related.
COM Manager
collects bus communication access requests from communication requesters and coordinates bus communication access requests.
The goals of COM Manager
are:
(
1
) Simplify the use of the bus communication stack for the user. This includes initialization of the bus communication stack and simplified network management
deal with.
(2
) Coordinate the bus communication stack
(
allowing the sending of signals and
receive) availability.
(3
) Temporarily cancel the sending of the signal to prevent
the ECU
from waking up the communication bus.
(4
) Control
more than one communication bus channel of
the ECU , which is achieved by implementing a state mechanism for each channel
accomplish.
(5
) Provide
the ECU
to keep the bus in the
"
silent communication
"
mode.
(6
) Simplifies resource management by allocating all resources necessary for the request communication pattern.
COM Manager
includes the following basic functions:
·
Comparison of AUTOSAR COM
and
OSEK COM
According to the functions provided by the communication part, compare the APIs
of the two in the same function
, and the unique
APIs of the two
,
Compared with
OSEK COM ,
AUTOSAR COM
has one more COM Manager , which is the communication management module department.
points, so the entire
AUTOSAR COM Manager is unique
to
the AUTOSAR
standard, the following is the same as the two
Functional part for comparison.
1.
Same functions and services
(
1
) Start and control services
The comparison between the two in the communication startup and control service can be seen: First,
the API provided by
AUTOSAR
is relatively
more, indicating that its function is stronger; secondly,
AUTOSAR
start-up and control services include
the I-PDU
(interaction layer protocol
Data unit) processing and control, such as
Com_IpduGroupStart
,
Com_IpduGroupStop
.
(2
) Communication service
It can be seen from the comparison that
the OSEK
communication service includes some simple handling of errors, such as obtaining error service
service
Id
(
COMErrorGetServiceId
), while
the AUTOSAR
communication service still includes the processing of
I-PDU
, such as
Com_TriggerIPDUSend
。
(3
) Notification mechanism support service (
OSEK
) and callback notification service (
AUTOSAR
)
The functions provided by the two in this part are not much different, mainly the modification and setting of some flags to control the communication
status and functions performed.
2.
Different functions and services
(
1
)
OSEK
provides a special service
for
I-PDU processing, called
OSEK indirect network management interface, including 2
APIs
: I-PDU transfer indication ( I_MessageTransfer ) and I-PDU
timeout
indication ( I_MessageTimeOut ).
(
2
)
The OSEK
communication part provides some routines to expand the communication,
including
3
APIs
:
StartCOMExtension
、
COMCallouts
、
COMErrorHook
。
(3
)
AUTOSAR
provides some scheduling functions, mainly for routing and scheduling the receiving or sending of messages or signals
function,
including
3
APIs
:
Com_MainFunctionRx
,
Com_MainFunctionTx
,
Com_MainFunctionRouteSignals
。
(4
) The communication part of
AUTOSAR
has a
COM Manager
, which is a communication management module, which is
AUTOSAR
Specific to the standard, it is mainly responsible for monitoring, managing, diagnosing and managing the status of
ECUs involved in communication
. The following table
Lists some of
the APIs it provides
.
2.6.3 FlexRay
·
AUTOSAR FlexRay
The layered architecture of AUTOSAR FlexRay is shown in the figure below:
·
FlexRay
interface
The FlexRay
interface provides a standardized interface to access the
FlexRay
communication system
/
hardware.
FlexRay
interface must
It must be independent of the special FlexRay CC
used
and its access via
the FlexRay
driver.
The FlexRay
interface is provided through
Uniform interface for access to one or several
FlexRay
drivers.
The main tasks of the FlexRay
interface are:
(
1
) Provide an abstract interface to the
FlexRay
communication system for the upper layer.
（
2
)
The FlexRay
interface accesses
the FlexRay
hardware through one or more hardware-specific driver modules instead of
direct access.
（
3
) In order to access the
FlexRay
communication controller,
the FlexRay
interface uses one or more
FlexRay
driver modules.
（
4
) To access
the FlexRay
transceivers,
the FlexRay
interface uses one or more
FlexRay
transceiver driver modules
piece.
（
5
)
The FlexRay
interface executable code is completely independent of the
FlexRay
communication controller and
FlexRay
transceiver.
（
6
)
The FlexRay
interface allows object code submission of code modules, following the
"one-fits-all"
principle.
（
7
) The functions provided by
the FlexRay
interface to the upper layer
AUTOSAR BSW
module are as follows:
A．
_ initialization
B．
_ configure
/
reconfigure
C.
_ Data transfer (send and receive)
D.
_ Start
/
stop
/
interrupt communication
E.
_
FlexRay
Dedicated Services
F.
_ Set the operating mode
G.
_ get status information
H.
_ Various timer functions
·
FlexRay
driver
The FlexRay
driver module must provide a unified interface for users of the
FlexRay
interface module and
API
to access many
FlexRay
communication controllers, these controllers are usually of the same type.
The FlexRay
driver is a software layer that will pump
Image function requests are mapped to sequences of
CC-
specific hardware.
The hardware implementation of
CC will be hidden from
the FlexRay interface.
·
FlexRay
transport layer
The FlexRay
transport layer uses physical and functional addresses, segmented confirmed and unconfirmed
1
-to
-1
communication, and segmented unacknowledged
1-
to
-n
communication is supported.
·
FlexRay
Transceiver Driver
The FlexRay
transceiver driver is responsible for handling the
FlexRay transceiver on
the ECU , based on
the status of the bus-specific NM
state.
2.6.4 IPDUM
PDU
multiplexing technology refers to
using more than one specific design of its
SDU
(
Service Data Unit )
The same PCI ( Protocol Control Information ) of a
PDU
(
Protocol Data Unit )
. The select subfield is
Part of the SDU of a multi-way
PDU
. It is used to distinguish the contents of multiple PDUs .
2.6.5 LIN
·
AUTOSAR LIN
The layered architecture of AUTOSAR LIN is shown in the figure below:
·
LIN
driver
The LIN
driver is the lowest part, which performs hardware access and provides hardware-independent
API for the upper layer
. The only upper
Enough access to the
LIN
driver is the
LIN
interface.
A
LIN
driver can support more than one channel.
The LIN
driver can handle one or more
hardware belonging to the same
LIN
LIN channel
of the hardware unit
.
·
LIN
interface
The LIN
interface is designed to be hardware independent. to the upper module (
PDU
router) and lower module (
LIN
driver) of the
Interface is well defined.
The LIN
interface can handle more than one
LIN
driver. A
LIN
driver can support more than one channel. This refers to
The thing is that a
LIN
driver can handle one or more
LIN
channels.
The LIN
interface is responsible for providing the upper layer with the main functions of
LIN 2.0
:
(
1 )
Execute the currently selected schedule
for each
LIN bus connected to
the ECU .
(2
) When the request from the upper layer comes, switch the scheduling table.
(3
) Receive frame transmission from upper layer and transmit data part as response in appropriate
LIN
frame.
(4
) Provide frame reception notification to the upper layer when the corresponding response is received in the appropriate frame.
(5
) Sleep and wake up service
(6
) Error handling
(7
) Diagnosis of transport layer services