文档库 最新最全的文档下载
当前位置:文档库 › AUTOSAR_SRS_BSWGeneral

AUTOSAR_SRS_BSWGeneral

Document Title General Requirements on

Basic Software Modules

AUTOSAR

Document Owner

AUTOSAR

Document Responsibility

043

Document Identification No

Standard

Document Classification

3.1.0

Document Version

Final

Document Status

4.0

Part of Release

2

Revision

Document Change History

Date Version Changed by Change Description

22.10.2010 3.1.0 AUTOSAR

Administration ?Changed Requirement [BSW00416] (sequence of initialisation): added check

of uninitialized module calls.

?Changed Requirement [BSW004] (version check): reworded to specify pass criteria

of checks.

?Changed Requirement [BSW00346] (Basic set of module files): added Link-time and Post-Build configuration header files.

?Changed Requirement [BSW00408] (Configuration parameter naming

convention): requirement relaxed.

?Changed Requirement [BSW00440] (Function Prototype for Callback

functions of AUTOSAR): modified

callback call mechanism through RTE.

?Changed Requirement [BSW00414] (Parameter if init function): added check

on coherence of configuration type (pre-

compile, link time, post-build) and pointer passed to API.

?Added Requirement [BSW00462]

(Requirement Id for Standardized Autosar Interface): AUTOSAR Standard

Interfaces description has now a

Requirement ID and is binding.

Document Change History Date Version Changed by Change Description

02.12.2009 3.0.0 AUTOSAR

Administration ?Added New Requirements: [BSW00443], [BSW00444], [BSW00445], [BSW00446], [BSW00442], [BSW00448], [BSW00447], [BSW00450], [BSW00453], [BSW00455], [BSW00456], [BSW00457, [BSW00449] ?Removed Requirements :

o[BSW00434] The Schedule Module provides an API for exclusive areas.

o[BSW00431] The BSW Scheduler module implements task bodies. These

requirements are available in SRS

RTE RTE00222, RTE00225

respectively.

?Changed requirements: [BSW00416], [BSW00407], BSW00379], [BSW00435],

[BSW00305], [BSW00429], [BSW00318], [BSW004], [BSW00402], [BSW00373],

[BSW00406], [BSW00414], [BSW00347], [BSW00343], [BSW003], [BSW00347]

?Legal disclaimer revised

23.06.2008 2.2.1 AUTOSAR

Administration

?Legal disclaimer revised

10.12.2007 2.2.0 AUTOSAR

Administration ?[BSW00439] Declaration of interrupt handlers and ISRs

?[BSW00440] Function prototype for callback functions of AUTOSAR Services ? [BSW00441] Enumeration literals and define naming convention

?Changes done for Interrupt Handling, Configuration Parameter Naming

Convention and AUTOSAR Services

?Document meta information extended

?Small layout adaptations made

26.01.2007 2.1.0 AUTOSAR

Administration ?Interface for BSW Modules to DEM and Debouncing for DEM

?Changes in Configuration Requirements ?Module Headerfile Structure

?Naming separation of different instances of BSW drivers

?Legal disclaimer revised

?“Advice for users” revised

?“Revision Information” added

Document Change History Date Version Changed by Change Description

Second release

23.05.2006 2.0.0 AUTOSAR

Administration

23.06.2005 1.0.0 AUTOSAR

Initial release

Administration

Disclaimer

This specification 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 specification.

The material contained in this specification is protected by copyright and other types of Intellectual Property Rights. The commercial exploitation of the material contained in this specification requires a license to such Intellectual Property Rights.

This specification 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 specification may be utilized or reproduced, in any form or by any means, without permission in writing from the publisher.

The AUTOSAR specifications have been developed for automotive applications only. They have neither been developed, nor tested for non-automotive applications.

The word AUTOSAR and the AUTOSAR logo are registered trademarks.

Advice for users

AUTOSAR specifications may contain exemplary items (exemplary reference models, "use cases", and/or references to exemplary technical solutions, devices, processes or software).

Any such exemplary items are contained in the specifications for illustration purposes only, and they themselves are not part of the AUTOSAR Standard. Neither their presence in such specifications, nor any later documentation of AUTOSAR conformance of products actually implementing such exemplary items, imply that intellectual property rights covering such exemplary items are licensed under the same rules as applicable to the AUTOSAR Standard.

