AUTOSAR CP RS ECUConfiguration
AUTOSAR CP RS ECUConfiguration
AUTOSAR CP R23-11
Requirements on ECU
Document Title Configuration
Document Owner AUTOSAR
Document Responsibility AUTOSAR
Document Identification No 85
4
AUTOSAR
2015-07-31 4.2.2 Release • Layout Update.
Management
• Updated [RS_ECUC_00008].
AUTOSAR • Added [RS_ECUC_00085].
2014-10-31 4.2.1 Release
Management • Added [RS_ECUC_00086].
• Tracing update.
AUTOSAR
2013-10-31 4.1.2 Release • Layout Update.
Management
AUTOSAR
2013-03-15 4.1.1 • Layout Update.
Administration
• Updated [RS_ECUC_00083].
AUTOSAR
2011-12-22 4.0.3 • Added detailed change history in
Administration
chapter 5.
• Introduction of Variant Handling
AUTOSAR
2010-02-02 3.1.4
Administration • Legal disclaimer revised
AUTOSAR
2008-08-13 3.1.1 • Legal disclaimer revised
Administration
• Document meta information extended
AUTOSAR
2007-12-21 3.0.1
Administration • Small layout adaptations made
• "Advice for users" revised
AUTOSAR
2007-01-24 2.1.15 • "Release Notes" added
Administration
• "Revision Information" added
• Added requirements [RS_ECUC_00076]
AUTOSAR
2006-11-28 2.1
Administration • Legal disclaimer revised
AUTOSAR
2006-05-16 2.0 • Initial release
Administration
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 intel-
lectual 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.
Contents
1 Scope of this document 8
1.1 Document Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2 Related Documentation 10
2.1 Input Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2 Specification Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3 Requirements Tracing 11
References
[1] Methodology for Classic Platform
AUTOSAR_CP_TR_Methodology
[2] Standardization Template
AUTOSAR_FO_TPS_StandardizationTemplate
[3] General Requirements on Basic Software Modules
AUTOSAR_CP_SRS_BSWGeneral
[4] Requirements on Runtime Environment
AUTOSAR_CP_SRS_RTE
[5] Glossary
AUTOSAR_FO_TR_Glossary
[6] Generic Structure Template
AUTOSAR_FO_TPS_GenericStructureTemplate
[7] AUTOSAR XML Schema Production Rules
AUTOSAR_FO_TPS_XMLSchemaProductionRules
[8] Specification of ECU Configuration
AUTOSAR_CP_TPS_ECUConfiguration
[9] Specification of ECU Configuration Parameters (XML)
AUTOSAR_CP_MOD_ECUConfigurationParameters
[10] Requirements on Standardization Template
AUTOSAR_FO_RS_StandardizationTemplate
[11] Layered Software Architecture
AUTOSAR_CP_EXP_LayeredSoftwareArchitecture
[12] Basic Software Module Description Template
AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate
[13] Software Component Template
AUTOSAR_CP_TPS_SoftwareComponentTemplate
[14] Specification of Memory Mapping
AUTOSAR_CP_SWS_MemoryMapping
The main focus of this requirements document is the format of the ECU Configuration
Description.
2 Related Documentation
2.3 Abbreviations
Abbreviation Meaning
BSW Basic Software
BSWMD Basic Software Module Description
ECUC ECU Configuration
SW-C Software Component
3 Requirements Tracing
The following table references the requirements specified in [10] and links to the fulfill-
ments of these.
Requirement Description Satisfied by
[RS_BRF_01024] AUTOSAR shall provide naming [RS_ECUC_00086]
rules for public symbols
[RS_BRF_01028] AUTOSAR shall provide naming [RS_ECUC_00086]
conventions for symbols in its
documentation
[RS_BRF_01120] AUTOSAR shall support re-flashing [RS_ECUC_00008] [RS_ECUC_00085]
of configured BSW data
[RS_BRF_01136] AUTOSAR shall support variants of [RS_ECUC_00078] [RS_ECUC_00079]
configured BSW data resolved after [RS_ECUC_00080] [RS_ECUC_00082]
system start-up [RS_ECUC_00083] [RS_ECUC_00084]
[SRS_BSW_00159] All modules of the AUTOSAR Basic [RS_ECUC_00049]
Software shall support a tool based
configuration
[SRS_BSW_00167] All AUTOSAR Basic Software [RS_ECUC_00050]
Modules shall provide configuration
rules and constraints to enable
plausibility checks
[SRS_BSW_00344] BSW Modules shall support [RS_ECUC_00048]
link-time configuration
[SRS_BSW_00345] BSW Modules shall support [RS_ECUC_00047]
pre-compile configuration
The ECU Configuration Template shall become the backbone for the integration
Description: of software on a particular ECU. Any necessary configuration information shall
be aggregated or referenced in this template.
Integration of software means basically the resolution of interdependencies
among particular parts of the software. The resolution process can only be
performed properly if all relevant information is accessible.
Rationale:
Note that this requirement does not imply that all relevant information is copied
into the template. References to elements in other templates may be included
to avoid redundant elements in the model.
The ECU Configuration Template will include references to SW Components
described using the SW component part of the meta model.
Use Case:
It will also allow to specify the sequencing of runnables within task, something
which is not specified by any other template.
Consequence: ECU Configuration tools (editors and generators) need to be
Dependencies: able to read parts of other templates as well (like System Template, SW
Component Template, ECU Resource Template).
Supporting –
Material:
c()
[RS_ECUC_00072] Support for referencing from dependent containers d
c()
c(SRS_BSW_00167)
[RS_ECUC_00055] Support standardization of mandatory and optional configu-
ration parameters d
Note that an implementation may still choose to fix the value for a mandatory
parameter (e.g. an object code delivery fixes the values of pre-compile
parameters). Anyhow, the value selected must then be stated in the ECU
Configuration Description [8].
The parameter ACTIVATE_PULLUP in the PORT Module is only needed if the
Use Case: hardware supports it. Thus an implementation of the PORT module may omit
the parameter if the target HW does not support pull ups.
Dependencies: –
Supporting –
Material:
c()
c()
[RS_ECUC_00043] Duplication free description d
c()
c()
[RS_ECUC_00046] Support definition of configuration class d
The ECU Configuration parameter definition shall support the definition of the
Description:
configuration class of configuration parameters.
The BSW SWS allows several configuration classes:
pre-compile time
link time
c()
There shall be only one configuration description mechanism for all different
Description: kinds of configuration classes. So regardless if "pre-compile-time" or "link-time"
or "post-build-time" configuration is described the description format shall be
the same.
The description of the configuration shall be independent from the BSW
implementations. Additional information might be needed if the parameter class
Rationale:
changes in the implementation, e.g. memory location for post-build-time
parameters.
If one BSW module is configured to be "pre-compile-time" configuration - and
Use Case: this module is exchanged against a "link-time" configuration one - the ECU
Configuration description shall not change due to this exchange.
Dependencies: –
Supporting –
Material:
c()
[RS_ECUC_00049] ECU Configuration description shall be tool process-able d
c(SRS_BSW_00159)
[RS_ECUC_00065] Development according to the AUTOSAR Generic Structure
Template document d
c()
The ECU Configuration Template schema shall be derived using the model
Description:
transformation described in the AUTOSAR XML Schema Production Rules.
The experience and tools already available for the AUTOSAR Modeling from
Rationale:
other templates shall be reused.
The template for the ECU Configuration is similar to other templates already
Use Case:
done within AUTOSAR.
Dependencies: –
Supporting AUTOSAR XML Schema Production Rules [7].
Material:
c()
[RS_ECUC_00018] Extension handling d
Description: The ECU Configuration must allow for later extensions to support the evolution
of the standard.
It may be possible, that extensions/additional aspects must be handled in the
ECU Configuration and ECU resources which are currently not part of the
Rationale:
standard. But at some point in time these extensions shall become part of the
standards next version.
If e.g. new type of ECU resources become available, it must be possible to
Use Case: easily incorporate this into the AUTOSAR architecture without changing the
standard at once, since changes to the standard may take some time.
[RS_ECUC_00002] is specifying vendor-specific extensions that will never be
Dependencies:
part of the standard.
Supporting –
Material:
c()
[RS_ECUC_00074] Support Sequential ECU Configuration d
c()
c()
[RS_ECUC_00078] Variable existence of container on value side d
The existence of a container and its substructure shall be variable in the ECU
Description:
Configuration Parameter Description.
Containers hold most of the structure of the configuration description. By
Rationale: enabling variability on container many use-cases can be supported.
Use Case: Variable existence of an OSTask.
Dependencies: –
Supporting –
Material:
c(RS_BRF_01136)
[RS_ECUC_00079] Variable existence of value d
c(RS_BRF_01136)
[RS_ECUC_00080] Variable value d
4
Use Case: Configuring multiple baud rates of a bus based on variation.
Dependencies: –
Supporting –
Material:
c(RS_BRF_01136)
[RS_ECUC_00082] Variable lower and upper multiplicity in ECU Configuration
Parameter definition d
Description: The definition of the lower and upper multiplicity in the ECU Configuration
Parameter definition shall be variable.
Through the lower and upper multiplicity the existence of elements in the ECU
Rationale: Configuration Parameter description is controlled. Making the bounds variable
allows for freedom in the definition.
Use Case: Make the decision whether parameters are mandatory or optional variant.
Dependencies: –
Supporting –
Material:
c(RS_BRF_01136)
[RS_ECUC_00083] Variable default value in ECU Configuration Parameter defini-
tion d
c(RS_BRF_01136)
[RS_ECUC_00084] Variable min and max ranges in ECU Configuration Parameter
definition d
The min and max ranges of ECU Configuration Parameters shall be variable in
Description:
the ECU Configuration Parameter definition.
Relationships between variation and the min/max values are quite often in the
Rationale: definition of the ECU Configuration Parameter definition.
The max value for the NvRamBlockId can be either 255 or 65535, depending
Use Case:
whether a 8- or 16-bit selection has been chosen.
Dependencies: –
5
4
Supporting –
Material:
c(RS_BRF_01136)
[RS_ECUC_00086] The TPS_ECUConfiguration shall provide naming conven-
tions for public symbols. d
c(RS_BRF_01024, RS_BRF_01028)
c(SRS_BSW_00345)
[RS_ECUC_00048] Link time configuration of BSW d
The configuration of parameters of BSW during link time shall be possible for
Description:
configuration parameters that are defined to be link time configurable.
When a BSW module is delivered as object code it can only be configured at
Rationale:
link time or post-build time.
Use Case: Support of link time configuration parameters.
5
4
Dependencies: –
Supporting AUTOSAR Glossary [5]
Material:
c(SRS_BSW_00344)
[RS_ECUC_00008] Post-build time configuration of BSW d
c(RS_BRF_01120)
[RS_ECUC_00085] Handling different configuration variants at post-build time d
It shall be possible to have variation points in the ECU configuration which are
Description:
bound at post-build time.
Rationale: This will allow the existence of several ECU configuration variants in one ECU.
The same ECU software can be used for multiple ECUs which share the same
Use Case: application (e.g. left and right door modules) and the correct configuration for
each one of them is chosen at runtime.
Dependencies: –
Supporting AUTOSAR Glossary [5]
Material:
c(RS_BRF_01120)
[RS_ECUC_00039] Support configuration of BSW d
4
• BSW SWS define a list of configuration parameters. These parameters need
to be reflected in the ECU Configuration template.
Use Case: • The OS SWS will identify configuration parameters from existing formats
(such as OIL) and place them in the SWS. In that case only the content of
OIL is used in the ECUC, not the actual format itself.
Dependencies: –
Supporting Related released specifications of BSW modules [11].
Material:
c()
[RS_ECUC_00015] Configuration of multiple instances of BSW modules d
c()
[RS_ECUC_00021] Select AUTOSAR SW Component and BSW Module imple-
mentation d
c()
Description: Parts of software (code, data) shall be map-able to specific memory areas.
Each software consists of several sections which are defined when
Rationale: developing/compiling the software. Those sections need to be placed in
different memory areas on the ECU.
• If data shall be post-build configurable it needs to be placed in non-volatile
memory. The location the data is placed is needed for tools to be able to
Use Case: change the data later on.
• Certain SW variables have to be placed in a NOINIT memory area which will
not be initialized during ECU start-up.
Software needs to publish the memory sections that have been used while
Dependencies: developing/compiling the software. This needs to be part of the BSWMD [12]
and the SWC-T [13].
Supporting Specification of Memory Mapping [14]
Material:
c()
[RS_ECUC_00040] Support configuration of RTE d
c()
[RS_ECUC_00076] Support the configuration of which AUTOSAR Services are
available on a specific ECU d
c()
c()
[RS_ECUC_00073] Support Service Configuration of AUTOSAR SW Components
d
c()
[RS_ECUC_00016] Execution order of runnable entities within one OS task d
c()
c()
The WP products will only identify the methods and mechanisms that may be
used to configure ECUs but will not identify any engineering trade-offs (e.g.
Description:
between performance and size) that must be considered by configuration
engineers.
The mechanisms are application independent so all potential impacts cannot
Rationale: be assessed. Application specific trade-offs must be considered by engineers
utilizing the mechanism for an application build.
The configuration parameter definition will only define valid ranges, but not
Use Case: provide algorithms for finding the best setting.
Dependencies: This should be part of the WP scope definition chapter of some deliverable.
Supporting –
Material:
c()
c()
BSW modules shall provide information on the memory needs for the module.
Description: This is also true when the memory need is dependent on the actual
configuration.
The amount of memory required typically depends on the configuration of the
Rationale: module and is finally determined at latest after configuration.
Post build data for COM stack varies in size, depending on the number of
Use Case: frames sent and received, code size (ROM) may vary for generated code. Data
structures in RAM and EEPROM may vary as well.
This is a requirement on the BSW Module Description, even though the actual
Dependencies:
value might depend on the configuration.
Supporting –
Material:
c()
[RS_ECUC_00036] Identify un-initialized resources. d
4
When unused (thus un-initialized) resources are identified a user may add
Use Case: appropriate drivers to the ECU which at least initialize these resources (e.g.
explicitly disable unused interrupts or I/O ports).
Dependencies: –
Supporting This would have to be checked by the tool-chain and/or process.
Material:
c()
[RS_ECUC_00056] Identify conflicting usage of micro controller registers d
ECU Configuration tool shall identify micro controller registers which are
Description: configured and/or accessed by more than one BSW module in an inconsistent
way.
BSW modules (AUTOSAR drivers, complex drivers etc) may directly access
micro controller registers. When BSW modules, possibly even from different
vendors, are integrated into a single ECU then these modules may try to
Rationale:
configure the same micro controller registers differently. Such conflicts must be
identified.
(Note: This is a requirement on the tool - not on the ECUC template)
Dependencies: –
4 LSB of a register are used by the GPT Driver, the 4 MSB of the same register
are used by the ICU. If both modules write the entire register (8 bit) then they
Use Case: overwrite each other’s configuration setting. Once a conflict is identified,
different BSW module implementations or different BSW configuration may be
used to resolve the problem.
Supporting [RS_BSWMD_00009] [12]
Material:
c()
[RS_ECUC_00062] Configuration option to initialize unused memory d
c()
5 Change History
Id Heading
[RS_ECUC_00078] Variable existence of container
[RS_ECUC_00079] Variable existence of value
[RS_ECUC_00080] Variable value
[RS_ECUC_00082] Variable lower and upper multiplicity in ECU Configuration Parameter defini-
tion
[RS_ECUC_00083] Variable default value in ECU Configuration Parameter definition
[RS_ECUC_00084] Variable min and max ranges in ECU Configuration Parameter definition
Id Heading
[RS_ECUC_00046] Support definition of configuration class
[RS_ECUC_00065] Development according to the AUTOSAR Generic Structure Template docu-
ment
[RS_ECUC_00066] Transformation of ECUC model according to the AUTOSAR Model Persis-
tence Rules for XML
[RS_ECUC_00072] Support for referencing from dependent containers
Id Heading
[ECUC_0075] Support exactly one to be configured micro-controller per ECU
none
Id Heading
[RS_ECUC_00083] Excluded "enumeration parameter definition"
none
Id Heading
[RS_ECUC_00085] Handling different configuration variants at post-build time
[RS_ECUC_00086] The TPS_ECUConfiguration shall provide naming conventions for public sym-
bols.
Id Heading
[RS_ECUC_00008] Post-build time configuration of BSW
[RS_ECUC_00078] Variable existence of container on value side
[RS_ECUC_00079] Variable existence of value
[RS_ECUC_00080] Variable value
[RS_ECUC_00082] Variable lower and upper multiplicity in ECU Configuration Parameter defini-
tion
[RS_ECUC_00083] Variable default value in ECU Configuration Parameter definition
[RS_ECUC_00084] Variable min and max ranges in ECU Configuration Parameter definition
none
none
Id Heading
[RS_ECUC_00066] Transformation of ECUC model according to the AUTOSAR XML Schema
Production Rules
none
none
none
none
none
none
none
none
none
none
none
none
none
none
none
none
none
none
none
none
none
none