Autosar Srs Bswgeneral
Autosar Srs Bswgeneral
Autosar Srs Bswgeneral
Removed Requirements :
[BSW00434] The Schedule Module
provides an API for exclusive areas.
[BSW00431] The BSW Scheduler
module implements task bodies.
These requirements are available in
SRS RTE SRS_Rte_00222,
RTE00225 respectively.
Changed requirements:
[SRS_BSW_00416],
[SRS_BSW_00407],
SRS_BSW_00379],
[SRS_BSW_00435],
[SRS_BSW_00305],
[SRS_BSW_00429],
[SRS_BSW_00318],
[SRS_BSW_00004],
[SRS_BSW_00402],
[SRS_BSW_00373],
[SRS_BSW_00406],
[SRS_BSW_00414],
[SRS_BSW_00347],
[SRS_BSW_00343],
[SRS_BSW_00003],
[SRS_BSW_00347]
Disclaimer
This work (specification and/or software implementation) and the material contained
in it, as released by AUTOSAR, is for the purpose of information only. AUTOSAR
and the companies that have contributed to it shall not be liable for any use of the
work.
The material contained in this work is protected by copyright and other types of
intellectual property rights. The commercial exploitation of the material contained in
this work requires a license to such intellectual property rights.
This work may be utilized or reproduced without any modification, in any form or by
any means, for informational purposes only. For any other purpose, no part of the
work may be utilized or reproduced, in any form or by any means, without permission
in writing from the publisher.
The work has been developed for automotive applications only. It has neither been
developed, nor tested for non-automotive applications.
The word AUTOSAR and the AUTOSAR logo are registered trademarks.
Table of Contents
1.1 Constraints
First scope for specification of requirements on Basic Software Modules are systems
which are not safety relevant. For this reason safety requirements are assigned to
medium priority.
The key words "MUST", "MUST NOT", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "MAY", and "OPTIONAL" in this document are to be interpreted as:
SHALL: This word means that the definition is an absolute requirement of the
specification.
SHALL NOT: This phrase means that the definition is an absolute prohibition
of the specification.
MUST: This word means that the definition is an absolute requirement of the
specification due to legal issues.
MUST NOT: This phrase means that the definition is an absolute prohibition of
the specification due to legal constraints.
SHOULD: This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a particular item,
but the full implications must be understood and carefully weighed before
choosing a different course.
SHOULD NOT: This phrase, or the phrase "NOT RECOMMENDED" mean
that there may exist valid reasons in particular circumstances when the
particular behavior is acceptable or even useful, but the full implications
should be understood and the case carefully weighed before implementing
any behavior described with this label.
MAY: This word, or the adjective „OPTIONAL“, means that an item is truly
optional. One vendor may choose to include the item because a particular
marketplace requires it or because the vendor feels that it enhances the
product while another vendor may omit the same item. An implementation,
which does not include a particular option, MUST be prepared to interoperate
with another implementation, which does include the option, though perhaps
with reduced functionality. In the same vein an implementation, which does
include a particular option, MUST be prepared to interoperate with another
implementation, which does not include the option (except, of course, for the
feature the option provides.)
Functional Requirements:
- Configuration (which elements of the module need to be configurable)
- Initialization
- Normal Operation
- Shutdown Operation
- Fault Operation
- …
Non-Functional Requirements:
- Timing Requirements
- Resource Usage
- Usability
- Output for other WPs (e.g. Description Templates, Tooling,...)
- ...
This Requirements Specification contains general requirements that are valid for all
SW modules that are part of the AUTOSAR Basic Software.
Abbreviation: Description:
Cat2 Category 2. Cat2 ISRs are supported by the OS and can make OS calls.
Cat1 Category 1. Cat1 interrupts are not supported by the OS and are only allowed to
make a very small selection of OS calls to enable and disable all interrupts.
4 Requirements Tracing
modules
RS_BRF_01096 AUTOSAR shall support SRS_BSW_00336
start-up and shutdown of
ECUs
RS_BRF_01104 AUTOSAR shall support SRS_BSW_00375
sleep and wake-up of ECUs
and buses
RS_BRF_01136 AUTOSAR shall support SRS_BSW_00101, SRS_BSW_00395,
variants of configured BSW SRS_BSW_00406
data resolved after system
start-up
RS_BRF_01144 AUTOSAR shall support SRS_BSW_00314
configuration parameters
which allow to trade interrupt
response time against
runtime
RS_BRF_01160 AUTOSAR shall support SRS_BSW_00459, SRS_BSW_00460
BSW distribution on multi-
core MCUs
RS_BRF_01192 AUTOSAR shall document all SRS_BSW_00009
architectural constraints
which exist to use the RTE
and the BSW
RS_BRF_01208 AUTOSAR OS shall support SRS_BSW_00416
to start lists of tasks regularly
RS_BRF_01320 AUTOSAR RTE shall SRS_BSW_00172
schedule SWC and BSW
modules
RS_BRF_01352 AUTOSAR RTE shall offer SRS_BSW_00407, SRS_BSW_00432
direct read/write data access,
and alternatively pre-read
data before a runnable is
called and post-write data
after the runnable returns
RS_BRF_01384 AUTOSAR RTE shall support SRS_BSW_00323, SRS_BSW_00393
automatic range checks of
data
RS_BRF_01440 AUTOSAR services shall SRS_BSW_00375
support system diagnostic
functionality
RS_BRF_01464 AUTOSAR services shall SRS_BSW_00425
support standardized
handling of watchdogs
RS_BRF_01480 AUTOSAR shall support SRS_BSW_00170
software component local
modes, ECU global modes,
and system wide modes
RS_BRF_01616 AUTOSAR communication SRS_BSW_00410
shall support initial values for
signals
RS_BRF_01856 AUTOSAR microcontroller SRS_BSW_00162
abstraction shall provide
13 of 80 Document ID 043: AUTOSAR_SRS_BSWGeneral
- AUTOSAR confidential -
General Requirements on Basic Software Modules
AUTOSAR CP Release 4.3.1
Body
Powertrain
Chassis
Safety (assumption: covered, because hardware and system infrastructure are
similar to the domains above)
The ECU application experience is taken from the following concrete applications:
5.1.1 Configuration
⌈
Type: Valid
Description: Link-time configuration phase shall be supported. Link-time parameters are
optional.
Rationale: Allow configurable functionality of modules that are deployed as object code.
Usually those modules are drivers.
Use Case: --
Dependencies: [SRS_BSW_00342] Usage of source code and object code
Supporting Material: --
⌋()
⌈
Type: Draft
Description: Post-build configuration phase shall be supported. Post-build parameters
are optional
Rationale: Change ECU configuration after ECU production without an update of the
16 of 80 Document ID 043: AUTOSAR_SRS_BSWGeneral
- AUTOSAR confidential -
General Requirements on Basic Software Modules
AUTOSAR CP Release 4.3.1
whole application.
Use Case: type declaration of the Config Type
typedef struct ComM_ConfigType_Tag {
...
} ComM_ConfigType; (in ComM_Cfg.h)
⌈
Type: Valid
Description: Modules of the AUTOSAR Basic Software shall be able to operate with more
than one configuration set, selectable at start-up time.
Rationale: Application of the same software to different cars.
Use Case: --
Dependencies: [SRS_BSW_00342] Usage of source code and object code
Supporting Material: --
⌋()
⌈
Type: Valid
Description:
Rationale: Static configuration is decoupled from implementation. Separation of
configuration dependent data at compile time furthermore enhances
flexibility, readability and reduces version management as no source code is
affected.
Use Case:
Dependencies: [SRS_BSW_00158] Separation of configuration from implementation
Supporting Material: --
⌋()
⌈
Type: Valid
Description: All modules of the AUTOSAR Basic Software shall support a tool based
configuration.
Rationale: Integration into AUTOSAR methodology
Use Case: The NVRAM manager can be automatically configured depending on the NV
⌈
Type: Valid
Description: All AUTOSAR Basic Software Modules shall provide configuration rules and
constraints to enable plausibility checks of configuration during ECU
configuration time where possible.
Rationale: Runtime efficiency:
Checks can be made by a configuration tool or the preprocessor instead
during runtime.
Safety:
Detect wrong or missing configurations as early as possible
Use Case: --
Dependencies: [SRS_BSW_00334] Provision of XML file
Supporting Material: --
⌋()
⌈
Type: Valid
Description: Optional functionality of a Basic-SW component that is not required in the
ECU shall be configurable at pre-compile-time (on/off).
Rationale: Optional functionalities of Basic SW components which are disabled by static
configuration shall not consume resources (RAM, ROM, runtime).
⌈
Type: Valid
Description: AUTOSAR SW-Components may depend on the system fault state or
configuration demand of OEM or driver. These reconfiguration dependencies
must be provided during ECU configuration time. This information must be
used for cross checks and functional evaluation at ECU configuration time
and for correct shut down/activation behavior at runtime.
Rationale: Resolve the interdependencies between AUTOSAR SW-Components.
Use Case: A fault of the steering angle sensor will lead to reduced function of the
related AUTOSAR SW-Components.
Example:
- faults (CAN bus off, sensor defective, calibration data checksum error)
- signal quality (lambda sensor not yet in operating temperature range)
- driver demands (disable ESP)
- ...
Dependencies: --
Supporting Material: --
⌋(RS_BRF_01480)
⌈
Type: Valid
Description: Configuration parameters being stored in memory shall be placed into
separate c-files (effected parameters are those from link-time configuration
as well as those from post-build time configuration).
Rationale: Enable the use of different object files.
Use Case: --
Dependencies: [SRS_BSW_00381] Separate configuration header file for pre-compile time
parameters
[SRS_BSW_00346] Basic set of module files
Supporting Material: Layered Software Architecture ([DOC_LAYERED_ARCH])
⌋()
⌈
Type: Valid
Description: If a pre-compile time configuration parameter is implemented as “const“ it
should be placed into a separate c-file.
Rationale: Enabling of object code integration.
Separation of configuration from implementation.
Use Case: --
Dependencies: --
Supporting Material: Layered Software Architecture ([DOC_LAYERED_ARCH])
19 of 80 Document ID 043: AUTOSAR_SRS_BSWGeneral
- AUTOSAR confidential -
General Requirements on Basic Software Modules
AUTOSAR CP Release 4.3.1
⌋()
⌈
Type: Obsolete
Description: The pre-compile time parameters shall be placed into a separate
configuration header file.
Rationale: Keep the configuration data separate.
Use Case: --
Dependencies: [SRS_BSW_00345] Pre-compile-time configuration
Supporting Material: --
⌋()
⌈
Type: Obsolete
Description: References to c-configuration parameters (link time and post-build time)
shall be placed into a separate h-file. The h-file shall be the same as pre-
compile time parameters.
Rationale: Put the references to c-configuration parameters in the same header file as
pre-compile time parameters to enable access to the configuration data.
Use Case: --
Dependencies: [SRS_BSW_00345], [SRS_BSW_00346]
Supporting Material: --
⌋(RS_BRF_01056)
⌈
Type: Valid
Description: The Basic Software Module specifications shall specify which other
configuration files from other modules they use at least in the description.
Rationale: Resolve compatibility issues
Use Case: --
Dependencies: [SRS_BSW_00384] List dependencies to other modules
Supporting Material: --
⌋()
⌈
Type: Valid
Description: The Basic Software Module specifications shall specify at least in the
description which other modules (in which versions) they require.
Rationale: Resolve compatibility issues
Use Case: --
Dependencies: [SRS_BSW_00383] List dependencies of configuration files
Supporting Material: --
⌋(RS_BRF_01064)
⌈
Type: Valid
Description: Containers are used to group configuration parameters that are defined for
the same object. Containers are to be defined whenever
1. Several configuration parameters logically belong together.
2. Configuration must be repeated with different parameter values for
several entities of same type (e.g. the NVRAM manager has some
parameters that are defined once for the whole module, which are
collected in one container, and a set of parameters that are defined
once per memory block, which are collected in another container.
This second container is included in the first container and will be
instantiated once for each memory block)
3. Containers may contain parameters of different configuration
classes. This will not map to the software implementation!
Rationale: Cluster the configuration parameters in order to ease the readability of code.
Use Case: Header configuration file with sections for each container
Dependencies: [SRS_BSW_00389] Containers shall have names
Supporting Material:
⌋()
⌈
Type: Valid
Description: Containers shall have names – these names will map to section headers in
the configuration header-files or configuration c-files containing the
parameters
Rationale: Enable referencing to the .XML document.
Use Case: --
Dependencies: --
Supporting Material: See Glossary ([GLOSSARY])
⌋(RS_BRF_01024)
⌈
Type: Valid
Description: The same intention, logical contents or semantic shall be placed in one
parameter only (There must not be several parameters with the same
intention, logical contents or semantic )
21 of 80 Document ID 043: AUTOSAR_SRS_BSWGeneral
- AUTOSAR confidential -
General Requirements on Basic Software Modules
AUTOSAR CP Release 4.3.1
⌈
Type: Valid
Description: Each Parameter shall have a type. Types shall be based on primitive or,
complex types defined within AUTOSAR specifications. I.e. they may be
combined to structures, arrays etc.
Parameters based on a “define” are not required to have an explicit cast to
their type, they shall have an appropriate C suffix (“U” if of unsigned integer
type, “L” if of integer long type and “F” if of single precision floating type).
Rationale: --
Use Case: --
Dependencies: --
Supporting Material: MISRA-C Rule 7.2
⌋(RS_BRF_01024)
⌈
Type: Valid
Description: Each parameter shall have a list of valid values or the minimum as well as
maximum values shall be specified.
Rationale: --
Use Case: E.g. the range is used to enable the consistency check by a tool.
Dependencies: --
Supporting Material: --
⌋(RS_BRF_01384)
⌈
Type: Valid
Description: A parameter may only be applicable for the module it is defined in.
In this case, the parameter is marked as "local". Alternatively, the parameter
may be shared with other modules (i.e. exported).
Rationale: Increase the uniformity of the use of this attribute and let as single entity
(BSW UML model) be the source for import information.
Use Case: Importing and exporting could be achieved in different ways: external
reference, redefinition in the other module.
Dependencies: --
Supporting Material:
⌋()
⌈
Type: Valid
Description: The Basic Software Module specifications must specify, via configuration
constraint items, all dependencies to this or other modules configuration
parameters. A dependency is for example: the value of another parameter
influences or invalidates the setting of this parameter. A dependency shall be
documented only once, i.e. if a dependency between two Basic Software
Modules exists, then the configuration constraint item shall be described only
in the Basic Software Module specification containing the influenced
configuration parameter.
Rationale: --
Use Case: Specified parameter “Bit timing register” requires other parameters e.g.,
“input clock frequency” which is defined in another module.
Dependencies: --
Supporting Material: --
⌋(RS_BRF_01136)
⌈
Type: Valid
Description: There are three main configuration classes for changing values (applicable
only to parameters) and multiplicities (applicable both to parameters and
containers). The Basic Software Module specifications shall specify the
classes to be supported per parameter/container. The classes are:
- pre- compile time configuration
- link time configuration
- post build time configuration
Rationale: Enable optimizing towards different goals of configuration.
Use Case: --
Dependencies: --
Supporting Material: --
⌋(RS_BRF_02200)
⌈
Type: Valid
Description: For each container, the module shall be able to specify whether the
multiplicity may be different in different configuration sets. For each
parameter, the module shall be able to specify whether the multiplicity and/or
the value may be different in different configuration sets.
Rationale: Enable to specify restrictions that are necessary to optimize the
implementation.
Use Case: --
Dependencies: --
23 of 80 Document ID 043: AUTOSAR_SRS_BSWGeneral
- AUTOSAR confidential -
General Requirements on Basic Software Modules
AUTOSAR CP Release 4.3.1
Supporting Material: --
⌋()
⌈
Type: Valid
Description: The configuration parameters in pre-compile time are fixed before
compilation starts. The configuration of the SW element is done at source
code level.
Rationale: Ease generation of efficient code.
Use Case: --
Dependencies: --
Supporting Material: [SRS_BSW_00345] Pre-compile-time configuration
⌋()
⌈
Type: Valid
Description: The link-time configuration is achieved on object code basis in the stage
after compiling and before linking (locating).
Rationale: Concept of configuration to support modules delivered as object code.
Use Case: --
Dependencies: --
Supporting Material: [SRS_BSW_00344] Reference to link-time configuration
⌋()
⌈
Type: Valid
Description: Parameter-sets are located in a separate segment and can be loaded after
the code. (see definition of post-build time configuration in the AUTOSAR
glossary). This means as well the memory layout of ext. conf. parameters
must be known.
This set of parameters may be optimized in a way (configuration is always
located at the same address) that the pointer indirection is avoided.
Rationale: --
Use Case: Loadable CAN configuration or communication matrix.
Dependencies: --
Supporting Material: --
⌋()
⌈
Type: Valid
Description: Parameter will be selected from multiple sets of parameters after code has
been loaded and started. During module startup (initialization) one of several
configurations is selected. This configuration is typically a data structure that
contains the relevant parameter values.
Rationale: --
Use Case: Reuse of ECUs.
Dependencies: --
Supporting Material: --
⌋()
⌈
Type: Valid
Description: In case of post-build configuration, or when one of multiple configuration sets
shall be selectable at initialization time, the configuration parameters of a
BSW module shall be reachable from a single base structure. The pointer to
this structure shall be passed to the Init function of the BSW module.
Rationale: 1. Allow selection of one configuration set in case more than one set is
available.
2. Allow moving of configuration in reprogrammable memory in case post-
build configuration is applied.
Use Case: Initialization concept for ComM or CanIf.
Dependencies: --
Supporting Material: --
⌋()
⌈
Type: Valid
Description: The provided informationshall be included in each module. This information
shall include: Vendor and module identification numbers, AUTOSAR release
version and software module version.
Rationale: The published information contains data defined by the implementer of the
SW module that doesn’t change when the module is adapted (i.e.
configured) to the actual HW/SW environment it is used in. It thus contains
version and manufacturer information to ease the integration of different
BSW modules.
Use Case: --
Dependencies: [SRS_BSW_00407], [SRS_BSW_00318]
Supporting Material: --
⌋(RS_BRF_01032)
5.1.2 Wake-Up
⌈
Type: Valid
Description: All Basic Software Modules that implement wake-up interrupts shall report
the wake-up reason to the ECU State Manager.
Within this notification the ECU State Manager shall store the passed wake-
up ID for later evaluation.
Rationale: Allow ECU State Manager to decide which start-up sequence is chosen
based on the wake-up reason.
Use Case: A body ECU can wake-up from 3 different wake-up sources. Depending on
the wake-up reason, the ECU
blinks the door lock indication LEDs
performs a full start-up
evaluates the received key ID and decides to start-up and unlock or
goto sleep again
Dependencies: --
Supporting Material: --
⌋(RS_BRF_01104,RS_BRF_01440)
5.1.3 Initialization
⌈
Type: Valid
Description: If a Basic Software Module needs to initialize variables and hardware
resources, this should be done in a separate initialization function. This
function shall be named <Module name>_Init(). This function shall only
be called by the BswM or EcuM.
Rationale: Interface to ECU state manager
Use Case: --
Dependencies: [SRS_BSW_00358] ,[SRS_BSW_00414] , [SRS_BSW_00406]
Supporting Material: --
⌋(RS_BRF_01136)
⌈
Type: Valid
Description: The sequence of modules to be initialized shall be configurable.
Rationale: To enable the handling of dependencies of Basic SW-modules with the
respect to environment, implementation and proprietary functionality the
26 of 80 Document ID 043: AUTOSAR_SRS_BSWGeneral
- AUTOSAR confidential -
General Requirements on Basic Software Modules
AUTOSAR CP Release 4.3.1
⌈
Type: Valid
Description: If the Default Error Tracer (DeT) Error is enabled, module APIs shall check if
the module is initialized.
If the Module is not initialized and Default Error Tracer (DeT) is enabled,
then the Module shall report respective error to DeT.
⌈
Type: Valid
Description: The init / deinit services shall only be called by BswM or EcuM
Rationale: The module does not need to protect itself against untimely calls.
Use Case:
Dependencies: [SRS_BSW_00101]
Supporting Material: --
⌋()
⌈
27 of 80 Document ID 043: AUTOSAR_SRS_BSWGeneral
- AUTOSAR confidential -
General Requirements on Basic Software Modules
AUTOSAR CP Release 4.3.1
Type: valid
Description: Memory mapping shall provide the possibility to define RAM segments which
are not to be initialized during startup (NoInit-Area).
This shall be achieved by using/modifying linker and C startup routines.
Rationale: There should be an area in the RAM, which will not be affected by a reset
(clearing all memory). This area is used as storage for persistent data which
are needed during normal operation (and that will not be stored in
EEPROM).
Use Case: Reset information is stored in RAM and has to be evaluated after reset.
Dependencies: --
Supporting Material: --
⌋(RS_BRF_00057)
⌈
Type: Valid
Description: If a SW component above or below RTE has the requirement to be tested by
external devices e.g. in the garage, the required function shall be accessed
via a common API from diagnostics services in Basic-SW (function, data
interface).
Rationale: Ensure less difference in handling and kind of API
Use Case: Tester in the garage requires calibration of a certain SW-component e.g.
steering angle sensor monitoring in the ESP. The interface must remain to
be ready for moving this SW-component.
This interface can also be used by XCP.
Dependencies: --
Supporting Material: --
⌋(RS_BRF_02144)
⌈
Type: Valid
Description: Each BSW module shall provide a function to read out the version
information of a dedicated module implementation.
It shall be possible to call this function at any time (e.g. before the init
function is called).
Rationale: If problems are detected within an ECU during lifetime this enables the
garage to check the version of the modules.
The AUTOSAR specification version number is checked during compile time
(see requirement SRS_BSW_00004) and therefore not required in this API.
Use Case: With this API the garage can read out version information which is
implemented in a dedicated (erroneous) ECU to enable the decision whether
⌈
Type: Valid
Description: BSW modules with AUTOSAR interfaces shall be describable with the
means of the SW-C Template. The BSW description template shall therefore
inherit the concepts of the SW-C Template for those BSW modules.
Rationale: AUTOSAR Services are located in the BSW, but have to interact with
AUTOSAR SW-Cs (above the RTE) via ports. Therefore the RTE generator
shall be able to read the input and shall be able to generate proper RTE.
Use Case: (1) SW-Cs use the service(s) related to the NvM_Read C-API of the NvM
(2) SW-Cs use services of the EcuM in order to request or release the run
mode
Dependencies: --
Supporting Material: --
⌋()
⌈
Type: Valid
Description: BSW module main processing functions are not allowed to enter a wait state
because the function must be able to be allocated to a basic task.
(see extended and basic task according to AUTOSAR OS classification).
Rationale: Typically, basic tasks are more efficient then extended tasks.
Enables schedule ability analysis and predictability.
Use Case: Enabling schedule ability analysis of the ECU.
Dependencies: --
Supporting Material: --
⌋()
⌈
Type: Valid
Description: The BSW module description template shall provide means to model the
following trigger conditions of schedulable objects:
Cyclic timings (fixed and selectable during runtime)
Sporadic events
Rationale: The model of the timing behavior of a BSW module can serve for the
purpose of
(1) documentation
⌈
Type: Valid
Description: BSW Modules shall ensure data consistency of data which is shared
between BSW modules.
There are two possible scenarios.
Scenario 1: the data is defined and managed within one BSW Module. In this
case, Exclusive Areas shall be defined and documented in the BSW module
description template of the managing module and used in the
implementation. The exclusive areas shall be defined with a name and the
accessing main functions, API services, callback functions and ISR
functions.
Scenario 2: the data is not managed by a BSW Module. This is only possible
in case of special hardware resources like registers. In this case, the
accessing modules need to disable and enable interrupts to ensure data
consistency
Rationale: To allow priority determination for preventing simultaneous access to shared
resources.
Use Case: Stop interrupt handler from corrupting a data buffer in COM due to
simultaneous access via the RTE.
Dependencies: --
Supporting Material: --
⌋()
⌈
Type: Valid
Description: ISR functions shall be defined and documented in the BSW module
description template.
The ISR functions shall be defined with a name and the category according
to the AUTOSAR OS.
In case of the intention to support memory protection a BSW module
implementation shall at least support interrupt category 2.
Rationale: Determination of locking scheme for a particular exclusive area.
Use Case: Stop interrupt handler from corrupting a data buffer in COM due to
simultaneous access via the RTE.
Dependencies: --
⌋()
⌈
Type: Valid
Description: A BSW module shall state if its main processing function(s) has to be
executed in a specific order or sequence with respect to other BSW main
processing function(s).
Rationale: Improved integration of BSW modules.
Use Case: Improved efficiency in the COM stack by ensuring receive and transmit call
sequence.
Dependencies: --
⌋()
⌈
Type: Valid
Description: BSW modules shall only be allowed to use certain OS services. The services
and their access shall be defined in SWS_BSW_General.
Rationale: Simplification of the OS integration of BSW modules.
Use Case: Integration of different BSW modules in one ECU.
Dependencies: --
Supporting Material: --
⌋()
⌈
Type: Valid
Description: Modules which propagate data up (read, receive) or down (write, transmit)
through the different layers of the BSW should have separate main
processing functions for the read/receive and write/transmit data path.
Rationale: Enables efficient scheduling of the main processing functions in a more
specific order to reduce execution time and latency.
Use Case: TASK(BSW_Scheduler_Communications) {
...
CanIf_MainFunction_Receive();
Com_MainFunction_Receive();
Com_MainFunction_Transmit();
CanIf_MainFunction_Transmit();
...
}
⌈
Type: Valid
Description: Main processing functions are only allowed to be called from task bodies
provided by the BSW Scheduler.
Rationale: Indirect and in-transparent timing dependencies between BSW modules
shall be prohibited.
Use Case: --
Dependencies: --
Supporting Material: --
⌋()
⌈
Type: Valid
Description: If a Main function of an un-initialized module is called, then it shall return
immediately without performing any functionality and without raising any
errors.
Rationale: Main Function processing of an un-initialized Module may result in undesired
and non defined behaviour.
Use Case: --
Dependencies: --
Supporting Material: --
⌋()
⌈
Type: Valid
Description: If a generic module (e.g. PDU Router) requests an interface
from an surrounding module, the surrounding module shall offer the
interface, unless a configuration parameter exists which suppresses calling
the interface.
In case the respective module does not support the functionality of
the interface, the module shall supply an 'empty function'.
⌈
Type: Valid
Description: In all cases where concurrent access to hardware registers may occur, the
caller has to protect manipulation of such registers by disabling interrupts
and using read-modify-write functions, unless there is specific hardware
support (e.g. atomic instructions) which makes such precautions
unnecessary.
Rationale: The respective implementation restriction in the SWS General guarantees
system consistency with no influence on system functionality. It only
applies to BSW modules with direct access to hardware registers
Use Case: CompletionOfCDD concept
Dependencies: --
Supporting Material: --
⌋()
⌈
Type: Valid
Description: Basic Software Modules which require a periodic main function shall allow to
configure the period time between ] 0 .. INF[ seconds.
Rationale: It should be avoided to standardize different upper limits for main functions.
Therefore the upper limit should be open (INF). Also the lower number
should exclude 0, since this value does not make sense. An implementation
may restrict the upper limit to a reasonable time, but the specifications
should not be limited. The lower limit is typically given by the used
implementation and hardware.
Use Case: Avoid fragmentation of different main functions caused by different upper
limits.
Dependencies: --
Supporting Material: --
⌋(RS_BRF_01056)
⌈
Type: Valid
Description: If a Basic SW module needs to shutdown functionality (e.g. release
hardware resources), this shall be done in a separate API function.
Rationale: Interface to ECU state manager
Use Case: --
Dependencies: --
Supporting Material: --
⌋(RS_BRF_01096)
⌈
Type: Changed (by the TF Production Errors)
Description: All AUTOSAR Basic Software Modules shall report development relevant
errors if development error detection is enabled:
Errors caused by software bugs
Errors caused by incorrect integration by the user
Errors caused by invalid configuration
Errors caused by bugs in the integration tools
Development errors are handled like assertions: After calling the configured
Det_ReportError hooks, the normal control flow of execution shall not be
continued. DET shall stop execution of the entire process.
This can be done for example with an endless loop or a halt statement or by
creating something like an exception stack trace. If there is only one hook
function configured, this might also do the exception handling and stop
execution.
Rationale: Extended error detection for debugging and especially integration.
Use Case: The EEPROM driver provides internal checking of API parameters which is
only activated for the first software integration test (‘development build’) and
disabled afterwards (‘deployment build’).
Dependencies: [SRS_BSW_00350] Development error detection keyword
Supporting Material:
⌋(RS_BRF_02168)
⌈
Type: Valid
Description: All AUTOSAR Basic Software Modules shall not return specific development
error codes via the API. In case of a detected development error, the error
shall only be reported to the DET. If the API- function which detected the
error has a return type it shall return a value which indicates an error.
Rationale: The production version of a module shall have a limited number of return
values.
Use Case: --
Dependencies: [SRS_BSW_00337] ,[SRS_BSW_00327] ,[SRS_BSW_00357]
Supporting Material: --
⌋(RS_BRF_02168)
⌈
Type: Changed (by the TF Production Errors)
Description: AUTOSAR Basic Software Modules shall report all production errors and
34 of 80 Document ID 043: AUTOSAR_SRS_BSWGeneral
- AUTOSAR confidential -
General Requirements on Basic Software Modules
AUTOSAR CP Release 4.3.1
⌈
Type: Valid
Description: Pre-de-bouncing of error status information reported via
Dem_SetEventStatus is done within the DEM.
Pre-de-bouncing is handled inside the Diagnostic Event Manager using
AUTOSAR predefined generic signal de-bouncing libraries.
The Diagnostic Event Manager shall define the interface to the libraries. By
defining the interface it is possible for the user to implement further
extensions for more complex pre-de-bouncing algorithms.
Rationale: Central configuration and handling of error events instead of spreading the
handling all over the Basic Software.
Use Case: This is only one of several possible use cases (error detected and notified):
Error Event
Error Event treated as
“Real“ Error
BSW Module
A P P F F F
Dem Starts
ReportError Timer
Dem
LibraryTimer
.
Dem
Main Function
20 40 60 80 100 t
0
P: DEM_PASSED
F: DEM_FAILED
The timer function shall be provided (in this example) in the pre-de-bouncing
library of the Diagnostic Event Manager.
Dependencies: [SRS_BSW_00339] Reporting of production relevant error status
Supporting Material: --
⌋()
5.1.6.5 [SRS_BSW_00417] Software which is not part of the SW-C shall report
error events only after the DEM is fully operational.
⌈
Type: Valid
Description: Software which is not part of the SW-C shall report error events only after
the DEM is fully operational.
Rationale: It is only possible to store errors in error memory after the DEM is fully
operational. To simplify error handling within DEM (and to gain efficiency)
this requirement is needed.
Use Case: Reporting of non plausible sensor values.
Dependencies: --
Supporting Material: --
⌋( RS_BRF_02184,RS_BRF_02168)
⌈
Type: Valid
Description: All AUTOSAR Basic Software Modules shall check passed API parameters
for validity. The (minimum) conditions if a parameter needs to be treated as
invalid shall be described for each parameter (e.g. check of reserved
values).
This checking shall be statically configurable (ON/OFF) per
module with one single preprocessor switch.
Rationale: Ease of debugging for development, efficient code for deployment.
Use Case: The EEPROM driver provides internal checking of API parameters which is
only activated for the first software integration test (‘development build’) and
disabled afterwards (‘deployment build’).
Dependencies: [SRS_BSW_00350],[SRS_BSW_00327]
Supporting Material: --
⌋(RS_BRF_01384)
⌈
Type: Valid
Description: All Basic SW Modules shall perform a pre-processor check of the versions of
all imported include files (Inter Module Checks).
Rationale: Compatibility enforcement, error avoidance, ease of integration
Use Case: The integration of incompatible imported files shall be avoided.
The version numbers of all modules shall be listed in the Basic Software
Description Template. During configuration a tool shall check whether the
version numbers of all integrated modules belong to the same AUTOSAR
major and minor release (same baseline). If not an error shall be reported.
⌈
Type: Valid
Description: All production code error ID symbols are defined by the Dem module and
shall be retrieved by the other BSW modules from Dem configuration.
Rationale: The error codes shall be defined in a central file, to simplify the include
structure of the DEM.
Use Case: --
Dependencies: --
Supporting Material: --
⌋()
⌈
Type: Changed (by the TF Production Errors)
Description: The BSW shall document all production errors, extended production errors,
development errors and runtime errors which are supported by the BSW
module.
Rationale: Documentation, overview of errors
Use Case: --
Dependencies:
Supporting Material: --
⌋( RS_BRF_02184,RS_BRF_02168)
⌈
Type: Valid
Description: The BSW shall specify the configuration for detecting an error. This
configuration shall describe criteria and limits how the error is detected and
possibly reset. This is applicable for production code errors as well as for
development errors.
Rationale: --
Use Case: a) configuration of debounce counters (counting up/down), configuration of
limits of these debounce counters etc.,
b) specify the library function which is to be used to debounce.
c) specify whether the Diagnostic modules may request to delete errors. If
so, specify how and when errors may be reset
Dependencies: --
Supporting Material: --
⌋( RS_BRF_02184,RS_BRF_02168,RS_BRF_02176)
⌈
Type: New
37 of 80 Document ID 043: AUTOSAR_SRS_BSWGeneral
- AUTOSAR confidential -
General Requirements on Basic Software Modules
AUTOSAR CP Release 4.3.1
Rationale: Catch sporadic error events caused by seldom occurring systematic faults.
Use Case:
CANNM_E_NET_START_IND: Reception of NM PDUs in Bus-Sleep
Mode
Dependencies: --
Supporting Material:
⌋( RS_BRF_02184,RS_BRF_02168,RS_BRF_02176)
⌈
Type: New
Description: All AUTOSAR Basic Software Modules shall report a production error if this
error is caused by any hardware problem, e.g., aging, deterioration, total
hardware failure, bad production quality, incorrect assembly, etc.
and the same root cause is not detected as a production error by
any other BSW module (usually, but not necessarily closer to the
hardware)
and if at least one of the following criteria is met:
o The error leads to an increase of emissions and must be
detected to fulfill applicable regulations.
o The error limits the capability of any other OBD relevant
diagnostic monitors.
o The error requires limp-home reactions, e.g. to prevent
further damage to the hardware; or customer perceivable
properties.
o The garage shall be pointed to the failed component for
repair actions.
Production errors shall be defined in a granularity of standardized
diagnostics trouble codes (e.g., SAE J2012), if possible.
Note: Production errors are regular operation of the software, but not of the
system. It is not any kind of exception handling. Software bugs or software
misbehavior are no production errors.
Rationale: Report errors that are useful in the field.
Use Case: Flash is no longer writable due to aging, emission relevant adaptation maps
can no longer be stored. The control unit must be replaced.
Dependencies: If not specified by AUTOSAR, the real classification of a particular error
beeing a production error or an extended production error may be selectable
by configuration. Dependent of this classification the particular error may
cause different reactions within the Dem.
Supporting Material: --
⌋( RS_BRF_02184,RS_BRF_02168,RS_BRF_02176)
⌈
Type: New
Description: AUTOSAR Basic Software Modules may report extended production errors
(to the module Dem) if this error is caused
by any hardware problem of the ECU itself, e.g., a memory
transactions failed,
by a misbehavior of the embedding environment, e.g., the loss of
messages due to any problem of the communication channel
AND
this error does not comply to any criteria of the production error
definition, notably
o OBD relevance
o direct limp-home reactions
o direct repair actions in the garage
the error cause is already covered by any other production error
Extended production errors shall define set and reset conditions.
Note: Extended production errors are regular operation of the software, but
not of the system. It is not any kind of exception handling. Software bugs or
software misbehavior are no ‘Extended production errors’.
Note: Extended production errors may not be entered in the primary event
memory of the module Dem.
⌈
Type: New
Description: The detection of production errors and extended production errors shall
distinguish between fault detection, failure free detection, and undecided
state. Only detected faults and explicitly failure free detected states shall be
reported.
Rationale: Avoid incorrect healing in case a failure still persists: Do not heal the
OBD pending/confirmed state unless the vehicle is failure free.
Allow the system to heal if the repair is executed without using a
garage tool to clear the error.
Heal only if the system is known to work, not in the absense of
detected failures, i.e., ensure the correct computation of the OBD
readiness information.
Use Case: The driver re-connects a disconnected sensor, and the system is again
working properly, and the production error is healed.
Dependencies: --
39 of 80 Document ID 043: AUTOSAR_SRS_BSWGeneral
- AUTOSAR confidential -
General Requirements on Basic Software Modules
AUTOSAR CP Release 4.3.1
Supporting Material: --
⌋( RS_BRF_02184,RS_BRF_02168,RS_BRF_02176)
⌈
Type: New
Description: State information are detected either by the change of the state or when
checked (event-based or cyclic).
Checks shall be executed as often as possible, at least once per related
monitoring cycle (e.g. OBD driving cycle for emission relevant systems), or
as often as required by applicable regulations, to the extend feasible.
Rationale: Timely detection of failures
Readiness / self-healing in case failures are absent
Ensure correct behavior of event handling during the
enableconditions are not fulfilled (if enable-conditions are handled in
Dem).
Use Case: If a monitor is required to be continuous according to the regulations
(CCR1968-2) the execution cycle shall be at least 2 times per second.
Dependencies: --
Supporting Material: CCR1968-2
⌋(RS_BRF_02096,RS_BRF_02224)
⌈
Type: New
Description: Production errors shall be able to heal, if a problem no longer persists.
Rationale: Detected production errors may cause fail-safe / limp-home modes, usually
through the FiM. During such operation, the detection algorithm may be
disabled, preventing the error from healing. Therefore, care must be taken to
avoid this situation or provide a means of healing, e.g., by starting without
fail-safe / limp-home modes in the next operating cycle.
Use Case: A component is detected as faulty and the error is reported to the Dem. As a
consequence, the component is disabled and no further fault or fault free
detection is possible. At the next operation cycle, the component is re-tested,
and passes the tests, PASS is reported to the Dem.
Dependencies: --
Supporting Material: --
⌋()
⌈
Type: New
Description: Some production errors detect the same root cause as failure. To avoid
duplicate error reports to the garage, detection of one error shall be disabled
40 of 80 Document ID 043: AUTOSAR_SRS_BSWGeneral
- AUTOSAR confidential -
General Requirements on Basic Software Modules
AUTOSAR CP Release 4.3.1
⌈
Type: New
Description: AUTOSAR Basic Software Modules may report transient faults.
Transient faults occur in the hardware due to particle passages or thermal
noise for instance and may cause software issues. The handling of those
transient faults may require use case dependent action that cannot be
reasonably decided by the detecting BSW module (most probably drivers)
themselves.
Transient faults are not implementation errors; they will not cause assertions
and therefore even not necessarily cause the abortion of the ‘normal’ control
flow of execution (as DET will do). They may heal in a sense that they
disappear again or get masked or get corrected by software activity.
Monitors of transient errors (if any) shall stay in production code (deployment
build).
Transient faults shall only be reported as an event in case of the occurrence
(have set conditions only). In contrast to production errors, there is no reset
conditions reported to an error handler.
An error handler of transient faults handles the corresponding transient faults
in a synchronous manner.
Rationale: Catch sporadic error events caused by transient hardware faults.
Use Case: • CAN controller goes offline due to bit-flip in its control register.
• Peripheral action lasts accidentally longer than expected (and
specified)
Dependencies: --
Supporting Material: --
⌋()
⌈
Type: Valid
Description: The AUTOSAR Basic Software shall provide a microcontroller abstraction
layer which provides a standardized interface to higher software layers.
Rationale: Portability and reusability.
Encapsulate implementation details of a specific microcontroller from higher
software layers.
Use Case: Exchange microcontroller ST10 with STAR12 without affecting higher
software layers interfacing with the microcontroller abstraction layer.
Dependencies: --
Supporting Material: [DOC_LAYERED_ARCH]
⌋(RS_BRF_01008,RS_BRF_01016)
⌈
Type: Valid
Description: The AUTOSAR Basic Software shall provide a hardware abstraction layer
which provides a stable interface to higher software layers which is
independent from the ECU hardware layout.
Rationale: Keep the impact of changes in the ECU hardware layout as small as
possible.
Portability and reusability of modules of higher software layers.
Flexibility for changes in the ECU hardware layout.
Use Case: Change the hardware layout of the ECU (e.g. PortA.5 PortD.7)
without affecting software layers interfacing with the hardware
abstraction layer.
Use the NVRAM manager with an internal and/or external EEPROM.
Provide uniform access to analog signals using the on-chip ADC or an
external ADC ASIC.
Dependencies: --
Supporting Material: [DOC_LAYERED_ARCH]
⌋(
RS_BRF_01016,RS_BRF_01856,RS_BRF_01864,RS_BRF_01872,RS_BRF_01880
,RS_BRF_01888,RS_BRF_01896,RS_BRF_01904,RS_BRF_01912,RS_BRF_0192
0,RS_BRF_01928,RS_BRF_01936)
⌈
Type: Valid
Description: Modules of the µC Abstraction Layer (MCAL) may not have hard coded
horizontal interfaces.
Necessary interactions (e.g. GPT triggered ADC conversion) shall be
implemented by using statically configurable notifications (callbacks).
Rationale: Avoidance of strong coupling, ease of integration, better structure
Use Case: --
Dependencies: --
Supporting Material: --
⌋()
⌈
Type: Valid
Description: Interfaces and the corresponding types which are provided exclusively for
one module should be separated into a dedicated header file. This should
prevent the inclusion of the <ModuleName>.h file.
Comment:
Common definitions for different interfaces (e.g. types) shall be defined in a
common header file (e.g. <Module Name>.h).
Rationale: Encapsulate an interface between modules in an include file
Use Case: Example: CanIf_Pdur.h, CanIf_NM.h
Dependencies: [SRS_BSW_00346] Basic set of module files.
Supporting Material: < Module name > shall be derived from WP Architecture “List of Basic
Software Modules”, [DOC_MOD_LIST] (2…8 characters). <User> shall be
the user module from the same list.
⌋()
⌈
Type: Valid
Description: Only the Operating System, complex drivers and modules of the
microcontroller abstraction layer are allowed to implement interrupt service
routines.
In the case of CAT2 ISRs this shall be at the latest in the RTE.
43 of 80 Document ID 043: AUTOSAR_SRS_BSWGeneral
- AUTOSAR confidential -
General Requirements on Basic Software Modules
AUTOSAR CP Release 4.3.1
In the case of CAT1 ISRs this shall be at the latest in the Interface layer.
⌈
Type: Valid
Description: The runtime of interrupt service routines and functions that are running in
interrupt context should be kept short.
Where an interrupt service routine is likely to take a long time, an operating
system task should be used instead.
Rationale: Real time behavior, avoid blocking of the whole system.
Use Case: An ISR calls a callback which is calling other callbacks.
Dependencies: [SRS_BSW_00333] Documentation of callback function context
Supporting Material: --
⌋()
⌈
Type: Valid
Description: It shall be possible to create an AUTOSAR ECU out of modules provided as
source code and modules provided as object code, even mixed.
Rationale: Allow both:
IP protection and guaranteed test coverage : object code
High efficiency and configurability at ECU configuration time (by
integrator) : source code
Use Case: Some simple drivers could be provided as object code. More complex and
configurable modules could be provided as source code or even generated
code.
Dependencies: [SRS_BSW_00344] Configuration at Runtime
Supporting Material: --
⌋()
⌈
44 of 80 Document ID 043: AUTOSAR_SRS_BSWGeneral
- AUTOSAR confidential -
General Requirements on Basic Software Modules
AUTOSAR CP Release 4.3.1
Type: Valid
Description: The unit of time for specification and configuration of Basic SW modules
shall be preferably in physical time unit, not ticks.
Nevertheless for some module “tick” parameters are accepted
Rationale: The duration of a "tick" varies from system to system.
Use Case: The software specification defines the unit (e.g. µs, s) and software
configuration uses these units.
OS Modules require time parameter values in ticks.
Dependencies: --
Supporting Material: --
⌋()
⌈
Type: Valid
Description: Files holding configuration data for AUTOSAR Basic SW modules shall have
a format that is readable and understandable by human beings.
Rationale: Plausibility checking, comparison of different versions of configuration data.
Use Case: XML is readable.
Dependencies: --
Supporting Material: --
⌋()
⌈
Type: Valid
Description: If an SWS of a BSW module is allowed to be linked to more than one
implementation of another BSW module into an AUTOSAR binary image,
then all involved SWS’s shall ensure that all externally visible C identifiers
(i.e. types, variables, macros, functions, etc) are defined such that no
conflicts can arise for surrounding BSW modules using these multiple
implementations at compile time and that no ambiguity exists at link time.
Rationale: If the rule is not followed, systems with multiple implementations of one BSW
Module will mostly get an error at compile time or link time.
Use Case: In CAN Driver there are 2 type definitions
i) Can_IdType
ii) Can_PduType
which are used in CanIf.
Can_IdType can be uint16 or uint32 type.
⌈
Type: Draft
Description: If more than one implementation of a BSW Module is linked into an Autosar
system which results in conflict of externally visible C Identifiers (i.e.
types, variables, macros etc ), a common header file may define all the
conflicting identifiers.
The header file shall be named as
<Module Abbreviation>_GeneralTypes.h
Module Abbreviation is defined in Basic Software Module List. It refers
to BSW Module which has more than one implementation.
Rationale: BSW systems with multiple implementations of one BSW Module will mostly
get an error at compile time or link time, if they are not harmonized.
Use Case: --
Dependencies: --
Supporting Material: --
⌋(RS_BRF_01016)
⌈
Type: Valid
Description: An AUTOSAR Basic Software module shall only invoke the callback
functions of Application Software Components and/or Sensor/Actuator SW-
Components through the Client Server communication of the RTE.
CDDs are not affected by this requirement.
Rationale: RTE shall not be bypassed if AUTOSAR Basic Software Modules are calling
callbacks provided by Application SW-Cs and/or Sensor/Actuator SW-Cs,
because only these components are restricted to having only AUTOSAR
interfaces. This is to support memory partitioning.
Use Case: --
Dependencies: --
Supporting Material: --
⌋(RS_BRF_01064)
⌈
Type: Valid
Description: Drivers for external devices shall use and offer the same interfaces as
internal drivers when calling or being called by the interface module.
Rationale: In general, the driver for external devices shall follow the same SWS
specification. For external drivers, when calling Det, use the same module ID
as the internal drivers.
Use Case: System which uses an internal and an independent external HW Wdg
module.
Dependencies: --
Supporting Material: [SRS_BSW_00005]
46 of 80 Document ID 043: AUTOSAR_SRS_BSWGeneral
- AUTOSAR confidential -
General Requirements on Basic Software Modules
AUTOSAR CP Release 4.3.1
⌋(RS_BRF_01056)
⌈
Type: Valid
Description: MISRA C describes programming rules for the C programming language and
a process to implement and follow these rules.
⌈
Type: Draft
Description: All AUTOSAR Basic Software Modules shall be identified by an
unambiguous name. The module name is always part of related files.
⌈
Type: Valid
Description: If instances of BSW modules are characterized by:
- same vendor and
- same functionality and
- same hardware device
they shall be accessed index based.
Rationale: --
Use Case: --
Dependencies: [SRS_BSW_00347] Naming separation of drivers
Supporting Material: --
⌋()
⌈
Type: Valid
Description: Driver modules shall be named according to the following rules (only for
implementation, not for the software specification):
First the module name has to be listed:
<Module Abbreviation>
After that the vendor Id defined in the AUTOSAR vendor list has to be
given
<Vendor Id>
At last a vendor specific name (the vendor API infix) follows
<Vendor API infix>
Only for API names, last name shall be
<API Service name>
All parts shall be separated by underscores “_”.
This naming extension applies to the following externally visible
elements of the module:
o File names
o API names
o Published parameters
o Memory allocation keyword
⌈
Type: Valid
Description: All AUTOSAR Basic Software Modules shall label enumeration literals and
#defines according to the following scheme:
⌈
Type: Valid
Description: All AUTOSAR Basic Software Modules shall label data types according to
the following scheme:
Note:
Basic AUTOSAR types ([SRS_BSW_00304]) need not support the scheme
defined here.
Dependencies: --
Supporting Material: --
⌋(RS_BRF_01024)
⌈
Type: Valid
Description: All AUTOSAR Basic Software Modules shall label global variables
according to the following scheme:
Composition of name: <Module name>_<Variable name>
Only one underscore between module name and variable name
Spelling of name: First letter of each word upper case, consecutive
letters lower case
Rationale: Enhance readability and unique classification of global variables.
Use Case:
Dependencies: --
Supporting Material: --
⌋(RS_BRF_01024)
⌈
Type: Valid
Description: All AUTOSAR Basic Software Modules shall implement an API based on the
following naming rules:
- Composition of API: <Module name>_ServiceName()
<Mip>_<Sn>
- Where <Mip> is the Module implementation prefix and <Sn> is the
API Service name
- Module name: 2..8 letters, derived from WP Architecture SW Module
List
- Only one underscore between module name and service name
- Spelling of API: First letter of each word upper case, consecutive
letters lower case
Rationale: Avoidance of name clashes, uniform AUTOSAR API;
The API shows to which module it belongs
Use Case: Can_TransmitFrame()
Nm_RequestBusCommunication()
Adc_Init()
Eep_Write()
Nvm_GetState()
Dependencies: --
⌈
Type: Valid
Description: The main processing function of each AUTOSAR Basic Software Module
shall be named according to the following rule:
Please Note: The Use case is not recommendation for the particular Module,
it just illustrates Main processing function possibilities.
Dependencies:
Supporting Material: <Module name> shall be derived from WP Architecture “List of Basic
Software Modules”, [DOC_MOD_LIST] (2…8 charactersWP Architecture SW
Module List (Module Abbreviations))
⌋(RS_BRF_01024)
⌈
Type: Valid
Description: All AUTOSAR Basic Software Modules shall apply the following naming
rules for all error values:
- Error values shall have only CAPITAL LETTERS
- Naming convention: <MODULENAME>_E_<ERRORNAME>
- If <ERRORNAME> consists of several words, they shall be
52 of 80 Document ID 043: AUTOSAR_SRS_BSWGeneral
- AUTOSAR confidential -
General Requirements on Basic Software Modules
AUTOSAR CP Release 4.3.1
separated by underscores
Rationale: Avoidance of name clashes, uniform AUTOSAR error values;
The error shows to which module it belongs.
Use Case: The EEPROM driver has the following error values:
EEP_E_BUSY
EEP_E_PARAM_ADDRESS
EEP_E_PARAM_LENGTH
EEP_E_WRITE_FAILED
Dependencies: [SRS_BSW_00331] [SRS_BSW_00369]
Supporting Material: < MODULENAME > shall be derived from WP Architecture “List of Basic
Software Modules”, [DOC_MOD_LIST] (2…8 characters)
⌋(RS_BRF_01024)
⌈
Type: Valid
Description: All AUTOSAR Basic Software Modules shall apply the following naming
rules for status values that are visible outside of the module:
- Status values shall have only CAPITAL LETTERS
- If <STATUSNAME> consists of several words, they shall be
separated by underscores
Rationale: Avoidance of name clashes, uniform AUTOSAR status values;
The status value shows to which module it belongs.
Use Case: The Eeprom driver has the following status values:
EEP_UNINIT
EEP_IDLE
EEP_BUSY
Dependencies: [SRS_BSW_00331] Separation of error and status values
Supporting Material: < MODULENAME > shall be derived from WP Architecture “List of Basic
Software Modules”, [DOC_MOD_LIST] (2…8 characters)
⌋(RS_BRF_01024)
⌈
Type: Draft
Description: All AUTOSAR Basic Software Modules shall allow the enabling/disabling of
detection and reporting of development errors. It shall be configurable and
the default value of the configuration shall be that those error type is
disabled.
Rationale: Provide module wide debug instrumentation facilities. Each defined keyword
has to be properly documented.
Use Case: Example:
In Eep_Cfg.h:
#define EEP_DEV_ERROR_DETECT STD_ON /* detection module
wide enabled */
…
In source Eep.c:
53 of 80 Document ID 043: AUTOSAR_SRS_BSWGeneral
- AUTOSAR confidential -
General Requirements on Basic Software Modules
AUTOSAR CP Release 4.3.1
#include "Eep_Cfg.h"
…
⌈
Type: Valid
Description: All AUTOSAR Basic Software Modules configuration parameters shall be
named according to the following naming rules:
- Naming convention: <Module Abbreviation><ParameterName>
< ParameterName > may consist of several words which may or may not be
separated by underscore.
⌈
Type: Valid
Description: Compiler switches shall be compared with defined values. Simple checks if a
compiler switch is defined shall not be used.
In general the symbols which switch functionality on or off are defined in
Std_Types.h
Rationale: C-Language allows asking for defined symbols. This shall be avoided.
Use Case: Example:
Do :
#if ( EEP_DEV_ERROR_DETECT == STD_ON )
..
Don’t:
#ifdef EEP_DEV_ERROR_DETECT
..
Dependencies: --
Supporting Material: --
⌋(RS_BRF_01616,RS_BRF_01024)
⌈
Type: Draft
Description: All AUTOSAR Basic Software Modules shall apply the following naming rule
for enabling/disabling the existence of the API. It shall be configurable and
the default value of the configuration shall be that this API is not available.
Rationale: Enable/Disable the reading out of version information
Use Case: Example:
In Eep_Cfg.h:
#define EEP_VERSION_INFO_API STD_ON /*API enabled */
…
Dependencies: [SRS_BSW_00407]
Supporting Material: < MODULENAME > shall be derived from WP Architecture “List of Basic
Software Modules”, [DOC_MOD_LIST] (2…8 characters)
⌋(RS_BRF_01028)
⌈
Type: Valid
Description: Each callout function shall be mapped to its own memory section and
memory class. These memory classes will then be mapped to the actually
implemented memory classes at integration time.
#define MSN_START_SEC_CBN_CODE
#define MSN_STOP_SEC_CBN_CODE
Where:
MSN: Module Short Name as officially defined in AUTOSAR (see
supporting material).
CBN: Call Back Name, which shall have the same spelling of the
Callback name including module reference but using only capital letters.
Cbn: Callback name using the conventional Camel Case notation for
API names.
Rationale: The memory segment used for a callout is not known to the module
developer. The integrator needs the freedom to map callouts independently
from the module's design.
Use Case: In order to ensure uniqueness, it is recommended to use the function´s
name to derive the name of the memory section and the name of the
memory class.
For example:
#define COM_START_SEC_COM_SOMECALLOUT_CODE
#include “Com_MemMap.h”
FUNC(void, COM_SOMECALLOUT_CODE) Com_SomeCallout(void);
#define COM_STOP_SEC_COM_SOMECALLOUT_CODE
#include “Com_MemMap.h”
Dependencies: --
Supporting Material: “List of Basic Software Modules”, UID [150]
⌋(RS_BRF_01024)
⌈
Type: Draft
Description: File names shall be considered case sensitive regardless of the filesystem in
which they are used.
Rationale: Some file systems do not distinguish between file names spelled with the
same letters but with different cases. Allowing such variability in the
definitions can cause ambiguities.
Use Case: If different implementers implement modules using same names with
different cases, the compile and link process shall have unpredictable results
depending on the file system on which they are executed, leading eventually
to errors (source or object file not found).
⌈
Type: Draft
Description: It shall not be allowed to name any two files so that they only differ by the
cases of their letters.
Rationale: Problems deriving potentially ambiguous name definitons must be avoided
already in the specification phase
Use Case: In a SWS the include files:
RTE_cfg.h
rte_cfg.h
⌈
Type: Valid
Description: NULL pointer error naming convention. The name for the development errors
for NULL pointer violations is <MIP>_E_PARAM_POINTER.
Rationale: Harmonization of standard
Use Case: --
Dependencies: --
Supporting Material: --
⌋ (RS_BRF_01024)
⌈
Type: Valid
Description: Invalid configuration set selection error naming convention
The name for the Invalid configuration set selection errors
<MIP>_E_INIT_FAILED.
Rationale: Harmonization of standard
Use Case: --
Dependencies: --
Supporting Material: --
⌋ (RS_BRF_01024)
⌈
Type: Valid
Description: The Get Version Information API name follows SRS_BSW_00310 and has
GetVersionInfo as Service name.
Example: void Eep_21_LDExt_GetVersionInfo (
Std_VersionInfoType *versioninfo
Rationale: Harmonization of standard
Use Case: --
Dependencies: --
Supporting Material: --
⌋ (RS_BRF_01024)
⌈
Type: Valid
Description: All AUTOSAR Basic Software Modules shall provide a standardized set of
unique header files which separates source code from configuration. The
exact structure shall be defined in SWS_BSW_General including the naming
convention using the module name.
Rationale: Source code and configuration are strictly separated. User defined
configurations will not imply a change of the original source code. Other
BSW Modules which need to access configuration data can do this without
need for source code change.
Use Case: Separate post built configuration data from precompile configuration data,
source code from configuration data in general etc..
Dependencies: [SRS_BSW_00158],[SRS_BSW_00345], [SRS_BSW_00347],
[SRS_BSW_00412],[SRS_BSW_00314], [SRS_BSW_00419]
Supporting Material: < Module name > shall be derived from WP Architecture “List of Basic
Software Modules”, [DOC_MOD_LIST] (2…8 characters)
⌋(RS_BRF_02080,RS_BRF_01024)
⌈
Type: Obsolete
Description: All modules of the AUTOSAR Basic Software shall strictly separate
configuration from implementation.
Rationale: Easy and clear configuration.
Use Case: The file Adc_Cfg.h contains the pre-compile time configurable parameters to
set the properties of the module Adc.
Post build configuration parameters are stored in the file Adc_PBcfg.c
Dependencies: [SRS_BSW_00345],[SRS_BSW_00346]
Supporting Material: --
58 of 80 Document ID 043: AUTOSAR_SRS_BSWGeneral
- AUTOSAR confidential -
General Requirements on Basic Software Modules
AUTOSAR CP Release 4.3.1
⌋()
⌈
Type: Valid
Description: All internal driver modules shall separate the interrupt frame definition from
the service routine in the following way:
<Module name>_Irq.c: implementation of interrupt frame
<Module name>.c: implementation of service routine called from
interrupt frame
Rationale: Flexibility using different compilers and/or different OS integrations
Use Case: The interrupt could be realized as ISR frame of the operating system or
implemented directly without changing the driver code.
The service routine can be called directly during module test without the
need of causing an interrupt.
Dependencies: --
Supporting Material: < Module name > shall be derived from WP Architecture “List of Basic
Software Modules”, [DOC_MOD_LIST] (2…8 characters)
⌋(RS_BRF_01144)
⌈
Type: Draft
Description: I. A Basic Software Module implementing an Autosar Service shall
include its Application Types Header file in the Module Header File.
II. Data Types used in Standard Interface and Standard AUTOSAR
Interface shall only be defined in RTE Types Header file only.
III. A Basic Software Module implementing an Autosar Service shall
include Rte_<ModuleShortName>.h as AUTOSAR Service
Application Header File, providing the interface for interaction with
the RTE.
IV. A Basic Software Module implementing an Autosar Service shall
include its AUTOSAR Service Application Header File in module
files, which are using RTE interfaces. The Application Header file
shall not be included in module files, which are in included directly or
indirectly by other modules.
Rationale: Standardizing Include Header file structure will allow common data types to
be defined in RTE Types header files. This will avoid double and inconsistent
59 of 80 Document ID 043: AUTOSAR_SRS_BSWGeneral
- AUTOSAR confidential -
General Requirements on Basic Software Modules
AUTOSAR CP Release 4.3.1
definition of data types in both BSW and Software Component. This will also
avoid type casts if SW-Cs are communicating with Autosar Services.
Use Case:
All BSW Services which are called by Application SW-C and share data
types. E.g.
Asynchronous NvRAM Block request result returned by the operation
GetErrorStatus and API service NvM_GetErrorStatus.
Dependencies: --
Supporting Material: Please see the Figure “Relationships between RTE Header Files” and
related information in Chapter “RTE Modules” of RTE_SWS
⌋()
⌈
Type: Draft
Description: All AUTOSAR standard types and constants shall be placed and organized
in a standard type header file.
Standard type header file naming convention: Std_Types.h
This standard type header file shall
include the Platform specific type header (Platform_Types.h)
include the compiler specific language extension header
(Compiler.h)
define the type Std_ReturnType
define values for E_OK and E_NOT_OK
define values for STD_ON, STD_OFF,STD_HIGH, STD_LOW,
STD_ACTIVE, STD_IDLE
Rationale: Provide uniform framework wide access to standard types to be used by all
modules.
Use Case: Each module that uses AUTOSAR integer data types and/or the standard
return type shall include the file Std_Types.h.
Dependencies: [SRS_BSW_00357], [SRS_BSW_00353]
Supporting Material: Important note for implementation of this header file:
Because E_OK is already defined within ISO 17356-3, E_OK has to be
checked for being already defined:
/* for ISO 17356-3 compliance this typedef has been
added */
#ifndef STATUSTYPEDEFINED
#define STATUSTYPEDEFINED
typedef unsigned char StatusType;
#define E_OK 0
#endif
⌋(RS_BRF_01024)
⌈
Type: Valid
Description: All integer type definitions of target and compiler specific scope shall be
placed and organized in a single type header.
Name of platform types header file: Platform_Types.h
Rationale: Separate compiler and µC-specific integer types from standard types.
Use Case: Changing the microcontroller and/or compiler shall only affect a limited
number of files.
⌈
Type: Valid
Description: All mappings of not standardized keywords of compiler specific scope shall
be placed and organized in a compiler specific type and keyword header.
⌈
Type: Valid
Description: All AUTOSAR Basic Software Modules shall only import the necessary
61 of 80 Document ID 043: AUTOSAR_SRS_BSWGeneral
- AUTOSAR confidential -
General Requirements on Basic Software Modules
AUTOSAR CP Release 4.3.1
information (i.e. header files) that is required to fulfill the modules functional
requirements.
Rationale: Promote defensive module layout. Modules shall not import functionality that
could be misused.
Shorten compile times.
Use Case: --
Dependencies: --
Supporting Material: --
⌋()
⌈
Type: Valid
Description: All AUTOSAR Basic Software Modules shall export only that kind of
information in their correspondent header-files explicitly needed by other
modules.
Rationale: Prevent other modules accessing functionality and data that is ‘none of their
business’.
Use Case: The NVRAM Manager shall not know all processor registers because
someone has included the processor register file in another header file used
by the NVRAM manager.
Dependencies: --
Supporting Material: --
⌋(RS_BRF_02024)
⌈
Type: Valid
Description: All AUTOSAR Basic Software Modules should avoid the duplication of code.
Rationale: Avoid bugs during maintenance
Use Case: A module contains 4 code segments which are equal. During maintenance of
the module 3 of them have been updated, 1 has been forgotten BUG.
Dependencies: --
Supporting Material: --
⌋(RS_BRF_02072,RS_BRF_02112,RS_BRF_02032)
⌈
Type: Valid
Description: All AUTOSAR Basic Software Modules implementing shared code shall
ensure reentrancy if code is exposed to preemptive or parallel environments.
For multi-core systems, reentrancy shall be ensured for unrestricted
concurrent execution of that service on several cores (concurrency safety).
Rationale: Shared code eases functional composition, reusability, code size reduction
and maintainability. As a drawback, shared code shall be implemented
reentrant if it is used in preemptive environments or on multiple partitions in
parallel. Please note that an implementation that is reentrant on single core
62 of 80 Document ID 043: AUTOSAR_SRS_BSWGeneral
- AUTOSAR confidential -
General Requirements on Basic Software Modules
AUTOSAR CP Release 4.3.1
⌈
Type: Valid
Description: Those software modules have to be developed once and shall be compilable
for all processor platforms without any changes. Any necessary processor or
compiler specific instructions (e.g. memory locators, pragmas, use of atomic
bit manipulations etc.) have to be exported to macros and include files.
Rationale: Minimize number of variants and development effort
Use Case: NVRAM Manager, Network Management, …
Dependencies: --
Supporting Material: --
⌋(RS_BRF_01000)
⌈
Type: Valid
Description: Autosar shall allow BSW modules to define and handle Interrupts.
Rationale: --
Use Case: In the case where the entire driver is delivered as source this isn’t a problem.
In the case where the MCAL BSW module is delivered as object code, the
interrupt handler could be written as a pair of small stubs (a cat1 stub and a
cat2 stub) that are delivered as source, compiled as necessary, and simply call
the main handler.
Dependencies: --
Supporting Material: --
⌋()
⌈
63 of 80 Document ID 043: AUTOSAR_SRS_BSWGeneral
- AUTOSAR confidential -
General Requirements on Basic Software Modules
AUTOSAR CP Release 4.3.1
Type: Valid
Description: It shall not be allowed for a module SWS to add requirements from Other
Modules
• If a requirement is missing, then raise an Rfc, possibly resulting in
a valid requirement within the module.
• For this validrequirement give reference of the document where original
requirement resides.
⌈
Type: Valid
Description: Every BSW Service API called by application software via RTE shall return a
Std_ReturnType, return value.
Refer to the Port Interface Section of the respective module, to
confirm if the APIs are accessed by the RTE.
Rationale: RTE call of BSW service always expect a return value of Std_ReturnType
Use Case: RTE always expects return type of Std_ReturnType for the BSW Service API
Call, any other return type or void shall cause incompatibility between the
RTE and BSW.
Dependencies: --
Supporting Material: --
⌋()
⌈
Type: Valid
Description: For success/failure of an API call, a return type is defined in Std_Types.h
which indicates the success or failure of the call.
Rationale: Enforces usage of already defined types instead of attempting to override
existing ones.
If different success states can occur and they are of interest for the caller
then different return values need to be defined.
Use Case:
Dependencies: [SRS_BSW_00348], [SRS_BSW_00377],[ SRS_BSW_00359]
Supporting Material: --
⌋(RS_BRF_01024)
⌈
Type: Valid
Description: 1. A Basic Software Module can return a module specifictypes.
Rationale: Example for possibility 1:
uint8 Can_Write(…)
return values: E_OK (0), CAN_BUSY (1), E_OK is taken from Std_Types.h,
CAN_BUSY is #defines in can.h.
Note: no strong type checking possible because return type is uint8 and
values are only #defines. E_OK can be used.
⌈
Type: Valid
Description: All AUTOSAR Basic Software Modules shall not use the native C data types.
⌈
Type: Draft
Description: For simple logical values and for API return values (if
applicable) AUTOSAR shall provide a boolean type.
The only allowed operations shall be: assignment, return, test for quality.
Rationale: Repeating requests of several WPs to define a boolean data type.
Use Case: API return value. Example:
In file Eep.h:
#include "Std_Types.h" /* this automatically includes
Platform_Types.h */
In calling module:
if (Eep_Busy() == FALSE) {…}
Dependencies: --
Supporting Material: Compiler vendors that provide a boolean data type that cannot be disabled
have to change their compiler (i.e. make it ANSI C compliant).
⌋()
⌈
Type: Valid
Description: All AUTOSAR Basic Software Modules shall not use compiler or platform
specific keywords directly.
Rationale: Direct use of not standardized keywords like "_near", "_far", "_pascal" in
the frameworks source code will create compiler and platform dependencies
that must strictly be avoided. If no precautions were made, portability and
reusability of influenced code is deteriorated and effective release
management is costly and hard to maintain.
Use Case:
Dependencies: [SRS_BSW_00361]
Supporting Material: --
⌋()
⌈
Type: Valid
Description: AUTOSAR Basic Software Modules shall not define global data in their
header files.
If global variables have to be used, the definition shall take place in the C
file.
Rationale: Avoid multiple definition and uncontrolled spreading of global data, limit
66 of 80 Document ID 043: AUTOSAR_SRS_BSWGeneral
- AUTOSAR confidential -
General Requirements on Basic Software Modules
AUTOSAR CP Release 4.3.1
⌈
Type: Valid
Description: All AUTOSAR Basic Software Modules shall indicate all global data with
read-only purposes by explicitly assigning the const keyword.
Rationale: In principle, all global data shall be avoided due to extra blocking efforts
when used in preemptive runtime environments. Unforeseen effects are to
occur if no precautions were made. If data is intended to serve as constant
data, global exposure is permitted only if data is explicitly declared read-only
using the const qualifier.
Use Case: const uint8 MaxPayload = 0x18;
Dependencies: --
Supporting Material: --
⌋()
Type: Valid
Description: All input parameters of scalar or enum type shall be passed as a value..
Rationale:
Use Case: For example a function named <Mip>_SomeFunction with a return type of
Std_ReturnType and a single parameter named SomeParameter of type
uint8 is defined with the following signature:
⌋(RS_BRF_01056)
Type: Valid
Description: All input parameters of structure type shall be passed as a reference
constant structure
Rationale: Passing input parameters of structure type by value would result in additional
67 of 80 Document ID 043: AUTOSAR_SRS_BSWGeneral
- AUTOSAR confidential -
General Requirements on Basic Software Modules
AUTOSAR CP Release 4.3.1
Std_ReturnType <Mip>_SomeFunction(P2CONST(SomeStructure,
AUTOMATIC, <MIP>_APPL_DATA) SomeParameter);
Dependencies:
Supporting Material: --
⌋ (RS_BRF_01056)
Type: Valid
Description: All input parameters of array type shall be passed as a reference to the
constant array base type
Rationale: This effectively matches the behavior specified in the ISO-C:90 namely that
a "declaration of a parameter as 'array of type' shall be adjusted to 'qualified
pointer to
type'".
Use Case: For example a function named <Mip>_SomeFunction with a return type of
Std_ReturnType and a single parameter named SomeParameter of type
array of uint8 is defined with the following signature:
⌋(RS_BRF_01056)
⌈
Type: Valid
Description: The passing of function pointers as API parameter is forbidden for all
AUTOSAR Basic Software Modules.
Rationale: MISRA C
Protected Operating System compatibility
Callbacks shall be defined statically at compile time, not during
runtime
Use Case: No, forbidden!!
Dependencies: [SRS_BSW_00007]
Supporting Material: --
⌋(RS_BRF_01056)
⌈
Type: Valid
Description: The return type of init() functions implemented by AUTOSAR Basic
Software Modules shall be void.
Rationale: Errors in initialization data shall be detected during configuration time (e.g.
by configuration tool).
Use Case: --
Dependencies: --
Supporting Material: --
⌋(RS_BRF_01056)
⌈
Type: Valid
Description: For post-build time configuration, or when multiple configuration sets are
available, the pointer to the base configuration structure (see
[SRS_BSW_00438]) shall be passed to the init function of the BSW module.
For pre-compile and link time configuration, when only one configuration set
is available, a NULL_PTR shall be passed for this parameter.
<Mip>_ConfigType
It shall be used for init function argument
Rationale: --
Use Case: Example:
void Eep_Init (const Eep_ConfigType *ConfigPtr)
⌈
Type: Valid
Description: All AUTOSAR Basic Software Modules callback functions shall avoid return
types other than void if possible.
Callback functions routed to Software Components (SWCs) via the RTE
shall be typed by Std_ReturnType, not void. The caller of the callback
function shall consider the case that the environment (RTE) can return
infrastructure errors (refer SWS_Rte_02593) e.g. in case the servers'
69 of 80 Document ID 043: AUTOSAR_SRS_BSWGeneral
- AUTOSAR confidential -
General Requirements on Basic Software Modules
AUTOSAR CP Release 4.3.1
⌈
Type: Valid
Description: AUTOSAR Basic Software Modules callback functions are allowed to have
parameters.
Rationale: Enhance flexibility and scope of callback functionality.
Use Case: If callback functions do serve as simple triggers, no parameter is necessary
to be passed.
⌈
Type: Valid
Description: The callback function invocation by the BSW module, which is routed via
RTE shall follow the signature provided by RTE to invoke servers via
Rte_Call API.
Rationale: The callback function has to be to be compatible to Rte_Call
API of the RTE to enable a type safe configuration and implementation of
AUTOSAR Services and IO Hardware Abstraction. Instance pointers are in
Basic Software not allowed.
Use Case: --
Dependencies: [SRS_BSW_00359]
Supporting Material: --
⌋( RS_BRF_01056,RS_BRF_01064)
⌈
Type: Valid
Description: It shall be allowed to use macros instead of functions where source code is
used and runtime is critical.
70 of 80 Document ID 043: AUTOSAR_SRS_BSWGeneral
- AUTOSAR confidential -
General Requirements on Basic Software Modules
AUTOSAR CP Release 4.3.1
It shall be allowed to use inline functions for the same purpose. Inline
functions have the advantage (compared to macros) that the compiler can
do type checking of function parameters and return values.
Rationale: Improve runtime behavior.
Use Case: --
Dependencies: Macros as well as inline functions are only possible when source code is
delivered.
Supporting Material: Attention has to be paid within reentrant systems.
MISRA-C
⌋()
⌈
Type: Valid
Description: All Basic Software Modules shall strictly separate error and status
information.
Rationale: Common API specification of AUTOSAR Basic Software Modules.
Use Case:
Dependencies: --
Supporting Material: [SRS_BSW_00327] Error values naming convention
[SRS_BSW_00335] Status values naming convention
⌋()
⌈
Type: Valid
Description: All Standardized Autosar Interfaces shall have unique requirement Id /
number.
The purpose of the standardized AUTOSAR Interface definition is to provide
a standard which has to be considered by Software Components defining
Service ports.
Therefore the Port of the Software Component has to be at least compatible
to the definition in the related SWS document.
Rationale: The standardized Autosar Interfaces definitions are not binding without a
requirement Id.
Use Case: A SWC deviating from the Operation names will hinder the integration
process. This is because the Ports of the Service and the Ports of the
Service User (SWC) are NOT compatible.
Dependencies: --
Supporting Material: --
⌋( RS_BRF_01056,RS_BRF_01024)
⌈
Type: Valid
71 of 80 Document ID 043: AUTOSAR_SRS_BSWGeneral
- AUTOSAR confidential -
General Requirements on Basic Software Modules
AUTOSAR CP Release 4.3.1
⌈
Type: Valid
Description: The specification of functional interfaces of AUTOSAR BSW modules shall
be specified in C90 according to ISO/IEC 9899:1990.
This implies that languages, which can interface to C90 can be used for
application programming.
Rationale: A useful reduction of programming languages to current programming
languages reduces the impacts on AUTOSAR definitions and specifications
due to logical and/or technical differences of different programming
languages.
Use Case: AUTOSAR implementation in C, C++.
Dependencies: --
Supporting Material: ISO/IEC 9899:1990 (C90)
⌋ (RS_BRF_01056)
5.2.3.9 currency
⌈
Type: Valid
Description: If a service supports concurrent execution in different partitions , the
implementation of the service shall ensure that concurrent handling of calls
is performed in a multi-core safe manner, i.e. several calls from different
partitions to the same service at the same time do not interfere with each
other.
This can be implemented, for example, by using exclusive areas and re-
entrant code.
⌈
Type: Valid
Description: If BSW is executed in multiple partitions, all functions in a BSW module
entity shall conform to the reentrancy level enforced by the API description of
the implemented Bsw module entry, or to a stricter level.
⌈
Type: Valid
Description: The module documentation shall contain at least the following items:.
Cover sheet with title, version number, date, author, document status,
document name
Change history with version number, date, author, change description,
document status
Table of contents (navigable)
Functional overview
Source file list and description
Module requirements
Used resources (interrupts, µC peripherals etc.)
Integration description (OS, interface to other modules etc.)
Configuration description with parameter, description, unit, validrange,
default value, relation to other parameters
⌈
Type: Valid
Description: “Multiplicity” defines how many times an entity (in this case configuration
parameter) is instanciated.
The multiplicity of each configuration parameter has to be documented.
It shall be documented what determines the number of entries (e.g. “one per
frame”).
Rationale: Overall (throughout the complete Basic Software) harmonization of
configuration parameter naming.
Use Case: Id of a PDU is multiple time present dependent on the number of PDUs to be
sent/received.
Dependencies: --
Supporting Material: --
⌋()
⌈
Type: Valid
Description: The scheduling strategy that is built inside the Basic Software Modules shall
be compatible with the strategy used in the system.
To achieve this, the following items shall be traced by BSW specific SWS:
polling / event driven
cooperative / pre-emptive
for each cyclic function:
invocation rate (either fixed value or allowed range)
execution order (dependencies to other modules)
synchronous / asynchronous processing
minimum and maximum function runtime (WCET)
maximum interrupt rate
Rationale: Today scheduling mechanisms differ between ECUs. A Basic Software
Module provides several entry points to be accessed by the other Basic
Software Modules/surrounding system. E.g. a function can react directly on
event or by a scheduled polling. The differences may result in difference in
real-time requirements, system load, latency etc.!
Use Case: On the one hand it is possible to avoid any direct function call between BSW
modules by using only scheduling and data interface – more deterministic.
On the other hand it is possible that beside the scheduling additional
functional interfaces exists to control BSW modules – less deterministic.
The integrating SW-system and its SW-architecture might restrict direct
function calls between SW-components. Thus not any SW-component will fit
in this SW-system.
Dependencies: --
Supporting Material: --
⌋(RS_BRF_01320)
⌈
Type: Valid
Description: For software integration the following data shall be available for each
supported platform:
- RAM/ROM consumption
Rationale: Due to stability of documentation, this information is provided in a separate
document for each supported platform. If a further platform is added, the
module documentation remains unvalid
Use Case: Microcontroller selection, software integration, configuration of operating
system
Dependencies: --
Supporting Material: --
⌋()
⌈
Type: Valid
Description: For each callback function it shall be specified if it is called from interrupt
context or not.
Rationale: User awareness. The code inside a callback function called from an ISR has
to be kept short.
Use Case: Some notification function is called from an ISR of the CAN driver. The user
filling this callback function has to know that the function is running in
interrupt context!
Dependencies: --
Supporting Material: --
⌋(RS_BRF_01064)
⌈
Type: Valid
Description: All Basic Software Modules shall provide a readable module vendor
identification in their published parameters.
Naming convention:
<MODULENAME>_VENDOR_ID
⌈
Type: Valid
Description: All software modules shall provide a module ID both in the header file and in
the module XML description file.
The value shall be taken from the Basic Software Module List.
Naming convention:
<MODULENAME>_MODULE_ID
⌈
Type: Valid
Description: All software modules shall provide a readable software version number in all
import header files.
Version number macros can be used for checking (Inter Module Checks)
and reading out the software version of a software module during compile
time and runtime.
It is preferred to derive this information from the version management
system automatically.
Rationale: Compatibility checking, configuration supervision
Use Case: --
Dependencies: [SRS_BSW_00004], [SRS_BSW_00318]
Supporting Material: --
⌋(RS_BRF_01032)
76 of 80 Document ID 043: AUTOSAR_SRS_BSWGeneral
- AUTOSAR confidential -
General Requirements on Basic Software Modules
AUTOSAR CP Release 4.3.1
⌈
Type: Valid
Description: Each AUTOSAR Basic Software Module file shall provide version numbers
in the header file as defined below:
Naming convention:
<MODULENAME>_SW_MAJOR_VERSION
<MODULENAME>_SW_MINOR_VERSION
<MODULENAME>_SW_PATCH_VERSION
<MODULENAME>_AR_RELEASE_MAJOR_VERSION
<MODULENAME>_AR_RELEASE_MINOR_VERSION
<MODULENAME>_AR_RELEASE_REVISION_VERSION
AR: Major/Minor/Revision Release Version number of AUTOSAR
specification which the appropriate implementation is based on.
SW: Major/minor/patch version number of the vendor specific
implementation of the module. The numbering shall be vendor specific
⌈
Type: Valid
Description: The version numbers of AUTOSAR Basic Software Modules shall be
enumerated according to the following rules:
- Increasing a more significant digit of a version number resets all less
significant digits
- The PATCH_VERSION is incremented if the module is still upwards and
downwards compatible (e.g. bug fixed)
- The MINOR_VERSION is incremented if the module is still downwards
compatible (e.g. validfunctionality added)
- The MAJOR_VERSION is incremented if the module is not compatible
any more (e.g. existing API valid)
Rationale: Provide unambiguous version identification for each module, provide version
cross check as well as basic version retrieval facilities.
Compatibility is always visible!
Use Case: Example: ADC module with version 1.14.2:
77 of 80 Document ID 043: AUTOSAR_SRS_BSWGeneral
- AUTOSAR confidential -
General Requirements on Basic Software Modules
AUTOSAR CP Release 4.3.1
- Versions 1.14.2 and 1.14.9 are exchangeable. 1.14.2 may contain bugs
- Version 1.14.2 can be used instead of 1.12.0, but not vice versa
- Version 1.14.2 cannot be used instead of 1.15.4 or 2.0.0
Dependencies: [SRS_BSW_00318]
Supporting Material: --
⌋(RS_BRF_01032)
⌈
Type: Valid
Description:
All needed informations by user of a module shall be stated in the
documentation of the module.
Rationale: Opportunity to identify uniquely the specific microprocessor, including known
bugs in the silicon so that its compatibility with the software can be
established.
Use Case: Different mask revisions of e.g. TriCore
Dependencies: --
Supporting Material: --
⌋(RS_BRF_01032)
⌈
Type: Valid
Description: All Basic Software Modules shall provide an XML file that contains the meta
data which is required for the SW integration process.
Rationale: Being able to have several drivers of the same type (e.g. 2 different
external flash drivers) on the same ECU without name clash
Ensure system consistency and correctness
Use Case: <function_provided>
<name>Eep_Write</name>
<prototype>Eep_ST16RF42_Write</prototype>
</function_provided>
⌈
Type: Valid
Description: AUTOSAR shall define header files which encapsulate compiler and platform
specific differences in memory mapping such that BSW modules and SWC
can be implemented of compiler and platform.
78 of 80 Document ID 043: AUTOSAR_SRS_BSWGeneral
- AUTOSAR confidential -
General Requirements on Basic Software Modules
AUTOSAR CP Release 4.3.1
6 References
[GLOSSARY] Glossary,
AUTOSAR_TR_Glossary.pdf