Table of Contents

1Scope of this document (10)

2How to read this document (11)

2.1Conventions used (11)

2.2Requirements structure (12)

3Acronym and abbrevations (13)

4General Requirements on Basic Software (14)

4.1Functional Requirements (14)

4.1.1Configuration (14)

4.1.1.1[BSW00344] Reference to link--time configuration (14)

4.1.1.2[BSW00404] Reference to post build time configuration (14)

4.1.1.3[BSW00405] Reference to multiple configuration sets (15)

4.1.1.4[BSW00345] Pre--compile--time configuration (15)

4.1.1.5[BSW159] Tool--based configuration (16)

4.1.1.6[BSW167] Static configuration checking (16)

4.1.1.7[BSW171] Configurability of optional functionality (17)

4.1.1.8[BSW170] Data for reconfiguration of AUTOSAR SW--Components

17

4.1.1.9[BSW00380] Separate C--Files for configuration parameters (18)

4.1.1.10[BSW00419] Separate C--Files for pre--compile time configuration

parameters (18)

4.1.1.11[BSW00381] Separate configuration header file for pre--compile

time parameters (19)

4.1.1.12[BSW00412] Separate H--File for configuration parameters (19)

4.1.1.13[BSW00383] List dependencies of configuration files (19)

4.1.1.14[BSW00384] List dependencies to other modules (20)

4.1.1.15[BSW00387] Specify the configuration class of callback function20

4.1.1.16[BSW00388] Introduce containers (20)

4.1.1.17[BSW00389] Containers shall have names (21)

4.1.1.18[BSW00390] Parameter content shall be unique within the module

21

4.1.1.19[BSW00391] Parameter shall have unique names (21)

4.1.1.20[BSW00392] Parameters shall have a type (22)

4.1.1.21[BSW00393] Parameters shall have a range (22)

4.1.1.22[BSW00394] Specify the scope of the parameters (23)

4.1.1.23[BSW00395] List the required parameters (per parameter) (23)

4.1.1.24[BSW00396] Configuration classes (23)

4.1.1.25[BSW00397] Pre--compile--time parameters (24)

4.1.1.26[BSW00398] Link--time parameters (24)

4.1.1.27[BSW00399] Loadable Post--build time parameters (24)

4.1.1.28[BSW00400] Selectable Post--build time parameters (25)

4.1.1.29[BSW00438] Post Build Configuration Data Structure (25)

4.1.1.30[BSW00402] Published information (26)

4.1.2Wake--Up (26)

4.1.2.1[BSW00375] Notification of wake--up reason (26)

4.1.3Initialization (27)

4.1.3.1[BSW101] Initialization interface (27)

4.1.3.2[BSW00416] Sequence of Initialization (27)

4.1.3.3[BSW00406] Check module initialization (28)

4.1.3.4[BSW00437] NoInit--Area in RAM (28)

4.1.4Normal Operation (29)

4.1.4.1[BSW168] Diagnostic Interface of SW components (29)

4.1.4.2[BSW00407] Function to read out published parameters (29)

4.1.4.3[BSW00423] Usage of SW--C template to describe BSW modules

with AUTOSAR Interfaces (30)

4.1.4.4[BSW00424] BSW main processing function task allocation (30)

4.1.4.5[BSW00425] Trigger conditions for schedulable objects (31)

4.1.4.6[BSW00426] Exclusive areas in BSW modules (31)

4.1.4.7[BSW00427] ISR description for BSW modules (32)

4.1.4.8[BSW00428] Execution order dependencies of main processing

functions 32

4.1.4.9[BSW00429] Restricted BSW OS functionality access (32)

4.1.4.10[BSW00432] Modules should have separate main processing

functions for read/receive and write/transmit data path (34)

4.1.4.11[BSW00433] Calling of main processing functions (34)

4.1.4.12[BSW00450] Main Function Processing for Un-Initialized Modules

34

4.1.4.13[BSW00442] Debugging Support in Modules (35)

4.1.4.14[BSW00461] Generic Interfaces (35)

4.1.5Shutdown Operation (36)

4.1.5.1[BSW00336] Shutdown interface (36)

4.1.6Fault Operation and Error Detection (36)

