Safety and Security Features in AUTOSAR

Nagarjuna Rao Kandimala, Michal SojkaCzech Technical University in Prague

166 27 Praha 6, Czech Republic

Thursday 15th November, 2012

Contents

1 Introduction 2

2 ISO 26262 2

3 AUTOSAR safety features 3

3.1 Memory partitioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

3.2 BSWM defensive behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3.2.1 Protection against unauthorized use of BSW . . . . . . . . . . . . . . . . . . . . . 4

3.2.2 Protection of data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3.3 End-to-End communication protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3.3.1 SW-C E2E communication protection . . . . . . . . . . . . . . . . . . . . . . . . . 4

3.4 Program flow monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.4.1 Logical program flow monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.5 Timing related features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.5.1 Provision of synchronized time bases . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.5.2 Synchronization of processing of asynchronous processing units . . . . . . . . . . . 6

3.5.3 Support time deterministic implementation of applications . . . . . . . . . . . . . . 6

3.5.4 Protection against timing violations . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.6 E-Gas monitoring related feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.7 Communication stack related feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

4 AUTOSAR security use cases 8

4.1 Secure access to ECUs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

4.2 Immobilizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

4.3 Transport interfaces: Generic security/protection . . . . . . . . . . . . . . . . . . . . . . . 8

5 AUTOSAR security concepts 9

5.1 Security and cryptographic architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1

5.2 Alarm clock concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

5.3 DCM manages security access level handling . . . . . . . . . . . . . . . . . . . . . . . . . 10

5.4 Format checking of diagnostic services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

5.5 NV block security of ECU reprogramming . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

5.6 Memory read access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Acronyms 12

Glossary 13

References 15

1 Introduction

Growing number of on-road vehicles increases the need for safety and security of passengers, pedestriansand the vehicle itself. The new safety standard ISO 26262 [1] provides the basis for development ofsafety-related systems comprising of electric, electronic and software components for road vehicles. Thestandard addresses generic concepts only and their implementation is up to the implementer of thedeveloped component.

AUTomotive Open System ARchitecture (AUTOSAR) 4.01 specifies many aspects of automotive systemsdevelopment. Among others, it defines concepts useful in development of safety related subsystems thatcomply with ISO 26262. It also defines several security related concepts. As both automotive safety andsecurity is the domain addressed by SESAMO project2, it is important to know what is supported byAUTOSAR and what is not. AUTOSAR is pretty big standard (it is published as a set of about 170PDF files) and it is not easy to look it up for concepts and features. For this reason, this document triesto summarize the safety and security related features (or concepts) specified in AUTOSAR.

2 ISO 26262

Before we start dealing with AUTOSAR itself, we mention the introductory requirements of ISO 26262[1] for functional safety of on-road vehicles.

• ISO 26262 provides an automotive safety lifecycle (management, development, production, oper-ation, service and decommissioning) and supports tailoring the necessary activities during theselifecycle phases.

• ISO 26262 provides an automotive specific risk-based approach for determining Automotive SafetyIntegrity Levels (ASILs).

• ISO 26262 uses ASILs for specifying the item’s necessary safety requirements for achieving anacceptable residual risk.

• ISO 26262 provides requirements for validation and confirmation measures to ensure a sufficientand acceptable level of safety being achieved.

• ISO 26262 provides requirements for the relation with suppliers.

1http://www.autosar.org2http://sesamo-project.eu

2

3 AUTOSAR safety features

AUTOSAR provides a useful document [2] that summarizes requirements related to functional safetyintroduced in the release 4.0 of AUTOSAR. This section is heavily based on this document.

3.1 Memory partitioning

This feature [3, BRF00115] is the extension of the Operating System (OS) and Run-Time Environment(RTE) functionality that enables the groups of Software Components (SW-Cs) to run in separate memorypartitions in order to avoid interference between them. It ensures that memory-related faults in a SW-Cdo not propagate to other SW-C’s. Additionally SW-C executed in user-mode has restricted access toCPU instructions that can change global CPU state [2].

Components running in a separate memory partition have to use inter-OS-Application communicationacross boundaries of memory partitions, but this is not yet defined in AUTOSAR.

Memory partitioning provides protection by means of restricting access to memory and memory-mappedhardware. In particular, code executing in one partition cannot modify memory of a different partition.Moreover, memory partitioning enables to protect read-only memory segments, as well as to protectmemory-mapped hardware.

