Document Title: Requirements On Memory Hardware Abstraction Layer

Requirements on Memory Hardware
Abstraction Layer
V1.0.5
R4.0 Rev 1
Document Title Requirements on Memory

Hardware Abstraction Layer
Document Owner AUTOSAR
Document Responsibility AUTOSAR
Document Identification No 116
Document Classification Auxiliary
Document Version 1.0.5

Document Status Final
Part of Release 4.0
Revision 1
Document Change History

Date Version Changed by Change Description
30.11.2009 1.0.5 AUTOSAR Legal disclaimer revised
Administration
Administration
31.10.2007 1.0.3 AUTOSAR  Document meta information extended
Administration  Small layout adaptations made
24.01.2007 1.0.2 AUTOSAR  “Advice for users” revised
Administration  “Revision Information” added
Administration
21.03.2006 1.0.0 AUTOSAR Initial release
Administration
1 of 28 Document ID 116: AUTOSAR_SRS_MemoryHWAbstractionLayer

- AUTOSAR confidential -
Abstraction Layer
V1.0.5
R4.0 Rev 1
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.

Abstraction Layer
V1.0.5
R4.0 Rev 1
Table of Content
1 Scope of this Document ...................................................................................... 5
2 How to read this document.................................................................................. 7

2.1 Conventions used......................................................................................... 7
2.2 Requirements structure ................................................................................ 8
3 Acronyms and abbreviations ............................................................................... 9
4 Requirements on Memory Hardware Abstraction Layer .................................... 10

4.1 Functional Overview................................................................................... 10
4.1.1 EEPROM Abstraction Layer................................................................ 10
4.1.2 Flash EEPROM Emulation .................................................................. 10
4.1.3 Memory Abstraction Interface ............................................................. 10
4.2 Memory Abstraction Modules ..................................................................... 11
4.2.1 Functional Requirements .................................................................... 11
4.2.1.1 Configuration................................................................................ 11
4.2.1.1.1 BSW14001 Configuration of address alignment ....................... 11
4.2.1.1.2 BSW14002 Configuration of number of required write cycles... 11
4.2.1.1.3 BSW14003 Configuration of maximum blocking time ............... 12
4.2.1.1.4 BSW14004 Configuration of “immediate” data blocks .............. 12
4.2.1.1.5 BSW14026 Don’t use certain block numbers............................ 12
4.2.1.1.6 BSW14027 Publish overhead for internal management data per
block .................................................................................................. 13
4.2.1.1.7 BSW14033 Publish overhead for internal management data per
page .................................................................................................. 13
4.2.1.2 Initialization .................................................................................. 14
4.2.1.3 Normal Operation......................................................................... 15
4.2.1.3.1 BSW14005 Virtual linear address space and segmentation ..... 15
4.2.1.3.2 BSW14006 Alignment of block erase / write addresses ........... 16
4.2.1.3.3 BSW14007 Alignment of block read address and read length.. 17
4.2.1.3.4 BSW14008 Checking block read addresses............................. 17
4.2.1.3.5 BSW14009 Conversion of logical to memory addresses .......... 17
4.2.1.3.6 BSW14010 Block-wise write service......................................... 18
4.2.1.3.7 BSW14029 Block-wise read service ......................................... 18
4.2.1.3.8 BSW14031 Service to cancel an ongoing asynchronous
operation .................................................................................................. 18
4.2.1.3.9 BSW14028 Service to invalidate a memory block .................... 19
4.2.1.3.10 BSW14012 Spreading of write access.................................... 19
4.2.1.3.11 BSW14013 Writing of “immediate” data must not be delayed. 20
4.2.1.3.12 BSW14032 Block-wise erase service for immediate data....... 20
4.2.1.4 Shutdown Operation .................................................................... 21
4.2.1.5 Fault Operation ............................................................................ 21
4.2.1.5.1 BSW14014 Detection of data inconsistencies .......................... 21
4.2.1.5.2 BSW14015 Reporting of data inconsistencies .......................... 21
4.2.1.5.3 BSW14016 Don’t return inconsistent data to the caller............. 22
4.2.2 Non-Functional Requirements (Qualities) ........................................... 22
Abstraction Layer
V1.0.5
R4.0 Rev 1
4.2.2.1 BSW14017 Scope of EEPROM Abstraction Layer ...................... 22
4.2.2.2 BSW14018 Scope of Flash EEPROM Emulation......................... 23
4.3 Memory Abstraction Interface .................................................................... 24
4.3.1 Functional Requirements .................................................................... 24
4.3.1.1 General ........................................................................................ 24
4.3.1.1.1 BSW14019 Provide uniform access to underlying memory
abstraction modules ................................................................................... 24
4.3.1.1.2 BSW14020 Selection of underlying memory abstraction modules
.................................................................................................. 24
4.3.1.2 Configuration................................................................................ 25
4.3.1.2.1 BSW14021 Number of underlying memory abstraction modules..
.................................................................................................. 25
4.3.1.3 Normal Operation......................................................................... 25
4.3.1.3.1 BSW14022 Preserving of functionality...................................... 25
4.3.1.4 Fault Operation ............................................................................ 25
4.3.1.4.1 BSW14023 Parameter checking............................................... 25
4.3.2 Non-Functional Requirements (Qualities) ........................................... 26
4.3.2.1 Timing Requirements ................................................................... 26
4.3.2.1.1 BSW14024 Preserving of timing behavior ................................ 26
4.3.2.2 Resource Usage .......................................................................... 26
4.3.2.2.1 BSW14025 Efficient implementation......................................... 26
4.4 Onboard Device Abstraction ...................................................................... 27
5 References ........................................................................................................ 28
5.1 Deliverables of AUTOSAR ......................................................................... 28
5.2 Related standards and norms .................................................................... 28