4.1.6.1[BSW00337] Classification of errors (36)

4.1.6.2[BSW00338] Detection and Reporting of development errors (37)

4.1.6.3[BSW00369] Do not return development error codes via API (37)

4.1.6.4[BSW00339] Reporting of production relevant error status (38)

4.1.6.5[BSW00422] Pre--de--bouncing of production relevant error status

39

4.1.6.6[BSW00417] Reporting of Error Events by Non--Basic Software.39

4.1.6.7[BSW00323] API parameter checking (40)

4.1.6.8[BSW004] Version check (40)

4.1.6.9[BSW00409] Header files for production code error IDs (41)

4.1.6.10[BSW00385] List possible error notifications (42)

4.1.6.11[BSW00386] Configuration for detecting an error (42)

4.1.7[BSW00455] Implementation Conformance Class 1 and 2 (ICC1 and ICC2) Guidelines (42)

4.2Non--functional Requirements (44)

4.2.1Software Architecture Requirements (44)

4.2.1.1[BSW161] Microcontroller abstraction (44)

4.2.1.2[BSW162] ECU layout abstraction (44)

4.2.1.3[BSW005] No hard coded horizontal interfaces within MCAL (44)

4.2.1.4[BSW00415] User dependent include files (45)

4.2.2Software Integration Requirements (45)

4.2.2.1[BSW164] Implementation of interrupt service routines (45)

4.2.2.2[BSW00325] Runtime of interrupt service routines (46)

4.2.2.3[BSW00326] Transition from ISRs to OS tasks (46)

4.2.2.4[BSW00342] Usage of source code and object code (47)

4.2.2.5[BSW00343] Specification and configuration of time (47)

4.2.2.6[BSW160] Human--readable configuration data (47)

4.2.2.7[BSW00453] – Harmonization of BSW Modules (48)

4.2.2.8[BSW00456] - Header file for Harmonizing BSW Modules (48)

4.2.2.9[BSW00457] - Callback functions of Application software components (49)

4.2.3Software Module Design Requirements (49)

4.2.3.1Software quality (49)

4.2.3.1.1[BSW007] HIS MISRA C (49)

4.2.3.2Naming conventions (50)

4.2.3.2.1[BSW00300] Module naming convention (50)

4.2.3.2.2[BSW00413] Accessing instances of BSW modules (50)

4.2.3.2.3[BSW00347] Naming separation of different instances of BSW

drivers 51

4.2.3.2.4[BSW00441] Enumeration literals and #define naming

convention 52

4.2.3.2.5[BSW00305] Data types naming convention (52)

4.2.3.2.6[BSW00307] Global variables naming convention (53)

4.2.3.2.7[BSW00310] API naming convention (53)

4.2.3.2.8[BSW00373] Main processing function naming convention (54)

4.2.3.2.9[BSW00327] Error values naming convention (55)

4.2.3.2.10[BSW00335] Status values naming convention (55)

4.2.3.2.11[BSW00350] Development error detection keyword (56)

4.2.3.2.12[BSW00408] Configuration parameter naming convention (56)

4.2.3.2.13[BSW00410] Compiler switches shall have defined values (57)

4.2.3.2.14[BSW00411] Get version info keyword (57)

4.2.3.3Module file structure (58)

4.2.3.3.1[BSW00346] Basic set of module files (58)

4.2.3.3.2[BSW158] Separation of configuration from implementation (59)

4.2.3.3.3[BSW00314] Separation of interrupt frames and service routines

59

4.2.3.3.4[BSW00370] Separation of callback interface from API (60)

4.2.3.3.5[BSW00435] Module Header File Structure for the Basic

Software Scheduler (60)

4.2.3.3.6[BSW00436] Module Header File Structure for the Basic

Software Memory Mapping (60)

4.2.3.3.7[BSW00447] Standardizing Include file structure of BSW

Modules Implementing Autosar Service (61)

4.2.3.4Standard header files (62)

4.2.3.4.1[BSW00348] Standard type header (62)

4.2.3.4.2[BSW00353] Platform specific type header (62)

4.2.3.4.3[BSW00361] Compiler specific language extension header (63)

4.2.3.5Module Design (64)

4.2.3.5.1[BSW00301] Limit imported information (64)