Partitioning of BSW is not in the scope of the concept/feature – only SW-C is covered. These extensionsare also useful for debugging and testing of SW-Cs.

Figure 1 shows an example of partitioning. Partitions are used as the fault containment regions. Whenan error is detected in a particular partition then that partition can be terminated or restarted duringrun-time. These partitions are configured in Electronic Control Unit (ECU) configuration file. Let usconsider a violation/error occurrence in the partition 1 of Figure 1, Partition 1 is then terminated bythe OS services and possible communication is stopped and the partition is restarted [4].

Figure 1: Example of Partitioning (source [4])

3

3.2 BSWM defensive behavior

Basic Software Module (BSWM) defensive behavior prevents data corruption and wrong service calls inthe AUTOSAR Basic Software, this is achieved by the concepts described in the following subsections.

3.2.1 Protection against unauthorized use of BSW

AUTOSAR provides protection for BSWM from unauthorized use by SW-Cs and other BSWMs, to avoidSW-Cs from corrupting or interfering with AUTOSAR service calls of safety-relevant SW-Cs and alsoto prevent non-safety related BSWMs from corrupting or interfering with BSW used by safety-relatedBSWMs [3, BRF00128].

Example use case for this concept: Only selected software modules are allowed to request the shutdownof ECU.

3.2.2 Protection of data

AUTOSAR protects safety-related data in RAM and non-volatile memory against corruption (e.g. byusing checksums) to handle internal data in a safe manner [3, BRF00129].

3.3 End-to-End communication protection

In an embedded system the exchange of data between sender and receiver(s) can affect the functionalsafety if its functional safety depends on integrity of such data. Therefore such data are transmitted usingmechanisms to protect them against the effects of faults within the communication link [2, Sec. 1.1.5].

The End-to-End (E2E) communication protection related features are implemented in AUTOSAR 4.0as a standard library providing protection mechanisms that enable sender to protect such data and thereceiver(s) to detect and handle errors in the communication link at runtime. This library providesmechanisms for E2E protection, adequate for safety-related communication having requirements up toASIL D.

SW-C end-to-end communication protection, described in the next section, aims to protect safety-relateddata exchange among SW-Cs [2].

3.3.1 SW-C E2E communication protection

This feature [3, BRF00114] helps SW-Cs located on remote ECUs to exchange safety-related data. Safecommunication is possible by using extensions to RTE and ECU configuration file. This feature alsohelps to detect and tolerate faults in RTE, communication software and other BSWMs, as well as incommunication hardware.

Logically, this feature creates a layer between Virtual Function Bus (VFB) and SW-Cs, which is realizedby the following means:

• Safety protocol library – it is a set of stateless library functions that verify the communication(e.g. if a Cyclic Redundancy Check (CRC) of a message is correct or is it on time) and which areinvoked by RTE or SW-Cs.

• Introduction of additional configurable attributes (fields) for SW-C ports (e.g. port address), usedby safety protocol library.

The port attributes have the state information of the communication whereas the stateless library func-tion does the checks. With these extensions any inter-ECU communication can be possibly used totransmit safety related data. The safety protocol will work on any network/bus that is supported byAUTOSAR.

4

Figure 2: Example of faults detected by E2E protection (source [4])

The protocol needs to be configured depending on reliability and type of network used, size and criticalityof transmitted data and fault tolerance of application. The configuration involves selection of usedmechanisms and mechanism strength (e.g. CRC8 or CRC16), the selection is done by the integrator.

3.4 Program flow monitoring

Program flow monitoring is a mechanism to check the correct execution of software. The focus of thisconcept is the detection of program flow errors, i.e. a divergence from the valid program sequence. Anincorrect program flow occurs if one or more program instructions are processed either in the incorrectsequence, not in time or are not even processed at all. Program flow errors can for example lead to datacorruption, data inconsistencies or the SW failures [2, Sec. 1.1.1].

Logical and temporal program flow monitoring is used in the automotive industry and mentioned e.g.in ISO 26262 as a measure to detect failures of the processing units and as measure for the detection offailures of the HW clock [2, Sec. 4.1.1].

3.4.1 Logical program flow monitoring

Logical monitoring of execution sequence of a program [3, BRF00131] enables the detection of errorsthat cause a divergence from valid program sequence during the error-free execution of the application.

The valid program sequences are identified and modeled during design phase and the component forLogical Monitoring of Program Sequence uses this model to supervise or monitor the proper executionof program sequences during runtime. If any divergence is detected usually the system is reset.