Abstraction Layer
V1.0.5
R4.0 Rev 1
1 Scope of this Document

This document specifies requirements on the modules making up the Memory
Hardware Abstraction Layer (MemHwA). The picture below shows the architecture
and context of this Memory Hardware Abstraction Layer.
id Component Model
NVRAM Manager
Memory Hardw are Abstraction
Memory Hardw are Abstraction::Memory Abstraction Interface
Memory Memory
Hardw are Hardw are
Abstraction:: Abstraction::
Flash EEPROM EEPROM
Emulation Abstraction
Memory Driv ers
Memory Driv ers:: Memory Driv ers:: Memory Driv ers::

Flash Driv er Vendor Specific EEPROM Driv er
Library
Figure 1: Components and Interfaces of the Memory Hardware Abstraction Layer
The EEPROM Abstraction (EA) module shall abstract from the addressing scheme of
the underlying EEPROM driver and provide a uniform addressing scheme. Also it
shall allow for a configurable, “virtually unlimited” number of erase-write-cycles. Thus
the upper layer (the NVRAM manager) needs not be changed if the underlying
EEPROM driver and device is changed.
The Flash EEPROM Emulation (FEE) module shall also abstract from the addressing
scheme of the underlying flash driver and provide a uniform addressing scheme and
a configurable, “virtually unlimited” number of erase-write-cycles. Thus the upper
layer (the NVRAM manager) needs not be changed if the underlying flash driver and
device is changed.
Abstraction Layer
V1.0.5
R4.0 Rev 1
The driver interface layers (EEPROM and flash interface) have to be skipped in order
to allow for an efficient implementation of the memory abstraction modules (FEE and
EA modules). The FEE and EA have to directly interface to the underlying memory
drivers. The requirements set forth for those interface layers shall instead apply to
the memory abstraction interface.
The Memory Abstraction Interface (MemIf) shall replace the driver interface layers
(EEPROM and flash interface) and allow the NVRAM manager to access several
memory abstraction modules (FEE and EA modules).
Instead of the combination of FEE / flash driver and / or EA / EEPROM driver, a

vendor specific library might be used that provides the same functionality and API as
those memory abstraction modules. The internals of such a library are of no concern
as long as the functionality and API are supported. In case the vendor library
replaces all needed FEE and EA modules, the Memory Abstraction Interface shall
only be a bunch of macros.

Abstraction Layer
V1.0.5
R4.0 Rev 1
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 are used (taken from Request for
Comment RFC 2119 from the Internet Engineering Task Force IETF)
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. Note that the requirement
level of the document in which they are used modifies the force of these words.
 MUST: This word, or the terms "REQUIRED" or "SHALL", mean that the
definition is an absolute requirement of the specification.
 MUST NOT: This phrase, or the phrase „SHALL NOT“, means that the
definition is an absolute prohibition of the specification.
 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.)

Abstraction Layer
V1.0.5
R4.0 Rev 1
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,...)
- ...

Abstraction Layer
V1.0.5
R4.0 Rev 1
3 Acronyms and abbreviations

Acronyms and abbreviations that have a local scope are not contained in the
AUTOSAR glossary. These must appear in a local glossary.
Acronyms / Description:
abbreviations
(Logical) Block Continuous area of memory that can be individually addressed by the module user
(i.e. for read / write / erase / compare operations). The block size is statically
configurable (pre-compile time).
Page Smallest amount of memory that can be written in one pass.
Sector Smallest amount of memory that can be erased in one pass.
FEE Flash EEPROM Emulation
EA EEPROM Abstraction Layer
MemIf Memory Abstraction Interface
As this is a document from professionals for professionals, all other terms are
expected to be known.

Abstraction Layer
V1.0.5
R4.0 Rev 1
4 Requirements on Memory Hardware Abstraction Layer

4.1 Functional Overview
4.1.1 EEPROM Abstraction Layer
The EEPROM Abstraction Layer (EA) shall extend the EEPROM driver such that it
provides upper layers with a virtual segmentation on a linear address space and a
“virtually limitless” number of erase / write cycles. Apart from that it shall provide the
same functionality as an EEPROM driver.
4.1.2 Flash EEPROM Emulation
The Flash EEPROM Emulation (FEE) shall emulate the behavior of the EEPROM
Abstraction Layer on flash memory technology. Thus it shall have the same
functional scope and API as the EEPROM Abstraction Layer and allow for a similar
configuration based on that of the underlying flash driver and flash device.
4.1.3 Memory Abstraction Interface
The Memory Abstraction Interface (MemIf) shall abstract from the number of
underlying FEE or EA modules and provide upper layers with a virtual segmentation
on a uniform linear address space.