4.2.3.5.2[BSW00302] Limit exported information (64)

4.2.3.5.3[BSW00328] Avoid duplication of code (65)

4.2.3.5.4[BSW00312] Shared code shall be reentrant (65)

4.2.3.5.5[BSW006] Platform independency (65)

4.2.3.5.6[BSW00439] Declaration of interrupt handlers and ISRs (66)

4.2.3.

5.7[BSW00448] Module SWS shall not contain requirements from

Other Modules (66)

4.2.3.

5.8[BSW00449] BSW Service APIs used by Autosar Application

Software shall return a Std_ReturnType (67)

4.2.3.6Types and keywords (67)

4.2.3.6.1[BSW00357] Standard API return type [ (67)

4.2.3.6.2[BSW00377] Module specific API return types (68)

4.2.3.6.3[BSW00304] AUTOSAR integer data types (69)

4.2.3.6.4[BSW00355] Do not redefine AUTOSAR integer data types (70)

4.2.3.6.5[BSW00378] AUTOSAR boolean type (71)

4.2.3.6.6[BSW00306] Avoid direct use of compiler and platform specific

keywords [ 72

4.2.3.7Global data (72)

4.2.3.7.1[BSW00308] Definition of global data (72)

4.2.3.7.2[BSW00309] Global data with read--only constraint (72)

4.2.3.8Interface and API (73)

4.2.3.8.1[BSW00371] Do not pass function pointers via API (73)

4.2.3.8.2[BSW00358] Return type of init() functions (73)

4.2.3.8.3[BSW00414] Parameter of init function (74)

4.2.3.8.4[BSW00376] Return type and parameters of main processing

functions 74

4.2.3.8.5[BSW00359] Return type of callback functions (75)

4.2.3.8.6[BSW00360] Parameters of callback functions (75)

4.2.3.8.7[BSW00440] Function prototype for callback functions of

AUTOSAR Services (75)

4.2.3.8.8[BSW00329] Avoidance of generic interfaces (76)

4.2.3.8.9[BSW00330] Usage of macros / inline functions instead of

functions 76

4.2.3.8.10[BSW00331] Separation of error and status values (77)

4.2.3.8.11[BSW00462] Requirement Id for Standardized Autosar Interface

77

4.2.4Safety Related Requirements (78)

4.2.4.1[BSW00443] Enabling / disabling defensive behavior of BSW (78)

4.2.4.2[BSW00444] Error reporting and logging for defensive behavior of 78 BSW (78)

4.2.4.3[BSW00445] Protection against untimely call of BSW initialization 79

4.2.4.4[BSW00446] Protection against untimely call of BSW de-initialization (79)

4.2.5Software Documentation Requirements (79)

4.2.5.1[BSW009] Module User Documentation (80)

4.2.5.2[BSW00401] Documentation of multiple instances of configuration parameters (80)

4.2.

5.3[BSW172] Compatibility and documentation of scheduling strategy 81

4.2.5.4[BSW010] Memory resource documentation (81)

4.2.5.5[BSW00333] Documentation of callback function context (82)

4.2.5.6[BSW00374] Module vendor identification (82)

4.2.5.7[BSW00379] Module identification (83)

4.2.5.8[BSW003] Version identification (83)

4.2.5.9[BSW00318] Format of module version numbers (83)

4.2.5.10[BSW00321] Enumeration of module version numbers (84)

4.2.5.11[BSW00341] Microcontroller compatibility documentation (85)

4.2.5.12[BSW00334] Provision of XML file (85)

5References (87)

5.1Deliverables of AUTOSAR (87)

5.2Related standards and norms (87)

5.2.1OSEK (87)

5.2.2HIS (87)

1 Scope of this document

The goal of AUTOSAR WP Architecture and this document is to define a common set of basic requirements that apply to all SW modules of the AUTOSAR Basic Software. These requirements shall be adopted and refined by the work packages responsible for the specification of Basic SW modules .

The functional requirements defined in this document shall be referenced in each Software Specification (SWS) document of the AUTOSAR Basic Software. 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.

2 How to read this document

Each requirement has its unique identifier starting with the prefix “BSW” (for “Basic Software”). For any review annotations, remarks or questions, please refer to this unique ID rather than chapter or page numbers!

2.1 Conventions used

In requirements, the following specific semantics shall be used (based on the Internet Engineering Task Force IETF).

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.)

2.2 Requirements structure

Each module specific chapter contains a short functional description of the Basic Software Module. Requirements of the same kind within each chapter are grouped under the following headlines (where applicable):

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,...)