To reduce the overhead caused by logical monitoring of program sequence, in AUTOSAR it is possibleto restrict the definition of Supervised Entities (SE) to safety-related tasks/runnables. At least thosehave to be monitored but non safety-related tasks can be monitored as well.

5

The logical program flow monitoring of SW-Cs and Basic Software (BSW) modules is implemented bymeans of extension of watchdog manager.

3.5 Timing related features

Timing related features [2, Sec. 4.2] can be divided into

• provision of synchronized time bases,• synchronization of processing of asynchronous processing units,• support for time deterministic implementation of applications and• support for protection against timing violations.

Those individual groups are described in the following subsections.

3.5.1 Provision of synchronized time bases

A synchronized time base is a SW time base existing at a processing entity that is synchronized with SWtime-bases at different processing entities. A synchronized time-base can be achieved by time protocolsor time agreement protocols that derive the synchronized time-base in a defined way from one or morephysical time-bases. Examples are the Network Time Protocol (NTP) and FlexRay time agreementprotocol [2, Sec. 4.2.1.1].

Synchronization will apply to the clock rate and optionally apply to the clock absolute value. Thesynchronized time bases are established by the synchronized time-base manager BSW module.

Provision of synchronized time bases within a cluster is restricted to FlexRay and TTCAN clusters inAUTOSAR release 4.0 [3, BRF00120].

AUTOSAR specifies to provide a service to access synchronized time bases available to BSWMs and SW-Cs, to enable SW-Cs to perform time-dependent actions and in particular synchronization & monitoring[3, BRF00127].

Possibility to synchronize AUTOSAR OS with global time from providing bus system in a well-definedand fast way, enabling applications to run their tasks synchronous to the global time from providing bussystem [3, BRF00278].

3.5.2 Synchronization of processing of asynchronous processing units

This concept is implemented to synchronize runnables within a set of SW-Cs. They have to be attachedto a synchronized RTE timing.

Synchronization is possible within a single ECU as well as across networks [3, BRF00126].

This feature is restricted to RTE timing events only. The events are used to trigger runnables. Thesynchronization of runnables that are controlled by different AUTOSAR OS instances (e.g. if they arerunning on different ECUs or different microcontrollers within one ECU) is only possible if they arelocated on ECUs within the same FlexRay or TTCAN network cluster.

3.5.3 Support time deterministic implementation of applications

Time deterministic implementation of applications requires to be able to specify timing constraints andanalyze timing properties at different stages of development, i.e. during virtual integration on VFBlevel, development of SW-Cs and finally the integration of SW-C into ECUs and of ECUs into a systemof ECUs [2].

It shall be possibile to develop implementations based on AUTOSAR with verifiable timing constraintson jitter, latency and execution time. This requirement relates to task scheduling, communication

6

scheduling and responsiveness to external events [3, BRF00122].

AUTOSAR specifies to enable the use of external events as an initiator for scheduling. As certain externalevents require a timely response to ensure correct behavior, these events must be able to initiate tasks[3, BRF00123].

3.5.4 Protection against timing violations

Depending on the Scalability Class, the AUTOSAR OS can provide protection mechanisms againsttiming violation. As the OS is only aware of tasks and not of runnables, the OS provides protectionmechanisms on the task level with the fault containment region being the OS application.

Timing protection of SW-Cs at runtime requires monitoring of runnables and preventing the propagationof timing faults from one SW-C to another. If SW-Cs require protection from each other, then theirrunnables have to be placed into different OS application, which implies that they are placed into differenttask bodies.

AUTOSAR specifies to provide statically configured runtime timing protection and monitoring. Thisincludes monitoring that tasks are dispatched at the specified time, meet their execution time budgetsand do not monopolize OS resources [3, BRF00121].

AUTOSAR recommends to provide a mechanism that monitors ECU local time. This is a necessarybasis for deterministic execution of safety functions and for detection of failures of the system by safetyintegrity functions, within the guaranteed time intervals [3, BRF00125].

3.6 E-Gas monitoring related feature

Electronic Gasoline (E-Gas) monitoring concept [5] is standardized by AKEGAS working group and isnot a part of AUTOSAR standard, but still it is a standardized automotive safety concept.

The E-Gas monitoring related SW is located in a Complex Device Driver (CDD). The CDD allows directaccess to the related inputs and outputs.

If the responsibility of detection is placed in CDD, AUTOSAR BSW requires to provide a mechanism totransmit the communication protections against a corruption or a loss of data to the CDD [2, BRF00243].