Abstraction Layer
V1.0.5
R4.0 Rev 1
4.2 Memory Abstraction Modules
4.2.1 Functional Requirements
4.2.1.1 Configuration
4.2.1.1.1 BSW14001 Configuration of address alignment
Initiator: DC
Date: 12.08.2005
Short Description: Configuration of address alignment
Type: Changed (reformulated after discussion in WP SPAL)
Importance: High
Description: The FEE and EA modules shall allow the configuration of the alignment of
the start and end addresses of logical blocks.
This configuration parameter shall be used by the configuration tool to

generate the block numbers according to the block start addresses.
Rationale: 1) Ease handling of blocks inside the FEE and EA modules by aligning
logical blocks to the underlying physical memory technology.
2) Allow for FEE and EA modules to calculate block start addresses instead
of requiring a lookup table to map logical to physical addresses.
Use Case: 1) The Freescale Star12 has an internal EEPROM with 4 byte sector and 2
byte page size. By aligning the block start and end addresses to 4 byte
boundaries the handling of blocks can be simplified since read-modify-write
behavior is no longer needed.
2) Example: The address alignment is set to 4 (bytes). The first logical block
gets the block number 1, its start address is 0 (a device specific base
address is added by the underlying memory driver). The block size is 22
bytes, so it takes up 6 4-byte “pages”. The next logical block should then get
not the number 2 but the number 7, thus allowing the memory abstraction
module to deduce that its start address is 24 ((block number -1) * page size).
Dependencies: --
Conflicts: --
Supporting Material: --
4.2.1.1.2 BSW14002 Configuration of number of required write cycles
Initiator: DC
Date: 12.08.2005
Short Description: Configuration of number of required write cycles
Type: Changed
Importance: High
Description: The FEE and EA modules shall allow the configuration of a required number
of write cycles for each logical block.
Rationale: Abstract from hardware properties of underlying physical devices.
Use Case: An external flash device is specified for 10.000 erase cycles per erase unit.
A logical block is configured that requires 50.000 erase cycles.
The FEE has to make sure that this logical block can be written 50.000 times
while at the same time no flash cell must be erased more than 10.000 times.
Dependencies: [BSW14012] Spreading of write access
Conflicts: --

Abstraction Layer
V1.0.5
R4.0 Rev 1
4.2.1.1.3 BSW14003 Configuration of maximum blocking time
Initiator: NEC
Date: 16.08.2005
Short Description: Configuration of maximum blocking time
Type: New
Importance: High
Description: The EA and FEE modules shall allow the configuration of the maximum
amount of time that the module shall be blocked by internal management
operations.
If these internal management operations take longer than the configured
maximum blocking time they have to be split up into several parts.
Rationale: Limit delay / unavailability time of the module.
Use Case: E.g. the FEE needs a couple of hundred milliseconds to reorganize the
currently stored blocks when using the two-sector concept but the
application must not be denied access to non-volatile memory for more than
50 milliseconds.
Dependencies: The blocking time also depends on the scheduling of the module’s main
function.
Conflicts: --
4.2.1.1.4 BSW14004 Configuration of “immediate” data blocks
Initiator: DC
Date: 16.08.2005
Short Description: Configuration of “immediate” data blocks
Type: New
Importance: High
Description: The FEE and EA modules shall allow the configuration of logical blocks for
“immediate” data. The number and size of these blocks shall only be limited
by the memory available on the respective hardware device.
Rationale: Certain data takes precedence over other data.
Use Case: Configuration of special memory areas for so called “crash data” which has
special requirements for writing.
Dependencies: [BSW14013] Writing of “immediate” data must not be delayed
Conflicts: --
4.2.1.1.5 BSW14026 Don’t use certain block numbers
Initiator: DC
Date: 02.09.2005
Short Description: Don’t use certain block numbers
Type: New
Importance: High
Description: The block numbers 0x0000 and 0xFFFF shall not be used by the memory
Abstraction Layer
V1.0.5
R4.0 Rev 1
abstraction module / generated by the configuration tool.
Rationale: These numbers can not be distinguished from the erased value of a flash or
EEPROM device.
Use Case: The implementation stores the block number in non-volatile memory e.g. to
mark the start or end of a logical block. When these numbers would be used,
that marker could not be found / distinguished from an empty EEPROM or
flash memory.
Dependencies: --
Conflicts: --
4.2.1.1.6 BSW14027 Publish overhead for internal management data per block
Initiator: DC
Date: 02.09.2005
Short Description: Publish overhead for internal management data per block
Type: New
Importance: High
Description: The FEE and EA modules shall publish their internal management overhead
per logical block.
Rationale: Allow the configuration tool to correctly determine the next free block start
address and the correct amount of physical memory used.
Use Case: The configuration tool shall check whether all the configured logical blocks
will fit on a physical device and how much physical memory is needed for the
emulation.
Dependencies: --
Conflicts: --
4.2.1.1.7 BSW14033 Publish overhead for internal management data per page
Initiator: DC
Date: 30.11.2005
Short Description: Publish overhead for internal management data per page
Type: New
Importance: High
Description: The FEE and EA modules shall publish their internal management overhead
per page or zero if there is no overhead for managing pages.
Rationale: Depending on the implementation, management information might have to
be stored for each (physical) page to associate it with the right logical block.
Use Case: The configuration tool shall check whether all the configured logical blocks
will fit on a physical device and how much physical memory is needed for the
emulation.
Dependencies: --
Conflicts: --