- ...

Mapping to AUTOSAR releases

For each requirement defined in the document “General Requirements on Basic Software Modules”, there shall be a reference to the AUTOSAR release(s) for which the requirement is valid. This is achieved by the row “AUTOSAR release” in the requirement description table.

This Requirements Specification contains general requirements that are valid for all SW modules that are part of the AUTOSAR Basic Software.

The obligatory part of the requirements is stated in the description of each requirement.

3 Acronym and abbrevations

Acronym: Description:

Interrupt frame An interrupt frame is the code which is generated by the compiler or the assembler code for prefix and postfix of interrupt routines. This code is Microcontroller specific ISR Interrupt Service Routine. Also used as a macro to declare in C a cat2 interrupt service routine.

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 General Requirements on Basic Software

The requirements on Basic Software cover the following domains:

? 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: ?Sunroof and power window ECU

?Diesel engine ECU

? ESP ECU

?BMW, DC and VW standard software packages (‘Standard Core’, ‘Standard Software Platform‘, ‘Standard Software Core’) including OSEK OS, communication modules, bootloader, basic diagnostic functions for the domains listed above

?Infotainment control ECU

4.1 Functional Requirements

4.1.1 Configuration

4.1.1.1 [BSW00344] Reference to link--time configuration

BMW

Initiator:

07.12.2006

Date:

1.0 and higher

AUTOSAR Release:

Reference to link time configuration

Short Description:

Changed

Type:

High

Importance:

All modules of the AUTOSAR Basic Software that operate on link--time Description:

configurable data at runtime shall use a read only reference (pointer) to an

external configuration instance.

Allow configurable functionality of modules that are deployed as object code. Rationale:

Usually those modules are drivers.

--

Use Case:

[BSW00342] Usage of source code and object code

Dependencies:

[ECUC0048] Link--time configuration (see [ECU_CONF_SRS])

--

Conflicts:

--

Supporting Material:

4.1.1.2 [BSW00404] Reference to post build time configuration

BMW

Initiator:

07.12.2006

Date:

AUTOSAR Release: 1.0 and higher

Reference to post build time configuration

Short Description:

Changed

Type:

High

Importance:

Modules of the AUTOSAR Basic Software that operate on one post build Description:

time configurable data entity shall use a read only reference (pointer) to an

external configuration instance. (violation of this requirement must be

reasoned)

As long as there is only one set of configuration data (i.e. we have no Rationale:

multiple configuration sets) the references can be resolved as constant

pointers. The indirections shall be kept as simple as possible

type declaration of the Config Type

Use Case:

typedef struct ComM_ConfigType_Tag {

...

} ComM_ConfigType; (in ComM_Cfg.h)

as a forward declaration use:

typedef struct ComM_ConfigType_Tag ComM_ConfigType;

extern void ComM(ComM_ConfigType * ComMConfigPtr); (in

ComM.h)

[BSW00342] Usage of source code and object code

Dependencies:

[ECUC0048] Link--time configuration (see [ECU_CONF_SRS])

--

Conflicts:

--

Supporting Material:

4.1.1.3 [BSW00405] Reference to multiple configuration sets

BMW / CAS

Initiator:

26.10.2006

Date:

2.0 and higher

AUTOSAR Release:

Reference to multiple configuration sets

Short Description:

Changed

Type:

High

Importance:

Modules of the AUTOSAR Basic Software that operate on more than one Description:

post build time configurable data entity shall use a reference (pointer) to an

external configuration instance.

Application of the same software to different cars.

Rationale:

--

Use Case:

[BSW00342] Usage of source code and object code

Dependencies:

[ECUC0048] Link--time configuration (see [ECU_CONF_SRS])

--

Conflicts:

--

Supporting Material:

4.1.1.4 [BSW00345] Pre--compile--time configuration

BMW

Initiator:

23.07.2004

Date:

1.0 and higher

AUTOSAR Release:

Pre--compile--time configuration

Short Description:

Changed to add “*.c” file

Type:

High

Importance:

Description: All modules of the AUTOSAR Basic Software, operating on Pre--compile--

time configuration data (not to be modified after compile time), shall group

and export the configuration data to configuration files.

Module specific configuration header file naming convention:

_Cfg.h and possibly

_Cfg.c

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.

In Tp_Cfg.h:

Use Case:

#define TP_USE_NORMAL_ADDRESSING KTPOFF

#define TP_USE_NORMAL_FIXED_ADDRESSING KTPOFF

#define TP_USE_EXTENDED_ADDRESSING KTPON

...

in Tp.c:

#include "Tp_Cfg.h"

#if (TP_USE_NORMAL_ADDRESSING == KTPOFF)

… do something

#endif

Dependencies: [BSW158] Separation of configuration from implementation

[ECUC0047] Pre--compile--time configuration (see [ECU_CONF_SRS])

--

Conflicts:

--

Supporting Material:

4.1.1.5 [BSW159] Tool--based configuration

BMW

Initiator:

10.02.2004

Date:

1.0 and higher

AUTOSAR Release:

Tool--based configuration.

Short Description:

New

Type:

High

Importance:

All modules of the AUTOSAR Basic Software shall support a tool based Description:

configuration.

Integration into AUTOSAR methodology

Rationale:

The NVRAM manager can be automatically configured depending on the NV Use Case:

parameters and their corresponding attributes of the software components.

--

Dependencies:

--

Conflicts:

--

Supporting Material:

4.1.1.6 [BSW167] Static configuration checking

BMW

Initiator:

24.11.2005

Date:

1.0 and higher

AUTOSAR Release:

Static configuration checking

Short Description:

Changed

Type:

High

Importance:

Description: All AUTOSAR Basic Software Modules shall provide configuration rules and

constraints to enable plausibility checks of configuration during ECU

configuration time where possible.

Runtime efficiency:

Rationale:

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: --

Requirements for configuration toolchain.

Dependencies:

[BSW00334] Provision of XML file

Conflicts: --

--

Supporting Material:

4.1.1.7 [BSW171] Configurability of optional functionality

BOSCH

Initiator:

29.02.2004

Date:

1.0 and higher

AUTOSAR Release:

Configure optional functionality in a way to minimize resource consumption Short Description:

Changed (18.03.2005)

Type:

High

Importance:

Optional functionality of a Basic--SW component that is not required in the Description:

ECU shall be configurable at pre--compile--time (on/off).

Optional functionalities of Basic SW components which are disabled by static Rationale:

configuration shall not consume resources (RAM, ROM, runtime).

Implementation example: in C language, preprocessing directives can be

used.

Ensure optimal resource consumption. There are many requirements

marked with high importance but not all are used in each ECU thus resource

overhead must be avoided.

Use Case: 1. The development error detection is a statically configurable optional

function that can be enabled and disabled.

2. The EEPROM write cycle reduction is a statically configurable optional

function that can be enabled and disabled.

Dependencies: --

--

Conflicts:

--

Supporting Material:

4.1.1.8 [BSW170] Data for reconfiguration of AUTOSAR SW--Components

BOSCH

Initiator:

24.11.2005

Date:

1.0 and higher

AUTOSAR Release:

The AUTOSAR SW Components shall provide information about their

Short Description:

dependency from faults, signal qualities, driver demands, ...

Changed

Type:

High

Importance:

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.

Resolve the interdependencies between AUTOSAR SW--Components. Rationale:

A fault of the steering angle sensor will lead to reduced function of the

Use Case:

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: --

--

Conflicts:

--

Supporting Material:

4.1.1.9 [BSW00380] Separate C--Files for configuration parameters

WP Architecture

Initiator:

30.06.2005

Date:

2.0 and higher

AUTOSAR Release:

Separate C--Files for configuration parameters

Short Description:

New

Type:

High

Importance:

Configuration parameters being stored in memory shall be placed into Description:

separate c--files (effected parameters are those from link--time configuration

as well as those from post--build time configuration).

Enable the use of different object files.

Rationale:

--

Use Case:

[BSW00381] Separate configuration header file for pre--compile time Dependencies:

parameters

[BSW00346] Basic set of module files

Conflicts: --