Exclusive/Priority access to Serial Peripheral Interface Bus (SPI) bus should be granted to SW mod-ules that carry out timing critical monitoring protocols between the main controller and a monitoringunit converted via SPI bus. This should be possible for both these SW modules being included in anAUTOSAR SW-C, and these modules being included in a complex device driver [3, BRF00251].

AUTOSAR specifies to allow the use of mechanisms for the testing and monitoring of I/O HW elementsas well as the safety related values received/transmitted using the I/O HW elements, to detect errors inmeasured sensor data or output actuator data, and to detect failures in I/O HW [3, BRF00248].

3.7 Communication stack related feature

This feature aims at enhancing fault detection in order to cover communication failure modes and alsoproviding possible recovery through redundancy [2]. The following concepts are from [3].

AUTOSAR specifies to provide mechanisms for data sequence control, enabling the possibility to checkwhether a signal is received in sequence [3, BRF00111]. For example, if a distributed safety relatedpowertrain control system receives a torque request signal via CAN with a sequence counter with avalue higher than expected, then this error is interpreted as several messages are lost and there mightbe an inconsistent state within the powertrain system, in this case usually the powertrain system isreinitialized.

AUTOSAR specifies to provide a mechanism that detects wrong routing and supports the correct routing

7

of signals between SW-Cs, to detect when a signal is coming from an unexpected SW-C sender or whenproviding the information that it is not supposed to provide. Such messages are reported as errors anddiscarded. [3, BRF00112]

AUTOSAR specifies to provide a mechanism that detects if periodic signals are not exchanged withindefined time interval. Timeouts are used to detect if communication system is functioning or if theindividual ECU is communicating. [3, BRF00113]

AUTOSAR specifies to support multiple communication links, to tolerate faults on one of the channels.[3, BRF00241]

AUTOSAR specifies to monitor network communication, to detect high-level issues with network com-munication and to increase the fault detection capabilities of the system [3, BRF00242]

4 AUTOSAR security use cases

In this section some of the security use cases are documented.

4.1 Secure access to ECUs

AUTOSAR specifies to provide secure access to ECUs (e.g. by user authentication), including stan-dardized up- and download of data and software. For this mechanisms and methods shall be defined [6,Main170].

• The update and upgrade feasibility provided by AUTOSAR includes technical challenges (e.g.standardized up-/download protocol, partly update of the software) and mechanisms (e.g. autho-rizing the user)

• To fulfill this requirement it is also necessary that the environment that is not standardized byAUTOSAR (like boot loader) needs to match the same security requirements.

4.2 Immobilizer

Immobilizer represents the anti-theft system, protecting the vehicle from unauthorized driving. In caseof any attempt for unauthorized engine start, immobilizer requests for visual and acoustical alarms tobe generated.

The core functionality of immobilizer is implemented within immobilizer manager. It incorporates thebasic functionalities like key learning, learnt key verification, immobilizer diagnostics etc. The datashared between these functionalities should be encrypted to ensure security operation. For furtherdetails on immobilizer, refer to [7, p. 77]

4.3 Transport interfaces: Generic security/protection

Protection against unauthorized access in production phase is absolutely required. In production phaseDiagnostic Log and Trace (DLT) module shall use the security mechanisms provided by DiagnosticCommunication Manager (DCM) to handle the access to the log and trace messages. The mechanism isabsolutely required to be implemented to permanently enable the communication module for testing [8,BSW35000029].

8

Figure 3: Security Application and Cryptographic routines (source [4])

Figure 4: Separation of Security Application and Cryptographic routines (source [4])

5 AUTOSAR security concepts

5.1 Security and cryptographic architecture

Each main security use case corresponds to a security application and each security application uses adifferent set of cryptographic services. The Crypto Service Manager (CSM) will make it possible fordifferent applications to use the same service but using different underlying cryptographic primitives andcryptographic schemes/routines [9]. For example one application might need to use the hash service tocompute an MD5 digest and another might need to compute an SHA1 digest as shown in Figure 3.

Commonality of cryptographic routines may lead to slightly different crypto implementation or to du-plicated code, due to which separation of security application and cryptographic routines is required.This is achieved by crypto module as shown in Figure 4.

Crypto module manages requests for cryptographic services from applications and dispatches to a pool ofcryptographic basic routines. To achieve this, crypto module exposes an interface for security applicationto allow for a generic access to standardized cryptographic routines and an interface for cryptographicroutines to allow for arbitrary implementations to plug-in crypto module and for use by security appli-cations, as shown in Figure 5.