Abstraction Layer
V1.0.5
R4.0 Rev 1
4.2.1.2 Initialization
No additional requirements, the “standard” requirements from the general section of

the SPAL SRS regarding initialization shall be applied.

Abstraction Layer
V1.0.5
R4.0 Rev 1
4.2.1.3 Normal Operation
4.2.1.3.1 BSW14005 Virtual linear address space and segmentation
Initiator: DC
Date: 10.08.2005
Short Description: Virtual linear address space and segmentation
Type: New
Importance: High
Description: The Flash EEPROM Emulation (FEE) and EEPROM Abstraction (EA) shall
provide upper layers with a virtual 32bit address space.
These 32 bit virtual (logical) addresses shall consist of a 16 bit logical block
identifier and a 16 bit address offset within this logical block. Thus the
memory abstraction layer shall support a (theoretical) number of 65534
logical (distinguishable) blocks per underlying physical device. Each block
can have a (theoretical) size of 64 KBytes.
Rationale: Abstract from hardware properties that would require changing the NVRAM
manager if the underlying devices / drivers change.
Use Case: 1) Support systems with a high number of small blocks
2) Support systems with a few big blocks like e.g. MMI systems (fonts,
speech) or navigation (maps, routes).
3) Allow NVRAM manager to encode block management information (e.g.
block type) in the logical block identifier (by making it big enough)
Dependencies: [BSW14026] Don’t use certain block numbers
Conflicts: --
Supporting Material: Figure 2: Virtual vs. physical address space

Abstraction Layer
V1.0.5
R4.0 Rev 1
Virtual address space Physical address space
Page size: 64 KBytes Page size: 8 Bytes
16 Bit Block Number 32 Bytes 32 Bytes Block #1 with 32 byte
uses 4 pages, no
internal residue
100 Bytes Block #5 with 100 byte
uses 13 pages, 4 byte
internal residue
16 Bit Block Offset Block 1 38 Bytes Block #17 with 38 byte

uses 5 pages, 2 byte
internal residue
100 Bytes
Block 2
38 Bytes
Block 3
Note: Sizes not shown to scale
Figure 2: Virtual vs. physical address space
4.2.1.3.2 BSW14006 Alignment of block erase / write addresses
Initiator: DC
Date: 10.08.2005
Short Description: Alignment of block erase / write addresses
Type: New
Importance: High
Description: The start address for a block erase or write operation shall always be aligned
to the virtual 64K boundary.
In other words: The offset shall be ignored for block erase / write requests,
every block erase / write request starts at address offset zero.
Rationale: Allow optimized erase / write operations in underlying emulation modules
and drivers if virtual 64K boundaries are mapped to physical sector / page
boundaries.
Use Case: Optimization of FEE and EA, simplify configuration and implementation.
Dependencies: --
Conflicts: --
Supporting Material: Just to make this clear: you can not erase or write only parts of the
configured block, it’s either all or nothing.