Layered Software Architecture ([DOC_LAYERED_ARCH])

Supporting Material:

4.1.1.10 [BSW00419] Separate C--Files for pre--compile time configuration

parameters

WP Architecture

Initiator:

07.12.2006

Date:

2.0 and higher

AUTOSAR Release:

Separate C--Files for pre--compile time configuration parameters

Short Description:

Changed

Type:

Medium

Importance:

Description: If a pre--compile time configuration parameter is implemented as “const“ it

should be placed into a separate c--file.

Enabling of object code integration.

Rationale:

Separation of configuration from implementation.

Use Case: --

[BSW00380] Separate C--Files for configuration parameters Dependencies:

--

Conflicts:

Layered Software Architecture ([DOC_LAYERED_ARCH])

Supporting Material:

4.1.1.11 [BSW00381] Separate configuration header file for pre--compile time

parameters

WP Architecture

Initiator:

21.10.2005

Date:

2.0 and higher

AUTOSAR Release:

Separate configuration header file for pre--compile time parameters

Short Description:

Changed (Telcon)

Type:

High

Importance:

The pre--compile time parameters shall be placed into a separate Description:

configuration header file.

Keep the configuration data separate.

Rationale:

--

Use Case:

[BSW00345] Pre--compile--time configuration

Dependencies:

--

Conflicts:

--

Supporting Material:

4.1.1.12 [BSW00412] Separate H--File for configuration parameters

WP Architecture

Initiator:

26.10.2006

Date:

2.0 and higher

AUTOSAR Release:

Separate H--File for configuration parameters

Short Description:

New

Type:

High

Importance:

References to c--configuration parameters (link time and post--build time) Description:

shall be placed into a separate h--file. The h--file shall be the same as pre--

compile time parameters.

Put the references to c--configuration parameters in the same header file as Rationale:

pre--compile time parameters to enable access to the configuration data.

--

Use Case:

[BSW00381] Separate configuration header file for pre--compile time Dependencies:

parameters

[BSW00345] Pre--compile--time configuration

[BSW00346] Basic set of module files

Conflicts: --

--

Supporting Material:

4.1.1.13 [BSW00383] List dependencies of configuration files

WP Architecture

Initiator:

08.12.2005

Date:

2.0 and higher

AUTOSAR Release:

List dependencies of configuration files

Short Description:

Changed

Type:

High

Importance:

The Basic Software Module specifications shall specify which other Description:

configuration files from other modules they use at least in the description.

Resolve compatibility issues

Rationale:

--

Use Case:

[BSW00384] List dependencies to other modules

Dependencies:

Conflicts: --

--

Supporting Material:

4.1.1.14 [BSW00384] List dependencies to other modules

WP Architecture

Initiator:

08.12.2005

Date:

2.0 and higher

AUTOSAR Release:

List dependencies to other modules

Short Description:

Changed

Type:

High

Importance:

The Basic Software Module specifications shall specify at least in the Description:

description which other modules (in which versions) they require.

Resolve compatibility issues

Rationale:

--

Use Case:

[BSW00383] List dependencies of configuration files

Dependencies:

--

Conflicts:

--

Supporting Material:

4.1.1.15 [BSW00387] Specify the configuration class of callback function

WP Architecture

Initiator:

08.12.2005

Date:

2.0 and higher

AUTOSAR Release:

Specify the configuration class of callback function

Short Description:

Changed

Type:

High

Importance:

The Basic Software Module specifications shall specify how the callback Description:

function is to be implemented. (Pre--compile macro, pointer at link time,

array of pointers at post--build time and pointer at post--build time)

v

Rationale:

If a pre--compile time callback function (macro) shall be changed to a post Use Case:

build time multiple configuration--set callback function (pointer to a function).

The implementation will change significantly.

--

Dependencies:

--

Conflicts:

See Glossary ([GLOSSARY]) and ECU Configuration (WP ECU Supporting Material:

Configuration) ([ECU_CONF_SRS])

4.1.1.16 [BSW00388] Introduce containers

WP Architecture

Initiator:

30.06.2005

Date:

2.0 and higher

AUTOSAR Release:

Introduce containers

Short Description:

New

Type:

High

Importance:

Containers are used to group configuration parameters that are defined for Description:

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

相关文档