CSM will make it possible to configure which services are needed and to create several configurationsfor each service where schemes and primitives can be chosen. Figure 6 shows the embedding of cryptomodule. CSM is located in system services of service layer. Also shown is the support of Crytographichardware, which is optional.

5.2 Alarm clock concept

Provides a real-time clock for wakeup purposes. SW-C can set or cancel wakeup alarms. Wakeup alarmallows them to leave a sleep state at a point in time in the future [3, BRF00196].

9

Figure 5: Cryptographic Architecture (source [4])

5.3 DCM manages security access level handling

The Diagnostic Communication Manager (DCM) is a basic software module that provides a common APIfor diagnostic services. The functionality of the DCM module is used by external diagnostic tools duringthe development, manufacturing or service. DCM module ensures diagnostic data flow and managesthe diagnostic states, especially diagnostic sessions and security states. DCM software specificationdocument [10] describes the functionality, the API, and the configuration of DCM.

The DCM shall manage the handling of the Unified Diagnostic Service (UDS) security access and alsothe security level handling. The accessibility of the services (service identifier) in the actual securitylevel shall be checked by the DCM [11, BSW04005].

Some diagnostic services are in dependence to a security access level. Therefore it is necessary that theDCM has knowledge about the current level and no service that is restricted by security will be processedwithout authorization. Not all diagnostic services are allowed in each security level [11, BSW04005].

5.4 Format checking of diagnostic services

The DCM absolutely requires to check the format of diagnostic service. An incorrect service shall berejected by a negative response, so that the application won’t get a request with incorrect format [11,BSW04036].

5.5 NV block security of ECU reprogramming

After ECU reprogramming some Non-Volatile Random Access Memory (NVRAM) data has to be keptsecure. This means that some of the Non-Volatile memory blocks (NV blocks) in the NVRAM shouldnever be erased nor be replaced with the default ROM data after first initialization, for example immo-bilizer code or vehicle identification number [12, BSW08015].

5.6 Memory read access

The OS may offer support to protect the memory sections of an OS-Application against read accessesby all other OS-Applications. If a task can read from any memory then it may operate on incorrectdata. This could result in failures at run time. Preventing read accesses provides a way of trapping suchfaults as soon as they occur. A secondary issue is security. While it is not anticipated that there areany security implications between OS-Applications on the same processor, read accesses does provideprotection if required [13, BSW11000]

10

Figure 6: Embedding of crypto module (source [4])

11

Acronyms

ASIL Automotive Safety Integrity LevelAUTOSAR AUTomotive Open System ARchitecture

BSW Basic SoftwareBSWM Basic Software Module

CDD Complex Device DriverCRC Cyclic Redundancy CheckCSM Crypto Service Manager

DCM Diagnostic Communication ManagerDLT Diagnostic Log and TraceDSD Diagnostic Service DispatcherDSL Diagnostic Session LayerDSP Diagnostic Service Processing

E2E End-to-EndECU Electronic Control UnitE-Gas Electronic Gasoline

NV block Non-Volatile memory blockNVRAM Non-Volatile Random Access Memory

OS Operating System

RTE Run-Time Environment

SPI Serial Peripheral Interface BusSW-C Software Component

UDS Unified Diagnostic Service

VFB Virtual Function Bus

12

Glossary

Complex Device Driver An Atomic Software Component that on oneside interfaces with the VFB and on theother side directly accesses Peripheral Hard-ware and/or ECU-Abstraction and/or MCAL.Complex Driver can be accessed via AUTOSARInterfaces and/or directly by Basic SoftwareModules[14]

Crypto Service Manager It offers a standardized access to cryptographicservices for applications and system functions.

Diagnostic Communication Manager This module provides a common API for diag-nostic services. The functionality of the DCMmodule is used by external diagnostic tools dur-ing the development, manufacturing or service.This module ensures diagnostic data flow andmanages the diagnostic states, especially di-agnostic sessions and security states. Furtherrefer[10]

Diagnostic Log and Trace It is a Basic Software Module, which handlesand stores log and trace messages produced bySWC itself or the interactions between SWCand RTE/VFB and by other Basic SofwareModules. The log and trace messages are gen-erated by calling APIs provided by the DLTmodule[8]

Diagnostic Service Dispatcher This is submodule of DCM and it processes astream of diagnostic data. It receives a new di-agnostic request over network and forwards itto a data processor and Transmits a diagnosticresponse over a network when triggered by thedata processor. Further refer[10]