Abstraction Layer
V1.0.5
R4.0 Rev 1
4.2.1.3.3 BSW14007 Alignment of block read address and read length
Initiator: DC
Date: 10.08.2005
Short Description: Alignment of block read address and read length
Type: New
Importance: High
Description: The start address and length for reading a block shall not be limited to a
certain alignment, i.e. it shall be possible to read one byte starting from any
memory address.
Rationale: Byte-wise reading of flash / EEPROM.
Use Case: CRC calculation in the NVRAM manager.
Dependencies: --
Conflicts: --
Supporting Material: This allows reading a logical block in several passes, e.g. needed for CRC
calculation.
Note 1: If there are certain hardware properties that require an alignment of
the read address, e.g. only 32bit aligned read possible, this shall be handled
by the underlying driver.
Note 2: This requirement shall allow the NVRAM manager to do a byte-wise
read access on a logical block, it does not require the NVRAM manager to
do so.
4.2.1.3.4 BSW14008 Checking block read addresses
Initiator: DC
Date: 10.08.2005
Short Description: Checking block read addresses
Type: New
Importance: High
Description: The FEE and EA modules shall not check the address offset for a read
operation. It is the responsibility of the caller to provide valid parameters.
Rationale: Simplify implementation of EA and FEE modules.
Use Case: --
Dependencies: --
Conflicts: --
4.2.1.3.5 BSW14009 Conversion of logical to memory addresses
Initiator: DC
Date: 24.06.2005
Short Description: Conversion of logical to memory addresses
Type: New
Importance: High
Description: The FEE and EA modules shall provide an unambiguous conversion
between the logical linear addresses and the addresses used to access the
underlying flash memory or EEPROM.
Rationale: The physical device and the start address of a logical block shall be derived
from the logical block identifier.
Use Case: Transparent mapping of logical blocks to several physical non-volatile
Abstraction Layer
V1.0.5
R4.0 Rev 1
memory devices.
Dependencies: --
Conflicts: --
Supporting Material: The memory addresses obtained by that conversion are address offsets to a
device specific base address as described in the flash and EEPROM driver
specifications.
4.2.1.3.6 BSW14010 Block-wise write service
Initiator: DC
Date: 12.08.2005
Short Description: Block-wise write service
Type: New
Importance: High
Description: The FEE and EA modules shall provide a write service that operates only on
complete configured logical blocks.
Rationale: Decouple the upper layer from driver internals.
Use Case: The upper layer shall only make one call to the Memory Abstraction Interface
to write a logical block to non-volatile memory. If there are several passes
needed to write all of the addressed memory area, this shall be handled
internally in the FEE or EA modules or the underlying device drivers.
Dependencies: --
Conflicts: --
4.2.1.3.7 BSW14029 Block-wise read service
Initiator: DC
Date: 30.09.2005
Short Description: Block-wise read service
Type: New
Importance: High
Description: The FEE and EA modules shall provide a read service that allows reading all
or part of a logical block.
Rationale: Allow for reading of NV memory.
Use Case: Read functionality of the NVRAM manager.
Dependencies: --
Conflicts: --
4.2.1.3.8 BSW14031 Service to cancel an ongoing asynchronous operation
Initiator: DC
Date: 30.09.2005
Short Description: Service to cancel an ongoing asynchronous operation
Type: New
Importance: High
Description: The FEE and EA modules shall provide a service that allows canceling an
ongoing asynchronous operation like e.g. a read, write, erase or compare
Abstraction Layer
V1.0.5
R4.0 Rev 1
operation.
Rationale: Needed for writing “immediate” data.
Use Case: Immediate data (crash data) has to be written, while a read operation is
currently in process.
Conflicts: --
4.2.1.3.9 BSW14028 Service to invalidate a memory block
Initiator: DC
Date: 12.08.2005
Short Description: Service to invalidate a memory block
Type: New
Importance: High
Description: The FEE and EA modules shall provide a service to invalidate a logical
block. This shall be done by setting the module internal block management
data appropriately.
Note: Erasing the contents of the physical memory is an implementation

option but not required.
Rationale: To enable a data block to be marked as invalid by the upper layer.
Use Case: Allow an application to mark data as outdated or no longer valid when
physically erasing the data is not possible or not desirable (e.g. on flash
memory technology).
Dependencies: --
Conflicts: --
4.2.1.3.10 BSW14012 Spreading of write access
Initiator: DC
Date: 12.08.2005
Short Description: Spreading of write access
Type: New (derived from MemSvc BSW032)
Importance: High
Description: If the configured number of write cycles for a logical block exceeds the
number provided by the underlying physical device, the FEE or EA module
has to provide sufficient mechanisms to spread the write requests for that
logical block over a bigger memory area.
Rationale: Allow for “unlimited” number of write cycles while simultaneously preventing
memory cells from being erased more often than specified by the hardware
vendor.
Use Case: An external flash device is specified for 10.000 erase cycles per erase unit.
A logical block is configured that requires 50.000 write cycles.
The FEE has to make sure that this logical block can be written 50.000 times
while at the same time no flash cell must be erased more than 10.000 times.
Dependencies: [BSW14002] Configuration of number of required write cycles
Conflicts: --
Supporting Material: This requirement replaces [BSW032] Spreading of write access and
[BSW08530] NVRAM block type – walking from MemSvc SRS.

Abstraction Layer
V1.0.5
R4.0 Rev 1
4.2.1.3.11 BSW14013 Writing of “immediate” data must not be delayed
Initiator: DC
Date: 16.08.2005
Short Description: Writing of “immediate” data must not be delayed
Type: New
Importance: High
Description: Writing of immediate data must not be delayed by internal management
operations nor by erasing the memory area to be written to.
If internal management operations are under way when immediate data has
to be written, they have to be interrupted until the data has been written to
non-volatile memory.
There has to be a pre-erased memory area for writing of immediate data