Diagnostic Session Layer This is a submodule of DCM and ensuresdata flow concerning diagnostic requests and re-sponses, supervises and guarantees diagnosticprotocol timing and manages diagnostic states,especially diagnostic session and security. Fur-ther refer[10]

Diagnostic Service Processing This is a submodule of DCM and it handlesthe actual diagnostic service requests. Furtherrefer[10]

Non-Volatile memory block the entire structure, which is needed to admin-istrate and to store a block of NV data.[12]

OS-Application A block of software including tasks, interrupts,hooks and user services that form a cohesivefunctional unit

runnable Runnable entity

13

runnable entity A Runnable Entity is a part of an AtomicSoftware-Component which can be executedand scheduled independently from the otherRunnable Entities of this Atomic Software-Component. It is described by a sequence ofinstructions that can be started by the glsRTE.Each runnable entity is associated with exactlyone Entry Point.

Scalability Class A group of features of the OS (like Memory Pro-tection or Timing Protection) as defined in [15,Sec. 7.11].

Virtual Function Bus It is an abstraction of the communication be-tween Atomic Software Components and AU-TOSAR Services. This abstraction is such thatspecification of the communication mechanismsis independent from the concrete technologychosen to realize the communication

14

References

[1] ISO26262, “ISO 26262 standard for functional safety of road vehicles,” Dec 2010.

[2] AUTOSAR, “Technical safety concept status report,” Oct 2010, R4.0 rev 2. [Online]. Available:http://www.autosar.org/download/R4.0/AUTOSAR TR SafetyConceptStatusReport.pdf

[3] AUTOSAR, “Feature specification of the BSW architecture and the RTE,” Dec 2011,R4.0 rev 3. [Online]. Available: http://www.autosar.org/download/R4.0/AUTOSAR RSBSWAndRTEFeatures.pdf

[4] S. Bunzel, S. Furst, J. Wagenhuber, and F. Stappert, “Safety and security related features inautosar,” June 2010. [Online]. Available: http://www.automotive2010.de/programm/content data/Bunzel-AUTOSAR.pdf

[5] E. W. Group, “Standardized E-Gas monitoring concept for engine management systems ofgasoline and diesel engines,” Jan 2007, r4.0. [Online]. Available: http://wenku.baidu.com/view/aedb0922bcd126fff7050b51.html

[6] AUTOSAR, “Main requirements,” Dec 2011, R4.0 rev 3. [Online]. Available: http://www.autosar.org/download/R4.0/AUTOSAR RS Main.pdf

[7] AUTOSAR, “Explanation of application interfaces of the body and comfort domain,” Dec2011, R4.0 rev 3. [Online]. Available: http://www.autosar.org/download/R4.0/AUTOSAR EXPAIBodyAndComfort.pdf

[8] AUTOSAR, “Requirements on diagnostic log and trace,” Nov 2009, R4.0 rev 1. [Online]. Available:http://www.autosar.org/download/R4.0/AUTOSAR SRS DiagnosticLogAndTrace.pdf

[9] AUTOSAR, “Explanation of application interfaces of the body and comfort domain,” Nov2009, R4.0 rev 1. [Online]. Available: http://www.autosar.org/download/R4.0/AUTOSAR SRSCryptoServiceManager.pdf

[10] AUTOSAR, “Specification of diagnostic communication manager,” Sep 2010, R4,rev 3. [Online]. Available: http://www.autosar.org/download/R4.0/AUTOSAR SWSDiagnosticCommunicationManager.pdf

[11] AUTOSAR, “Requirements on diagnostic,” Dec 2011, R4.0, rev 3. [Online]. Available:http://www.autosar.org/download/R4.0/AUTOSAR SRS Diagnostic.pdf

[12] AUTOSAR, “Requirements on memory services,” Dec 2009, R4.0 rev 1. [Online]. Available:http://www.autosar.org/download/R4.0/AUTOSAR SRS MemoryServices.pdf

[13] AUTOSAR, “Requirements on operating system,” Oct 2011, R4.0 rev 3. [Online]. Available:http://www.autosar.org/download/R4.0/AUTOSAR SRS OS.pdf

[14] AUTOSAR, “Glossary,” Dec 2011, R4 rev 3. [Online]. Available: http://www.autosar.org/download/R4.0/AUTOSAR TR Glossary.pdf

[15] AUTOSAR, “Specification of operating system,” Nov 2011, R4.0 rev 3. [Online]. Available:http://www.autosar.org/download/R4.0/AUTOSAR SWS OS.pdf

15