available at all times.
Rationale: Immediate data has to be written immediately (that’s what the name implies)
that is as fast as the underlying hardware allows.
Use Case: The FEE is reorganizing the blocks currently stored in flash when crash data
has to be written.
Dependencies: [BSW14004] Configuration of “immediate” data blocks
If an ongoing hardware access, e.g. an erase operation, can not be aborted
its runtime has to be taken into account as the maximum allowable delay for
immediate write operations.
Conflicts: --
4.2.1.3.12 BSW14032 Block-wise erase service for immediate data
Initiator: DC
Date: 09.11.2005
Short Description: Block-wise erase service for immediate data
Type: New
Importance: High
Description: The FEE and EA modules shall provide an erase service that operates only
on complete logical blocks containing immediate data.
Rationale: BSW14013 requires pre-erased memory, therefore this memory areas have
to be somehow erasable.
Use Case: --
Conflicts: --
Supporting Material: - This service should only be called by a special application like e.g.
diagnostics.
- A possible implementation would be to invalidate the block containing
immediate data and subsequently force a re-organization of blocks.
During this re-organization invalidated blocks shall not be copied to the
new memory location, thus the memory area for the immediate data will
be (left) erased.

Abstraction Layer
V1.0.5
R4.0 Rev 1
4.2.1.4 Shutdown Operation
The modules of the Memory Abstraction Layer don’t need any shutdown capabilities
(also there are no shutdown capabilities in the flash or EEPROM driver).
4.2.1.5 Fault Operation
4.2.1.5.1 BSW14014 Detection of data inconsistencies
Initiator: DC
Date: 12.08.2005
Short Description: Detection of data inconsistencies
Type: New
Importance: High
Description: The FEE and EA modules shall detect possible data inconsistencies due to
aborted / interrupted write operations.
Rationale: The “user” shall not work on inconsistent data therefore it has to be
recognized.
Use Case: 1) A write operation is interrupted by a loss of power, after power-on-reset
the possible inconsistency of data shall be detected upon the next read
access to the affected memory area.
2) A write operation is cancelled by the upper layer. Upon next read access
to the affected memory area the possible data inconsistency shall be
detected.
Dependencies: --
Conflicts: --
Supporting Material: Depending on the implementation, the physical device and the point in the
write operation at which the interrupt occurs the FEE or EA module might be
able to determine that the operation has failed but not which was the block
that should have been written.
4.2.1.5.2 BSW14015 Reporting of data inconsistencies
Initiator: DC
Date: 12.08.2005
Short Description: Reporting of data inconsistencies
Type: New
Importance: High
Description: The FEE and EA modules shall report possible data inconsistencies due to
aborted / interrupted write operations to the DEM exactly once. After that the
inconsistent memory area has to be marked such that no further errors are
reported for that block.
Rationale: Avoid “endless loops” in error reporting on every block read operation.
Use Case: A write operation is interrupted or cancelled, the inconsistency is detected
and reported upon the next read access to the affected memory area.
Dependencies: [BSW14014] Detection of data inconsistencies
Conflicts: --
Supporting Material: Depending on the implementation and the point in the write operation at
which the interrupt occurs the FEE or EA module might be able to determine
that the operation has failed but not which was the block that should have
been written.

Abstraction Layer
V1.0.5
R4.0 Rev 1
In this case a read operation on that block might return old (outdated) data to
the caller if such data is available. If this is not desired from the application,
the block has to be explicitly invalidated before it is overwritten.
4.2.1.5.3 BSW14016 Don’t return inconsistent data to the caller
Initiator: DC
Date: 02.09.2005
Short Description: Don’t return inconsistent data to the caller
Type: New
Importance: High
Description: The FEE and EA modules shall not return inconsistent data to the caller.
Rationale: The “user” shall not work on inconsistent data.
Use Case: A write operation is interrupted or cancelled, the data of that block thus is
inconsistent. This inconsistency is detected on the next read access to that
block, the data shall then not be returned to the caller.
Dependencies: [BSW14014] Detection of data inconsistencies
Conflicts: --
Supporting Material: Depending on the implementation and the point in the write operation at
which the interrupt occurs the FEE or EA module might be able to determine
that the operation has failed but not which was the block that should have
been written.
In this case a read operation on that block might return old (outdated) data to
the caller if such data is available. If this is not desired from the application,
the block has to be explicitly invalidated before it is overwritten.
Providing default data for an inconsistent block is the job of the NVRAM
manager.
4.2.2 Non-Functional Requirements (Qualities)
4.2.2.1 BSW14017 Scope of EEPROM Abstraction Layer
Initiator: DC
Date: 12.08.2005
Short Description: Scope of EEPROM Abstraction Layer
Type: Changed (EA extends scope, deleted statement about EEPROM driver
requirements)
Importance: High
Description: The EEPROM Abstraction Layer (EA) shall extend the functional scope of an
EEPROM driver. In addition to the properties of an EEPROM driver, the EA
shall work on a virtual 32bit address space and it shall abstract completely
from the limitation of erase / write cycles given by the underlying device.
Rationale: Uniform handling of all EEPROM devices.
Use Case: The NVRAM manager shall not need to be changed if the underlying
EEPROM drivers and devices change.
Dependencies: --
Conflicts: --
Supporting Material: AUTOSAR SRS EEPROM driver

Abstraction Layer
V1.0.5
R4.0 Rev 1
4.2.2.2 BSW14018 Scope of Flash EEPROM Emulation
Initiator: DC
Date: 24.06.2005
Short Description: Scope of Flash EEPROM Emulation
Type: Changed (FEE extends scope, deleted statement about flash driver
requirements)
Importance: High
Description: The Flash EEPROM Emulation (FEE) shall extend the functional scope of
and internal flash driver. It shall have the same functional scope and API as
an EA module.
Rationale: Uniform handling of all flash devices.
Use Case: The NVRAM manager shall not need to be changed if the underlying flash
drivers and devices change.
Dependencies: [BSW14017] Scope of EEPROM Abstraction Layer
Conflicts: --
Supporting Material: AUTOSAR SRS EEPROM driver
AUTOSAR SRS Flash driver

Abstraction Layer
V1.0.5
R4.0 Rev 1
4.3 Memory Abstraction Interface
The following requirements have been taken over from the SPAL SRS on Memory
Abstraction and have been adapted (in wording only) to the architectural concept
shown in Figure 1.
4.3.1 Functional Requirements
4.3.1.1 General
4.3.1.1.1 BSW14019 Provide uniform access to underlying memory abstraction

modules
Initiator: DC
Date: 02.09.2005
Short Description: Provide uniform access to underlying memory abstraction modules
Type: New (derived from BSW12172)
Importance: High
Description: The Memory Abstraction Interface shall provide uniform access to those API
services of the underlying memory abstraction modules that are required for
usage within the NVRAM manager.
Further comments:
The initialization routines and the job processing functions are not mapped
by the memory abstraction interface.
Rationale: Allow usage of memory abstraction modules by one uniform interface.
Use Case: Allow the upper layer access to internal and external memory devices
without any difference.
Dependencies: --
Conflicts: --
Supporting Material: This requirement shall replace [BSW12172].
4.3.1.1.2 BSW14020 Selection of underlying memory abstraction modules
Initiator: DC
Date: 02.09.2005
Short Description: Selection of underlying memory abstraction modules
Importance: High
Description: The Memory Abstraction Interface shall allow the selection of an underlying
memory abstraction module (FEE or EA module) by using a device index.
Rationale: Requirement of the NVRAM Manager
Use Case: The NVRAM Manager uses a device index for selecting the appropriate
memory abstraction module.
Dependencies: --
Conflicts: --
Supporting Material: SWS NVRAM Manager
This requirement shall replace [BSW12173].

Abstraction Layer
V1.0.5
R4.0 Rev 1
4.3.1.2 Configuration
4.3.1.2.1 BSW14021 Number of underlying memory abstraction modules
Initiator: DC
Date: 02.09.2005
Short Description: Number of underlying memory abstraction modules
Importance: High
Description: The Memory Abstraction Interface shall allow the pre-compile time
configuration of the number of underlying memory abstraction modules.
Rationale: Flexibility
Use Case: One ECU only uses internal EEPROM (thus needing one EA module),
another ECU uses both internal plus external EEPROM (thus needing two
EA modules).
Dependencies: --
Conflicts: --
Supporting Material: WP Architecture
4.3.1.3 Normal Operation
4.3.1.3.1 BSW14022 Preserving of functionality
Initiator: DC
Date: 02.09.2005
Short Description: Preserving of functionality
Importance: High
Description: The Memory Abstraction Interface shall preserve the functionality of the
underlying memory abstraction module. It shall not provide additional
functionality.
Rationale: Simplicity, efficiency
Use Case: The memory abstraction modules abstract from all hardware properties, the
Memory Abstraction Interface does not need to add anything (it only is
needed to access more than one memory abstraction module).
Dependencies: --
Conflicts: --
4.3.1.4 Fault Operation
4.3.1.4.1 BSW14023 Parameter checking
Initiator: DC
Date: 02.09.2005
Short Description: Parameter checking
Importance: High
Description: The Memory Abstraction Interface shall only check those parameters that
Abstraction Layer
V1.0.5
R4.0 Rev 1
are used within the interface itself and that are not passed to the underlying
memory abstraction modules.
Rationale: Simplicity, efficiency: avoid double checking of parameters.
Use Case: The device index may be checked (depending on the setting of the
development error detection switch). The block address shall not be
checked.
Dependencies: --
Conflicts: --
4.3.2 Non-Functional Requirements (Qualities)
4.3.2.1 Timing Requirements
4.3.2.1.1 BSW14024 Preserving of timing behavior
Initiator: DC
Date: 02.09.2005
Short Description: Preserving of timing behavior
Importance: High
Description: The Memory Abstraction Interface shall preserve the timing behavior of the
underlying memory abstraction modules and their APIs by 1:1 mapping of
the Memory Abstraction Interface API to the memory abstraction modules’
API
Rationale: Simplicity, efficiency
Use Case: Example:
The write service of the Memory Abstraction Interface is directly mapped to
the write service of an underlying memory abstraction module (FEE or EA).
Dependencies: --
Conflicts: --
4.3.2.2 Resource Usage
4.3.2.2.1 BSW14025 Efficient implementation
Initiator: DC
Date: 02.09.2005
Short Description: Efficient implementation
Importance: High
Description: The Memory Abstraction Interface shall be implemented in a way that almost
no memory and runtime overhead is caused by the implementation of this
layer.
Implementation hint: use macros if possible.

Rationale: Resource and runtime efficiency.
Use Case: Only one memory abstraction module is used on an ECU. In this case, the
Memory Abstraction Interface can be dissolved by the preprocessor.
Abstraction Layer
V1.0.5
R4.0 Rev 1
Dependencies: --
Conflicts: --
4.4 Onboard Device Abstraction
For the Onboard Device Abstraction the same requirements like for the Memory
Hardware Abstraction apply. One member of the Onboard Device Abstraction is the
Watchdog Interface.

Abstraction Layer
V1.0.5
R4.0 Rev 1
5 References
5.1 Deliverables of AUTOSAR
[1] List of Basic Software Modules
AUTOSAR_TR_BSWModuleList.pdf
[2] Layered Software Architecture

AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[3] General Requirements on Basic Software Modules,

AUTOSAR_SRS_BSWGeneral.pdf
[4] General Requirements on SPAL

AUTOSAR_SRS_SPALGeneral.pdf
5.2 Related standards and norms
None


Document Title: Requirements On Memory Hardware Abstraction Layer

Uploaded by

Copyright:

Available Formats

Document Title: Requirements On Memory Hardware Abstraction Layer

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Document Title: Requirements On Memory Hardware Abstraction Layer

Uploaded by

Copyright:

Available Formats

Requirements on Memory Hardware

Document Title Requirements on Memory

Document Version 1.0.5

Document Change History

1 of 28 Document ID 116: AUTOSAR_SRS_MemoryHWAbstractionLayer

Advice for users

AUTOSAR specifications may contain exemplary items (exemplary reference

2 of 28 Document ID 116: AUTOSAR_SRS_MemoryHWAbstractionLayer

1 Scope of this Document ...................................................................................... 5

2 How to read this document.................................................................................. 7

4 Requirements on Memory Hardware Abstraction Layer .................................... 10

4 of 28 Document ID 116: AUTOSAR_SRS_MemoryHWAbstractionLayer

1 Scope of this Document

Memory Hardw are Abstraction

Memory Hardw are Abstraction::Memory Abstraction Interface

Memory Driv ers

Memory Driv ers:: Memory Driv ers:: Memory Driv ers::

Figure 1: Components and Interfaces of the Memory Hardware Abstraction Layer

Instead of the combination of FEE / flash driver and / or EA / EEPROM driver, a

6 of 28 Document ID 116: AUTOSAR_SRS_MemoryHWAbstractionLayer

2 How to read this document

2.1 Conventions used

7 of 28 Document ID 116: AUTOSAR_SRS_MemoryHWAbstractionLayer

2.2 Requirements structure

8 of 28 Document ID 116: AUTOSAR_SRS_MemoryHWAbstractionLayer

3 Acronyms and abbreviations

9 of 28 Document ID 116: AUTOSAR_SRS_MemoryHWAbstractionLayer

4 Requirements on Memory Hardware Abstraction Layer

4.1.1 EEPROM Abstraction Layer

4.1.2 Flash EEPROM Emulation

4.1.3 Memory Abstraction Interface

10 of 28 Document ID 116: AUTOSAR_SRS_MemoryHWAbstractionLayer

4.2 Memory Abstraction Modules

4.2.1 Functional Requirements

4.2.1.1.1 BSW14001 Configuration of address alignment

This configuration parameter shall be used by the configuration tool to

4.2.1.1.2 BSW14002 Configuration of number of required write cycles

11 of 28 Document ID 116: AUTOSAR_SRS_MemoryHWAbstractionLayer

4.2.1.1.3 BSW14003 Configuration of maximum blocking time

4.2.1.1.4 BSW14004 Configuration of “immediate” data blocks

4.2.1.1.5 BSW14026 Don’t use certain block numbers

13 of 28 Document ID 116: AUTOSAR_SRS_MemoryHWAbstractionLayer

No additional requirements, the “standard” requirements from the general section of

14 of 28 Document ID 116: AUTOSAR_SRS_MemoryHWAbstractionLayer

4.2.1.3.1 BSW14005 Virtual linear address space and segmentation

15 of 28 Document ID 116: AUTOSAR_SRS_MemoryHWAbstractionLayer

16 Bit Block Offset Block 1 38 Bytes Block #17 with 38 byte

Note: Sizes not shown to scale

Figure 2: Virtual vs. physical address space

4.2.1.3.2 BSW14006 Alignment of block erase / write addresses

16 of 28 Document ID 116: AUTOSAR_SRS_MemoryHWAbstractionLayer

4.2.1.3.4 BSW14008 Checking block read addresses

4.2.1.3.5 BSW14009 Conversion of logical to memory addresses

4.2.1.3.6 BSW14010 Block-wise write service

4.2.1.3.7 BSW14029 Block-wise read service

4.2.1.3.8 BSW14031 Service to cancel an ongoing asynchronous operation

4.2.1.3.9 BSW14028 Service to invalidate a memory block

Note: Erasing the contents of the physical memory is an implementation

4.2.1.3.10 BSW14012 Spreading of write access