Specification of Operating System

AUTOSAR CP R22-11

Document Title

Specification of Operating

System

Document Owner AUTOSAR

Document Responsibility AUTOSAR

Document Identification No 34

Document Status published

Part of AUTOSAR Standard Classic Platform

Part of Standard Release R22-11

Document Change History

Date Release Changed by

Description

2022-11-24 R22-11

AUTOSAR

Release

Management

• Several minor issues and

clarifications (IOC error codes,

applicability of multi-core, ARTI

updates)

• Additional memory allocation

keywords

• Added further uptraces to SRS

requirements

• Removal of

StartNonAutosarCore API

2021-11-25 R21-11

AUTOSAR

Release

Management

• Further updates to ARTI sections

• API changes and clarifications

(SetScheduleTableAsync,

GetNumberOfActivatedCores)

• New configuration options for

placement of callouts.

• Update of RES_SCHEDULER

handling.

• Minor correction / clarification /

editorial changes

2020-11-30 R20-11

AUTOSAR

Release

Management

• Updates to ARTI description and

configuration

• Ioc: correction regarding N:M

communication

• Minor correction / clarification /

editorial changes

1 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

2019-11-28 R19-11

AUTOSAR

Release

Management

• Various updates for ARTI

• Enhanced memory mapping for IOC

• Some type improvements for

multi-core

• Minor correction / clarification /

editorial changes

• Changed Document Status from

Final to published

2018-10-31 4.4.0

AUTOSAR

Release

Management

• New asynchronous services

• ARTI support (DRAFT)

• Editorial changes / clarifications

2017-12-08 4.3.1

AUTOSAR

Release

Management

• minor corrections / clarifications /

editorial changes; For details please

refer to the ChangeDocumentation

2016-11-30 4.3.0

AUTOSAR

Release

Management

• Added new API for peripheral access

• Added new API for interrupt handling

• Minor updates/clarification of

descriptions

• Editorial changes

2015-07-31 4.2.2

AUTOSAR

Release

Management

• Allow calls to ControlIdle from all

cores

• Minor updates/clarification of

descriptions

• Editorial changes

2014-10-31 4.2.1

AUTOSAR

Release

Management

• Add support for AsilQmProtection

• Minor updates/clarification of

descriptions

• Editorial changes

2014-03-31 4.1.3

AUTOSAR

Release

Management

• Changed multiplicity of attributes in

IocSender/ReceiverProperties

• Minor updates/clarification of

descriptions

• Editorial changes

2 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

2013-10-31 4.1.2

AUTOSAR

Release

Management

• Clarification on

E_OS_NESTING_DEADLOCK

• Update of table 2

• Corrected multiplicity of

ECUC_Os_00393

• Minor updates/clarification of

descriptions

• Editorial changes

• Removed chapter(s) on change

documentation

2013-03-15 4.1.1

AUTOSAR

Administration

• Add support for ECU degradation

• Changed service interface

description to a formal format

• Several minor changes and

clarifications

2011-12-22 4.0.3

AUTOSAR

Administration

• Included Multi-Core support from

former "Specification of Multi-Core

OS Architecture"

2010-09-30 3.1.5

AUTOSAR

Administration

• Clarification in 7.8.1 (meaning of "do

nothing") and 7.1.2.1 ("OSEK

declarations")

• Minor changes as typos and

rewording

2010-02-02 3.1.4

AUTOSAR

Administration

• Extension of services (Chapter 12)

• States in OS- Applications

• Active termination of other

OS-Applications in possible

(Chapter8)

• Legal disclaimer revised

• Chapter 10.4 revised

2009-02-04 3.1.2

AUTOSAR

Administration

• Changes in OS configuration:

• removed "OsAppModeId" Parameter

from OsAppModeContainer

• added optional references from

OsAppModeContainer to OsAlarm,

OsTask and OsScheduleTable

2008-08-13 3.1.1

AUTOSAR

Administration

• Legal Disclaimer revised

2008-02-01 3.0.2

AUTOSAR

Administration

• Added "OsScheduleTableDuration"

parameter to configuration

specification chapter

3 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

2007-12-21 3.0.1

AUTOSAR

Administration

• Changed methods for timing

protection

• Moved configuration from OIL to

AUTOSAR XML

• Clarrified description for

synchronization and

ScheduleTables

• Document meta information

extended

• Small layout adaptations made

2007-01-24 2.1.15

AUTOSAR

Administration

• Added support for

SoftwareFreeRunningTimer

(SWFRT) incl. 2 new APIs

• Added API to start a

ScheduleTable synchron

• Misc. Corrections, Clarification and

further explanations

• Legal disclaimer revised

• Release Notes added

• "Advice for users" revised

• "Revision Information" added

2006-05-16 2.0

AUTOSAR

Administration

• Document structure adapted to

common Release 2.0 SWS

Template.

• Major changes in chapter 10

• Structure of document changed

partly

• Other changes see chapter 14

2005-05-31 1.0

AUTOSAR

Administration

• Initial Release

4 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Disclaimer

This work (specification and/or software implementation) and the material contained in

it, as released by AUTOSAR, is for the purpose of information only. AUTOSAR and the

companies that have contributed to it shall not be liable for any use of the work.

The material contained in this work is protected by copyright and other types of intel-

lectual property rights. The commercial exploitation of the material contained in this

work requires a license to such intellectual property rights.

This work may be utilized or reproduced without any modification, in any form or by

any means, for informational purposes only. For any other purpose, no part of the work

may be utilized or reproduced, in any form or by any means, without permission in

writing from the publisher.

The work has been developed for automotive applications only. It has neither been

developed, nor tested for non-automotive applications.

The word AUTOSAR and the AUTOSAR logo are registered trademarks.

5 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Contents

1 Introduction and functional overview 15

2 Acronyms and Abbreviations 16

2.1 Glossary of Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3 Related documentation 21

3.1 Input documents & related standards and norms . . . . . . . . . . . . 21

3.2 Related specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4 Constraints and assumptions 22

4.1 Existing Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.3 Interaction with the RTE . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.4 Operating System Abstraction Layer (OSAL) . . . . . . . . . . . . . . . 23

4.5 Multi-Core Hardware assumptions . . . . . . . . . . . . . . . . . . . . 23

4.5.1 CPU Core features . . . . . . . . . . . . . . . . . . . . . . . 23

4.5.2 Memory features . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.5.3 Multi-Core Limitations . . . . . . . . . . . . . . . . . . . . . . 24

4.6 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.6.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.6.2 Programming Language . . . . . . . . . . . . . . . . . . . . . 25

4.6.3 Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.7 Applicability to car domains . . . . . . . . . . . . . . . . . . . . . . . . 26

5 Dependencies to other modules 27

5.1 File structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.1.1 Code file structure . . . . . . . . . . . . . . . . . . . . . . . . 27

5.1.2 Header file structure . . . . . . . . . . . . . . . . . . . . . . . 27

5.1.3 ARTI File Structure . . . . . . . . . . . . . . . . . . . . . . . 27

6 Requirements Tracing 28

7 Functional specification 41

7.1 Core OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

7.1.1 Background & Rationale . . . . . . . . . . . . . . . . . . . . 41

7.1.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 41

7.1.2.1 Restrictions on OSEK OS . . . . . . . . . . . . . . . 42

7.1.2.2 Undefined Behaviour in OSEK OS . . . . . . . . . . 42

7.1.2.3 Extensions to OSEK OS . . . . . . . . . . . . . . . . 43

7.2 Software Free Running Timer . . . . . . . . . . . . . . . . . . . . . . . 43

7.3 ScheduleTables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

7.3.1 Background & Rationale . . . . . . . . . . . . . . . . . . . . 44

7.3.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 45

7.3.2.1 Structure of a ScheduleTable . . . . . . . . . . . . 45

7.3.2.2 Constraints on Expiry Points . . . . . . . . . . . . . . 45

6 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

7.3.2.3 Processing ScheduleTables . . . . . . . . . . . . 46

7.3.2.4 Repeated ScheduleTable Processing . . . . . . . 47

7.3.2.5 Controlling ScheduleTable Processing . . . . . . 48

7.4 ScheduleTable Synchronization . . . . . . . . . . . . . . . . . . . . 50

7.4.1 Background & Rationale . . . . . . . . . . . . . . . . . . . . 50

7.4.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 52

7.4.2.1 Implicit Synchronization . . . . . . . . . . . . . . . . 52

7.4.2.2 Explicit Synchronization . . . . . . . . . . . . . . . . 53

7.4.2.3 Performing Synchronization . . . . . . . . . . . . . . 57

7.5 Stack Monitoring Facilities . . . . . . . . . . . . . . . . . . . . . . . . . 59

7.5.1 Background & Rationale . . . . . . . . . . . . . . . . . . . . 59

7.5.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 59

7.6 OS-Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

7.6.1 Background & Rationale . . . . . . . . . . . . . . . . . . . . 60

7.6.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 62

7.7 Protection Facilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

7.7.1 Memory Protection . . . . . . . . . . . . . . . . . . . . . . . 64

7.7.1.1 Background & Rationale . . . . . . . . . . . . . . . . 64

7.7.1.2 Requirements . . . . . . . . . . . . . . . . . . . . . . 65

7.7.2 Timing Protection . . . . . . . . . . . . . . . . . . . . . . . . 66

7.7.2.1 Background & Rationale . . . . . . . . . . . . . . . . 66

7.7.2.2 Requirements . . . . . . . . . . . . . . . . . . . . . . 70

7.7.2.3 Implementation Notes . . . . . . . . . . . . . . . . . 71

7.7.3 Service Protection . . . . . . . . . . . . . . . . . . . . . . . . 72

7.7.3.1 Background & Rationale . . . . . . . . . . . . . . . . 72

7.7.3.2 Invalid Object Parameter or Out of Range Value . . . 73

7.7.3.3 Service Calls Made from Wrong Context . . . . . . . 73

7.7.3.4 Services with Undefined Behaviour . . . . . . . . . . 75

7.7.3.5 Service Restrictions for Non-Trusted OS-Applications 76

7.7.3.6 Service Calls on Objects in Different OS-Applications 77

7.7.4 Protecting the Hardware used by the OS . . . . . . . . . . . 78

7.7.4.1 Background & Rationale . . . . . . . . . . . . . . . . 78

7.7.4.2 Requirements . . . . . . . . . . . . . . . . . . . . . . 79

7.7.4.3 Implementation Notes . . . . . . . . . . . . . . . . . 79

7.7.5 Providing Trustedfunctions . . . . . . . . . . . . . . . . 79

7.7.5.1 Background & Rationale . . . . . . . . . . . . . . . . 79

7.7.5.2 Requirements . . . . . . . . . . . . . . . . . . . . . . 80

7.8 Protection Error Handling . . . . . . . . . . . . . . . . . . . . . . . . . 80

7.8.1 Background & Rationale . . . . . . . . . . . . . . . . . . . . 80

7.8.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 82

7.9 Operating System for Multi-Core . . . . . . . . . . . . . . . . . . . . . 83

7.9.1 Background & Rationale . . . . . . . . . . . . . . . . . . . . 83

7.9.1.1 Requirements . . . . . . . . . . . . . . . . . . . . . . 84

7.9.2 Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

7.9.2.1 Requirements . . . . . . . . . . . . . . . . . . . . . . 85

7.9.3 Locatable entities (LE) . . . . . . . . . . . . . . . . . . . . . . 85

7 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

7.9.3.1 Requirements . . . . . . . . . . . . . . . . . . . . . . 85

7.9.4 Multi-Core start-up concept . . . . . . . . . . . . . . . . . . . 86

7.9.4.1 Requirements . . . . . . . . . . . . . . . . . . . . . . 88

7.9.5 Cores under control of the AUTOSAR OS . . . . . . . . . . . 89

7.9.5.1 Requirements . . . . . . . . . . . . . . . . . . . . . . 89

7.9.6 Multi-Core shutdown concept . . . . . . . . . . . . . . . . . . 89

7.9.6.1 Synchronized shutdown concept . . . . . . . . . . . 89

7.9.6.2 Individual shutdown concept . . . . . . . . . . . . . . 90

7.9.6.3 Shutdown in case of fatal internal errors . . . . . . . 91

7.9.7 OS service functionality (overview) . . . . . . . . . . . . . . . 91

7.9.8 GetTaskID . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

7.9.9 Interrupt disabling . . . . . . . . . . . . . . . . . . . . . . . . 93

7.9.9.1 Requirements . . . . . . . . . . . . . . . . . . . . . . 93

7.9.10 Task activation . . . . . . . . . . . . . . . . . . . . . . . . . 94

7.9.10.1 Requirements . . . . . . . . . . . . . . . . . . . . . . 94

7.9.11 Task Chaining . . . . . . . . . . . . . . . . . . . . . . . . . . 94

7.9.11.1 Requirements . . . . . . . . . . . . . . . . . . . . . . 94

7.9.12 Event setting . . . . . . . . . . . . . . . . . . . . . . . . . . 95

7.9.12.1 Requirements . . . . . . . . . . . . . . . . . . . . . . 95

7.9.13 Activating additional cores . . . . . . . . . . . . . . . . . . . 95

7.9.14 Start of the OS . . . . . . . . . . . . . . . . . . . . . . . . . . 95

7.9.14.1 Requirements . . . . . . . . . . . . . . . . . . . . . . 96

7.9.15 Task termination . . . . . . . . . . . . . . . . . . . . . . . . 96

7.9.15.1 Requirements . . . . . . . . . . . . . . . . . . . . . . 96

7.9.16 Termination of OS-Applications . . . . . . . . . . . . . . . . . 97

7.9.16.1 Requirements . . . . . . . . . . . . . . . . . . . . . . 97

7.9.17 Shutdown of the OS . . . . . . . . . . . . . . . . . . . . . . . 97

7.9.17.1 Requirements . . . . . . . . . . . . . . . . . . . . . . 97

7.9.18 Waiting for Events . . . . . . . . . . . . . . . . . . . . . . . 98

7.9.18.1 Requirements . . . . . . . . . . . . . . . . . . . . . . 98

7.9.19 Calling trusted functions . . . . . . . . . . . . . . . . . . . . . 98

7.9.19.1 Requirements . . . . . . . . . . . . . . . . . . . . . . 99

7.9.20 Invoking reschedule . . . . . . . . . . . . . . . . . . . . . . . 99

7.9.20.1 Requirements . . . . . . . . . . . . . . . . . . . . . . 99

7.9.21 Resource handling . . . . . . . . . . . . . . . . . . . . . . . 99

7.9.22 The CoreID . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

7.9.22.1 Requirements . . . . . . . . . . . . . . . . . . . . . . 100

7.9.23 Counters, background & rationale . . . . . . . . . . . . . . 100

7.9.24 Multi-Core restrictions on Counters . . . . . . . . . . . . . . 101

7.9.24.1 Requirements . . . . . . . . . . . . . . . . . . . . . . 101

7.9.25 Synchronization of Counters . . . . . . . . . . . . . . . . . 102

7.9.26 Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

7.9.26.1 Requirements . . . . . . . . . . . . . . . . . . . . . . 103

7.9.27 ScheduleTables . . . . . . . . . . . . . . . . . . . . . . . . 104

7.9.27.1 Requirements . . . . . . . . . . . . . . . . . . . . . . 104

7.9.28 The spinlock mechanism . . . . . . . . . . . . . . . . . . . . 104

8 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

7.9.28.1 Requirements . . . . . . . . . . . . . . . . . . . . . . 107

7.9.29 Offline checks . . . . . . . . . . . . . . . . . . . . . . . . . . 108

7.9.29.1 Requirements . . . . . . . . . . . . . . . . . . . . . . 108

7.9.30 Auto start Objects . . . . . . . . . . . . . . . . . . . . . . . . 109

7.9.30.1 Requirements . . . . . . . . . . . . . . . . . . . . . . 109

7.10 Inter-OS-Application Communicator (IOC) . . . . . . . . . . . . . . . . 109

7.10.1 Background & Rationale . . . . . . . . . . . . . . . . . . . . 109

7.10.2 IOC - General purpose . . . . . . . . . . . . . . . . . . . . . 112

7.10.3 IOC functionality . . . . . . . . . . . . . . . . . . . . . . . . . 112

7.10.3.1 Communication . . . . . . . . . . . . . . . . . . . . . 112

7.10.3.2 Notification . . . . . . . . . . . . . . . . . . . . . . . 113

7.10.4 IOC interface . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

7.10.5 IOC internal structure . . . . . . . . . . . . . . . . . . . . . . 114

7.10.6 IOC configuration and generation . . . . . . . . . . . . . . . 115

7.10.7 IOC integration examples . . . . . . . . . . . . . . . . . . . . 116

7.10.7.1 Example 1 - 1:1 sender/receiver communication

without notification . . . . . . . . . . . . . . . . . . . 116

7.10.7.2 Example 2 - N:1 client/server communication with re-

ceiver notification by RTE . . . . . . . . . . . . . . . 118

7.10.8 Future extensions . . . . . . . . . . . . . . . . . . . . . . . . 119

7.11 System Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

7.11.1 Background & Rationale . . . . . . . . . . . . . . . . . . . . 119

7.11.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 120

7.12 Hook Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

7.12.1 Background & Rationale . . . . . . . . . . . . . . . . . . . . 121

7.12.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 121

7.13 Hardware peripheral access . . . . . . . . . . . . . . . . . . . . . . . . 122

7.13.1 Background & Rationale . . . . . . . . . . . . . . . . . . . . 122

7.13.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 123

7.14 Interrupt source API . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

7.14.1 Background & Rationale . . . . . . . . . . . . . . . . . . . . 123

7.14.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 124

7.15 Error classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

7.16 ARTI Debug Information . . . . . . . . . . . . . . . . . . . . . . . . . . 125

7.16.1 OS ARTI Objects . . . . . . . . . . . . . . . . . . . . . . . . 126

7.17 ARTI Hook Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

7.17.1 Class AR_CP_OS_APPLICATION . . . . . . . . . . . . . . . 128

7.17.2 Class AR_CP_OS_TASK . . . . . . . . . . . . . . . . . . . . 129

7.17.3 Class AR_CP_OS_CAT2ISR . . . . . . . . . . . . . . . . . . 131

7.17.4 Class AR_CP_OS_SERVICECALLS . . . . . . . . . . . . . . 133

7.17.5 Class AR_CP_OS_SPINLOCK . . . . . . . . . . . . . . . . . 136

7.17.6 Class AR_CP_OS_HOOK . . . . . . . . . . . . . . . . . . . 137

8 API specification 138

8.1 Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

8.1.1 Error codes of type StatusType . . . . . . . . . . . . . . . 138

9 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

8.2 Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

8.3 Type definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

8.3.1 ApplicationType (for OS-Applications) . . . . . . . . . . 139

8.3.2 ApplicationStateType . . . . . . . . . . . . . . . . . . . 139

8.3.3 ApplicationStateRefType . . . . . . . . . . . . . . . . . 140

8.3.4 TrustedFunctionIndexType . . . . . . . . . . . . . . . . 140

8.3.5 TrustedFunctionParameterRefType . . . . . . . . . . 140

8.3.6 AccessType . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

8.3.7 ObjectAccessType . . . . . . . . . . . . . . . . . . . . . . 141

8.3.8 ObjectTypeType . . . . . . . . . . . . . . . . . . . . . . . . 141

8.3.9 MemoryStartAddressType . . . . . . . . . . . . . . . . . 142

8.3.10 MemorySizeType . . . . . . . . . . . . . . . . . . . . . . . . 142

8.3.11 ISRType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

8.3.12 ScheduleTableType . . . . . . . . . . . . . . . . . . . . . 143

8.3.13 ScheduleTableStatusType . . . . . . . . . . . . . . . . . 143

8.3.14 ScheduleTableStatusRefType . . . . . . . . . . . . . . 143

8.3.15 ProtectionReturnType . . . . . . . . . . . . . . . . . . . 144

8.3.16 RestartType . . . . . . . . . . . . . . . . . . . . . . . . . . 144

8.3.17 PhysicalTimeType . . . . . . . . . . . . . . . . . . . . . . 145

8.3.18 CoreIdType . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

8.3.19 SpinlockIdType . . . . . . . . . . . . . . . . . . . . . . . . 145

8.3.20 TryToGetSpinlockType . . . . . . . . . . . . . . . . . . . 146

8.3.21 IdleModeType . . . . . . . . . . . . . . . . . . . . . . . . . 146

8.3.22 AreaIdType . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

8.4 Function definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

8.4.1 GetApplicationID . . . . . . . . . . . . . . . . . . . . . . 147

8.4.2 GetCurrentApplicationID . . . . . . . . . . . . . . . . . 147

8.4.3 GetISRID . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

8.4.4 CallTrustedFunction . . . . . . . . . . . . . . . . . . . . 149

8.4.5 CheckISRMemoryAccess . . . . . . . . . . . . . . . . . . . 151

8.4.6 CheckTaskMemoryAccess . . . . . . . . . . . . . . . . . . 151

8.4.7 CheckObjectAccess . . . . . . . . . . . . . . . . . . . . . 152

8.4.8 CheckObjectOwnership . . . . . . . . . . . . . . . . . . . 153

8.4.9 StartScheduleTableRel . . . . . . . . . . . . . . . . . . 154

8.4.10 StartScheduleTableAbs . . . . . . . . . . . . . . . . . . 155

8.4.11 StopScheduleTable . . . . . . . . . . . . . . . . . . . . . 156

8.4.12 NextScheduleTable . . . . . . . . . . . . . . . . . . . . . 157

8.4.13 StartScheduleTableSynchron . . . . . . . . . . . . . . 158

8.4.14 SyncScheduleTable . . . . . . . . . . . . . . . . . . . . . 159

8.4.15 SetScheduleTableAsync . . . . . . . . . . . . . . . . . . 161

8.4.16 GetScheduleTableStatus . . . . . . . . . . . . . . . . . 162

8.4.17 IncrementCounter . . . . . . . . . . . . . . . . . . . . . . 163

8.4.18 GetCounterValue . . . . . . . . . . . . . . . . . . . . . . . 164

8.4.19 GetElapsedValue . . . . . . . . . . . . . . . . . . . . . . . 164

8.4.20 TerminateApplication . . . . . . . . . . . . . . . . . . . 165

8.4.21 AllowAccess . . . . . . . . . . . . . . . . . . . . . . . . . . 167

10 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

8.4.22 GetApplicationState . . . . . . . . . . . . . . . . . . . . 168

8.4.23 GetNumberOfActivatedCores . . . . . . . . . . . . . . . 169

8.4.24 GetCoreID . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

8.4.25 StartCore . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

8.4.26 GetSpinlock . . . . . . . . . . . . . . . . . . . . . . . . . . 170

8.4.27 ReleaseSpinlock . . . . . . . . . . . . . . . . . . . . . . . 172

8.4.28 TryToGetSpinlock . . . . . . . . . . . . . . . . . . . . . . 173

8.4.29 ShutdownAllCores . . . . . . . . . . . . . . . . . . . . . . 174

8.4.30 ControlIdle . . . . . . . . . . . . . . . . . . . . . . . . . . 175

8.4.31 ReadPeripheral8, ReadPeripheral16, ReadPeriph-

eral32 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

8.4.32 WritePeripheral8, WritePeripheral16, WritePe-

ripheral32 . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

8.4.33 ModifyPeripheral8, ModifyPeripheral16, Modi-

fyPeripheral32 . . . . . . . . . . . . . . . . . . . . . . . . 179

8.4.34 EnableInterruptSource . . . . . . . . . . . . . . . . . . 181

8.4.35 DisableInterruptSource . . . . . . . . . . . . . . . . . 182

8.4.36 ClearPendingInterrupt . . . . . . . . . . . . . . . . . . 182

8.4.37 ActivateTaskAsyn . . . . . . . . . . . . . . . . . . . . . . 183

8.4.38 SetEventAsyn . . . . . . . . . . . . . . . . . . . . . . . . . 183

8.5 IOC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184

8.5.1 Imported types . . . . . . . . . . . . . . . . . . . . . . . . . . 184

8.5.2 Type definitions . . . . . . . . . . . . . . . . . . . . . . . . . 184

8.5.3 Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184

8.5.4 Function definitions . . . . . . . . . . . . . . . . . . . . . . . 185

8.5.4.1 IocInit (DRAFT) . . . . . . . . . . . . . . . . . . . 185

8.5.4.2 IocSend/IocWrite . . . . . . . . . . . . . . . . . . 186

8.5.4.3 IocSendGroup/IocWriteGroup . . . . . . . . . . 189

8.5.4.4 IocReceive/IocRead . . . . . . . . . . . . . . . . 192

8.5.4.5 IocReceiveGroup/IocReadGroup . . . . . . . . . 194

8.5.4.6 IocEmptyQueue . . . . . . . . . . . . . . . . . . . . 197

8.6 Expected Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

8.6.1 Mandatory Interfaces . . . . . . . . . . . . . . . . . . . . . . 197

8.6.2 Optional Interfaces . . . . . . . . . . . . . . . . . . . . . . . . 198

8.6.2.1 ReceiverPullCB . . . . . . . . . . . . . . . . . . . . . 198

8.7 Hook functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198

8.7.1 ProtectionHook . . . . . . . . . . . . . . . . . . . . . . . . 199

8.7.2 Application specific StartupHook . . . . . . . . . . . . . . . 200

8.7.3 Application specific ErrorHook . . . . . . . . . . . . . . . . 200

8.7.4 Application specific ShutdownHook . . . . . . . . . . . . . . 201

8.8 Service Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

8.8.1 Port interface of Os . . . . . . . . . . . . . . . . . . . . . . . 201

8.8.2 Client-Server-Interfaces . . . . . . . . . . . . . . . . . . . . . 202

8.8.2.1 Os_Service . . . . . . . . . . . . . . . . . . . . . . . 202

8.8.2.2 Implementation Data Types . . . . . . . . . . . . . . 203

9 Sequence diagrams 204

11 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

9.1 Sequence chart for calling trusted functions . . . . . . . . . . . . . . . 204

9.2 Sequence chart for usage of ErrorHook . . . . . . . . . . . . . . . . 205

9.3 Sequence chart for ProtectionHook . . . . . . . . . . . . . . . . . . 206

9.4 Sequence chart for StartupHook . . . . . . . . . . . . . . . . . . . . 207

9.5 Sequence chart for ShutdownHook . . . . . . . . . . . . . . . . . . . 207

9.6 Sequence diagrams of Sender Receiver communication over the IOC . 208

9.6.1 Last-is-best communication . . . . . . . . . . . . . . . . . . . 208

9.6.2 Queued communication without pull callback . . . . . . . . . 209

9.6.3 Queued communication with pull callback . . . . . . . . . . . 210

10 Configuration specification 212

10.1 How to read this chapter . . . . . . . . . . . . . . . . . . . . . . . . . . 212

10.1.1 Rules for paramters . . . . . . . . . . . . . . . . . . . . . . . 212

10.2 Containers and configuration parameters . . . . . . . . . . . . . . . . . 212

10.2.1 Os . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213

10.2.2 OsAlarmSetEvent . . . . . . . . . . . . . . . . . . . . . . . . 215

10.2.3 OsAlarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215

10.2.4 OsAlarmAction . . . . . . . . . . . . . . . . . . . . . . . . . . 217

10.2.5 OsAlarmActivateTask . . . . . . . . . . . . . . . . . . . . . . 218

10.2.6 OsAlarmAutostart . . . . . . . . . . . . . . . . . . . . . . . . 218

10.2.7 OsAlarmCallback . . . . . . . . . . . . . . . . . . . . . . . . 220

10.2.8 OsAlarmIncrementCounter . . . . . . . . . . . . . . . . . . . 220

10.2.9 OsApplication . . . . . . . . . . . . . . . . . . . . . . . . . . 221

10.2.10 OsApplicationHooks . . . . . . . . . . . . . . . . . . . . . . . 227

10.2.11 OsApplicationTrustedFunction . . . . . . . . . . . . . . . . . 229

10.2.12 OsAppMode . . . . . . . . . . . . . . . . . . . . . . . . . . . 230

10.2.13 OsCounter . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230

10.2.14 OsEvent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234

10.2.15 OsDriver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234

10.2.16 OsHooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235

10.2.17 OsIsr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238

10.2.18 OsIsrResourceLock . . . . . . . . . . . . . . . . . . . . . . . 242

10.2.19 OsIsrTimingProtection . . . . . . . . . . . . . . . . . . . . . . 242

10.2.20 OsOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245

10.2.21 OsPeripheralArea . . . . . . . . . . . . . . . . . . . . . . . . 248

10.2.22 OsResource . . . . . . . . . . . . . . . . . . . . . . . . . . . 250

10.2.23 OsScheduleTable . . . . . . . . . . . . . . . . . . . . . . . . 251

10.2.24 OsScheduleTableAutostart . . . . . . . . . . . . . . . . . . . 254

10.2.25 OsScheduleTableEventSetting . . . . . . . . . . . . . . . . . 256

10.2.26 OsScheduleTableExpiryPoint . . . . . . . . . . . . . . . . . . 257

10.2.27 OsScheduleTableTaskActivation . . . . . . . . . . . . . . . . 257

10.2.28 OsScheduleTblAdjustableExpPoint . . . . . . . . . . . . . . . 258

10.2.29 OsScheduleTableSync . . . . . . . . . . . . . . . . . . . . . 259

10.2.30 OsSpinlock . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260

10.2.31 OsTask . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261

10.2.32 OsTaskAutostart . . . . . . . . . . . . . . . . . . . . . . . . . 266

12 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

10.2.33 OsTaskResourceLock . . . . . . . . . . . . . . . . . . . . . . 266

10.2.34 OsTaskTimingProtection . . . . . . . . . . . . . . . . . . . . 267

10.2.35 OsTimeConstant . . . . . . . . . . . . . . . . . . . . . . . . . 269

10.3 Containers and configuration parameter extensions of the IOC . . . . . 270

10.3.1 OsIoc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271

10.3.2 OsIocCommunication . . . . . . . . . . . . . . . . . . . . . . 271

10.3.3 OsIocSenderProperties . . . . . . . . . . . . . . . . . . . . . 272

10.3.4 OsIocReceiverProperties . . . . . . . . . . . . . . . . . . . . 274

10.3.5 OsIocDataProperties . . . . . . . . . . . . . . . . . . . . . . 276

10.4 Containers and configuration parameters for ARTI . . . . . . . . . . . 278

10.4.1 ArtiHardware . . . . . . . . . . . . . . . . . . . . . . . . . . . 278

10.4.2 ArtiHardwareCoreClass . . . . . . . . . . . . . . . . . . . . . 279

10.4.3 ArtiHardwareCoreInstance . . . . . . . . . . . . . . . . . . . 282

10.4.4 ArtiOs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286

10.4.5 ArtiOsAlarmClass . . . . . . . . . . . . . . . . . . . . . . . . 288

10.4.6 ArtiOsAlarmInstance . . . . . . . . . . . . . . . . . . . . . . 289

10.4.7 ArtiOsClass . . . . . . . . . . . . . . . . . . . . . . . . . . . 292

10.4.8 ArtiOsContextClass . . . . . . . . . . . . . . . . . . . . . . . 293

10.4.9 ArtiOsContextInstance . . . . . . . . . . . . . . . . . . . . . 294

10.4.10 ArtiOsInstance . . . . . . . . . . . . . . . . . . . . . . . . . . 296

10.4.11 ArtiOsIsrClass . . . . . . . . . . . . . . . . . . . . . . . . . . 299

10.4.12 ArtiOsIsrInstance . . . . . . . . . . . . . . . . . . . . . . . . 300

10.4.13 ArtiOsMessageContainerClass . . . . . . . . . . . . . . . . . 302

10.4.14 ArtiOsMessageContainerInstance . . . . . . . . . . . . . . . 303

10.4.15 ArtiOsResourceClass . . . . . . . . . . . . . . . . . . . . . . 306

10.4.16 ArtiOsResourceInstance . . . . . . . . . . . . . . . . . . . . 307

10.4.17 ArtiOsStackClass . . . . . . . . . . . . . . . . . . . . . . . . 310

10.4.18 ArtiOsStackInstance . . . . . . . . . . . . . . . . . . . . . . . 311

10.4.19 ArtiOsTaskClass . . . . . . . . . . . . . . . . . . . . . . . . . 313

10.4.20 ArtiOsTaskInstance . . . . . . . . . . . . . . . . . . . . . . . 316

10.5 Published Information . . . . . . . . . . . . . . . . . . . . . . . . . . . 320

11 Generation of the OS 321

11.1 Read in configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321

11.2 Consistency check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321

11.3 Generating operating system . . . . . . . . . . . . . . . . . . . . . . . 323

12 Application Notes 324

12.1 Hooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324

12.2 Providing Trusted Functions . . . . . . . . . . . . . . . . . . . . . . . . 324

12.3 Software Components and OS-Applications . . . . . . . . . . . . . . . 326

12.4 Global Time Synchronization . . . . . . . . . . . . . . . . . . . . . . . 326

12.5 Working with FlexRay . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326

12.6 Migration from OIL to XML . . . . . . . . . . . . . . . . . . . . . . . . . 328

12.7 Debug support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328

12.8 Integration hints for peripheral protection . . . . . . . . . . . . . . . . . 329

12.9 Termination of OS-Applications . . . . . . . . . . . . . . . . . . . . . . 330

13 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

13 AUTOSAR Service implemented by the OS 332

13.1 Scope of this Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . 332

13.1.1 Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332

13.2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332

13.3 Specification of the Ports and Port Interfaces . . . . . . . . . . . . . . 332

14 Outlook on Memory Protection Configuration 334

14.1 Configuration Approach . . . . . . . . . . . . . . . . . . . . . . . . . . 334

A Not applicable requirements 335

14 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

1 Introduction and functional overview

This document describes the essential requirements on the AUTOSAR Operating Sys-

tem to satisfy the top-level requirements presented in the AUTOSAR SRS [1].

In general, operating systems can be split up in different groups according to their

characteristics, e.g. statically configured vs. dynamically managed. To classify the

AUTOSAR OS, here are the basic features of the OS

• is configured and scaled statically

• is amenable to reasoning of real-time performance

• provides a priority-based scheduling policy

• provides protective functions (memory, timing etc.) at run-time

• is hostable on low-end controllers and without external resources

This feature set defines the type of OS commonly used in the current generation of au-

tomotive ECUs, except for Telematic/Infotainment systems. It is assumed that Telem-

atic/Infotainment systems will continue to use proprietary OSs under the AUTOSAR

framework (e.g. Windows CE, VxWorks, QNX, etc.). In the case where AUTOSAR

components are needed to run on these proprietary OSs, the interfaces defined in this

document should be provided as an Operating System Abstraction Layer (OSAL).

This document uses the industry standard [2] (ISO 17356-3) as the basis for the

AUTOSAR OS. The reader should be familiar with this standard before reading this

document.

This document describes extensions to, and restrictions of [2].

15 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

2 Acronyms and Abbreviations

The glossary below includes acronyms and abbreviations relevant to the AUTOSAR

Operating System module that are not included in the [3, AUTOSAR glossary].

Abbreviation Description

API

Application Programming Interface

AUTOSAR

ARTI

AUTOSAR Run-time interface

BSW Basic Software

BSWMD Basic Software Module Description

CDD Complex Driver

COM Communication

ECC Extended Conformance Class

ECU Electronic Control Unit

HW Hardware

Identifier

IOC Inter OS-Application communicator

ISR

Interrupt Service Routine

A locatable entity is a distinct piece of software that has the same effect

regardless of which core it is located.

MC Multi-Core

MCU

Microcontroller Unit

ME Mutual exclusion

MPU Memory Protection Unit

NMI Non maskable interrupt

OIL OSEK Implementation Language

OS Operating System

OSEK/VDX Offene Systeme und deren Schnittstellen für die Elektronik im Kraftfahrzeug

RTE Run-Time Environment

RTOS Real Time Operating System

SC Single-Core

SLA Software Layered Architecture

SW Software

SWC Software Component

SWFRT Software FreeRunningTimer

2.1 Glossary of Terms

Term

Definition

Access Right

An indication that an object (e.g. Task, ISR, hook function) of an OS-Application has the permission

of access or manipulation with respect to memory, OS services or (set of) OS objects.

Cardinality The number of items in a set.

Counter

An operating system object that registers a count in ticks. There are two types of counters:

16 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Term

Definition

Hardware

Counter

A Counter that is advanced by hardware (e.g. timer). The count value is

maintained by the peripheral "in hardware".

Software

Counter

A Counter which is incremented by making the IncrementCounter API call

(see [SWS_Os_00399]). The count value is maintained by the operating system

"in software".

Deadline

The time at which a Task/Category 2 ISR must reach a certain point during its execution defined by

system design relative to the stimulus that triggered activation. See figure 2.1

Delay

The number of ticks between two adjacent expiry points on a ScheduleTable.

A pair of expiry points X and Y are said to be adjacent when:

• There is no expiry point Z such that X.Offset < Z.Offset < Y.Offset. In this case the Delay =

Y.Offset-X.Offset

• X and Y are the Final Expiry Point and the Initial Expiry Point respectively. In this case Delay

= (Duration-X.Offset)+Y.Offset

When used in the text, Delay is a relative number of ticks measured from a specified expiry point.

For example: X.Delay is the delay from X to the next expiry point.

Deviation

The minimum number of ticks between the current position on an explicitly synchronized

ScheduleTable and the value of the synchronization count modulo the duration of the

ScheduleTable.

Duration

The number of ticks from a notional zero at which a ScheduleTable wraps.

Execution Time Tasks: The net time a Task spends in the RUNNING state without entering the SUSPENDED or

WAITING state excluding all preemptions due to ISRs which preempt the Task. An extended Task

executing the WaitEvent API call to wait on an Event which is already set notionally enters the

WAITING state. For multiple activated basic Tasks the net time is per activation of a Task.

ISRs: The net time from the first to the last instruction of the user provided Category 2 interrupt

handler excluding all preemptions due to higher priority ISRs executing in preference.

Execution time includes the time spent in the error, pretask and posttask hooks and the time spent

making OS service calls.

Execution Budget

Maximum permitted execution time for a Task/ISR.

The offset on a ScheduleTable, measured from zero, at which the OS activates Tasks and/or

sets Events.

Initial Expiry

Point

The expiry point with the smallest offset

Expiry Point

Final Expiry

Point

The expiry point with the largest offset

A Hook function is implemented by the user and invoked by the operating system in the case of

certain incidents. In order to react to these on system or application level, there are two kinds of

hook functions

Application-

specific

Hook functions within the scope of an individual OS-Application.

Hook Function

System-specific Hook functions within the scope of the complete system (in general provided by

the integrator).

Initial Offset The smallest expiry point offset on a ScheduleTable. This can be zero.

Interarrival Time

Basic Tasks: The time between successively entering the READY state from the SUSPENDED state.

Activation of a Task always represents a new arrival. This applies in the case of multiple activations,

even if an existing instance of the Task is in the RUNNING or READY state.

Extended Tasks: The time between successively entering the READY state from the SUSPENDED or

WAITING states. Setting an Event for a Task in the WAITING state represents a new arrival if the

Task is waiting on the Event. Waiting for an Event in the RUNNING state which is already set

represents a new arrival.

ISRs: The time between successive occurrences of an interrupt.

See figure 2.1

Interrupt Lock Time

The time for which a Task/ISR executes with Category 1 interrupts disabled/suspended and/or

Category 2 interrupts disabled/suspended .

Interrupt Source Enable The switch which enables a specific interrupt source in the hardware.

17 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Term

Definition

Interrupt Vector Table

Conceptually, the interrupt vector table contains the mapping from hardware interrupt requests to

(software) interrupt service routines. The real content of the Interrupt Vector Table is very hardware

specific, e.g. it can contain the start addresses of the interrupt service routines.

Final Delay

The difference between the Final Expiry Point offset and the duration on a ScheduleTable in ticks.

This value defines the delay from the Final Expiry Point to the logical end of the ScheduleTable

for single-shot and "nexted" ScheduleTables.

Forced OS-Application

Termination

The operating system frees all system objects, e.g. forcibly terminates Tasks, disables interrupts,

etc., which are associated to the OS-Application. OS-Application and internal variables are

potentially left in an undefined state.

Forced Termination

The OS terminates the Task/Category 2 ISR and does "unlock" it’s held resources. For details see

[SWS_Os_00108] and [SWS_Os_00109].

Linker File

File containing linking settings for the linker. The syntax of the linker file depends on the specific

linker and, consequently, definitions are stored "linker-specific" in the linker file.

Lock Budget Maximum permitted Interrupt Lock Time or Resource Lock Time.

Master core

A master core is a core from which the AUTOSAR system is bootstrapped.

Memory Protection Unit

A Memory Protection Unit (MPU) enables memory partitioning with individual protection attributes.

This is distinct from a Memory Management Unit (MMU) that provides a mapping between virtual

addresses and physical memory locations at runtime.

Note that some devices may realize the functionality of an MPU in an MMU.

Describes the permissions available on a processor.

Privileged In general, in "privileged mode" unrestricted access is available to memory as

well as the underlying hardware.

Mode

Non-privileged In "non-privileged mode" access is restricted.

Modulus

The number of ticks required to complete a full wrap of an OSEK Counter. This is equal to

OsCounterMaxAllowedValue +1 ticks of the Counter.

A collection of OS objects

Trusted

An OS-Application that may be executed in privileged mode and may have

unrestricted access to the API and hardware resources. Only trusted

applications can provide trusted functions.

OS-Application

Non-trusted

An OS-Application that is executed in non-privileged mode has restricted access

to the API and hardware resources.

OS object Object that belongs to a single OS-Application: Task, ISR, Alarm, Event, ScheduleTable,

Resource, Trustedfunction, Counter, application-specific hook.

OS Service OS services are the API of the operating system.

Systematic error in the software of an OS-Application.

Memory access

violation

A protection error caused by access to an address in a manner for which no

access right exists.

Timing fault

A protection error that violates the timing protection.

Illegal service A protection error that violates the service protection, e.g. unauthorized call to

OS service.

Protection Error

Hardware

exception

division by zero, illegal instruction etc.

Resource Lock Time

The time an OSEK Resource is held by a Task/ISR (excluding the preemptions of the Task/ISR

by higher prior Tasks/ISRs).

Response Time

The time between a Task/ISR being made ready to execute and generating a specified response.

The time includes all preemptions. See figure 2.1

Restart an

OS-Application

An OS-Application can be restarted after self-termination or being forcibly terminated because of a

protection error. When an OS-Application is restarted, the OS activates the configured

OsRestartTask.

Scalability Class The features of the OS (e.g. Memory Protection or Timing Protection), described by this document,

can be grouped together to customize the operating system to the needs of the application. There

are 4 defined groups of features which are named scalability classes. For details see Chapter 7.11

18 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Term

Definition

ScheduleTable

Encapsulation of a statically defined set of expiry points.

Par t of an object file in which instructions or data are combined to form a unit (contiguous address

space in memory allocated for data or code). A section in an object file (object file format) has a

name and a size.

From the linker perspective, two different sides can be distinguished:

Input section

memory section in an input object file of the linker.

Section

Output section memory section in an output object file of the linker.

Set (of OS objects) This document uses the term set, indicating a collection of the same type of OS objects, in the strict

mathematical sense, i.e.:

- a set contains zero or more OS objects (this means a set can be empty)

- the OS objects in the set are unique (this means there cannot be duplicate OS objects in the set)

Spinlock A spinlock is a locking mechanism where the Task waits in a loop (spins) repeatedly checking for a

shared variable to become a certain value.

The value indicates whether the lock is free or not. In Multi-Core systems the comparison and

changing of the variable typically requires an atomic operation.

As the Task remains active but is not doing anything useful, a spinlock is a busy waiting mechanism

Spinlock variable A spinlock variable is a shared variable used by a spinlock to indicate whether a spinlock is free or

occupied.

Address label that can be imported/used by software modules and resolved by the linker. The

precise syntax of the labels is linker-specific. Here, these address labels are used to identify the

start and end of memory sections.

Start symbol Tags the start of a memory section

Symbol

End symbol

Tags the end of a memory section

Synchronization of

ScheduleTables with

a synchronization

Counter

Synchronization with a synchronization Counter is achieved, if the expiry points of the

ScheduleTable are processed within an absolute deviation from the synchronization Counter

that is smaller than or equal to a precision threshold.

Synchronization

Counter

The "Synchronization Counter", distinct from an OS Counter object, is an external Counter,

external to the OS, against which expiry points of a ScheduleTable are synchronized

A Task is the object which executes (user) code and which is managed by the OS. E.g. the OS

switches between different Tasks (schedules). There are 2 types of Tasks; for more details see [2].

Basic Task

A Task which cannot block by itself. This means that it cannot wait for (OS)

Event(s).

Task

Extended Task

A Task which can block by itself and wait for (OS) Event(s).

Time Frame

The minimum inter-arrival time for a Task/ISR.

Trustedfunction

A service provided by a trusted OS-Application that can be used by other OS-Applications (trusted

or non-trusted).

Worst case execution

time (WCET)

The longest possible execution time.

Write access

Storing a value in a register or memory location. All memory accesses that have the consequence

of writing (e.g. reads that have the side effect of writing to a memory location) are treated as write

accesses.

19 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Figure 2.1: Definition of Timing Terminology

20 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

3 Related documentation

3.1 Input documents & related standards and norms

[1] Requirements on Operating System

AUTOSAR_SRS_OS

[2] ISO 17356-3: Road vehicles – Open interface for embedded automotive applica-

tions – Part 3: OSEK/VDX Operating System (OS)

[3] Glossary

AUTOSAR_TR_Glossary

[4] General Specification of Basic Software Modules

AUTOSAR_SWS_BSWGeneral

[5] Virtual Functional Bus

AUTOSAR_EXP_VFB

[6] General Requirements on Basic Software Modules

AUTOSAR_SRS_BSWGeneral

[7] Requirements on Free Running Timer

AUTOSAR_SRS_FreeRunningTimer

[8] ISO 17356-6: Road vehicles – Open interface for embedded automotive applica-

tions – Part 6: OSEK/VDX Implementation Language (OIL)

[9] Specification of AUTOSAR Run-Time Interface

AUTOSAR_SWS_ClassicPlatformARTI

[10] Specification of RTE Software

AUTOSAR_SWS_RTE

[11] Software Component Template

AUTOSAR_TPS_SoftwareComponentTemplate

[12] Specification of Memory Mapping

AUTOSAR_SWS_MemoryMapping

3.2 Related specification

AUTOSAR provides a General Specification on Basic Software Modules [4, SWS BSW

General], which is also valid for AUTOSAR Operating System.

Thus, the specification [4, SWS BSW General] shall be considered as additional and

required specification for AUTOSAR Operating System.

All OSEK OS related types, defines and functions can be found in [2]

21 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

4 Constraints and assumptions

4.1 Existing Standards

This document makes the following assumptions about the referenced related stan-

dards and norms:

• [2] provides a sufficiently flexible scheduling policy to schedule AUTOSAR sys-

tems.

• [2] is a mature specification and implementations are used in millions of ECUs

worldwide.

• [2] does not provide enough support for isolating multi-source software compo-

nents at runtime.

• [2] does not provide enough runtime support for demonstrating the absence of

some classes of fault propagation in a safety-case.

4.2 Terminology

The specification uses the following operators when requirements specify multiple

terms:

• NOT : negation of a single term e.g. NOT Weekend

• AND : conjunction of two terms e.g. Weekend AND Saturday

• OR : disjunction of two terms e.g. Monday OR Tuesday

A requirement comprising multiple terms is evaluated left to right. The precedence

rules are:

• Highest Precedence NOT

• Lowest Precedence AND OR

The expression NOT X AND Y means (NOT X) AND (Y)

Where operators of the same precedence are used in the same sentence, commas are

used to disambiguate. The expression X AND Y, OR Z means (X AND Y) OR Z.

4.3 Interaction with the RTE

The configuration of an AUTOSAR system [5] maps the runnables of a software compo-

nent to (one or more) Tasks that are scheduled by the operating system. All runnables

in a Task share the same protection boundary. In AUTOSAR, a software component

22 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

must not include an interrupt handler. A software component is therefore implemented

as runnables executing within the body of a Task, or set of Tasks, only.

Runnables get access to hardware-sourced data through the AUTOSAR RTE. The RTE

provides the runtime interface between runnables and the basic software modules. The

basic software modules also comprise a number of Tasks and ISRs that are scheduled

by the operating system.

It is assumed that the software component templates and the description of the basic

software modules provide sufficient information about the required runtime behavior to

be able to specify the attributes of Tasks required to configure the OS.

4.4 Operating System Abstraction Layer (OSAL)

Systems that do not use the OS defined in AUTOSAR can provide a platform for the

execution of AUTOSAR software components using an Operating System Abstraction

Layer. The interface to the OSAL is exactly that defined for the AUTOSAR OS.

4.5 Multi-Core Hardware assumptions

There are currently several existing and suggested HW-architectures

for Multi-Core

microprocessors. There is considerable variation in the features offered by these ar-

chitectures. Therefore this section attempts to capture a common set of architectural

features required for Multi-Core.

Hardware assumptions shall remain assumptions and shall not become official

AUTOSAR requirements.

4.5.1 CPU Core features

1. More than one core on the same piece of silicon.

2. The HW offers a method that can be used by the SW to identify a core.

3. The hardware supports atomic read and atomic write operations for a fixed word

length depending on the hardware.

4. The hardware supports some atomic Test-And-Set functionality or similar func-

tionalities that can be used to build a critical section shared between cores. Ad-

ditional atomic operations may exist.

In this context "architecture" encompasses: the connections between cores and memory, and to

peripherals and how interrupts work.

23 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

5. The cores may have the same instruction set; at least a common basic instr uction

set is available on all cores. Core specific add-ons may exist, but they are not

considered.

6. The cores have the same data representation. For example, the same size of

integer, same byte and bit order, etc.

7. If per-core caches exist, AUTOSAR requires support for RAM - cache coherency

in HW or in SW. In software means that the cache-controller can be programmed

by the SW in a way that it invalidates cache lines or excludes certain memory

regions from caching.

8. In case of an exception (such as an illegal memory reference or divide by zero)

the exception occurs on the core that introduced the exception.

9. For notification purposes, it is possible to trigger an interrupt/trap on any core.

4.5.2 Memory features

• Shared RAM is available to all cores; at least all cores can share a substantial

part of the memory.

• Flash shall be shared between all cores at least. However, performance can be

improved if Flash/RAM can be partitioned so that there are separate pathways

from cores to Flash.

• A single address space is assumed, at least in the shared parts of the memory

address space.

• The AUTOSAR Multi-Core architecture shall be capable to run on systems that

do and do not support memory protection. If memory protection exists, all cores

are covered by a hardware-based memory protection.

4.5.3 Multi-Core Limitations

• In AUTOSAR R4.0, it is not supported to activate additional cores under control

of AUTOSAR after the Operating System was started.

• The scheduling algorithm does not assign Tasks dynamically to cores.

• The AUTOSAR OS Resource algorithm is not supported across cores. Re-

sources can be used locally, between Tasks that are bound to the same core

but not between Tasks/ISRs which are bound to different cores.

24 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

4.6 Limitations

4.6.1 Hardware

The core AUTOSAR operating system assumes free access to hardware resources,

which are managed by the OS itself. This includes, but is not limited to, the following

hardware:

• interrupt control registers

• processor status words

• stack pointer(s)

Specific (extended) features of the core operating system extend the requirements on

hardware resource. The following list outlines the features that have requirements on

the hardware. Systems that do not use these OS features do not have these hardware

requirements.

• Memory Protection: A hardware memory protection unit is required. All memory

accesses that have the consequence of writing (e.g. reads that have the side

effect of writing to a memory location) shall be treated as writes.

• Time Protection: Timer Hardware for monitoring execution times and arrival rates.

• Privileged and non-privileged modes on the MCU: to protect the OS against in-

ternal corruption caused by writes to OS controlled registers. This mode must

not allow OS-Applications to circumvent protection (e.g. write registers which

govern memory protection, write to processor status word etc.). The privileged

mode must be under full control of the protected OS which uses the mode inter-

nally and to transfer control back and forth from a non-trusted OS-Application to

a trusted OS-Application. The microprocessor must support a controlled means

which moves a processor into this privileged mode.

• Local/Global Time Synchronization: A global time source is needed.

In general hardware failures in the processor are not detected by the operating system.

In the event of hardware failure, correct operation of the OS cannot be guaranteed.

The resources managed by a specific OS implementation have to be defined within the

appropriate configuration file of the OS.

4.6.2 Programming Language

The API of the operating system is defined as C function calls or macros. If other

languages are used, they must adapt to the C interface.

25 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

4.6.3 Miscellaneous

The operating system does not provide services for dynamic memory management.

4.7 Applicability to car domains

The operating system has the same design constraints regarding size and scalability

under which [2] was designed. The immediate domain of applicability is therefore

currently body, chassis and power train ECUs. However, there is no reason that the

OS cannot be used to implement ECUs for infotainment applications.

26 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

5 Dependencies to other modules

There are no forced dependencies on other modules, however:

• It is assumed that the operating system may use timer units directly to drive coun-

ters.

• If the user needs to drive scheduling directly from global time, then a global time

interrupt is required.

• If the user needs to synchronize the processing of a ScheduleTable to a global

time, the operating system needs to be told the global time using the Sync-

ScheduleTable service.

• The IOC described in this document provides communication between OS-

Applications. The IOC generation is based on configuration information which

is generated by the RTE generator. On the other hand the RTE uses functions

generated by the IOC to transmit data.

5.1 File structure

5.1.1 Code file structure

The code file structure of the Operating System module is not fixed, besides the re-

quirements in the [6, General SRS].

5.1.2 Header file structure

The IOC generator generates an additional header file Ioc.h. Users of the Ioc.h shall

include the Ioc.h file. If an implementation of the IOC requires additional header files, it

is free to include them. The header files are self-contained, that means they will include

all other header files, which they require.

5.1.3 ARTI File Structure

To support ARTI based debugging and tracing, all source files of the OS module with

ARTI hook macros shall include an "Os_Arti.h" file. This file (along with the corre-

sponding Arti.h and Arti.c file) will be provided by the ARTI hook implementer, i.e. the

tracing tool. When building the final executable, the linker will pull in the compiled Arti.c

file, too.

The usage of the ARTI hook macros is configurable. If the OS is configured to not use

ARTI, the inclusion of "Os_Arti.h" may be omitted, and the ARTI hooks macros may be

expanded to empty macros (nothing).

27 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

6 Requirements Tracing

The following tables reference the requirements specified in [6, SRS BSW General], [7,

SRS FreeRunningTimer] and [1, SRS OS] and links to the fulfillment of these. Please

note that if column “Satisfied by” is empty for a specific requirement this means that

this requirement is not fulfilled by this document.

Requirement Description Satisfied by

[RS_ARTIFO_-

00014]

ARTI Hooks shall be

implemented with minimal

intrusion

[SWS_Os_00836] [SWS_Os_00837]

[RS_ARTIFO_-

00015]

ARTI Hooks shall follow a fixed

format

[SWS_Os_00839] [SWS_Os_00841]

[SWS_Os_00842] [SWS_Os_00844]

[SWS_Os_00846] [SWS_Os_00857]

[RS_Arti_00029] AUTOSAR shall support

recording timing events of

application states

[SWS_Os_00838]

[RS_Arti_00030] AUTOSAR shall support

recording timing events of tasks

[SWS_Os_00840]

[RS_Arti_00031] AUTOSAR shall support

recording timing events of

category 2 interrupt states

[SWS_Os_00849]

[RS_Arti_00032] AUTOSAR shall support

recording timing events of

service calls

[SWS_Os_00843]

[RS_Arti_00033] AUTOSAR shall support

recording timing events of

spinlock states

[SWS_Os_00845]

[RS_Arti_00034] AUTOSAR shall support

recording timing events of

protection hooks

[SWS_Os_00856] [SWS_Os_00857]

[SRS_BSW_00003] All software modules shall

provide version and identification

information

[SWS_Os_NA_00767]

[SRS_BSW_00005] Modules of the µC Abstraction

Layer (MCAL) may not have

hard coded horizontal interfaces

[SWS_Os_NA_00767]

[SRS_BSW_00006] The source code of software

modules above the µC

Abstraction Layer (MCAL) shall

not be processor and compiler

dependent.

[SWS_Os_NA_00767]

[SRS_BSW_00007] All Basic SW Modules written in

C language shall conform to the

MISRA C 2012 Standard.

[SWS_Os_NA_00767]

[SRS_BSW_00009] All Basic SW Modules shall be

documented according to a

common standard.

[SWS_Os_NA_00767]

[SRS_BSW_00010] The memory consumption of all

Basic SW Modules shall be

documented for a defined

configuration for all supported

platforms.

[SWS_Os_NA_00767]

28 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Requirement Description Satisfied by

[SRS_BSW_00161] The AUTOSAR Basic Software

shall provide a microcontroller

abstraction layer which provides

a standardized interface to

higher software layers

[SWS_Os_NA_00767]

[SRS_BSW_00162] The AUTOSAR Basic Software

shall provide a hardware

abstraction layer

[SWS_Os_NA_00767]

[SRS_BSW_00168] SW components shall be tested

by a function defined in a

common API in the Basis-SW

[SWS_Os_NA_00767]

[SRS_BSW_00170] The AUTOSAR SW Components

shall provide information about

their dependency from faults,

signal qualities, driver demands

[SWS_Os_NA_00767]

[SRS_BSW_00172] The scheduling strategy that is

built inside the Basic Software

Modules shall be compatible

with the strategy used in the

system

[SWS_Os_NA_00767]

[SRS_BSW_00301] All AUTOSAR Basic Software

Modules shall only import the

necessary information

[SWS_Os_NA_00767]

[SRS_BSW_00302] All AUTOSAR Basic Software

Modules shall only export

information needed by other

modules

[SWS_Os_NA_00767]

[SRS_BSW_00305] Data types naming convention [SWS_Os_NA_00767]

[SRS_BSW_00306] AUTOSAR Basic Software

Modules shall be compiler and

platform independent

[SWS_Os_NA_00767]

[SRS_BSW_00307] Global variables naming

convention

[SWS_Os_NA_00767]

[SRS_BSW_00308] AUTOSAR Basic Software

Modules shall not define global

data in their header files, but in

the C file

[SWS_Os_NA_00767]

[SRS_BSW_00309] All AUTOSAR Basic Software

Modules shall indicate all global

data with read-only purposes by

explicitly assigning the const

keyword

[SWS_Os_NA_00767]

[SRS_BSW_00310] API naming convention [SWS_Os_NA_00767]

[SRS_BSW_00312] Shared code shall be reentrant [SWS_Os_NA_00767]

[SRS_BSW_00314] All internal driver modules shall

separate the interrupt frame

definition from the service

routine

[SWS_Os_NA_00767]

[SRS_BSW_00318] Each AUTOSAR Basic Software

Module file shall provide version

numbers in the header file

[SWS_Os_NA_00767]

29 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Requirement Description Satisfied by

[SRS_BSW_00321] The version numbers of

AUTOSAR Basic Software

Modules shall be enumerated

according specific rules

[SWS_Os_NA_00767]

[SRS_BSW_00325] The runtime of interrupt service

routines and functions that are

running in interrupt context shall

be kept short

[SWS_Os_NA_00767]

[SRS_BSW_00327] Error values naming convention [SWS_Os_NA_00767]

[SRS_BSW_00328] All AUTOSAR Basic Software

Modules shall avoid the

duplication of code

[SWS_Os_NA_00767]

[SRS_BSW_00330] It shall be allowed to use macros

instead of functions where

source code is used and runtime

is critical

[SWS_Os_NA_00767]

[SRS_BSW_00331] All Basic Software Modules shall

strictly separate error and status

information

[SWS_Os_NA_00767]

[SRS_BSW_00333] For each callback function it

shall be specified if it is called

from interrupt context or not

[SWS_Os_NA_00767]

[SRS_BSW_00334] All Basic Software Modules shall

provide an XML file that contains

the meta data

[SWS_Os_NA_00767]

[SRS_BSW_00335] Status values naming

convention

[SWS_Os_NA_00767]

[SRS_BSW_00336] Basic SW module shall be able

to shutdown

[SWS_Os_00001] [SWS_Os_00713]

[SRS_BSW_00337] Classification of development

errors

[SWS_Os_NA_00767]

[SRS_BSW_00339] Reporting of production relevant

error status

[SWS_Os_NA_00767]

[SRS_BSW_00342] It shall be possible to create an

AUTOSAR ECU out of modules

provided as source code and

modules provided as object

code, even mixed

[SWS_Os_NA_00767]

[SRS_BSW_00343] The unit of time for specification

and configuration of Basic SW

modules shall be preferably in

physical time unit

[SWS_Os_NA_00767]

[SRS_BSW_00344] BSW Modules shall support

link-time configuration

[SWS_Os_NA_00767]

[SRS_BSW_00345] BSW Modules shall support

pre-compile configuration

[SWS_Os_00001]

[SRS_BSW_00347] A Naming seperation of different

instances of BSW drivers shall

be in place

[SWS_Os_NA_00767]

[SRS_BSW_00350] All AUTOSAR Basic Software

Modules shall allow the

enabling/disabling of detection

and reporting of development

errors.

[SWS_Os_NA_00767]

30 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Requirement Description Satisfied by

[SRS_BSW_00351] Encapsulation of compiler

specific methods to map objects

[SWS_Os_00815]

[SRS_BSW_00357] For success/failure of an API call

a standard return type shall be

defined

[SWS_Os_NA_00767]

[SRS_BSW_00358] The return type of init() functions

implemented by AUTOSAR

Basic Software Modules shall be

void

[SWS_Os_NA_00767]

[SRS_BSW_00369] All AUTOSAR Basic Software

Modules shall not return specific

development error codes via the

API

[SWS_Os_NA_00767]

[SRS_BSW_00373] The main processing function of

each AUTOSAR Basic Software

Module shall be named

according the defined

convention

[SWS_Os_NA_00767]

[SRS_BSW_00374] All Basic Software Modules shall

provide a readable module

vendor identification

[SWS_Os_NA_00767]

[SRS_BSW_00375] Basic Software Modules shall

report wake-up reasons

[SWS_Os_NA_00767]

[SRS_BSW_00377] A Basic Software Module can

return a module specific types

[SWS_Os_NA_00767]

[SRS_BSW_00378] AUTOSAR shall provide a

boolean type

[SWS_Os_NA_00767]

[SRS_BSW_00379] All software modules shall

provide a module identifier in the

header file and in the module

XML description file.

[SWS_Os_NA_00767]

[SRS_BSW_00383] The Basic Software Module

specifications shall specify

which other configuration files

from other modules they use at

least in the description

[SWS_Os_NA_00767]

[SRS_BSW_00384] The Basic Software Module

specifications shall specify at

least in the description which

other modules they require

[SWS_Os_NA_00767]

[SRS_BSW_00385] List possible error notifications [SWS_Os_NA_00767]

[SRS_BSW_00386] The BSW shall specify the

configuration and conditions for

detecting an error

[SWS_Os_NA_00767]

[SRS_BSW_00388] Containers shall be used to

group configuration parameters

that are defined for the same

object

[SWS_Os_NA_00767]

[SRS_BSW_00389] Containers shall have names [SWS_Os_NA_00767]

[SRS_BSW_00390] Parameter content shall be

unique within the module

[SWS_Os_NA_00767]

[SRS_BSW_00392] Parameters shall have a type [SWS_Os_NA_00767]

[SRS_BSW_00393] Parameters shall have a range [SWS_Os_NA_00767]

31 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Requirement Description Satisfied by

[SRS_BSW_00394] The Basic Software Module

specifications shall specify the

scope of the configuration

parameters

[SWS_Os_NA_00767]

[SRS_BSW_00395] The Basic Software Module

specifications shall list all

configuration parameter

dependencies

[SWS_Os_NA_00767]

[SRS_BSW_00396] The Basic Software Module

specifications shall specify the

supported configuration classes

for changing values and

multiplicities for each parameter/

container

[SWS_Os_NA_00767]

[SRS_BSW_00399] Parameter-sets shall be located

in a separate segment and shall

be loaded after the code

[SWS_Os_NA_00767]

[SRS_BSW_00401] Documentation of multiple

instances of configuration

parameters shall be available

[SWS_Os_NA_00767]

[SRS_BSW_00403] The Basic Software Module

specifications shall specify for

each parameter/container

whether it supports different

values or multiplicity in different

configuration sets

[SWS_Os_NA_00767]

[SRS_BSW_00404] BSW Modules shall support

post-build configuration

[SWS_Os_NA_00767]

[SRS_BSW_00405] BSW Modules shall support

multiple configuration sets

[SWS_Os_NA_00767]

[SRS_BSW_00406] A static status variable denoting

if a BSW module is initialized

shall be initialized with value 0

before any APIs of the BSW

module is called

[SWS_Os_NA_00767]

[SRS_BSW_00407] Each BSW module shall provide

a function to read out the version

information of a dedicated

module implementation

[SWS_Os_NA_00767]

[SRS_BSW_00409] All production code error ID

symbols are defined by the Dem

module and shall be retrieved by

the other BSW modules from

Dem configuration

[SWS_Os_NA_00767]

[SRS_BSW_00410] Compiler switches shall have

defined values

[SWS_Os_NA_00767]

[SRS_BSW_00411] All AUTOSAR Basic Software

Modules shall apply a naming

rule for enabling/disabling the

existence of the API

[SWS_Os_NA_00767]

[SRS_BSW_00413] An index-based accessing of the

instances of BSW modules shall

be done

[SWS_Os_NA_00767]

32 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Requirement Description Satisfied by

[SRS_BSW_00414] Init functions shall have a pointer

to a configuration structure as

single parameter

[SWS_Os_NA_00767]

[SRS_BSW_00415] Interfaces which are provided

exclusively for one module shall

be separated into a dedicated

header file

[SWS_Os_NA_00767]

[SRS_BSW_00416] The sequence of modules to be

initialized shall be configurable

[SWS_Os_NA_00767]

[SRS_BSW_00417] Software which is not part of the

SW-C shall report error events

only after the Dem is fully

operational.

[SWS_Os_NA_00767]

[SRS_BSW_00419] If a pre-compile time

configuration parameter is

implemented as const it should

be placed into a separate c-file

[SWS_Os_NA_00767]

[SRS_BSW_00422] Pre-de-bouncing of error status

information is done within the

Dem

[SWS_Os_NA_00767]

[SRS_BSW_00423] BSW modules with AUTOSAR

interfaces shall be describable

with the means of the SW-C

Template

[SWS_Os_NA_00767]

[SRS_BSW_00425] The BSW module description

template shall provide means to

model the defined trigger

conditions of schedulable

objects

[SWS_Os_NA_00767]

[SRS_BSW_00432] Modules should have separate

main processing functions for

read/receive and write/transmit

data path

[SWS_Os_NA_00767]

[SRS_BSW_00437] Memory mapping shall provide

the possibility to define RAM

segments which are not to be

initialized during startup

[SWS_Os_NA_00767]

[SRS_BSW_00439] Enable BSW modules to handle

interrupts

[SWS_Os_NA_00767]

[SRS_BSW_00440] The callback function invocation

by the BSW module shall follow

the signature provided by RTE to

invoke servers via Rte_Call

API

[SWS_Os_NA_00767]

[SRS_BSW_00441] Naming convention for type,

macro and function

[SWS_Os_NA_00767]

[SRS_BSW_00448] Module SWS shall not contain

requirements from other

modules

[SWS_Os_NA_00767]

[SRS_BSW_00449] BSW Service APIs used by

Autosar Application Software

shall return a Std_ReturnType

[SWS_Os_NA_00767]

[SRS_BSW_00452] Classification of runtime errors [SWS_Os_NA_00767]

33 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Requirement Description Satisfied by

[SRS_BSW_00453] BSW Modules shall be

harmonized

[SWS_Os_NA_00767]

[SRS_BSW_00454] An alternative interface without a

parameter of category DATA_

REFERENCE shall be available.

[SWS_Os_NA_00767]

[SRS_BSW_00456] A Header file shall be defined in

order to harmonize BSW

Modules

[SWS_Os_NA_00767]

[SRS_BSW_00457] Callback functions of Application

software components shall be

invoked by the Basis SW

[SWS_Os_NA_00767]

[SRS_BSW_00458] Classification of production

errors

[SWS_Os_NA_00767]

[SRS_BSW_00459] It shall be possible to

concurrently execute a service

offered by a BSW module in

different partitions

[SWS_Os_00589]

[SRS_BSW_00461] Modules called by generic

modules shall satisfy all

interfaces requested by the

generic module

[SWS_Os_NA_00767]

[SRS_BSW_00462] All Standardized Autosar

Interfaces shall have unique

requirement Id / number

[SWS_Os_NA_00767]

[SRS_BSW_00466] Classification of extended

production errors

[SWS_Os_NA_00767]

[SRS_BSW_00469] Fault detection and healing of

production errors and extended

production errors

[SWS_Os_NA_00767]

[SRS_BSW_00470] Execution frequency of

production error detection

[SWS_Os_NA_00767]

[SRS_BSW_00471] Do not cause dead-locks on

detection of production errors -

the ability to heal from previously

detected production errors

[SWS_Os_NA_00767]

[SRS_BSW_00472] Avoid detection of two

production errors with the same

root cause.

[SWS_Os_NA_00767]

[SRS_BSW_00473] Classification of transient faults [SWS_Os_NA_00767]

[SRS_BSW_00478] Timing limits of main functions [SWS_Os_NA_00767]

[SRS_BSW_00479] Interfaces for handling request

from external devices

[SWS_Os_NA_00767]

[SRS_BSW_00480] Null pointer errors shall follow a

naming rule

[SWS_Os_91025]

[SRS_BSW_00481] Invalid configuration set

selection errors shall follow a

naming rule

[SWS_Os_NA_00767]

[SRS_BSW_00482] Get version information function

shall follow a naming rule

[SWS_Os_NA_00767]

[SRS_BSW_00483] BSW Modules shall handle

buffer alignments internally

[SWS_Os_NA_00767]

[SRS_BSW_00484] Input parameters of scalar and

enum types shall be passed as a

value.

[SWS_Os_NA_00767]

34 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Requirement Description Satisfied by

[SRS_BSW_00485] Input parameters of structure

type shall be passed as a

reference to a constant structure

[SWS_Os_NA_00767]

[SRS_BSW_00486] Input parameters of array type

shall be passed as a reference

to the constant array base type

[SWS_Os_NA_00767]

[SRS_BSW_00487] Errors for module initialization

shall follow a naming rule

[SWS_Os_NA_00767]

[SRS_BSW_00490] List possible security events [SWS_Os_NA_00767]

[SRS_BSW_00492] Reporting of security events

during startup

[SWS_Os_NA_00767]

[SRS_BSW_00494] ServiceInterface argument with

a pointer datatype

[SWS_Os_NA_00767]

[SRS_Frt_00020] The configuration and

initialization shall be performed

by the module providing the

SWFRT functionality (OS) if the

GPT Timer is not used .

[SWS_Os_00374]

[SRS_Frt_00022] It shall be possible to state

which HW Timer is used

[SWS_Os_00370]

[SRS_Frt_00025] Access methods to time

information shall be provided for

different users.

[SWS_Os_00383] [SWS_Os_00392]

[SRS_Frt_00030] The read - out value shall start

with Zero

[SWS_Os_00384]

[SRS_Frt_00031] The SWFRT shall increment i.e.

Consecutive read out values will

increase - unless the defined

range of the SWFRT was

exceeded

[SWS_Os_00384]

[SRS_Frt_00032] Wrap around shall work without

software interaction.

[SWS_Os_NA_00767]

[SRS_Frt_00033] There shall be a function to

achieve an atomic read the of

the timer’s value.

[SWS_Os_00377]

[SRS_Frt_00034] The module shall provide

functionality to calculate the ticks

elapsed between a previously

stored value (passed as a

parameter) and the current timer

value.

[SWS_Os_00382]

[SRS_Frt_00047] The SWFRT shall provide a

"user" dependent API (function /

macro) to convert ticks to time.

[SWS_Os_00393]

[SRS_Os_00097] The OS shall provide an API that

is backward compatible to the

API of OSEK OS

[SWS_Os_00001]

[SRS_Os_00098] The Operating System shall

provide statically configurable

schedule tables based on time

tables as an optional service

[SWS_Os_00002] [SWS_Os_00007]

35 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Requirement Description Satisfied by

[SRS_Os_00099] The Operating System shall

provide a mechanism which

allows switching between

different schedule tables

[SWS_Os_00191]

[SRS_Os_11000] The OS may offer support to

protect the memory sections of

an OS-Application against read

accesses by all other

OS-Applications

[SWS_Os_00026]

[SRS_Os_11001] The OS shall provide partitions

which allow for fault isolation

and fault recovery capabilities

[SWS_Os_00056]

[SRS_Os_11002] The operating system shall

provide the ability to synchronize

the processing of schedule

tables with a global system time

base

[SWS_Os_00013] [SWS_Os_00199]

[SWS_Os_00201] [SWS_Os_00206]

[SWS_Os_00227]

[SRS_Os_11003] The operating system shall be

able to monitor stack usage and

check for a stack overflow on a

per executable object basis

[SWS_Os_00067] [SWS_Os_00068]

[SRS_Os_11005] The operating system shall

prevent an OS-Application from

modifying the memory of other

OS-Applications

[SWS_Os_00195] [SWS_Os_00207]

[SWS_Os_00208] [SWS_Os_00795]

[SWS_Os_00806] [SWS_Os_00807]

[SWS_Os_91010] [SWS_Os_91011]

[SWS_Os_91012] [SWS_Os_91013]

[SWS_Os_91014] [SWS_Os_91015]

[SWS_Os_91016] [SWS_Os_91017]

[SWS_Os_91018]

[SRS_Os_11006] The operating system shall allow

tasks and ISRs within an

OS-Application to exchange

data

[SWS_Os_00086] [SWS_Os_00087]

[SWS_Os_00196]

[SRS_Os_11007] The operating system shall allow

OS-Applications to execute

shared code

[SWS_Os_00081]

[SRS_Os_11008] The OS shall not allow a timing

fault in any OS-Application to

propagate

[SWS_Os_00028] [SWS_Os_00033]

[SWS_Os_00037] [SWS_Os_00048]

[SWS_Os_00064] [SWS_Os_00089]

[SWS_Os_00465] [SWS_Os_00469]

[SWS_Os_00470] [SWS_Os_00471]

[SWS_Os_00472] [SWS_Os_00473]

[SWS_Os_00474]

[SRS_Os_11009] The operating system shall

prevent the corruption of the OS

by any call of a system service

[SWS_Os_00051] [SWS_Os_00052]

[SWS_Os_00069] [SWS_Os_00070]

[SWS_Os_00088] [SWS_Os_00092]

[SWS_Os_00093]

[SRS_Os_11010] The operating system shall

prevent an OS-Application

modifying OS objects that are

not owned by that

OS-Application

[SWS_Os_00056]

36 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Requirement Description Satisfied by

[SRS_Os_11011] The OS shall protect itself

against OS-Applications

attempting to modify control

registers directly which are

managed by the OS

[SWS_Os_00096] [SWS_Os_00245]

[SWS_Os_00808] [SWS_Os_00809]

[SWS_Os_00810] [SWS_Os_00811]

[SWS_Os_00812] [SWS_Os_00813]

[SWS_Os_00814] [SWS_Os_91019]

[SWS_Os_91020] [SWS_Os_91021]

[SRS_Os_11012] The OS shall provide scalability

for its protection features

[SWS_Os_00240] [SWS_Os_00241]

[SRS_Os_11013] The OS shall be capable of

notifying the occurrence of a

protection error at runtime

[SWS_Os_00033] [SWS_Os_00037]

[SWS_Os_00044] [SWS_Os_00051]

[SWS_Os_00056] [SWS_Os_00064]

[SWS_Os_00068] [SWS_Os_00070]

[SWS_Os_00088] [SWS_Os_00093]

[SWS_Os_00210] [SWS_Os_00246]

[SRS_Os_11014] In case of a protection error, the

OS shall provide an action for

recovery on OS-, OS-Application

and task/ISR-level

[SWS_Os_00033] [SWS_Os_00037]

[SWS_Os_00106] [SWS_Os_00107]

[SWS_Os_00108] [SWS_Os_00109]

[SWS_Os_00110] [SWS_Os_00243]

[SWS_Os_00244]

[SRS_Os_11016] The OS implementation shall

offer scalability which is

configurable by a generation tool

[SWS_Os_00240] [SWS_Os_00241]

[SRS_Os_11018] The OS shall provide interr upt

mask functions

[SWS_Os_00299]

[SRS_Os_11019] The AUTOSAR OS generation

tool shall create the interrupt

vector table

[SWS_Os_00336]

[SRS_Os_11020] The OS shall provide a standard

interface to tick a software

counter

[SWS_Os_00286]

[SRS_Os_11021] The OS shall provide a

mechanism to cascade multiple

software counters from a single

hardware counter.

[SWS_Os_00301]

[SRS_Os_11022] The OS shall provide a

mechanism to terminate

OS-Application

[SWS_Os_00258] [SWS_Os_00447]

[SRS_Os_11023] The OS shall provide a

mechanism by which a

terminated OS-Application can

be restarted

[SWS_Os_00258] [SWS_Os_00287]

[SWS_Os_00503] [SWS_Os_00555]

[SRS_Os_12001] The OS shall create an ARTI

module description file

[SWS_Os_00858]

[SRS_Os_12002] The OS code shall incorporate

ARTI hooks

[SWS_Os_00836] [SWS_Os_00837]

[SRS_Os_12003] ARTI module description file

shall support all ORTI containers

[SWS_Os_00829]

[SRS_Os_80001] The OS shall be able to manage

multiple closely coupled CPU

Cores

[SWS_Os_00568] [SWS_Os_00569]

[SWS_Os_00579] [SWS_Os_00583]

[SWS_Os_00596] [SWS_Os_00600]

[SWS_Os_00606] [SWS_Os_00616]

[SWS_Os_00627] [SWS_Os_00628]

[SWS_Os_00672] [SWS_Os_00673]

[SWS_Os_00674] [SWS_Os_00675]

37 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Requirement Description Satisfied by

[SRS_Os_80003] The multi core extension shall

provide the same degree of

predictability as the single core

[SWS_Os_00570] [SWS_Os_00571]

[SWS_Os_00573]

[SRS_Os_80005] OsApplications and as a result

TASKS and OsISRs shall be

assigned statically to cores

[SWS_Os_00570] [SWS_Os_00571]

[SWS_Os_00572] [SWS_Os_00573]

[SWS_Os_00667] [SWS_Os_00826]

[SRS_Os_80006] Initialization/Start-up of the

system shall be synchronized

[SWS_Os_00572] [SWS_Os_00574]

[SWS_Os_00575] [SWS_Os_00576]

[SWS_Os_00577] [SWS_Os_00578]

[SWS_Os_00579] [SWS_Os_00580]

[SWS_Os_00581] [SWS_Os_00582]

[SWS_Os_00607] [SWS_Os_00608]

[SWS_Os_00609] [SWS_Os_00610]

[SWS_Os_00625] [SWS_Os_00668]

[SWS_Os_00669] [SWS_Os_00670]

[SWS_Os_00676] [SWS_Os_00677]

[SWS_Os_00678] [SWS_Os_00679]

[SWS_Os_00681]

[SRS_Os_80007] Shutdown procedure shall be

triggered by any core

[SWS_Os_00586] [SWS_Os_00587]

[SWS_Os_00588] [SWS_Os_00616]

[SWS_Os_00617] [SWS_Os_00621]

[SWS_Os_00713] [SWS_Os_00714]

[SWS_Os_00715] [SWS_Os_00716]

[SRS_Os_80008] It shall be a common OS

configuration across multiple

cores

[SWS_Os_00567] [SWS_Os_00582]

[SRS_Os_80011] The number of cores that the

operating system manages shall

be configurable offline

[SWS_Os_00583] [SWS_Os_00825]

[SRS_Os_80013] The behaviour of services shall

be identical to single core

systems

[SWS_Os_00569] [SWS_Os_00589]

[SWS_Os_00590] [SWS_Os_00591]

[SWS_Os_00592] [SWS_Os_00593]

[SWS_Os_00594] [SWS_Os_00595]

[SWS_Os_00607] [SWS_Os_00618]

[SWS_Os_00619] [SWS_Os_00623]

[SWS_Os_00629] [SWS_Os_00630]

[SWS_Os_00631] [SWS_Os_00635]

[SWS_Os_00636] [SWS_Os_00637]

[SWS_Os_00638] [SWS_Os_00639]

[SWS_Os_00640] [SWS_Os_00643]

[SWS_Os_00645] [SWS_Os_00646]

[SWS_Os_00647] [SWS_Os_00663]

[SWS_Os_00664] [SWS_Os_00665]

[SRS_Os_80015] The MC extensions shall provide

a mechanism to activate tasks

on different cores

[SWS_Os_00596] [SWS_Os_00598]

[SWS_Os_00599] [SWS_Os_00600]

[SWS_Os_00816] [SWS_Os_00818]

[SWS_Os_00819] [SWS_Os_91022]

[SWS_Os_91023]

[SRS_Os_80016] Event mechanism shall work

across cores

[SWS_Os_00602] [SWS_Os_00604]

[SWS_Os_00605] [SWS_Os_00817]

38 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Requirement Description Satisfied by

[SRS_Os_80018] A method to synchronize tasks

on more than one core shall be

provided

[SWS_Os_00632] [SWS_Os_00633]

[SWS_Os_00634] [SWS_Os_00641]

[SWS_Os_00642] [SWS_Os_00644]

[SWS_Os_00648] [SWS_Os_00649]

[SWS_Os_00650] [SWS_Os_00652]

[SWS_Os_00653] [SWS_Os_00654]

[SWS_Os_00655] [SWS_Os_00656]

[SWS_Os_00657] [SWS_Os_00658]

[SWS_Os_00659] [SWS_Os_00660]

[SWS_Os_00661]

[SRS_Os_80020] A data exchange mechanism

shall be provided

[SWS_Os_00611] [SWS_Os_00671]

[SWS_Os_00718] [SWS_Os_00719]

[SWS_Os_00720] [SWS_Os_00721]

[SWS_Os_00722] [SWS_Os_00723]

[SWS_Os_00724] [SWS_Os_00725]

[SWS_Os_00726] [SWS_Os_00727]

[SWS_Os_00728] [SWS_Os_00729]

[SWS_Os_00730] [SWS_Os_00731]

[SWS_Os_00732] [SWS_Os_00733]

[SWS_Os_00734] [SWS_Os_00735]

[SWS_Os_00736] [SWS_Os_00737]

[SWS_Os_00738] [SWS_Os_00739]

[SWS_Os_00740] [SWS_Os_00741]

[SWS_Os_00742] [SWS_Os_00743]

[SWS_Os_00744] [SWS_Os_00745]

[SWS_Os_00746] [SWS_Os_00747]

[SWS_Os_00748] [SWS_Os_00749]

[SWS_Os_00750] [SWS_Os_00751]

[SWS_Os_00752] [SWS_Os_00753]

[SWS_Os_00754] [SWS_Os_00755]

[SWS_Os_00756] [SWS_Os_00757]

[SWS_Os_00758] [SWS_Os_00759]

[SWS_Os_00760] [SWS_Os_00761]

[SWS_Os_00803] [SWS_Os_00805]

[SWS_Os_00827] [SWS_Os_00828]

[SWS_Os_00830] [SWS_Os_00831]

[SWS_Os_00832] [SWS_Os_00833]

[SWS_Os_00834] [SWS_Os_00835]

[SRS_Os_80021] The MC extension of the

AUTOSAR environment shall

support a mutual exclusion

mechanism between cores that

shall not cause deadlocks

[SWS_Os_00612] [SWS_Os_00613]

[SWS_Os_00614] [SWS_Os_00615]

[SWS_Os_00620] [SWS_Os_00622]

[SWS_Os_00624] [SWS_Os_00648]

[SWS_Os_00649] [SWS_Os_00650]

[SWS_Os_00651] [SWS_Os_00652]

[SWS_Os_00653] [SWS_Os_00654]

[SWS_Os_00655] [SWS_Os_00656]

[SWS_Os_00657] [SWS_Os_00658]

[SWS_Os_00659] [SWS_Os_00660]

[SWS_Os_00661] [SWS_Os_00662]

[SWS_Os_00666] [SWS_Os_00686]

39 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Requirement Description Satisfied by

[SWS_Os_00687] [SWS_Os_00688]

[SWS_Os_00689] [SWS_Os_00690]

[SWS_Os_00691] [SWS_Os_00692]

[SWS_Os_00693] [SWS_Os_00694]

[SWS_Os_00695] [SWS_Os_00696]

[SWS_Os_00697] [SWS_Os_00698]

[SWS_Os_00699] [SWS_Os_00700]

[SWS_Os_00701] [SWS_Os_00703]

[SWS_Os_00704] [SWS_Os_00705]

[SWS_Os_00706] [SWS_Os_00707]

[SWS_Os_00708] [SWS_Os_00709]

[SWS_Os_00710] [SWS_Os_00711]

[SWS_Os_00712] [SWS_Os_00792]

[SWS_Os_00801]

[SRS_Os_80022] In case no task is going to be

scheduled on a specific core, the

OS shall execute a user

selectable operation

[SWS_Os_00769]

[SRS_Os_80023] The OS shall execute an

operation which can be selected

at runtime, in case no task is

going to be scheduled on a

specific core

[SWS_Os_00770] [SWS_Os_00771]

[SWS_Os_00802]

40 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

7 Functional specification

7.1 Core OS

7.1.1 Background & Rationale

The OSEK/VDX Operating System [2] is widely used in the automotive industry and

has been proven in use in all classes of ECUs found in modern vehicles. The concepts

that OSEK OS has introduced are widely understood and the automotive industry has

many years of collective experience in engineering OSEK OS based systems.

OSEK OS is an event-triggered operating system. This provides high flexibility in the

design and maintenance of AUTOSAR based systems. Event triggering gives free-

dom for the selection of the events to drive scheduling at runtime, for example angular

rotation, local time source, global time source, error occurrence etc.

For these reasons the core functionality of the AUTOSAR OS shall be based upon the

OSEK OS. In particular OSEK OS provides the following features to support concepts

in AUTOSAR:

• fixed priority-based scheduling

• facilities for handling interrupts

• only interrupts with higher priority than Tasks

• some protection against incorrect use of OS services

• a startup interface through StartOS and the StartupHook

• a shutdown interface through ShutdownOS and the ShutdownHook

OSEK OS provides many features in addition to these. Readers should consult the

specification [2] for details.

Basing AUTOSAR OS on OSEK OS means that legacy applications will be backward

compatible - i.e. applications written for OSEK OS will run on AUTOSAR OS. However,

some of the features introduced by AUTOSAR OS require restrictions on the use of

existing OSEK OS features or extend existing OSEK OS features.

7.1.2 Requirements

[SWS_Os_00001] dThe Operating System module shall provide an API that is back-

ward compatible with the OSEK OS API [2].c(SRS_Os_00097, SRS_BSW_00336,

SRS_BSW_00345)

41 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

7.1.2.1 Restrictions on OSEK OS

It is too inefficient to achieve timing and memory protection for alarm callbacks. They

are therefore not allowed in specific scalability classes ([SWS_Os_00242])

[SWS_Os_00242] dThe Operating System module shall only allow Alarm Callbacks

in Scalability Class 1.c()

OSEK OS is required to provide functionality to handle inter-task (internal) communi-

cation according to the OSEK COM specification when internal communication only

is required in the system. In AUTOSAR, internal communication is provided by the

AUTOSAR RTE or by AUTOSAR COM at least one of which will be present for all

AUTOSAR ECUs.

AUTOSAR OS, when used in an AUTOSAR system, therefore does not need to support

internal communication.

An OSEK OS must implement internal communication if the symbol LOCALMES-

SAGESONLY is defined. AUTOSAR OS can deprecate the need to implement OSEK

COM functionality and maintain compatibility with OSEK suite of specifications by

ensuring that AUTOSAR OS always exists in an environment where LOCALMES-

SAGESONLY is undefined.

OSEK OS has one special Resource called RES_SCHEDULER. This Resource has 2

specific aspects:

1. It is always present in the system, even if it is not configured. This means that the

RES_SCHEDULER is always known by the OS.

2. It has always the highest Task priority. This means a Task which allocates this

Resource cannot be preempted by other Tasks.

Since special cases are always hard to handle (e.g. in this case with respect to timing

protection) AUTOSAR OS handles RES_SCHEDULER as any other Resource. This

means that the RES_SCHEDULER is not automatically created.

Note that on multi-core systems the scheduling happens per core. Chapter 7.9.21

contains more information regarding handling of Resources in such systems.

In OSEK OS users must declare Operating System objects with specific macros (e.g.

DeclareTask(), . . . ) An AUTOSAR OS implementation shall not depend on such

declarations and shall (for backwards compatibility) supply macros without functionality.

7.1.2.2 Undefined Behaviour in OSEK OS

There are a number of cases where the behaviour of OSEK OS is undefined. These

cases represent a barrier to portability. AUTOSAR OS tightens the OSEK OS specifi-

cation by defining the required behaviour.

42 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

[SWS_Os_00304] dIf in a call to SetRelAlarm the parameter "increment" is set to

zero, the service shall return E_OS_VALUE in standard and extended status .c()

[SWS_Os_00424] dThe first call to StartOS (for starting the Operating System) shall

not return.c()

[SWS_Os_00425] dIf ShutdownOS is called and ShutdownHook returns then the Op-

erating System module shall disable all interrupts and enter an endless loop.c()

7.1.2.3 Extensions to OSEK OS

[SWS_Os_00299] dThe Operating System module shall provide the ser vices Dis-

ableAllInterrupts, EnableAllInterrupts, SuspendAllInterrupts, Re-

sumeAllInterrupts prior to calling StartOS and after calling ShutdownOS.c

(SRS_Os_11018)

It is assumed that the static variables of the functions mentioned in [SWS_Os_00299]

are initialized.

[SWS_Os_00301] dThe Operating System module shall provide the ability to incre-

ment a software Counter as an alternative action on alarm expiry.c(SRS_Os_11021)

The Operating System module provides API service IncrementCounter (see

[SWS_Os_00399]) to increment a software Counter.

[SWS_Os_00476] dThe Operating System module shall allow to automatically start

preconfigured absolute alarms during the start of the Operating System.c()

[SWS_Os_00476] is an extension to OSEK OS which allows this only for relative

alarms.

[SWS_Os_00566] dThe Operating System API shall check in extended mode all

pointer arguments for a NULL pointer and return E_OS_PARAM_POINTER in extended

status if such an argument is NULL.c()

7.2 Software Free Running Timer

Due to the fact that the number of timers is often very limited, some functionality and

configuration is added to extend the reuse of timers. E.g. this allows timer measure-

ments. For more details see also [7] (SWFRT).

[SWS_Os_00374] dThe Operating System module shall handle all the initialization and

configuration of timers used directly by the Operating System module and not handled

by the GPT driver.c(SRS_Frt_00020)

The Operating System module provides API service GetCounterValue (see

[SWS_Os_00383]) to read the current count value of a Counter (returning either the

43 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

hardware timer ticks if Counter is driven by hardware or the software ticks when user

drives Counter).

The Operating System module provides API service GetElapsedValue (see

[SWS_Os_00392]) to get the number of ticks between the current tick value and a

previously read tick value.

[SWS_Os_00384] dThe Operating System module shall adjust the read out values of

hardware timers (which drive counters) in such that the lowest value is zero and con-

secutive reads return an increasing count value until the timer wraps at its modulus.c

(SRS_Frt_00030, SRS_Frt_00031)

7.3 ScheduleTables

7.3.1 Background & Rationale

It is possible to implement a statically defined Task activation mechanism using an

OSEK Counter and a series of auto started alarms. In the simple case, this can

be achieved by specifying that the Alarms are not modified once started. Run-time

modifications can only be made if relative synchronization between alarms can be

guaranteed. This typically means modifying the alarms while associated Counter tick

interrupts are disabled.

ScheduleTables address the synchronization issue by providing an encapsulation of

a statically defined set of expiry points. Each expiry point defines:

• one or more actions that must occur when it is processed where an action is the

activation of a Task or the setting of an event.

• An offset in ticks from the start of the ScheduleTable

Each ScheduleTable has a duration in ticks. The duration is measured from zero

and defines the modulus of the ScheduleTable.

At runtime, the Operating System module will iterate over the ScheduleTable, pro-

cessing each expiry point in turn. The iteration is driven by an OSEK Counter. It

therefore follows that the properties of the Counter have an impact on what is possi-

ble to configure on the ScheduleTable.

44 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

7.3.2 Requirements

7.3.2.1 Structure of a ScheduleTable

Figure 7.1: Anatomy of a ScheduleTable

[SWS_Os_00401] dA ScheduleTable shall have at least one expiry point.c()

[SWS_Os_00402] dAn expiry point shall contain a (possibly empty) set of Tasks to

activate.c()

[SWS_Os_00403] dAn expiry point shall contain a (possibly empty) set of Events to

set.c()

[SWS_Os_00404] dAn expiry point shall contain an offset in ticks from the start of the

ScheduleTable.c()

7.3.2.2 Constraints on Expiry Points

There is no use case for an empty expiry point, so each one must define at least one

action.

[SWS_Os_00407] dAn expiry point shall activate at least one Task OR set at least one

event.c()

The OS needs to know the order in which expiry points are processed. It is therefore

necessary to ensure that the expiry points on a ScheduleTable can be totally or-

dered. This is guaranteed by forcing each expiry point on a ScheduleTable to have

a unique offset.

[SWS_Os_00442] dEach expiry point on a given ScheduleTable shall have a unique

offset.c()

45 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Iteration over expiry points on a ScheduleTable is driven by an OSEK Counter.

The characteristics of the Counter - OsCounterMinCycle and OsCounterMaxAl-

lowedValue - place constraints on expiry point offsets.

[SWS_Os_00443] dThe Initial Offset shall be zero OR in the range OsCounterMin-

Cycle .. OsCounterMaxAllowedValue of the underlying Counter.c()

Similarly, constraints apply to the delays between of adjacent expiry points and the

delay to the logical end of the ScheduleTable.

[SWS_Os_00408] dThe delay between adjacent expiry points shall be in the range Os-

CounterMinCycle .. OsCounterMaxAllowedValue of the underlying Counter.c

()

7.3.2.3 Processing ScheduleTables

[SWS_Os_00002] dThe Operating System module shall process each expiry point on

a ScheduleTable from the Initial Expiry Point to the Final Expiry Point in order of

increasing offset.c(SRS_Os_00098)

[SWS_Os_00007] dThe Operating System module shall permit multiple Sched-

uleTables to be processed concurrently.c(SRS_Os_00098)

[SWS_Os_00409] dA ScheduleTable of the Operating System module shall be

driven by exactly one Counter.c()

[SWS_Os_00410] dThe Operating System module shall be able to process at least

one ScheduleTable per Counter at any given time.c()

[SWS_Os_00411] dThe Operating System module shall make use of ticks so that one

tick on the Counter corresponds to one tick on the ScheduleTable.c()

It is possible to activate a Task and set (one or more unique) Events for the same

Task at the same expiry point. The ordering of Task activations and event settings

performed from the expiry point could lead to different implementations exhibiting differ-

ent behaviour (for example, activating a suspended Task and then setting and event on

the Task would succeed but if the ordering was reversed then the event setting would

fail). To prevent such non-determinism, it is necessary to enforce a strict ordering of

actions on the expiry point.

[SWS_Os_00412] dIf an expiry point contains actions to activate a Task and to set one

or several Event(s) of the same Task, then the Operating System module shall pro-

cess this Task activation before the related Event(s) are set. No further assumptions

about the order for the processing of expiry points can be made.c()

A ScheduleTable always has a defined state and the following figure illustrates the

different states (for a non-synchronized ScheduleTable) and the transitions between

them.

46 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Figure 7.2: States of a ScheduleTable

If a ScheduleTable is not active - this means that is not processed by the Op-

erating System - the state is SCHEDULETABLE_STOPPED. After starting a Sched-

uleTables enters the SCHEDULETABLE_RUNNING state where the OS processes the

expiry points. If the service to switch a ScheduleTable is called a ScheduleTable

enters the SCHEDULETABLE_NEXT state and waits until the "current" ScheduleTable

ends.

7.3.2.4 Repeated ScheduleTable Processing

A ScheduleTable may or may not repeat after the final expiry point is processed.

This allows two types of behaviour:

1. single-shot - the ScheduleTable processes each expiry point in sequence and

then stops at the end. This is useful for triggering a phased sequence of actions

in response to some trigger

2. repeating - the ScheduleTable processes each expiry point in turn, after pro-

cessing the final expiry point, it loops back to the initial expire point. This is useful

for building applications that perform repeated processing or system which need

to synchronize processing to a driver source.

A repeating ScheduleTable means that each expiry point is repeated at a period

equal to the ScheduleTable duration.

[SWS_Os_00413] dThe ScheduleTable shall be configurable as either single-shot

or repeating.c()

47 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

[SWS_Os_00009] dIf the ScheduleTable is single-shot, the Operating System mod-

ule shall stop the processing of the ScheduleTable Final Delay ticks after the Final

Expiry Point is processed.c()

[SWS_Os_00427] dIf the ScheduleTable is single-shot, the Operating System mod-

ule shall allow a Final Delay between 0 .. OsCounterMaxAllowedValue of the un-

derlying Counter.c()

[SWS_Os_00444] dFor periodic ScheduleTables the value of Final Delay shall be in

the range OsCounterMinCycle .. OsCounterMaxAllowedValue of the underlying

Counter.c()

[SWS_Os_00194] dAfter processing the Final Expiry Point, and if the ScheduleTable

is repeating, the Operating System shall process the next Initial Expiry Point, after Final

Delay plus Initial Offset ticks have elapsed.c()

7.3.2.5 Controlling ScheduleTable Processing

The application is responsible for starting and stopping the processing of a Sched-

uleTable.

The Operating System module provides the service StartScheduleTableAbs (see

[SWS_Os_00358]) to start the processing of a ScheduleTable at an absolute value

"Start" on the underlying Counter. (The Initial Expiry Point has to be processed when

the value of the underlying Counter equals Start + InitialOffset).

The Operating System module provides the service StartScheduleTableRel (see

[SWS_Os_00347]) to start the processing of a ScheduleTable at "Offset" relative to

the "Now" value on the underlying Counter (The Initial Expiry Point shall be processed

when the value of the underlying Counter equals Now + Offset + InitialOffset).

The figure below illustrates the two different methods for a ScheduleTable driven

by a Counter with a modulus of 65536 (i.e. an OsCounterMaxAllowedValue =

65535).

48 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Figure 7.3: Starting a ScheduleTable at an Absolute and a Relative Count

The Operating System module provides the service StopScheduleTable (see

[SWS_Os_00006]) to cancel the processing of a ScheduleTable immediately at any

point while the ScheduleTable is running.

[SWS_Os_00428] dIf ScheduleTable processing has been cancelled before reach-

ing the Final Expiry Point and is subsequently restarted then [SWS_Os_00358]/

[SWS_Os_00347] means that the re-start occurs from the start of the Sched-

uleTable.c()

The Operating System module provides the service NextScheduleTable (see

[SWS_Os_00191]) to switch the processing from one ScheduleTable to another

ScheduleTable.

[SWS_Os_00414] dWhen a ScheduleTable switch is requested, the OS shall con-

tinue to process expiry points on the current ScheduleTable. After the Final Ex-

piry Point there will be a delay equivalent to Final Delay ticks before processing the

switched-to ScheduleTable. The initial expiry point will be processed after initial

offset.c()

49 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

The Operating System module provides the service GetScheduleTableStatus (see

[SWS_Os_00227]) to query the state of a ScheduleTable.

ScheduleTables can be configured (see chapter 10) to start automatically during

start of the Operating System module (like Tasks and Alarms in OSEK OS). OSEK OS

defines a specific order: Autostart of Tasks is performed before autostart of alarms.

AUTOSAR OS extends this with ScheduleTables.

[SWS_Os_00510] dThe Operating System module shall perform the autostart of

ScheduleTables during startup after the autostart of Tasks and Alarms.c()

7.4 ScheduleTable Synchronization

7.4.1 Background & Rationale

The absolute time at which the Initial Expiry Point on a ScheduleTable is processed

is under user control. However, if the ScheduleTable repeats then it is not guaran-

teed that the absolute count value at which the initial expiry point was first processed

is the same count value at which it is subsequently processed. This is because the

duration of the ScheduleTable need not be equal to the Counter modulus.

In many cases it may be important that ScheduleTable expiry points are processed

at specific absolute values of the underlying Counter. This is called synchronization.

Typical use-cases include:

• Synchronization of expiry points to degrees of angular rotation for motor manage-

ment

• Synchronizing the computation to a global (network) time base. Note that in

AUTOSAR, the Operating System does not provide a global (network) time

source because

1. a global time may not be needed in many cases

2. other AUTOSAR modules, most notably FlexRay, provide this independently

to the Operating System

3. if the Operating System is required to synchronize to multiple global (net-

work) time sources (for example when building a gateway between two time-

triggered networks) the Operating System cannot be the source of a unique

global time.

AUTOSAR OS provides support for synchronization in two ways:

• implicit synchronization - the Counter driving the ScheduleTable is the

Counter with which synchronization is required. This is typically how syn-

chronization with time-triggered networking technologies (e.g. FlexRay, TTP) is

achieved - the underlying hardware manages network time synchronization and

50 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

simply presents time as an output/compare timer interface to the Operating Sys-

tem. The following figure shows the possible states for ScheduleTables with

implicit synchronization.

Figure 7.4: States of an implicit synchronized ScheduleTable

• explicit synchronization - the ScheduleTable is driven by an Operating Sys-

tem Counter which is not the Counter with which synchronization is required.

The Operating System provides additional functionality to keep ScheduleTable

processing driven by the Operating System Counter synchronized with the syn-

chronization Counter. This is typically how synchronization with periodically

broadcast global times works. The next figure shows the states of such Sched-

uleTables.

51 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Figure 7.5: States of an explicit synchronized ScheduleTable (not all conditions for

transitions are shown in the picture)

7.4.2 Requirements

[SWS_Os_00013] dThe Operating System module shall provide the ability to synchro-

nize the processing of ScheduleTable to known Counter values.c(SRS_Os_11002)

7.4.2.1 Implicit Synchronization

The Operating System module does not need to provide any additional support for

implicit synchronization of ScheduleTables. However, it is necessary to constrain

configuration and runtime control of the ScheduleTable so that ticks on the config-

ured ScheduleTable can be aligned with ticks on the Counter. This requires the

range of the ScheduleTable to be identical to the range of the Counter (the equality

of tick resolution of each is guaranteed by the requirements on the ScheduleTable /

Counter interaction):

[SWS_Os_00429] dA ScheduleTable of the Operating System module that is im-

plicitly synchronized shall have a Duration equal to OsCounterMaxAllowedValue +

1 of its associated OSEK OS Counter.c()

52 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

To synchronize the processing of the ScheduleTable it must be started at a known

counter value. The implication of this is that a ScheduleTable requiring implicit syn-

chronization must only be started at an absolute counter value and cannot be started

at a relative count value.

[SWS_Os_00430] dThe Operating System module shall prevent a ScheduleTable

that is implicitly synchronized from being started at a relative count value.c()

When the ScheduleTable is started at an absolute counter value each expiry point

will be processed when the counter equals the value specified in the service call plus

expiry point’s offset. The common use-case is to ensure that the offsets specified

in the ScheduleTable configuration correspond to absolute values of the underlying

Counter. This is achieved trivially using StartScheduleTableAbs(Tbl,0) as shown

below.

Figure 7.6: Example for implicit synchronized ScheduleTable

7.4.2.2 Explicit Synchronization

An explicitly synchronized ScheduleTable requires additional support from the Op-

erating System module. The ScheduleTable is driven by an Operating System mod-

ule’s Counter as normal (termed the "drive Counter") but processing needs to be

synchronized with a different Counter (termed the "synchronization Counter") which

is not an Operating System module’s Counter object.

The following constraints must be enforced between the ScheduleTable, the Oper-

ating System module’s Counter and the synchronization Counter:

Constraint1:

53 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

[SWS_Os_00431] dA ScheduleTable that is explicitly synchronized shall have a du-

ration no greater than modulus of the drive Counter.c()

Constraint2:

[SWS_Os_00462] dA ScheduleTable that is explicitly synchronized shall have a du-

ration equal to the modulus of the synchronization Counter.c()

Constraint3:

[SWS_Os_00463] dThe synchronization Counter shall have the same resolution as

the drive Counter associated with the ScheduleTable. This means that a tick on the

ScheduleTable has the same duration as a tick on the synchronization Counter.c()

Note that it is in the responsibility of the Operating System module user to verify that

Constraints 2 and 3 are satisfied by their system.

The function of explicit synchronization is for the Operating System module to keep

processing each expiry point at absolute value of the synchronization Counter equal

to the expiry point’s offset. This means that explicit synchronization always assumes

that the notional zero of the ScheduleTable has to be synchronized with absolute

value zero on the synchronization Counter.

To achieve this, the Operating System module must be told the value of the synchro-

nization Counter by the user. As the modulus of the synchronization Counter and

the ScheduleTable are identical, the Operating System module can use this infor-

mation to calculate drift. The Operating System module then automatically adjusts the

delay between specially configured expiry points, retarding them or advancing them as

appropriate, to ensure that synchronization is maintained.

7.4.2.2.1 Startup

There are two options for starting an explicitly synchronized ScheduleTable:

1. Asynchronous start: Start the ScheduleTable at an arbitrary value of the syn-

chronization Counter.

2. Synchronous start: Start the ScheduleTable at absolute value zero of the syn-

chronization Counter only after a synchronization count has been provided. This

may mean waiting for first synchronization indefinitely.

Asynchronous start is provided by the existing absolute and relative ScheduleTable

start services. Both of these services set the point at which the initial expiry point is

processed with respect to the driver Counter not the synchronization Counter. This

allows the ScheduleTable to start running before the value of the synchronization

Counter is known.

Synchronous start requires an additional service that starts the ScheduleTable only

after the Operating System module is told the value of the synchronization Counter.

54 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

The Operating System module provides the service StartScheduleTableSyn-

chron (see [SWS_Os_00201]) to start an explicitly synchronized ScheduleTable

synchronously. The Initial Expiry Point will be processed after (Duration - Value) + Ini-

tial Offset ticks of the driver Counter have elapsed where Value is the absolute value

of the synchronization Counter provided to the ScheduleTable.

[SWS_Os_00435] dIf an explicitly synchronized ScheduleTable was started syn-

chronously, then the Operating System module shall guarantee that it has state "wait-

ing" when the call of service StartScheduleTableSynchron returns.c()

7.4.2.2.2 Providing a Synchronization Count

The Operating System module must be told the value of the synchronization Counter.

Since the ScheduleTable duration is equal to the modulus of the synchronization

Counter, the Operating System module can use this to determine the drift between

the current count value on the ScheduleTable time and the synchronization count

and decide whether (or not) any action to achieve synchronization is required.

The Operating System module provides the service SyncScheduleTable (see

[SWS_Os_00199]) to provide the ScheduleTable with a synchronization count and

start synchronization.

7.4.2.2.3 Specifying Synchronization Bounds

A ScheduleTable defaults to denying adjustment at all expiry points. Adjustment is

allowed only when explicitly configured. The range of adjustment that the Operating

System module can make at an adjustable expiry point is controlled by specifying:

• OsScheduleTableMaxShorten : the maximum value that can be subtracted

from the expiry offset

• OsScheduleTableMaxLengthen: the maximum value that can be added to the

expiry point offset

The following figure illustrates the behaviour depending on OsScheduleTable-

MaxShorten and OsScheduleTableMaxLengthen:

55 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Figure 7.7: Adjustment of Expiry Points

[SWS_Os_00415] dAn expiry point shall permit the configuration of an OsSched-

uleTableMaxShorten that defines the maximum number of ticks that can be sub-

tracted from expiry point offset.c()

56 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

[SWS_Os_00416] dAn expiry point shall permit the configuration of an OsSched-

uleTableMaxLengthen that defines the maximum number of ticks that can be added

to expiry point offset.c()

When performing synchronization it is important that the expiry points on the Sched-

uleTable are processed according to the total ordering defined by their offsets.

This means that the range of permitted values for OsScheduleTableMaxShorten

and OsScheduleTableMaxLengthen must ensure that the next expiry point is not

retarded into the past or advanced beyond more than one iteration of the Sched-

uleTable.

[SWS_Os_00436] dThe value of (Offset - OsScheduleTableMaxShorten ) of an

expiry point shall be greater than (Offset + OsCounterMinCycle) of the pervious

expiry point.c()

[SWS_Os_00559] dThe value of OsScheduleTableMaxLengthen shall be smaller

than the duration of the ScheduleTable.c()

[SWS_Os_00437] dThe value of (OsScheduleTableMaxLengthen + delay_from_

previous_EP) of an expiry point shall be less than the OsCounterMaxAllowedValue

of the underlying Counter.c()

Explicitly synchronized ScheduleTables allow the tolerance of some drift between

the ScheduleTable value and the synchronization counter value. This tolerance can

be zero, indicating that the ScheduleTable is not considered synchronized unless

the values are identical.

[SWS_Os_00438] dA ScheduleTable shall define a precision bound with a value in

the range 0 to duration.c()

7.4.2.3 Performing Synchronization

The Operating System module uses the synchronization count to support (re-

)synchronization of a ScheduleTable at each expiry point by calculating an adjust-

ment to the delay to the next expiry point. This provides faster re-synchronization of

the ScheduleTable than doing the action on the final expiry point.

[SWS_Os_00206] dWhen a new synchronization count is provided, the Operating Sys-

tem module shall calculate the current deviation between the explicitly synchronized

scheduled table and the synchronization count.c(SRS_Os_11002)

It is meaningless to try and synchronize an explicitly synchronized ScheduleTable

before a synchronization count is provided.

[SWS_Os_00417] dThe Operating System module shall start to synchronize an explic-

itly synchronized ScheduleTable after a synchronization count is provided AND shall

continue to adjust expiry points until synchronized.c()

57 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

[SWS_Os_00418] dThe Operating System module shall set the state of an explicitly

synchronized ScheduleTable to "running and synchronous" if the deviation is less

than or equal to the configured OsScheduleTblExplicitPrecision threshold.c()

[SWS_Os_00419] dThe Operating System module shall set the state of an explicitly

synchronized ScheduleTable to "running" if the deviation is greater than the config-

ured OsScheduleTblExplicitPrecision threshold.c()

[SWS_Os_00420] dIF the deviation is non-zero AND the next expiry point is adjustable

AND the table is behind the sync Counter (TableTicksAheadOfSyncCounter <= Ta-

bleTicksBehindOfSyncCounter) THEN the OS shall set the next EP to expire delay -

min(MaxShorten, Deviation) ticks from the current expiry.c()

[SWS_Os_00421] dIF the deviation is non-zero AND the next expiry point is adjustable

AND the table is ahead of the sync Counter (TableTicksAheadOfSyncCounter > Ta-

bleTicksBehindOfSyncCounter) THEN the OS shall set the next EP to expire delay +

min(MaxLengthen, Deviation) ticks from the current expiry.c()

Figure 7.8 shows explicit synchronization of a ScheduleTable. It assumes the fol-

lowing:

• EP1-3 have OsScheduleTableMaxLengthen=2

• EP1-3 have OsScheduleTableMaxShorten =1

Figure 7.8: Explicit ScheduleTable Synchronization

The Operating System module provides the service SetScheduleTableAsync (see

[SWS_Os_00422]) to cancel synchronization being performed at adjustable expiry

points on a ScheduleTable.

58 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

The Operating System module provides the service GetScheduleTableStatus (see

[SWS_Os_00227]) to query the state of a ScheduleTable also with respect to syn-

chronization.

7.5 Stack Monitoring Facilities

7.5.1 Background & Rationale

On processors that do not provide any memory protection hardware it may still be

necessary to provide a "best effort with available resources" scheme for detectable

classes of memory faults. Stack monitoring will identify where a Task or ISR has

exceeded a specified stack usage at context switch time. This may mean that there

is considerable time between the system being in error and that fault being detected.

Similarly, the error may have been cleared at the point the fault is notified (the stack

may be less than the specified size when the context switch occurs).

It is not usually sufficient to simply monitor the entire stack space for the system be-

cause it is not necessarily the Task/ISR that was executing that used more than stack

space than required - it could be a lower priority object that was pre-empted.

Significant debugging time can be saved by letting the Operating System correctly

identify the Task/Category 2 ISR in error.

Note that for systems using an MPU and scalability class 3 or 4 a stack overflow may

cause a memory exception before the stack monitoring is able to detect the fault.

7.5.2 Requirements

[SWS_Os_00067] dThe Operating System module shall provide a stack monitoring

which detects possible stack faults of Task(s)/Category 2 ISR(s).c(SRS_Os_11003)

[SWS_Os_00068] dIf a stack fault is detected by stack monitoring AND no Protec-

tionHook is configured, the Operating System module shall call the ShutdownOS

service with the status E_OS_STACKFAULT.c(SRS_Os_11003, SRS_Os_11013)

[SWS_Os_00396] dIf a stack fault is detected by stack monitoring AND a Protec-

tionHook is configured the Operating System module shall call the Protection-

Hook with the status E_OS_STACKFAULT.c()

59 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

7.6 OS-Application

7.6.1 Background & Rationale

An AUTOSAR OS must be capable of supporting a collection of Operating System

objects (Tasks, ISRs, Alarms, ScheduleTables, Counters) that form a cohesive

functional unit. This collection of objects is termed an OS-Application.

The Operating System module is responsible for scheduling the available processing

resource between the OS-Applications that share the processor. If OS-Application(s)

are used, all Tasks, ISRs, Counters, Alarms and ScheduleTables must belong to

an OS-Application. All objects which belong to the same OS-Application have access

to each other. The right to access objects from other OS-Applications may be granted

during configuration. An Event is accessible if the Task for which the event can be

set is accessible. Access means that these Operating System objects are allowed as

parameters to API services.

There are two classes of OS-Application:

1. Trusted OS-Applications are allowed to run with monitoring or protection features

disabled at runtime. They may have unrestricted access to memory, the Oper-

ating System module’s API, and need not have their timing behaviour enforced

at runtime. They are allowed to run in privileged mode when supported by the

processor. The Operating System module assumes that trusted OS-Applications

(and trusted functions) do not cause a memory related protection fault. If such a

fault happens the system stability is likely gone and a shutdown may be the only

option.

2. Non-Trusted OS-Applications are not allowed to run with monitoring or protection

features disabled at runtime. They have restricted access to memory, restricted

access to the Operating System module’s API and have their timing behaviour

enforced at runtime. They are not allowed to run in privileged mode when sup-

ported by the processor.

It is assumed that the Operating System module itself is trusted.

There are services offered by the AUTOSAR OS which give the caller information about

the access rights and the membership of objects. These services are intended to be

used in case of an inter-OS-Application call for checking access rights and arguments.

Note that Resource objects do not belong to any OS-Application, but access to them

must be explicitly granted. (The same principle applies to spinlocks in Multi-Core sys-

tems)

The running OS-Application is defined as the OS-Application to which the currently

running Task or ISR belongs. In case of a hook routine the Task or ISR which caused

the call of the hook routine defines the running OS-Application.

60 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Figure 7.9: UML-model of OS-Application

OS-Applications have a state which defines the scope of accessibility of its Operating

System objects from other OS-Applications. Each OS-Application is always in one of

the following states:

• Active and accessible (APPLICATION_ACCESSIBLE): Operating System objects

may be accessed from other OS-Applications. This is the default state at startup.

• Currently in restart phase (APPLICATION_RESTARTING). Operating System ob-

jects cannot be accessed from other OS-Applications. State is valid until the

OS-Application calls AllowAccess.

• Terminated and not accessible (APPLICATION_TERMINATED): Operating Sys-

tem objects cannot be accessed from other OS-Applications. State will not

change.

The following figure shows the states and the possible transitions:

61 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Figure 7.10: States of OS-Applications

7.6.2 Requirements

[SWS_Os_00445] dThe Operating System module shall support OS-Applications

which are a configurable selection of Tr usted Functions, Tasks, ISRs, Alarms,

ScheduleTables, Counters, hooks (for startup, error and shutdown).c()

[SWS_Os_00446] dThe Operating System module shall support the notion of trusted

and non-trusted OS-Applications.c()

[SWS_Os_00464] dTrusted OS-Applications may offer services ("trusted services") to

other (even non-trusted) OS-Applications.c()

The Operating System module provides the services GetApplicationID and

GetCurrentApplicationID (see [SWS_Os_00016]) to determine the configured

resp. currently executing OS-Application (a unique identifier shall be allocated to each

application).

The Operating System module provides the service CheckObjectOwnership

(see [SWS_Os_00017]) to determine to which OS-Application a given Task, ISR,

Counter, Alarm or ScheduleTable belongs.

The Operating System module provides the service CheckObjectAccess (see

[SWS_Os_00256]) to determine which OS-Applications are allowed to use the IDs of

a Task, Resource, Counter, Alarm or ScheduleTable in API calls.

62 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

The Operating System module provides the service TerminateApplication (see

[SWS_Os_00258]) to terminate the OS-Application to which the calling Task/Category

2 ISR/application specific error hook belongs. (This is an OS-Application level variant

of the TerminateTask service)

The Operating System provides the service TerminateApplication (see

[SWS_Os_00258]) to ter minate another OS-Application AND calls to this service shall

be ignored if the caller does not belong to a trusted OS-Application.

[SWS_Os_00447] dIf the Operating System module ter minates an OS-Application,

then it shall:

• terminate all running, ready and waiting Tasks/ISRs of the OS-Application AND

• disable all interrupts of the OS-Application AND

• stop all active alarms of the OS-Applications AND

• stop all ScheduleTables of the OS-Application.

c(SRS_Os_11022)

[SWS_Os_00448] dThe Operating System module shall prevent access of OS-

Applications, trusted or non-trusted, to objects not belonging to this OS-Application,

except access rights for such objects are explicitly granted by configuration.c()

The Operating System provides the service GetApplicationState (see

[SWS_Os_00499]) to request the current state of an OS-Application.

[SWS_Os_00500] dThe Operating System module shall set the state of all OS-

Applications after the call of StartOS and before any StartupHook is called to AP-

PLICATION_ACCESSIBLE.c()

The Operating System module provides the service AllowAccess (see

[SWS_Os_00501]) to set the own state of an OS-Application from APPLICA-

TION_RESTARTING to APPLICATION_ACCESSIBLE.

[SWS_Os_00502] dIf an OS-Application is ter minated (e.g. through a service call or

via protection hook) and no restart is requested, then the Operating System module

shall set the state of this OS-Application to APPLICATION_TERMINATED.c()

[SWS_Os_00503] dIf an OS-Application is ter minated (e.g. through a service call or

via protection hook) and a restart is requested, then the Operating System module

shall set the state of this OS-Application to APPLICATION_RESTARTING.c(SRS_Os_-

11023)

[SWS_Os_00504] dThe Operating System module shall deny access to Operating

System objects from other OS-Applications to an OS-Application which is not in state

APPLICATION_ACCESSIBLE.c()

[SWS_Os_00509] dIf a service call is made on an Operating System object that is

owned by another OS-Application without state APPLICATION_ACCESSIBLE, then the

Operating System module shall return E_OS_ACCESS.c()

63 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

An example for [SWS_Os_00509] is a call to ActivateTask for a Task in an OS-

Application that is restarting.

7.7 Protection Facilities

Protection is only possible for Operating System managed objects. This means that:

• It is not possible to provide protection during runtime of Category 1 ISRs, be-

cause the operating system is not aware of any Category 1 ISRs being invoked.

Therefore, if any protection is required, Category 1 ISRs have to be avoided. If

Category 1 interrupts AND OS-Applications are used together then all Category

1 ISR must belong to a trusted OS-Application.

• It is not possible to provide protection between functions called from the body of

the same Task/Category 2 ISR.

7.7.1 Memory Protection

7.7.1.1 Background & Rationale

Memory protection will only be possible on processors that provide hardware support

for memory protection.

The memory protection scheme is based on the (data, code and stack) sections of the

executable program.

Stack: An OS-Application comprises a number of Tasks and ISRs. The stack for

these objects, by definition, belongs only to the owner object and there is therefore no

need to share stack data between objects, even if those objects belong to the same

OS-Application.

Memory protection for the stacks of Tasks and ISRs is useful mainly for two reasons:

1. Provide a more immediate detection of stack overflow and underflow for the Task

or ISR than can be achieved with stack monitoring

2. Provide protection between constituent parts of and OS-Application, for example

to satisfy some safety constraints.

Data: OS-Applications can have private data sections and Tasks/ISRs can have pri-

vate data sections. OS-Application’s private data sections are shared by all Tasks/

ISRs belonging to that OS-Application.

Code: Code sections are either private to an OS-Application or can be shared between

all OS-Applications (to use shared libraries). In the case where code protection is not

used, executing incorrect code will eventually result in a memory, timing or service

violation.

64 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

7.7.1.2 Requirements

Data Sections and Stack

[SWS_Os_00198] dThe Operating System module shall prevent write access to its

own data sections and its own stack from non-trusted OS-Applications.c()

[SWS_Os_00795] dThe OS shall offer the possibility to restrict write access of trusted

OS-Applications in the same way as it is done for non-tr usted OS-Applications.c(SRS_-

Os_11005)

This can be configured with the OsTrustedApplicationWithProtection.

Private data of an OS-Application

[SWS_Os_00026] dThe Operating System module may prevent read access to an

OS-Application’s data section attempted by other non-trusted OS-Applications.c(SRS_-

Os_11000)

[SWS_Os_00086] dThe Operating System module shall permit an OS-Application read

and write access to that OS-Application’s own private data sections.c(SRS_Os_11006)

[SWS_Os_00207] dThe Operating System module shall prevent write access to the

OS-Application’s private data sections from other non-trusted OS-Applications.c(SRS_-

Os_11005)

Private Stack of Task/ISR

[SWS_Os_00196] dThe Operating System module shall permit a Task/Category 2

ISR read and write access to that Task’s/Category 2 ISR’s own private stack.c(SRS_-

Os_11006)

[SWS_Os_00208] dThe Operating System module may prevent wr ite access to the

private stack of Tasks/Category 2 ISRs of a non-trusted application from all other

Tasks/ISRs in the same OS-Application.c(SRS_Os_11005)

[SWS_Os_00355] dThe Operating System module shall prevent write access to all

private stacks of Tasks/Category 2 ISRs of an OS-Application from other non-trusted

OS-Applications.c()

Private data of a Task/ISR

[SWS_Os_00087] dThe Operating System module shall permit a Task/Category 2

ISR read and wr ite access to that Task’s/Category 2 ISR’s own private data sections.c

(SRS_Os_11006)

[SWS_Os_00195] dThe Operating System module may prevent wr ite access to the

private data sections of a Task/Categor y 2 ISR of a non-trusted application from all

other Tasks/ISRs in the same OS-Application.c(SRS_Os_11005)

[SWS_Os_00356] dThe Operating System module shall prevent write access to all

private data sections of a Task/Category 2 ISR of an OS-Application from other non-

trusted OS-Applications.c()

65 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Code Sections

[SWS_Os_00027] dThe Operating System module may provide an OS-Application the

ability to protect its code sections against executing by non-trusted OS-Applications.c()

[SWS_Os_00081] dThe Operating System module shall provide the ability to provide

shared library code in sections that are executable by all OS-Applications.c(SRS_Os_-

11007)

Peripherals

[SWS_Os_00209] dIf OsTrustedApplicationWithProtection == FALSE then

the Operating System module shall permit trusted OS-Applications read and write ac-

cess to peripherals.c()

[SWS_Os_00083] dThe Operating System module shall allow non-trusted OS-

Applications to write to their assigned peripherals only (incl. reads that have the side

effect of writing to a memory location).c()

Memory Access Violation

[SWS_Os_00044] dIf a memory access violation is detected, the Oper-

ating System module shall call the ProtectionHook with status code

E_OS_PROTECTION_MEMORY.c(SRS_Os_11013)

7.7.2 Timing Protection

7.7.2.1 Background & Rationale

A timing fault in a real-time system occurs when a Task or interrupt misses its deadline

at runtime.

AUTOSAR OS does not offer deadline monitoring for timing protection. Deadline mon-

itoring is insufficient to correctly identify the Task/ISR causing a timing fault in an

AUTOSAR system. When a deadline is violated this may be due to a timing fault in-

troduced by an unrelated Task/ISR that interferes/blocks for too long. The fault in this

case lies with the unrelated Task/ISR and this will propagate through the system until

a Task/ISR misses its deadline. The Task/ISR that misses a deadline is therefore not

necessarily the Task/ISR that has failed at runtime, it is simply the earliest point that

a timing fault is detected.

If action is taken based on a missed deadline identified with deadline monitoring this

would potentially use false evidence of error to terminate a correct OS-Application in

favor of allowing an incorrect OS-Application to continue running. The problem is best

illustrated by example. Consider a system with the following configuration:

66 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

TaskID Priority Execution Time Deadline

(=Period)

A High 1 5

B Medium 3 10

Low 5 15

Assuming that all Tasks are ready to run at time zero, the following execution trace

would be expected and all Tasks would meet their respective deadlines.

Figure 7.11: Example execution trace

Now consider the case when Tasks A and B behave incorrectly. The figure below

shows both Task A and Task B executing for longer than specified and Task B arriving

2 ticks earlier than specified. Both Tasks A and B meet their deadlines. Task C

however, behaves correctly but it fails to meet its deadline because of the incorrect

execution of Tasks A and B. This is fault propagation - a fault in an unrelated part of

the system is causing a correctly functioning part of the system to fail.

67 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Figure 7.12: Insufficiency of Deadline Monitoring

Whether a Task or ISR meets its deadline in a fixed priority preemptive operating

system like AUTOSAR OS is determined by the following factors:

• the execution time of Task/ISRs in the system

• the blocking time that Task/ISRs suffers from lower priority Tasks/ISRs locking

shared resources or disabling interrupts

• the interarrival rate of Task/ISRs in the system

For safe and accurate timing protection it is necessary for the operating system to

control these factors at runtime to ensure that Tasks/ISRs can meet their respective

deadlines.

AUTOSAR OS prevents timing errors from (1) by using execution time protection to

guarantee a statically configured upper bound, called the Execution Budget, on the

execution time of:

• Tasks

• Category 2 ISRs

AUTOSAR OS prevents timing errors from (2) by using locking time protection to guar-

antee a statically configured upper bound, called the Lock Budget, on the time that:

• Resources are held by Tasks/Category 2 ISRs

• OS interrupts are suspended by Tasks/Category 2 ISRs

• ALL interrupts are suspended/disabled by Tasks/Category 2 ISRs

68 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

AUTOSAR OS prevents timing errors from (3) by using inter-arrival time protection to

guarantee a statically configured lower bound, called the Time Frame, on the time

between:

• A Task being permitted to transition into the READY state due to:

– Activation (the transition from the SUSPENDED to the READY state)

– Release (the transition from the WAITING to the READY state)

• A Category 2 ISR arriving. An arrival occurs when the Category 2 ISR is recog-

nized by the OS

Inter-arrival time protection for basic Tasks controls the time between successive ac-

tivations, irrespective of whether activations are queued or not. In the case of queued

activations, activating a basic Task which is in the READY or RUNNING state is a new

activation because it represents the activation of a new instance of the Task. Inter-

arrival time protection therefore interacts with queued activation to control the rate at

which the queue is filled.

Inter-arrival time protection for extended Tasks controls the time between successive

activations and releases. When a Task is in the WAITING state and multiple Events

are set with a single call to SetEvent this represents a single release. When a Task

waits for one or more Events which are already set this represents a notional Wait/

Release/Start transition and therefore is considered as a new release.

The following figure shows how execution time protection and inter-arr ival time protec-

tion interact with the task state transition model for AUTOSAR OS.

Figure 7.13: Time protection interaction with the task state transition model

69 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Notes:

1. Inter-arrival time enforcement on Category 2 ISRs can be used to protect an

ECU from a "babbling idiot" source of interrupts (e.g. a CAN controller taking an

interrupt each time a frame is received from another ECU on the network).

2. Timing protection only applies to Tasks or Category 2 ISRs. There is no pro-

tection for Category 1 ISRs. If timing protection error occurs during a category 1

ISR, consistency of the Operating System module cannot be guaranteed. There-

fore we discourage timing protection in systems with category 1 interrupts.

3. Timing protection does not apply before the Operating System module is started.

4. In the case of trusted OS-Applications it is essential that all timing information

is correct, otherwise the system may fail at run-time. For a non-trusted OS-

Application, timing protection can be used to enforce timing boundaries between

executable objects.

7.7.2.2 Requirements

[SWS_Os_00028] dIn a non-trusted OS-Application, the Operating System module

shall apply timing protection to every Task/Category 2 ISR of this non-trusted OS-

Application.c(SRS_Os_11008)

[SWS_Os_00089] dIn a trusted OS-Application, the Operating System module shall

provide the ability to apply timing protection to Tasks/Category 2 ISRs of this OS-

Application.c(SRS_Os_11008)

[SWS_Os_00397] dIf no OS-Application is configured, the Operating System module

shall be able to apply timing protection to Tasks/Category 2 ISRs.c()

Timing Protection: Tasks

[SWS_Os_00064] dIf a Task’s OsTaskExecutionBudget is reached

then the Operating System module shall call the ProtectionHook with

E_OS_PROTECTION_TIME.c(SRS_Os_11008, SRS_Os_11013)

[SWS_Os_00473] dThe Operating System module shall reset a Task’s OsTaskEx-

ecutionBudget on a transition to the SUSPENDED or WAITING states.c(SRS_Os_-

11008)

[SWS_Os_00465] dThe Operating System module shall limit the inter-arrival time of

Tasks to one per OsTaskTimeFrame.c(SRS_Os_11008)

[SWS_Os_00469] dThe Operating System module shall start an OsTaskTimeFrame

when a Task is activated successfully.c(SRS_Os_11008)

[SWS_Os_00472] dThe Operating System module shall start an OsTaskTimeFrame

when a Task is released successfully.c(SRS_Os_11008)

70 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

[SWS_Os_00466] dIf an attempt is made to activate a Task before the end of an Os-

TaskTimeFrame then the Operating System module shall not perform the activation

AND shall call the ProtectionHook with E_OS_PROTECTION_ARRIVAL.c()

[SWS_Os_00467] dIf an attempt is made to release a Task before the end of an

OsTaskTimeFrame then the Operating System module shall not perform the release

AND shall call the ProtectionHook with E_OS_PROTECTION_ARRIVAL AND the

event shall be set.c()

Timing Protection: ISRs

[SWS_Os_00210] dIf a Category 2 ISR’s OsIsrExecutionBudget is reached

then the Operating System module shall call the ProtectionHook with

E_OS_PROTECTION_TIME.c(SRS_Os_11013)

[SWS_Os_00474] dThe Operating System module shall reset an ISR’s OsIsrExecu-

tionBudget when the ISR returns control to the OS or terminates.c(SRS_Os_11008)

[SWS_Os_00470] dThe Operating System module shall limit the inter-arrival time of

Category 2 ISRs to one per OsIsrTimeFrame.c(SRS_Os_11008)

[SWS_Os_00471] dThe Operating System module shall measure the start of an Os-

IsrTimeFrame from the point at which it recognizes the interrupt (i.e. in the Operating

System interrupt wrapper).c(SRS_Os_11008)

[SWS_Os_00048] dIf Category 2 interrupt occurs before the end of the OsIsrTime-

Frame then the Operating System module shall not execute the user provided ISR

AND shall call the ProtectionHook with E_OS_PROTECTION_ARRIVAL.c(SRS_-

Os_11008)

Timing Protection: Resource Locking and Interrupt Disabling

[SWS_Os_00033] dIf a Task/Category 2 ISR holds an OSEK Resource

and exceeds the OsTaskResourceLockBudget (or OsIsrResourceLockBud-

get) , the Operating System module shall call the ProtectionHook with

E_OS_PROTECTION_LOCKED.c(SRS_Os_11008, SRS_Os_11013, SRS_Os_11014)

[SWS_Os_00037] dIf a Task/Category 2 ISR disables interrupts (via Suspend/Dis-

able|All/OS|Interrupts()) and exceeds the configured OsIsrAllInterruptLock-

Budget (or OsIsrOsInterruptLockBudget or OsTaskAllInterruptLockBud-

get or OsTaskOsInterruptLockBudget) the Operating System module shall call

the ProtectionHook with E_OS_PROTECTION_LOCKED.c(SRS_Os_11008, SRS_-

Os_11013, SRS_Os_11014)

7.7.2.3 Implementation Notes

Execution time enforcement requires hardware support, e.g. a timing enforcement

interrupt. If an interrupt is used to implement the time enforcement, the priority of this

interrupt has to be high enough to "interrupt" the supervised Tasks or ISRs.

71 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Depending on the real hardware support this could mean that DisableAllInter-

rupts and SuspendAllInterrupts disable not all interrupts (e.g. all interr upts

except of the interrupt used for timing protection) or that the usage of Category 1 ISRs

- which bypass the Operating System (and also the timing protection) - is limited some-

how.

The implementation has to document such implementation specific behaviour (e.g. the

limitations when timing protection is used).

7.7.3 Service Protection

7.7.3.1 Background & Rationale

As OS-Applications can interact with the Operating System module through services,

it is essential that the service calls will not corrupt the Operating System module itself.

Service Protection guards against such corruption at runtime.

There are a number of cases to consider with Service Protection: An OS-Application

makes an API call

1. with an invalid handle or out of range value.

2. in the wrong context, e.g. calling ActivateTask in the StartupHook.

3. or fails to make an API call that results in the OSEK OS being left in an undefined

state, e.g. it terminates without a ReleaseResource call

4. that impacts on the behaviour of every other OS-Application in the system, e.g.

ShutdownOS

5. to manipulate Operating System objects that belong to another OS-Application

(to which it does not have the necessary permissions), e.g. an OS-Application

tries to execute ActivateTask on a Task it does not own.

The OSEK OS already provides some service protection through the status codes

returned from service calls and this will provide the basis for service protection. This

means that service protection will only apply for the extended status of OSEK OS.

However, OSEK OS does not cover all the cases outlined above. The following sections

describe - besides the mandatory extended status - the additional protection require-

ments to be applied in each of these cases.

72 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

7.7.3.2 Invalid Object Parameter or Out of Range Value

7.7.3.2.1 Background & Rationale

The current OSEK OS service calls already return E_OS_ID on invalid objects (i.e.

objects not defined in the OIL file) and E_OS_VALUE for out of range values (e.g. setting

an alarm cycle time less than OsCounterMinCycle).

7.7.3.2.2 Requirements

[SWS_Os_00051] dIf an invalid address (address is not writable by this OS-

Application) is passed as an out-parameter to an Operating System service, the Oper-

ating System module shall return the status code E_OS_ILLEGAL_ADDRESS.c(SRS_-

Os_11009, SRS_Os_11013)

7.7.3.3 Service Calls Made from Wrong Context

7.7.3.3.1 Background & Rationale

The current OSEK OS defines the valid calling context for service calls (see [2]), how-

ever protects against only a small set of these invalid calls, e.g. calling Terminate-

Task from a Category 2 ISR.

Service

Task

Cat1 ISR

Cat2 ISR

ErrorHook

PreTaskHook

PostTaskHook

StartupHook

ShutdownHook

Alarm Callback

ProtectionHook

ActivateTask

OK OK

ActivateTaskAsyn

OK OK

TerminateTask

OK C

ChainTask OK C

Schedule OK C

GetTaskID OK OK OK OK OK OK

GetTaskState OK OK OK OK OK

DisableAllInterrupts

OK OK OK OK OK OK OK OK OK OK

EnableAllInterrupts

OK OK OK OK OK OK OK OK OK OK

SuspendAllInterrupts OK OK OK OK OK OK OK OK OK OK

ResumeAllInterrupts

OK OK OK OK OK OK OK OK OK OK

SuspendOSInterrupts OK OK OK OK OK OK OK OK OK OK

ResumeOSInterrupts OK OK OK OK OK OK OK OK OK OK

GetResource OK OK

ReleaseResource

OK OK

SetEvent OK OK

SetEventAsyn OK OK

73 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

ClearEvent OK C

GetEvent OK OK OK OK OK

WaitEvent

OK C

GetAlarmBase OK OK OK OK OK

GetAlarm OK OK OK OK OK

SetRelAlarm OK OK

SetAbsAlarm OK OK

CancelAlarm OK OK

GetActiveApplicationMode OK OK OK OK OK OK OK

StartOS

ShutdownOS OK OK OK OK

GetApplicationID OK OK OK OK OK OK OK OK

GetISRID OK OK OK OK

CallTrustedFunction OK OK

CheckISRMemoryAccess OK OK OK OK

CheckTaskMemoryAccess OK OK OK OK

CheckObjectAccess OK OK OK OK

CheckObjectOwnership OK OK OK OK

StartScheduleTableRel OK OK

StartScheduleTableAbs OK OK

StopScheduleTable OK OK

NextScheduleTable OK OK

StartScheduleTableSynchron OK OK

SyncScheduleTable OK OK

GetScheduleTableStatus OK OK

SetScheduleTableAsync OK OK

IncrementCounter OK OK

GetCounterValue OK OK

GetElapsedValue OK OK

TerminateApplication

OK OK

AllowAccess

OK OK

GetApplicationState OK OK OK OK OK OK OK OK

ControlIdle OK OK

GetCurrentApplicationID OK OK OK OK OK OK OK OK

ReadPeripheral8

OK OK

ReadPeripheral16

OK OK

ReadPeripheral32

OK OK

WritePeripheral8

OK OK

WritePeripheral16

OK OK

WritePeripheral32

OK OK

ModifyPeripheral8 OK OK

ModifyPeripheral16 OK OK

ModifyPeripheral32 OK OK

DisableInterruptSource OK OK

EnableInterruptSource OK OK

ClearPendingInterrupt OK OK

Table 7.1: Allowed Calling Context for OS Ser vice Calls

Only in case of self termination.

74 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

In the table above "C" indicates that validity is only "Checked in Extended status by

E_OS_CALLEVEL" .

7.7.3.3.2 Requirements

[SWS_Os_00088] dIf an OS-Application makes a service call from the wrong con-

text AND is currently not inside a Category 1 ISR the Operating System module shall

not perform the requested action (the service call shall have no effect) and return

E_OS_CALLEVEL or the "invalid value" of the service.c(SRS_Os_11009, SRS_Os_-

11013)

7.7.3.4 Services with Undefined Behaviour

7.7.3.4.1 Background & Rationale

There are a number of situations where the behaviour of OSEK OS is undefined in

extended status. This is unacceptable when protection is required as it would allow the

Operating System module to be corrupted through its own service calls. The implemen-

tation of service protection for the Operating System module must therefore describe

and implement a behaviour that does not jeopardize the integrity of the system or of

any OS-Application which did not cause the specific error.

7.7.3.4.2 Requirements

Tasks ends without calling a TerminateTask or ChainTask

[SWS_Os_00052] dIf a Task returns from its entry function without making a Termi-

nateTask or ChainTask call, the Operating System module shall terminate the Task

(and call the OsPostTaskHook if configured).c(SRS_Os_11009)

[SWS_Os_00069] dIf a Task returns from its entry function without making a Termi-

nateTask or ChainTask call AND the error hook is configured, the Operating System

module shall call the ErrorHook (this is done regardless of whether the Task causes

other errors, e.g. E_OS_RESOURCE) with status E_OS_MISSINGEND before the Task

leaves the RUNNING state.c(SRS_Os_11009)

[SWS_Os_00070] dIf a Task returns from the entry function without making a Termi-

nateTask or ChainTask call and still holds OSEK Resources, the Operating System

module shall release them.c(SRS_Os_11009, SRS_Os_11013)

[SWS_Os_00239] dIf a Task returns from the entry function without making a Termi-

nateTask or ChainTask call and interrupts are still disabled, the Operating System

module shall enable them.c()

75 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Category 2 ISR ends with locked interrupts or allocated resources

[SWS_Os_00368] dIf a Category 2 ISR calls DisableAllInterrupts / Sus-

pendAllInterrupts / SuspendOSInterrupts and ends (returns) without call-

ing the corresponding EnableAllInterrupts / ResumeAllInterrupts / Re-

sumeOSInterrupts, the Operating System module shall perform the missing service

and shall call the ErrorHook (if configured) with the status E_OS_DISABLEDINT.c()

[SWS_Os_00369] dIf a Category 2 ISR calls GetResource and ends (returns) with-

out calling the corresponding ReleaseResource, the Operating System module shall

perform the ReleaseResource call and shall call the ErrorHook (if configured) with

the status E_OS_RESOURCE (see [12], section 13.1).c()

PostTaskHook called during ShutdownOS

[SWS_Os_00071] dIf the PostTaskHook is configured, the Operating System module

shall not call the hook if ShutdownOS is called.c()

Tasks/ISRs calls EnableAllInterrupts/ResumeAllInterrupts/ResumeOSIn-

terrupts without a corresponding disable

[SWS_Os_00092] dIf EnableAllInterrupts / ResumeAllInterrupts / Re-

sumeOSInterrupts are called and no corresponding DisableAllInterrupts /

SuspendAllInterrupts / SuspendOSInterrupts was done before, the Operat-

ing System module shall not perform this Operating System service.c(SRS_Os_11009)

Tasks/ISRs calling OS services when DisableAllInterupts/SuspendAllInterrupts/

SuspendOSInterrupts called

[SWS_Os_00093] dIf interrupts are disabled/suspended by a Task/ISR/Hook and

the Task/ISR/Hook calls any Operating System service (excluding the interrupt ser-

vices) then the Operating System module shall ignore the service AND shall return

E_OS_DISABLEDINT if the service returns a StatusType value.c(SRS_Os_11009,

SRS_Os_11013)

7.7.3.5 Service Restrictions for Non-Trusted OS-Applications

7.7.3.5.1 Background & Rationale

The Operating System service calls available are restricted according to the calling

context (see 7.7.3.3). In a protected system, additional constraints need to be placed to

prevent non-trusted OS-Applications executing API calls that can have a global effect

on the system. Each level of restriction is a proper subset of the previous level as

shown in the figure below.

76 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Figure 7.14: API Restrictions

There are two defined integrity levels:

1. Trusted

2. Non-Trusted

that correspond exactly with trusted and non-trusted OS-Applications.

7.7.3.5.2 Requirements

[SWS_Os_00054] dThe Operating System module shall ignore calls to ShutdownOS

from non-trusted OS-Applications.c()

7.7.3.6 Service Calls on Objects in Different OS-Applications

7.7.3.6.1 Background

Section 7.7.3.2 stated that E_OS_ID is returned by OSEK OS service calls when the

object is invalid. Under the protection scheme a service call can be invalid because

77 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

the caller does not have valid per missions for the object (a new meaning for multi-OS-

Application systems).

This is a similar case to an object not being accessible in OSEK OS (for example, when

a Task tries to get a Resource which exists in the system but has not been configured

as used by the Task).

7.7.3.6.2 Requirements

[SWS_Os_00056] dIf an OS-object identifier is the parameter of an Operating Sys-

tem module’s system service, and no sufficient access rights have been assigned

to this OS-object at configuration time (parameter Os[...]AccessingApplication, e.g.

OsTaskAccessingApplication) to the calling Task/Category 2 ISR, the Operat-

ing System module’s system service shall return E_OS_ACCESS.c(SRS_Os_11001,

SRS_Os_11010, SRS_Os_11013)

[SWS_Os_00449] dCheckTaskMemoryAccess and CheckISRMemoryAccess

check the memory access. Memory access checking is possible for all OS-Applications

and from all OS-Applications and does not need granted rights.c()

[SWS_Os_00449] is an exception to [SWS_Os_00056].

[SWS_Os_00450] dCheckObjectAccess checks the access rights for Operating

System objects. Checking object access is possible for all OS-Applications and from

all OS-Applications and does not need granted rights.c()

[SWS_Os_00450] is an exception to [SWS_Os_00056].

7.7.4 Protecting the Hardware used by the OS

7.7.4.1 Background & Rationale

Where a processor supports privileged and non-privileged mode it is usually the case

that certain registers, and the instructions to modify those registers, are inaccessible

outside the privileged mode.

On such hardware, executing the Operating System module in privileged mode and

Tasks/ISRs in non-privileged mode protects the registers fundamental to Operating

System module operation from inadvertent corruption by the objects executing in non-

privileged mode. The Operating System module’s services will need to execute in

privileged mode as they will need to modify the registers that are protected outside this

mode.

The Operating System module can use the control registers of the MPU, timer unit(s),

interrupt controller, etc. and therefore it is necessary to protect those registers against

non-trusted OS-Applications.

78 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

7.7.4.2 Requirements

[SWS_Os_00058] dIf supported by hardware, the Operating System module shall ex-

ecute non-trusted OS-Applications in non-privileged mode.c()

[SWS_Os_00096] dAs far as supported by hardware, the Operating System module

shall not allow non-trusted OS-Applications to access control registers managed by the

Operating System module.c(SRS_Os_11011)

[SWS_Os_00245] dIf an instruction exception occurs (e.g. division by

zero) the Operating System module shall call the protection hook with

E_OS_PROTECTION_EXCEPTION.c(SRS_Os_11011)

7.7.4.3 Implementation Notes

When the Operating System module is running non-tr usted OS-Applications, the Oper-

ating System module’s treatment of interrupt entry and hook routines must be carefully

managed.

Interrupt handling: Where the MCU supports different modes (as discussed in this

section) ISRs will require the Operating System module to do extra work in the ISR()

wrapper. ISRs will typically be entered in privileged mode. If the handler is part of a

non-trusted OS-Application then the ISR() wrapper must make sure that a switch to

non-privileged mode occurs before the handler executes.

7.7.5 Providing Trustedfunctions

7.7.5.1 Background & Rationale

An OS-Application can invoke a Trustedfunction provided by (another) trusted OS-

Application. That can require a switch from non-privileged to privileged mode. This is

typically achieved by these operations:

• Each trusted OS-Application may export services which are callable from other

OS-Applications.

• During configuration these trusted services must be configured to be called from

a non-trusted OS-Application.

• The call from the non-trusted OS-Application to the trusted service is using a

mechanism (e.g. trap/software interrupt) provided by the Operating System. The

service is passed as an identifier that is used to determine, in the trusted envi-

ronment, if the service can be called.

• The Operating System offers services to check if a memory region is write/read/

execute accessible from an OS-Application. It also returns information if the

memory region is part of the stack space.

79 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

The Operating System software specification does not provide support for non-trusted

services.

7.7.5.2 Requirements

[SWS_Os_00451] dThe Operating System module shall allow exporting services from

trusted OS-Applications.c()

The Operating System module provides the service CallTrustedFunction (see

[SWS_Os_00097]) to call a trusted function from a (trusted or non-trusted) OS-

Application.

[SWS_Os_00100] dIf CallTrustedFunction is called and the called trusted func-

tion is not configured the Operating System module shall call the ErrorHook with

E_OS_SERVICEID.c()

The Operating System module provides the services CheckISRMemoryAccess and

CheckTaskMemoryAccess (see [SWS_Os_00512] and [SWS_Os_00513]) for OS-

Applications to check if a memory region is write/read/execute accessible from a Task/

Category 2 ISR and also return information if the memory region is part of the stack

space.

7.8 Protection Error Handling

7.8.1 Background & Rationale

The Operating System can detect protection errors based on statically configured in-

formation on what the constituent parts of an OS-Application can do at runtime. See

section 7.7.

Unlike monitoring, protection facilities will trap the erroneous state at the point the error

occurs, resulting in the shortest possible time between transition into an erroneous

state and detection of the fault. The different kinds of protection errors are descr ibed

in the glossary. If a protection error occurs before the Operating System module is

started the behaviour is not defined. If a protection error happens during shutdown,

e.g. in the application-specific shutdown hook, an endless loop between the shutdown

service and the protection hook may occur.

In the case of a protection error, the Operating System module calls a user provided

ProtectionHook for the notification of protection errors at runtime. The Protec-

tionHook runs in the context of the Operating System module and must therefore be

trusted code.

The Operating System module itself needs only to detect an error and provide the abil-

ity to act. The ProtectionHook can select one out of four options the Operating

80 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

System module provides, which will be performed after retur ning from the Protec-

tionHook, depending on the retur n value of the ProtectionHook. The options are:

1. do nothing

2. forcibly terminate the faulty Task/Category 2 ISR

3. forcibly terminate all Tasks and ISRs in the faulty OS-Application

• without restart of the OS-Application

• with restart of the OS-Application

4. shutdown the Operating System module.

Requirements [SWS_Os_00243] and [SWS_Os_00244] define the order of the default

reaction if no faulty Task/Category 2 ISR or OS-Application can be found, e.g. in the

system specific hook routines. Also OS-Applications are only mandatory in Scalability

Classes 3 and 4, therefore in other Scalability Classes OS-Applications need not be

defined.

Note that forcibly terminating interrupts is handled differently in "forcibly terminate the

faulty ISR" and "forcibly terminate the OS-Application". If a faulty ISR is forcibly ter-

minated, the current invocation of the ISR is terminated. A subsequent invocation is

allowed. If the OS-Application is forcibly terminated, then the interrupt source is also

disabled, preventing subsequent interrupts.

Notes regarding the return value PRO_IGNORE

The meaning of "do nothing" (PRO_IGNORE) means that the error reaction is ignored.

The PRO_IGNORE is only allowed in specific situations (currently: arrival rate errors).

After the error is detected (e.g. as specified in [SWS_Os_00466] or [SWS_Os_00467])

the protection hook is called. If the hook returns with PRO_IGNORE the OS does con-

tinue its normal operation. If a service call was the root cause of the violation (e.g.

an ActivateTask) and protection hook returns PRO_IGNORE the ser vice call shall

continue its operation (e.g. to activate a Task) and return E_OK (if successful and

possible).

Example 1: A Task calls ActivateTask(B) and causes an arrival rate violation. The

activation is not performed ([SWS_Os_00466]) and protection hook is called. When

returning PRO_IGNORE the OS continues and the ActivateTask service activates B

and returns E_OK.

Example 2: A Task A calls SetEvent for Task B (which currently waits for the event).

The OS detects ([SWS_Os_00467]) an arrival rate violation and performs a call of

the protection hook. When the call returns with PRO_IGNORE, the SetEvent service

continues and sets the event. Task B changes to READY state and a rescheduling

might happen. The SetEvent service call will return E_OK to Task A.

81 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

7.8.2 Requirements

[SWS_Os_00211] dThe Operating System module shall execute the Protection-

Hook with the same permissions as the Operating System module.c()

[SWS_Os_00107] dIf no ProtectionHook is configured and a protection error oc-

curs, the Operating System module shall call ShutdownOS.c(SRS_Os_11014)

[SWS_Os_00106] dIf the ProtectionHook returns PRO_IGNORE and was called with

E_OS_PROTECTION_ARRIVAL the Operating System module shall return control to

the user application.c(SRS_Os_11014)

[SWS_Os_00553] dIf the ProtectionHook returns PRO_TERMINATETASKISR the

Operating System module shall forcibly terminate the faulty Task/Category 2 ISR.c()

[SWS_Os_00554] dIf the ProtectionHook returns PRO_TERMINATEAPPL the Oper-

ating System module shall forcibly terminate the faulty OS-Application.c()

[SWS_Os_00555] dIf the ProtectionHook returns

PRO_TERMINATEAPPL_RESTART the Operating System module shall forcibly

terminate the faulty OS-Application and afterwards restart the OS-Application.c

(SRS_Os_11023)

[SWS_Os_00556] dIf the ProtectionHook returns PRO_SHUTDOWN the Operating

System module shall call the ShutdownOS.c()

[SWS_Os_00506] dIf the ProtectionHook is called with

E_OS_PROTECTION_ARRIVAL the only valid return values are PRO_IGNORE or

PRO_SHUTDOWN

. Returning other values will result in a call to ShutdownOS.c()

[SWS_Os_00475] dIf the ProtectionHook returns PRO_IGNORE and the Protec-

tionHook was not called with E_OS_PROTECTION_ARRIVAL then the Operating Sys-

tem module shall call ShutdownOS.c()

[SWS_Os_00243] dIf the ProtectionHook returns PRO_TERMINATETASKISR and

no Task or ISR can be associated with the error, the running OS-Application is forcibly

terminated by the Operating System module. If even no OS-Application can be as-

signed, ShutdownOS is called.c(SRS_Os_11014)

[SWS_Os_00244] dIf the ProtectionHook returns PRO_TERMINATEAPPL or

PRO_TERMINATEAPPL_RESTART and no OS-Application can be assigned, Shut-

downOS is called.c(SRS_Os_11014)

[SWS_Os_00557] dIf the ProtectionHook returns

PRO_TERMINATEAPPL_RESTART and no OsRestartTask was configured for

the faulty OS-Application, ShutdownOS is called.c()

[SWS_Os_00108] dIf the Operating System module forcibly terminates a Task,

it terminates the Task, releases all allocated OSEK resources and calls

The reason for this case is that the Task which is supervised is not necessary active (and can not

be e.g. terminated) and it can be that the caller of the activation is the real problem.

82 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

EnableAllInterrupts/ ResumeOSInterrupts / ResumeAllInterrupts if

the Task called DisableAllInterrupts / SuspendOSInterrupts / Sus-

pendAllInterrupts before without the corresponding EnableAllInterrupts/

ResumeOSInterrupts / ResumeAllInterrupts call.c(SRS_Os_11014)

[SWS_Os_00109] dIf the Operating System module forcibly terminates an interrupt

service routine, it clears the interrupt request, aborts the interrupt service routine (The

interrupt source stays in the current state.) and releases all OSEK resources the inter-

rupt service routine has allocated and calls EnableAllInterrupts / ResumeOSIn-

terrupts / ResumeAllInterrupts if the interrupt called DisableAllInter-

rupts / SuspendOSInterrupts / SuspendAllInterrupts before without the cor-

responding EnableAllInterrupts/ ResumeOSInterrupts / ResumeAllInter-

rupts call.c(SRS_Os_11014)

[SWS_Os_00110] dIf the Operating System module shall forcibly terminate an OS-

Application, it: shall

• forcibly terminate all Tasks/ISRs of the OS-Application AND

• cancel all alarms of the OS-Application AND

• stop ScheduleTables of the OS-Application AND

• disable interrupt sources of Category 2 ISRs belonging to the OS-Application

c(SRS_Os_11014)

[SWS_Os_00111] dWhen the Operating System module restarts an OS-Application, it

shall activate the configured OsRestartTask.c()

7.9 Operating System for Multi-Core

This chapter specifies some extensions that allow to use an AUTOSAR system on

Multi-Core micro-processors. It describes the main philosophy as well as additional

extensions to the existing OS functionality regarding Multi-Core. The following chap-

ter contains a specification of a new mechanism within the OS called IOC (Inter OS-

Application Communicator) that supports the communication between OS-Applications

located on the same or on different cores

7.9.1 Background & Rationale

The existing AUTOSAR-OS is based on the OSEK/VDX Operating System which is

widely used in the automotive industry. The AUTOSAR Multi-Core OS is derived from

the existing AUTOSAR OS.

83 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

The Multi-Core OS in AUTOSAR is not a virtual ECU concept, instead it shall be under-

stood as an OS that shares the same configuration and most of the code but operates

on different data structures for each core.

To reduce the memory footprint all cores should use the same code base. Sometimes

it can be beneficial to spend some more ROM/Flash, e.g. to use a local ROM, and

"double" parts of the code to get faster ROM/Flash access.

7.9.1.1 Requirements

[SWS_Os_00567] dThe generated part of the OS is derived from a single configuration

that contains the relevant information for all cores. This implies, that IDs (e.g. TaskID,

ResourceID, . . . ) are unique across cores. Every ID shall refer exactly to one entity

independent from the core on which the entity is accessed. This applies also to objects

that cannot be shared between cores.c(SRS_Os_80008)

7.9.2 Scheduling

The priority of the Tasks drives the scheduling. Since multiple cores run truly parallel,

several Tasks can execute at the same time.

Figure 7.15: Priorities are assigned to Tasks. The cores schedule independently from

each other. The Tasks T2, T3 and T5 are executed in true parallelism. Tasks with the

same priority on the same core will be executed in order of activation; Tasks with the

same priority on different cores may not be executed in the order of activation, since the

cores schedule independent from each other.

84 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

The OS can be entered on each core in parallel. This optimizes scalability towards

multiple cores. The cores schedule independently. This implies that the schedule on

one core does not consider the scheduling on the other cores

. A low priority Task on

one core may run in parallel with a high priority Task on another core.

Tasks and ISRs cannot dynamically change cores by means of the scheduling algo-

rithm.

7.9.2.1 Requirements

[SWS_Os_00568] dImplementations shall be able to independently execute a Task or

an ISR on each started AUTOSAR OS core in parallel.c(SRS_Os_80001)

[SWS_Os_00569] dThe scheduling strategy as defined in AUTOSAR OS shall apply

for each individual core in a Multi-Core system, for the Tasks and ISR assigned to the

core.c(SRS_Os_80001, SRS_Os_80013)

7.9.3 Locatable entities (LE)

A locatable entity is an entity that has to be located entirely on one core. The assign-

ment of LEs to cores is defined at configuration time (OsApplicationCoreRef).

In this release of the AUTOSAR standard OS-Applications shall be the LEs. Because

every Task has to run on some core, the usage of OS-Applications becomes obligatory

in AUTOSAR R4.0 for Multi-Core systems. BSW modules are not allowed to ignore OS-

Applications, even if they do not use any protection mechanisms. This is independent

from the SC class.

As is stated in the AUTOSAR Specification of the Operating System, if OS-Applications

are used, all Tasks, ISR etc. must belong to an OS-Application. This implies, that no

AUTOSAR software exists outside of an OS-Application in Multi-Core systems.

On single-core systems OS-Applications are available only for SC3 and SC4 because

the mechanism is used to support memory protection and implies the usage of ex-

tended mode. In Multi-core systems OS-Applications are always available independent

of memory protection and on SC1 standard mode shall be possible.

7.9.3.1 Requirements

[SWS_Os_00570] dAll Tasks that are assigned to the same OS-Application shall exe-

cute on the same core.c(SRS_Os_80003, SRS_Os_80005)

This also applies to Tasks with the same priority, bound to different cores. It also means that non-

preemptive Tasks cannot be preempted on the core they are running, but Tasks on other cores can run

in parallel.

85 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

[SWS_Os_00571] dAll ISRs that are assigned to the same OS-Application shall exe-

cute on the same core.c(SRS_Os_80003, SRS_Os_80005)

[SWS_Os_00572] dISR balancing (if supported by the HW) shall be switched off at

boot time by the OS.c(SRS_Os_80005, SRS_Os_80006)

[SWS_Os_00764] dThe OS module shall support OS-Applications in case of Multi-

Core also for SC1 and SC2.c()

[SWS_Os_00763] dIn an SC1 system standard mode shall be possible.c()

[SWS_Os_00573] dThe binding of OS-Applications to cores shall be configured within

the OS-Application container.c(SRS_Os_80003, SRS_Os_80005)

A new configuration item: OsApplicationCoreRef within the OS-Application con-

tainer shall be used to define the core to which the OS-Application is bound. The OS

generator will map the configuration parameter "CORE" to a certain core, so that all

OS-Applications with the same configuration parameter reside on the same core.

7.9.4 Multi-Core start-up concept

The way cores are started depends heavily on the hardware. Typically the hardware

only starts one core, referred as the master core, while the other cores (slaves) remain

in halt state until they are activated by the software.

In contrast to such a master-slave system other boot concepts with cores that start

independently from each other are conceivable. However it is possible to emulate

master-slave behavior on such systems by software.

The AUTOSAR Multi-Core OS specification requires a system with master-slave start-

up behavior, either supported directly by the hardware or emulated in software. The

master core is defined to be the core that requires no software activation, whereas a

slave core requires activation by software.

In Multi-Core configurations, each slave core that is used by AUTOSAR must be acti-

vated before StartOS is entered on the core. Depending on the hardware, it may be

possible to only activate a subset of the available cores from the master. The slave

cores might activate additional cores before calling StartOS. All cores that belong to

the AUTOSAR system have to be activated by the designated AUTOSAR API function.

Additionally, the StartOS function has to be called on all these cores.

If a core is activated it executes some HW and compiler specific operations, before the

"main" function is called. In case the same "main" function is executed on each core,

the cores have to be differentiated by their specific core Id within the function.

Example:

1 void main ()

2 {

3 StatusType rv;

86 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

5 /

...

7 switch (GetCoreID())

8 {

10 case OS_CORE_ID_MASTER:

11 /

...

13 StartCore(OS_CORE_ID_0, &rv);

14 StartOS(OSDEFAULTAPPMODE);

15 break;

17 case OS_CORE_ID_0:

18 /

...

20 StartCore(OS_CORE_ID_1, &rv);

21 StartOS(DONOTCARE);

22 break;

24 otherwise:

26 StartOS(DONOTCARE);

28 }

29 }

StartOS synchronizes all cores twice. The first synchronization point is located before

the StartupHooks are executed, the second after the OS-Application specific Star-

tupHooks have finished and before the scheduler is started. The exact point where the

second synchronization occurs depends on the implementation, but it shall be before

the scheduling is started. This release of the AUTOSAR specification does not support

timeouts during the synchronization phase. Cores that are activated with StartCore

but do not call StartOS may cause the system to hang. It is in the responsibility of the

integrator to avoid such behavior.

As shown in figure 7.16, the StartupHook is called on every core r ight after the first

synchronization. However, there is only one StartupHook in the system. If, for exam-

ple, core-individual functionality must be executed during StartupHook the GetCor-

eID function can be used to discriminate the individual cores. After the global Star-

tupHook has finished each core performs the StartupHooks of its OS-Applications .

Since OS-Applications are bound to cores the OS-Application specific StartupHooks

are executed only on the core to which the corresponding OS-Application is bound.

87 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Figure 7.16: This figure shows an example of an initialization process with 4 cores

7.9.4.1 Requirements

[SWS_Os_00574] dThe master core shall be able to activate cores.c(SRS_Os_80006)

[SWS_Os_00575] dAny slave core shall be able to activate cores.c(SRS_Os_80006)

[SWS_Os_00576] dIt shall be allowed to use only a subset of the cores available on a

µC for the AUTOSAR system.c(SRS_Os_80006)

[SWS_Os_00577] dThe cores shall boot in master-slave mode. If this is not supported

by the hardware, it shall be that the cores boot in parallel and emulate the behavior of

a master-slave system.c(SRS_Os_80006)

[SWS_Os_00578] dIn case of an emulation a slave core (CoreS), which is controlled by

the AUTOSAR OS (AUTOSAR core), shall not enter the main function before another

core has activated the slave core by means of StartCore(CoreS).c(SRS_Os_80006)

[SWS_Os_00579] dAll cores that belong to the AUTOSAR system shall be synchro-

nized within the StartOS function before the scheduling is started and after the global

StartupHook is called.c(SRS_Os_80001, SRS_Os_80006)

[SWS_Os_00580] dAll cores that belong to the AUTOSAR system shall be synchro-

nized within the StartOS before the global StartupHook is called.c(SRS_Os_80006)

[SWS_Os_00581] dThe global StartupHook shall be called on all cores immediately

after the first synchronization point.c(SRS_Os_80006)

[SWS_Os_00582] dThe OS-Application-specific StartupHooks shall be called after

the global StartupHook but only on the cores to which the OS-Application is bound.c

(SRS_Os_80006, SRS_Os_80008)

88 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

7.9.5 Cores under control of the AUTOSAR OS

The AUTOSAR OS controls several cores as stated above. It need not control all cores

of a µC, however. The maximum number of controlled cores shall be configured within

the OsOS section of the configuration.

The AUTOSAR OS API provides a StartCore function to start the cores under its

control. The StartCore function takes a scalar value parameter of type CoreIdType,

specifying the core that shall be started. StartCore can be called more than once on

the master core and also on slave cores. Each core can only be started once, however.

For example:

1 StartusType rv1, rv2;

2 StartCore(OS_CORE_ID_1, &rv1);

3 StartCore(OS_CORE_ID_2, &rv2);

4 if (rv1 != E_OK) || (rv2 != E_OK)

5 EnterPanicMode();

6 StartOS(OSDEFAULTAPPMODE);

The StartOS function shall be called on all cores that have been activated by Start-

Core. It is not allowed to call StartCore from a core that has already called StartOS.

Cores that belong to the AUTOSAR system shall be started by the designated

AUTOSAR OS API service StartCore.

7.9.5.1 Requirements

[SWS_Os_00583] dThe number of cores that can be controlled by the AUTOSAR OS

shall be configured offline.

A new configuration item (OsNumberOfCores) within the OsOS container is used to

specify the maximum number of cores that are controlled by the AUTOSAR OS. If no

value for OsNumberOfCores has been specified the number of cores shall be one.c

(SRS_Os_80001, SRS_Os_80011)

7.9.6 Multi-Core shutdown concept

AUTOSAR supports two shutdown concepts, the synchronized shutdown and the in-

dividual shutdown concept. While the synchronized shutdown is triggered by the new

API function ShutdownAllCores, the individual shutdown is invoked by the existing

API function ShutdownOS.

7.9.6.1 Synchronized shutdown concept

If a Task with the proper rights calls ShutdownAllCores, a signal is sent to all other

cores to induce the shutdown procedure. Once the shutdown procedure has started

89 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

on a core, interrupts and Tasks are not further processed, and no scheduling will take

place, therefore it makes no sense to activate any Task, however no error will be

generated. It is in the responsibility of the application developer/system integrator to

make sure that any preparations for shutdown on application and basic software level

are completed before calling ShutdownAllCores (e.g. by means of the ECU state

manager).

During the shutdown procedure every core executes its OS-Application specific Shut-

downHook functions, followed by a synchronization point. After all cores have reached

the synchronization point the global ShutdownHook function is executed by all cores

in parallel.

Figure 7.17: Example of a shutdown procedure

[SWS_Os_00586] dDuring the shutdown, the OS-Application specific ShutdownHook

shall be called on the core on which the corresponding OS-Application is bound.c

(SRS_Os_80007)

[SWS_Os_00587] dBefore calling the global ShutdownHook, all cores shall be syn-

chronized.c(SRS_Os_80007)

[SWS_Os_00588] dThe global ShutdownHook shall be called on all cores.c(SRS_-

Os_80007)

7.9.6.2 Individual shutdown concept

If a Task calls ShutdownOS the OS will be shut down on the core on which Shut-

downOS has been called. Every core shall be able to invoke ShutdownOS . Similar to

StartOS this function will shutdown the individual core. To shutdown the whole ECU

ShutdownOS has to be called on every core. The function will not return.

Individual shutdown is not supported in AUTOSAR R4.x (AUTOSAR mode manage-

ment will not use it).

90 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

7.9.6.3 Shutdown in case of fatal internal errors

In multicore systems it can happen that a fatal internal OS error is detected only on

one core. In such cases a local shutdown of that core does not make sense.

[SWS_Os_00762] dIn cases where the OS detects a fatal internal error all cores shall

be shut down.c()

7.9.7 OS service functionality (overview)

Within this chapter we describe which existing single core AUTOSAR OS functionality

has been extended. The following table gives an overview of all standard OS API

functions. The column "Multi-Core support" contains one of the following values:

• Extended: The function that has been extended substantially to support special

Multi-Core functionality.

• Adapted: the function required some minor changes but basically remains un-

changed.

• Unchanged: the behavior of the function has not changed.

• New: the function is a new AUTOSAR OS API-function.

Service Multi-Core support

Annotation

ActivateTask Extended

Cross core use shall be supported.

AllowAccess Unchanged Works only on the same core.

CallTrustedFunction

Adapted Function must be bound to the same core.

CancelAlarm

Extended

Cross core use shall be supported.

ChainTask

Extended

Cross core use shall be supported.

CheckISRMemoryAccess

Unchanged

CheckObjectAccess

Unchanged

CheckObjectOwnership

Unchanged

CheckTASKMemoryAccess

Unchanged

ClearEvent

Unchanged

ControlIdle

Unchanged

Is allowed to be called from any core.

DisableAllInterrupts Unchanged Works only on the same core.

EnableAllInterrupts Unchanged Works only on the same core.

GetActiveApplicationMode

Unchanged

GetAlarm

Extended

Cross core use shall be supported.

GetAlarmBase

Extended

Cross core use shall be supported.

GetApplicationID

Unchanged

GetApplicationState

Extended

Cross core use shall be supported.

GetCoreID

New

ID of the current core.

GetCounterValue

Adapted

Cross core is not allowed.

GetElapsedValue

Adapted

Cross core is not allowed.

GetEvent

Unchanged

91 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Service Multi-Core support

Annotation

GetISRID

Unchanged

GetNumberOfActivatedCores

New

Number of cores running the AUTOSAR OS.

GetResource

Adapted Nestable with spinlocks.

GetScheduleTableStatus

Extended

Cross core use shall be supported.

GetSpinlock

New

Occupy a spinlock.

GetTaskID

Unchanged Works only on the same core.

GetTaskState

Extended

Cross core use shall be supported.

IncrementCounter

Adapted

Cross core is not allowed.

NextScheduleTable

Unchanged

ReleaseResource Adapted Nestable with spinlocks.

ReleaseSpinlock

New Release a spinlock.

ResumeAllInterrupts Unchanged Works only on the same core.

ResumeOSInterrupts

Unchanged Works only on the same core.

Schedule

Adapted

Check for unreleased spinlocks

SetAbsAlarm

Extended

Cross core use shall be supported

SetEvent

Extended

Cross core use shall be supported.

SetRelAlarm

Extended

Cross core use shall be supported

SetScheduleTableAsync

Unchanged

ShutdownAllCores

New

Synchronized shutdown.

ShutdownOS

Extended

Support for MC systems

StartCore

New

Start additional core

StartOS

Extended

Support for MC systems

StartScheduleTableAbs

Extended

Cross core use shall be supported.

StartScheduleTableRel

Extended

Cross core use shall be supported.

StartScheduleTableSynchron

Unchanged

StopScheduleTable

Extended

Cross core use shall be supported.

SuspendAllInterrupts

Unchanged Works only on the same core

SuspendOSInterrupts

Unchanged Works only on the same core

SyncScheduleTable

Unchanged

TerminateApplication Extended

Check for unreleased spinlocks. Cross core use shall be

supported.

TerminateTask Adapted

Check for unreleased spinlocks

TryToGetSpinlock

New Try to occupy a spinlock

WaitEvent Adapted

Check for unreleased spinlocks

Table 7.2: Gives an overview of changes to the OS Service Calles

Service

Task

Cat1

ISR

Cat2

ISR

Error

Hook

Pre

Task

Hook

Post

Task

Hook

Startup

Hook

Shut-

down

Hook

Alarm

Call-

back

Pro-

tec-

tion-

Hook

GetNumberOfActivated-

Cores

Ok Ok

GetCoreID

Ok Ok Ok Ok Ok Ok Ok Ok Ok Ok

StartCore

GetSpinlock

Ok Ok

92 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

ReleaseSpinlock

Ok Ok

TryToGetSpinlock

Ok Ok

GetNumberOfActivated-

Cores

Ok Ok

ShutdownAllCores

Ok Ok Ok Ok

Table 7.3: Allowed Calling Context for OS Ser vice Calls

[SWS_Os_00589] dAll functions that are not allowed to operate cross core shall re-

turn E_OS_CORE in extended status if called with parameters that require a cross core

operation.c(SRS_Os_80013, SRS_BSW_00459)

7.9.8 GetTaskID

GetTaskID can be called both from Task and Category 2 ISR level. When called from

an interrupt routine, on Single-Core systems, GetTaskID returns either the interrupted

Task or indicates that no Task is running. On Multi-Core systems it

• indicates that no Task is running on the core or,

• returns the ID of the interrupted Task on the core.

7.9.9 Interrupt disabling

Note: All types of interr upts can only be disabled on the local core. This implies that

the interrupt flags on other cores remain in their current state. Scheduling continues

on the other cores. Running ISRs on other cores continue executing.

7.9.9.1 Requirements

[SWS_Os_00590] dThe OS service DisableAllInterrupts shall only affect the

core on which it is called.c(SRS_Os_80013)

[SWS_Os_00591] dThe OS service EnableAllInterrupts shall only affect the

core on which it is called.c(SRS_Os_80013)

[SWS_Os_00592] dThe OS service SuspendAllInterrupts shall only affect the

core on which it is called.c(SRS_Os_80013)

[SWS_Os_00593] dThe OS service ResumeAllInterrupts shall only affect the

core on which it is called.c(SRS_Os_80013)

[SWS_Os_00594] dThe OS service SuspendOSInterrupts shall only affect the

core on which it is called.c(SRS_Os_80013)

93 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

[SWS_Os_00595] dThe OS service ResumeOSInterrupts shall only affect the core

on which it is called.c(SRS_Os_80013)

7.9.10 Task activation

Task activation shall be extended to work across cores. This document will not specify

any implementation details. This functions timing behavior can be slower when working

across cores. If a Task has to be activated on another core, a scheduling decision is

necessary on that core. If the core has not been started an error is generated.

7.9.10.1 Requirements

[SWS_Os_00596] dIt shall be possible to activate a Task that is part of an OS-

Application located on another core, as long as the assigned access rights allow it.c

(SRS_Os_80001, SRS_Os_80015)

[SWS_Os_00598] dThe call of ActivateTask across cores shall behave syn-

chronously, i.e. a call returns after the Task has been activated or an error has been

detected. It shall not be possible to continue execution on the calling core before

ActivateTask is accomplished on the remote core.c(SRS_Os_80015)

[SWS_Os_00599] dIn case of an error when calling ActivateTask across cores,

the error handler shall be called on the core on which ActivateTask was originally

called.c(SRS_Os_80015)

[SWS_Os_00816] dThe operating system shall provide an asynchronous version of

ActivateTask which does not return errors to the caller, but only calls the (global)

error hook (if configured). The function name shall be ActivateTaskAsyn.c(SRS_-

Os_80015)

7.9.11 Task Chaining

Task chaining shall be extended to work across cores. This document will not specify

any implementation details. This function’s timing behavior can be slower when work-

ing across cores. If a Task has to be activated on another core, a scheduling decision

is necessary on that core. If the core has not been activated, an error is generated.

7.9.11.1 Requirements

[SWS_Os_00600] dIt shall be possible to chain a Task that is part of an OS-Application

located on another core, as long as the assigned access rights allow it.c(SRS_Os_-

80001, SRS_Os_80015)

94 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

7.9.12 Event setting

SetEvent shall be extended to work across cores. This document will not specify any

implementation details. This function’s timing behavior can be slower when working

across cores. If the core has not been activated, an error is generated.

7.9.12.1 Requirements

[SWS_Os_00602] dIt shall be possible to set an Event that is part of an OS-

Application located on another core, as long as the assigned access rights allow it.c

(SRS_Os_80016)

[SWS_Os_00604] dThe call of SetEvent across cores shall behave synchronously,

i.e. a call returns after the Event has been set or an error has been detected. It

shall not be possible to continue execution on the calling core before SetEvent is

accomplished on the remote core.c(SRS_Os_80016)

[SWS_Os_00605] dIn case of an error when calling SetEvent across cores, the error

handler shall be called on the core on which SetEvent was originally called.c(SRS_-

Os_80016)

[SWS_Os_00817] dThe operating system shall provide an asynchronous version of

SetEvent which does not return errors to the caller, but only calls the (global) error

hook (if configured). The function name shall be SetEventAsyn.c(SRS_Os_80016)

7.9.13 Activating additional cores

The mechanism by which additional cores can be activated as described in section

7.9.5

7.9.14 Start of the OS

It is necessary to extend the functionality of StartOS. This is because StartOS is

called once on each core. The user provides the so called application mode

to the

Operating System through the call parameter of StartOS(AppMode).The applica-

tion mode defines which of the configured (startup) objects (Tasks, Alarms, Sched-

uleTables) the OS automatically starts.

On a Multi-Core system all cores shall run in the same application mode. If StartOS

is called with the Appmode DONOTCARE, the AppMode of the other cores is used. At

least one core has to define an AppMode other than DONOTCARE.

This is the application mode of the Operating System and shall not be confused by other application

modes defined in the AUTOSAR mode management.

95 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

If the application mode is the same on all cores, StartOS will proceed its task. More

details can be found in chapter 7.9.4.

7.9.14.1 Requirements

[SWS_Os_00606] dThe AUTOSAR specification does not support the activation of

AUTOSAR cores after calling StartOS on that core. If StartCore is called after

StartOS it shall return with E_OS_ACCESS in extended status.c(SRS_Os_80001)

[SWS_Os_00607] dStartOS shall start the OS on the core on which it is called.c

(SRS_Os_80006, SRS_Os_80013)

[SWS_Os_00608] dIf more than one core calls StartOS with an AppMode other than

DONOTCARE, the AppModes shall be the same. StartOS shall check this at the first

synchronization point. In case of violation, StartOS shall not start the scheduling,

shall not call any StartupHooks, and shall enter an endless loop on every core.c

(SRS_Os_80006)

[SWS_Os_00609] dIf StartOS is called with the AppMode DONOTCARE the application

mode of the other core(s) (differing from DONOTCARE) shall be used.c(SRS_Os_80006)

[SWS_Os_00610] dAt least one core shall define an AppMode other than DONOT-

CARE.c(SRS_Os_80006)

[SWS_Os_00611] dIf the IOC is configured, StartOS shall initialize the data structures

of the IOC.c(SRS_Os_80020)

[SWS_Os_00830] DRAFT dIf the IOC is configured and the OS Generator is invoked

in "Default mode", StartOS shall invoke the IocInit (See [SWS_Os_00835]) to ini-

tialize the data structures of the IOC.c(SRS_Os_80020)

7.9.15 Task termination

The termination of Tasks requires an additional check: It is not allowed to terminate a

Task while a spinlock is occupied. If TerminateTask / ChainTask is called with an

occupied spinlock an error is returned.

7.9.15.1 Requirements

If TerminateTask (or ChainTask) is called while the calling Task holds a spinlock,

the behavior is undefined in standard status.

[SWS_Os_00612] dIn extended status TerminateTask / ChainTask shall return

with an error (E_OS_SPINLOCK), which can be evaluated in the application.c(SRS_-

Os_80021)

96 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

[SWS_Os_00613] dSpinlocks occupied by Tasks that are terminated in response to a

protection hook shall be automatically released. This applies also to the case in which

an OS-Application is terminated.c(SRS_Os_80021)

7.9.16 Termination of OS-Applications

Similar to Tasks an OS-Application cannot be terminated while any of its Tasks occupy

a spinlock. In such cases, the lock is automatically released. To avoid an avalanche of

error handling, no calls to the ErrorHook are made.

It might be possible that TerminateApplication(A) is called in parallel from differ-

ent cores. The implementation has to support such a call pattern by executing the first

arriving call of TerminateApplication(A)and ignoring any subsequent calls until

the termination is completed.

7.9.16.1 Requirements

[SWS_Os_00614] dTerminateApplication shall check if any of the Tasks in the

OS-Application have occupied a spinlock. If so, the spinlocks shall be released.c

(SRS_Os_80021)

[SWS_Os_00615] dIf TerminateApplication(A) is called in parallel from different

cores, the OsApplication A is terminated by the first call, any subsequent calls will

return with E_OK in standard and extended status without doing anything, until the

termination is completed.c(SRS_Os_80021)

7.9.17 Shutdown of the OS

Every core shall be able to invoke shutdown by using the ShutdownOS function. By

calling ShutdownOS only the calling core will enter the shutdown procedure.

If the user wants to shutdown all cores (more or less in parallel) ShutdownAllCores

shall be used. ShutdownOS and ShutdownAllCores will not return.

The OS service ShutdownOS is not used by the AUTOSAR mode management in

AUTOSAR R4.0. The function is offered for users that run the OS on cores without

RTE and without mode management.

7.9.17.1 Requirements

[SWS_Os_00616] dShutdownOS shall be callable from each core running an

AUTOSAR OS.c(SRS_Os_80001, SRS_Os_80007)

97 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

[SWS_Os_00617] dShutdownOS shall shutdown the core on which it was called.c

(SRS_Os_80007)

[SWS_Os_00618] dThe OS shall not start Tasks of an OS-Application once the shut-

down procedure has been entered on a particular core.c(SRS_Os_80013)

[SWS_Os_00619] dThe AUTOSAR OS function ShutdownOS shall be callable in par-

allel on multiple cores.c(SRS_Os_80013)

[SWS_Os_00620] dShutdownOS shall release all spinlocks which are occupied by the

calling core.c(SRS_Os_80021)

[SWS_Os_00621] dShutdownAllCores shall be callable from each core running an

AUTOSAR OS.c(SRS_Os_80007)

7.9.18 Waiting for Events

The Event waiting mechanism must be adapted to the new Multi-Core spinlock func-

tionality:

A Task might be de-scheduled when calling WaitEvent, in which case it would not

be able to release the spinlock. WaitEvent must therefore check if the calling Task

holds a spinlock. As with Resources, spinlocks cannot be occupied by Tasks in wait

state.

7.9.18.1 Requirements

[SWS_Os_00622] dThe AUTOSAR Operating System WaitEvent API service shall

check if it has been called while the calling Task has occupied a spinlock. In extended

status an error E_OS_SPINLOCK shall be returned and the Task shall not enter the

wait state.c(SRS_Os_80021)

7.9.19 Calling trusted functions

Functions can be declared as trusted as part of an OS-Application. They can then

only be executed through the CallTrustedFunction API function. Assuming that

the access rights are configured accordingly, a Task from OS-Application A can call a

trusted function from OS-Application B.

On a Multi-Core system, these trusted function calls from one OS-Application to an-

other are limited to the same core.

98 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

7.9.19.1 Requirements

[SWS_Os_00623] dThe OS API function CallTrustedFunction shall return

E_OS_ACCESS in extended status if the target trusted function is part of an OS-

Application on another core.c(SRS_Os_80013)

7.9.20 Invoking reschedule

The Schedule API service must be adapted to the new Multi-Core spinlock function-

ality in the same manner as WaitEvent.

A Task shall not actively force a de-scheduling while it occupies spinlocks.

7.9.20.1 Requirements

[SWS_Os_00624] dThe AUTOSAR Operating System Schedule API service shall

check if it has been called while the calling Task has occupied a spinlock. In ex-

tended status an error E_OS_SPINLOCK shall be returned and the scheduler shall not

be called.c(SRS_Os_80021)

7.9.21 Resource handling

The GetResource function allows mutual exclusion between Tasks on the same core.

The OS generator shall check offline that the Tasks are not on different cores.(see

7.9.29) and the GetResource function will check this requirement online.

The priority ceiling protocol (used by GetResource) temporarily changes the priority

of a Task. Such an approach fails on Multi-Core systems as the priorities are local to

each core. Therefore the ceiling protocol is not sufficient to protect a critical section

against access from different cores.

[SWS_Os_00801] dIf Spinlocks and Resources are locked by a Task/ISR they have

to be unlocked in strict LIFO order. ReleaseResource shall return E_OS_NOFUNC

if the unlock order is violated. No other functionality shall be performed.c(SRS_Os_-

80021)

[SWS_Os_00851] dIf OsUseResScheduler is TRUE, the OS generation tool shall

create a virtual instance of RES_SCHEDULER for each configured core.c()

[SWS_Os_00852] dIt shall be possible for tasks running on different cores to occupy

their own instance of RES_SCHEDULER at the same time.c()

[SWS_Os_00853] dThe ceiling priority of each instance of RES_SCHEDULER shall pre-

vent the execution of any other task on the core on which it is occupied but shall have

no effect on the scheduling on any other core.c()

99 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

[SWS_Os_00854] dIf OsUseResScheduler is FALSE AND the configuration contains

a resource called RES_SCHEDULER, the configured resource shall behave the same as

any other configured resource.c()

[SWS_Os_00855] dIt shall be possible to configure a LINKED resource that links to

RES_SCHEDULER. In a multi-core configuration with OsUseResScheduler=TRUE,

the linkage shall be to the instance of RES_SCHEDULER on the core to which the

LINKED resource is assigned.c()

7.9.22 The CoreID

Every HW assigns a unique physical Id to a core. The physical core Id is the only

way to distinguish between cores. The physical core Ids of a µC are not necessarily

consecutive and do not necessarily start with zero.

The SW requires a mechanism to identify a core, e.g. to use core specific variables.

Because the physical core Id usually cannot be used as a direct array index for core

specific variables, a logical CoreID is necessary to map physical core Ids to array

indexes. In the SW it is not necessary to know the physical core Id, the logical CoreID

is sufficient.

The mapping of OS-Applications and other SW objects to cores is specified in the

configuration files. All such mappings shall be HW independent and therefore shall not

be based on the physical core Id but on the logical CoreID.

The function GetCoreID internally maps the physical core Id to the logical CoreID.

The mapping is implementation specific. GetCoreID can be either a C function or a

macro.

7.9.22.1 Requirements

[SWS_Os_00625] dThe AUTOSAR Operating System API function GetCoreID shall

be callable before StartOS.c(SRS_Os_80006)

[SWS_Os_00627] dAn implementation shall define a set of constants OS_CORE_ID_

<No> of the type CoreIdType with <No> a value from 0 to OsNumberOfCores-1.c

(SRS_Os_80001)

[SWS_Os_00628] dAn implementation shall offer a constant OS_CORE_ID_MASTER of

the type CoreIdType that refers to the master core.c(SRS_Os_80001)

7.9.23 Counters, background & rationale

A Counter is represented by a counter value, measured in "ticks", and some counter

specific constants.

100 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Similarly to Single-Core situation, each operating system (on each core) offers at least

one Counter that is derived from a timer. Therefore, it is possible to define several

Counters which belong to different OS-Applications and either resides on the same

or different cores.

Figure 7.18: Examples of allowed configurations for Counters, Alarms, Schedule-tables

and ISRs

7.9.24 Multi-Core restrictions on Counters

The AUTOSAR OS can only increment Counters on the core on which it resides.

A Counter which is assigned to an OS-Application X cannot be incremented by an

OS-Application Y if X and Y are assigned to different cores.

7.9.24.1 Requirements

[SWS_Os_00629] dA Counter belonging to an OS-Application shall be incremented

by the core on which the OS-Application resides. The Counter shall not be incre-

mented by other cores.c(SRS_Os_80013)

[SWS_Os_00630] dIt shall not be allowed to drive a ScheduleTable from a

Counter, which is assigned to a different core.c(SRS_Os_80013)

[SWS_Os_00631] dIt shall not be allowed to drive an Alarm from a Counter, which

is assigned to a different core.c(SRS_Os_80013)

101 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

There are two different reasons for these restrictions:

• Race conditions can occur when cross-core modification of Counter is allowed

(one core waits for a Counter to be modified by another core).

• The core which is incrementing the Counter has to check if Alarms which are

based on the Counter have expired. Handling of expired Alarms is more com-

plex when different cores manipulate the same Alarms, because mutual exclu-

sion becomes necessary.

Figure 7.19: Example of disallowed configurations for Counters, Alarms, Schedule-

tables and Call-backs

7.9.25 Synchronization of Counters

Counters are used to drive Alarms and ScheduleTables. To synchronize Alarms

and ScheduleTables that reside on different cores, the corresponding Counters

have to be synchronized. For example, if the hardware supports this, it is possible

102 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

that corresponding free running hardware counters on different cores use the same

timer (same counter value maintained by the peripheral) and therefor provide the same

timebase on different cores. Software Counters can then get advanced by alarms at-

tached to these core local corresponding hardware counters, e.g. to drive synchronized

ScheduleTables on different cores. The quality of the synchronicity depends on the

hardware architecture and on the system configuration. .

7.9.26 Alarms

The Alarm mechanism of the AUTOSAR Operating System provides services to acti-

vate Tasks, set Events, increment Counters, or call an Alarm call-back (OsAlarm-

CallbackName).

As stated above, Alarms can only be bound to a Counter which resides on the same

core. Tasks can be activated and Events can be set with an Alarm action regardless

of the core to which the Task is bound. The access rights defined by OS-Applications

have to be respected, however. Additionally it shall be allowed to manipulate Alarms

when they are bound to other cores. The API-services SetRelAlarm, SetAbsAlarm,

and CancelAlarm can be used to manipulate parameters of Alarms on other cores.

7.9.26.1 Requirements

[SWS_Os_00632] dIf an Alarm expires, it shall be allowed to activate a Task on a

different core.c(SRS_Os_80018)

[SWS_Os_00633] dIf an Alarm expires, it shall be allowed to set an Event on a

different core.c(SRS_Os_80018)

[SWS_Os_00634] dThe AUTOSAR Operating System shall process an Alarm on the

core on which its corresponding OS-Application resides.c(SRS_Os_80018)

[SWS_Os_00635] dAlarm callbacks shall be executed on the core to which the Alarm

is bound. This is only applicable to SC1 systems, because otherwise Alarm Callback

are not allowed ([SWS_Os_00242]).c(SRS_Os_80013)

[SWS_Os_00636] dSetRelAlarm shall also work on an Alarm that is bound to an-

other core.c(SRS_Os_80013)

[SWS_Os_00637] dSetAbsAlarm shall also work on an Alarm that is bound to an-

other core.c(SRS_Os_80013)

[SWS_Os_00638] dCancelAlarm shall also work on an Alarm that is bound to an-

other core.c(SRS_Os_80013)

[SWS_Os_00639] dGetAlarmBase shall also work on an Alarm that is bound to

another core.c(SRS_Os_80013)

103 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

[SWS_Os_00640] dGetAlarm shall also work on an Alarm that is bound to another

core.c(SRS_Os_80013)

7.9.27 ScheduleTables

Similarly to Alarms, ScheduleTables can be used to activate Tasks and set

Events. As with Alarms, a ScheduleTable can only be bound to a Counter which

resides on the same core.

To simplify system startup, it should be possible to start ScheduleTables on other

cores. The system designer is responsible for the correct handling of Sched-

uleTables. For example, ScheduleTables can be controlled from one core.

7.9.27.1 Requirements

[SWS_Os_00641] dA ScheduleTable shall be able to activate a Task bound on a

core other than the one upon which the ScheduleTables resides.c(SRS_Os_80018)

[SWS_Os_00642] dA ScheduleTable shall be able to set an Event on a core other

than the one upon which the ScheduleTables residesc(SRS_Os_80018)

[SWS_Os_00643] dThe AUTOSAR Operating System shall process a Sched-

uleTable on the core on which its corresponding OS-Application resides.c(SRS_-

Os_80013)

[SWS_Os_00644] dThe API call StartScheduleTableAbs shall be able to start

ScheduleTables of OS-Applications residing on other cores.c(SRS_Os_80018)

[SWS_Os_00645] dThe API call StartScheduleTableRel shall be able to start

ScheduleTables of OS-Applications residing on other cores.c(SRS_Os_80013)

[SWS_Os_00646] dThe API call StopScheduleTable shall be able to stop Sched-

uleTables of OS-Applications residing on other cores.c(SRS_Os_80013)

[SWS_Os_00647] dThe API service GetScheduleTableStatus shall be able to get

the status of a ScheduleTable that is part of an OS-Application residing on a different

core.c(SRS_Os_80013)

7.9.28 The spinlock mechanism

With the Multi-Core concept, a new mechanism is needed to support mutual exclusion

for Tasks on different cores. This new mechanism shall not be used between Tasks

on the same core because it makes no sense. In such cases the AUTOSAR Operating

System returns an error.

104 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

A SpinlockType, which is similar to OSEK’s ResourceType, shall be used. Spinlocks

are configured offline.

A spinlock is a busy waiting mechanism that polls a (lock) variable until it becomes

available. Typically, this requires an atomic test and set functionality, the details of

which are implementation specific.

Once a lock variable is occupied by a Task/Category 2 ISR, other Tasks/Category 2

ISRs on other cores shall be unable to occupy the lock variable. The spinlock mecha-

nism will not de-schedule these other Tasks while they poll the lock variable. However

it might happen that a Task/ISR with a higher priority becomes ready while the lock

variable is being polled. In such cases the spinning Task will be interfered. This is

illustrated in figure 7.20.

Figure 7.20: A deadlock situation caused by interference, the high priority Task spins

indefinitely because the low priority Task has occupied the spinlock. In such cases the

second GetSpinlock call will return with an error.

A user can protect a Task against such a situation by, for example, rapping the spinlock

with SuspendAllInterrupts, so that it cannot be interfered by other Tasks. The

OS can do this automatically for the caller - see OsSpinlockLockMethod.

A second deadlock situation can be created by nested spinlocks calls, as illustrated in

figure 7.21.

105 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Figure 7.21: This figure shows a typical deadlock caused by two spinlocks taken in

different order by Tasks on two different cores

To avoid deadlocks it is not allowed to nest different spinlocks. Optionally if spinlocks

shall be nested, a unique order has to be defined. Spinlocks can only be taken in this

order whereas it is allowed to skip individual spinlocks. Cycles are not allowed within

the defined order. This is illustrated in figure 7.22.

Figure 7.22: Usage of spinlocks

This figure 7.22 shows an example in which two Tasks have access to a set of spin-

locks S1 – S6. It is allowed to occupy the spinlocks in the predefined order and it is

allowed to skip spinlocks. If multiple spinlocks are occupied at the same time, locking

and unlocking has to occur in strict LIFO order

The spinlock mechanism is not deadlock free by itself. The order in which spinlocks

from Tasks/ISRs are requested has to be mentioned in the configuration description.

If a Task occupies a spinlock, scheduling shall be restricted.

Note: AUTOSAR does not prescribe which algorithms are used to implement spinlocks.

Since users may want to analyze the timing behavior (e.g. lock times) an implementa-

tion shall document the real behavior.

106 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

7.9.28.1 Requirements

[SWS_Os_00648] dThe AUTOSAR Operating System shall provide a spinlock mecha-

nism that works across cores.c(SRS_Os_80018, SRS_Os_80021)

[SWS_Os_00649] dThe AUTOSAR Operating System shall provide a GetSpinlock

function which occupies a spinlock. If the spinlock is already occupied, GetSpinlock

shall keep on trying to occupy the spinlock until it succeeds.c(SRS_Os_80018, SRS_-

Os_80021)

[SWS_Os_00650] dGetSpinlock shall be callable from Task level.c(SRS_Os_-

80018, SRS_Os_80021)

[SWS_Os_00651] dGetSpinlock shall be callable from Category 2 ISR level.c

(SRS_Os_80021)

The behavior of GetSpinlock is undefined if called from a category 1 ISR

[SWS_Os_00652] dThe AUTOSAR Operating System shall provide a TryToGet-

Spinlock function which occupies a spinlock. If the spinlock is already occupied

by a Task, TryToGetSpinlock shall return.c(SRS_Os_80018, SRS_Os_80021)

[SWS_Os_00653] dTryToGetSpinlock shall be callable from Task level.c(SRS_-

Os_80018, SRS_Os_80021)

[SWS_Os_00654] dTryToGetSpinlock shall be callable from Category 2 ISR level.c

(SRS_Os_80018, SRS_Os_80021)

[SWS_Os_00655] dThe AUTOSAR Operating System shall provide a ReleaseSpin-

lock function which releases an occupied spinlock. If the spinlock is not occupied an

error shall be returned.c(SRS_Os_80018, SRS_Os_80021)

[SWS_Os_00656] dReleaseSpinlock shall be callable from Task level.c(SRS_Os_-

80018, SRS_Os_80021)

[SWS_Os_00657] dReleaseSpinlock shall be callable from Category 2 ISR level.c

(SRS_Os_80018, SRS_Os_80021)

[SWS_Os_00658] dThe AUTOSAR Operating System shall generate an error if a Task

tries to occupy a spinlock that is assigned to a Task/Category 2 ISR on the same core

(including itself).c(SRS_Os_80018, SRS_Os_80021)

[SWS_Os_00659] dThe AUTOSAR Operating System shall generate an error if an

Category 2 ISR tries to occupy a spinlock that is assigned to a Task/Category 2 ISR

on the same core.c(SRS_Os_80018, SRS_Os_80021)

[SWS_Os_00660] dA unique order in which multiple spinlocks can be occupied by a

Task/Category 2 ISR on one core should be configurable in the AUTOSAR Operat-

ing System. This might be realized by the configuration item (OsSpinlockSucces-

sor{NEXT_SPINLOCK}) where NEXT_SPINLOCK refers to the consecutive spinlock.

(See OsSpinlockSuccessor)c(SRS_Os_80018, SRS_Os_80021)

107 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

[SWS_Os_00661] dThe AUTOSAR Operating System shall generate an error if a

Task/Category 2 ISR on a core, where the same or a different Task/ISR already holds

a spinlock, tr ies to seize another spinlock that has not been configured as a direct or

indirect successor of the latest acquired spinlock (by means of the OsSpinlockSuc-

cessor configuration parameter) or if no successor is configured.c(SRS_Os_80018,

SRS_Os_80021)

7.9.29 Offline checks

AUTOSAR Resources cannot be shared between Tasks/ISRs on different cores. The

OS generator has to check if a user tries to assign a Resource to Tasks on different

cores and stop the generation process with an error.

Counters cannot be accessed from OS-Applications on different cores. The OS gen-

erator has to reject configurations that violate this rule.

The linked list of spinlocks must be free of cycles to allow correct nesting of spinlocks

in order to prevent deadlocks.

The OS generator tool must check that an OS-Application does not get assigned to

a non-existing core. Additional checks at configuration time, e.g. by an AUTOSAR

description editor are recommended.

7.9.29.1 Requirements

[SWS_Os_00662] dThe OS generator tool shall return with an error if it detects a Re-

source referred to by any Tasks or ISRs assigned to different cores.c(SRS_Os_-

80021)

[SWS_Os_00663] dThe OS generator tool shall return with an error if an Alarm is

assigned to a Counter on a different core.c(SRS_Os_80013)

[SWS_Os_00664] dThe OS generator tool shall return with an error if a Counter on a

different core shall be incremented as an Alarm action.c(SRS_Os_80013)

[SWS_Os_00665] dThe OS generator tool shall return with an error if a Sched-

uleTable is assigned to a Counter on a different core.c(SRS_Os_80013)

[SWS_Os_00666] dThe OS generator tool shall return with an error if the linked list of

spinlocks is not free of cycles.c(SRS_Os_80021)

[SWS_Os_00667] dThe OS generator tool shall check the assignment of OsAppli-

cations (including the Tasks assigned to the OsApplication) to cores and return

an error in case any of these cores does not exist.c(SRS_Os_80005)

108 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

7.9.30 Auto start Objects

Before scheduling starts the AUTOSAR Operating System

activates all auto-start ob-

jects that are configured. This mechanism shall work similar on a Multi-Core system.

Before scheduling starts, the Multi-Core OS shall activate all configured auto-start ob-

jects on the respective core. Due to the fact that OS-Applications are defined as the

locatable entity no further configuration container is required. Auto-start objects are

already configured as part of an OS-Application.

7.9.30.1 Requirements

[SWS_Os_00668] dThe AUTOSAR Operating System shall automatically activate all

auto-start Tasks configured for the current AppMode, with respect to the core, before

the initial start of the scheduling.c(SRS_Os_80006)

[SWS_Os_00669] dThe AUTOSAR Operating System shall automatically activate all

auto-start Alarms configured for the current AppMode, with respect to the core, before

the initial start of the scheduling.c(SRS_Os_80006)

[SWS_Os_00670] dThe AUTOSAR Operating System shall automatically activate all

auto-start ScheduleTables configured for the current AppMode, with respect to the

core, before the initial start of the scheduling.c(SRS_Os_80006)

7.10 Inter-OS-Application Communicator (IOC)

7.10.1 Background & Rationale

IOC stands for Inter OS-Application Communicator.

The "IOC" is responsible for the communication between OS-Applications and in partic-

ular for the communication crossing core or memory protection boundaries. Its internal

functionality is closely connected to the Operating System.

StartOs

109 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Figure 7.23: IOC overall view

There are use cases where 1 to N IOC code instances needs to be generated on top of

the OS code which is used by multiple different Software Clusters. As those Software

Clusters use different IOC configurations, as a consequence the OS code shall not

include any code depending on a specific IOC configuration.

To ensure compatibility between IOC and OS code, there is still a dependency in that it

is necessary to use the same OS configuration for the generation of the different IOC

code Instances. Furthermore, the OS and IOC code should be generated from an OS

Generator coming from the same vendor.

[SWS_Os_00671] dThe IOC implementation shall be part of the Operating System

The IOC is a third type of communication, in addition to

• Intra OS-Application communication: Always handled within the RTE

• Inter ECU communication: Already available via well-defined interfaces to the

communication stack (COM)

c(SRS_Os_80020)

IOC mode: This is the mode where the OS generator is invoked with a configuration

parameter to generate the IOC code only.

OS mode: This is the mode where the OS generator is invoked with a configuration

parameter to generate the OS code only.

Default mode: This is the current behavior where the IOC code is generated along

with OS code.

[SWS_Os_00831] DRAFT dThe OS Generator shall provide configuration parameters

allowing IOC communication code ("IOC mode") to be generated separately from OS

code (("OS mode").c(SRS_Os_80020)

110 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

[SWS_Os_00831] means that the OS Generator shall be able to produce only OS code

or only IOC code in a single invocation.

[SWS_Os_00832] DRAFT dThe Operating System in the Host Software Cluster shall

be able to handle multiple IOC code Instances related to different Software Clusters.c

(SRS_Os_80020)

[SWS_Os_00833] DRAFT dWhen the OS generator is invoked in "OS mode" it shall

only generate the OS code. Thereby the OS code shall not include any code that

depends on a specific IOC configuration, because different Clusters will use different

IOC configurations with the same OS code.c(SRS_Os_80020)

Please note that it is mandatory to use the same OS configuration for the generation

of the different IOC instances to ensure compatibility between the IOC and OS code.

[SWS_Os_00834] DRAFT dWhen the OS generator is invoked in "IOC mode" it shall

only generate the IOC code. Thereby the name of the C module containing the gener-

ated IOC code shall be Ioc.c and the name of the header file containing the generated

IOC APIs shall be Ioc.h.c(SRS_Os_80020)

Requirements [SWS_Os_00833] and [SWS_Os_00834] ensure that OS and IOC can

be generated independently from each other but linked together while building the ECU

instance /Machine. ()

[SWS_Os_00835] DRAFT dIf the IOC is configured, there shall be a function IocInit

responsible for the initialization of the data structures of the IOC.c(SRS_Os_80020)

Memory protection boundaries are a characteristic of OS-Applications and special

communication mechanisms are needed to cross them. Multi-Core systems may also

need additional measures to make communication between cores safe.

All AUTOSAR software, both BSW and software components, must belong to an OS-

Application (see 7.9.3), but not necessarily to the same one. It is expected that the

BSW will be trusted code, but it shall be defined as one or more OS-Applications.

The IOC provides communication services between OS-Applications and in particular

over core boundaries in Multi-Core systems. Because the cross-core communication

is always an inter-OS-Application communication, the two mechanisms are combined.

An inter OS-Application communication may not necessarily require a cross core com-

munication, however.

Communication between OS-Applications is expected to be more frequent than inter

ECU communication. This would be the case when existing; closely related Software

Components and their r unnable entities are distr ibuted to two or more cores to increase

system performance. Meeting timing constraints is expected to become more difficult,

when runnables which have been designed to run on a single core are distributed over

several cores.

In systems with only one core, the IOC can be omitted completely, if just one OS-

Application is available, or if no OS-Application uses memory protection mechanisms.

The IOC does not provide standardized support for measurement of IOC channels.

111 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

7.10.2 IOC - General purpose

The IOC provides communication services which can be accessed by clients which

need to communicate across OS-Application boundaries on the same ECU or Software

Cluster.

The RTE uses IOC services to communicate across such boundaries. All communica-

tion must be routed through the RTE on sender (or client) and on receiver (or server)

side.

Direct access to IOC services by clients other than the RTE is currently not supported,

but possible, if the client (e.g. a CDD) provides a hand written or generated IOC Con-

figuration Description as specified and specific callback functions if necessary. Only

sender/receiver communication is supported however by the IOC.

To keep the RTE as hardware independent as possible, all inter OS-Application and

inter core communication mechanisms and implementation variants are encapsulated

in the IOC. The IOC internal functionality is dependent on hardware architecture prop-

erties, in particular on the memory architecture.

The IOC has to guarantee data consistency in inter OS-Application and inter core

(Multi-Core systems) communication, this means in particular:

• In queued communication the sequential order of communication operations shall

remain unchanged. In the N:1 communication case, the order of the messages

from the different sources is a property of the implementation.

• The content of all data sent in one communication operation shall remain un-

changed, i.e. each communication operation shall be treated as atomic opera-

tion.

• The lock mechanism (interrupt locks; spinlocks; lock free implementation; ...)

which is used by the IOC to guarantee the data consistency is not standardized.

7.10.3 IOC functionality

7.10.3.1 Communication

The IOC provides sender-receiver (signal passing) communication only. The RTE (or

adapted BSW modules in a future release of this specification) translates Client-Server

invocations and response transmissions into Sender-Receiver communication.

1:1, N:1 and N:M (unqueued only) communication are supported by the IOC.

The IOC allows the transfer of one data item per atomic communication operation. A

data item can either be a value for atomic basic data types or a reference for complex

data structures. The data str ucture must be implemented as a single memory block,

however. This way the data item can be transmitted in one piece. The IOC does not

need to know the internal data structure. The basic memory address and length (which

112 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

can be calculated from the type of the data item) is sufficient. The IOC does, e.g., not

support a conversion of endianness between cores.

Transferring more than one data item in one operation is also supported for 1:1 com-

munication only. In this case several types and memory addresses have to be used by

the IOC function. The advantage compared to sequential IOC calls is that mechanisms

to open memory protection boundaries and to notify the receiver have to be executed

just once. Additionally, all data items are guaranteed to be consistent, because they

are transferred in one atomic operation.

The IOC provides both, unqueued (Last-is-Best, data semantics) or queued (First-In-

First-Out, event semantics) communication operations. If present, the IOC internal

queue has a configurable length.

Each atomic communication operation gets specified individually by its own descrip-

tion block in a Configuration Description with regard to sender, receiver, data type(s),

notification, and queuing.

7.10.3.2 Notification

The IOC optionally notifies the receiver as soon as the transferred data is available

for access on the receiver side, by calling a configured callback function which gets

provided by the user of the communication.

A possible implementation is to trigger an interrupt (Category 2 ISR) mechanism to

invoke the callback function from the ISR on receiver side, or to use a microcontroller

supplied trap. The callback function shall be efficient and compact, because it is called

from within the ISR.

In certain cases, it might not be necessary to trigger an ISR to notify the receiver. The

IOC generator can then select the appropriate IOC internal notification method based

on the hardware architecture and other constraints. This might be more efficient than

an ISR for communication between OS-Applications on the same core.

The notification might be handled completely by the client of the IOC, e.g. when the

RTE calls the IOC send function, and then notifies the receiver side RTE that new data

are available from the IOC. In this case, the IOC is not affected at all by the details of

the notification mechanism.

In case such alternative solutions prove to be more efficient, the IOC internal notifica-

tion might get removed in future AUTOSAR releases.

7.10.4 IOC interface

The interface between RTE and IOC shall be similar to the interface between Software

Components and the RTE, i.e. by generating specific interfaces for each communica-

tion operation instead of providing a generic API.

113 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

This supports optimization methods (like function inlining or replacing function calls

by macros) much better than standardized interfaces. Most of the optimization can

be performed offline at code generation time instead of consuming valuable real-time

resources.

There is a unique set of IOC service APIs (at least to send and receive data) for each

data communication specified in the IOC Configuration Description. Each service API

gets generated and can be identified by a unique Id for each data communication. In

case of N:1 communication, each sender must use its own API.

The same IOC service API and hence the same 1:1 communication can get used by

more than one runnable inside the same SWC both on sender and on receiver side.

However, the IOC functions are not reentrant, because otherwise e.g. spinlock errors

could occur in case the IOC uses spinlocks in Multi-Core systems. The same IOC API

must therefore only be called sequentially. This is no problem, if all runnable entities

are scheduled within the same Task, otherwise the caller is responsible to guarantee

that the same IOC API is not called again before it returns from a different invocation.

Software Components may access the IOC only via RTE. Only the RTE decides which

communication services to use to support the communication needs of Software Com-

ponents.

Direct access to IOC services by BSW modules is not supported, but allowed for CDDs

and other modules, if unavoidable. The clients have to provides a hand written or

generated IOC Configuration Description as specified. In case of notification of the

receiver, a specific callback function has to be specified and provided by the client.

Only sender/receiver communication is supported however by the IOC.

7.10.5 IOC internal structure

This section gives some hints on possible IOC implementation options.

The IOC may enter the privileged mode to cross the protection boundaries between

OS-Applications. The IOC therefore has to be part of the OS. Note that functionality

that is placed in the kernel context might be non-interruptible by Tasks or Category 2

ISR. The functionality can be interrupted by Cat1 ISRs, however.

The IOC send service writes data into a buffer located in a memory area which is

shared with the receiving communication partners (This is one possible implementation

example using shared memory). Depending on the hardware architecture and other

constraints, different implementation options might be available within the IOC. These

options shall be transparent to the client (RTE), however.

The IOC ensures data consistency, i.e. there is a protection against concurrent access

to the same data from all senders and the receiver for protection against inconsistent

behavior and data corruption. The implementation can be hardware dependent.

114 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

In systems with shared memory, there can be a specific communication buffer for each

data item in a memory section which is shared between the sending and receiving

OS-Applications.

If an IOC communication with event semantics (queued) is configured the length of the

queue shall be defined.

7.10.6 IOC configuration and generation

Data element specific interfaces between RTE and IOC require extensive code genera-

tion. Instead of generating the IOC together with the RTE, a sequential code generation

process is used, to separate generic RTE code generation and hardware dependent

IOC code generation as much as possible. The following steps shall be performed:

• Step 1: Specify all information about the allocation of Software Components to

OS-Applications and cores in the ECU Configuration Description file.

• Step 2: Generate the RTE. The RTE generator creates data element specific IOC

services calls and the corresponding IOC Configuration Description blocks (XML

format) to specify the communication relations for each data element.

• Step 3: Generate the IOC code, according to the IOC Configuration Description

(Step 2) while considering the hardware description files. Additionally, generate a

header file (Ioc.h) for inclusion in RTE.c to provide definitions, function prototypes

and macros.

Each atomic communication has to be specified in the IOC Configuration Description

in a standardized XML format. There is one description block per communication op-

eration specifying:

• Unique identifier

• Data type(s)

• Sender properties

• Receiver properties

• Name of callback function on receiver side in case of notification.

• Whether communication is queued or unqueued (last is best)

• In case of queued communication: Length of the queue

For details see chapter 10.3

For each inter-OS-Application communication, the RTE generator creates one or more

calls to an IOC function to send or receive data, and adds a corresponding description

block to the IOC Configuration Description.

There are possibly multiple sources which contribute to the IOC configuration (e.g.,

RTE, CDD). The main input will come from the RTE generator. Other sources for the

115 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

IOC Configuration Description (not supported in this specification revision) might be

BSW module configuration tools or non-AUTOSAR components, which are allowed to

use BSW services.

In ECUs or Software Clusters with only one OS-Application, the IOC Configuration

Description can be omitted.

[SWS_Os_00824] dAll the data allocated by the OS for the IOC communication shall

be wrapped with the memory allocation keywords mechanism

1 #define OS_<IE>_START_SEC_<sadm>

2 #include "Os_MemMap.h"

4 <IOC buffers>

6 #define OS_<IE>_STOP_SEC_<sadm>

7 #include "Os_MemMap.h"

where <IE> is the shortName of the sending OsApplication configured in Os-

IocSendingOsApplicationRef of the respective OsIocCommunication chan-

nel, and <sadm> is the shortName of the referred swAddrMethod, if configured in

OsMemoryMappingCodeLocationRef of the respective OsIocDataProperties

within the OsIocCommunication channel. If the OsMemoryMappingCodeLoca-

tionRef is not defined the OS is permitted to select an appropriate swAddrMethod.c

()

7.10.7 IOC integration examples

This section describes two typical use cases that show how the IOC can support com-

munication between OS-Applications. In both examples the OS-Applications are lo-

cated on different cores of a Multi-Core system.

7.10.7.1 Example 1 - 1:1 sender/receiver communication without notification

One Software Component sends data items in event semantics (queued) to another

Software Component located on a different core. A runnable entity on the receiver side

is invoked periodically (e.g. by an Alarm) and receives the data via RTE (see figure

7.24).

Because the communication crosses core boundaries, the RTE invokes the IOC to

transfer the data from core 0 to core 1.

On the sending side, the

Rte_Send_<port>_<item> (..., <data>)

call is mapped to an

IocSend_<Id> (<data>)

116 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

call.

Figure 7.24: IOC without notification

In this example, the IocSend service writes the data into a buffer, located in a shared

memory area which can get read by the receiver via the IOC.

On the receiving side, the receiving runnable gets invoked periodically. The

Rte_Receive_<port>_<item> (..., <data>)

call is mapped to an

IocReceive_<Id> (<data>)

call to read data from the IOC internal queue. An additional queue within the RTE is

not necessary for 1:1 communication.

The IOC generator generates all the send and receive functions. The functions might

be defined as macros for optimization purposes.

This kind of port to port communication without notification is suitable for:

• Sender/receiver communication

• Queued or unqueued communication

• 1:1 communication.

117 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

7.10.7.2 Example 2 - N:1 client/server communication with receiver notification

by RTE

One Software Component invokes a service operation that is provided by another Soft-

ware Component located on a different core. A r unnable entity on the receiver side is

activated to calculate the result (see figure 7.25).

The RTE realizes the service on client side by mapping the client/server call to a

sender/receiver communication. Because the communication crosses core bound-

aries, the RTE uses the IOC to transfer the data from Core 0 to Core 1.

On the sending side, the

Rte_Call_<port>_<op> (..., <data>)

call is mapped to a

IocSend_<Id> (<data>)

call to transmit the parameters over the IOC to the core hosting the server runnable.

Figure 7.25: IOC with notification by RTE

After writing the data into the IOC internal queue buffer, the Rte_Call function uses

an OS call to notify the receiver by activating the server Task on the receiving core.

This Task is provided by the RTE. This Task body is responsible for reading the data

from the IOC buffer by calling IocReceive function and for forwarding the data to the

server runnable. Depending on the return value of the IOC function, the IocReceive

118 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

and server runnable calls might be repeated several times to empty the IOC internal

queued buffer (if specified).

The result of the service on Core 1 is transferred back to the client on Core 0 in a

similar way. The communication path of the result is not displayed in figure 7.25.

This kind of port to port communication with notification by the RTE is suitable for:

• Sender/receiver communication with notification

• Client/server communication. In this case the RTE has to provide services to

map the server call into 1:1 sender/receiver communication for the server call

and another sender/receiver communication to return the result to the client

• Queued or unqueued communication

• 1:1 communication, if the receiver does not poll for data periodically (In this case,

the solution in example 1 might have been more suitable)

• N:1 communication.

7.10.8 Future extensions

Some features are not supported by the first release of this specification, but might get

added in a later release:

• In the future, the IOC will handle direct and efficient communication among BSW

modules or between BSW modules and Software Components (via the RTE)

located in different OS applications. Additional support of direct access from

BSW modules to IOC services will be added.

• Other notification options (like activation of a specified Task on receiver side)

might be added later to the IOC.

7.11 System Scalability

7.11.1 Background & Rationale

In order to customize the operating system to the needs of the user and to take full

advantage of the processor features the operating system can be scaled according to

the following scalability classes

Feature De-

scribed

Section

Scala-

bility

Class 1

Scala-

bility

Class 2

Scala-

bility

Class 3

Scala-

bility

Class 4

Hardware requirements

119 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

OSEK OS (all

conformance classes)

7.1 Yes Yes Yes Yes

Counter Interface

8.4.17 Yes Yes Yes Yes

SWFRT Interface

8.4.18,

8.4.19

Yes Yes Yes Yes

ScheduleTables 7.3 Yes Yes Yes Yes

Stack Monitoring

7.5 Yes Yes Yes Yes

ProtectionHook 7.8 Yes Yes Yes

Timing Protection 7.7.2 Yes Yes

Timer(s) with high priority interrupt

Global

Time/Synchronization

Support

7.4 Yes Yes

Global time source

Memory Protection 7.7.1,

7.7.4

Yes Yes MPU

OS-Applications

7.6,

7.12

Yes Yes

Service Protection

7.7.3 Yes Yes

CallTrustedFunc-

tion

7.7.5 Yes Yes

(Non-)privileged Modes

Table 7.4: Scalability classes

Feature

Scalability

Class 1

Scalability

Class 2

Scalability

Class 3

Scalability

Class 4

Minimum number of

ScheduleTables supported

2 8 2 8

Minimum number of

OS-Applications supported

0 0 2 2

Minimum number of software

Counters supported

8 8 8 8

Table 7.5: Minimum requirements of scalability classes

7.11.2 Requirements

[SWS_Os_00240] dIf an implementation of a lower scalability class supports features

of higher classes then the interfaces for the features must comply with this Operating

System software specification.c(SRS_Os_11012, SRS_Os_11016)

[SWS_Os_00241] dThe Operating System module shall support the features accord-

ing to the configured scalability class. (See table 7.4)c(SRS_Os_11012, SRS_Os_-

11016)

[SWS_Os_00327] dThe Operating System module shall always use extended status

in Scalability Class 3 and 4.c()

see [SWS_Os_00764]

120 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

7.12 Hook Functions

7.12.1 Background & Rationale

Hook routines as defined in OSEK OS run at the level of the Operating System module

and therefore can only belong to the trusted environment. Furthermore, these hook

routines are global to the system (system-specific) and will probably be supplied by the

ECU integrator.

In AUTOSAR however, each OS-Application may have the need to execute application

specific code e.g. initialize some hardware in its own additional (application-specific)

startup hook. These are called application specific hook routines. In general the appli-

cation specific hooks have the same properties as the hook routines described in the

OSEK OS specification. Differences are described below.

7.12.2 Requirements

[SWS_Os_00439] dThe Operating System module shall provide the OSEK error

macros (OSError...()) to all configured error hooks AND there shall be two (like

in OIL) global configuration parameters to switch these macros on or off.c()

StartupHook

[SWS_Os_00060] dIf an application-specific startup hook is configured for an OS-

Application <App>, the Operating System module shall call StartupHook_<App> on

startup of the Operating System module.c()

[SWS_Os_00226] dThe Operating System module shall execute an application-

specific startup hook with the access rights of the associated OS-Application.c()

[SWS_Os_00236] dIf both a system-specific and one (or more) application specific

startup hook(s) are configured, the Operating System module shall call the system-

specific startup hook before the application-specific startup hook(s).c()

ShutdownHook

[SWS_Os_00112] dIf an application-specific shutdown hook is configured for an OS-

Application <App>, the Operating System module shall call ShutdownHook_<App>

on shutdown of the OS.c()

[SWS_Os_00225] dThe Operating System module shall execute an application-

specific shutdown hook with the access rights of the associated OS-Application.c()

[SWS_Os_00237] dIf both a system-specific and one (or more) application specific

shutdown hook(s) are configured, the Operating System module shall call the system-

specific shutdown hook after the application-specific shutdown hook(s).c()

ErrorHook

121 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

[SWS_Os_00246] dWhen an error occurs AND an application-specific error hook is

configured for the faulty OS-Application <App>, the Operating System module shall

call that application-specific error hook ErrorHook_<App> after the system specific

error hook is called (if configured).c(SRS_Os_11013)

[SWS_Os_00085] dThe Operating System module shall execute an application-

specific error hook with the access rights of the associated OS-Application.c()

[SWS_Os_00367] dOperating System module’s services which do not return a Sta-

tusType - except ActivateTaskAsyn and SetEventAsyn - shall not raise the error

hook(s).c()

7.13 Hardware peripheral access

7.13.1 Background & Rationale

On some MCU architectures, there are memory mapped hardware registers (peripheral

area), which are only accessible in specific modes (e.g. in privileged mode). As long

as a Tasks/ISRs is running with full hardware access they can directly access these

registers. If memory protection is used by the Operating System, Task/ISRs of non-

trusted Os-Applications cannot access such registers directly because this would be

recognized as a memory violation by the Operating System.

To allow access to such registers even from non-trusted applications the Operating

Systems offers the following APIs to read, write and modify registers:

• ReadPeripheral8

• ReadPeripheral16

• ReadPeripheral32

• WritePeripheral8

• WritePeripheral16

• WritePeripheral32

• ModifyPeripheral8

• ModifyPeripheral16

• ModifyPeripheral32

In order to control the access to the registers the access has to be configured for each

OsApplication. By this the Os can check during run-time if a caller has sufficient

rights.

122 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

7.13.2 Requirements

[SWS_Os_00806] dCheck access to peripheral registers

The Operating System shall only execute access to peripheral registers via APIs Read

PeripheralX, WritePeripheralX and ModifyPeripheralX if :

• parameter Address is in range of OsPeripheralAreaStartAddress and Os-

PeripheralAreaEndAddress

• parameter Area is valid

• the caller is configured to have sufficient rights (OsPeripheralAreaAc-

cessingApplication).

c(SRS_Os_11005)

[SWS_Os_00807] dError handling of peripheral access API

If the Operating System detects an error (see [[SWS_Os_00806]]) while executing a

ReadPeripheralX, WritePeripheralX and ModifyPeripheralX the OS shall return the ap-

propriate StatusType and call the ErrorHook. Otherwise E_OK shall be returned.c

(SRS_Os_11005)

7.14 Interrupt source API

7.14.1 Background & Rationale

The Operating System needs to guarantee the scheduling, wherefore it needs to be the

only component which accesses the interrupt controller. Therefore it provides to other

BSW/CDD components the interfaces DisableInterruptSource, EnableInter-

ruptSource and ClearPendingInterrupt to give access to the interrupt control

registers of category 2 ISRs.

The pair of DisableInterruptSource/EnableInterruptSource may be used

for two different purposes:

1. A specific interrupt should be masked for a short time (potentially to avoid data con-

sistency problems). A masked request shall be served afterwards, once the interrupt

source gets enabled again.

2. Interrupt requests of a specific source should be ignored for a specific time (poten-

tially a longer time e.g. while the CAN driver sleeps). After enabling the source, only

new requests should be considered.

123 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

7.14.2 Requirements

[SWS_Os_00808] dThe Operating System shall provide for each category 2 interr upt

source (OsIsrCategory == CATEGORY_2) the APIs DisableInterruptSource,

EnableInterruptSource and ClearPendingInterrupt.c(SRS_Os_11011)

DisableInterruptSource/EnableInterruptSource does not support nested

calls.

[SWS_Os_00809] dNested calls of interrupt source control API

The Operating System shall return E_OS_NOFUNC (in EXTENDED status) in case Dis-

ableInterruptSource is called for an interrupt source which is already disabled or

EnableInterruptSource is called for an interrupt source which is already enabled.c

(SRS_Os_11011)

[SWS_Os_00810] dError handling of interrupt source control API

If the Operating System detects an error while executing a DisableInterrupt-

Source, EnableInterruptSource and ClearPendingInterrupt the OS shall

return the appropr iate StatusType and call the ErrorHook. Otherwise E_OK shall

be returned.c(SRS_Os_11011)

[SWS_Os_00811] dA call of EnableInterruptSource shall enable the requested

interrupt source by modifying the interrupt controller registers. Additionally it shall clear

the interrupt pending flag.c(SRS_Os_11011)

[SWS_Os_00812] dA call of DisableInterruptSource shall disable the requested

interrupt source by modifying the interrupt controller registers.c(SRS_Os_11011)

[SWS_Os_00813] dA call of ClearPendingInterrupt shall clear the interrupt

pending flag by modifying the respective interrupt controller registers.c(SRS_Os_-

11011)

[SWS_Os_00814] dClearing of pending interrupts shall be restricted to clearing the

pending flag in the interrupt controller.c(SRS_Os_11011)

Note: This does not necessarily guarantee that the interrupt request is cleared suc-

cessfully, i.e. the ISR may still be serviced afterwards. (This may happen due to racing

conditions or as the request needs to be cleared in the requesting hardware unit also.)

7.15 Error classification

AUTOSAR BSW modules normally report their errors to Det (development errors) or

Dem (production errors). The OS handles errors differently (see also [2]) and does not

report its errors to Dem/Det. If a reporting of errors to Dem/Det is needed the user can

perform these actions in the ErrorHook.

The following table contains all error codes which might be reported from the OS (be-

sides those already defined in [2])

124 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

[SWS_Os_91025] d

Type of error

Related error code Error value

An invalid address is given as a parameter to a

service.

E_OS_ILLEGAL_ADDRESS

Assigned by

implementation

A memory access violation occurred

E_OS_PROTECTION_MEMORY

Assigned by

implementation

A stack fault detected via stack monitoring by the

E_OS_STACKFAULT

Assigned by

implementation

Core is not available E_OS_CORE

Assigned by

implementation

Potential deadlock due to wrong nesting

E_OS_NESTING_DEADLOCK

Assigned by

implementation

Tasks terminates without a TerminateTask() or

ChainTask() call.

E_OS_MISSINGEND

Assigned by

implementation

A Task/Category 2 ISR blocks for too long E_OS_PROTECTION_LOCKED

Assigned by

implementation

De-scheduling with occupied spinlock

E_OS_SPINLOCK

Assigned by

implementation

A null pointer was given as argument

E_OS_PARAM_POINTER

Assigned by

implementation

Service cannot be called. E_OS_SERVICEID

Assigned by

implementation

A trap occurred

E_OS_PROTECTION_EXCEPTION

Assigned by

implementation

Deadlock situation due to interference E_OS_INTERFERENCE_DEADLOCK

Assigned by

implementation

A Task or Category 2 ISR exceeds its execution

time budget

E_OS_PROTECTION_TIME

Assigned by

implementation

A service of the OS is called inside an interrupt

disable/enable pair.

E_OS_DISABLEDINT

Assigned by

implementation

A Task/Category 2 ISR arrives before its

timeframe has expired

E_OS_PROTECTION_ARRIVAL

Assigned by

implementation

c(SRS_BSW_00480)

7.16 ARTI Debug Information

[SWS_Os_00858] dThe OS shall create an ARTI module description file.c(SRS_Os_-

12001)

[SWS_Os_00829] dARTI module description file shall support all ORTI containers.c

(SRS_Os_12003)

The ARTI Debug Information intends to enable the attached tool to evaluate and display

information about the operating system, its state, its performance, the different Task

states, the different operating system objects etc.

Additionally the ARTI Debug Information contains dynamic information as a set of at-

tributes that are represented by formulas to access corresponding dynamic values.

Formulas for dynamic data access are comprised of constants, operations, and sym-

bolic names within the target file. To obtain internal values of the required OS objects,

the debug tool can then evaluate the given formula.

125 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

7.16.1 OS ARTI Objects

It describes a set of attributes for system objects and a method for interpreting the

data obtained. The types defined in the section are specified to allow the debugger

to determine the target memory access method as well as the best way of displaying

the retrieved data. In most cases the information that the user will require to see is a

textual description of an attribute rather than the actual value read from the variable.

An example of this is as follows; when a user requests the current state of a Task he

will expect to see something like RUNNING, WAITING, READY or SUSPENDED, instead

of the actual numeric value that is used by the OS to represent this information inter-

nally. For this reason a mapping is specified, which allows a kernel manufacturer to

describe how an internal OS value must be mapped to a descriptive value.

• ArtiOs

• ArtiHwCore

• ArtiOsAlarm

• ArtiOsContext

• ArtiOsIsr

• ArtiOsResource

• ArtiOsMessageContainer

• ArtiOsStack

• ArtiOsTask

These objects are declared in Arti containers with definitions named "*Class". The

instances of these objects are placed in the same Arti container with definitions named

"*Instance".

7.17 ARTI Hook Macros

[SWS_Os_00836] dThe OS shall incorporate special macros that can be used by an

ARTI trace tool to insert tracing functionality of any kind.c(RS_ARTIFO_00014, SRS_-

Os_12002)

[SWS_Os_00837] dThe hooks for an AUTOSAR CP OS shall follow the general

structure of ARTI macros: ARTI_TRACE(_contextName, _className, _in-

stanceName, instanceParameter, _eventName, eventParameter);c

(RS_ARTIFO_00014, SRS_Os_12002)

Some of the parameters are using literal text (Token) rather than a symbolic identi-

fier. This allows a macro definition concatenating these parameters to more specific

macros. Passing and evaluating all parameters at run-time would be very costly es-

pecially by means of run-time consumption. Here is a possible implementation of the

126 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

generic ARTI_TRACE macro as it could be defined by a ARTI trace tool vendor to match

the interface of his trace tool:

1 #define ARTI_TRACE(_contextName, _className, _instanceName,

instanceParameter, _eventName, eventParameter) \

2 ARTI_TRACE ## _ ## _className ## _ ## _eventName ## _ ## _instanceName

## _ ## _contextName ( (instanceParameter), (eventParameter) )

Such an implementation will generate one hook for all the possible combinations of

_className, _eventName and _contextName and pass only parameters instance_id

and event_value at run-time.

The parameters’ meanings are described in the following.

• _contextName Token, literal text, name of the context. One of the following:

– NOSUSP indicating that the hook gets called in a context where interrupts

are disabled

– SPRVSR indicating that the called hook may disable interrupts

– USER indicating the called hook cannot disable interrupts

• _className Token, literal text, name of the class of macros. Predefined classes

for an AUTOSAR OS are:

– AR_CP_OS_APPLICATION starts and stops the application

– AR_CP_OS_TASK schedules Tasks

– AR_CP_OS_CAT2ISR dispatches Category 2 interrupts

– AR_CP_OS_SERVICECALLS calls service routines

– AR_CP_OS_SPINLOCK calls spinlocks

– AR_CP_OS_PROTECTIONHOOK calls ProtectionHook

• _instanceName Short name of the OS instance as defined in the ARXML.

• instanceParameter Index [uint32] 0..4294967295 of the CPU core as seen by the

OS (<Core Index>). Should always start with 0 and count up consecutively. This

might be equal to the index of the physical core, but doesn’t have to be.

• _eventName Token, literal text, name of the event as defined for a particular class.

• eventParameter A [uint32] 0..4294967295 value as an argument to an event.

Therefore all ARTI macros for an AUTOSAR OS do compile the following template:

1 ARTI_TRACE(_contextName, <AR OS Class Name>, <OS Short Name>, <Core

Index>, <Event Name>, <Event Parameter>)

Example of hook call in OS:

1 ARTI_TRACE( NOSUSP, AR_CP_OS_TASK, OS1, (uint32)GetCoreID(),

OsTask_Activation, (uint32)GetTaskID() );

127 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Example of preprocessed output:

1 ARTI_TRACE_NOSUSP_AR_CP_OS_TASK_OS1_OsTask_Activation( (uint32)

GetCoreID(), (uint32)GetTaskID() );

7.17.1 Class AR_CP_OS_APPLICATION

[SWS_Os_00838] dThe OS shall create events of class AR_CP_OS_APPLICATION

to allow tracing of OS applications [as defined for the AUTOSAR Classic Platform]c

(RS_Arti_00029)

The states used by ARTI are based on the states of OS-Applications, see figure 7.10

in chapter Background & Rationale 7.6.1 for details.

States used by ARTI:

ARTI

Initial -

Accessible APPLICATION_ACCESSIBLE

Restarting APPLICATION_RESTARTING

Terminated APPLICATION_TERMINATED

Transitions used by ARTI:

Name Transition Event Name

Start

Initial -> Accessible

OsApplication_Start

Restart Accessible -> Restarting

OsApplication_Restart

AllowAccess Restarting -> Accessible

OsApplication_AllowAccess

Terminate Accessible -> Terminated

OsApplication_Terminate

[SWS_Os_00839] dARTI macros of the class AR_CP_OS_APPLICATION shall com-

pile the following template:

1 ARTI_TRACE(_contextName, AR_CP_OS_APPLICATION, <OS Short Name>, <Core

ID>, <Event Name>, <Application ID>)

c(RS_ARTIFO_00015)

The <Core ID> for any event shall represent the core id where the corresponding ap-

plication is running on.

The <Event Name> should follow the transition table above.

The <Application ID> shall be a numeric identifier of the OS Application.

128 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

7.17.2 Class AR_CP_OS_TASK

ARTI needs to trace all Task states and all state transitions within the OS. For some

timing parameters (e.g. the "runtime" of a Task, which goes from started to termi-

nated), the simple "ready" state of the OS is not enough. Tools evaluating the timings

need to reconstruct a more complex state diagram by calculating the transitions from

history. To be compatible to the pure OS state diagram, AR_CP_OS_TASK refers to

this state model, knowing that tools need to postprocess the event flow to get all rele-

vant information. However, if an OS implementation can provide a more detailed state

diagram, ARTI allows to define more events that won’t need postprocessing and allow

earlier synchronization of the trace if it is truncated (limited trace buffers). This state di-

agram is then handled with the class "AR_CP_OSARTI_TASK". If possible, the second

state machine is to be preferred.

AR_CP_OS_TASK

[SWS_Os_00840] dThe OS shall create events of class AR_CP_OS_TASK to allow

tracing of Tasks.c(RS_Arti_00030)

The following state diagram shows the states and transitions as defined by the OS:

Figure 7.26: ARTI Task states

Transitions used by ARTI:

Name Transition Event Name

Activate

Suspended -> Ready OsTask_Activate

Start

Ready -> Running

OsTask_Start

Preempt Running -> Ready

OsTask_Preempt

Wait Running -> Waiting

OsTask_Wait

Release Waiting -> Ready

OsTask_Release

Terminate

Running -> Suspended OsTask_Terminate

129 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

AR_CP_OSARTI_TASK

The class AR_CP_OSARTI_TASK contains events allowing the tracing of OS Tasks

with an enhanced state model.

The following states diagram shows the state machine as used by ARTI:

Figure 7.27: ARTI enhanced Task states

States used by ARTI:

ARTI

Suspended

SUSPENDED

Activated READY

Running RUNNING

Preempted READY

Waiting WAITING

Released READY

Transitions used by ARTI:

130 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Name Transition Event Name

Activate

Suspended -> Activated OsTask_Activate

Start

Activated -> Running

OsTask_Start

Preempt Running -> Preempted

OsTask_Preempt

Resume Preempted -> Running

OsTask_Resume

Wait Running -> Waiting

OsTask_Wait

Release Waiting -> Released

OsTask_Release

Continue

Released -> Running

OsTask_Continue

Terminate

Running -> Suspended OsTask_Terminate

[SWS_Os_00841] dARTI macros of the classes AR_CP_OS_TASK and AR_CP_OS-

ARTI_TASK shall compile the following templates:

1 ARTI_TRACE(_contextName, AR_CP_OS_TASK, <OS Short Name>, <Core ID>, <

Event Name>, <Task ID>)

2 ARTI_TRACE(_contextName, AR_CP_OSARTI_TASK, <OS Short Name>, <Core ID>,

<Event Name>, <Task ID>)

c(RS_ARTIFO_00015)

The <Core ID> for any event shall represent the core id where the corresponding Task

is scheduled on.

The <Event Name> should follow the transition table above.

The <Task ID> shall be a numeric identifier of the OS Task.

7.17.3 Class AR_CP_OS_CAT2ISR

[SWS_Os_00849] dThe OS shall create events to trace all states of Cat2Isrs and all

state transitions within the OS ("Cat2Isr" refers to a category 2 interrupt service rou-

tine).c(RS_Arti_00031)

For some timing parameters (e.g. the interrupt pending time), the simple Category

2 interrupt start/stop of the OS is not enough. Tools evaluating the timings need to

reconstruct a more complex state diagram by calculating the transitions from history.

To be compatible to the OS, AR_CP_OS_CAT2ISR refers to this state model, knowing

that tools need to postprocess the event flow to get all relevant infor mation. However,

if an OS implementation can provide a more detailed state diagram, ARTI allows to

define more events that won’t need postprocessing and allow earlier synchronization

of the trace if it is truncated (limited trace buffers). This state diagram is then handled

with the class "AR_CP_OSARTI_CAT2ISR". If possible, the second state machine is

to be preferred.

AR_CP_OS_CAT2ISR

The class AR_CP_OS_CAT2ISR contains events allowing the tracing of Category 2

interrupts as defined for the AUTOSAR Classic Platfor m.

The following state diagram shows the states and transitions as defined by the OS:

131 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Figure 7.28: ARTI category 2 ISR states

Transitions used by ARTI:

Name Transition Event Name

Start

Inactive -> Running

OsCat2Isr_Start

Stop

Running -> Inactive

OsCat2Isr_Stop

AR_CP_OSARTI_CAT2ISR

The class AR_CP_OSARTI_CAT2ISR contains events allowing the tracing of Category

2 interrupts with an enhanced state model.

The following state diagram shows the state machine as used by ARTI:

Figure 7.29: ARTI enhanced category 2 ISR states

States used by ARTI:

132 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

ARTI

Inactive Inactive

Activated Inactive

Running Running

Preempted Running

Transitions used by ARTI:

Name Transition Event Name

Activate Inactive-> Activated

OsCat2Isr_Activate

Start

Activated -> Running

OsCat2Isr_Start

Preempt Running -> Preempted

OsCat2Isr_Preempt

Resume Preempted -> Running

OsCat2Isr_Resume

Stop

Running -> Inactive

OsCat2Isr_Stop

[SWS_Os_00842] dARTI macros of the classes AR_CP_OS_CAT2ISR and AR_CP_

OSARTI_CAT2ISR shall compile the following template:

1 ARTI_TRACE(_contextName, AR_CP_OS_CAT2ISR, <OS Short Name>, <Core Index

>, <Event Name>, <Cat2Isr Index>)

2 ARTI_TRACE(_contextName, AR_CP_OSARTI_CAT2ISR, <OS Short Name>, <Core

Index>, <Event Name>, <Cat2Isr Index>)

c(RS_ARTIFO_00015)

The <Core Index> for any event shall represent the core index where the corresponding

Category 2 interrupt is scheduled on.

The <Event Name> should follow the transition table above.

The <Cat2Isr Index> shall be a numeric identifier of the Category 2 interrupt.

7.17.4 Class AR_CP_OS_SERVICECALLS

[SWS_Os_00843] dThe OS shall create events of class AR_CP_OS_SERVICECALLS

when entering and exiting the service call from an application context.c(RS_Arti_-

00032)

These hooks shall only be called, if the service call is called from an application context.

It shall not be called, if the service call is used within the OS context.

The events apply only to the entries and exits of the ser vice calls, not to the objects

(and their states) handled by the service call.

[SWS_Os_00844] dARTI macros of the class AR_CP_OS_SERVICECALLS shall

compile the following template:

1 ARTI_TRACE(_contextName, AR_CP_OS_SERVICECALLS, <OS Short Name>, <Core

Index>, <eventName>, <eventParameter>)

c(RS_ARTIFO_00015)

133 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

The <Core Index> for any event in the following table shall represent the core id where

the corresponding service call is called.

The <eventName> is a string literal composed of a prefix "OsServiceCall", the ser-

vice call name and "_Start" or "_Retur n" for the entry or exit of the service call. E.g.

when ActivateTask is called, the event names on entry and exit are OsServiceCall_

ActivateTask_Start rsp. OsServiceCall_ActivateTask_Return.

The <eventParamter> is an uint32 representation of either one of the function param-

eters or the return value. It depends on the service call and is listed in the following

table:

OS Service Call

From

eventParameter on Start

on Return

ActivateTask

OSEK

TaskID

(StatusType) returnValue

TerminateTask

OSEK

TaskID

(StatusType) returnValue

ChainTask

OSEK

TaskID

(StatusType) returnValue

Schedule

OSEK

(StatusType) returnValue

GetTaskID

OSEK

(TaskType) *TaskID

GetTaskState

OSEK

TaskID

(TaskStateType) *State

EnableAllInterrupts

OSEK

0 0

DisableAllInterrupts

OSEK

0 0

ResumeAllInterrupts

OSEK

0 0

SuspendAllInterrupts

OSEK

0 0

ResumeOSInterrupts

OSEK

0 0

SuspendOSInterrupts

OSEK

0 0

GetResource

OSEK

ResID

(StatusType) returnValue

ReleaseResource

OSEK

ResID

(StatusType) returnValue

SetEvent

OSEK

TaskID

(StatusType) returnValue

ClearEvent

OSEK

Mask

(StatusType) returnValue

GetEvent

OSEK

TaskID

(EventMaskType) * Event

WaitEvent

OSEK

Mask

(StatusType) returnValue

GetAlarmBase

OSEK

AlarmID

(AlarmBaseRefType) Info

GetAlarm

OSEK

AlarmID

(TickType) *Tick

SetRelAlarm

OSEK

AlarmID

(StatusType) returnValue

SetAbsAlarm

OSEK

AlarmID

(StatusType) returnValue

CancelAlarm

OSEK

AlarmID

(StatusType) returnValue

GetActiveApplication-

Mode

OSEK

(AppModeType) returnValue

StartOS

OSEK

Mode not applicable

ShutdownOS

OSEK

Error not applicable

GetApplicationID

AUTOSAR

(ApplicationType) return

Value

GetCurrentApplica-

tionID

AUTOSAR

(ApplicationType) return

Value

GetISRID

AUTOSAR

(ISRType) returnValue

CallTrustedFunction

AUTOSAR

FunctionIndex

(StatusType) returnValue

CheckISRMemoryAccess

AUTOSAR ISRID (AccessType) returnValue

CheckTaskMemoryAccess

AUTOSAR

TaskID

(AccessType) returnValue

CheckObjectAccess

AUTOSAR

ApplID

(ObjectAccessType) return

Value

134 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

OS Service Call

From

eventParameter on Start

on Return

CheckObjectOwnership

AUTOSAR

ObjectTypeType

(ApplicationType) return

Value

StartScheduleTableRel

AUTOSAR ScheduleTableID (StatusType) returnValue

StartScheduleTableAbs

AUTOSAR ScheduleTableID (StatusType) returnValue

StopScheduleTable

AUTOSAR ScheduleTableID (StatusType) returnValue

NextScheduleTable

AUTOSAR ScheduleTableID_To (StatusType) returnValue

StartScheduleTa-

bleSynchron

AUTOSAR ScheduleTableID (StatusType) returnValue

SyncScheduleTable

AUTOSAR ScheduleTableID (StatusType) returnValue

SetScheduleTableAsync

AUTOSAR ScheduleTableID (StatusType) returnValue

GetScheduleTableSta-

tus

AUTOSAR ScheduleTableID (ScheduleTableSta-

tusType) *Schedule

Status

IncrementCounter

AUTOSAR

CounterID

(StatusType) returnValue

GetCounterValue

AUTOSAR

CounterID

(TickType) *Value

GetElapsedValue

AUTOSAR

CounterID

(TickType) *ElapsedValue

TerminateApplication

AUTOSAR

Application

(StatusType) returnValue

AllowAccess

AUTOSAR

(StatusType) returnValue

GetApplicationState

AUTOSAR

Application

(

ApplicationStateType)

*Value

GetNumberOfActivated-

Cores

AUTOSAR

(uint32) returnValue

GetCoreID

AUTOSAR

(CoreIdType) returnValue

StartCore

AUTOSAR CoreID (StatusType) *Status

GetSpinlock

AUTOSAR SpinlockId (StatusType) returnValue

ReleaseSpinlock

AUTOSAR SpinlockId (StatusType) returnValue

TryToGetSpinlock

AUTOSAR SpinlockId (

TryToGetSpinlockType)

*Success

ShutdownAllCores

AUTOSAR

Error 0

ControlIdle

AUTOSAR

IdleMode

(StatusType) returnValue

ReadPeripheral8

AUTOSAR

Address

(uint8) *ReadValue

ReadPeripheral16

AUTOSAR

Address

(uint16) *ReadValue

ReadPeripheral32

AUTOSAR

Address

(uint32) *ReadValue

WritePeripheral8

AUTOSAR

Address

(StatusType) returnValue

WritePeripheral16

AUTOSAR

Address

(StatusType) returnValue

WritePeripheral32

AUTOSAR

Address

(StatusType) returnValue

ModifyPeripheral8

AUTOSAR

Address

(StatusType) returnValue

ModifyPeripheral16

AUTOSAR

Address

(StatusType) returnValue

ModifyPeripheral32

AUTOSAR

Address

(StatusType) returnValue

EnableInterruptSource

AUTOSAR ISRID (StatusType) returnValue

DisableInterrupt-

Source

AUTOSAR ISRID (StatusType) returnValue

ClearPendingInterrupt

AUTOSAR ISRID (StatusType) returnValue

ActivateTaskAsyn

AUTOSAR

id 0

SetEventAsyn

AUTOSAR

id 0

135 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

If the eventParameter of a returning service call is not of type StatusType, and if the

service call does not return E_OK, the hook shall be called with a non-valid value as

eventParameter, to give the hook consuming tool the possibility to detect the failure of

the call.

7.17.5 Class AR_CP_OS_SPINLOCK

[SWS_Os_00845] dThe OS shall create events of class AR_CP_OS_SPINLOCK to

allow tracing of OS spinlocks and all state transistions within the OS.c(RS_Arti_00033)

These macros mark an event of an actual state change, not the OS service call. (E.g.

getting a spinlock may happen later than requesting it; a request to release may not

cause a release if it is already released.)

Figure 7.30: ARTI spin lock states

[SWS_Os_00846] dARTI macros of the class AR_CP_OS_SPINLOCK shall compile

the following template:

1 ARTI_TRACE(_contextName, AR_CP_OS_SPINLOCK, <OS Short Name>, <Core

Index>, <_eventName>, <eventParameter>)

c(RS_ARTIFO_00015)

The <Core Index> for any event in the following table shall represent the core id where

the corresponding service call is called.

The following events are part of the class AR_CP_OS_SPINLOCK:

Event description

State transition

_eventName eventParameter

Locking Spinlock

Released -> Locked

OsSpinlock_Locked SpinlockId

Releasing Spinlock

Locked -> Released

OsSpinlock_Released SpinlockId

136 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

7.17.6 Class AR_CP_OS_HOOK

[SWS_Os_00856] dThe OS shall create events of class AR_CP_OS_HOOK when en-

tering and exiting the hook function.c(RS_Arti_00034)

[SWS_Os_00857] dARTI macros of the class AR_CP_OS_HOOK shall compile the

following template:

1 ARTI_TRACE(_contextName, AR_CP_OS_HOOK, <OS Short Name>, <Core Index>,

<eventName>, <eventParameter>)

c(RS_Arti_00034, RS_ARTIFO_00015)

The <Core Index> for any event in the following table shall represent the core id on

which the corresponding hook function is executed.

The <eventName> is a string literal composed of the prefix OsHook, the hook

function name and _Start or _Return for the entry or exit of the hook function.

E.g. when the ErrorHook is called, the event names on entry and exit are Os-

Hook_ErrorHook_Start respectively OsHook_ErrorHook_Return.

The <eventParamter> is an uint32 representation of either the function parameter

or the return value. It depends on the hook function and is listed in the following table:

OS hook function Origin eventParameter on Start

eventParameter on Return

ErrorHook

OSEK

Error 0

ErrorHook_<App>

AUTOSAR

Error 0

PostTaskHook

OSEK

0 0

PreTaskHook

OSEK

0 0

ProtectionHook

AUTOSAR

Fatalerror ReturnValue

StartupHook OSEK

0 0

StartupHook_<App> AUTOSAR

0 0

ShutdownHook OSEK

Error 0

ShurtdownHook_<App> AUTOSAR

Fatalerror 0

The ARTI hook which indicates the exit of the ProtectionHook (e.g. eventName

is OsHook_ProtectionHook_Return) shall be invoked after the OS has checked

the ReturnValue of the ProtectionHook (based on the requirements described in

chapter 7.8.2., for example [SWS_Os_00506] or [SWS_Os_00475]). The eventPa-

rameter of this ARTI hook shall reflect the action which is taken by the OS as a result

of the return value of the ProtectionHook.

137 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

8 API specification

This chapter contains the APIs offered by the operating system. Note that not all

services are available in all scalability classes, and that the behavior of some ser-

vices is extended for specific scalability classes. For example, API to relatively start a

ScheduleTable has an additional check if the ScheduleTable allows implicit syn-

chronization. This check is only performed in SC2 and SC4 where synchronization of

ScheduleTables is supported.

8.1 Constants

8.1.1 Error codes of type StatusType

The following constants are available in a multi-core environment.

[SWS_Os_91007] d

Name AppModeType

Kind

Enumeration

Range

DONOTCARE

– –

Description

AppMode of the core shall be inherited from another core.

Available via

Os.h

c()

[SWS_Os_91002] d

Name

TotalNumberOfCores

Kind

Type

Derived from

scalar

Range 1..65535 – –

Description

The total number of cores

Available via

Os.h

c()

Additional constants are in section 7.15 and [2].

8.2 Macros

OSMEMORY_IS_READABLE(<AccessType>)

OSMEMORY_IS_WRITEABLE(<AccessType>)

OSMEMORY_IS_EXECUTABLE(<AccessType>)

OSMEMORY_IS_STACKSPACE(<AccessType>)

138 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

These macros return a value not equal to zero if the memory is readable / writable

/ executable or stack space. The argument of the macros must be of type Ac-

cessType. Typically the return value of the service CheckTaskMemoryAccess (or

CheckISRMemoryAccess) is used as argument for these macros.

8.3 Type definitions

8.3.1 ApplicationType (for OS-Applications)

[SWS_Os_00772] d

Name ApplicationType

Kind

Type

Derived from

uint32

Range

INVALID_OSAPPLICATION

– –

Description

This data type identifies the OS-Application.

Available via

Os.h

c()

[SWS_Os_00826] dThe range of valid OS-Applications described by Application-

Type shall be zero-based and consecutive. The Value of INVALID_OSAPPLICATION

shall lie outside the range of valid OS-Application IDs.c(SRS_Os_80005)

Note: The OS may use other representations internally for a performance optimal im-

plementation.

8.3.2 ApplicationStateType

[SWS_Os_00773] d

Name

ApplicationStateType

Kind

Type

Derived from

scalar

APPLICATION_

ACCESSIBLE

– –

APPLICATION_

RESTARTING

– –

Range

APPLICATION_

TERMINATED

– –

Description

This data type identifies the state of an OS-Application.

Available via

Os.h

c()

139 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

8.3.3 ApplicationStateRefType

[SWS_Os_00774] d

Name

ApplicationStateRefType

Kind

Type

Derived from

pointer

Description

This data type points to location where a ApplicationStateType can be stored.

Available via

Os.h

c()

8.3.4 TrustedFunctionIndexType

[SWS_Os_00775] d

Name TrustedFunctionIndexType

Kind

Type

Derived from

scalar

Description

This data type identifies a trusted function.

Available via

Os.h

c()

8.3.5 TrustedFunctionParameterRefType

[SWS_Os_00776] d

Name

TrustedFunctionParameterRefType

Kind

Type

Derived from

pointer

Description

This data type points to a structure which holds the arguments for a call to a trusted function.

Available via

Os.h

c()

8.3.6 AccessType

[SWS_Os_00777] d

Name AccessType

Kind

Type

Derived from

integral

140 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Description

This type holds information how a specific memory region can be accessed.

Available via

Os.h

c()

8.3.7 ObjectAccessType

[SWS_Os_00778] d

Name

ObjectAccessType

Kind

Type

Derived from

implementation_specific

ACCESS

– –

Range

NO_ACCESS

– –

Description

This data type identifies if an OS-Application has access to an object.

Available via

Os.h

c()

8.3.8 ObjectTypeType

[SWS_Os_00779] d

Name

ObjectTypeType

Kind

Type

Derived from

implementation_specific

OBJECT_TASK

– –

OBJECT_ISR

– –

OBJECT_ALARM

– –

OBJECT_RESOURCE

– –

OBJECT_COUNTER

– –

Range

OBJECT_

SCHEDULETABLE

– –

Description

This data type identifies an object.

Available via

Os.h

c()

141 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

8.3.9 MemoryStartAddressType

[SWS_Os_00780] d

Name

MemoryStartAddressType

Kind

Pointer

Type void*

Description

This data type is a pointer which is able to point to any location in the MCU address space.

Available via

Os.h

c()

8.3.10 MemorySizeType

[SWS_Os_00781] d

Name

MemorySizeType

Kind

Type

Derived from

implementation_specific

Description

This data type holds the size (in bytes) of a memory region.

Available via

Os.h

c()

8.3.11 ISRType

[SWS_Os_00782] d

Name

ISRType

Kind

Type

Derived from

implementation_specific

Range

INVALID_ISR

– –

Description

This data type identifies an interrupt service routine (ISR).

Available via

Os.h

c()

142 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

8.3.12 ScheduleTableType

[SWS_Os_00783] d

Name

ScheduleTableType

Kind

Type

Derived from

implementation_specific

Description

This data type identifies a schedule table.

Available via

Os.h

c()

8.3.13 ScheduleTableStatusType

[SWS_Os_00784] d

Name

ScheduleTableStatusType

Kind

Type

Derived from

implementation_specific

SCHEDULETABLE_

STOPPED

– –

SCHEDULETABLE_NEXT

– –

SCHEDULETABLE_

WAITING

– –

SCHEDULETABLE_

RUNNING

– –

Range

SCHEDULETABLE_

RUNNING_AND_

SYNCHRONOUS

– –

Description

This type describes the status of a schedule. The status can be one of the following: o The

schedule table is not started (SCHEDULETABLE_STOPPED) o The schedule table will be started

after the end of currently running schedule table (schedule table was used in NextScheduleTable()

service) (SCHEDULETABLE_NEXT) o The schedule table uses explicit synchronization, has been

started and is waiting for the global time. (SCHEDULETABLE_WAITING) o The schedule table is

running, but is currently not synchronous to a global time source (SCHEDULETABLE_RUNNING)

o The schedule table is running and is synchronous to a global time source (SCHEDULETABLE_

RUNNING_AND_SYNCHRONOUS)

Available via

Os.h

c()

8.3.14 ScheduleTableStatusRefType

[SWS_Os_00785] d

Name

ScheduleTableStatusRefType

Kind

Pointer

Type

ScheduleTableStatusType*

143 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Description

This data type points to a variable of the data type ScheduleTableStatusType.

Available via

Os.h

c()

8.3.15 ProtectionReturnType

[SWS_Os_00787] d

Name ProtectionReturnType

Kind

Type

Derived from

implementation_specific

PRO_IGNORE

– –

PRO_TERMINATETASKISR

– –

PRO_TERMINATEAPPL

– –

PRO_TERMINATEAPPL_

RESTART

– –

Range

PRO_SHUTDOWN

– –

Description

This data type identifies a value which controls further actions of the OS on return from the

protection hook.

Available via

Os.h

c()

8.3.16 RestartType

[SWS_Os_00788] d

Name RestartType

Kind

Type

Derived from

implementation_specific

RESTART

– –

Range

NO_RESTART

– –

Description

This data type defines the use of a Restart Task after terminating an OS-Application.

Available via

Os.h

c()

144 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

8.3.17 PhysicalTimeType

[SWS_Os_00789] d

Name PhysicalTimeType

Kind

Type

Derived from

implementation_specific

Description

This data type is used for values returned by the conversion macro (see SWS_Os_00393) OS_

TICKS2<Unit>_<Counter>().

Available via

Os.h

c()

8.3.18 CoreIdType

[SWS_Os_00790] d

Name

CoreIdType

Kind

Type

Derived from

scalar

OS_CORE_ID_MASTER

–

refers to the master core, may be

an alias for OS_CORE_ID_<x>

Range

OS_CORE_ID_0..OS_

CORE_ID_65533

–

refers to logical core 0, core 1 etc.

Description

CoreIdType is a scalar that allows identifying a single core. The CoreIdType shall represent the

logical CoreID

Available via

Os.h

c()

[SWS_Os_00825] dThe range of valid Core-IDs described by CoreIdType shall be

zero-based and consecutive.c(SRS_Os_80011)

8.3.19 SpinlockIdType

[SWS_Os_00791] d

Name

SpinlockIdType

Kind

Type

Derived from

scalar

1..65535 –

0x01, 0x02, ...: identifies a

spinlock instance

Range

INVALID_SPINLOCK

0 represents an invalid spinlock

instance

Description

SpinlockIdType identifies a spinlock instance and is used by the API functions: GetSpinlock,

ReleaseSpinlock and TryToGetSpinlock.

Available via

Os.h

c()

145 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

8.3.20 TryToGetSpinlockType

[SWS_Os_00792] d

Name

TryToGetSpinlockType

Kind

Enumeration

TRYTOGETSPINLOCK_

SUCCESS

–

Spinlock successfully occupied

Range

TRYTOGETSPINLOCK_

NOSUCCESS

– Unable to occupy the spinlock

Description

The TryToGetSpinlockType indicates if the spinlock has been occupied or not.

Available via

Os.h

c(SRS_Os_80021)

8.3.21 IdleModeType

[SWS_Os_00793] d

Name IdleModeType

Kind

Type

Derived from

scalar

Range

IDLE_NO_HALT

–

the core does not perform any

specific actions during idle time

Description

This data type identifies the idle mode behavior.

Available via

Os.h

c()

8.3.22 AreaIdType

[SWS_Os_91000] d

Name AreaIdType

Kind

Type

Derived from

scalar

Range 0..65534 –

identifies a peripheral area

Description

AreaIdType identifies a peripheral area and is used by the API functions: ReadPeripheralX, Write

PeripheralX and ModifyPeripheralX

Available via

Os.h

c()

146 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

8.4 Function definitions

The availability of the following services is defined in table 7.4. The use of these ser-

vices may be restricted depending on the context they are called from. See table 7.1

for details.

8.4.1 GetApplicationID

[SWS_Os_00016] d

Service Name

GetApplicationID

Syntax

ApplicationType GetApplicationID (

void

)

Service ID [hex]

0x00

Sync/Async

Synchronous

Reentrancy Reentrant

Parameters (in)

None

Parameters (inout)

None

Parameters (out)

None

Return value ApplicationType

<identifier of running OS-Application> or

INVALID_OSAPPLICATION

Description

This service determines the OS-Application (a unique identifier has to be allocated to each

application) where the caller originally belongs to (was configured to).

Available via

Os.h

c()

[SWS_Os_00261] dGetApplicationID shall return the application identifier to

which the executing Task/ISR/hook was configured.c()

[SWS_Os_00262] dIf no OS-Application is running, GetApplicationID shall return

INVALID_OSAPPLICATION.c()

[SWS_Os_00514] dAvailability of GetApplicationID: Available in Scalability

Classes 3 and 4 and in multi-core systems.c()

8.4.2 GetCurrentApplicationID

[SWS_Os_00797] d

Service Name

GetCurrentApplicationID

Syntax

ApplicationType GetCurrentApplicationID (

void

)

Service ID [hex]

0x27

147 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Sync/Async

Synchronous

Reentrancy Reentrant

Parameters (in)

None

Parameters (inout)

None

Parameters (out)

None

Return value ApplicationType

<identifier of the OS-Application> or INVALID_OSAPPLICATION

Description

This service determines the OS-Application where the caller of the service is currently

executing. Note that if the caller is not within a CallTrustedFunction() call the value is equal to

the result of GetApplicationID().

Available via

Os.h

c()

[SWS_Os_00798] dGetCurrentApplicationID shall return the application identi-

fier in which the current Task/ISR/hook is executed.c()

[SWS_Os_00799] dIf no OS-Application is running, GetCurrentApplicationID

shall return INVALID_OSAPPLICATION.c()

[SWS_Os_00800] dAvailability of GetCurrentApplicationID: Available in Scala-

bility Classes 3 and 4.c()

8.4.3 GetISRID

[SWS_Os_00511] d

Service Name

GetISRID

Syntax

ISRType GetISRID (

void

)

Service ID [hex]

0x01

Sync/Async

Synchronous

Reentrancy Reentrant

Parameters (in)

None

Parameters (inout)

None

Parameters (out)

None

Return value

ISRType <Identifier of running ISR> or

INVALID_ISR

Description

This service returns the identifier of the currently executing ISR.

Available via

Os.h

c()

[SWS_Os_00263] dIf called from category 2 ISR (or Hook routines called inside a

category 2 ISR), GetISRID shall return the identifier of the currently executing ISR.c

()

[SWS_Os_00264] dIf its caller is not a category 2 ISR (or Hook routines called inside

a category 2 ISR), GetISRID shall return INVALID_ISR.c()

148 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

[SWS_Os_00515] dAvailability of GetISRID: Available in all Scalability Classes.c()

8.4.4 CallTrustedFunction

[SWS_Os_00097] d

Service Name

CallTrustedFunction

Syntax

StatusType CallTrustedFunction (

TrustedFunctionIndexType FunctionIndex,

TrustedFunctionParameterRefType FunctionParams

)

Service ID [hex]

0x02

Sync/Async

Synchronous

Reentrancy Reentrant

FunctionIndex

Index of the function to be called.

Parameters (in)

FunctionParams

Pointer to the parameters for the function - specified by the

FunctionIndex - to be called. If no parameters are provided, a

NULL pointer has to be passed.

Parameters (inout)

None

Parameters (out)

None

Return value

StatusType E_OK: No Error

E_OS_SERVICEID: No function defined for this index

Description

A (trusted or non-trusted) OS-Application uses this service to call a trusted function

Available via

Os.h

c()

[SWS_Os_00265] dIf <FunctionIndex> is a defined function index, CallTrusted-

Function shall call the function <FunctionIndex> out of a list of implementation spe-

cific trusted functions with the protection settings of the OS-Application which provides

the trusted function AND shall return E_OK after completion.c()

[SWS_Os_00312] dCaveats of CallTrustedFunction:

• The called trusted function must conform to the following C prototype: void

TRUSTED_<name_of_the_trusted_service>( TrustedFunctionIndex

Type,TrustedFunctionParameterRefType); (The arguments are the

same as the arguments of CallTrustedFunction).

• Normally, a user will not directly call this service, but it will be part of some stan-

dard interface, e.g. a standard I/O interface.

• It is the duty of the called trusted function to check rights of passed parameters,

especially if parameters are interpreted as out parameters.

• It should be noted that the CallTrustedFunction does not disable timing pro-

tection for the Task which called the service. This may lead to timing faults (calls

of the ProtectionHook) even inside of a trusted OS-Application. It is therefore

recommended to use CallTrustedFunction only for stateless functions (e.g.

functions which do not write or do not have internal states)

149 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

c()

[SWS_Os_00266] dWhen CallTrustedFunction calls the function <FunctionIn-

dex>, that function shall be executed with the same processor mode, memory protec-

tion boundaries and the service protection limitations of the OS-Application to which

it belongs. The notion of "current application" shall remain that of the calling Task or

Category 2 ISR.c()

Reaction to timing protection can be defined to terminate the OS-Application. If a Task

is inside CallTrustedFunction and Task rescheduling takes place within the same

OS-Application, the newly running higher priority Task may cause timing protection

and terminate the OS-Application, thus indirectly aborting the trusted function. To avoid

this, the scheduling of other Tasks which belong to the same OS-Application as the

caller needs to be restricted, as well as the availability of interrupts of the same OS-

Application.

[SWS_Os_00565] dWhen CallTrustedFunction is called and the caller of Call-

TrustedFunction is supervised with timing protection, the Operating System shall

delay any timing protection errors until the CallTrustedFunction returns to a

OsApplication with OsTrustedApplicationDelayTimingViolationCall ==

FALSE.c()

[SWS_Os_00564] dIf such a violation is detected inside a nested call sequence of

CallTrustedFunction of a Task, the delay shall last until the return of Call-

TrustedFunction to an OsApplication with OsTrustedApplicationDelay-

TimingViolationCall == FALSE.c()

[SWS_Os_00563] dThe OperatingSystem shall not schedule any other Tasks which

belong to the same OS-Application as the non-trusted caller of the service. It shall

be done by priority ceiling. Also interrupts of Category 2 which belong to the same

OS-Application shall be disabled during the execution of the service.c()

[SWS_Os_00364] dIf CallTrustedFunction calls the trusted function from a Cat-

egory 2 ISR context, that function shall continue to run on the same interrupt priority

and be allowed to call all system services defined for Category 2 ISR.c() See also table

in chapter 7.7.3.3.

[SWS_Os_00365] dIf CallTrustedFunction calls the trusted function from a Task

context, that function shall continue to run on the same priority and be allowed to call

all system services defined for Tasks.c() See also table in chapter 7.7.3.3.1.

[SWS_Os_00292] dIf the function index <FunctionIndex> in a call of CallTrusted-

Function is undefined, CallTrustedFunction shall return E_OS_SERVICEID.c

()

[SWS_Os_00516] dAvailability of CallTrustedFunction: Available in Scalability

Classes 3 and 4.c()

150 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

8.4.5 CheckISRMemoryAccess

[SWS_Os_00512] d

Service Name

CheckISRMemoryAccess

Syntax

AccessType CheckISRMemoryAccess (

ISRType ISRID,

MemoryStartAddressType Address,

MemorySizeType Size

)

Service ID [hex]

0x03

Sync/Async

Synchronous

Reentrancy Reentrant

ISRID ISR reference

Address

Start of memory area

Parameters (in)

Size Size of memory area

Parameters (inout)

None

Parameters (out)

None

Return value AccessType Value which contains the access rights to the memory area.

Description

This service checks if a memory region is write/read/execute accessible and also returns

information if the memory region is part of the stack space.

Available via

Os.h

c()

[SWS_Os_00267] dIf the ISR reference <ISRID> in a call of CheckISRMemoryAc-

cess is valid, CheckISRMemoryAccess shall return the access rights of the ISR on

the specified memory area.c()

[SWS_Os_00313] dIf an access right (e.g. "read") is not valid for the whole memory

area specified in a call of CheckISRMemoryAccess, CheckISRMemoryAccess shall

yield no access regarding this right.c()

[SWS_Os_00268] dIf the ISR reference <ISRID> is not valid, CheckISRMemoryAc-

cess shall yield no access rights.c()

[SWS_Os_00517] dAvailability of CheckISRMemoryAccess: Available in Scalability

Classes 3 and 4.c()

8.4.6 CheckTaskMemoryAccess

[SWS_Os_00513] d

Service Name

CheckTaskMemoryAccess

Syntax

AccessType CheckTaskMemoryAccess (

TaskType TaskID,

MemoryStartAddressType Address,

MemorySizeType Size

)

151 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Service ID [hex]

0x04

Sync/Async

Synchronous

Reentrancy Reentrant

TaskID

Task reference

Address

Start of memory area

Parameters (in)

Size Size of memory area

Parameters (inout)

None

Parameters (out)

None

Return value AccessType Value which contains the access rights to the memory area.

Description

This service checks if a memory region is write/read/execute accessible and also returns

information if the memory region is part of the stack space.

Available via

Os.h

c()

[SWS_Os_00269] dIf the Task reference <TaskID> in a call of CheckTaskMemo-

ryAccess is valid, CheckTaskMemoryAccess shall return the access rights of the

Task on the specified memory area.c()

[SWS_Os_00314] dIf an access right (e.g. "read") is not valid for the whole memory

area specified in a call of CheckTaskMemoryAccess, CheckTaskMemoryAccess

shall yield no access regarding this right.c()

[SWS_Os_00270] dIf the Task reference <TaskID> in a call of CheckTaskMemory-

Access is not valid, CheckTaskMemoryAccess shall yield no access rights.c()

[SWS_Os_00518] dAvailability of CheckTaskMemoryAccess: Available in Scalability

Classes 3 and 4c()

8.4.7 CheckObjectAccess

[SWS_Os_00256] d

Service Name

CheckObjectAccess

Syntax

ObjectAccessType CheckObjectAccess (

ApplicationType ApplID,

ObjectTypeType ObjectType,

void ...

)

Service ID [hex]

0x05

Sync/Async

Synchronous

Reentrancy Reentrant

ApplID

OS-Application identifier

ObjectType Type of the following parameter

Parameters (in)

... The object to be examined

Parameters (inout)

None

Parameters (out)

None

152 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Return value

ObjectAccessType ACCESS if the ApplID has access to the object

NO_ACCESS otherwise

Description

This service determines if the OS-Applications, given by ApplID, is allowed to use the IDs of a

Task, Resource, Counter, Alarm or Schedule Table in API calls.

Available via

Os.h

c()

[SWS_Os_00271] dIf the OS-Application <ApplID> in a call of CheckObjectAccess

has access to the queried object, CheckObjectAccess shall return ACCESS.c()

[SWS_Os_00272] dIf the OS-Application <ApplID> in a call of CheckObjectAccess

has no access to the queried object, CheckObjectAccess shall return NO_ACCESS.c

()

[SWS_Os_00423] dIf in a call of CheckObjectAccess the object to be examined is

not a valid object OR <ApplID> is invalid OR <ObjectType> is invalid THEN CheckOb-

jectAccess shall return NO_ACCESS.c()

[SWS_Os_00519] dAvailability of CheckObjectAccess: Available in Scalability

Classes 3 and 4.c()

8.4.8 CheckObjectOwnership

[SWS_Os_00017] d

Service Name

CheckObjectOwnership

Syntax

ApplicationType CheckObjectOwnership (

ObjectTypeType ObjectType,

void ...

)

Service ID [hex]

0x06

Sync/Async

Synchronous

Reentrancy Reentrant

ObjectType Type of the following parameter

Parameters (in)

... The object to be examined

Parameters (inout)

None

Parameters (out)

None

Return value ApplicationType

<OS-Application>: the OS-Application to which the object Object

Type belongs or

INVALID_OSAPPLICATION if the object does not exists

Description

This service determines to which OS-Application a given Task, ISR, Counter, Alarm or

Schedule Table belongs

Available via

Os.h

c()

[SWS_Os_00273] dIf the object <ObjectType> specified in a call of CheckObjec-

tOwnership exists, CheckObjectOwnership shall return the identifier of the OS-

Application to which the object belongs.c()

153 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

[SWS_Os_00274] dIf in a call of CheckObjectOwnership the specified object <Ob-

jectType> is invalid OR the argument of the type (the ". . . ") is invalid OR the object does

not belong to any OS-Application, CheckObjectOwnership shall return INVALID_

OSAPPLICATION.c()

[SWS_Os_00520] dAvailability of CheckObjectOwnership: Available in Scalability

Classes 3 and 4 and in multi-core systems.c()

8.4.9 StartScheduleTableRel

[SWS_Os_00347] d

Service Name

StartScheduleTableRel

Syntax

StatusType StartScheduleTableRel (

ScheduleTableType ScheduleTableID,

TickType Offset

)

Service ID [hex]

0x07

Sync/Async

Synchronous

Reentrancy Reentrant

ScheduleTableID Schedule table to be started

Parameters (in)

Offset Number of ticks on the counter before the the schedule table

processing is started

Parameters (inout)

None

Parameters (out)

None

Return value

StatusType E_OK: No Error

E_OS_ID (only in EXTENDED status): ScheduleTableID not

valid.

E_OS_VALUE (only in EXTENDED status): Offset is greater than

(OsCounterMaxAllowedValue - InitialOffset) or is equal to 0.

E_OS_STATE: Schedule table was already started.

Description

This service starts the processing of a schedule table at "Offset" relative to the "Now" value on

the underlying counter.

Available via

Os.h

c()

[SWS_Os_00275] dIf the ScheduleTable <ScheduleTableID> in a call of

StartScheduleTableRel is not valid, StartScheduleTableRel shall return

E_OS_ID.c()

[SWS_Os_00452] dIf the ScheduleTable <ScheduleTableID> in a call of

StartScheduleTableRel is implicitely synchronized (OsScheduleTblSync-

Strategy = IMPLICIT), StartScheduleTableRel shall return E_OS_ID.c()

[SWS_Os_00332] dIf <Offset> in a call of StartScheduleTableRel is zero

StartScheduleTableRel shall return E_OS_VALUE.c()

[SWS_Os_00276] dIf the offset <Offset>) is greater than OsCounterMaxAllowed-

Value of the underlying Counter minus the Initial Offset, StartScheduleTableRel

shall return E_OS_VALUE.c()

154 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

[SWS_Os_00277] dIf the ScheduleTable <ScheduleTableID> in a call of

StartScheduleTableRel is not in the state SCHEDULETABLE_STOPPED,

StartScheduleTableRel shall return E_OS_STATE.c()

[SWS_Os_00278] dIf the input parameters of StartScheduleTableRel are valid

and the state of ScheduleTable <ScheduleTableID> is SCHEDULETABLE_STOPPED,

then StartScheduleTableRel shall start the processing of a ScheduleTable

<ScheduleTableID>. The Initial Expiry Point shall be processed after <Offset> + Initial

Offset ticks have elapsed on the underlying Counter. The state of <ScheduleTable

ID> is set to SCHEDULETABLE_RUNNING before the service returns to the caller.c()

[SWS_Os_00521] dAvailability of StartScheduleTableRel: Available in all Scala-

bility Classes.c()

8.4.10 StartScheduleTableAbs

[SWS_Os_00358] d

Service Name

StartScheduleTableAbs

Syntax

StatusType StartScheduleTableAbs (

ScheduleTableType ScheduleTableID,

TickType Start

)

Service ID [hex]

0x08

Sync/Async

Synchronous

Reentrancy Reentrant

ScheduleTableID Schedule table to be started

Parameters (in)

Start

Absolute counter tick value at which the schedule table is started

Parameters (inout)

None

Parameters (out)

None

Return value

StatusType E_OK: No Error

E_OS_ID (only in EXTENDED status): ScheduleTableID not valid

E_OS_VALUE (only in EXTENDED status): "Start" is greater

than OsCounterMaxAllowedValue

E_OS_STATE: Schedule table was already started

Description

This service starts the processing of a schedule table at an absolute value "Start" on the

underlying counter.

Available via

Os.h

c()

[SWS_Os_00348] dIf the ScheduleTable <ScheduleTableID> in a call of

StartScheduleTableAbs is not valid, StartScheduleTableAbs shall return

E_OS_ID.c()

[SWS_Os_00349] dIf the <Start> in a call of StartScheduleTableAbs is greater

than the OsCounterMaxAllowedValue of the underlying Counter, StartSched-

uleTableAbs shall return E_OS_VALUE.c()

155 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

[SWS_Os_00350] dIf the ScheduleTable <ScheduleTableID> in a call of

StartScheduleTableAbs is not in the state SCHEDULETABLE_STOPPED,

StartScheduleTableAbs shall return E_OS_STATE.c()

[SWS_Os_00351] dIf the input parameters of StartScheduleTableAbs are valid

and <ScheduleTableID> is in the state SCHEDULETABLE_STOPPED, StartSched-

uleTableAbs shall start the processing of ScheduleTable <ScheduleTableID>

when the underlying Counter next equals <Start> and shall set the state of <Schedule

TableID> to

- SCHEDULETABLE_RUNNING (for a non-synchronized / Explicitly synchronized

ScheduleTable) OR

- SCHEDULETABLE_RUNNING_AND_SYNCHRONOUS (for implicitly synchronized

ScheduleTable)

before returning to the user. (The Initial Expir y Point will be processed when the un-

derlying Counter next equals <Start>+Initial Offset).c()

[SWS_Os_00522] dAvailability of StartScheduleTableAbs: Available in all Scala-

bility Classes.c()

8.4.11 StopScheduleTable

[SWS_Os_00006] d

Service Name

StopScheduleTable

Syntax

StatusType StopScheduleTable (

ScheduleTableType ScheduleTableID

)

Service ID [hex]

0x09

Sync/Async

Synchronous

Reentrancy Reentrant

Parameters (in)

ScheduleTableID Schedule table to be stopped

Parameters (inout)

None

Parameters (out)

None

Return value

StatusType E_OK: No Error

E_OS_ID (only in EXTENDED status): ScheduleTableID not

valid.

E_OS_NOFUNC: Schedule table was already stopped

Description

This service cancels the processing of a schedule table immediately at any point while the

schedule table is running.

Available via

Os.h

c()

[SWS_Os_00279] dIf the ScheduleTable identifier <ScheduleTableID> in a call of

StopScheduleTable is not valid, StopScheduleTable shall return E_OS_ID.c()

156 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

[SWS_Os_00280] dIf the ScheduleTable with identifier <ScheduleTableID> is in

state SCHEDULETABLE_STOPPED when calling StopScheduleTable, StopSched-

uleTable shall return E_OS_NOFUNC.c()

[SWS_Os_00281] dIf the input parameters of StopScheduleTable are valid,

StopScheduleTableshall set the state of <ScheduleTableID> to SCHED-

ULETABLE_STOPPED and (stop the ScheduleTable <ScheduleTableID> from pro-

cessing any further expiry points and) shall return E_OK.c()

[SWS_Os_00523] dAvailability of StopScheduleTable: Available in all Scalability

Classes.c()

8.4.12 NextScheduleTable

[SWS_Os_00191] d

Service Name

NextScheduleTable

Syntax

StatusType NextScheduleTable (

ScheduleTableType ScheduleTableID_From,

ScheduleTableType ScheduleTableID_To

)

Service ID [hex]

0x0a

Sync/Async

Synchronous

Reentrancy Reentrant

ScheduleTableID_From Currently processed schedule table

Parameters (in)

ScheduleTableID_To Schedule table that provides its series of expiry points

Parameters (inout)

None

Parameters (out)

None

Return value

StatusType E_OK: No error

E_OS_ID (only in EXTENDED status): ScheduleTableID_From or

ScheduleTableID_To

not valid

E_OS_NOFUNC: ScheduleTableID_From not started

E_OS_STATE: ScheduleTableID_To is started or next

Description

This service switches the processing from one schedule table to another schedule table.

Available via

Os.h

c(SRS_Os_00099)

[SWS_Os_00282] dIf the input parameter <ScheduleTableID_From> or <ScheduleTa-

bleID_To> in a call of NextScheduleTable is not valid, NextScheduleTable shall

return E_OS_ID.c()

[SWS_Os_00330] dIf in a call of NextScheduleTable ScheduleTable <Schedule

TableID_To> is driven by different Counter than ScheduleTable <ScheduleTable

ID_From> then NextScheduleTable shall return an error E_OS_ID.c()

[SWS_Os_00283] dIf the ScheduleTable <ScheduleTableID_From> in a call of

NextScheduleTable is in state SCHEDULETABLE_STOPPED OR in state SCHED-

ULETABLE_NEXT, NextScheduleTable shall leave the state of <ScheduleTable_

From> and <ScheduleTable_To> unchanged and return E_OS_NOFUNC.c()

157 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

[SWS_Os_00309] dIf the ScheduleTable <ScheduleTableID_To> in a call of

NextScheduleTable is not in state SCHEDULETABLE_STOPPED, NextSched-

uleTable shall leave the state of <ScheduleTable_From> and <ScheduleTable_To>

unchanged and return E_OS_STATE.c()

[SWS_Os_00484] dIf OsScheduleTblSyncStrategy of <ScheduleTableID_To> in

a call of NextScheduleTable is not equal to the OsScheduleTblSyncStrategy

of <ScheduleTableID_From> then NextScheduleTable shall return E_OS_ID.c()

[SWS_Os_00284] dIf the input parameters of NextScheduleTable are valid then

NextScheduleTable shall start the processing of ScheduleTable <ScheduleTa-

bleID_To> <ScheduleTableID_From>.FinalDelay ticks after the Final Expiry Point on

<ScheduleTableID_From> is processed and shall return E_OK. NextScheduleTable

shall process the Initial Expiry Point on <ScheduleTableID_To> at <ScheduleTableID_

From>.Final Delay + <ScheduleTable_To>.Initial Offset ticks after the Final Expiry Point

on <ScheduleTableID_From> is processed .c()

[SWS_Os_00324] dIf the input parameters of NextScheduleTable are valid AND the

<ScheduleTableID_From> already has a "next" ScheduleTable then NextSched-

uleTableshall replace the previous "next" ScheduleTable with <ScheduleTa-

bleID_To> and shall change the old "next" ScheduleTable state to SCHED-

ULETABLE_STOPPED.c()

[SWS_Os_00505] dIf OsScheduleTblSyncStrategy of the ScheduleTables

<ScheduleTableID_From> and <ScheduleTableID_To> in a call of NextSched-

uleTable is EXPLICIT and the Operating System module already synchronizes

<ScheduleTableID_From>, NextScheduleTable shall continue synchonization after

the start of processing <ScheduleTableID_To>.c()

[SWS_Os_00453] dIf the <ScheduleTableID_From> in a call of NextScheduleTable

is stopped, NextScheduleTable shall not start the "next" ScheduleTable and

change its state to SCHEDULETABLE_STOPPED.c()

[SWS_Os_00524] dAvailability of NextScheduleTable: Available in all Scalability

Classes.c()

8.4.13 StartScheduleTableSynchron

[SWS_Os_00201] d

Service Name

StartScheduleTableSynchron

Syntax

StatusType StartScheduleTableSynchron (

ScheduleTableType ScheduleTableID

)

Service ID [hex]

0x0b

Sync/Async

Synchronous

Reentrancy Reentrant

158 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Parameters (in)

ScheduleTableID Schedule table to be started

Parameters (inout)

None

Parameters (out)

None

Return value

StatusType E_OK: No Error

E_OS_ID (only in EXTENDED status): ScheduleTableID not valid

E_OS_STATE: Schedule table was already started

Description

This service starts an explicitly synchronized schedule table synchronously.

Available via

Os.h

c(SRS_Os_11002)

[SWS_Os_00387] dIf in a call of StartScheduleTableSynchron the Sched-

uleTable <ScheduleTableID> is not valid OR the ScheduleTable <ScheduleTable

ID> is not explicitly synchronized (OsScheduleTblSyncStrategy != EXPLICIT)

StartScheduleTableSynchron shall return E_OS_ID.c()

[SWS_Os_00388] dIf the ScheduleTable <ScheduleTableID> in a call of

StartScheduleTableSynchron is not in the state SCHEDULETABLE_STOPPED,

StartScheduleTableSynchron shall return E_OS_STATE.c()

[SWS_Os_00389] dIf <ScheduleTableID> in a call of StartScheduleTableSyn-

chron is valid, StartScheduleTableSynchron shall set the state of <Schedule

TableID> to SCHEDULETABLE_WAITING and start the processing of ScheduleTable

<ScheduleTableID> after the synchronization count of the ScheduleTable is set via

SyncScheduleTable. The Initial Expiry Point shall be processed when (Duration-

SyncValue)+InitialOffset ticks have elapsed on the synchronization Counter where:

• Duration is <ScheduleTableID>.OsScheduleTableDuration

• SyncValue is the <Value> parameter passed to the SyncScheduleTable

• InitialOffset is the shortest expiry point offset in <ScheduleTableID>

c()

[SWS_Os_00525] dAvailability of StartScheduleTableSynchron: Available in

Scalability Classes 2 and 4.c()

8.4.14 SyncScheduleTable

[SWS_Os_00199] d

Service Name

SyncScheduleTable

Syntax

StatusType SyncScheduleTable (

ScheduleTableType ScheduleTableID,

TickType Value

)

Service ID [hex]

0x0c

159 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Sync/Async

Synchronous

Reentrancy Reentrant

ScheduleTableID Schedule table to be synchronized

Parameters (in)

Value

The current value of the synchronization counter

Parameters (inout)

None

Parameters (out)

None

Return value

StatusType E_OK: No errors

E_OS_ID (only in EXTENDED status): The ScheduleTableID was

not valid or schedule

table can not be synchronized (OsScheduleTblSyncStrategy not

set or

OsScheduleTblSyncStrategy = IMPLICIT)

E_OS_VALUE (only in EXETENDED status): The <Value> is out

of range

E_OS_STATE: The state of schedule table <ScheduleTableID> is

equal to

SCHEDULETABLE_STOPPED

Description

This service provides the schedule table with a synchronization count and start synchronization.

Available via

Os.h

c(SRS_Os_11002)

[SWS_Os_00454] dIf the <ScheduleTableID> in a call of SyncScheduleTable is

not valid OR ScheduleTable can not be explicitely synchronized (OsScheduleT-

blSyncStrategy is not equal to EXPLICIT) SyncScheduleTable shall return

E_OS_ID.c()

[SWS_Os_00455] dIf the <Value> in a call of SyncScheduleTable is greater or

equal than the OsScheduleTableDuration, SyncScheduleTable shall return

E_OS_VALUE.c()

[SWS_Os_00456] dIf the state of the ScheduleTable <ScheduleTableID> in a

call of SyncScheduleTable is equal to SCHEDULETABLE_STOPPED or SCHED-

ULETABLE_NEXT SyncScheduleTable shall return E_OS_STATE.c()

[SWS_Os_00457] dIf the parameters in a call of SyncScheduleTable are valid,

SyncScheduleTable shall provide the Operating System module with the current

synchronization count for the given ScheduleTable. (It is used to synchronize the

processing of the ScheduleTable to the synchronization Counter.)c()

[SWS_Os_00526] dAvailability of SyncScheduleTable: Available in Scalability

Classes 2 and 4.c()

160 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

8.4.15 SetScheduleTableAsync

[SWS_Os_00422] d

Service Name

SetScheduleTableAsync

Syntax

StatusType SetScheduleTableAsync (

ScheduleTableType ScheduleTableID

)

Service ID [hex]

0x0d

Sync/Async

Synchronous

Reentrancy Reentrant

Parameters (in)

ScheduleTableID Schedule table for which status is requested

Parameters (inout)

None

Parameters (out)

None

Return value

StatusType E_OK: No Error

E_OS_ID (only in EXTENDED status): Invalid ScheduleTableID

Description

This service stops synchronization of a schedule table.

Available via

Os.h

c()

[SWS_Os_00362] dIf SetScheduleTableAsync is called for a running Sched-

uleTable, the Operating System module shall stop further synchronization until a

SyncScheduleTable call is made.c()

[SWS_Os_00323] dIf SetScheduleTableAsync is called for a running Sched-

uleTable the Operating System module shall continue to process expiry points on

the ScheduleTable.c()

[SWS_Os_00458] dIf OsScheduleTblSyncStrategy of <ScheduleTableID> in a

call of SetScheduleTableAsync is not equal to EXPLICIT OR if <ScheduleTable

ID> is invalid then SetScheduleTableAsync shall return E_OS_ID.c()

[SWS_Os_00483] dIf the current state of the <ScheduleTableID> in a call

of SetScheduleTableAsync equals to SCHEDULETABLE_STOPPED, SCHED-

ULETABLE_NEXT or SCHEDULETABLE_WAITING then SetScheduleTableAsync

shall return E_OS_STATE.c()

[SWS_Os_00300] dIf the current state of <ScheduleTableID> in a call of SetSched-

uleTableAsync equals SCHEDULETABLE_RUNNING_AND_SYNCHRONOUS (or

SCHEDULETABLE_RUNNING) then SetScheduleTableAsync shall set (or keep in

case of SCHEDULETABLE_RUNNING) the status of <ScheduleTableID> to SCHED-

ULETABLE_RUNNING.c()

[SWS_Os_00527] dAvailability of SetScheduleTableAsync: Available in Scalability

Classes 2 and 4.c()

161 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

8.4.16 GetScheduleTableStatus

[SWS_Os_00227] d

Service Name

GetScheduleTableStatus

Syntax

StatusType GetScheduleTableStatus (

ScheduleTableType ScheduleTableID,

ScheduleTableStatusRefType ScheduleStatus

)

Service ID [hex]

0x0e

Sync/Async

Synchronous

Reentrancy Reentrant

Parameters (in)

ScheduleTableID Schedule table for which status is requested

Parameters (inout)

None

Parameters (out)

ScheduleStatus Reference to ScheduleTableStatusType

Return value

StatusType E_OK: No Error

E_OS_ID (only in EXTENDED status): Invalid ScheduleTableID

Description

This service queries the state of a schedule table (also with respect to synchronization).

Available via

Os.h

c(SRS_Os_11002)

[SWS_Os_00289] dIf the ScheduleTable <ScheduleTableID> in a call of

GetScheduleTableStatus is NOT started, GetScheduleTableStatus shall

pass back SCHEDULETABLE_STOPPED via the reference parameter <ScheduleStatus>

AND shall return E_OK.c()

[SWS_Os_00353] dIf the ScheduleTable <ScheduleTableID> in a call of

GetScheduleTableStatus was used in a NextScheduleTable call AND waits

for the end of the current ScheduleTable, GetScheduleTableStatus shall return

SCHEDULETABLE_NEXT via the reference parameter <ScheduleStatus> AND shall re-

turn E_OK.c()

[SWS_Os_00354] dIf the ScheduleTable <ScheduleTableID> in a call of

GetScheduleTableStatus is configured with explicit synchronization AND <Sched-

uleTableID> was started with StartScheduleTableSynchronAND no synchroniza-

tion count was provided to the Operating System, GetScheduleTableStatus shall

return SCHEDULETABLE_WAITING via the reference parameter <ScheduleStatus>

AND shall return E_OK.c()

[SWS_Os_00290] dIf the ScheduleTable <ScheduleTableID> in a call of

GetScheduleTableStatus is started AND synchronous, GetScheduleTa-

bleStatus shall pass back SCHEDULETABLE_RUNNING_AND_SYNCHRONOUS via the

reference parameter <ScheduleStatus> AND shall return E_OK.c()

[SWS_Os_00291] dIf the ScheduleTable <ScheduleTableID> in a call of

GetScheduleTableStatus is started AND NOT synchronous (deviation is not

within the precision interval OR the ScheduleTable has been set asynchronous),

GetScheduleTableStatus shall pass back SCHEDULETABLE_RUNNING via the ref-

erence parameter ScheduleStatus AND shall return E_OK.c()

162 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

[SWS_Os_00293] dIf the identifier <ScheduleTableID> in a call of GetScheduleTa-

bleStatus is NOT valid, GetScheduleTableStatus shall return E_OS_ID.c()

[SWS_Os_00528] dAvailability of GetScheduleTableStatus: Available in all Scal-

ability Classes.c()

8.4.17 IncrementCounter

[SWS_Os_00399] d

Service Name

IncrementCounter

Syntax

StatusType IncrementCounter (

CounterType CounterID

)

Service ID [hex]

0x0f

Sync/Async

Synchronous

Reentrancy Reentrant

Parameters (in)

CounterID The Counter to be incremented

Parameters (inout)

None

Parameters (out)

None

Return value

StatusType E_OK: No errors

E_OS_ID (only in EXTENDED status): The CounterID was not

valid or counter is implemented in hardware and can not be

incremented by software

Description

This service increments a software counter.

Available via

Os.h

c()

[SWS_Os_00285] dIf the input parameter <CounterID> in a call of Increment-

Counter is not valid OR the Counter is a hardware Counter, IncrementCounter

shall return E_OS_ID.c()

[SWS_Os_00286] dIf the input parameter of IncrementCounter is valid, Incre-

mentCounter shall increment the Counter <CounterID> by one (if any alarm con-

nected to this Counter expires, the given action, e.g. Task activation, is done) and

shall return E_OK.c(SRS_Os_11020)

[SWS_Os_00321] dIf in a call of IncrementCounter an error happens during the

execution of an alarm action, e.g. E_OS_LIMIT caused by a Task activation, Incre-

mentCounter shall call the error hook(s), but the IncrementCounter service itself

shall return E_OK.c()

[SWS_Os_00529] dCaveats of IncrementCounter: If called from a Task,

rescheduling may take place.c()

[SWS_Os_00530] dAvailability of IncrementCounter: Available in all Scalability

Classes.c()

163 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

8.4.18 GetCounterValue

[SWS_Os_00383] d

Service Name

GetCounterValue

Syntax

StatusType GetCounterValue (

CounterType CounterID,

TickRefType Value

)

Service ID [hex]

0x10

Sync/Async

Synchronous

Reentrancy Reentrant

Parameters (in)

CounterID The Counter which tick value should be read

Parameters (inout)

None

Parameters (out)

Value

Contains the current tick value of the counter

Return value

StatusType E_OK: No errors

E_OS_ID (only in EXTENDED status): The <CounterID> was not

valid

Description

This service reads the current count value of a counter (returning either the hardware timer

ticks if counter is driven by hardware or the software ticks when user drives counter).

Available via

Os.h

c(SRS_Frt_00025)

[SWS_Os_00376] dIf the input parameter <CounterID> in a call of GetCounter-

Value is not valid, GetCounterValue shall return E_OS_ID.c()

[SWS_Os_00377] dIf the input parameter <CounterID> in a call of GetCounter-

Value is valid, GetCounterValue shall return the current tick value of the Counter

via <Value> and return E_OK.c(SRS_Frt_00033)

[SWS_Os_00531] dCaveats of GetCounterValue: Note that for counters of Os-

CounterType = HARDWARE the real timer value (the - possibly adjusted - hardware

value, see [SWS_Os_00384]) is returned, whereas for counters of OsCounterType =

SOFTWARE the current "software" tick value is returned.c()

[SWS_Os_00532] dAvailability of GetCounterValue: Available in all Scalability

Classes.c()

8.4.19 GetElapsedValue

[SWS_Os_00392] d

Service Name

GetElapsedValue

Syntax

StatusType GetElapsedValue (

CounterType CounterID,

TickRefType Value,

TickRefType ElapsedValue

)

Service ID [hex]

0x11

164 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Sync/Async

Synchronous

Reentrancy Reentrant

Parameters (in)

CounterID The Counter to be read

Parameters (inout)

Value

in: the previously read tick value of the counter out: the current

tick value of the counter

Parameters (out)

ElapsedValue

The difference to the previous read value

Return value

StatusType E_OK: No errors

E_OS_ID (only in EXTENDED status): The CounterID was not

valid

E_OS_VALUE (only in EXTENDED status): The given Value was

not valid

Description

This service gets the number of ticks between the current tick value and a previously read tick

value.

Available via

Os.h

c(SRS_Frt_00025)

[SWS_Os_00381] dIf the input parameter <CounterID> in a call of GetElapsed-

Value is not valid GetElapsedValue shall return E_OS_ID.c()

[SWS_Os_00391] dIf the <Value> in a call of GetElapsedValue is larger than

the max allowed value of the <CounterID>, GetElapsedValue shall return

E_OS_VALUE.c()

[SWS_Os_00382] dIf the input parameters in a call of GetElapsedValue are valid,

GetElapsedValue shall return the number of elapsed ticks since the given <Value>

value via <ElapsedValue> and shall return E_OK.c(SRS_Frt_00034)

[SWS_Os_00460] dGetElapsedValue shall return the current tick value of the

Counter in the <Value> parameter.c()

[SWS_Os_00533] dCaveats of GetElapsedValue:If the timer already passed the

<Value> value a second (or multiple) time, the result returned is wrong. The reason is

that the service can not detect such a relative overflow.c()

[SWS_Os_00534] dAvailability of GetElapsedValue: Available in all Scalability

Classes.c()

8.4.20 TerminateApplication

[SWS_Os_00258] d

Service Name

TerminateApplication

Syntax

StatusType TerminateApplication (

ApplicationType Application,

RestartType RestartOption

)

Service ID [hex]

0x12

Sync/Async

Synchronous

165 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Reentrancy Reentrant

Application

The identifier of the OS-Application to be terminated. If the caller

belongs to <Application> the call results in a self termination.

Parameters (in)

RestartOption Either RESTART for doing a restart of the OS-Application or NO_

RESTART if OS-Application shall not be restarted.

Parameters (inout)

None

Parameters (out)

None

Return value

StatusType E_OK: No errors

E_OS_ID: <Application> was not valid (only in EXTENDED

status)

E_OS_VALUE: <RestartOption> was neither RESTART nor NO_

RESTART (only in EXTENDED status)

E_OS_ACCESS: The caller does not have the right to terminate

<Application> (only in EXTENDED status)

E_OS_STATE: The state of <Application> does not allow

terminating <Application>

Description

This service terminates the OS-Application to which the calling Task/Category 2 ISR/application

specific error hook belongs.

Available via

Os.h

c(SRS_Os_11022, SRS_Os_11023)

[SWS_Os_00493] dIf the input parameter <Application> in a call of TerminateAp-

plication is not valid TerminateApplication shall return E_OS_ID.c()

[SWS_Os_00459] dIf the <RestartOption> in a call of TerminateApplication is

invalid, TerminateApplication shall return E_OS_VALUE.c()

[SWS_Os_00494] dIf the input parameter <Application> in a call of TerminateAp-

plication is valid AND the caller belongs to a non-trusted OS-Application AND

the caller does not belong to <Application> TerminateApplication shall return

E_OS_ACCESS.c()

[SWS_Os_00507] dIf the state of <Application> in a call of TerminateAp-

plication is APPLICATION_TERMINATED TerminateApplication shall return

E_OS_STATE.c()

[SWS_Os_00508] dIf the state of <Application> in a call of TerminateApplication

is APPLICATION_RESTARTING and the caller does not belong to the <Application>

then TerminateApplication shall return E_OS_STATE.c()

[SWS_Os_00548] dIf the state of <Application> in a call of TerminateApplication

is APPLICATION_RESTARTING AND the caller does belong to the <Application> AND

the <RestartOption> is equal RESTART then TerminateApplication shall retur n

E_OS_STATE.c()

[SWS_Os_00287] dIf the parameters in a call of TerminateApplication are valid

and the above criteria are met TerminateApplication shall terminate <Applica-

tion> (i.e. to kill all Tasks, disable the interrupt sources of those ISRs which belong

to the OS-Application and free all other OS resources associated with the application)

AND shall activate the configured OsRestartTask of <Application> if <RestartOp-

tion> equals RESTART. If no OsRestartTask is configured, no restart shall happen.

166 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

If the <Application> is restarted, its state is set to APPLICATION_RESTARTING oth-

erwise to APPLICATION_TERMINATED. If the caller belongs to <Application> Termi-

nateApplication shall not return, otherwise it shall return E_OK.c(SRS_Os_11023)

[SWS_Os_00535] dCaveats of TerminateApplication:

• If no applications are configured the implementation shall make sure that this

service is not available.

• Tasks and interrupts that are owned by a trusted application can terminate any

OS-Application. Tasks and interrupts that are owned by a non-trusted application

can only terminate their owning OS-Application.

c()

Note: Although trusted OS-Application can be forcibly terminated by Tasks/Interrupts

of other trusted OS-Applications it is not recommended. This may have further impacts,

e.g. to users who are currently part of such an OS-Application via a CallTrusted-

Function call.

[SWS_Os_00536] dAvailability of TerminateApplication: Available in Scalability

Classes 3 and 4.c()

8.4.21 AllowAccess

[SWS_Os_00501] d

Service Name

AllowAccess

Syntax

StatusType AllowAccess (

void

)

Service ID [hex]

0x13

Sync/Async

Synchronous

Reentrancy Reentrant

Parameters (in)

None

Parameters (inout)

None

Parameters (out)

None

Return value

StatusType E_OK: No errors

E_OS_STATE:The OS-Application of the caller is in the wrong

state

Description

This service sets the own state of an OS-Application from APPLICATION_RESTARTING to

APPLICATION_ACCESSIBLE.

Available via

Os.h

c()

[SWS_Os_00497] dIf the state of the OS-Application of the caller of AllowAccess is

not APPLICATION_RESTARTING AllowAccess shall return E_OS_STATE.c()

167 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

[SWS_Os_00498] dIf the state of the OS-Application of the caller of AllowAc-

cess is APPLICATION_RESTARTING, AllowAccess shall set the state to APPLICA-

TION_ACCESSIBLE and allow other OS-Applications to access the configured objects

of the callers OS-Application.c()

[SWS_Os_00547] dAvailability of AllowAccess: Available in Scalability Classes 3

and 4.c()

8.4.22 GetApplicationState

[SWS_Os_00499] d

Service Name

GetApplicationState

Syntax

StatusType GetApplicationState (

ApplicationType Application,

ApplicationStateRefType Value

)

Service ID [hex]

0x14

Sync/Async

Synchronous

Reentrancy Reentrant

Parameters (in)

Application

The OS-Application from which the state is requested

Parameters (inout)

None

Parameters (out)

Value

The current state of the application

Return value

StatusType E_OK: No errors

E_OS_ID: <Application> is not valid (only in EXTENDED status)

Description

This service returns the current state of an OS-Application.

Available via

Os.h

c()

[SWS_Os_00495] dIf the <Application> in a call of GetApplicationState is not

valid GetApplicationState shall return E_OS_ID.c()

[SWS_Os_00496] dIf the parameters in a call of GetApplicationState are valid,

GetApplicationState shall return the state of OS-Application <Application> in

<Value>.c()

[SWS_Os_00537] dAvailability of GetApplicationState: Available in Scalability

Classes 3 and 4.c()

168 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

8.4.23 GetNumberOfActivatedCores

[SWS_Os_00672] d

Service Name

GetNumberOfActivatedCores

Syntax

uint32 GetNumberOfActivatedCores (

void

)

Service ID [hex]

0x15

Sync/Async

Synchronous

Reentrancy Reentrant

Parameters (in)

None

Parameters (inout)

None

Parameters (out)

None

Return value uint32

Number of cores running the AUTOSAR OS (see below)

Description

The function returns the number of cores running the AUTOSAR OS. This function might be a

macro.

Available via

Os.h

c(SRS_Os_80001) The function GetNumberOfActivatedCores shall be callable

from within a Task and an Category 2 ISR. Otherwise the behavior is unspecified.

[SWS_Os_00673] dThe return value of GetNumberOfActivatedCores shall be less

or equal to the configured value of OsNumberOfCores.c(SRS_Os_80001)

8.4.24 GetCoreID

[SWS_Os_00674] d

Service Name

GetCoreID

Syntax

CoreIdType GetCoreID (

void

)

Service ID [hex]

0x16

Sync/Async

Synchronous

Reentrancy Reentrant

Parameters (in)

None

Parameters (inout)

None

Parameters (out)

None

Return value

CoreIdType The return value is the unique ID of the core.

Description

The function returns a unique core identifier.

Available via

Os.h

c(SRS_Os_80001)

[SWS_Os_00675] dThe function GetCoreID shall return the unique logical CoreID of

the core on which the function is called. The mapping of physical cores to logical Core

IDs is implementation specific.c(SRS_Os_80001)

169 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

8.4.25 StartCore

[SWS_Os_00676] d

Service Name

StartCore

Syntax

void StartCore (

CoreIdType CoreID,

StatusType

Status

)

Service ID [hex]

0x17

Sync/Async

Synchronous

Reentrancy Non Reentrant

Parameters (in)

CoreID Core identifier

Parameters (inout)

None

Parameters (out)

Status Return value of the function in extended status: E_OK: No Error

E_OS_ID: Core ID is invalid. E_OS_ACCESS: The function was

called after starting the OS. E_OS_STATE: The Core is already

activated.

Return value of the function in standard status E_OK: No Error

Return value None

Description

It is not supported to call this function after StartOS(). The function starts the core specified by

the parameter CoreID. The OUT parameter allows the caller to check whether the operation

was successful or not. If a core is started by means of this function StartOS shall be called on

the core.

Available via

Os.h

c(SRS_Os_80006)

[SWS_Os_00677] dThe function StartCore shall start one core that shall run under

the control of the AUTOSAR OS.c(SRS_Os_80006)

[SWS_Os_00678] dCalls to the StartCore function after StartOS shall return with

E_OS_ACCESS and the core shall not be started.c(SRS_Os_80006)

[SWS_Os_00679] dIf the parameter CoreIDs refers to a core that was already started

by the function StartCore the related core is ignored and E_OS_STATE shall be

returned.c(SRS_Os_80006)

[SWS_Os_00681] dThere is no call to the ErrorHook if an error occurs during

StartCore.c(SRS_Os_80006)

8.4.26 GetSpinlock

[SWS_Os_00686] d

Service Name

GetSpinlock

Syntax

StatusType GetSpinlock (

SpinlockIdType SpinlockId

)

Service ID [hex]

0x19

170 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Sync/Async

Synchronous

Reentrancy Reentrant

Parameters (in)

SpinlockId The value refers to the spinlock instance that shall be locked.

Parameters (inout)

None

Parameters (out)

None

Return value

StatusType E_OK - In standard and extended status : No Error

E_OS_ID - In extended status: The SpinlockId is invalid

E_OS_INTERFERENCE_DEADLOCK - In extended status: A

TASK tries to occupy the spinlock while the lock is already

occupied by a TASK on the same core. This would cause a

deadlock.

E_OS_NESTING_DEADLOCK - In extended status: A TASK tries

to occupy the spinlock while a TASK on the same core is holding

a different spinlock in a way that may cause a deadlock.

E_OS_ACCESS - In extended status: The spinlock cannot be

accessed.

Description

GetSpinlock tries to occupy a spin-lock variable. If the function returns, either the lock is

successfully taken or an error has occurred. The spinlock mechanism is an active polling

mechanism. The function does not cause a de-scheduling.

Available via

Os.h

c(SRS_Os_80021)

[SWS_Os_00687] dThe function GetSpinlock shall occupy a spinlock. If the spinlock

is already occupied the function shall busy wait until the spinlock becomes available.c

(SRS_Os_80021)

[SWS_Os_00688] dThe function GetSpinlock shall return E_OK if no error was de-

tected. The spinlock is now occupied by the calling Task/Category 2 ISR on the calling

core.c(SRS_Os_80021)

[SWS_Os_00689] dThe function GetSpinlock shall return E_OS_ID if the parameter

SpinlockID refers to a spinlock that does not exist.c(SRS_Os_80021)

[SWS_Os_00690] dThe function GetSpinlock shall return

E_OS_INTERFERENCE_DEADLOCK if the spinlock referred by the parameter Spinlock

ID is already occupied by a Task/Category 2 ISR on the same core.c(SRS_Os_80021)

[SWS_Os_00691] dThe function GetSpinlock shall return

E_OS_NESTING_DEADLOCK if the sequence by which multiple spinlocks are oc-

cupied at the same time on one core do not comply with the configured order.c

(SRS_Os_80021)

[SWS_Os_00692] dThe function GetSpinlock shall return E_OS_ACCESS if the ac-

cessing OS-Application was not listed in the configuration (OsSpinlock).c(SRS_Os_-

80021)

[SWS_Os_00693] dIt shall be allowed to call the function GetSpinlock while inter-

rupts are disabled.c(SRS_Os_80021)

[SWS_Os_00694] dIt shall be allowed to call the function GetSpinlock while a Re-

source is occupied.c(SRS_Os_80021)

171 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

8.4.27 ReleaseSpinlock

[SWS_Os_00695] d

Service Name

ReleaseSpinlock

Syntax

StatusType ReleaseSpinlock (

SpinlockIdType SpinlockId

)

Service ID [hex]

0x1a

Sync/Async

Synchronous

Reentrancy Reentrant

Parameters (in)

SpinlockId The value refers to the spinlock instance that shall be locked.

Parameters (inout)

None

Parameters (out)

None

Return value

StatusType E_OK - In standard and extended status: No Error

E_OS_ID - In extended status: The SpinlockId is invalid.

E_OS_STATE - In extended status: The Spinlock is not occupied

by the TASK

E_OS_ACCESS - In extended status: The Spinlock cannot be

accessed.

E_OS_NOFUNC - In extended status: Attempt to release a

spinlock while another spinlock (or resource) has to be released

before.

Description

ReleaseSpinlock releases a spinlock variable that was occupied before. Before terminating a

TASK all spinlock variables that have been occupied with GetSpinlock() shall be released.

Before calling WaitEVENT all Spinlocks shall be released.

Available via

Os.h

c(SRS_Os_80021)

[SWS_Os_00696] dThe function ReleaseSpinlock shall release a spinlock that has

been occupied by the same (calling) Task. If the related GetSpinlock call used

configured locks (OsSpinlockLockMethod) the function shall also perform the undo

of the used lock.c(SRS_Os_80021)

[SWS_Os_00697] dThe function ReleaseSpinlock shall return E_OK if no error was

detected. The spinlock is now free and can be occupied by the same or other Tasks.c

(SRS_Os_80021)

[SWS_Os_00698] dThe function ReleaseSpinlock shall return E_OS_ID if the pa-

rameter SpinlockID refers to a spinlock that does not exist.c(SRS_Os_80021)

[SWS_Os_00699] dThe function ReleaseSpinlock shall return E_OS_STATE if the

parameter SpinlockID refers to a spinlock that is not occupied by the calling Task.c

(SRS_Os_80021)

[SWS_Os_00700] dThe function ReleaseSpinlock shall return E_OS_ACCESS if the

Task has no access to the spinlock referred by the parameter SpinlockIDc(SRS_Os_-

80021)

[SWS_Os_00701] dThe function ReleaseSpinlock shall return E_OS_NOFUNC if the

Task tries to release a spinlock while another spinlock (or Resource) has to be re-

leased before. No functionality shall be performed.c(SRS_Os_80021)

172 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

8.4.28 TryToGetSpinlock

[SWS_Os_00703] d

Service Name

TryToGetSpinlock

Syntax

StatusType TryToGetSpinlock (

SpinlockIdType SpinlockId,

TryToGetSpinlockType

Success

)

Service ID [hex]

0x1b

Sync/Async

Synchronous

Reentrancy Reentrant

Parameters (in)

SpinlockId The value refers to the spinlock instance that shall be locked.

Parameters (inout)

None

Parameters (out)

Success Returns if the lock has been occupied or not

Return value

StatusType E_OK - In standard and extended status: No Error

E_OS_ID - In extended status: The SpinlockId is invalid.

E_OS_INTERFERENCE_DEADLOCK - In extended status: A

TASK tries to occupy the spinlock while the lock is already

occupied by a TASK on the same core. This would cause a

deadlock.

E_OS_NESTING_DEADLOCK - In extended status: A TASK tries

to occupy a spinlock while holding a different spinlock in a way

that may cause a deadlock.

E_OS_ACCESS - In extended status: The spinlock cannot be

accessed.

Description

TryToGetSpinlock has the same functionality as GetSpinlock with the difference that if the

spinlock is already occupied by a TASK on a different core the function sets the OUT parameter

"Success" and returns with E_OK.

Available via

Os.h

c(SRS_Os_80021)

[SWS_Os_00704] dThe function TryToGetSpinlock shall atomically test the avail-

ability of the spinlock and if available occupy it. The result of success is returned.c

(SRS_Os_80021)

[SWS_Os_00705] dThe function TryToGetSpinlock shall set the OUT parameter

"Success" to TRYTOGETSPINLOCK_SUCCESS if the spinlock was successfully occu-

pied, and TRYTOGETSPINLOCK_NOSUCCESS if not. In both cases E_OK shall be re-

turned.c(SRS_Os_80021)

[SWS_Os_00706] dIf the function TryToGetSpinlock does not retur n E_OK, the

OUT parameter "Success" shall be undefined.c(SRS_Os_80021)

[SWS_Os_00707] dThe function TryToGetSpinlock shall return E_OS_ID if the pa-

rameter SpinlockID refers to a spinlock that does not exist.c(SRS_Os_80021)

[SWS_Os_00708] dThe function TryToGetSpinlock shall return

E_OS_INTERFERENCE_DEADLOCK if the spinlock referred by the parameter Spinlock

ID is already occupied by a Task on the same core.c(SRS_Os_80021)

[SWS_Os_00709] dThe function TryToGetSpinlock shall return

E_OS_NESTING_DEADLOCK if a Task tries to occupy a spinlock while holding a

different spinlock in a way that may cause a deadlock.c(SRS_Os_80021)

173 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

[SWS_Os_00710] dThe function TryToGetSpinlock shall return E_OS_ACCESS if

the Task has no access to the spinlock referred by the parameter SpinlockIDc(SRS_-

Os_80021)

[SWS_Os_00711] dIt shall be allowed to call the function TryToGetSpinlock while

interrupts are disabled.c(SRS_Os_80021)

[SWS_Os_00712] dIt shall be allowed to call the function TryToGetSpinlock while

a Resource is occupied.c(SRS_Os_80021)

8.4.29 ShutdownAllCores

[SWS_Os_00713] d

Service Name

ShutdownAllCores

Syntax

void ShutdownAllCores (

StatusType Error

)

Service ID [hex]

0x1c

Sync/Async

Synchronous

Reentrancy Reentrant

Parameters (in)

Error <Error> needs to be a valid error code supported by the

AUTOSAR OS.

Parameters (inout)

None

Parameters (out)

None

Return value None

Description

After this service the OS on all AUTOSAR cores is shut down. Allowed at TASK level and ISR

level and also internally by the OS. The function will never return. The function will force other

cores into a shutdown.

Available via

Os.h

c(SRS_Os_80007, SRS_BSW_00336)

[SWS_Os_00714] dA synchronized shutdown shall be triggered by the API function

ShutdownAllCores.c(SRS_Os_80007)

[SWS_Os_00715] dShutdownAllCores shall not return.c(SRS_Os_80007)

[SWS_Os_00716] dIf ShutdownAllCores is called from non trusted code the call

shall be ignored.c(SRS_Os_80007)

174 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

8.4.30 ControlIdle

[SWS_Os_00769] d

Service Name

ControlIdle

Syntax

StatusType ControlIdle (

CoreIdType CoreID,

IdleModeType IdleMode

)

Service ID [hex]

0x1d

Sync/Async

Synchronous

Reentrancy Non Reentrant

CoreID

selects the core which idle mode is set

Parameters (in)

IdleMode

the mode which shall be performed during idle time

Parameters (inout)

None

Parameters (out)

None

Return value

StatusType E_OK: No Error

E_OS_ID (only EXTENDED status): Invalid core and/or invalid

idleMode

Description

This API allows the caller to select the idle mode action which is performed during idle time of

the OS (e.g. if no Task/ISR is active). It can be used to implement energy savings. The real idle

modes are hardware dependent and not standardized. The default idle mode on each core is

IDLE_NO_HALT.

Available via

Os.h

c(SRS_Os_80022)

[SWS_Os_00770] dThe function ControlIdle shall return E_OK if no error was de-

tected and the parameters are validc(SRS_Os_80023)

[SWS_Os_00771] dThe function ControlIdle shall return E_OS_ID if the parameter

CoreID or IdleMode is invalid (e.g. refered core does not exist; idle mode is not known).

In single core systems the check of CoreID shall be omitted.c(SRS_Os_80023)

[SWS_Os_00802] dIf the core (given by CoreID) is already in another idle mode (dif-

ferent to the given IdleMode) the new IdleMode shall become effective the next time

that core enters the idle mode.c(SRS_Os_80023)

8.4.31 ReadPeripheral8, ReadPeripheral16, ReadPeripheral32

[SWS_Os_91013] d

Service Name

ReadPeripheral8

Syntax

StatusType ReadPeripheral8 (

AreaIdType Area,

const uint8

Address,

uint8

ReadValue

)

Service ID [hex]

0x28

Sync/Async

Synchronous

175 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Reentrancy Reentrant

Area

hardware peripheral area reference

Parameters (in)

Address memory address

Parameters (inout)

None

Parameters (out)

ReadValue

content of the given memory location (<Address>)

Return value

StatusType E_OK No error

E_OS_ID Area id is out of range (EXTENDED status)

E_OS_VALUE Address does not belong to given Area

(EXTENDED status)

E_OS_CALLEVEL Wrong call context of the API function

(EXTENDED status)

E_OS_ACCESS The calling task or ISR is not allowed to access

the given

Description

This service returns the content of a given memory location (<Address>).

Available via

Os.h

c(SRS_Os_11005)

[SWS_Os_91015] d

Service Name

ReadPeripheral16

Syntax

StatusType ReadPeripheral16 (

AreaIdType Area,

const uint16

Address,

uint16

ReadValue

)

Service ID [hex]

0x29

Sync/Async

Synchronous

Reentrancy Reentrant

Area

hardware peripheral area reference

Parameters (in)

Address memory address

Parameters (inout)

None

Parameters (out)

ReadValue

content of the given memory location (<Address>)

Return value

StatusType E_OK No error

E_OS_ID Area id is out of range (EXTENDED status)

E_OS_VALUE Address does not belong to given Area

(EXTENDED status)

E_OS_CALLEVEL Wrong call context of the API function

(EXTENDED status)

E_OS_ACCESS The calling task or ISR is not allowed to access

the given

Description

This service returns the content of a given memory location (<Address>).

Available via

Os.h

c(SRS_Os_11005)

176 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

[SWS_Os_91014] d

Service Name

ReadPeripheral32

Syntax

StatusType ReadPeripheral32 (

AreaIdType Area,

const uint32

Address,

uint32

ReadValue

)

Service ID [hex]

0x2a

Sync/Async

Synchronous

Reentrancy Reentrant

Area

hardware peripheral area reference

Parameters (in)

Address memory address

Parameters (inout)

None

Parameters (out)

ReadValue

content of the given memory location (<Address>)

Return value

StatusType E_OK No error

E_OS_ID Area id is out of range (EXTENDED status)

E_OS_VALUE Address does not belong to given Area

(EXTENDED status)

E_OS_CALLEVEL Wrong call context of the API function

(EXTENDED status)

E_OS_ACCESS The calling task or ISR is not allowed to access

the given

Description

This service returns the content of a given memory location (<Address>).

Available via

Os.h

c(SRS_Os_11005)

8.4.32 WritePeripheral8, WritePeripheral16, WritePeripheral32

[SWS_Os_91010] d

Service Name

WritePeripheral8

Syntax

StatusType WritePeripheral8 (

AreaIdType Area,

uint8

Address,

uint8 WriteValue

)

Service ID [hex]

0x2b

Sync/Async

Synchronous

Reentrancy Reentrant

Area

hardware peripheral area reference

Parameters (in)

Address memory address

Parameters (inout)

None

Parameters (out)

WriteValue value to be written at the memory address

177 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Return value

StatusType E_OK No error

E_OS_ID Area id is out of range (EXTENDED status)

E_OS_VALUE Address does not belong to given Area

(EXTENDED status)

E_OS_CALLEVEL Wrong call context of the API function

(EXTENDED status)

E_OS_ACCESS The calling task or ISR is not allowed to access

the given

Description

This service writes the <value> to a given memory location (<memory address>).

Available via

Os.h

c(SRS_Os_11005)

[SWS_Os_91012] d

Service Name

WritePeripheral16

Syntax

StatusType WritePeripheral16 (

AreaIdType Area,

uint16

Address,

uint16 WriteValue

)

Service ID [hex]

0x2c

Sync/Async

Synchronous

Reentrancy Reentrant

Area

hardware peripheral area reference

Parameters (in)

Address memory address

Parameters (inout)

None

Parameters (out)

WriteValue value to be written at the memory address

Return value

StatusType E_OK No error

E_OS_ID Area id is out of range (EXTENDED status)

E_OS_VALUE Address does not belong to given Area

(EXTENDED status)

E_OS_CALLEVEL Wrong call context of the API function

(EXTENDED status)

E_OS_ACCESS The calling task or ISR is not allowed to access

the given

Description

This service writes the <value> to a given memory location (<memory address>).

Available via

Os.h

c(SRS_Os_11005)

[SWS_Os_91011] d

Service Name

WritePeripheral32

Syntax

StatusType WritePeripheral32 (

AreaIdType Area,

uint32

Address,

uint32 WriteValue

)

Service ID [hex]

0x2d

Sync/Async

Synchronous

Reentrancy Reentrant

Parameters (in)

Area

hardware peripheral area reference

178 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Address memory address

Parameters (inout)

None

Parameters (out)

WriteValue

content of the given memory location (<Address>)

Return value

StatusType E_OK No error

E_OS_ID Area id is out of range (EXTENDED status)

E_OS_VALUE Address does not belong to given Area

(EXTENDED status)

E_OS_CALLEVEL Wrong call context of the API function

(EXTENDED status)

E_OS_ACCESS The calling task or ISR is not allowed to access

the given

Description

This service writes the <value> to a given memory location (<memory address>).

Available via

Os.h

c(SRS_Os_11005)

8.4.33 ModifyPeripheral8, ModifyPeripheral16, ModifyPeripheral32

[SWS_Os_91016] d

Service Name

ModifyPeripheral8

Syntax

StatusType ModifyPeripheral8 (

AreaIdType Area,

uint8

Address,

uint8 Clearmask,

uint8 Setmask

)

Service ID [hex]

0x2e

Sync/Async

Synchronous

Reentrancy Reentrant

Area

hardware peripheral area reference

Address memory address

Clearmask memory address will be modified by an bit-AND

Parameters (in)

Setmask memory address will be modified by an bit-OR

Parameters (inout)

None

Parameters (out)

None

Return value

StatusType E_OK No error

E_OS_ID Area id is out of range (EXTENDED status)

E_OS_VALUE Address does not belong to given Area

(EXTENDED status)

E_OS_CALLEVEL Wrong call context of the API function

(EXTENDED status)

E_OS_ACCESS The calling task or ISR is not allowed to access

the given

Description

This service modifies a given memory location (<memory address>) with the formula:

*<Address> = ((*<Address> & <clearmask>) | <setmask>)

Available via

Os.h

c(SRS_Os_11005)

179 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

[SWS_Os_91018] d

Service Name

ModifyPeripheral16

Syntax

StatusType ModifyPeripheral16 (

AreaIdType Area,

uint16

Address,

uint16 Clearmask,

uint16 Setmask

)

Service ID [hex]

0x35

Sync/Async

Synchronous

Reentrancy Reentrant

Area

hardware peripheral area reference

Address memory address

Clearmask memory address will be modified by an bit-AND

Parameters (in)

Setmask memory address will be modified by an bit-OR

Parameters (inout)

None

Parameters (out)

None

Return value

StatusType E_OK No error

E_OS_ID Area id is out of range (EXTENDED status)

E_OS_VALUE Address does not belong to given Area

(EXTENDED status)

E_OS_CALLEVEL Wrong call context of the API function

(EXTENDED status)

E_OS_ACCESS The calling task or ISR is not allowed to access

the given

Description

This service modifies a given memory location (<memory address>) with the formula:

*<Address> = ((*<Address> & <clearmask>) | <setmask>)

Available via

Os.h

c(SRS_Os_11005)

[SWS_Os_91017] d

Service Name

ModifyPeripheral32

Syntax

StatusType ModifyPeripheral32 (

AreaIdType Area,

uint32

Address,

uint32 Clearmask,

uint32 Setmask

)

Service ID [hex]

0x2f

Sync/Async

Synchronous

Reentrancy Reentrant

Area

hardware peripheral area reference

Address memory address

Clearmask memory address will be modified by an bit-AND

Parameters (in)

Setmask memory address will be modified by an bit-OR

Parameters (inout)

None

Parameters (out)

None

180 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Return value

StatusType E_OK No error

E_OS_ID Area id is out of range (EXTENDED status)

E_OS_VALUE Address does not belong to given Area

(EXTENDED status)

E_OS_CALLEVEL Wrong call context of the API function

(EXTENDED status)

E_OS_ACCESS The calling task or ISR is not allowed to access

the given

Description

This service modifies a given memory location (<memory address>) with the formula:

*<Address> = ((*<Address> & <clearmask>) | <setmask>)

Available via

Os.h

c(SRS_Os_11005)

8.4.34 EnableInterruptSource

[SWS_Os_91020] d

Service Name

EnableInterruptSource

Syntax

StatusType EnableInterruptSource (

ISRType ISRID,

boolean ClearPending

)

Service ID [hex]

0x31

Sync/Async

Synchronous

Reentrancy Reentrant

ISRID The ID of a category 2 ISR.

Parameters (in)

ClearPending Defines whether the pending flag shall be cleared (TRUE) or not

(FALSE).

Parameters (inout)

None

Parameters (out)

None

Return value

StatusType E_OK No error.

E_OS_ID ISRID is not a valid category 2 ISR identifier

(EXTENDED status)

E_OS_CALLEVEL Wrong call context of the API function

(EXTENDED status)

E_OS_ACCESS The calling application is not the owner of the

ISR passed in ISRID (Service Protection)

Description

Enables the interrupt source by modifying the interrupt controller registers. Additionally it may

clear the interrupt pending flag

Available via

Os.h

c(SRS_Os_11011)

181 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

8.4.35 DisableInterruptSource

[SWS_Os_91019] d

Service Name

DisableInterruptSource

Syntax

StatusType DisableInterruptSource (

ISRType ISRID

)

Service ID [hex]

0x30

Sync/Async

Synchronous

Reentrancy Reentrant

Parameters (in)

ISRID The ID of a category 2 ISR.

Parameters (inout)

None

Parameters (out)

None

Return value

StatusType E_OK No error.

E_OS_ID ISRID is not a valid category 2 ISR identifier

(EXTENDED status)

E_OS_CALLEVEL Wrong call context of the API function

(EXTENDED status)

E_OS_ACCESS The calling application is not the owner of the

ISR passed in ISRID (Service Protection)

Description

Disables the interrupt source by modifying the interrupt controller registers.

Available via

Os.h

c(SRS_Os_11011)

8.4.36 ClearPendingInterrupt

[SWS_Os_91021] d

Service Name

ClearPendingInterrupt

Syntax

StatusType ClearPendingInterrupt (

ISRType ISRID

)

Service ID [hex]

0x32

Sync/Async

Synchronous

Reentrancy Reentrant

Parameters (in)

ISRID The ID of a category 2 ISR.

Parameters (inout)

None

Parameters (out)

None

Return value

StatusType E_OK No error.

E_OS_ID ISRID is not a valid category 2 ISR identifier

(EXTENDED status)

E_OS_CALLEVEL Wrong call context of the API function

(EXTENDED status)

E_OS_ACCESS The calling application is not the owner of the

ISR passed in ISRID (Service Protection)

Description

Clears the interrupt pending flag by modifying the interrupt controller registers.

Available via

Os.h

c(SRS_Os_11011)

182 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

8.4.37 ActivateTaskAsyn

[SWS_Os_91022] d

Service Name

ActivateTaskAsyn

Syntax

void ActivateTaskAsyn (

TaskType id

)

Service ID [hex]

0x33

Sync/Async

Asynchronous

Reentrancy Reentrant

Parameters (in)

The id of the task to be activated

Parameters (inout)

None

Parameters (out)

None

Return value None

Description

Asynchronous version of the ActivateTask() function. Intended to be used for cross core task

activation. Possible errors are not returned to the caller, but may be reported via error hooks.

Available via

Os.h

c(SRS_Os_80015)

[SWS_Os_00818] dAvailability of ActivateTaskAsyn: Available in systems which

support OS-Applications.c(SRS_Os_80015)

Note: If during the Task activation an error occurs, and the caller is already gone (e.g.

callers OS-Application is already ter minated, OR callers core is shutting down OR ...)

calls to error hooks are dropped and no reporting is done.

8.4.38 SetEventAsyn

[SWS_Os_91023] d

Service Name

SetEventAsyn

Syntax

void SetEventAsyn (

TaskType id,

EventMaskType m

)

Service ID [hex]

0x34

Sync/Async

Asynchronous

Reentrancy Reentrant

The id of the task to be activated

Parameters (in)

Mask of the events to be set

Parameters (inout)

None

Parameters (out)

None

Return value None

Description

Asynchronous version of the SetEvent() function. Intended to be used for cross core event

setting. Possible errors are not returned to the caller, but may be reported via error hooks.

Available via

Os.h

c(SRS_Os_80015)

183 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

[SWS_Os_00819] dAvailability of SetEventAsyn: Available in systems which support

OS-Applications.c(SRS_Os_80015)

Note: If during the event setting an error occurs and the caller is already gone (e.g.

callers OS-Application is already ter minated, OR callers core is shutting down OR ...)

calls to error hooks are dropped and no reporting is done.

8.5 IOC

8.5.1 Imported types

In this chapter all types included from the following modules are listed:

[SWS_Os_91029] d

Module

Header File

Imported Type

Std Std_Types.h Std_ReturnType

c()

[SWS_Os_00827] dIf an ImplementationDataType is defined with the typeEmitter

empty or set to RTE and is used for IOC communication, the IOC shall include Rte_

Type.hc(SRS_Os_80020)

[SWS_Os_00828] dIf an ImplementationDataType is defined with the typeEmitter

!= RTE and does end with ".h" and is used for IOC communication, the IOC shall

include specified header file.c(SRS_Os_80020)

8.5.2 Type definitions

None

8.5.3 Constants

Name

Communication

Type

Errorname / Value

Annotation

IOC_E_OK

All, SND/RCV

Std_ReturnType

RTE_E_OK / 0

No error occurred

IOC_E_LENGTH

Queued SND

Std_ReturnType

RTE_E_LIMIT / 130 In case of "event"

(queued) semantic,

the internal buffer

within the IOC

communication

service is too small

for the requested

transmission size.

184 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

IOC_E_LIMIT

Queued

SND

Std_ReturnType

RTE_E_LIMIT / 130 In case of "event"

(queued) semantic,

the internal buffer

within the IOC

communication

service is full (Case:

Receiver slower than

sender). This error

produces additionally

an Overlayed Error on

the receiver side at

the next data

reception.

IOC_E_LOST_DATA

Queued

RCV

Std_ReturnType

Overlayed Error

RTE_E_LOST_DATA /

In case of "event"

(queued) semantic,

this Overlayed Error

indicates that the IOC

service refuses an

IocSend request due

to internal buffer

overflow.

IOC_E_NO_DATA

Queued

RCV

Std_ReturnType

RTE_E_NO_DATA /

131

In case of "event"

(queued) semantic,

no data is available

for reception.

8.5.4 Function definitions

[SWS_Os_00805] : dThe optional length parameter of the API shall be generated if the

VariableDataPrototype is of type dynamic and no size indicator is used in the according

ApplicationArrayDataType.c(SRS_Os_80020)

8.5.4.1 IocInit (DRAFT)

[SWS_Os_91026]{DRAFT} d

Service Name

IocInit (draft)

Syntax

void IocInit (

void

)

Service ID [hex]

0x35

Sync/Async

Synchronous

Reentrancy Non Reentrant

Parameters (in)

None

Parameters (inout)

None

Parameters (out)

None

Return value None

185 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Description

This service initializes the data structures of the IOC.

Tags: atp.Status=draft

Available via

Ioc.h

c()

8.5.4.2 IocSend/IocWrite

The IocWrite API call is generated for "data" (unqueued) semantics and the Ioc-

Send API call is generated for "event" (queued) semantics.

[SWS_Os_00718] d

Service Name

IocSend_<IocId>[_<SenderId>]

Syntax

Std_ReturnType IocSend_<IocId>[_<SenderId>] (

<Data> IN,

[uint16 numberOfBytesIN]

)

Service ID [hex]

0x1e

Sync/Async

Asynchronous

Reentrancy

This function is generated individually for each sender. The individual function is not reentrant

(if called from different runnable entities that belong to the same sender), but different functions

can be called in parallel.

Data value to be sent over a communication identified by the <Ioc

Id>. The parameter will be passed by value for primitive data

elements and by reference for all other types.

Example: Std_ReturnType IocSend_RTE_25 (const uint32 UI_

Value); Std_ReturnType IocSend_RTE_42 (const TASKParams3

*pStr_Value);

Parameters (in)

numberOfBytesIN (optional) number of bytes to be send

Parameters (inout)

None

Parameters (out)

None

Return value

Std_ReturnType IOC_E_OK: The data has been passed successfully to the

communication service.

IOC_E_LIMIT: IOC internal communication buffer is full (Case:

Receiver is slower than sender). This error produces an IOC_E_

LOST_DATA Overlayed Error on the receiver side at the next data

reception.

IOC_E_LENGTH: The <numberOfBytesIN> exceeds either the

internal buffer or is equal zero, so no data is send.

Description

Performs an "explicit" sender-receiver transmission of data elements with "event" semantic for a

unidirectional 1:1 or N:1 communication between OS-Applications located on the same or on

different cores.

<IocId> is a unique identifier that references a unidirectional 1:1 or N:1 communication.

<SenderId> is used only in N:1 communication. Together with <IocId>, it uniquely identifies the

sender. It is separated from <IocId> with an underscore. In case of 1:1 communication, it shall

be omitted.

Available via

Ioc.h

c(SRS_Os_80020)

186 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

[SWS_Os_91003] d

Service Name

IocWrite_<IocId>[_<SenderId>]

Syntax

Std_ReturnType IocWrite_<IocId>[_<SenderId>] (

<Data> IN,

[uint16 numberOfBytesIN]

)

Service ID [hex]

0x1f

Sync/Async

Asynchronous

Reentrancy

This function is generated individually for each sender. The individual function is not reentrant

(if called from different runnable entities that belong to the same sender), but different functions

can be called in parallel.

Data value to be sent over a communication identified by the <Ioc

Id>. The parameter will be passed by value for primitive data

elements and by reference for all other types.

Example: Std_ReturnType IocWrite_RTE_25 (const uint32 UI_

Value); Std_ReturnType IocWrite_RTE_42 (const TASKParams3

*pStr_Value);

Parameters (in)

numberOfBytesIN (optional) number of bytes to be send

Parameters (inout)

None

Parameters (out)

None

Return value

Std_ReturnType IOC_E_OK: The data has been passed successfully to the

communication service.

IOC_E_LENGTH: The <numberOfBytesIN> exceeds either the

internal buffer or is equal zero, so no data is send.

Description

Performs an "explicit" sender-receiver transmission of data elements with "data" semantic for a

unidirectional 1:1 or N:1 communication between OS-Applications located on the same or on

different cores.

<IocId> is a unique identifier that references a unidirectional 1:1 or N:1 communication.

<SenderId> is used only in N:1 communication. Together with <IocId>, it uniquely identifies the

sender. It is separated from <IocId> with an underscore. In case of 1:1 communication, it shall

be omitted.

<numberOfBytesIN> specifies the size of the data to be transmitted (in bytes).

Available via

Ioc.h

c()

General:

[SWS_Os_00719] dIocSend/IocWrite is asynchronous in that way it shall not have

to wait for the reception of the data on the receiving side to return from execution.c

(SRS_Os_80020)

[SWS_Os_00720] dThe IocSend/IocWrite function shall not return until the data

given in parameter have been completely physically sent over the communication

medium.

For example in case of communication over shared RAM, an IocSend/IocWrite shall

return when all data have been copied in the target shared RAM.c(SRS_Os_80020)

[SWS_Os_00721] dIn case of "event" (queued) semantic, the IocSend function shall

guarantee the order of delivery. In case of senders from different cores, the order in

which messages are received will be determined by the implementation.c(SRS_Os_-

80020)

187 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

[SWS_Os_00722] dThe IocSend/IocWrite function shall support mechanism to

guarantee data-Integrity during transmission.

The IocSend/IocWrite function shall solve the crossing of the protection boundaries

of OS-Applications. It has to be generated in case of intra-core and inter-core commu-

nication.c(SRS_Os_80020)

[SWS_Os_00820] dThe IocSend/IocWrite function shall be wrapped with the mem-

ory allocation keywords mechanism

1 #define OS_<IE>_START_SEC_CODE

2 #include "Os_MemMap.h"

4 <IocSend, IocWrite>

6 #define OS_<IE>_STOP_SEC_CODE

7 #include "Os_MemMap.h"

where <IE> is the shortName of the sending OsApplication configured in OsIoc-

SendingOsApplicationRef of the respective OsIocCommunication channel.c()

Parameters:

[SWS_Os_00723] dThe IN <Data> parameter of the IocSend/IocWrite function

shall be passed

by value for primitive data types, as an pointer to the array base type for arrays and by

reference for all other types.c(SRS_Os_80020)

[SWS_Os_00724] dFor data passed as an pointer to the array base type or by refer-

ence, the IocSend/IocWrite function shall guarantee upon return that the parameter

is safe for re-use.c(SRS_Os_80020)

Returned values:

[SWS_Os_00725] dThe IocSend/IocWrite function shall return IOC_E_OK if the

data was passed successfully to the communication service.c(SRS_Os_80020)

[SWS_Os_00726] dIn case of "event" semantic the IocSend function shall return

IOC_E_LIMIT if an IOC internal transmission buffer became full (Case: Receiver is

slower than sender or/and configured inter nal IOC buffer size is too small).

If this error occurs the IOC internal buffer could not be filled with the parameter. In that

case this error shall produce an IOC_E_LOST_DATAOverlayed Error on the receiver

side at the next data reception (s. SWS_Os_00745).c(SRS_Os_80020)

Internal structures:

[SWS_Os_00727] dIn case of "event" semantic the IOC shall configure its internal

transmission buffer size with the value of the attribute OsIocBufferLength.c(SRS_-

Os_80020)

188 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

8.5.4.3 IocSendGroup/IocWriteGroup

The IocWriteGroup API call is generated for "data" (unqueued) semantics and the

IocSendGroup API call is generated for "event" (queued) semantics.

[SWS_Os_00728] d

Service Name

IocSendGroup_<IocId>

Syntax

Std_ReturnType IocSendGroup_<IocId> (

<Data1> IN1,

[uint16 numberOfBytesIN1],

<Data2> IN2,

[uint16 numberOfBytesIN2],

...

)

Service ID [hex]

0x20

Sync/Async

Asynchronous

Reentrancy

This function is generated individually for each sender. The individual function is not reentrant

(if called from different runnable entities that belong to the same sender), but different functions

can be called in parallel.

IN1

List of parameters with data values to be sent over a

communication identified by the <IocId>. The parameters will be

passed by value for simple data elements and by reference for all

other types.

Example:

Std_ReturnType IocSendGroup_RTE_G1 (const uint32 UI_

Value1, const uint16 Value2, const uint8 Value3, const uint16

Value4);

numberOfBytesIN1 (optional) number of bytes for parameter IN1 to be send.

IN2 –

numberOfBytesIN2

–

Parameters (in)

–

Parameters (inout)

None

Parameters (out)

None

Return value

Std_ReturnType IOC_E_OK: The data has been passed successfully to the

communication service.

IOC_E_LIMIT: IOC internal communication buffer is full (Case:

Receiver is slower than sender). This error produces an IOC_E_

LOST_DATA Overlayed Error on the receiver side at the next data

reception.

IOC_E_LENGTH: Al least one of the <numberOfBytesIN<x>>

exceeds either the internal buffer or is equal zero, so no data is

send.

Description

Performs an "explicit" sender-receiver transmission of data elements with "event" semantic for a

unidirectional 1:1 communication between OS-Applications located on the same or on different

cores.

This API involves a group of data elements which values are specified in parameter.

<IocId> is a unique identifier that references a unidirectional 1:1 communication involving many

data elements.

The optional parameter <numberOfBytesIN<x>> specifies the size of the data to be transmitted

(in bytes) for parameter <IN<x>>.

Available via

Ioc.h

c(SRS_Os_80020)

189 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

[SWS_Os_91004] d

Service Name

IocWriteGroup_<IocId>

Syntax

Std_ReturnType IocWriteGroup_<IocId> (

<Data1> IN1,

[uint16 numberOfBytesIN1],

<Data2> IN2,

[uint16 numberOfBytesIN2],

...

)

Service ID [hex]

0x21

Sync/Async

Asynchronous

Reentrancy

This function is generated individually for each sender. The individual function is not reentrant

(if called from different runnable entities that belong to the same sender), but different functions

can be called in parallel.

IN1

List of parameters with data values to be sent over a

communication identified by the <IocId>. The parameters will be

passed by value for simple data elements and by reference for all

other types.

Example:

Std_ReturnType IocWriteGroup_RTE_G1 (const uint32 UI_

Value1, const uint16 Value2, const uint8 Value3, const uint16

Value4);

numberOfBytesIN1 (optional) number of bytes for parameter IN1 to be send.

IN2 –

numberOfBytesIN2

–

Parameters (in)

–

Parameters (inout)

None

Parameters (out)

None

Return value

Std_ReturnType IOC_E_OK: The data has been passed successfully to the

communication service.

IOC_E_LENGTH: Al least one of the <numberOfBytesIN<x>>

exceeds either the internal buffer or is equal zero, so no data is

send.

Description

Performs an "explicit" sender-receiver transmission of data elements with "data" semantic for a

unidirectional 1:1 communication between OS-Applications located on the same or on different

cores.

This API involves a group of data elements which values are specified in parameter.

<IocId> is a unique identifier that references a unidirectional 1:1 communication involving many

data elements.

The optional parameter <numberOfBytesIN<x>> specifies the size of the data to be transmitted

(in bytes) for parameter <IN<x>>.

Available via

Ioc.h

c()

General:

[SWS_Os_00729] dIocSendGroup/IocWriteGroup is asynchronous in that way it

shall not have to wait for the reception of the data on the receiving side to return from

execution.c(SRS_Os_80020)

[SWS_Os_00730] dThe IocSendGroup/IocWriteGroup function shall not return

until the data given in parameter have been completely physically sent over the com-

munication medium. For example in case of communication over shared RAM, an

190 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

IocSendGroup/IocWriteGroup shall return when all data have been copied in the

target shared RAM.c(SRS_Os_80020)

[SWS_Os_00731] dIn case of "event" semantic, the IocSendGroup function shall

guarantee the order of delivery.c(SRS_Os_80020)

[SWS_Os_00732] dThe IocSendGroup/IocWriteGroup function shall support

mechanisms to guarantee data-Integrity during transmission.

The IocSendGroup/IocWriteGroup function shall solve the crossing of the protec-

tion boundaries of OS-Applications. It has to be generated in case of intra-core and

inter-core communication.c(SRS_Os_80020)

[SWS_Os_00821] dThe IocSendGroup/IocWriteGroup function shall be wrapped

with the memory allocation keywords mechanism

1 #define OS_<IE>_START_SEC_CODE

2 #include "Os_MemMap.h"

4 <IocSendGroup, IocWriteGroup>

6 #define OS_<IE>_STOP_SEC_CODE

7 #include "Os_MemMap.h"

where <IE> is the shortName of the sending OsApplication configured in OsIoc-

SendingOsApplicationRef of the respective OsIocCommunication channel.c()

Parameters:

[SWS_Os_00733] dThe IN <DataN> parameters of the IocSendGroup/IocWrite-

Group function shall be passed by values for primitive data types, as pointer to the

array base type for arrays and by references for all other types.c(SRS_Os_80020)

[SWS_Os_00734] dFor data passed as an pointer to the array base type or by refer-

ence, the IocSendGroup/IocWriteGroup function shall guarantee upon return that

the parameter is safe for re-use.c(SRS_Os_80020)

Returned values:

[SWS_Os_00735] dThe IocSendGroup/IocWriteGroup function shall return IOC_

E_OK if the data was passed successfully to the communication service.c(SRS_Os_-

80020)

[SWS_Os_00736] dIn case of "event" semantic the IocSendGroup function shall re-

turn IOC_E_LIMIT if an IOC internal transmission buffer got full (Case: Receiver is

slower than sender or/and configured inter nal IOC buffer size is too small).

If this error occurs the IOC Inter nal buffer could not be filled with the parameter. In that

case this error produces an IOC_E_LOST_DATAOverlayed Error on the receiver side

at the next data reception.c(SRS_Os_80020)

Internal structures:

191 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

[SWS_Os_00737] dIn case of "event" semantic the IOC shall configure its internal

transmission buffer size with the value of the attribute OsIocBufferLength.c(SRS_-

Os_80020)

8.5.4.4 IocReceive/IocRead

The IocRead API call is generated for "data" and the IocReceive API call is gener-

ated for "events".

[SWS_Os_00738] d

Service Name

IocReceive_<IocId>

Syntax

Std_ReturnType IocReceive_<IocId> (

<Data> OUT,

[uint16

numberOfBytesOUT]

)

Service ID [hex]

0x22

Sync/Async

Synchronous

Reentrancy

This function is generated individually for each receiver. The individual function is not reentrant

(if called from different runnable entities that belong to the same receiver), but different

functions can be called in parallel.

Parameters (in)

None

Parameters (inout)

None

OUT Data reference to be filled with the received data element.

Parameters (out)

numberOfBytesOUT (optional) data reference to be filled with the length of the

received data element in bytes.

Return value

Std_ReturnType IOC_E_OK: Data was received successfully

IOC_E_NO_DATA: No data is available for reception.

IOC_E_LOST_DATA: This Overlayed Error indicates that the IOC

communication service refused an IOCSend request from sender

due to an internal buffer overflow. There is no error in the data

returned in parameter.

Description

Performs an "explicit" sender-receiver reception of data elements with "event" semantic for a

unidirectional communication between OS-Applications located on the same or on different

cores..

<IocId> is a unique identifier that references a unidirectional 1:1 or N:1 communication.

Available via

Ioc.h

c(SRS_Os_80020)

[SWS_Os_91005] d

Service Name

IocRead_<IocId>[_<ReceiverId>]

Syntax

Std_ReturnType IocRead_<IocId>[_<ReceiverId>] (

<Data> OUT,

[uint16

numberOfBytesOUT]

)

Service ID [hex]

0x23

Sync/Async

Synchronous

192 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Reentrancy

Non Reentrant This function is generated individually for each receiver. The individual function

is not reentrant (if called from different runnable entities that belong to the same receiver), but

different functions can be called in parallel.

Parameters (in)

None

Parameters (inout)

None

OUT Data reference to be filled with the received data element.

Parameters (out)

numberOfBytesOUT (optional) data reference to be filled with the length of the

received data element in bytes.

Return value

Std_ReturnType IOC_E_OK: Data was received successfully

Description

Performs an "explicit" sender-receiver reception of data elements with "data" semantic for a

unidirectional communication between OS-Applications located on the same or on different

cores.

<IocId> is a unique identifier that references a unidirectional 1:1 or N:1 communication.

<ReceiverId> is used only in N:M communication. Together with <IocId>, it uniquely identifies

the receiver. It is separated from <IocId> with an underscore. If communication is different from

N:M it shall be omitted.

Available via

Ioc.h

c()

General:

[SWS_Os_00739] dA successful call to the IocReceive/IocRead function indicates

that data has been received successfully in the OUT <Data> given in parameter.

The IocReceive/IocRead function has to be generated in case of intra-core and

inter-core communication.c(SRS_Os_80020)

[SWS_Os_00822] dThe IocReceive/IocRead function shall be wrapped with the

memory allocation keywords mechanism

1 #define OS_<IE>_START_SEC_CODE

2 #include "Os_MemMap.h"

4 <IocReceive, IocRead>

6 #define OS_<IE>_STOP_SEC_CODE

7 #include "Os_MemMap.h"

where <IE> is the shortName of the reading OsApplication configured in OsIocRe-

ceivingOsApplicationRef of the respective OsIocCommunication channel.c()

[SWS_Os_00740] dIf the OsIocReceiverPullCB attribute is defined with a callback

function name, the IOC shall call this function on the receiving core for each data

transmission.c(SRS_Os_80020)

Parameters:

[SWS_Os_00741] dIn case of "data" semantic the IocRead function shall always be

able to deliver the last available datum. In case of senders from different cores, the

precision of the order might be limited by the hardware and implementation.c(SRS_-

Os_80020)

193 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

[SWS_Os_00742] dThe IocReceive/IocRead function shall guarantee upon return-

ing from execution that the reference given in parameter is safe for use.c(SRS_Os_-

80020)

[SWS_Os_00803] dThe OUT <Data> parameter of the IocReceive/IocRead func-

tion shall be passed as an pointer to the array base type for arrays and by reference

for all other types.c(SRS_Os_80020)

Returned values:

[SWS_Os_00743] dThe IocReceive/IocRead function shall return IOC_E_OK if the

data was received successfully in the OUT <Data> parameter.c(SRS_Os_80020)

[SWS_Os_00744] dIn case of "event" semantic and if no data is available the function

IocReceive shall return IOC_E_NO_DATA.c(SRS_Os_80020)

[SWS_Os_00745] dIn case of "event" semantic an IOC_E_LOST_DATAOverlayed Er-

ror shall be returned by the IocReceive function if the IOC communication service

refused an IocSend request from sender due to an internal buffer overflow. There is

no error in the data returned in parameter.c(SRS_Os_80020)

8.5.4.5 IocReceiveGroup/IocReadGroup

The IocReadGroup API call is generated for "data" and the IocReceiveGroup API

call is generated for "events".

[SWS_Os_00746] d

Service Name

IocReceiveGroup_<IocId>

Syntax

Std_ReturnType IocReceiveGroup_<IocId> (

<Data1> OUT1,

[uint16

numberOfBytesOUT1],

<Data2> OUT2,

[uint16

numberOfBytesOUT2],

...

)

Service ID [hex]

0x24

Sync/Async

Synchronous

Reentrancy

This function is generated individually for each receiver. The individual function is not reentrant

(if called from different runnable entities that belong to the same receiver), but different

functions can be called in parallel.

Parameters (in)

None

Parameters (inout)

None

OUT1 List of data references to be filled with the received data

elements. The specified order of the parameter shall match to the

specified order in the corresponding send function.

numberOfBytesOUT1 (optional) data reference to be filled with the length of the

received data element (OUT1) in bytes.

OUT2

–

Parameters (out)

numberOfBytesOUT2

–

194 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

–

Return value

Std_ReturnType IOC_E_OK: Data was received successfully

IOC_E_NO_DATA: No data is available for reception.

IOC_E_LOST_DATA: This Overlayed Error indicates that the IOC

communication service refused an IOCSend request from sender

due to an internal buffer overflow. There is no error in the data

returned in parameter.

Description

Performs an "explicit" sender-receiver transmission of data elements with "event" semantic for a

unidirectional 1:1 communication between OS-Applications located on the same or on different

cores.

This API involves a group of data elements which values are specified in parameter.

<IocId> is a unique identifier that references a unidirectional 1:1 communication involving many

data elements.

Available via

Ioc.h

c(SRS_Os_80020)

[SWS_Os_91006] d

Service Name

IocReadGroup_<IocId>

Syntax

Std_ReturnType IocReadGroup_<IocId> (

<Data1> OUT1,

[uint16

numberOfBytesOUT1],

<Data2> OUT2,

[uint16

numberOfBytesOUT2],

...

)

Service ID [hex]

0x25

Sync/Async

Synchronous

Reentrancy

This function is generated individually for each receiver. The individual function is not reentrant

(if called from different runnable entities that belong to the same receiver), but different

functions can be called in parallel.

Parameters (in)

None

Parameters (inout)

None

OUT1 List of data references to be filled with the received data

elements. The specified order of the parameter shall match to the

specified order in the corresponding send function.

numberOfBytesOUT1 (optional) data reference to be filled with the length of the

received data element (OUT1) in bytes.

OUT2

–

numberOfBytesOUT2

–

Parameters (out)

–

Return value

Std_ReturnType IOC_E_OK: Data was received successfully

Description

Performs an "explicit" sender-receiver transmission of data elements with a "data" semantic for

a unidirectional 1:1 communication between OS-Applications located on the same or on

different cores.

This API involves a group of data elements which values are specified in parameter.

<IocId> is a unique identifier that references a unidirectional 1:1 communication involving many

data elements.

Available via

Ioc.h

c()

General:

195 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

[SWS_Os_00747] dA successful call to the IocReceiveGroup/IocReadGroup func-

tion indicates that data has been received successfully in the given parameters.

The IocReceiveGroup/IocReadGroup function has to be generated in case of intra-

core and inter-core communication.c(SRS_Os_80020)

[SWS_Os_00823] dThe IocReceiveGroup/IocReadGroup function shall be

wrapped with the memory allocation keywords mechanism

1 #define OS_<IE>_START_SEC_CODE

2 #include "Os_MemMap.h"

4 <IocReceiveGroup, IocReadGroup>

6 #define OS_<IE>_STOP_SEC_CODE

7 #include "Os_MemMap.h"

where <IE> is the shortName of the reading OsApplication configured in OsIocRe-

ceivingOsApplicationRef of the respective OsIocCommunication n channel.c

()

[SWS_Os_00748] dIf the OsIocReceiverPullCB attribute is defined with a callback

function name, the IOC shall call this function on the receiving core for each data

transmission.c(SRS_Os_80020)

Parameters:

[SWS_Os_00749] dIn case of "data" semantic the IocReadGroup function shall al-

ways be able to deliver the last available datum.c(SRS_Os_80020)

[SWS_Os_00750] dThe IocReceiveGroup/IocReadGroup function shall guarantee

upon returning from execution that the references given in parameters are safe for

use.c(SRS_Os_80020)

[SWS_Os_00804] dThe OUT <DataN> parameters of the IocReceiveGroup/

IocReadGroup function shall be passed as pointer to the array base type for arrays

and by references for all other types.c()

Returned values:

[SWS_Os_00751] dThe IocReceiveGroup/IocReadGroup function shall return

IOC_E_OK if the data was received successfully in the list of references given in pa-

rameter.c(SRS_Os_80020)

[SWS_Os_00752] dIn case of "event" semantic and if no data is available the function

IocReceiveGroup shall return IOC_E_NO_DATA.c(SRS_Os_80020)

[SWS_Os_00753] dIn case of "event" semantic an IOC_E_LOST_DATAOverlayed Er-

ror shall be returned by the IocReceiveGroup function if the IOC communication

service refused an IocSendGroup request from sender due to an internal buffer over-

flow. There is no error in the data returned in parameter.c(SRS_Os_80020)

196 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

8.5.4.6 IocEmptyQueue

[SWS_Os_00754] d

Service Name

IocEmptyQueue_<IocId>

Syntax

Std_ReturnType IocEmptyQueue_<IocId> (

void

)

Service ID [hex]

0x26

Sync/Async

Synchronous

Reentrancy Non reentrant

Parameters (in)

None

Parameters (inout)

None

Parameters (out)

None

Return value

Std_ReturnType IOC_E_OK: Content of the queue was successfully deleted

Description

In case of queued communication identified by the <IocId> in the function name, the content of

the IOC internal communication queue shall be deleted.

Available via

Ioc.h

c(SRS_Os_80020)

General:

[SWS_Os_00755] dThe function IocEmptyQueue_<IocId> shall be present for all IOC

elements with queued semantics.c(SRS_Os_80020)

[SWS_Os_00756] dThe function IocEmptyQueue_<IocId> shall delete all contents

from the associated data queue.

The IocEmptyQueue should be generated in a more efficient way than an iterative

call to an IocReceive function.c(SRS_Os_80020)

8.6 Expected Interfaces

In this chapter all interfaces required from other modules are listed.

8.6.1 Mandatory Interfaces

There are no mandatory interfaces for the IOC.

197 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

8.6.2 Optional Interfaces

8.6.2.1 ReceiverPullCB

[SWS_Os_00757] d

Service Name

Syntax

void <ReceiverPullCB> (

void

)

Sync/Async

Synchronous

Reentrancy Reentrant

Parameters (in)

None

Parameters (inout)

None

Parameters (out)

None

Return value None

Description

This callback function can be configured for the receiver of a communication. If configured, IOC

calls this callback on the receiving core for each data reception. <ReceiverPullCB> is the

callback function name configured by the receiver in the OsIocReceiverPullCB attribute to be

called on data reception."

Available via

Os.h

c(SRS_Os_80020)

[SWS_Os_00758] dThe <ReceiverPullCB> function name shall be defined within a

configuration file for each IOC communication in the OsIocReceiverPullCB at-

tribute.c(SRS_Os_80020)

[SWS_Os_00759] dThe name of the callback shall be unique over the micro controller.

For this purpose the following example can be considered as orientation for the IOC

user:

Example: Rte_IocReceiveCB_<IocId>c(SRS_Os_80020)

[SWS_Os_00760] dThe <ReceiverPullCB> function on the receiver side is using the

access rights of the receiving OsApplication.c(SRS_Os_80020)

Note: This means that such a callback cannot be reused by another OsApplication.

[SWS_Os_00761] dThis notification mechanism shall be supported for both queued

and unqueued communication semantic.c(SRS_Os_80020)

The owner of the <ReceiverPullCB> function shall pay attention that the execution time

of the function shall not last too long. It shall be possible to call this function from an

IOC-ISR.

8.7 Hook functions

Hook functions are called by the operating system if specific conditions are met. They

are provided by the user. Besides the ProtectionHook below, the hooks from [8] and/or

extensions from 7.12 may be called by the OS.

198 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

8.7.1 ProtectionHook

[SWS_Os_00538] d

Service Name

ProtectionHook

Syntax

ProtectionReturnType ProtectionHook (

StatusType Fatalerror

)

Sync/Async

Synchronous

Reentrancy Reentrant

Parameters (in)

Fatalerror The error which caused the call to the protection hook

Parameters (inout)

None

Parameters (out)

None

Return value ProtectionReturnType

PRO_IGNORE

PRO_TERMINATETASKISR

PRO_TERMINATEAPPL

PRO_TERMINATEAPPL_RESTART

PRO_SHUTDOWN

The return value defines the action the OS shall take after the

protection hook.

Description

The protection hook is always called if a serious error occurs. E.g. exceeding the worst case

execution time or violating against the memory protection.

Available via

Os_Externals.h

c()

Depending on the return value the Operating System module will either:

• forcibly terminate the Task/Category 2 ISR which causes the problem OR

• forcibly terminate the OS-Application the Task/Category 2 ISR belong (optional

with restart) OR

• shutdown the system OR

• do nothing

(see 7.8.2)

[SWS_Os_00308] dIf ProtectionHook returns an invalid value, the Operating Sys-

tem module shall take the same action as if no protection hook is configured.c()

[SWS_Os_00542] dAvailability of ProtectionHook: Available in Scalability Classes

2, 3 and 4.c()

199 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

8.7.2 Application specific StartupHook

[SWS_Os_00539] d

Service Name

StartupHook_<App>

Syntax

void StartupHook_<App> (

void

)

Sync/Async

Synchronous

Reentrancy Reentrant

Parameters (in)

None

Parameters (inout)

None

Parameters (out)

None

Return value None

Description

The application specific startup hook is called during the start of the OS (after the user has

started the OS via StartOS()).

Available via

Os_Externals.h

c()

The application specific StartupHook is always called after the standard Star-

tupHook (see [SWS_Os_00236]). If more than one OS-Application is configured

which use startup hooks, the order of calls to the startup hooks of the different OS-

Applications is not defined.

[SWS_Os_00543] dAvailability of StartupHook_<App>: Available in Scalability

Classes 3 and 4.c()

8.7.3 Application specific ErrorHook

[SWS_Os_00540] d

Service Name

ErrorHook_<App>

Syntax

void ErrorHook_<App> (

StatusType Error

)

Sync/Async

Synchronous

Reentrancy Reentrant

Parameters (in)

Error The error which caused the call to the error hook

Parameters (inout)

None

Parameters (out)

None

Return value None

Description

The application specific error hook is called whenever a Task or Category 2 ISR which belongs

to the OS-Application causes an error.

Available via

Os_Externals.h

c()

If the general ErrorHook is configured, the general ErrorHook is called before the

application specific error hook is called (see [SWS_Os_00246]).

200 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

[SWS_Os_00544] dAvailability of ErrorHook_<App>: Available in Scalability Classes

3 and 4.c()

8.7.4 Application specific ShutdownHook

[SWS_Os_00541] d

Service Name

ShutdownHook_<App>

Syntax

void ShutdownHook_<App> (

StatusType Fatalerror

)

Sync/Async

Synchronous

Reentrancy Reentrant

Parameters (in)

Fatalerror The error which caused the action to shut down the operating

system.

Parameters (inout)

None

Parameters (out)

None

Return value None

Description

The application specific shutdown hook is called whenever the system starts the shut down of

itself.

Available via

Os_Externals.h

c()

If the general ShutdownHook is configured, the general ShutdownHook is called after

all application specific shutdown hook(s) are called (see [SWS_Os_00237]). If more

OS-Applications with an application specific shutdown hook exist the order of calls to

these application specific shutdown hooks is not defined.

[SWS_Os_00545] dAvailability of ShutdownHook_<App>: Available in Scalability

Classes 3 and 4.c()

8.8 Service Interfaces

8.8.1 Port interface of Os

[SWS_Os_91027] d

Name

OsService

Kind

ProvidedPort

Interface

OsService_{Counter}

Description

–

Type

CounterType

Port Defined

Argument Value(s)

Value

{ecuc(Os/OsCounter)}

Variation

–

c()

201 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

8.8.2 Client-Server-Interfaces

8.8.2.1 Os_Service

[SWS_Os_00560] d

Name

OsService_{Counter}

Comment

–

IsService

true

Variation

({ecuc(Os/OsCounter/OsSecondsPerTick)} != NULL)

Counter = {ecuc(Os/OsCounter.SHORT-NAME)}

E_OK Operation successful

E_OS_ACCESS

–

E_OS_ID

–

E_OS_STATE

–

Possible Errors

E_OS_VALUE

–

Operation

GetCounterValue

Comment

This service reads the current count value of a counter (returning either the hardware timer

ticks if counter is driven by hardware or the software ticks when user drives counter).

Mapped to API –

Variation

–

Value

Type TimeInMicrosecondsType

Direction

OUT

Comment

Contains the current tick value of the counter

Parameters

Variation

–

Possible Errors

E_OK

E_OS_ID

Operation

GetElapsedValue

Comment

This service gets the number of ticks between the current tick value and a previously read tick

value.

Mapped to API –

Variation

–

Value

Type TimeInMicrosecondsType

Direction

INOUT

Comment

in: the previously read tick value of the counter

out: the current tick value of the counter

Variation

–

ElapsedValue

Type TimeInMicrosecondsType

Direction

OUT

Comment

The difference to the previous read value

Parameters

Variation

–

Possible Errors

E_OK

E_OS_ID

E_OS_VALUE

c()

202 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

8.8.2.2 Implementation Data Types

[SWS_Os_00794] d

Name TimeInMicrosecondsType

Kind

Type

Derived from

uint64

Description

–

Variation

–

Available via

Rte_Os_Type.h

c()

[SWS_Os_00786] d

Name

CounterType

Kind

Type

Derived from

uint32

Description

This data type identifies a counter.

Variation

–

Available via

Rte_Os_Type.h

c()

203 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

9 Sequence diagrams

9.1 Sequence chart for calling trusted functions

Figure 9.1: System Call sequence chart

The above sequence describes a call to the CallTrustedFunction service. It starts

with a user who calls a service which requires itself a call to a trusted function. The

service then packs the argument for the trusted function into a structure and calls

CallTrustedFunction with the ID and the pointer as arguments. Afterwards the

OS checks if the access to the requested service is valid. If no access is granted

E_OS_SERVICEID is returned. Otherwise the trusted service itself is called and the

function checks the arguments for access right, etc.

204 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

9.2 Sequence chart for usage of ErrorHook

Figure 9.2: Error Hook sequence chart

The above sequence chart shows the sequence of error hook calls in case a service

does not return with E_OK. Note that in this case the general error hook and the OS-

Application specific error hook are called.

205 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

9.3 Sequence chart for ProtectionHook

Figure 9.3: ProtectionHook sequence chart

The sequence shows the flow of control if a protection error occurs. Depending on the

return values of the ProtectionHook, either the faulty Task/ISR is forcibly terminated

or the OS-Application is forcibly terminated or the system is shut down. If the action is

to terminate the faulty OS-Application an option is to start afterwards the restart Task,

which can do a cleanup, etc.

206 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

9.4 Sequence chart for StartupHook

Figure 9.4: StartupHook sequence chart

The above sequence shows the flow of control during the startup of the OS. Like in

OSEK OS the user calls the StartOS service to start the OS. During the startup the

startup hooks are called in the above order. The rest of the startup sequence is identi-

cal to the defined behaviour of OSEK OS.

9.5 Sequence chart for ShutdownHook

The next sequence shows the behaviour in case of a shut down. The flow is the same

as in OSEK OS with the exception that the shut down hooks of the OS-Applications are

called before the general ShutdownHook is called. Note that the specific shutdown

hooks of the application are not allowed to block, they must return to the caller.

207 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Figure 9.5: ShutdownHook sequence chart

9.6 Sequence diagrams of Sender Receiver communication over

the IOC

9.6.1 Last-is-best communication

The 9.6 shows a sequence of successful and failure cases in the interaction between

the IOC and the RTE in case of last-is-best communication ("data" semantic).

208 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Figure 9.6: IOC - Last-is-best communication

9.6.2 Queued communication without pull callback

The figure 9.7 shows the interaction between IOC and RTE with a focus on the con-

gestion control for a queued communication.

The defined communication has no callback functionality for data reception, has an

internal buffer size of 2 data elements, no waitpoints are defined and the implicated

OS-Applications are located on different cores.

209 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Figure 9.7: IOC - Queued communication without callback

9.6.3 Queued communication with pull callback

The figure 9.8 shows the interaction between IOC and RTE in case of a queued com-

munication with an activated callback functionality. The RTE might handle notification

internally and might therefore not provide any callback functions, but a similar scenario

will occur in case of communication between CDDs on different cores. The receiving

CDD will provide the callback function in this case.

The defined communication has no waitpoints and describes a communication impli-

cating two OS-Applications located on different cores.

210 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Figure 9.8: IOC Queued Communication with callback

211 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

10 Configuration specification

In general, this chapter defines configuration parameters and their clustering into con-

tainers. In order to support the specification Chapter 10.1 descr ibes fundamentals.

It also specifies a template (table) you shall use for the parameter specification. We

intend to leave Chapter 10.1 in the specification to guarantee comprehension.

Chapter 10.2 specifies the structure (containers) and the parameters of the module Os.

Chapter 10.3 specifies the structure (containers) and the parameters of the Ioc.

Chapter 10.4 specifies the structure (containers) and the ARTI parameters for the Os

and Ioc.

Chapter 10.5 specifies published information of the module Os.

10.1 How to read this chapter

For details refer to the chapter 10.1 “Introduction to configuration specification” in [4].

10.1.1 Rules for paramters

Some configuration parameters are configured as floating point values and sometimes

these values must be rounded in order to be used. The following rules define the

rounding of specific parameters:

• Execution times (for the timing protection) are "round down"

• Timeframes are "round down"

10.2 Containers and configuration parameters

The following chapters summarize all configuration parameters and their containers.

Background information about the detailed meaning of the parameters can be found in

chapters 7 and 8.

For better readability OIL names of the 2.1 OS specification are given in curly braces

in the namefield of configuration parameters.

212 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

10.2.1 Os

SWS Item [ECUC_Os_00396]

Module Name

Description

Configuration of the Os (Operating System) module.

Post-Build Variant Support

false

Supported Config Variants

VARIANT-PRE-COMPILE

Included Containers

Container Name Multiplicity Scope / Dependency

OsAlarm

0..*

An OsAlarm may be used to asynchronously inform or activate a

specific task. It is possible to start alarms automatically at

system start-up depending on the application mode.

OsAppMode

1..*

OsAppMode is the object used to define ISO 17356-3 properties

for an ISO 17356-3 application mode.

No standard attributes are defined for AppMode.

In a CPU, at least one AppMode object has to be defined.

[source: ISO 17356-6]

An OsAppMode called OSDEFAULTAPPMODE must always be

there for ISO 17356 compatibility.

OsApplication

0..*

An AUTOSAR OS must be capable of supporting a collection of

OS objects (tasks, interrupts, alarms, hooks etc.) that form a

cohesive functional unit. This collection of objects is termed an

OS-Application.

All objects which belong to the same OS-Application have

access to each other. Access means to allow to use these

objects within API services.

Access by other applications can be granted separately.

OsCounter

0..*

Configuration information for the counters that belong to the Os

Application.

OsEvent

0..*

Representation of OS events in the configuration context.

Adopted from the ISO 17356-6 specification.

OsIoc

0..1

Configuration of the IOC (Inter OS Application Communicator).

OsIsr

0..*

The OsIsr container represents an ISO 17356 interrupt service

routine.

OsOS

OS is the object used to define ISO 17356-3 properties for an

ISO 17356 application.

Per CPU exactly one OS object has to be defined.

OsPeripheralArea

0..65534

Container to structure the configuration parameters of one

peripheral area. The container short name can be used to

access this area.

OsResource

0..*

An OsResource object is used to co-ordinate the concurrent

access by tasks and ISRs to a shared resource, e.g. the

scheduler, any program sequence, memory or any hardware

area.

OsScheduleTable

0..*

An OsScheduleTable addresses the synchronization issue by

providing an encapsulation of a statically defined set of alarms

that cannot be modified at runtime.

OsSpinlock

0..*

An OsSpinlock object is used to co-ordinate concurrent access

by TASKs/ISR2s on different cores to a shared resource.

OsTask

0..*

This container represents an ISO 17356 task.

213 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Os: EcucModuleDef

upperMultiplicity = 1

lowerMultiplicity = 0

OsApplication:

EcucParamConfContainerDef

upperMultiplicity = *

lowerMultiplicity = 0

OsOS:

EcucParamConfContainerDef

OsTask:

EcucParamConfContainerDef

upperMultiplicity = *

lowerMultiplicity = 0

OsScheduleTable:

EcucParamConfContainerDef

upperMultiplicity = *

lowerMultiplicity = 0

OsResource:

EcucParamConfContainerDef

upperMultiplicity = *

lowerMultiplicity = 0

OsIsr:

EcucParamConfContainerDef

upperMultiplicity = *

lowerMultiplicity = 0

OsEvent:

EcucParamConfContainerDef

upperMultiplicity = *

lowerMultiplicity = 0

OsEventMask:

EcucIntegerParamDef

upperMultiplicity = 1

lowerMultiplicity = 0

min = 0

OsAppMode:

EcucParamConfContainerDef

upperMultiplicity = *

lowerMultiplicity = 1

OsAlarm:

EcucParamConfContainerDef

upperMultiplicity = *

lowerMultiplicity = 0

OsCounter:

EcucParamConfContainerDef

lowerMultiplicity = 0

upperMultiplicity = *

OsSpinlock:

EcucParamConfContainerDef

lowerMultiplicity = 0

upperMultiplicity = *

OsIoc:

EcucParamConfContainerDef

lowerMultiplicity = 0

upperMultiplicity = 1

OsPeripheralArea:

EcucParamConfContainerDef

upperMultiplicity = 65534

lowerMultiplicity = 0

OsPeripheralAreaId:

EcucIntegerParamDef

symbolicNameValue = true

OsPeripheralAreaStartAddress:

EcucIntegerParamDef

min = 0

OsPeripheralAreaEndAddress:

EcucIntegerParamDef

min = 0

OsPeripheralAreaAccessingApplication:

EcucReferenceDef

upperMultiplicity = *

lowerMultiplicity = 0

+container

+reference

+container

+parameter

+destination

+container

+parameter

+container

+parameter

+container

+parameter

+container

Figure 10.1: Os configuration overview

214 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

10.2.2 OsAlarmSetEvent

SWS Item [ECUC_Os_00016]

Container Name

OsAlarmSetEvent

Parent Container

OsAlarmAction

Description

This container specifies the parameters to set an event

Configuration Parameters

SWS Item [ECUC_Os_00017]

Parameter Name

OsAlarmSetEventRef

Parent Container

OsAlarmSetEvent

Description

Reference to the event that will be set by that alarm action

Multiplicity

Type

Reference to OsEvent

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: local

SWS Item [ECUC_Os_00018]

Parameter Name

OsAlarmSetEventTaskRef

Parent Container

OsAlarmSetEvent

Description

Reference to the task that will be activated by that event

Multiplicity

Type

Reference to OsTask

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: local

No Included Containers

10.2.3 OsAlarm

SWS Item [ECUC_Os_00003]

Container Name

OsAlarm

Parent Container

Description

An OsAlarm may be used to asynchronously inform or activate a specific task. It is

possible to start alarms automatically at system start-up depending on the application

mode.

Configuration Parameters

215 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

SWS Item [ECUC_Os_00004]

Parameter Name

OsAlarmAccessingApplication

Parent Container

OsAlarm

Description

Reference to applications which have an access to this object.

Multiplicity

0..*

Type

Reference to OsApplication

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

SWS Item [ECUC_Os_00005]

Parameter Name

OsAlarmCounterRef

Parent Container

OsAlarm

Description

Reference to the assigned counter for that alarm

Multiplicity

Type

Reference to OsCounter

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: local

Included Containers

Container Name Multiplicity Scope / Dependency

OsAlarmAction

This container defines which type of notification is used when the

alarm expires.

OsAlarmAutostart

0..1

If present this container defines if an alarm is started

automatically at system start-up depending on the application

mode.

216 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

OsAlarm:

EcucParamConfContainerDef

upperMultiplicity = *

lowerMultiplicity = 0

OsAlarmAutostart:

EcucParamConfContainerDef

upperMultiplicity = 1

lowerMultiplicity = 0

OsAlarmAlarmTime:

EcucIntegerParamDef

min = 0

OsAlarmCycleTime:

EcucIntegerParamDef

min = 0

OsAlarmAppModeRef:

EcucReferenceDef

upperMultiplicity = *

lowerMultiplicity = 1

OsAppMode:

EcucParamConfContainerDef

upperMultiplicity = *

lowerMultiplicity = 1

OsAlarmCounterRef:

EcucReferenceDef

Ecu

OsAlarmAction:

EcucChoiceContainerDef

OsAlarmActivateTask:

EcucParamConfContainerDef

upperMultiplicity = 1

lowerMultiplicity = 0

OsAlarmSetEvent:

EcucParamConfContainerDef

upperMultiplicity = 1

lowerMultiplicity = 0

OsAlarmCallback:

EcucParamConfContainerDef

upperMultiplicity = 1

lowerMultiplicity = 0

OsAlarmIncrementCounter:

EcucParamConfContainerDef

upperMultiplicity = 1

lowerMultiplicity = 0

OsAlarmActivateTaskRef:

EcucReferenceDef

OsAlarmSetEventTaskRef:

EcucReferenceDef

OsAlarmCallbackName:

EcucFunctionNameDef

OsAlarmSetEventRef:

EcucReferenceDef

OsAlarmIncrementCounterRef:

EcucReferenceDef

OsAlarmAccessingApplication:

EcucReferenceDef

upperMultiplicity = *

lowerMultiplicity = 0

OsApplication:

EcucParamConfContainerDef

upperMultiplicity = *

lowerMultiplicity = 0

OsAlarmAutostartType:

EcucEnumerationParamDef

ABSOLUTE:

EcucEnumerationLiteralDef

RELATIVE:

EcucEnumerationLiteralDef

OsMemoryMappingCodeLocationRef:

EcucForeignReferenceDef

destinationType = SW-ADDR-METHOD

lowerMultiplicity = 0

upperMultiplicity = 1

+reference

+parameter

+destination

+reference

+parameter

+choice

+parameter

+subContainer

+destination

+reference

+destination

+reference

+subContainer

+destination

+parameter

+destination

+reference

+literal

+choice

+destination

+reference

Figure 10.2: OsAlarm configuration overview

10.2.4 OsAlarmAction

SWS Item [ECUC_Os_00006]

Choice Container Name

OsAlarmAction

Parent Container

OsAlarm

Description

This container defines which type of notification is used when the alarm expires.

Container Choices

Container Name Multiplicity Scope / Dependency

OsAlarmActivateTask

0..1

This container specifies the parameters to activate a task.

OsAlarmCallback

0..1

This container specifies the parameters to call a callback OS

alarm action.

OsAlarmIncrementCounter

0..1

This container specifies the parameters to increment a counter.

OsAlarmSetEvent

0..1

This container specifies the parameters to set an event

217 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

10.2.5 OsAlarmActivateTask

SWS Item [ECUC_Os_00007]

Container Name

OsAlarmActivateTask

Parent Container

OsAlarmAction

Description

This container specifies the parameters to activate a task.

Configuration Parameters

SWS Item [ECUC_Os_00008]

Parameter Name

OsAlarmActivateTaskRef

Parent Container

OsAlarmActivateTask

Description

Reference to the task that will be activated by that alarm action

Multiplicity

Type

Reference to OsTask

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: local

No Included Containers

10.2.6 OsAlarmAutostart

SWS Item [ECUC_Os_00009]

Container Name

OsAlarmAutostart

Parent Container

OsAlarm

Description

If present this container defines if an alarm is started automatically at system start-up

depending on the application mode.

Configuration Parameters

SWS Item [ECUC_Os_00010]

Parameter Name

OsAlarmAlarmTime

Parent Container

OsAlarmAutostart

Description

The relative or absolute tick value when the alarm expires for the first time. Note that

for an alarm which is RELATIVE the value must be at bigger than 0.

Multiplicity

Type

EcucIntegerParamDef

Range 0 .. 18446744073709551615

Default value

–

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: local

218 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

SWS Item [ECUC_Os_00011]

Parameter Name

OsAlarmAutostartType

Parent Container

OsAlarmAutostart

Description

This specifies the type of autostart for the alarm..

Multiplicity

Type

EcucEnumerationParamDef

ABSOLUTE The alarm is started on startup via SetAbs

Alarm().

Range

RELATIVE

The alarm is started on startup via SetRel

Alarm().

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: local

SWS Item [ECUC_Os_00012]

Parameter Name

OsAlarmCycleTime

Parent Container

OsAlarmAutostart

Description

Cycle time of a cyclic alarm in ticks. If the value is 0 than the alarm is not cyclic.

Multiplicity

Type

EcucIntegerParamDef

Range 0 .. 18446744073709551615

Default value

–

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: local

SWS Item [ECUC_Os_00013]

Parameter Name

OsAlarmAppModeRef

Parent Container

OsAlarmAutostart

Description

Reference to the application modes for which the AUTOSTART shall be performed

Multiplicity

1..*

Type

Reference to OsAppMode

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: local

No Included Containers

219 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

10.2.7 OsAlarmCallback

SWS Item [ECUC_Os_00014]

Container Name

OsAlarmCallback

Parent Container

OsAlarmAction

Description

This container specifies the parameters to call a callback OS alarm action.

Configuration Parameters

SWS Item [ECUC_Os_00087]

Parameter Name

OsAlarmCallbackName

Parent Container

OsAlarmCallback

Description

Name of the function that is called when this alarm callback is triggered.

Multiplicity

Type

EcucFunctionNameDef

Default value

–

Regular Expression

–

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: local

SWS Item [ECUC_Os_00409]

Parameter Name

OsMemoryMappingCodeLocationRef

Parent Container

OsAlarmCallback

Description

Reference to the memory mapping containing details about the section where the code

is placed.

Multiplicity

0..1

Type

Foreign reference to SW-ADDR-METHOD

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

No Included Containers

10.2.8 OsAlarmIncrementCounter

SWS Item [ECUC_Os_00302]

Container Name

OsAlarmIncrementCounter

Parent Container

OsAlarmAction

Description

This container specifies the parameters to increment a counter.

Configuration Parameters

220 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

SWS Item [ECUC_Os_00015]

Parameter Name

OsAlarmIncrementCounterRef

Parent Container

OsAlarmIncrementCounter

Description

Reference to the counter that will be incremented by that alarm action

Multiplicity

Type

Reference to OsCounter

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

No Included Containers

10.2.9 OsApplication

SWS Item [ECUC_Os_00114]

Container Name

OsApplication

Parent Container

Description

An AUTOSAR OS must be capable of supporting a collection of OS objects (tasks,

interrupts, alarms, hooks etc.) that for m a cohesive functional unit. This collection of

objects is termed an OS-Application.

All objects which belong to the same OS-Application have access to each other.

Access means to allow to use these objects within API services.

Access by other applications can be granted separately.

Configuration Parameters

SWS Item [ECUC_Os_00115]

Parameter Name

OsTrusted

Parent Container

OsApplication

Description

Parameter to specify if an OS-Application is trusted or not.

true: OS-Application is trusted false: OS-Application is not trusted (default)

Multiplicity

Type

EcucBooleanParamDef

Default value

false

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

dependency: Required for scalability class 3 and 4.

SWS Item [ECUC_Os_00395]

Parameter Name

OsTrustedApplicationDelayTimingViolationCall

Parent Container

OsApplication

221 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Description

Parameter to specify if a timing violation which occurs within an trusted OS-Application

is raised immediately of if it is delayed until the current task returns to the calling

OS-Application (return of CallTrustedFunction) true: violation / call to ProtectionHook()

is delayed false: timing violation cause an immediate call to the ProtectionHook().

Multiplicity

Type

EcucBooleanParamDef

Default value

true

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

SWS Item [ECUC_Os_00394]

Parameter Name

OsTrustedApplicationWithProtection

Parent Container

OsApplication

Description

Parameter to specify if a trusted OS-Application is executed with memory protection or

not.

true: OS-Application runs within a protected environment. This means that write

access is limited. false: OS-Application has full write access (default)

Multiplicity

Type

EcucBooleanParamDef

Default value

false

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

SWS Item [ECUC_Os_00231]

Parameter Name

OsAppAlarmRef

Parent Container

OsApplication

Description

Specifies the OsAlarms that belong to the OsApplication.

Multiplicity

0..*

Type

Reference to OsAlarm

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

222 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

SWS Item [ECUC_Os_00234]

Parameter Name

OsAppCounterRef

Parent Container

OsApplication

Description

References the OsCounters that belong to the OsApplication.

Multiplicity

0..*

Type

Reference to OsCounter

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

SWS Item [ECUC_Os_00392]

Parameter Name

OsAppEcucPar titionRef

Parent Container

OsApplication

Description

Denotes which "EcucPar tition" is implemented by this "OSApplication".

Multiplicity

0..1

Type

Reference to EcucPar tition

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

SWS Item [ECUC_Os_00221]

Parameter Name

OsAppIsrRef

Parent Container

OsApplication

Description

references which OsIsrs belong to the OsApplication

Multiplicity

0..*

Type

Reference to OsIsr

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

223 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

SWS Item [ECUC_Os_00393]

Parameter Name

OsApplicationCoreRef

Parent Container

OsApplication

Description

Reference to the Core Definition in the Ecuc Module where the CoreId is defined. This

reference is used to describe to which Core the OsApplication is bound.

Multiplicity

0..1

Type

Reference to EcucCoreDefinition

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: local

SWS Item [ECUC_Os_00230]

Parameter Name

OsAppScheduleTableRef

Parent Container

OsApplication

Description

References the OsScheduleTables that belong to the OsApplication.

Multiplicity

0..*

Type

Reference to OsScheduleTable

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

SWS Item [ECUC_Os_00116]

Parameter Name

OsAppTaskRef

Parent Container

OsApplication

Description

references which OsTasks belong to the OsApplication

Multiplicity

0..*

Type

Reference to OsTask

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

224 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Scope / Dependency

scope: ECU

SWS Item [ECUC_Os_00402]

Parameter Name

OsMemoryMappingCodeLocationRef

Parent Container

OsApplication

Description

Reference to the memory mapping containing details about the section where the code

is placed.

Multiplicity

0..1

Type

Foreign reference to SW-ADDR-METHOD

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

SWS Item [ECUC_Os_00120]

Parameter Name

OsRestartTask

Parent Container

OsApplication

Description

Optionally one task of an OS-Application may be defined as Restart Task.

Multiplicity = 1: Restart Task is activated by the Operating System if the protection hook

requests it.

Multiplicity = 0: No task is automatically started after a protection error happened.

Multiplicity

0..1

Type

Reference to OsTask

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

dependency: Required for scalability class 3 and 4.

Included Containers

Container Name Multiplicity Scope / Dependency

OsApplicationHooks

Container to structure the OS-Application-specific hooks

OsApplicationTrustedFunction

0..*

Container to structure the configuration parameters of trusted

functions

225 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

OsApplication: EcucParamConfContainerDef

upperMultiplicity = *

lowerMultiplicity = 0

OsScheduleTable:

EcucParamConfContainerDef

upperMultiplicity = *

lowerMultiplicity = 0

OsAppScheduleTableRef:

EcucReferenceDef

upperMultiplicity = *

lowerMultiplicity = 0

OsAlarm:

EcucParamConfContainerDef

upperMultiplicity = *

lowerMultiplicity = 0

OsAppTaskRef: EcucReferenceDef

upperMultiplicity = *

lowerMultiplicity = 0

OsIsr:

EcucParamConfContainerDef

upperMultiplicity = *

lowerMultiplicity = 0

OsAppAlarmRef:

EcucReferenceDef

upperMultiplicity = *

lowerMultiplicity = 0

OsTask:

EcucParamConfContainerDef

upperMultiplicity = *

lowerMultiplicity = 0

OsRestartTask: EcucReferenceDef

upperMultiplicity = 1

lowerMultiplicity = 0

OsApplicationHooks:

EcucParamConfContainerDef

OsAppIsrRef: EcucReferenceDef

upperMultiplicity = *

lowerMultiplicity = 0

OsCounter:

EcucParamConfContainerDef

lowerMultiplicity = 0

upperMultiplicity = *

OsAppCounterRef:

EcucReferenceDef

upperMultiplicity = *

lowerMultiplicity = 0

OsTrusted: EcucBooleanParamDef

defaultValue = false

OsApplicationTrustedFunction:

EcucParamConfContainerDef

upperMultiplicity = *

lowerMultiplicity = 0

OsAppEcucPartitionRef:

EcucReferenceDef

lowerMultiplicity = 0

upperMultiplicity = 1

EcucPartition:

EcucParamConfContainerDef

lowerMultiplicity = 0

upperMultiplicity = *

EcucCoreDefinition:

EcucParamConfContainerDef

lowerMultiplicity = 0

upperMultiplicity = *

OsApplicationCoreRef:

EcucReferenceDef

lowerMultiplicity = 0

upperMultiplicity = 1

OsTrustedApplicationWithProtection:

EcucBooleanParamDef

defaultValue = false

OsTrustedApplicationDelayTimingViolationCall:

EcucBooleanParamDef

defaultValue = true

OsMemoryMappingCodeLocationRef:

EcucForeignReferenceDef

destinationType = SW-ADDR-METHOD

lowerMultiplicity = 0

upperMultiplicity = 1

+reference

+destination

+reference

+destination

+reference

+destination

+reference

+parameter

+destination

+subContainer

+parameter

+reference

+destination

+reference

+parameter

+subContainer

+destination

+reference

+destination

+reference

Figure 10.3: OsApplication configuration overview

226 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

10.2.10 OsApplicationHooks

SWS Item [ECUC_Os_00020]

Container Name

OsApplicationHooks

Parent Container

OsApplication

Description

Container to structure the OS-Application-specific hooks

Configuration Parameters

SWS Item [ECUC_Os_00213]

Parameter Name

OsAppErrorHook

Parent Container

OsApplicationHooks

Description

Select the OS-Application error hook.

true: Hook is called false: Hook is not called

Multiplicity

Type

EcucBooleanParamDef

Default value

–

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

dependency: Required for scalability class 3 and 4.

SWS Item [ECUC_Os_00125]

Parameter Name

OsAppShutdownHook

Parent Container

OsApplicationHooks

Description

Select the OS-Application specific shutdown hook for the OS-Application.

true: Hook is called false: Hook is not called

Multiplicity

Type

EcucBooleanParamDef

Default value

–

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

dependency: Required for scalability class 3 and 4.

SWS Item [ECUC_Os_00124]

Parameter Name

OsAppStartupHook

Parent Container

OsApplicationHooks

Description

Select the OS-Application specific startup hook for the OS-Application.

true: Hook is called false: Hook is not called

Multiplicity

Type

EcucBooleanParamDef

Default value

–

Post-Build Variant Value

false

227 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

dependency: Required for scalability class 3 and 4.

SWS Item [ECUC_Os_00402]

Parameter Name

OsMemoryMappingCodeLocationRef

Parent Container

OsApplicationHooks

Description

Reference to the memory mapping containing details about the section where the code

is placed.

Multiplicity

0..1

Type

Foreign reference to SW-ADDR-METHOD

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

No Included Containers

OsApplication:

EcucParamConfContainerDef

upperMultiplicity = *

lowerMultiplicity = 0

OsApplicationHooks:

EcucParamConfContainerDef

OsAppStartupHook:

EcucBooleanParamDef

OsAppShutdownHook:

EcucBooleanParamDef

OsAppErrorHook:

EcucBooleanParamDef

OsMemoryMappingCodeLocationRef:

EcucForeignReferenceDef

destinationType = SW-ADDR-METHOD

lowerMultiplicity = 0

upperMultiplicity = 1

ARElement

AtpBlueprint

AtpBlueprintable

SwAddrMethod

+ memoryAllocationKeywordPolicy: MemoryAllocationKeywordPolicyType [0..1]

+ option: Identifier [0..*]

+ sectionInitializationPolicy: SectionInitializationPolicyType [0..1]

+ sectionType: MemorySectionType [0..1]

+parameter

+subContainer

+reference

+parameter

Figure 10.4: OsApplicationHooks configuration overview

228 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

10.2.11 OsApplicationTrustedFunction

SWS Item [ECUC_Os_00021]

Container Name

OsApplicationTrustedFunction

Parent Container

OsApplication

Description

Container to structure the configuration parameters of trusted functions

Configuration Parameters

SWS Item [ECUC_Os_00254]

Parameter Name

OsTrustedFunctionName

Parent Container

OsApplicationTrustedFunction

Description

Trusted function (as part of a trusted OS-Application) available to other

OS-Applications. This also supersedes the ISO 17356-6 attribute TRUSTED in

APPLICATION because the optionality of this parameter is describing that already.

Multiplicity

Type

EcucFunctionNameDef

Default value

–

Regular Expression

–

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

dependency: Required for scalability class 3 and 4 and in trusted OS-Applications.

SWS Item [ECUC_Os_00408]

Parameter Name

OsMemoryMappingCodeLocationRef

Parent Container

OsApplicationTrustedFunction

Description

Reference to the memory mapping containing details about the section where the code

is placed.

Multiplicity

0..1

Type

Foreign reference to SW-ADDR-METHOD

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

No Included Containers

229 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

OsApplicationTrustedFunction:

EcucParamConfContainerDef

upperMultiplicity = *

lowerMultiplicity = 0

OsTrustedFunctionName:

EcucFunctionNameDef

OsMemoryMappingCodeLocationRef:

EcucForeignReferenceDef

destinationType = SW-ADDR-METHOD

lowerMultiplicity = 0

upperMultiplicity = 1

ARElement

AtpBlueprint

AtpBlueprintable

SwAddrMethod

+ memoryAllocationKeywordPolicy: MemoryAllocationKeywordPolicyType [0..1]

+ option: Identifier [0..*]

+ sectionInitializationPolicy: SectionInitializationPolicyType [0..1]

+ sectionType: MemorySectionType [0..1]

+parameter

+reference

Figure 10.5: OsApplicationTrustedFunction configuration overview

10.2.12 OsAppMode

SWS Item [ECUC_Os_00022]

Container Name

OsAppMode

Parent Container

Description

OsAppMode is the object used to define ISO 17356-3 properties for an ISO 17356-3

application mode.

No standard attributes are defined for AppMode.

In a CPU, at least one AppMode object has to be defined.

[source: ISO 17356-6]

An OsAppMode called OSDEFAULTAPPMODE must always be there for ISO 17356

compatibility.

Configuration Parameters

No Included Containers

10.2.13 OsCounter

SWS Item [ECUC_Os_00026]

Container Name

OsCounter

Parent Container

Description

Configuration information for the counters that belong to the OsApplication.

Configuration Parameters

SWS Item [ECUC_Os_00027]

Parameter Name

OsCounterMaxAllowedValue

Parent Container

OsCounter

Description

Maximum possible allowed value of the system counter in ticks.

Multiplicity

Type

EcucIntegerParamDef

230 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Range 1 .. 18446744073709551615

Default value

–

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: local

SWS Item [ECUC_Os_00028]

Parameter Name

OsCounterMinCycle

Parent Container

OsCounter

Description

The MINCYCLE attribute specifies the minimum allowed number of counter ticks for a

cyclic alarm linked to the counter.

Multiplicity

Type

EcucIntegerParamDef

Range 1 .. 18446744073709551615

Default value

–

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: local

SWS Item [ECUC_Os_00029]

Parameter Name

OsCounterTicksPerBase

Parent Container

OsCounter

Description

The TICKSPERBASE attribute specifies the number of ticks required to reach a

counterspecific unit. The interpretation is implementation-specific.

Multiplicity

Type

EcucIntegerParamDef

Range 1 .. 4294967295

Default value

–

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: local

SWS Item [ECUC_Os_00255]

Parameter Name

OsCounterType

Parent Container

OsCounter

Description

This parameter contains the natural type or unit of the counter.

Multiplicity

Type

EcucEnumerationParamDef

HARDWARE This counter is driven by some hardware e.g. a

hardware timer unit.

Range

SOFTWARE The counter is driven by some software which

calls the IncrementCounter service.

231 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

SWS Item [ECUC_Os_00030]

Parameter Name

OsSecondsPerTick

Parent Container

OsCounter

Description

Time of one counter tick in seconds.

Multiplicity

0..1

Type

EcucFloatParamDef

Range [0 .. INF]

Default value

–

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

SWS Item [ECUC_Os_00031]

Parameter Name

OsCounterAccessingApplication

Parent Container

OsCounter

Description

Reference to applications which have an access to this object.

Multiplicity

0..*

Type

Reference to OsApplication

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: local

232 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Included Containers

Container Name Multiplicity Scope / Dependency

OsDriver

0..1

This Container contains the information who will drive the

counter. This configuration is only valid if the counter has Os

CounterType set to HARDWARE.

If the container does not exist (multiplicity=0) the timer is

managed by the OS internally (OSINTERNAL).

If the container exists the OS can use the GPT interface to

manage the timer. The user have to supply the GPT channel.

If the counter is driven by some other (external to the OS) source

(like a TPU for example) this must be described as a vendor

specific extension.

OsTimeConstant

0..*

Allows the user to define constants which can be e.g. used to

compare time values with timer tick values.

A time value will be converted to a timer tick value during

generation and can later on accessed via the OsConstName.

The conversation is done by rounding time values to the nearest

fitting tick value.

OsCounter:

EcucParamConfContainerDef

lowerMultiplicity = 0

upperMultiplicity = *

OsCounterMinCycle:

EcucIntegerParamDef

min = 1

OsCounterMaxAllowedValue:

EcucIntegerParamDef

min = 1

OsCounterTicksPerBase:

EcucIntegerParamDef

min = 1

max = 4294967295

OsCounterType:

EcucEnumerationParamDef

SOFTWARE:

EcucEnumerationLiteralDef

HARDWARE:

EcucEnumerationLiteralDef

OsApplication:

EcucParamConfContainerDef

upperMultiplicity = *

lowerMultiplicity = 0

OsDriver:

EcucParamConfContainerDef

lowerMultiplicity = 0

upperMultiplicity = 1

OsSecondsPerTick:

EcucFloatParamDef

upperMultiplicity = 1

lowerMultiplicity = 0

min = 0

max = INF

OsGptChannelRef: EcucReferenceDef

lowerMultiplicity = 0

upperMultiplicity = 1

requiresSymbolicNameValue = true

GptChannelConfiguration:

EcucParamConfContainerDef

upperMultiplicity = *

lowerMultiplicity = 1

OsTimeConstant:

EcucParamConfContainerDef

lowerMultiplicity = 0

upperMultiplicity = *

OsTimeValue:

EcucFloatParamDef

min = 0

max = INF

OsCounterAccessingApplication:

EcucReferenceDef

upperMultiplicity = *

lowerMultiplicity = 0

GptChannelId:

EcucIntegerParamDef

min = 0

max = 4294967295

symbolicNameValue = true

+parameter

+subContainer

+destination

+parameter

+destination

+parameter

+reference

+literal

+parameter

+reference

+subContainer

+parameter

+literal

Figure 10.6: OsCounter configuration overview

233 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

10.2.14 OsEvent

SWS Item [ECUC_Os_00033]

Container Name

OsEvent

Parent Container

Description

Representation of OS events in the configuration context. Adopted from the ISO

17356-6 specification.

Configuration Parameters

SWS Item [ECUC_Os_00034]

Parameter Name

OsEventMask

Parent Container

OsEvent

Description

If event mask would be set to AUTO in OIL, this parameter should be omitted here.

Multiplicity

0..1

Type

EcucIntegerParamDef

Range 0 .. 18446744073709551615

Default value

–

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: local

No Included Containers

10.2.15 OsDriver

SWS Item [ECUC_Os_00371]

Container Name

OsDriver

Parent Container

OsCounter

Description

This Container contains the information who will drive the counter. This configuration is

only valid if the counter has OsCounterType set to HARDWARE.

If the container does not exist (multiplicity=0) the timer is managed by the OS internally

(OSINTERNAL).

If the container exists the OS can use the GPT interface to manage the timer. The user

have to supply the GPT channel.

If the counter is driven by some other (external to the OS) source (like a TPU for

example) this must be described as a vendor specific extension.

Configuration Parameters

234 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

SWS Item [ECUC_Os_00032]

Parameter Name

OsGptChannelRef

Parent Container

OsDriver

Description

Reference to the GPT channel.

Multiplicity

0..1

Type

Symbolic name reference to GptChannelConfiguration

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

No Included Containers

10.2.16 OsHooks

SWS Item [ECUC_Os_00035]

Container Name

OsHooks

Parent Container

OsOS

Description

Container to structure all hooks belonging to the OS

Configuration Parameters

SWS Item [ECUC_Os_00036]

Parameter Name

OsErrorHook

Parent Container

OsHooks

Description

Error hook as defined by ISO 17356

true: Hook is called false: Hook is not called

Multiplicity

Type

EcucBooleanParamDef

Default value

–

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: local

SWS Item [ECUC_Os_00037]

Parameter Name

OsPostTaskHook

Parent Container

OsHooks

235 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Description

Post-task hook as defined by ISO 17356

true: Hook is called false: Hook is not called

Multiplicity

Type

EcucBooleanParamDef

Default value

–

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: local

SWS Item [ECUC_Os_00038]

Parameter Name

OsPreTaskHook

Parent Container

OsHooks

Description

Pre-task hook as defined by ISO 17356

true: Hook is called false: Hook is not called

Multiplicity

Type

EcucBooleanParamDef

Default value

–

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: local

SWS Item [ECUC_Os_00214]

Parameter Name

OsProtectionHook

Parent Container

OsHooks

Description

Switch to enable/disable the call to the (user supplied) protection hook.

true: Protection hook is called on protection error false: Protection hook is not called

Multiplicity

0..1

Type

EcucBooleanParamDef

Default value

–

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

dependency: Required for scalability class 2,3 and 4

SWS Item [ECUC_Os_00039]

Parameter Name

OsShutdownHook

Parent Container

OsHooks

236 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Description

Shutdown hook as defined by ISO 17356

true: Hook is called false: Hook is not called

Multiplicity

Type

EcucBooleanParamDef

Default value

–

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: local

SWS Item [ECUC_Os_00040]

Parameter Name

OsStartupHook

Parent Container

OsHooks

Description

Startup hook as defined by ISO 17356

true: Hook is called false: Hook is not called

Multiplicity

Type

EcucBooleanParamDef

Default value

–

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: local

SWS Item [ECUC_Os_00402]

Parameter Name

OsMemoryMappingCodeLocationRef

Parent Container

OsHooks

Description

Reference to the memory mapping containing details about the section where the code

is placed.

Multiplicity

0..1

Type

Foreign reference to SW-ADDR-METHOD

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

No Included Containers

237 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

OsOS:

EcucParamConfContainerDef

OsHooks:

EcucParamConfContainerDef

OsStartupHook:

EcucBooleanParamDef

OsErrorHook:

EcucBooleanParamDef

OsShutdownHook:

EcucBooleanParamDef

OsPreTaskHook:

EcucBooleanParamDef

OsPostTaskHook:

EcucBooleanParamDef

OsProtectionHook:

EcucBooleanParamDef

upperMultiplicity = 1

lowerMultiplicity = 0

OsMemoryMappingCodeLocationRef:

EcucForeignReferenceDef

destinationType = SW-ADDR-METHOD

lowerMultiplicity = 0

upperMultiplicity = 1

ARElement

AtpBlueprint

AtpBlueprintable

SwAddrMethod

+ memoryAllocationKeywordPolicy: MemoryAllocationKeywordPolicyType [0..1]

+ option: Identifier [0..*]

+ sectionInitializationPolicy: SectionInitializationPolicyType [0..1]

+ sectionType: MemorySectionType [0..1]

+parameter

+reference

+parameter

+subContainer

+parameter

Figure 10.7: OsHooks configuration overview

10.2.17 OsIsr

SWS Item [ECUC_Os_00041]

Container Name

OsIsr

Parent Container

Description

The OsIsr container represents an ISO 17356 interrupt service routine.

Configuration Parameters

SWS Item [ECUC_Os_00042]

Parameter Name

OsIsrCategory

Parent Container

OsIsr

Description

This attribute specifies the category of this ISR.

Multiplicity

Type

EcucEnumerationParamDef

CATEGORY_1 Interrupt is of category 1

Range

CATEGORY_2 Interrupt is of category 2

238 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: local

SWS Item [ECUC_Os_00403]

Parameter Name

OsIsrPeriod

Parent Container

OsIsr

Description

This parameter specifies the period in seconds of this ISR in case of a cyclically

triggered interrupt.

If this parameter is not given the interrupt can be activated sporadicly or cyclically with

a unknown period value.

This value is information, e.g. for time base calculations in the RTE in case Timing

Events are mapped onto this OsIsr. Be aware, that this parameter is not supposed to

be relevant for the OS! It’s the responsibility of the integrator to ensure the activation of

the ISR according the configured period. This information is given as part of the OS

configuration to support configuration work flows using a fixed set of OsIsrs.

Multiplicity

0..1

Type

EcucFloatParamDef

Range [-INF .. INF]

Default value

–

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

SWS Item [ECUC_Os_00043]

Parameter Name

OsIsrResourceRef

Parent Container

OsIsr

Description

This reference defines the resources accessed by this ISR.

Multiplicity

0..*

Type

Reference to OsResource

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: local

239 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

SWS Item [ECUC_Os_00402]

Parameter Name

OsMemoryMappingCodeLocationRef

Parent Container

OsIsr

Description

Reference to the memory mapping containing details about the section where the code

is placed.

Multiplicity

0..1

Type

Foreign reference to SW-ADDR-METHOD

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

Included Containers

Container Name Multiplicity Scope / Dependency

OsIsrTimingProtection

0..1 This container contains all parameters which are related to

timing protection

If the container exists, the timing protection is used for this

interrupt. If the container does not exist, the interrupt is not

supervised regarding timing violations.

240 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

OsIsr:

EcucParamConfContainerDef

upperMultiplicity = *

lowerMultiplicity = 0

OsIsrCategory:

EcucEnumerationParamDef

OsResource:

EcucParamConfContainerDef

upperMultiplicity = *

lowerMultiplicity = 0

OsIsrResourceLock:

EcucParamConfContainerDef

lowerMultiplicity = 0

upperMultiplicity = *

OsIsrResourceLockResourceRef:

EcucReferenceDef

OsIsrResourceLockBudget:

EcucFloatParamDef

min = 0

max = INF

OsIsrOsInterruptLockBudget:

EcucFloatParamDef

upperMultiplicity = 1

lowerMultiplicity = 0

min = 0

max = INF

OsIsrResourceRef:

EcucReferenceDef

upperMultiplicity = *

lowerMultiplicity = 0

OsIsrAllInterruptLockBudget:

EcucFloatParamDef

upperMultiplicity = 1

lowerMultiplicity = 0

min = 0

max = INF

OsIsrExecutionBudget:

EcucFloatParamDef

upperMultiplicity = 1

lowerMultiplicity = 0

min = 0

max = INF

OsIsrTimeFrame:

EcucFloatParamDef

upperMultiplicity = 1

lowerMultiplicity = 0

min = 0

max = INF

CATEGORY_2:

EcucEnumerationLiteralDef

CATEGORY_1:

EcucEnumerationLiteralDef

OsIsrTimingProtection:

EcucParamConfContainerDef

lowerMultiplicity = 0

upperMultiplicity = 1

OsMemoryMappingCodeLocationRef:

EcucForeignReferenceDef

destinationType = SW-ADDR-METHOD

lowerMultiplicity = 0

upperMultiplicity = 1

OsIsrPeriod: EcucFloatParamDef

lowerMultiplicity = 0

upperMultiplicity = 1

ARElement

AtpBlueprint

AtpBlueprintable

SwAddrMethod

+ memoryAllocationKeywordPolicy: MemoryAllocationKeywordPolicyType [0..1]

+ option: Identifier [0..*]

+ sectionInitializationPolicy: SectionInitializationPolicyType [0..1]

+ sectionType: MemorySectionType [0..1]

+parameter

+destination

+parameter

+subContainer

+literal

+parameter

+reference

+parameter

+destination

+literal

+subContainer

+reference

+parameter

Figure 10.8: OsIsr configuration overview

241 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

10.2.18 OsIsrResourceLock

SWS Item [ECUC_Os_00388]

Container Name

OsIsrResourceLock

Parent Container

OsIsrTimingProtection

Description

This container contains a list of times the interrupt uses resources.

Configuration Parameters

SWS Item [ECUC_Os_00389]

Parameter Name

OsIsrResourceLockBudget

Parent Container

OsIsrResourceLock

Description

This parameter contains the maximum time the interrupt is allowed to hold the given

resource (in seconds).

Multiplicity

Type

EcucFloatParamDef

Range [0 .. INF]

Default value

–

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

dependency: Required for scalability class 2 and 4

SWS Item [ECUC_Os_00390]

Parameter Name

OsIsrResourceLockResourceRef

Parent Container

OsIsrResourceLock

Description

Reference to the resource the locking time is depending on

Multiplicity

Type

Reference to OsResource

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

dependency: Required for scalability class 2 and 4

No Included Containers

10.2.19 OsIsrTimingProtection

SWS Item [ECUC_Os_00326]

Container Name

OsIsrTimingProtection

Parent Container

OsIsr

242 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Description

This container contains all parameters which are related to timing protection

If the container exists, the timing protection is used for this interrupt. If the container

does not exist, the interrupt is not supervised regarding timing violations.

Configuration Parameters

SWS Item [ECUC_Os_00229]

Parameter Name

OsIsrAllInterruptLockBudget

Parent Container

OsIsrTimingProtection

Description

This parameter contains the maximum time for which the ISR is allowed to lock all

interrupts (via SuspendAllInterrupts() or DisableAllInterrupts()) (in seconds).

Multiplicity

0..1

Type

EcucFloatParamDef

Range [0 .. INF]

Default value

–

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

dependency: Required for scalability class 2 and 4

SWS Item [ECUC_Os_00222]

Parameter Name

OsIsrExecutionBudget

Parent Container

OsIsrTimingProtection

Description

The parameter contains the maximum allowed execution time of the interrupt (in

seconds).

Multiplicity

0..1

Type

EcucFloatParamDef

Range [0 .. INF]

Default value

–

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

dependency: Required for scalability class 2 and 4

243 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

SWS Item [ECUC_Os_00387]

Parameter Name

OsIsrOsInterruptLockBudget

Parent Container

OsIsrTimingProtection

Description

This parameter contains the maximum time for which the ISR is allowed to lock all

Category 2 interrupts (via SuspendOSInterrupts()) (in seconds).

Multiplicity

0..1

Type

EcucFloatParamDef

Range [0 .. INF]

Default value

–

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

dependency: Required for scalability class 2 and 4

SWS Item [ECUC_Os_00223]

Parameter Name

OsIsrTimeFrame

Parent Container

OsIsrTimingProtection

Description

This parameter contains the minimum inter-arrival time between successive interrupts

(in seconds).

Multiplicity

0..1

Type

EcucFloatParamDef

Range [0 .. INF]

Default value

–

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

dependency: Required for scalability class 2 and 4

Included Containers

Container Name Multiplicity Scope / Dependency

OsIsrResourceLock

0..*

This container contains a list of times the interrupt uses

resources.

244 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

10.2.20 OsOS

SWS Item [ECUC_Os_00044]

Container Name

OsOS

Parent Container

Description

OS is the object used to define ISO 17356-3 properties for an ISO 17356 application.

Per CPU exactly one OS object has to be defined.

Configuration Parameters

SWS Item [ECUC_Os_01019]

Parameter Name

OsNumberOfCores

Parent Container

OsOS

Description

Maximum number of cores that are controlled by the OS.

The OS uses the value internally. It depends on the ECU HW.

Multiplicity

0..1

Type

EcucIntegerParamDef

Range 1 .. 65535

Default value

–

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: local

SWS Item [ECUC_Os_00259]

Parameter Name

OsScalabilityClass

Parent Container

OsOS

Description

A scalability class for each System Object "OS" has to be selected. In order to

customize the operating system to the needs of the user and to take full advantage of

the processor features the operating system can be scaled according to the scalability

classes.

If the scalability class is omitted this translates to the OIL AUTO mechanism.

Multiplicity

0..1

Type

EcucEnumerationParamDef

SC1

–

SC2

–

SC3

–

Range

SC4

–

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

245 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

SWS Item [ECUC_Os_00307]

Parameter Name

OsStackMonitoring

Parent Container

OsOS

Description

Select stack monitoring of Tasks/Category 2 ISRs

true: Stacks are monitored false: Stacks are not monitored

Multiplicity

Type

EcucBooleanParamDef

Default value

–

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

SWS Item [ECUC_Os_00046]

Parameter Name

OsStatus

Parent Container

OsOS

Description

The Status attribute specifies whether a system with standard or extended status has

to be used. Automatic assignment is not supported for this attribute.

Multiplicity

Type

EcucEnumerationParamDef

EXTENDED –

Range

STANDARD

–

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: local

SWS Item [ECUC_Os_00406]

Parameter Name

OsUseArti

Parent Container

OsOS

Description

The OsUseArti attribute defines whether the OS uses and calls ARTI hooks. This

includes also the generation of related ARTI artifacts by the generator.

Multiplicity

Type

EcucBooleanParamDef

Default value

–

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: local

SWS Item [ECUC_Os_00047]

Parameter Name

OsUseGetServiceId

Parent Container

OsOS

Description

As defined by ISO 17356

Multiplicity

246 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Type

EcucBooleanParamDef

Default value

–

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: local

SWS Item [ECUC_Os_00048]

Parameter Name

OsUseParameterAccess

Parent Container

OsOS

Description

As defined by ISO 17356

Multiplicity

Type

EcucBooleanParamDef

Default value

–

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: local

SWS Item [ECUC_Os_00049]

Parameter Name

OsUseResScheduler

Parent Container

OsOS

Description

The OsUseResScheduler attribute defines whether the resource RES_SCHEDULER is

used within the application.

Multiplicity

Type

EcucBooleanParamDef

Default value

true

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: local

Included Containers

Container Name Multiplicity Scope / Dependency

OsHooks

Container to structure all hooks belonging to the OS

247 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

OsOS:

EcucParamConfContainerDef

OsStatus:

EcucEnumerationParamDef

STANDARD:

EcucEnumerationLiteralDef

EXTENDED:

EcucEnumerationLiteralDef

OsScalabilityClass:

EcucEnumerationParamDef

lowerMultiplicity = 0

SC1:

EcucEnumerationLiteralDef

SC2:

EcucEnumerationLiteralDef

SC3:

EcucEnumerationLiteralDef

SC4:

EcucEnumerationLiteralDef

OsUseResScheduler:

EcucBooleanParamDef

defaultValue = true

OsStackMonitoring:

EcucBooleanParamDef

OsHooks:

EcucParamConfContainerDef

OsUseGetServiceId:

EcucBooleanParamDef

OsUseParameterAccess:

EcucBooleanParamDef

Os: EcucModuleDef

upperMultiplicity = 1

lowerMultiplicity = 0

OsUseArti:

EcucBooleanParamDef

OsNumberOfCores:

EcucIntegerParamDef

min = 1

max = 65535

lowerMultiplicity = 0

upperMultiplicity = 1

+parameter

+subContainer

+literal

+parameter

+literal

+parameter

+container

+literal

+parameter

Figure 10.9: OsOs configuration overview

10.2.21 OsPeripheralArea

SWS Item [ECUC_Os_00397]

Container Name

OsPeripheralArea

Parent Container

Description

Container to structure the configuration parameters of one peripheral area. The

container short name can be used to access this area.

Post-Build Variant Multiplicity

false

Pre-compile time

X All Variants

Link time

–

Multiplicity Configuration Class

Post-build time

–

Configuration Parameters

248 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

SWS Item [ECUC_Os_00400]

Parameter Name

OsPeripheralAreaEndAddress

Parent Container

OsPeripheralArea

Description

Last valid address of a peripheral area.

Multiplicity

Type

EcucIntegerParamDef

Range 0 .. 18446744073709551615

Default value

–

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: local

SWS Item [ECUC_Os_00398]

Parameter Name

OsPeripheralAreaId

Parent Container

OsPeripheralArea

Description

Id of peripheral area.

Multiplicity

Type

EcucIntegerParamDef (Symbolic Name generated for this parameter)

Range 0 .. 18446744073709551615

Default value

–

Post-Build Variant Value

false

Scope / Dependency

scope: local

SWS Item [ECUC_Os_00399]

Parameter Name

OsPeripheralAreaStartAddress

Parent Container

OsPeripheralArea

Description

First valid address of a peripheral area.

Multiplicity

Type

EcucIntegerParamDef

Range 0 .. 18446744073709551615

Default value

–

Post-Build Variant Multiplicity

false

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: local

SWS Item [ECUC_Os_00401]

Parameter Name

OsPeripheralAreaAccessingApplication

Parent Container

OsPeripheralArea

Description

Reference to application which have access to this object.

Multiplicity

0..*

Type

Reference to OsApplication

Post-Build Variant Multiplicity

false

249 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Post-Build Variant Value

false

Scope / Dependency

scope: local

No Included Containers

10.2.22 OsResource

SWS Item [ECUC_Os_00252]

Container Name

OsResource

Parent Container

Description

An OsResource object is used to co-ordinate the concurrent access by tasks and ISRs

to a shared resource, e.g. the scheduler, any program sequence, memory or any

hardware area.

Configuration Parameters

SWS Item [ECUC_Os_00050]

Parameter Name

OsResourceProperty

Parent Container

OsResource

Description

This specifies the type of the resource.

Multiplicity

Type

EcucEnumerationParamDef

INTERNAL The resource is an internal resource.

LINKED

The resource is a linked resource (a second

name for a existing resource).

Range

STANDARD

The resource is a standard resource.

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: local

SWS Item [ECUC_Os_00051]

Parameter Name

OsResourceAccessingApplication

Parent Container

OsResource

Description

Reference to applications which have an access to this object.

Multiplicity

0..*

Type

Reference to OsApplication

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

250 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Scope / Dependency

scope: local

SWS Item [ECUC_Os_00052]

Parameter Name

OsResourceLinkedResourceRef

Parent Container

OsResource

Description

The link to the resource. Must be valid if OsResourceProperty is LINKED. If Os

ResourceProperty is not LINKED the value is ignored.

Multiplicity

0..1

Type

Reference to OsResource

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: local

No Included Containers

OsResource:

EcucParamConfContainerDef

upperMultiplicity = *

lowerMultiplicity = 0

OsResourceProperty:

EcucEnumerationParamDef

STANDARD:

EcucEnumerationLiteralDef

LINKED:

EcucEnumerationLiteralDef

INTERNAL:

EcucEnumerationLiteralDef

OsResourceLinkedResourceRef:

EcucReferenceDef

upperMultiplicity = 1

lowerMultiplicity = 0

OsResourceAccessingApplication:

EcucReferenceDef

upperMultiplicity = *

lowerMultiplicity = 0

OsApplication:

EcucParamConfContainerDef

upperMultiplicity = *

lowerMultiplicity = 0

+literal

+reference

+literal

+parameter

+reference

+destination

+literal

+destination

Figure 10.10: OsResource configuration overview

10.2.23 OsScheduleTable

SWS Item [ECUC_Os_00141]

Container Name

OsScheduleTable

Parent Container

251 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Description

An OsScheduleTable addresses the synchronization issue by providing an

encapsulation of a statically defined set of alarms that cannot be modified at runtime.

Configuration Parameters

SWS Item [ECUC_Os_00053]

Parameter Name

OsScheduleTableDuration

Parent Container

OsScheduleTable

Description

This parameter defines the modulus of the schedule table (in ticks).

Multiplicity

Type

EcucIntegerParamDef

Range 0 .. 18446744073709551615

Default value

–

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: local

SWS Item [ECUC_Os_00144]

Parameter Name

OsScheduleTableRepeating

Parent Container

OsScheduleTable

Description

true: first expiry point on the schedule table shall be processed at final expiry point

delay ticks after the final expiry point is processed.

false: the schedule table processing stops when the final expiry point is processed.

Multiplicity

Type

EcucBooleanParamDef

Default value

–

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

SWS Item [ECUC_Os_00145]

Parameter Name

OsScheduleTableCounterRef

Parent Container

OsScheduleTable

Description

This parameter contains a reference to the counter which drives the schedule table.

Multiplicity

Type

Reference to OsCounter

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

252 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

SWS Item [ECUC_Os_00054]

Parameter Name

OsSchTblAccessingApplication

Parent Container

OsScheduleTable

Description

Reference to applications which have an access to this object.

Multiplicity

0..*

Type

Reference to OsApplication

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: local

Included Containers

Container Name Multiplicity Scope / Dependency

OsScheduleTableAutostart

0..1

This container specifies if and how the schedule table is started

on startup of the Operating System. The options to start a

schedule table correspond to the API calls to start schedule

tables during runtime.

OsScheduleTableExpiryPoint

1..*

The point on a Schedule Table at which the OS activates tasks

and/or sets events

OsScheduleTableSync

0..1

This container specifies the synchronization parameters of the

schedule table.

253 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

OsScheduleTable:

EcucParamConfContainerDef

upperMultiplicity = *

lowerMultiplicity = 0

OsScheduleTableRepeating:

EcucBooleanParamDef

OsScheduleTableExpiryPoint:

EcucParamConfContainerDef

upperMultiplicity = *

lowerMultiplicity = 1

OsEvent:

EcucParamConfCo

upperMultiplic

lowerMultiplici

OsScheduleTableSe

EcucReferenc

OsScheduleTableEventSetting:

EcucParamConfContainerDef

upperMultiplicity = *

lowerMultiplicity = 0

OsScheduleTableTaskActivation:

EcucParamConfContainerDef

upperMultiplicity = *

lowerMultiplicity = 0

OsScheduleTableSync:

EcucParamConfContainerDef

upperMultiplicity = 1

lowerMultiplicity = 0

OsCounter:

EcucParamConfContainerDef

lowerMultiplicity = 0

upperMultiplicity = *

OsScheduleTableCounterRef:

EcucReferenceDef

OsScheduleTableAutostart:

EcucParamConfContainerDef

upperMultiplicity = 1

lowerMultiplicity = 0

OsScheduleTableAppModeRef:

EcucReferenceDef

upperMultiplicity = *

lowerMultiplicity = 1

OsScheduleTableStartValue:

EcucIntegerParamDef

lowerMultiplicity = 0

upperMultiplicity = 1

OsAppMo

EcucParamConfC

upperMultipli

lowerMultipli

OsScheduleTblExpPointOffset:

EcucIntegerParamDef

min = 0

OsScheduleTblAdjustableExpPoint:

EcucParamConfContainerDef

lowerMultiplicity = 0

upperMultiplicity = 1

OsScheduleTableMaxLe

EcucIntegerParam

min = 0

OsScheduleTableMaxSh

EcucIntegerParamD

min = 0

OsScheduleTblSyncStrategy:

EcucEnumerationParamDef

defaultValue = NONE

NONE:

EcucEnumerationL

EXPLICIT:

EcucEnumerationL

IMPLICIT:

EcucEnumerationL

OsScheduleTblExplicitPrecision:

EcucIntegerParamDef

upperMultiplicity = 1

lowerMultiplicity = 0

min = 0

OsScheduleTableAutosta

EcucEnumerationPara

OsScheduleTableDuration:

EcucIntegerParamDef

+reference

+referenc

+destination

+parameter

+subContainer

+literal

+parameter

+subContainer

+parameter

+destination

+parameter

+reference

+parameter

+literal

+destination

+subContainer

+literal

+reference

+parameter

+subContainer

+parameter

+subContainer

Figure 10.11: OsScheduleTable configuration overview

10.2.24 OsScheduleTableAutostart

SWS Item [ECUC_Os_00335]

Container Name

OsScheduleTableAutostart

Parent Container

OsScheduleTable

Description

This container specifies if and how the schedule table is started on startup of the

Operating System. The options to start a schedule table correspond to the API calls to

start schedule tables during runtime.

Configuration Parameters

254 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

SWS Item [ECUC_Os_00056]

Parameter Name

OsScheduleTableAutostartType

Parent Container

OsScheduleTableAutostart

Description

This specifies the type of the autostart for the schedule table.

Multiplicity

Type

EcucEnumerationParamDef

ABSOLUTE

The schedule table is started during startup with

the StartScheduleTableAbs() service.

RELATIVE The schedule table is started during startup with

the StartScheduleTableRel() service.

Range

SYNCHRON

The schedule table is started during startup with

the StartScheduleTableSynchron() service.

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: local

SWS Item [ECUC_Os_00057]

Parameter Name

OsScheduleTableStar tValue

Parent Container

OsScheduleTableAutostart

Description

Absolute autostart tick value when the schedule table starts. Only used if the Os

ScheduleTableAutostartType is ABSOLUTE.

Relative offset in ticks when the schedule table starts. Only used if the OsSchedule

TableAutostartType is RELATIVE.

Multiplicity

0..1

Type

EcucIntegerParamDef

Range 0 .. 18446744073709551615

Default value

–

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

SWS Item [ECUC_Os_00058]

Parameter Name

OsScheduleTableAppModeRef

Parent Container

OsScheduleTableAutostart

Description

Reference in which application modes the schedule table should be started during

startup

Multiplicity

1..*

Type

Reference to OsAppMode

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

255 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Pre-compile time

X All Variants

Link time

–

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

No Included Containers

10.2.25 OsScheduleTableEventSetting

SWS Item [ECUC_Os_00059]

Container Name

OsScheduleTableEventSetting

Parent Container

OsScheduleTableExpiryPoint

Description

Event that is triggered by that schedule table.

Configuration Parameters

SWS Item [ECUC_Os_00060]

Parameter Name

OsScheduleTableSetEventRef

Parent Container

OsScheduleTableEventSetting

Description

Reference to event that will be set by action

Multiplicity

Type

Reference to OsEvent

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: local

SWS Item [ECUC_Os_00061]

Parameter Name

OsScheduleTableSetEventTaskRef

Parent Container

OsScheduleTableEventSetting

Description

–

Multiplicity

Type

Reference to OsTask

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: local

No Included Containers

256 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

10.2.26 OsScheduleTableExpiryPoint

SWS Item [ECUC_Os_00143]

Container Name

OsScheduleTableExpiryPoint

Parent Container

OsScheduleTable

Description

The point on a Schedule Table at which the OS activates tasks and/or sets events

Configuration Parameters

SWS Item [ECUC_Os_00062]

Parameter Name

OsScheduleTblExpPointOffset

Parent Container

OsScheduleTableExpiryPoint

Description

The offset from zero (in ticks) at which the expiry point is to be processed.

Multiplicity

Type

EcucIntegerParamDef

Range 0 .. 18446744073709551615

Default value

–

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

Included Containers

Container Name Multiplicity Scope / Dependency

OsScheduleTableEventSetting

0..* Event that is triggered by that schedule table.

OsScheduleTableTaskActivation

0..* Task that is triggered by that schedule table.

OsScheduleTblAdjustableExpPoint

0..1 Adjustable expiry point

10.2.27 OsScheduleTableTaskActivation

SWS Item [ECUC_Os_00066]

Container Name

OsScheduleTableTaskActivation

Parent Container

OsScheduleTableExpiryPoint

Description

Task that is triggered by that schedule table.

Configuration Parameters

SWS Item [ECUC_Os_00067]

Parameter Name

OsScheduleTableActivateTaskRef

Parent Container

OsScheduleTableTaskActivation

Description

Reference to task that will be activated by action

Multiplicity

Type

Reference to OsTask

Post-Build Variant Value

false

Pre-compile time

X All Variants

Value Configuration Class

Link time

–

257 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Post-build time

–

Scope / Dependency

scope: ECU

No Included Containers

10.2.28 OsScheduleTblAdjustableExpPoint

SWS Item [ECUC_Os_00068]

Container Name

OsScheduleTblAdjustableExpPoint

Parent Container

OsScheduleTableExpiryPoint

Description

Adjustable expiry point

Configuration Parameters

SWS Item [ECUC_Os_00069]

Parameter Name

OsScheduleTableMaxLengthen

Parent Container

OsScheduleTblAdjustableExpPoint

Description

The maximum positive adjustment that can be made to the expiry point offset (in ticks).

Multiplicity

Type

EcucIntegerParamDef

Range 0 .. 18446744073709551615

Default value

–

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: local

SWS Item [ECUC_Os_00070]

Parameter Name

OsScheduleTableMaxShor ten

Parent Container

OsScheduleTblAdjustableExpPoint

Description

The maximum negative adjustment that can be made to the expiry point offset (in ticks).

Multiplicity

Type

EcucIntegerParamDef

Range 0 .. 18446744073709551615

Default value

–

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: local

No Included Containers

258 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

10.2.29 OsScheduleTableSync

SWS Item [ECUC_Os_00063]

Container Name

OsScheduleTableSync

Parent Container

OsScheduleTable

Description

This container specifies the synchronization parameters of the schedule table.

Configuration Parameters

SWS Item [ECUC_Os_00064]

Parameter Name

OsScheduleTblExplicitPrecision

Parent Container

OsScheduleTableSync

Description

This configuration is only valid if the explicit synchronization is used.

Multiplicity

0..1

Type

EcucIntegerParamDef

Range 0 .. 18446744073709551615

Default value

–

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

SWS Item [ECUC_Os_00065]

Parameter Name

OsScheduleTblSyncStrategy

Parent Container

OsScheduleTableSync

Description

AUTOSAR OS provides support for synchronization in two ways: explicit and implicit.

Multiplicity

Type

EcucEnumerationParamDef

EXPLICIT The schedule table is driven by an OS counter

but processing needs to be synchronized with a

different counter which is not an OS counter

object.

IMPLICIT

The counter driving the schedule table is the

counter with which synchronisation is required.

Range

NONE No support for synchronisation.

Default value

NONE

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

No Included Containers

259 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

10.2.30 OsSpinlock

SWS Item [ECUC_Os_00258]

Container Name

OsSpinlock

Parent Container

Description

An OsSpinlock object is used to co-ordinate concurrent access by TASKs/ISR2s on

different cores to a shared resource.

Configuration Parameters

SWS Item [ECUC_Os_01038]

Parameter Name

OsSpinlockLockMethod

Parent Container

OsSpinlock

Description

Lock method which is used when a spinlock is taken. Note that it is possible that a user

(e.g. a Task) might hold more than one spinlock. In this case the last lock taken is

forced to use at least a lock methode which locks as strong as the current one.

Multiplicity

Type

EcucEnumerationParamDef

LOCK_ALL_INTERRUPTS

–

LOCK_CAT2_INTERRUPTS

–

LOCK_NOTHING

–

Range

LOCK_WITH_RES_

SCHEDULER

–

Default value

LOCK_NOTHING

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: local

SWS Item [ECUC_Os_01021]

Parameter Name

OsSpinlockAccessingApplication

Parent Container

OsSpinlock

Description

Reference to OsApplications that have an access to this object.

Multiplicity

1..*

Type

Reference to OsApplication

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: local

SWS Item [ECUC_Os_01022]

Parameter Name

OsSpinlockSuccessor

Parent Container

OsSpinlock

260 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Description

Reference to OsApplications that have an access to this object.

To check whether a spinlock can be occupied (in a nested way) without any danger of

deadlock, a linked list of spinlocks can be defined. A spinlock can only be occupied in

the order of the linked list. It is allowed to skip a spinlock.

If no linked list is specified, spinlocks cannot be nested.

Multiplicity

0..1

Type

Reference to OsSpinlock

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: local

No Included Containers

OsSpinlock:

EcucParamConfContainerDef

lowerMultiplicity = 0

upperMultiplicity = *

OsSpinlockAccessingApplication:

EcucReferenceDef

lowerMultiplicity = 1

upperMultiplicity = *

OsSpinlockSuccessor:

EcucReferenceDef

lowerMultiplicity = 0

upperMultiplicity = 1

OsApplication:

EcucParamConfContainerDef

upperMultiplicity = *

lowerMultiplicity = 0

OsSpinlockLockMethod:

EcucEnumerationParamDef

defaultValue = LOCK_NOTHING

LOCK_ALL_INTERRUPTS:

EcucEnumerationLiteralDef

LOCK_CAT2_INTERRUPTS:

EcucEnumerationLiteralDef

LOCK_WITH_RES_SCHEDULER:

EcucEnumerationLiteralDef

LOCK_NOTHING:

EcucEnumerationLiteralDef

+destination

+parameter

+literal

+reference

+destination

+literal

+reference

Figure 10.12: OsSpinlock configuration overview

10.2.31 OsTask

SWS Item [ECUC_Os_00073]

Container Name

OsTask

Parent Container

Description

This container represents an ISO 17356 task.

Configuration Parameters

261 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

SWS Item [ECUC_Os_00074]

Parameter Name

OsTaskActivation

Parent Container

OsTask

Description

This attribute defines the maximum number of queued activation requests for the task.

A value equal to "1" means that at any time only a single activation is permitted for this

task. Note that the value must be a natural number starting at 1.

Multiplicity

Type

EcucIntegerParamDef

Range 1 .. 4294967295

Default value

–

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: local

SWS Item [ECUC_Os_00404]

Parameter Name

OsTaskPeriod

Parent Container

OsTask

Description

This parameter specifies the period in seconds of this task in case of a cyclically

activated task.

If this parameter is not given the task can be activated sporadicly or cyclically with a

unknown period value.

This value is information, e.g. for time base calculations in the RTE in case Timing

Events are mapped onto this OsTask.Be aware, that this parameter is not supposed to

be relevant for the OS! This information is given as part of the OS configuration to

support configuration work flows using a fixed set of OsTasks.

Multiplicity

0..1

Type

EcucFloatParamDef

Range [-INF .. INF]

Default value

–

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

SWS Item [ECUC_Os_00075]

Parameter Name

OsTaskPriority

Parent Container

OsTask

Description

The priority of a task is defined by the value of this attribute. This value has to be

understood as a relative value, i.e. the values show only the relative ordering of the

tasks.

ISO 17356-3 defines the lowest priority as zero (0); larger values correspond to higher

priorities.

Multiplicity

262 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Type

EcucIntegerParamDef

Range 0 .. 4294967295

Default value

–

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: local

SWS Item [ECUC_Os_00076]

Parameter Name

OsTaskSchedule

Parent Container

OsTask

Description

The OsTaskSchedule attribute defines the preemptability of the task.

If this attribute is set to NON, no internal resources may be assigned to this task.

Multiplicity

Type

EcucEnumerationParamDef

FULL Task is preemptable.

Range

NON

Task is not preemptable.

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: local

SWS Item [ECUC_Os_00402]

Parameter Name

OsMemoryMappingCodeLocationRef

Parent Container

OsTask

Description

Reference to the memory mapping containing details about the section where the code

is placed.

Multiplicity

0..1

Type

Foreign reference to SW-ADDR-METHOD

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

SWS Item [ECUC_Os_00077]

Parameter Name

OsTaskAccessingApplication

Parent Container

OsTask

Description

Reference to applications which have an access to this object.

Multiplicity

0..*

Type

Reference to OsApplication

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

X All Variants

Multiplicity Configuration Class

Link time

–

263 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Post-build time

–

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: local

SWS Item [ECUC_Os_00078]

Parameter Name

OsTaskEventRef

Parent Container

OsTask

Description

This reference defines the list of events the extended task may react on.

Multiplicity

0..*

Type

Reference to OsEvent

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: local

SWS Item [ECUC_Os_00079]

Parameter Name

OsTaskResourceRef

Parent Container

OsTask

Description

This reference defines a list of resources accessed by this task.

Multiplicity

0..*

Type

Reference to OsResource

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: local

Included Containers

Container Name Multiplicity Scope / Dependency

OsTaskAutostart

0..1 This container determines whether the task is activated during

the system start-up procedure or not for some specific

application modes.

If the task shall be activated during the system start-up, this

container is present and holds the references to the application

modes in which the task is auto-started.

OsTaskTimingProtection

0..1 This container contains all parameters regarding timing

protection of the task.

264 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

OsTask:

EcucParamConfContainerDef

upperMultiplicity = *

lowerMultiplicity = 0

OsAppMode:

EcucParamConfContainerDef

upperMultiplicity = *

lowerMultiplicity = 1

OsTaskAppModeRef:

EcucReferenceDef

upperMultiplicity = *

lowerMultiplicity = 1

OsTaskAutostart:

EcucParamConfContainerDef

upperMultiplicity = 1

lowerMultiplicity = 0

OsTaskPriority:

EcucIntegerParamDef

min = 0

max = 4294967295

OsTaskActivation:

EcucIntegerParamDef

min = 1

max = 4294967295

OsTaskSchedule:

EcucEnumerationParamDef

NON:

EcucEnumerationLiteralDef

FULL: EcucEnumerationLiteralDef

OsTaskEventRef:

EcucReferenceDef

upperMultiplicity = *

lowerMultiplicity = 0

OsEvent:

EcucParamConfContainerDef

upperMultiplicity = *

lowerMultiplicity = 0

OsResource:

EcucParamConfContainerDef

upperMultiplicity = *

lowerMultiplicity = 0

OsTaskResourceRef:

EcucReferenceDef

upperMultiplicity = *

lowerMultiplicity = 0

OsTaskExecutionBudget:

EcucFloatParamDef

upperMultiplicity = 1

lowerMultiplicity = 0

min = 0

max = INF

OsTaskTimeFrame:

EcucFloatParamDef

upperMultiplicity = 1

lowerMultiplicity = 0

min = 0

max = INF

OsTaskResourceLock:

EcucParamConfContainerDef

lowerMultiplicity = 0

upperMultiplicity = *

OsTaskResourceLockResourceRef:

EcucReferenceDef

OsTaskResourceLockBudget:

EcucFloatParamDef

min = 0

max = INF

OsTaskOsInterruptLockBudget:

EcucFloatParamDef

upperMultiplicity = 1

lowerMultiplicity = 0

min = 0

max = INF

OsTaskAllInterruptLockBudget:

EcucFloatParamDef

upperMultiplicity = 1

lowerMultiplicity = 0

min = 0

max = INF

OsTaskTimingProtection:

EcucParamConfContainerDef

upperMultiplicity = 1

lowerMultiplicity = 0

OsTaskAccessingApplication:

EcucReferenceDef

upperMultiplicity = *

lowerMultiplicity = 0

OsApplication:

EcucParamConfContainerDef

upperMultiplicity = *

lowerMultiplicity = 0

OsMemoryMappingCodeLocationRef:

EcucForeignReferenceDef

destinationType = SW-ADDR-METHOD

lowerMultiplicity = 0

upperMultiplicity = 1

OsTaskPeriod:

EcucFloatParamDef

lowerMultiplicity = 0

upperMultiplicity = 1

+parameter

+destination

+reference

+destination

+parameter

+destination

+reference

+subContainer

+reference

+parameter

+literal

+parameter

+reference

+destination

+parameter

+literal

+reference

+destination

+parameter

+subContainer

+parameter

+reference

Figure 10.13: OsTask configuration overview

265 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

10.2.32 OsTaskAutostart

SWS Item [ECUC_Os_00080]

Container Name

OsTaskAutostart

Parent Container

OsTask

Description

This container determines whether the task is activated during the system start-up

procedure or not for some specific application modes.

If the task shall be activated during the system start-up, this container is present and

holds the references to the application modes in which the task is auto-started.

Configuration Parameters

SWS Item [ECUC_Os_00081]

Parameter Name

OsTaskAppModeRef

Parent Container

OsTaskAutostart

Description

Reference to application modes in which that task is activated on startup of the OS

Multiplicity

1..*

Type

Reference to OsAppMode

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

No Included Containers

10.2.33 OsTaskResourceLock

SWS Item [ECUC_Os_00082]

Container Name

OsTaskResourceLock

Parent Container

OsTaskTimingProtection

Description

This container contains the worst case time between getting and releasing a given

resource (in seconds).

Configuration Parameters

SWS Item [ECUC_Os_00083]

Parameter Name

OsTaskResourceLockBudget

Parent Container

OsTaskResourceLock

Description

This parameter contains the maximum time the task is allowed to lock the resource (in

seconds)

Multiplicity

Type

EcucFloatParamDef

Range [0 .. INF]

266 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Default value

–

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

dependency: Required for scalability class 2 and 4

SWS Item [ECUC_Os_00084]

Parameter Name

OsTaskResourceLockResourceRef

Parent Container

OsTaskResourceLock

Description

Reference to the resource used by the task

Multiplicity

Type

Reference to OsResource

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

dependency: Required for scalability class 2 and 4

No Included Containers

10.2.34 OsTaskTimingProtection

SWS Item [ECUC_Os_00325]

Container Name

OsTaskTimingProtection

Parent Container

OsTask

Description

This container contains all parameters regarding timing protection of the task.

Configuration Parameters

SWS Item [ECUC_Os_00085]

Parameter Name

OsTaskAllInterruptLockBudget

Parent Container

OsTaskTimingProtection

Description

This parameter contains the maximum time for which the task is allowed to lock all

interrupts (via SuspendAllInterrupts() or DisableAllInterrupts()) (in seconds).

Multiplicity

0..1

Type

EcucFloatParamDef

Range [0 .. INF]

Default value

–

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Multiplicity Configuration Class

Post-build time

–

267 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

dependency: Required for scalability class 2 and 4

SWS Item [ECUC_Os_00185]

Parameter Name

OsTaskExecutionBudget

Parent Container

OsTaskTimingProtection

Description

This parameter contains the maximum allowed execution time of the task (in seconds).

Multiplicity

0..1

Type

EcucFloatParamDef

Range [0 .. INF]

Default value

–

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

dependency: Required for scalability class 2 and 4

SWS Item [ECUC_Os_00086]

Parameter Name

OsTaskOsInterruptLockBudget

Parent Container

OsTaskTimingProtection

Description

This parameter contains the maximum time for which the task is allowed to lock all

Category 2 interrupts (via SuspendOSInterrupts()) (in seconds).

Multiplicity

0..1

Type

EcucFloatParamDef

Range [0 .. INF]

Default value

–

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

dependency: Required for scalability class 2 and 4

268 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

SWS Item [ECUC_Os_00391]

Parameter Name

OsTaskTimeFrame

Parent Container

OsTaskTimingProtection

Description

The minimum inter-arrival time between activations and/or releases of a task (in

seconds).

Multiplicity

0..1

Type

EcucFloatParamDef

Range [0 .. INF]

Default value

–

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

dependency: Only available in scalability class 2 and 4

Included Containers

Container Name Multiplicity Scope / Dependency

OsTaskResourceLock

0..* This container contains the worst case time between getting and

releasing a given resource (in seconds).

10.2.35 OsTimeConstant

SWS Item [ECUC_Os_00386]

Container Name

OsTimeConstant

Parent Container

OsCounter

Description

Allows the user to define constants which can be e.g. used to compare time values with

timer tick values.

A time value will be converted to a timer tick value during generation and can later on

accessed via the OsConstName. The conversation is done by rounding time values to

the nearest fitting tick value.

Configuration Parameters

SWS Item [ECUC_Os_00002]

Parameter Name

OsTimeValue

Parent Container

OsTimeConstant

Description

This parameter contains the value of the constant in seconds.

Multiplicity

Type

EcucFloatParamDef

Range [0 .. INF]

Default value

–

Post-Build Variant Value

false

269 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

No Included Containers

10.3 Containers and configuration parameter extensions of the

IOC

This section describes the content of the IOC Configuration Description that is needed

for the generation of the IOC API.

OsIoc:

EcucParamConfContainerDef

lowerMultiplicity = 0

upperMultiplicity = 1

OsIocCommunication:

EcucParamConfContainerDef

lowerMultiplicity = 0

upperMultiplicity = *

OsIocDataTypeRef: EcucForeignReferenceDef

destinationType = IMPLEMENTATION-DATA-TYPE

lowerMultiplicity = 1

upperMultiplicity = 1

OsIocSendingOsApplicationRef:

EcucReferenceDef

lowerMultiplicity = 1

upperMultiplicity = 1

OsIocReceivingOsApplicationRef:

EcucReferenceDef

lowerMultiplicity = 1

upperMultiplicity = 1

OsIocSenderId:

EcucIntegerParamDef

min = 0

max = 255

lowerMultiplicity = 0

upperMultiplicity = 1

OsApplication:

EcucParamConfContainerDef

upperMultiplicity = *

lowerMultiplicity = 0

OsIocBufferLength:

EcucIntegerParamDef

max = 4294967295

upperMultiplicity = 1

lowerMultiplicity = 0

OsIocReceiverPullCB:

EcucFunctionNameDef

lowerMultiplicity = 0

upperMultiplicity = 1

Os: EcucModuleDef

upperMultiplicity = 1

lowerMultiplicity = 0

OsIocSenderProperties:

EcucParamConfContainerDef

lowerMultiplicity = 1

upperMultiplicity = *

OsIocReceiverProperties:

EcucParamConfContainerDef

lowerMultiplicity = 1

upperMultiplicity = *

OsIocDataProperties:

EcucParamConfContainerDef

lowerMultiplicity = 1

upperMultiplicity = *

OsIocInitValue:

EcucStringParamDef

lowerMultiplicity = 0

upperMultiplicity = 1

OsIocDataPropertyIndex:

EcucIntegerParamDef

max = 255

upperMultiplicity = 1

lowerMultiplicity = 0

FUNCTION:

EcucEnumerationLiteralDef

MACRO:

EcucEnumerationLiteralDef

OsIocFunctionImplementationKind:

EcucEnumerationParamDef

lowerMultiplicity = 0

upperMultiplicity = 1

defaultValue = DO_NOT_CARE

OsMemoryMappingCodeLocationRef:

EcucForeignReferenceDef

destinationType = SW-ADDR-METHOD

lowerMultiplicity = 0

upperMultiplicity = 1

DO_NOT_CARE:

EcucEnumerationLiteralDef

OsIocReceiverId:

EcucIntegerParamDef

min = 0

max = 255

lowerMultiplicity = 0

upperMultiplicity = 1

+reference

+parameter

+subContainer

+parameter

+container

+reference

+parameter

+destination

+parameter

+subContainer

+parameter

+subContainer

+parameter

+literal

+parameter

+subContainer

+reference

+literal

+parameter

+container

+literal

Figure 10.14: OsIoc configuration overview

270 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

10.3.1 OsIoc

SWS Item [ECUC_Os_01000]

Container Name

OsIoc

Parent Container

Description

Configuration of the IOC (Inter OS Application Communicator).

Configuration Parameters

Included Containers

Container Name Multiplicity Scope / Dependency

OsIocCommunication

0..*

Representation of a 1:1 or N:1 or N:M (unqueued only)

communication between software parts located in different

OS-Applications that are bound to the same or to different cores.

The name shall begin with the name of the sending software

service and be followed by a unique identifier delivered by the

sending software service. In the case of RTE as user attention

shall be paid on the fact that uniqueness for identifier names has

to be reached over ports, data elements, object instances and

maybe additional identification properties (E.g. Case 1:N

mapping to 1:1). Example:

• <NameSpace>_UniqueID

10.3.2 OsIocCommunication

SWS Item [ECUC_Os_01003]

Container Name

OsIocCommunication

Parent Container

OsIoc

Description

Representation of a 1:1 or N:1 or N:M (unqueued only) communication between

software parts located in different OS-Applications that are bound to the same or to

different cores. The name shall begin with the name of the sending software service

and be followed by a unique identifier delivered by the sending software service. In the

case of RTE as user attention shall be paid on the fact that uniqueness for identifier

names has to be reached over ports, data elements, object instances and maybe

additional identification properties (E.g. Case 1:N mapping to 1:1). Example:

• <NameSpace>_UniqueID

Configuration Parameters

SWS Item [ECUC_Os_01001]

Parameter Name

OsIocBufferLength

Parent Container

OsIocCommunication

Description

This attribute defines the size of the IOC internal queue to be allocated for a queued

communication.

This configuration information shall allow the optimization of the needed memory for

communications requiring buffers within the RTE and within the IOC.

Multiplicity

0..1

Type

EcucIntegerParamDef

Range 0 .. 4294967295

Default value

–

Post-Build Variant Multiplicity

false

271 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: local

Included Containers

Container Name Multiplicity Scope / Dependency

OsIocDataProperties

1..*

Data properties of the data to be transferred on the IOC

communication channel.

OsIocReceiverProperties

1..*

Representation of receiver properties for one communication.

For each OsIocCommunication one (1:1) or many receivers

(N:M) have to be defined. This container should be instantiated

within an OsIocCommunication.

OsIocSenderProperties

1..*

Representation of sender properties for one communication. For

each OsIocCommunication one (1:1) or many senders (N:1 or

N:M) have to be defined. Multiplicity > 1 (N:1 or N:M

communication) is only allowed for Multiplicity of OsIocDataType

Ref = 1.

This container should be instantiated within an OsIoc

Communication.

10.3.3 OsIocSenderProperties

SWS Item [ECUC_Os_01015]

Container Name

OsIocSenderProperties

Parent Container

OsIocCommunication

Description

Representation of sender properties for one communication. For each OsIoc

Communication one (1:1) or many senders (N:1 or N:M) have to be defined. Multiplicity

> 1 (N:1 or N:M communication) is only allowed for Multiplicity of OsIocDataTypeRef =

This container should be instantiated within an OsIocCommunication.

Configuration Parameters

SWS Item [ECUC_Os_01036]

Parameter Name

OsIocFunctionImplementationKind

Parent Container

OsIocSenderProperties

Description

This parameter is used to select whether this communication is implemented as a

macro or as a function.

Multiplicity

0..1

Type

EcucEnumerationParamDef

DO_NOT_CARE It is not defined whether a macro or a function is

used.

FUNCTION Communication is implemented as a function

Range

MACRO Communication is implemented as a macro

272 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Default value

DO_NOT_CARE

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: local

SWS Item [ECUC_Os_01016]

Parameter Name

OsIocSenderId

Parent Container

OsIocSenderProperties

Description

Representation of a sender in a N:1 or N:M communication to distinguish between

senders.

This parameter does not exist in 1:1 communication.

Multiplicity

0..1

Type

EcucIntegerParamDef

Range 0 .. 255

Default value

–

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

SWS Item [ECUC_Os_01014]

Parameter Name

OsIocSendingOsApplicationRef

Parent Container

OsIocSenderProperties

Description

This attribute is a reference to the sending OS-Application instance defined in the

configuration file of the OS.

This information shall allows the generator to get additional information necessary for

the code generation like:

• The protection properties of the communicating OS-Applications to find out

which protection boundaries have to be crossed.

• The core identifiers to find out if an intra or an inter core communication has to

be realized

• Interrupt details in case of cross core notification to realize over IRQs

Multiplicity

Type

Reference to OsApplication

Post-Build Variant Value

false

Pre-compile time

X All Variants

Value Configuration Class

Link time

–

273 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Post-build time

–

Scope / Dependency

scope: local

No Included Containers

10.3.4 OsIocReceiverProperties

SWS Item [ECUC_Os_01017]

Container Name

OsIocReceiverProperties

Parent Container

OsIocCommunication

Description

Representation of receiver properties for one communication. For each OsIoc

Communication one (1:1) or many receivers (N:M) have to be defined. This container

should be instantiated within an OsIocCommunication.

Configuration Parameters

SWS Item [ECUC_Os_01037]

Parameter Name

OsIocFunctionImplementationKind

Parent Container

OsIocReceiverProperties

Description

This parameter is used to select whether this communication is implemented as a

macro or as a function.

Multiplicity

0..1

Type

EcucEnumerationParamDef

DO_NOT_CARE It is not defined whether a macro or a function is

used.

FUNCTION Communication is implemented as a function

Range

MACRO Communication is implemented as a macro

Default value

DO_NOT_CARE

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: local

SWS Item [ECUC_Os_00407]

Parameter Name

OsIocReceiverId

Parent Container

OsIocReceiverProperties

Description

Representation of a receiver in a N:M communication to distinguish between receivers.

This parameter does not exist in 1:1 or N:1 communication.

Multiplicity

0..1

Type

EcucIntegerParamDef

Range 0 .. 255

274 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Default value

–

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

SWS Item [ECUC_Os_01010]

Parameter Name

OsIocReceiverPullCB

Parent Container

OsIocReceiverProperties

Description

This attribute defines the name of a callback function that the IOC shall call on the

receiving core for each data reception.

In case of non existence of this attribute no ReceiverPullCB notification shall be applied

by the IOC. The name of the function shall begin with the name of the receiving

module, followed with a callback name and followed by the IocId.

Example: void RTE_ReceiverPullCB_RTE25 (void).

If this attribute does not exist, it means that no ReceiverPullCB shall be called (No

notification from IOC is required). If this attribute exists the IOC shall call the callback

function on the receiving core.

Multiplicity

0..1

Type

EcucFunctionNameDef

Default value

–

Regular Expression

–

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: local

SWS Item [ECUC_Os_01012]

Parameter Name

OsIocReceivingOsApplicationRef

Parent Container

OsIocReceiverProperties

275 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Description

This attribute is a reference to the receiving OsApplication instance defined in the

configuration file of the OS.

This information allows for the generator to get additional information necessary for the

code generation like:

• The protection properties of the communicating OsApplications to find out

which protections have to be crossed

• The core identifiers to find out if an intra or an inter core communication has to

be realized

• Interrupt details in case of cross core notification to realize over IRQs

Multiplicity

Type

Reference to OsApplication

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: local

No Included Containers

10.3.5 OsIocDataProperties

SWS Item [ECUC_Os_01023]

Container Name

OsIocDataProperties

Parent Container

OsIocCommunication

Description

Data properties of the data to be transferred on the IOC communication channel.

Configuration Parameters

SWS Item [ECUC_Os_01035]

Parameter Name

OsIocDataPropertyIndex

Parent Container

OsIocDataProperties

Description

This parameter is used to define in which order the data is send, e.g. whether IocSend

Group(A,B) or IocSendGroup(B,A) shall be used.

Multiplicity

0..1

Type

EcucIntegerParamDef

Range 0 .. 255

Default value

–

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: local

276 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

SWS Item [ECUC_Os_01024]

Parameter Name

OsIocInitValue

Parent Container

OsIocDataProperties

Description

Initial Value for the data to be transferred on the IOC communication channel.

Multiplicity

0..1

Type

EcucStringParamDef

Default value

–

Regular Expression

–

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: local

SWS Item [ECUC_Os_01005]

Parameter Name

OsIocDataTypeRef

Parent Container

OsIocDataProperties

Description

This is the type of the data to be transferred on the IOC communication channel. This

attribute is necessary to generate the parameter type of the Ioc functions. Additionally

this information should be used to compute the data size for necessary data copy

operations within the Ioc module.

If more than one attribute is defined, the IOC generator should generate an IocXxx

Group function (Xxx= CHOICE [Send, Receive, Write, Read]).

N:1 or N:M communication (Multiplicity of OsIocSenderProperties > 1) is only allowed

for multiplicity of OsIocDataTypeRef = 1

Multiplicity

Type

Foreign reference to IMPLEMENTATION-DATA-TYPE

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: local

SWS Item [ECUC_Os_00405]

Parameter Name

OsMemoryMappingCodeLocationRef

Parent Container

OsIocDataProperties

Description

Reference to the memory mapping containing details about the section where the IOC

buffer is placed.

Multiplicity

0..1

Type

Foreign reference to SW-ADDR-METHOD

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

X All Variants

Multiplicity Configuration Class

Link time

–

277 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Post-build time

–

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

No Included Containers

10.4 Containers and configuration parameters for ARTI

This section describes the structure (containers) and the parameters of ARTI objects

related to the OS configuration. ARTI objects are defined by the MOD_ARTI model.

For a detailed description of the referenced ARTI parameters, please see chapter 10

of [9]. Also refer to application note 12.7 of this document.

10.4.1 ArtiHardware

SWS Item [ECUC_Arti_00061]

Container Name

ArtiHardware

Parent Container

Arti

Description

The ArtiHardware container contains ARTI extensions to the EcucHardware module.

Post-Build Variant Multiplicity

true

Pre-compile time

VARIANT-PRE-COMPILE

Link time

–

Multiplicity Configuration Class

Post-build time

VARIANT-POST-BUILD

Configuration Parameters

Included Containers

Container Name Multiplicity Scope / Dependency

ArtiHardwareCoreClass

0..1

Contains the layout of an ARTI "Core" object, extending the Ecuc

CoreDefinition.

ArtiHardwareCoreInstance

0..*

Description: Represents an instance of an ARTI "Core" object,

extending the EcucCoreDefinition. When using ARTI for

debugging or hardware based tracing, this is mandatory (i.e.

multiplicity 1..*), else optional.

<ECUC-MODULE-CONFIGURATION-VALUES>

<SHORT-NAME>Vendor1ArtiHardware</SHORT-NAME>

<DEFINITION-REF DEST="ECUC-MODULE-DEF">

/AUTOSAR/Arti/ArtiHardware</DEFINITION-REF>

<ECUC-CONTAINER-VALUE>

<SHORT-NAME>ArtiCoreClass</SHORT-NAME>

<DEFINITION-REF DEST="ECUC-PARAM-CONF-CONTAINER-DEF">

/AUTOSAR/Arti/ArtiHardware/ArtiHardwareCoreClass</DEFINITION-REF>

<...>

278 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

</ECUC-CONTAINER-VALUE>

<ECUC-CONTAINER-VALUE>

<SHORT-NAME>ArtiCore0</SHORT-NAME>

<DEFINITION-REF DEST="ECUC-PARAM-CONF-CONTAINER-DEF">

/AUTOSAR/Arti/ArtiHardware/ArtiHardwareCoreInstance</DEFINITION-REF>

<...>

</ECUC-CONTAINER-VALUE>

<ECUC-CONTAINER-VALUE>

<SHORT-NAME>ArtiCore1</SHORT-NAME>

<DEFINITION-REF DEST="ECUC-PARAM-CONF-CONTAINER-DEF">

/AUTOSAR/Arti/ArtiHardware/ArtiHardwareCoreInstance</DEFINITION-REF>

<...>

</ECUC-CONTAINER-VALUE>

</CONTAINERS>

</ECUC-MODULE-CONFIGURATION-VALUES>

10.4.2 ArtiHardwareCoreClass

SWS Item [ECUC_Arti_00062]

Container Name

ArtiHardwareCoreClass

Parent Container

ArtiHardware

Description

Contains the layout of an ARTI "Core" object, extending the EcucCoreDefinition.

Post-Build Variant Multiplicity

true

Pre-compile time

VARIANT-PRE-COMPILE

Link time

–

Multiplicity Configuration Class

Post-build time

VARIANT-POST-BUILD

Configuration Parameters

SWS Item [ECUC_Arti_00054]

Parameter Name

ArtiHardwareCoreClassCurrentApplicationRef

Parent Container

ArtiHardwareCoreClass

Description

Refers to the ArtiObjectClassParameter that defines the ArtiCurrentApplicationInstance

parameter.

Multiplicity

0..1

Type

Reference to ArtiObjectClassParameter

Post-Build Variant Multiplicity

true

Post-Build Variant Value

true

Pre-compile time

VARIANT-PRE-COMPILE

Link time

–

Multiplicity Configuration Class

Post-build time

VARIANT-POST-BUILD

Pre-compile time

VARIANT-PRE-COMPILE

Link time

–

Value Configuration Class

Post-build time

VARIANT-POST-BUILD

Scope / Dependency

scope: ECU

279 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

SWS Item [ECUC_Arti_00056]

Parameter Name

ArtiHardwareCoreClassCurrentIsrRef

Parent Container

ArtiHardwareCoreClass

Description

Refers to the ArtiObjectClassParameter that defines the ArtiCurrentIsrInstance

parameter.

Multiplicity

0..1

Type

Reference to ArtiObjectClassParameter

Post-Build Variant Value

true

Pre-compile time

VARIANT-PRE-COMPILE

Link time

–

Value Configuration Class

Post-build time

VARIANT-POST-BUILD

Scope / Dependency

scope: ECU

SWS Item [ECUC_Arti_00058]

Parameter Name

ArtiHardwareCoreClassCurrentTaskRef

Parent Container

ArtiHardwareCoreClass

Description

Refers to the ArtiObjectClassParameter that defines the ArtiCurrentTaskInstance

parameter.

Multiplicity

Type

Reference to ArtiObjectClassParameter

Post-Build Variant Value

true

Pre-compile time

VARIANT-PRE-COMPILE

Link time

–

Value Configuration Class

Post-build time

VARIANT-POST-BUILD

Scope / Dependency

scope: ECU

SWS Item [ECUC_Arti_00064]

Parameter Name

ArtiHardwareCoreClassGenericComponentRef

Parent Container

ArtiHardwareCoreClass

Description

Refers to an ArtiGenericComponentClass that extends the core description.

Multiplicity

0..1

Type

Reference to ArtiGenericComponentClass

Post-Build Variant Multiplicity

true

Post-Build Variant Value

true

Pre-compile time

VARIANT-PRE-COMPILE

Link time

–

Multiplicity Configuration Class

Post-build time

VARIANT-POST-BUILD

Pre-compile time

VARIANT-PRE-COMPILE

Link time

–

Value Configuration Class

Post-build time

VARIANT-POST-BUILD

Scope / Dependency

scope: ECU

SWS Item [ECUC_Arti_00066]

Parameter Name

ArtiHardwareCoreClassLastErrorRef

Parent Container

ArtiHardwareCoreClass

Description

Refers to the ArtiObjectClassParameter that defines the ArtiLastErrorInstance

parameter.

Multiplicity

0..1

280 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Type

Reference to ArtiObjectClassParameter

Post-Build Variant Multiplicity

true

Post-Build Variant Value

true

Pre-compile time

VARIANT-PRE-COMPILE

Link time

–

Multiplicity Configuration Class

Post-build time

VARIANT-POST-BUILD

Pre-compile time

VARIANT-PRE-COMPILE

Link time

–

Value Configuration Class

Post-build time

VARIANT-POST-BUILD

Scope / Dependency

scope: ECU

SWS Item [ECUC_Arti_00094]

Parameter Name

ArtiHardwareCoreClassRunningTaskPriorityRef

Parent Container

ArtiHardwareCoreClass

Description

Refers to the ArtiObjectClassParameter that defines the ArtiHwCoreInstanceRunning

TaskPriority parameter. This attribute specifies how to evaluate the current priority of

the task referred by RUNNINGTASK. The current priority can be different from the

static task priority as a result of priority ceiling protocol. This attribute differs from Arti

CurrentTask->ArtiOsTaskClassPriority as here is a single variable while in multiple

tasks there is a single variable per task.

Multiplicity

0..1

Type

Reference to ArtiObjectClassParameter

Post-Build Variant Multiplicity

true

Post-Build Variant Value

true

Pre-compile time

VARIANT-PRE-COMPILE

Link time

–

Multiplicity Configuration Class

Post-build time

VARIANT-POST-BUILD

Pre-compile time

VARIANT-PRE-COMPILE

Link time

–

Value Configuration Class

Post-build time

VARIANT-POST-BUILD

Scope / Dependency

scope: ECU

No Included Containers

<ECUC-CONTAINER-VALUE>

<SHORT-NAME>ArtiCoreClass</SHORT-NAME>

<DEFINITION-REF DEST="ECUC-PARAM-CONF-CONTAINER-DEF">/AUTOSAR/Arti/

ArtiHardware/ArtiHardwareCoreClass</DEFINITION-REF>

<REFERENCE-VALUES>

<ECUC-REFERENCE-VALUE>

<DEFINITION-REF DEST="ECUC-REFERENCE-DEF">/AUTOSAR/Arti/

ArtiHardware/ArtiHardwareCoreClass/

ArtiHardwareCoreClassCurrentApplicationRef</DEFINITION-REF>

<VALUE-REF DEST="ECUC-CONTAINER-VALUE">/Vendor1/Vendor1Arti/

ArtiObjectClassParameter_ArtiHwCore_CurrentApplication

</VALUE-REF>

</ECUC-REFERENCE-VALUE>

<ECUC-REFERENCE-VALUE>

<DEFINITION-REF DEST="ECUC-REFERENCE-DEF">/AUTOSAR/Arti/

ArtiHardware/ArtiHardwareCoreClass/

ArtiHardwareCoreClassCurrentTaskRef</DEFINITION-REF>

<VALUE-REF DEST="ECUC-CONTAINER-VALUE">/Vendor1/Vendor1Arti/

281 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

ArtiObjectClassParameter_ArtiHwCore_CurrentTask</VALUE-REF>

</ECUC-REFERENCE-VALUE>

</REFERENCE-VALUES>

</ECUC-CONTAINER-VALUE>

10.4.3 ArtiHardwareCoreInstance

SWS Item [ECUC_Arti_00063]

Container Name

ArtiHardwareCoreInstance

Parent Container

ArtiHardware

Description

Description: Represents an instance of an ARTI "Core" object, extending the EcucCore

Definition. When using ARTI for debugging or hardware based tracing, this is

mandatory (i.e. multiplicity 1..*), else optional.

Post-Build Variant Multiplicity

true

Pre-compile time

VARIANT-PRE-COMPILE

Link time

–

Multiplicity Configuration Class

Post-build time

VARIANT-POST-BUILD

Configuration Parameters

SWS Item [ECUC_Arti_00091]

Parameter Name

ArtiHardwareCoreInstanceCoreId

Parent Container

ArtiHardwareCoreInstance

Description

This parameter represents the "CoreID" as given by the OS, returned by GetCoreID().

Multiplicity

Type

EcucIntegerParamDef

Range 0 .. 18446744073709551615

Default value

–

Post-Build Variant Value

true

Pre-compile time

VARIANT-PRE-COMPILE

Link time

–

Value Configuration Class

Post-build time

VARIANT-POST-BUILD

Scope / Dependency

scope: ECU

SWS Item [ECUC_Arti_00055]

Parameter Name

ArtiHardwareCoreInstanceCurrentApplicationRef

Parent Container

ArtiHardwareCoreInstance

Description

Refers to the ArtiObjectInstanceParameter that contains the evaluation for the "current

application" that is running on this core.

Multiplicity

Type

Reference to ArtiObjectInstanceParameter

Post-Build Variant Value

true

Pre-compile time

VARIANT-PRE-COMPILE

Link time

–

Value Configuration Class

Post-build time

VARIANT-POST-BUILD

Scope / Dependency

scope: ECU

282 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

SWS Item [ECUC_Arti_00057]

Parameter Name

ArtiHardwareCoreInstanceCurrentIsrRef

Parent Container

ArtiHardwareCoreInstance

Description

Refers to the ArtiObjectInstanceParameter that contains the evaluation for the "current

ISR" that is running on this core.

Multiplicity

0..1

Type

Reference to ArtiObjectInstanceParameter

Post-Build Variant Multiplicity

true

Post-Build Variant Value

true

Pre-compile time

VARIANT-PRE-COMPILE

Link time

–

Multiplicity Configuration Class

Post-build time

VARIANT-POST-BUILD

Pre-compile time

VARIANT-PRE-COMPILE

Link time

–

Value Configuration Class

Post-build time

VARIANT-POST-BUILD

Scope / Dependency

scope: ECU

SWS Item [ECUC_Arti_00059]

Parameter Name

ArtiHardwareCoreInstanceCurrentTaskRef

Parent Container

ArtiHardwareCoreInstance

Description

Refers to the ArtiObjectInstanceParameter that contains the evaluation for the "current

task" that is running on this core.

Multiplicity

Type

Reference to ArtiObjectInstanceParameter

Post-Build Variant Value

true

Pre-compile time

VARIANT-PRE-COMPILE

Link time

–

Value Configuration Class

Post-build time

VARIANT-POST-BUILD

Scope / Dependency

scope: ECU

SWS Item [ECUC_Arti_00060]

Parameter Name

ArtiHardwareCoreInstanceEcucCoreRef

Parent Container

ArtiHardwareCoreInstance

Description

Refers to the EcucCoreDefinition of this core.

Multiplicity

Type

Reference to EcucCoreDefinition

Post-Build Variant Value

true

Pre-compile time

VARIANT-PRE-COMPILE

Link time

–

Value Configuration Class

Post-build time

VARIANT-POST-BUILD

Scope / Dependency

scope: ECU

SWS Item [ECUC_Arti_00065]

Parameter Name

ArtiHardwareCoreInstanceGenericComponentRef

Parent Container

ArtiHardwareCoreInstance

Description

Refers to an ArtiGenericComponentInstance that extends a core.

Multiplicity

0..1

Type

Reference to ArtiGenericComponentInstance

283 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Post-Build Variant Multiplicity

true

Post-Build Variant Value

true

Pre-compile time

VARIANT-PRE-COMPILE

Link time

–

Multiplicity Configuration Class

Post-build time

VARIANT-POST-BUILD

Pre-compile time

VARIANT-PRE-COMPILE

Link time

–

Value Configuration Class

Post-build time

VARIANT-POST-BUILD

Scope / Dependency

scope: ECU

SWS Item [ECUC_Arti_00067]

Parameter Name

ArtiHardwareCoreInstanceLastErrorRef

Parent Container

ArtiHardwareCoreInstance

Description

Refers to the ArtiObjectInstanceParameter that contains the evaluation for the "last

error" that happened on this core.

Multiplicity

0..1

Type

Reference to ArtiObjectInstanceParameter

Post-Build Variant Multiplicity

true

Post-Build Variant Value

true

Pre-compile time

VARIANT-PRE-COMPILE

Link time

–

Multiplicity Configuration Class

Post-build time

VARIANT-POST-BUILD

Pre-compile time

VARIANT-PRE-COMPILE

Link time

–

Value Configuration Class

Post-build time

VARIANT-POST-BUILD

Scope / Dependency

scope: ECU

SWS Item [ECUC_Arti_00095]

Parameter Name

ArtiHardwareCoreInstanceRunningTaskPriorityRef

Parent Container

ArtiHardwareCoreInstance

Description

Refers to the ArtiObjectInstanceParameter that contains the evaluation for the "running

task priority" that is on this core.

Multiplicity

0..1

Type

Reference to ArtiObjectInstanceParameter

Post-Build Variant Multiplicity

true

Post-Build Variant Value

true

Pre-compile time

VARIANT-PRE-COMPILE

Link time

–

Multiplicity Configuration Class

Post-build time

VARIANT-POST-BUILD

Pre-compile time

VARIANT-PRE-COMPILE

Link time

–

Value Configuration Class

Post-build time

VARIANT-POST-BUILD

Scope / Dependency

scope: ECU

SWS Item [ECUC_Arti_00096]

Parameter Name

ArtiHardwareCoreInstanceValidRef

Parent Container

ArtiHardwareCoreInstance

284 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Description

Refers to the ArtiObjectInstanceParameter that contains the evaluation for the "validity"

of this ArtiHwCoreInstance. Ever y object declaration may contain a VALID attribute

telling the debugger whether the object’s attributes are currently valid. It may have an

integer type of any size. Its possible values are 0 (invalid) and non zero (object is valid).

Multiplicity

0..1

Type

Reference to ArtiObjectInstanceParameter

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

No Included Containers

<ECUC-CONTAINER-VALUE>

<SHORT-NAME>ArtiCore0</SHORT-NAME>

<DEFINITION-REF DEST="ECUC-PARAM-CONF-CONTAINER-DEF">/AUTOSAR/Arti/

ArtiHardware/ArtiHardwareCoreInstance</DEFINITION-REF>

<REFERENCE-VALUES>

<ECUC-REFERENCE-VALUE>

<DEFINITION-REF DEST="ECUC-REFERENCE-DEF">/AUTOSAR/Arti/

ArtiHardware/ArtiHardwareCoreInstance/

ArtiHardwareCoreInstanceCurrentApplicationRef</DEFINITION-REF>

<VALUE-REF DEST="ECUC-CONTAINER-VALUE">/Vendor1/Vendor1Arti/

ArtiObjectInstanceParameter_CurrentApplicationOnCore0

</VALUE-REF>

</ECUC-REFERENCE-VALUE>

<ECUC-REFERENCE-VALUE>

<DEFINITION-REF DEST="ECUC-REFERENCE-DEF">/AUTOSAR/Arti/

ArtiHardware/ArtiHardwareCoreInstance/

ArtiHardwareInstanceCurrentTaskRef</DEFINITION-REF>

<VALUE-REF DEST="ECUC-CONTAINER-VALUE">/Vendor1/Vendor1Arti/

ArtiObjectInstanceParameter_CurrentTaskOnCore0</VALUE-REF>

</ECUC-REFERENCE-VALUE>

<ECUC-REFERENCE-VALUE>

<DEFINITION-REF DEST="ECUC-REFERENCE-DEF">/AUTOSAR/Arti/

ArtiHardware/ArtiHardwareCoreInstance/

ArtiHardwareCoreInstanceEcucCoreRef</DEFINITION-REF>

<VALUE-REF DEST="ECUC-CONTAINER-VALUE">

/Vendor1/Vendor1EcucEcuC/Hardware/Core0</VALUE-REF>

</ECUC-REFERENCE-VALUE>

</REFERENCE-VALUES>

</ECUC-CONTAINER-VALUE>

285 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

10.4.4 ArtiOs

SWS Item [ECUC_Arti_00071]

Container Name

ArtiOs

Parent Container

Arti

Description

The ArtiOs container contains ARTI extensions to the EcucDefs/Os module.

Post-Build Variant Multiplicity

true

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Configuration Parameters

SWS Item [ECUC_Arti_00178]

Parameter Name

ArtiOsGenericComponentRef

Parent Container

ArtiOs

Description

Refers to an ArtiGenericComponentClass that relates to the OS.

Multiplicity

0..*

Type

Reference to ArtiGenericComponentClass

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

Included Containers

Container Name Multiplicity Scope / Dependency

ArtiOsAlarmClass

0..1

Contains the layout of an ArtiOsAlarm object.

ArtiOsAlarmInstance

0..*

Represents an instance of an ArtiOsAlarm object, extending the

EcuC OsTaskAlarm.

ArtiOsClass

0..1

Contains the layout of an ARTI "Os" object, extending the EcuC

OsOS.

ArtiOsContextClass

0..1

Contains the layout of an ARTI "OsContext" object.

ArtiOsContextInstance

0..*

Represents an instance of an "ArtiContext" object.

ArtiOsInstance

0..1

Represents an instance of an ARTI "Os" object, extending the

EcuC OsOS.

ArtiOsIsrClass

0..1

Contains the layout of an ARTI "OsIsr" object, extending the Ecu

C OsIsr.

ArtiOsIsrInstance

0..*

Represents an instance of an ARTI "OsIsr" object, extending the

EcuC OsIsr.

ArtiOsMessageContainerClass

0..1

Contains the layout of an ARTI "OsMessageContainer" object.

The "OsMessageContainer" object represents an existing

combination of OSEK messages.

ArtiOsMessageContainerInstance

0..*

Represents an instance of an "ArtiMessageContainer" object.

ArtiOsResourceClass

0..1

Contains the layout of an ArtiOsResource object. The ArtiOs

Resource object represents an OSEK resource.

ArtiOsResourceInstance

0..*

Represents an instance of an ArtiOsResource object.

286 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Included Containers

Container Name Multiplicity Scope / Dependency

ArtiOsStackClass

0..1

Contains the layout of an ArtiOsStack object. The ArtiOsStack

object defines the memory area of any stack in the system.

ArtiOsStackInstance

0..*

Represents an instance of an ArtiOsStack object.

ArtiOsTaskClass

0..1

Contains the layout of an ARTI "OsTask" object, extending the

EcuC OsTask.

ArtiOsTaskInstance

0..*

Represents an instance of an ARTI "OsTask" object, extending

the EcuC OsTask.

<ECUC-MODULE-CONFIGURATION-VALUES>

<SHORT-NAME>Vendor1ArtiOs</SHORT-NAME>

<DEFINITION-REF DEST="ECUC-MODULE-DEF">

/AUTOSAR/Arti/ArtiOs</DEFINITION-REF>

<ECUC-CONTAINER-VALUE>

<SHORT-NAME>ArtiOsClass_Conf</SHORT-NAME>

<DEFINITION-REF DEST="ECUC-PARAM-CONF-CONTAINER-DEF">

/AUTOSAR/Arti/ArtiOs/ArtiOsClass</DEFINITION-REF>

<...>

</ECUC-CONTAINER-VALUE>

<ECUC-CONTAINER-VALUE>

<SHORT-NAME>ArtiOsInstance_Conf</SHORT-NAME>

<DEFINITION-REF DEST="ECUC-PARAM-CONF-CONTAINER-DEF">

/AUTOSAR/Arti/ArtiOs/ArtiOsInstance</DEFINITION-REF>

<...>

</ECUC-CONTAINER-VALUE>

<ECUC-CONTAINER-VALUE>

<SHORT-NAME>ArtiOsTaskClass_Conf</SHORT-NAME>

<DEFINITION-REF DEST="ECUC-PARAM-CONF-CONTAINER-DEF">

/AUTOSAR/Arti/ArtiOs/ArtiOsTaskClass</DEFINITION-REF>

</ECUC-CONTAINER-VALUE>

<ECUC-CONTAINER-VALUE>

<SHORT-NAME>ArtiOsTaskInstance_TaskHighPriority</SHORT-NAME>

<DEFINITION-REF DEST="ECUC-PARAM-CONF-CONTAINER-DEF">

/AUTOSAR/Arti/ArtiOs/ArtiOsTaskInstance</DEFINITION-REF>

<...>

</ECUC-CONTAINER-VALUE>

<ECUC-CONTAINER-VALUE>

<SHORT-NAME>ArtiOsTaskInstance_TaskLowPriority</SHORT-NAME>

<DEFINITION-REF DEST="ECUC-PARAM-CONF-CONTAINER-DEF">

/AUTOSAR/Arti/ArtiOs/ArtiOsTaskInstance</DEFINITION-REF>

<...>

</ECUC-CONTAINER-VALUE>

</CONTAINERS>

</ECUC-MODULE-CONFIGURATION-VALUES>

287 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

10.4.5 ArtiOsAlarmClass

SWS Item [ECUC_Arti_00108]

Container Name

ArtiOsAlarmClass

Parent Container

ArtiOs

Description

Contains the layout of an ArtiOsAlarm object.

Post-Build Variant Multiplicity

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Configuration Parameters

SWS Item [ECUC_Arti_00110]

Parameter Name

ArtiOsAlarmClassGenericComponentClassRef

Parent Container

ArtiOsAlarmClass

Description

Refers to an ArtiGenericComponentClass that extends the ArtiOsAlarmClass.

Multiplicity

0..1

Type

Reference to ArtiGenericComponentClass

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

SWS Item [ECUC_Arti_00111]

Parameter Name

ArtiOsAlarmClassStateRef

Parent Container

ArtiOsAlarmClass

Description

Refers to the ArtiObjectClassParameter that declares the attribute ArtiOsAlarmState

Ref in ArtiOsAlarmInstances. This attribute specifies if an alarm is "RUNNING" or

"STOPPED". The refered ArtiObjectClassParameter does include the mapping from

integer to human readable "RUNNING" or "STOPPED".

Multiplicity

0..1

Type

Reference to ArtiObjectClassParameter

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

No Included Containers

288 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

10.4.6 ArtiOsAlarmInstance

SWS Item [ECUC_Arti_00109]

Container Name

ArtiOsAlarmInstance

Parent Container

ArtiOs

Description

Represents an instance of an ArtiOsAlarm object, extending the EcuC OsTaskAlarm.

Post-Build Variant Multiplicity

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Configuration Parameters

SWS Item [ECUC_Arti_00112]

Parameter Name

ArtiOsAlarmInstanceAction

Parent Container

ArtiOsAlarmInstance

Description

This attribute provides a string with a description of the action when the alarm expires,

e.g. "ActivateTask TaskA".

Multiplicity

0..1

Type

EcucStringParamDef

Default value

–

Regular Expression

–

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

SWS Item [ECUC_Arti_00113]

Parameter Name

ArtiOsAlarmInstanceCounter

Parent Container

ArtiOsAlarmInstance

Description

This attribute provides a string containing the name of the counter used by this alarm.

Multiplicity

0..1

Type

EcucStringParamDef

Default value

–

Regular Expression

–

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

289 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

SWS Item [ECUC_Arti_00156]

Parameter Name

ArtiOsAlarmInstanceAlarmTimeRef

Parent Container

ArtiOsAlarmInstance

Description

This attribute specifies how to evaluate the time until the alarm expires next. The time

should be represented in seconds.

Multiplicity

0..1

Type

Reference to ArtiObjectInstanceParameter

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

SWS Item [ECUC_Arti_00114]

Parameter Name

ArtiOsAlarmInstanceCycleTimeRef

Parent Container

ArtiOsAlarmInstance

Description

This attribute specifies how to evaluate the cycle time for cyclic alarms. The value of

"cycle time" is 0 for non-cyclic alarms. The time should be represendet in seconds.

Multiplicity

0..1

Type

Reference to ArtiObjectInstanceParameter

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

SWS Item [ECUC_Arti_00115]

Parameter Name

ArtiOsAlarmInstanceEcuCRef

Parent Container

ArtiOsAlarmInstance

Description

Refers to an EcuC OsAlarm that is beeing extended.

Multiplicity

0..1

Type

Reference to OsAlarm

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

290 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Scope / Dependency

scope: ECU

SWS Item [ECUC_Arti_00116]

Parameter Name

ArtiOsAlarmInstanceGenericComponentInstanceRef

Parent Container

ArtiOsAlarmInstance

Description

Refers to an ArtiGenericComponentInstance that extends the ArtiOsAlarmInstance.

Multiplicity

0..1

Type

Reference to ArtiGenericComponentInstance

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

SWS Item [ECUC_Arti_00117]

Parameter Name

ArtiOsAlarmInstanceStateRef

Parent Container

ArtiOsAlarmInstance

Description

Refers to the ArtiObjectInstanceParameter that contains the evaluation for the "state" of

this alarm. The result then is mapped with the typemap of the ArtiOsAlarmStateRef of

the ArtiOsAlarmClass.

Multiplicity

0..1

Type

Reference to ArtiObjectInstanceParameter

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

SWS Item [ECUC_Arti_00118]

Parameter Name

ArtiOsAlarmInstanceValidRef

Parent Container

ArtiOsAlarmInstance

Description

Refers to the ArtiObjectInstanceParameter that contains the evaluation for the "validity"

of this alarm. Every object declaration may contain a VALID attribute telling the

debugger whether the object’s attributes are currently valid. It may have an integer type

of any size. Its possible values are 0 (invalid) and non zero (object is valid).

Multiplicity

0..1

Type

Reference to ArtiObjectInstanceParameter

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Multiplicity Configuration Class Pre-compile time

VARIANT-PRE-COMPILE

291 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Link time

X VARIANT-LINK-TIME

Post-build time

–

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

No Included Containers

10.4.7 ArtiOsClass

SWS Item [ECUC_Arti_00074]

Container Name

ArtiOsClass

Parent Container

ArtiOs

Description

Contains the layout of an ARTI "Os" object, extending the EcuC OsOS.

Post-Build Variant Multiplicity

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Configuration Parameters

SWS Item [ECUC_Arti_00072]

Parameter Name

ArtiOsClassAppModeRef

Parent Container

ArtiOsClass

Description

Refers to the ArtiObjectClassParameter that defines the ArtiOsAppModeInstance

parameter.

Multiplicity

Type

Reference to ArtiObjectClassParameter

Post-Build Variant Value

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

SWS Item [ECUC_Arti_00076]

Parameter Name

ArtiOsClassGenericComponentRef

Parent Container

ArtiOsClass

Description

Refers to an ArtiGenericComponentClass that extends the OS description.

Multiplicity

0..1

Type

Reference to ArtiGenericComponentClass

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

292 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

SWS Item [ECUC_Arti_00097]

Parameter Name

ArtiOsClassServiceTraceRef

Parent Container

ArtiOsClass

Description

Refers to the ArtiObjectClassParameter that defines the ArtiOsInstanceServiceTrace

parameter. This attribute indicates the entry or exit of a service routine and the ID of

this service routine. The value of this attribute must be evaluated from one single

memory location.

Multiplicity

0..1

Type

Reference to ArtiObjectClassParameter

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

No Included Containers

<ECUC-CONTAINER-VALUE>

<SHORT-NAME>ArtiOsClass_Conf</SHORT-NAME>

<DEFINITION-REF DEST="ECUC-PARAM-CONF-CONTAINER-DEF">/AUTOSAR/Arti/

ArtiOs/ArtiOsClass</DEFINITION-REF>

<REFERENCE-VALUES>

<ECUC-REFERENCE-VALUE>

<DEFINITION-REF DEST="ECUC-REFERENCE-DEF">/AUTOSAR/Arti/

ArtiOs/ArtiOsClass/ArtiOsClassAppModeRef</DEFINITION-REF>

<VALUE-REF DEST="ECUC-CONTAINER-VALUE">/Vendor1/Vendor1Arti/

ArtiObjectClassParameter_ArtiOs_OsAppMode</VALUE-REF>

</ECUC-REFERENCE-VALUE>

</REFERENCE-VALUES>

</ECUC-CONTAINER-VALUE>

10.4.8 ArtiOsContextClass

SWS Item [ECUC_Arti_00119]

Container Name

ArtiOsContextClass

Parent Container

ArtiOs

Description

Contains the layout of an ARTI "OsContext" object.

293 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Post-Build Variant Multiplicity

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Configuration Parameters

SWS Item [ECUC_Arti_00121]

Parameter Name

ArtiOsContextClassGenericComponentClassRef

Parent Container

ArtiOsContextClass

Description

Refers to an ArtiGenericComponentClass that extends the ArtiOsContextClass.

Multiplicity

0..1

Type

Reference to ArtiGenericComponentClass

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

No Included Containers

10.4.9 ArtiOsContextInstance

SWS Item [ECUC_Arti_00120]

Container Name

ArtiOsContextInstance

Parent Container

ArtiOs

Description

Represents an instance of an "ArtiContext" object.

Post-Build Variant Multiplicity

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Configuration Parameters

SWS Item [ECUC_Arti_00122]

Parameter Name

ArtiOsContextInstanceAddressRef

Parent Container

ArtiOsContextInstance

Description

Refers to the ArtiObjectInstanceParameter that contains the evaluation for the

"address" of this context.

Multiplicity

0..1

Type

Reference to ArtiObjectInstanceParameter

Post-Build Variant Multiplicity

false

294 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Post-Build Variant Value

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

SWS Item [ECUC_Arti_00123]

Parameter Name

ArtiOsContextInstanceGenericComponentInstanceRef

Parent Container

ArtiOsContextInstance

Description

Refers to an ArtiGenericComponentInstance that extends the ArtiOsContext.

Multiplicity

0..1

Type

Reference to ArtiGenericComponentInstance

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

SWS Item [ECUC_Arti_00124]

Parameter Name

ArtiOsContextInstanceSizeRef

Parent Container

ArtiOsContextInstance

Description

Refers to the ArtiObjectInstanceParameter that contains the evaluation for the "size" of

this context.

Multiplicity

0..1

Type

Reference to ArtiObjectInstanceParameter

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

SWS Item [ECUC_Arti_00125]

Parameter Name

ArtiOsContextInstanceValidRef

Parent Container

ArtiOsContextInstance

295 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Description

Refers to the ArtiObjectInstanceParameter that contains the evaluation for the "validity"

of this context. Every object declaration may contain a VALID attribute telling the

debugger whether the object’s attributes are currently valid. It may have an integer type

of any size. Its possible values are 0 (invalid) and non zero (object is valid).

Multiplicity

0..1

Type

Reference to ArtiObjectInstanceParameter

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

No Included Containers

10.4.10 ArtiOsInstance

SWS Item [ECUC_Arti_00080]

Container Name

ArtiOsInstance

Parent Container

ArtiOs

Description

Represents an instance of an ARTI "Os" object, extending the EcuC OsOS.

Post-Build Variant Multiplicity

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Configuration Parameters

SWS Item [ECUC_Arti_00073]

Parameter Name

ArtiOsInstanceAppModeRef

Parent Container

ArtiOsInstance

Description

Refers to the ArtiObjectInstanceParameter that contains the evaluation for the

"application mode" of this OS.

Multiplicity

Type

Reference to ArtiObjectInstanceParameter

Post-Build Variant Value

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

296 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

SWS Item [ECUC_Arti_00075]

Parameter Name

ArtiOsInstanceEcucRef

Parent Container

ArtiOsInstance

Description

Refers to the EcucDefs/Os/OsOS of this OS.

Multiplicity

Type

Reference to OsOS

Post-Build Variant Value

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

SWS Item [ECUC_Arti_00078]

Parameter Name

ArtiOsInstanceGenericComponentRef

Parent Container

ArtiOsInstance

Description

Refers to an ArtiGenericComponentInstance that extends the OS.

Multiplicity

0..1

Type

Reference to ArtiGenericComponentInstance

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

SWS Item [ECUC_Arti_00079]

Parameter Name

ArtiOsInstanceHookRef

Parent Container

ArtiOsInstance

Description

Refers to a hook defined in the OS.

Multiplicity

0..*

Type

Reference to ArtiHook

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

SWS Item [ECUC_Arti_00098]

Parameter Name

ArtiOsInstanceServiceTraceRef

Parent Container

ArtiOsInstance

297 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Description

Refers to a hook defined in the OS.

Multiplicity

0..1

Type

Reference to ArtiObjectInstanceParameter

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

SWS Item [ECUC_Arti_00099]

Parameter Name

ArtiOsInstanceValidRef

Parent Container

ArtiOsInstance

Description

Refers to the ArtiObjectInstanceParameter that contains the evaluation for the "validity"

of this ArtiOsInstance. Ever y object declaration may contain a VALID attribute telling

the debugger whether the object’s attributes are currently valid. It may have an integer

type of any size. Its possible values are 0 (invalid) and non zero (object is valid).

Multiplicity

0..1

Type

Reference to ArtiObjectInstanceParameter

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

No Included Containers

<ECUC-CONTAINER-VALUE>

<SHORT-NAME>ArtiOsInstance_Conf</SHORT-NAME>

<DEFINITION-REF DEST="ECUC-PARAM-CONF-CONTAINER-DEF">/AUTOSAR/Arti/

ArtiOs/ArtiOsInstance</DEFINITION-REF>

<REFERENCE-VALUES>

<ECUC-REFERENCE-VALUE>

<DEFINITION-REF DEST="ECUC-REFERENCE-DEF">/AUTOSAR/Arti/

ArtiOs/ArtiOsInstance/ArtiOsInstanceAppModeRef</DEFINITION-REF>

<VALUE-REF DEST="ECUC-CONTAINER-VALUE">/Vendor1/Vendor1Arti/

ArtiObjectInstanceParameter_OsAppMode</VALUE-REF>

</ECUC-REFERENCE-VALUE>

<ECUC-REFERENCE-VALUE>

<DEFINITION-REF DEST="ECUC-REFERENCE-DEF">/AUTOSAR/Arti/

ArtiOs/ArtiOsInstance/ArtiOsInstanceEcucRef</DEFINITION-REF>

<VALUE-REF DEST="ECUC-CONTAINER-VALUE">/Vendor1/Vendor1EcucOs/

Vendor1Os</VALUE-REF>

</ECUC-REFERENCE-VALUE>

<ECUC-REFERENCE-VALUE>

298 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

<DEFINITION-REF DEST="ECUC-REFERENCE-DEF">/AUTOSAR/Arti/

ArtiOs/ArtiOsInstance/ArtiOsInstanceHookRef</DEFINITION-REF>

<VALUE-REF DEST="ECUC-CONTAINER-VALUE">/Vendor1/Vendor1Arti/

ArtiHook_ArtiOs_TaskStart</VALUE-REF>

</ECUC-REFERENCE-VALUE>

<ECUC-REFERENCE-VALUE>

<DEFINITION-REF DEST="ECUC-REFERENCE-DEF">/AUTOSAR/Arti/

ArtiOs/ArtiOsInstance/ArtiOsInstanceHookRef</DEFINITION-REF>

<VALUE-REF DEST="ECUC-CONTAINER-VALUE">/Vendor1/Vendor1Arti/

ArtiHook_ArtiOs_TaskStop</VALUE-REF>

</ECUC-REFERENCE-VALUE>

</REFERENCE-VALUES>

</ECUC-CONTAINER-VALUE>

10.4.11 ArtiOsIsrClass

SWS Item [ECUC_Arti_00081]

Container Name

ArtiOsIsrClass

Parent Container

ArtiOs

Description

Contains the layout of an ARTI "OsIsr" object, extending the EcuC OsIsr.

Post-Build Variant Multiplicity

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Configuration Parameters

SWS Item [ECUC_Arti_00084]

Parameter Name

ArtiOsIsrClassGenericComponentRef

Parent Container

ArtiOsIsrClass

Description

Refers to an optional ArtiGenericComponentClass that extends the OsIsr with

additional parameters.

Multiplicity

0..1

Type

Reference to ArtiGenericComponentClass

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

No Included Containers

299 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

10.4.12 ArtiOsIsrInstance

SWS Item [ECUC_Arti_00086]

Container Name

ArtiOsIsrInstance

Parent Container

ArtiOs

Description

Represents an instance of an ARTI "OsIsr" object, extending the EcuC OsIsr.

Post-Build Variant Multiplicity

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Configuration Parameters

SWS Item [ECUC_Arti_00174]

Parameter Name

ArtiOsIsrInstanceCategory

Parent Container

ArtiOsIsrInstance

Description

Specifies category of this ISR. If omitted the instance is related to a CATEGORY_2.

Multiplicity

0..1

Type

EcucEnumerationParamDef

CATEGORY_1

–

Range

CATEGORY_2

–

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

X All Variants

Link time

–

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

SWS Item [ECUC_Arti_00083]

Parameter Name

ArtiOsIsrInstanceFunction

Parent Container

ArtiOsIsrInstance

Description

This parameter represents the C function name of the ISR routine.

Multiplicity

0..1

Type

EcucFunctionNameDef

Default value

–

Regular Expression

–

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

300 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

SWS Item [ECUC_Arti_00093]

Parameter Name

ArtiOsIsrInstanceId

Parent Container

ArtiOsIsrInstance

Description

This parameter represents the "ISRID" as given by the OS, returned by GetISRID().

Multiplicity

Type

EcucIntegerParamDef

Range 0 .. 18446744073709551615

Default value

–

Post-Build Variant Value

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

SWS Item [ECUC_Arti_00082]

Parameter Name

ArtiOsIsrInstanceEcucRef

Parent Container

ArtiOsIsrInstance

Description

Refers to the EcucDefs/Os/OsIsr of this ISR.

Multiplicity

0..1

Type

Reference to OsIsr

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

X All Variants

Link time

–

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

SWS Item [ECUC_Arti_00085]

Parameter Name

ArtiOsIsrInstanceGenericComponentRef

Parent Container

ArtiOsIsrInstance

Description

Refers to an optional ArtiGenericComponentInstance that extends this OsIsr with

additional parameters.

Multiplicity

0..1

Type

Reference to ArtiGenericComponentInstance

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

301 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

SWS Item [ECUC_Arti_00157]

Parameter Name

ArtiOsIsrInstanceValidRef

Parent Container

ArtiOsIsrInstance

Description

Refers to the ArtiObjectInstanceParameter that contains the evaluation for the "validity"

of this ArtiOsIsrInstance. Ever y object declaration may contain a VALID attribute telling

the debugger whether the object’s attributes are currently valid. It may have an integer

type of any size. Its possible values are 0 (invalid) and non zero (object is valid).

Multiplicity

0..1

Type

Reference to ArtiObjectInstanceParameter

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

No Included Containers

10.4.13 ArtiOsMessageContainerClass

SWS Item [ECUC_Arti_00126]

Container Name

ArtiOsMessageContainerClass

Parent Container

ArtiOs

Description

Contains the layout of an ARTI "OsMessageContainer" object. The "OsMessage

Container" object represents an existing combination of OSEK messages.

Post-Build Variant Multiplicity

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Configuration Parameters

SWS Item [ECUC_Arti_00128]

Parameter Name

ArtiOsMessageContainerClassGenericComponentClassRef

Parent Container

ArtiOsMessageContainerClass

Description

Refers to an ArtiGenericComponentClass that extends the ArtiOsMessageContainer

Class.

Multiplicity

0..1

Type

Reference to ArtiGenericComponentClass

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

302 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

No Included Containers

10.4.14 ArtiOsMessageContainerInstance

SWS Item [ECUC_Arti_00127]

Container Name

ArtiOsMessageContainerInstance

Parent Container

ArtiOs

Description

Represents an instance of an "ArtiMessageContainer" object.

Post-Build Variant Multiplicity

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Configuration Parameters

SWS Item [ECUC_Arti_00129]

Parameter Name

ArtiOsMessageContainerInstanceMsgName

Parent Container

ArtiOsMessageContainerInstance

Description

This attribute provides the name of the message as defined in OIL file.

Multiplicity

0..1

Type

EcucStringParamDef

Default value

–

Regular Expression

–

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

SWS Item [ECUC_Arti_00130]

Parameter Name

ArtiOsMessageContainerInstanceMsgType

Parent Container

ArtiOsMessageContainerInstance

Description

This attribute provides the type of the message.

Multiplicity

0..1

Type

EcucStringParamDef

303 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Default value

–

Regular Expression

–

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

SWS Item [ECUC_Arti_00131]

Parameter Name

ArtiOsMessageContainerInstanceFirstElementRef

Parent Container

ArtiOsMessageContainerInstance

Description

Refers to the ArtiObjectInstanceParameter that contains the evaluation for the

"firstelement" of this "ArtiOsMessageContainer". This attribute provides the formula for

evaluation of address of first valid message. This message will be received next. If no

message is in the queue the value is zero.

Multiplicity

0..1

Type

Reference to ArtiObjectInstanceParameter

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

SWS Item [ECUC_Arti_00132]

Parameter Name

ArtiOsMessageContainerInstanceGenericComponentInstanceRef

Parent Container

ArtiOsMessageContainerInstance

Description

Refers to an ArtiGenericComponentInstance that extends the ArtiOsMessageContainer

Instance.

Multiplicity

0..1

Type

Reference to ArtiGenericComponentInstance

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

304 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

SWS Item [ECUC_Arti_00133]

Parameter Name

ArtiOsMessageContainerInstanceQueueCountRef

Parent Container

ArtiOsMessageContainerInstance

Description

Refers to the ArtiObjectInstanceParameter that contains the evaluation for the

"queuecount" of this "ArtiOsMessageContainer". This attribute provides the number of

valid messages in the queue and "1" for unqueued messages.

Multiplicity

0..1

Type

Reference to ArtiObjectInstanceParameter

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

SWS Item [ECUC_Arti_00134]

Parameter Name

ArtiOsMessageContainerInstanceQueueSizeRef

Parent Container

ArtiOsMessageContainerInstance

Description

Refers to the ArtiObjectInstanceParameter that contains the evaluation for the

"queuesize" of this "ArtiOsMessageContainer". This attribute provides the size of the

queue for queued messages and "1" for unqueued messages.

Multiplicity

0..1

Type

Reference to ArtiObjectInstanceParameter

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

SWS Item [ECUC_Arti_00135]

Parameter Name

ArtiOsMessageContainerInstanceValidRef

Parent Container

ArtiOsMessageContainerInstance

Description

Refers to the ArtiObjectInstanceParameter that contains the evaluation for the "validity"

of this ArtiOsMessageContainerInstance. Ever y object declaration may contain a

VALID attribute telling the debugger whether the object’s attributes are currently valid. It

may have an integer type of any size. Its possible values are 0 (invalid) and non zero

(object is valid).

Multiplicity

0..1

Type

Reference to ArtiObjectInstanceParameter

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Multiplicity Configuration Class Pre-compile time

VARIANT-PRE-COMPILE

305 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Link time

X VARIANT-LINK-TIME

Post-build time

–

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

No Included Containers

10.4.15 ArtiOsResourceClass

SWS Item [ECUC_Arti_00136]

Container Name

ArtiOsResourceClass

Parent Container

ArtiOs

Description

Contains the layout of an ArtiOsResource object. The ArtiOsResource object

represents an OSEK resource.

Post-Build Variant Multiplicity

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Configuration Parameters

SWS Item [ECUC_Arti_00138]

Parameter Name

ArtiOsResourceClassGenericComponentClassRef

Parent Container

ArtiOsResourceClass

Description

Refers to an ArtiGenericComponentClass that extends the ArtiOsResourceClass.

Multiplicity

0..1

Type

Reference to ArtiGenericComponentClass

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

SWS Item [ECUC_Arti_00139]

Parameter Name

ArtiOsResourceClassLockerRef

Parent Container

ArtiOsResourceClass

Description

Refers to the ArtiObjectClassParameter that declares the attribute ArtiOsResource

LockerRef in ArtiOsResourceInstances. This attribute indicates the locking ArtiOsTask

Instance or ArtiOsIsrInstance.

Multiplicity

0..1

306 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Type

Reference to ArtiObjectClassParameter

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

SWS Item [ECUC_Arti_00140]

Parameter Name

ArtiOsResourceClassStateRef

Parent Container

ArtiOsResourceClass

Description

Refers to the ArtiObjectClassParameter that declares the attribute ArtiOsResource

StateRef in ArtiOsResourceInstances. This attribute represents the state of a resource

("LOCKED"/"UNLOCKED"). The ArtiObjectClassParameter does include the mapping

from integer to human readable "LOCKED" or "UNLOCKED".

Multiplicity

0..1

Type

Reference to ArtiObjectClassParameter

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

No Included Containers

10.4.16 ArtiOsResourceInstance

SWS Item [ECUC_Arti_00137]

Container Name

ArtiOsResourceInstance

Parent Container

ArtiOs

Description

Represents an instance of an ArtiOsResource object.

Post-Build Variant Multiplicity

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Configuration Parameters

307 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

SWS Item [ECUC_Arti_00141]

Parameter Name

ArtiOsResourceInstancePriority

Parent Container

ArtiOsResourceInstance

Description

This attribute has two components that state: that the RESOURCE is used by TASKs

only or by TASKs and ISRs, and the priority that will be used when locking the

RESOURCE.

Multiplicity

0..1

Type

EcucStringParamDef

Default value

–

Regular Expression

–

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

SWS Item [ECUC_Arti_00142]

Parameter Name

ArtiOsResourceInstanceEcuCRef

Parent Container

ArtiOsResourceInstance

Description

Refers to an EcuC OsResource that is beeing extended.

Multiplicity

0..1

Type

Reference to OsResource

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

SWS Item [ECUC_Arti_00143]

Parameter Name

ArtiOsResourceInstanceGenericComponentInstanceRef

Parent Container

ArtiOsResourceInstance

Description

Refers to an ArtiGenericComponentInstance that extends the ArtiOsResourceInstance.

Multiplicity

0..1

Type

Reference to ArtiGenericComponentInstance

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Value Configuration Class Pre-compile time

VARIANT-PRE-COMPILE

308 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Link time

X VARIANT-LINK-TIME

Post-build time

–

Scope / Dependency

scope: ECU

SWS Item [ECUC_Arti_00145]

Parameter Name

ArtiOsResourceInstanceLockerRef

Parent Container

ArtiOsResourceInstance

Description

Refers to the ArtiObjectInstanceParameter that contains the evaluation for the "locker"

of this ArtiOsResource.

Multiplicity

0..1

Type

Reference to ArtiObjectInstanceParameter

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

SWS Item [ECUC_Arti_00144]

Parameter Name

ArtiOsResourceInstanceStateRef

Parent Container

ArtiOsResourceInstance

Description

Refers to the ArtiObjectInstanceParameter that contains the evaluation for the "state" of

this ArtiOsResource.

Multiplicity

0..1

Type

Reference to ArtiObjectInstanceParameter

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

SWS Item [ECUC_Arti_00146]

Parameter Name

ArtiOsResourceInstanceValidRef

Parent Container

ArtiOsResourceInstance

Description

Refers to the ArtiObjectInstanceParameter that contains the evaluation for the "validity"

of this ArtiOsResourceInstance. Every object declaration may contain a VALID attribute

telling the debugger whether the object’s attributes are currently valid. It may have an

integer type of any size. Its possible values are 0 (invalid) and non zero (object is valid).

Multiplicity

0..1

Type

Reference to ArtiObjectInstanceParameter

Post-Build Variant Multiplicity

false

309 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Post-Build Variant Value

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

No Included Containers

10.4.17 ArtiOsStackClass

SWS Item [ECUC_Arti_00147]

Container Name

ArtiOsStackClass

Parent Container

ArtiOs

Description

Contains the layout of an ArtiOsStack object. The ArtiOsStack object defines the

memory area of any stack in the system.

Post-Build Variant Multiplicity

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Configuration Parameters

SWS Item [ECUC_Arti_00149]

Parameter Name

ArtiOsStackClassGenericComponentClassRef

Parent Container

ArtiOsStackClass

Description

Refers to an ArtiGenericComponentClass that extends the ArtiOsStackClass.

Multiplicity

0..1

Type

Reference to ArtiGenericComponentClass

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

No Included Containers

310 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

10.4.18 ArtiOsStackInstance

SWS Item [ECUC_Arti_00148]

Container Name

ArtiOsStackInstance

Parent Container

ArtiOs

Description

Represents an instance of an ArtiOsStack object.

Post-Build Variant Multiplicity

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Configuration Parameters

SWS Item [ECUC_Arti_00150]

Parameter Name

ArtiOsStackInstanceDirection

Parent Container

ArtiOsStackInstance

Description

This attribute specifies the direction of stack growth and may have either "UP" or

"DOWN" as its value. UP means growing from lower to higher addresses. DOWN

means growing from higher addresses to lower addresses.

Multiplicity

0..1

Type

EcucStringParamDef

Default value

–

Regular Expression

–

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

SWS Item [ECUC_Arti_00151]

Parameter Name

ArtiOsStackInstanceBaseAddressRef

Parent Container

ArtiOsStackInstance

Description

Refers to the ArtiObjectInstanceParameter that contains the evaluation for the

"baseaddress" of this ArtiOsStack. This attribute specifies the lowest address of stack

memory area, regardless of the stack direction.

Multiplicity

0..1

Type

Reference to ArtiObjectInstanceParameter

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

311 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

SWS Item [ECUC_Arti_00152]

Parameter Name

ArtiOsStackInstanceFillPatternRef

Parent Container

ArtiOsStackInstance

Description

Refers to the ArtiObjectInstanceParameter that contains the evaluation for the

"fillpattern" of this ArtiOsStack. If the operating system fills the stack during

initialisation, this attribute specifies with which pattern the stack area is initialised. This

allows the debugger to evaluate the maximum stack usage. For "stackdirection"

"DOWN" the pattern starts at "baseaddress". For "stackdirection" "UP" the pattern

starts at "baseaddress" + "size". If no pattern is used, this attribute must be omitted.

Multiplicity

0..1

Type

Reference to ArtiObjectInstanceParameter

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

SWS Item [ECUC_Arti_00153]

Parameter Name

ArtiOsStackInstanceGenericComponentInstanceRef

Parent Container

ArtiOsStackInstance

Description

Refers to an ArtiGenericComponentInstance that extends the ArtiOsStackInstance.

Multiplicity

0..1

Type

Reference to ArtiGenericComponentInstance

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

SWS Item [ECUC_Arti_00154]

Parameter Name

ArtiOsStackInstanceSizeRef

Parent Container

ArtiOsStackInstance

Description

Refers to the ArtiObjectInstanceParameter that contains the evaluation for the "size" of

this ArtiOsStack. This attribute represents the size (in bytes) of the memory area

allocated for stack.

Multiplicity

0..1

Type

Reference to ArtiObjectInstanceParameter

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

VARIANT-PRE-COMPILE

Multiplicity Configuration Class

Link time

X VARIANT-LINK-TIME

312 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Post-build time

–

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

SWS Item [ECUC_Arti_00155]

Parameter Name

ArtiOsStackInstanceValidRef

Parent Container

ArtiOsStackInstance

Description

Refers to the ArtiObjectInstanceParameter that contains the evaluation for the "validity"

of this ArtiOsStackInstance. Every object declaration may contain a VALID attribute

telling the debugger whether the object’s attributes are currently valid. It may have an

integer type of any size. Its possible values are 0 (invalid) and non zero (object is valid).

Multiplicity

0..1

Type

Reference to ArtiObjectInstanceParameter

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

No Included Containers

10.4.19 ArtiOsTaskClass

SWS Item [ECUC_Arti_00087]

Container Name

ArtiOsTaskClass

Parent Container

ArtiOs

Description

Contains the layout of an ARTI "OsTask" object, extending the EcuC OsTask.

Post-Build Variant Multiplicity

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Configuration Parameters

SWS Item [ECUC_Arti_00077]

Parameter Name

ArtiOsTaskClassClassGenericComponentRef

Parent Container

ArtiOsTaskClass

Description

Refers to an ArtiGenericComponentClass that extends the OsTask.

Multiplicity

0..1

Type

Reference to ArtiGenericComponentClass

313 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

SWS Item [ECUC_Arti_00100]

Parameter Name

ArtiOsTaskClassContextRef

Parent Container

ArtiOsTaskClass

Description

ArtiOsTaskContextRef in ArtiOsTaskInstances. This attribute contains a reference to

the context object that the task is currently using.

Multiplicity

0..1

Type

Reference to ArtiObjectClassParameter

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

SWS Item [ECUC_Arti_00068]

Parameter Name

ArtiOsTaskClassCurrentTaskStateRef

Parent Container

ArtiOsTaskClass

Description

Refers to the ArtiObjectClassParameter that defines the ArtiCurrentTaskStateInstance

parameter including the task state mapping.

Multiplicity

0..1

Type

Reference to ArtiObjectClassParameter

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

SWS Item [ECUC_Arti_00101]

Parameter Name

ArtiOsTaskClassPriorityRef

Parent Container

ArtiOsTaskClass

314 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Description

Refers to the ArtiObjectClassParameter that declares the attribute ArtiOsTaskPriority

Ref in ArtiOsTaskInstances. This attribute represents the current prior ity of the TASK

object. The current priority can be different from the static task priority as a result of

priority ceiling protocol. The priority displayed is the pr iority as defined in the OsTask.

Multiplicity

0..1

Type

Reference to ArtiObjectClassParameter

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

SWS Item [ECUC_Arti_00102]

Parameter Name

ArtiOsTaskClassStackRef

Parent Container

ArtiOsTaskClass

Description

Refers to the ArtiObjectClassParameter that declares the attribute ArtiOsTaskStackRef

in ArtiOsTaskInstances. This attribute contains a reference to the stack object that the

task is currently using.

Multiplicity

0..1

Type

Reference to ArtiObjectClassParameter

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

No Included Containers

<ECUC-CONTAINER-VALUE>

<SHORT-NAME>ArtiOsTaskClass_Conf</SHORT-NAME>

<DEFINITION-REF DEST="ECUC-PARAM-CONF-CONTAINER-DEF">/AUTOSAR/Arti/

ArtiOs/ArtiOsTaskClass</DEFINITION-REF>

<REFERENCE-VALUES>

<ECUC-REFERENCE-VALUE>

<DEFINITION-REF DEST="ECUC-REFERENCE-DEF">/AUTOSAR/Arti/

ArtiOs/ArtiOsTaskClass/

ArtiOsTaskClassGenericComponentRef</DEFINITION-REF>

<VALUE-REF DEST="ECUC-CONTAINER-VALUE">/Vendor1/Vendor1ArtiGeneric/

ArtiGenericComponentClass_Vendor1Task</VALUE-REF>

</ECUC-REFERENCE-VALUE>

</REFERENCE-VALUES>

</ECUC-CONTAINER-VALUE>

315 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

10.4.20 ArtiOsTaskInstance

SWS Item [ECUC_Arti_00090]

Container Name

ArtiOsTaskInstance

Parent Container

ArtiOs

Description

Represents an instance of an ARTI "OsTask" object, extending the EcuC OsTask.

Post-Build Variant Multiplicity

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Configuration Parameters

SWS Item [ECUC_Arti_00089]

Parameter Name

ArtiOsTaskInstanceFunction

Parent Container

ArtiOsTaskInstance

Description

This parameter represents the C function name of the task body.

Multiplicity

0..1

Type

EcucFunctionNameDef

Default value

–

Regular Expression

–

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

SWS Item [ECUC_Arti_00092]

Parameter Name

ArtiOsTaskInstanceId

Parent Container

ArtiOsTaskInstance

Description

This parameter represents the "TaskID" as given by the OSEK OS, returned by Get

TaskID().

Multiplicity

Type

EcucIntegerParamDef

Range 0 .. 18446744073709551615

Default value

–

Post-Build Variant Value

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

SWS Item [ECUC_Arti_00104]

Parameter Name

ArtiOsTaskInstanceContextRef

Parent Container

ArtiOsTaskInstance

316 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Description

Refers to the ArtiObjectInstanceParameter that contains the evaluation for the ArtiOs

Context of this ArtiOsTask.

Multiplicity

0..1

Type

Reference to ArtiObjectInstanceParameter

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

SWS Item [ECUC_Arti_00105]

Parameter Name

ArtiOsTaskInstanceCurrentActivationsRef

Parent Container

ArtiOsTaskInstance

Description

Refers to the ArtiObjectInstanceParameter that contains the evaluation for the "current

activations" of this task. This attribute specifies the number of current activations for the

task.

Multiplicity

0..1

Type

Reference to ArtiObjectInstanceParameter

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

SWS Item [ECUC_Arti_00069]

Parameter Name

ArtiOsTaskInstanceCurrentTaskStateRef

Parent Container

ArtiOsTaskInstance

Description

Refers to the ArtiObjectInstanceParameter that contains the evaluation for the "current

state" of this task.

Multiplicity

0..1

Type

Reference to ArtiObjectInstanceParameter

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

317 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

SWS Item [ECUC_Arti_00088]

Parameter Name

ArtiOsTaskInstanceEcucRef

Parent Container

ArtiOsTaskInstance

Description

Refers to an ArtiGenericComponentInstance that extends the OsTask.

Multiplicity

Type

Reference to OsTask

Post-Build Variant Value

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

SWS Item [ECUC_Arti_00070]

Parameter Name

ArtiOsTaskInstanceGenericComponentRef

Parent Container

ArtiOsTaskInstance

Description

Refers to an ArtiGenericComponentInstance that extends the OsTask.

Multiplicity

0..1

Type

Reference to ArtiGenericComponentInstance

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

SWS Item [ECUC_Arti_00106]

Parameter Name

ArtiOsTaskInstancePriorityRef

Parent Container

ArtiOsTaskInstance

Description

Refers to the ArtiObjectInstanceParameter that contains the evaluation for the "task

priority" of this task.

Multiplicity

0..1

Type

Reference to ArtiObjectInstanceParameter

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

318 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

SWS Item [ECUC_Arti_00107]

Parameter Name

ArtiOsTaskInstanceStackRef

Parent Container

ArtiOsTaskInstance

Description

Refers to the ArtiObjectInstanceParameter that contains the evaluation for the ArtiOs

Stack of this ArtiOsTask.

Multiplicity

0..1

Type

Reference to ArtiObjectInstanceParameter

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

SWS Item [ECUC_Arti_00103]

Parameter Name

ArtiOsTaskInstanceValidRef

Parent Container

ArtiOsTaskInstance

Description

Refers to the ArtiObjectInstanceParameter that contains the evaluation for the "validity"

of this ArtiOsTaskInstance. Every object declaration may contain a VALID attribute

telling the debugger whether the object’s attributes are currently valid. It may have an

integer type of any size. Its possible values are 0 (invalid) and non zero (object is valid).

Multiplicity

0..1

Type

Reference to ArtiObjectInstanceParameter

Post-Build Variant Multiplicity

false

Post-Build Variant Value

false

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Multiplicity Configuration Class

Post-build time

–

Pre-compile time

VARIANT-PRE-COMPILE

Link time

X VARIANT-LINK-TIME

Value Configuration Class

Post-build time

–

Scope / Dependency

scope: ECU

No Included Containers

<ECUC-CONTAINER-VALUE>

<SHORT-NAME>ArtiOsTaskInstance_TaskHighPriority</SHORT-NAME>

<DEFINITION-REF DEST="ECUC-PARAM-CONF-CONTAINER-DEF">/AUTOSAR/Arti/

ArtiOs/ArtiOsTaskInstance</DEFINITION-REF>

<REFERENCE-VALUES>

<ECUC-REFERENCE-VALUE>

<DEFINITION-REF DEST="ECUC-REFERENCE-DEF">/AUTOSAR/Arti/

ArtiOs/ArtiOsTaskInstance/

ArtiOsTaskInstanceGenericComponentRef</DEFINITION-REF>

<VALUE-REF DEST="ECUC-CONTAINER-VALUE">/Vendor1/Vendor1ArtiGeneric/

ArtiGenericComponentInstance_TaskHighPriority</VALUE-REF>

</ECUC-REFERENCE-VALUE>

<ECUC-REFERENCE-VALUE>

<DEFINITION-REF DEST="ECUC-REFERENCE-DEF">/AUTOSAR/Arti/

319 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

ArtiOs/ArtiOsTaskInstance/

ArtiOsTaskInstanceEcucRef</DEFINITION-REF>

<VALUE-REF DEST="ECUC-CONTAINER-VALUE">/Vendor1/Vendor1EcucOs/

TaskHighPriority</VALUE-REF>

</ECUC-REFERENCE-VALUE>

</REFERENCE-VALUES>

</ECUC-CONTAINER-VALUE>

10.5 Published Information

For details refer to the chapter 10.3 “Published Information” in [4].

320 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

11 Generation of the OS

Figure 11.1: Generation activities

11.1 Read in configuration

[SWS_Os_00172] dThe generator shall provide the user the ability of reading the in-

formation of a selectable configuration file.c()

11.2 Consistency check

The conistency check can issue warnings or errors. Warnings mean that the generation

is completed successfully, only indicating a not advisable configuration. Errors mean

that the generation is not performed.

[SWS_Os_00173] dThe generator shall provide the user the ability of performing a

consistency check of the current configuration.c()

[SWS_Os_00050] dIf service protection is required and OsStatus is not equal to EX-

TENDED (all the associated error handling is provided), the consistency check shall

issue an error.c()

[SWS_Os_00045] dIf timing protection is configured together with OSEK OS Category

1 interrupts, the consistency check shall issue a warning.c()

321 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

[SWS_Os_00562] dIf timing protection is configured together with OsPreTaskHook or

OsPostTaskHook the consistency check shall issue a warning.c()

[SWS_Os_00320] dIf configured attributes do not match the configured scalability

class (e.g. defining an execution time budget in Tasks or Category 2 ISRs and se-

lected scalability class is 1) the consistency check shall issue a warning.c()

[SWS_Os_00311] dIf OsScalabilityClass is SC3 or SC4, or system is Multi-Core,

AND a Task OR Category 2 ISR OR Counters OR Alarms OR ScheduleTables

does not belong to exactly one OS-Application the consistency check shall issue an

error.c()

[SWS_Os_00361] dIf OsScalabilityClass is SC3 or SC4, or system is Multi-Core,

AND a Category 1 ISR does not belong to exactly one trusted OS-Application the

consistency check shall issue an errorc()

[SWS_Os_00177] dIf OsScalabilityClass is SC3 or SC4, or system is Multi-Core,

AND an interrupt source that is used by the OS is assigned to an OS-Application, the

consistency check shall issue an error.c()

[SWS_Os_00303] dIf OsAlarmIncrementCounter is configured as action on alarm

expiry AND the alarm is driven directly or indirectly (a cyclic chain of alarm actions with

OsAlarmIncrementCounter) by that Counter, the consistency check shall issue a

warning.c()

[SWS_Os_00328] dIf OsStatus is STANDARD and OsScalabilityClass is SC3

or SC4 the consistency check shall issue an error.c()

[SWS_Os_00343] dIf OsScalabilityClass is SC3 or SC4, or system is Multi-Core,

AND a Task is referenced within a ScheduleTable object AND the OS-Application

of the ScheduleTable has no access to the Task, the consistency check shall issue

an error.c()

[SWS_Os_00344] dIf OsScalabilityClass is SC3 or SC4, or system is Multi-Core,

AND a Task is referenced within an alarm object AND the OS-Application of the alarm

has no access to the Task, the consistency check shall issue an error.c()

[SWS_Os_00440] dIf a ScheduleTable has OsScheduleTblSyncStrategy = IM-

PLICIT and the OsCounterMaxAllowedValue+1 of the associated Counter is not

equal to the duration of the ScheduleTable then the consitency check shall issue an

error.c()

[SWS_Os_00461] dIf OsScalabilityClass is SC2, SC3 or SC4 AND Alarm Call-

backs are configured the conistency check shall isuue an error.c()

[SWS_Os_00850] dIf OsUseResScheduler is TRUE AND the configuration contains

a resource called RES_SCHEDULER, the generation tool shall ignore the configured

RES_SCHEDULER.c()

322 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

11.3 Generating operating system

[SWS_Os_00179] dIf the consistency check of the read-in configuration file has not

run free of errors, the generator shall not generate/configure the operating system.c()

[SWS_Os_00336] dThe generator shall generate a relocatable memory section con-

taining the interrupt vector table.c(SRS_Os_11019)

[SWS_Os_00370] dThe generator shall print out information about timers used inter-

nally by the OS during generation (e.g. on console, list file).c(SRS_Frt_00022)

[SWS_Os_00393] dThe generator shall create conversation macros to convert counter

ticks (given as argument) into real time. The format of the macro is OS_TICKS2

<Unit>_<Counter>(ticks) whereas <Unit> is one of NS (nanoseconds), US (mi-

croseconds), MS (milliseconds) or SEC (seconds) and <Counter> is the name of the

Counter; E.g. OS_TICKS2MS_MyCounter())c(SRS_Frt_00047)

[SWS_Os_00815] dThe OS code shall wrap each declaration of Task, ISR, trusted

functions, alarm callbacks and hook functions with the Memory Mapping Allocation

Keywords macros.

1 #define OS_START_SEC_<sadm>

2 #include "Os_MemMap.h"

4 < Task, ISR, trusted functions or hook functions declaration>

6 #define OS_STOP_SEC_<sadm>

7 #include "Os_MemMap.h"

where <sadm> is the shortName of the SwAddrMethod if configured (e.g. in OsMemo-

ryMappingCodeLocationRef).c(SRS_BSW_00351)

323 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

12 Application Notes

12.1 Hooks

In OSEK OS, PreTask & PostTask Hooks run at the level of the OS with unrestricted

access rights and therefore must be trusted. It is strongly recommended that these

hook routines are only used during debugging and are not used in a final product.

When an OS-Application is killed the shutdown and startup hooks of the OS-Application

are not called. Cleanup of OS-Application specific data can be done in the restart

Task.

All application-specific hook functions (startup, shutdown and error) must return (block-

ing or endless loops are not acceptable).

12.2 Providing Trusted Functions

Address checking shall be done before data is accessed. Special care must be taken

if parameters passed by reference point to the stack space of a Task or interrupt,

because this address space might no longer belong to the Task or interrupt when the

address is used.

The following code fragment shows an example how a trusted function is called and

how the checks should be done.

1 struct parameter_struct {type1 name1, type2 name2, StatusType

return_value};

3 /

This service is called by the user and uses a trusted function

4 StatusType system_service( type1 parameter1, type2 parameter2)

5 {

6 /

store parameters in a structure (parameter1 and parameter2)

7 struct parameter_struct local_struct;

8 local_struct.name1 = parameter1;

9 local_struct.name2 = parameter2;

10 /

call CallTrustedFunction with appropriate index and

pointer to structure

12 if(CallTrustedFunction(SYSTEM_SERVICE_INDEX, &local_struct) != E_OK

)

13 return(FUNCTION_DOES_NOT_EXIST);

14 return(local_struct.return_value);

15 }

17 /

The CallTrustedFunction() service switches to the privileged

mode. Note that the example is only a fragment!

19 StatusType CallTrustedFunction( TrustedFunctionIndexType ix,

TrustedFunctionParameterRefType ref)

20 {

21 /

check for legal service index and return error if necessary

22 if(ix > MAX_SYSTEM_SERVICE)

23 return(E_OS_SERVICEID);

324 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

24 /

some implementation specific magic happens: the processor is

set to privileged mode

27 /

indirectly call target function based on the index

28 (

(system-service_list[ix]))(ix, ref);

29 /

some implementation specific magic happens: the processor is

set to non-privileged mode

32 return(E_OK);

33 }

36 /

This part of the system service is called by

CallTrustedFunction()

38 void TRUSTED_system_service_part2 (TrustedFunctionIndexType a,

parameter_struct

local_struct)

39 {

40 TaskRefType task;

41 type1 parameter1;

42 type2 parameter2;

43 if (GetTaskID(&task) != E_OK)

44 task = INVALID_TASK;

45 /

get parameters out of the structure (parameter1 and

parameter2)

47 parameter1 = local_struct.name1;

48 parameter2 = local_struct.name2;

49 /

check the parameters if necessary

50 /

example is for parameter1 being an address and parameter2

being a size

52 /

example only for system_service called from tasks

53 if(GetISRID()!=INVALID_ISR)

54 {

55 /

error: not callable from ISR

56 local_struct.return_value = E_OS_ACCESS;

57 }

58 else if(OSMEMORY_IS_WRITEABLE(CheckTaskMemoryAccess(task,parameter1

,parameter2)))

59 {

60 /

system_service_part3() is now the function as it

would be if directly called in a non-protected

environment

63 local_struct.return_value = system_service_part3(parameter1,

parameter2);

64 }

65 else

66 {

67 /

error handling

68 local_struct.return_value = E_OS_ACCESS;

69 }

70 }

Note: Since the service of CallTrustedFunction is very generic, it is needed to

define a stub-interface which does the packing and unpacking of the arguments (as the

example show). Depending on the implementation the stub interface may be (partly)

generated by the generation tool.

325 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

12.3 Software Components and OS-Applications

Trusted OS-Applications can be permitted access to IO space. As software compo-

nents can not be allowed direct access to the hardware, software components can

not be trusted OS-Applications because this would violate this protection feature. The

configuration process must ensure that this is the case.

The AUTOSAR Virtual Function Bus (VFB) specification places no restrictions on how

runnables from software components are mapped to OS Tasks. However, the protec-

tion mechanisms in AUTOSAR OS apply only to OS managed objects. This means

that all runnables in a Task:

• Are not protected from each other at runtime

• Share the same protection boundary

If runnables need to be protected they must therefore be allocated to different Tasks

and those Tasks protected accordingly.

A simple rule can suffice:

"When allocating runnables to Tasks, only allocate runnables from the same software

component into the same Task."

If multiple software components from the same application are to reside on the

same processor, then, assuming protection is required between applications (or parts

thereof) on the same processor, this rule could be modified to relax the scope of pro-

tection to the application:

"When allocating runnables to Tasks, only allocate runnables from the same applica-

tion into the same Task."

If an OS-Application is killed and the restart Task is activated it can not assume that the

startup of the OS-Application has finished. Maybe the fault happened in the application

startup hook and no Task of the application was started so far.

12.4 Global Time Synchronization

The OS currently assumes that the global time synchronization is done by the user

(unless implicit synchronization is used). This allows maximum flexibility regarding the

time source. For synchronization with e.g. FlexRay some glue code may be necessary

which transfer the information from the time source to the OS.

12.5 Working with FlexRay

ScheduleTables in the AUTOSAR OS may be synchronized with a global (network)

time provided by FlexRay in essentially two ways:

326 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

• Using the FlexRay interface’s services for controlling timer interrupts related to

global time to provide a "hardware" counter tick source to drive the processing of

a ScheduleTable (implicit synchronization)

• Using the FlexRay interface’s service for accessing the current global time and

passing this into the OS through the SyncScheduleTable OS service call

This section looks at the second option only.

In FlexRay time is presented as a tuple of a Cycle and a MacrotickOffset within the

cycle. Cycle is an 8-bit value and MacrotickOffset is a 16-bit value.

In AUTOSAR OS a ScheduleTable is associated with an underlying Counter that

has a notion of ticks. It is therefore possible to synchronize with either the Cycle or the

tuple of Cycle/MacrotickOffset to give the resolution of synchronization required by the

application.

If Cycle only resolution is required then an OS Counter object should be configured

to have a OsCounterMaxAllowedValue equal to the maximum number of Cycles.

If Cycle/MacrotickOffset is required then an OS Counter object should be configured

with a OsCounterMaxAllowedValue of the maximum number of Cycles multiplied

by the MacrotickOffset. This provides the OS with a time base against which a Sched-

uleTable can be synchronized.

Synchronization between the OS and an external global time source is provided by

telling the OS the global time through the SyncScheduleTable service call. This call

takes a scalar parameter of TickType so to interface this to FlexRay’s representation

of time a small conversion needs to be done. The following example assumes a Cycle

of 255 with 65535 Macroticks per Cycle. TickType is at least 24-bits wide.

1 #define OSTIME(x) (TickType)(x);

3 FrIf_GetGlobalTime(Controller, &Cycle, &Macrotick);

5 SyncScheduleTable(Tbl, ((OSTIME(Cycle) <<16)+(OSTIME(Macrotick))));

Telling the ScheduleTable that GlobalTime can be done when the application detects

that the FlexRay controller has lost synchronization with the network (by polling the

controller sync status). The following code indicates how this can be used to force an

associated ScheduleTable into the SCHEDULETABLE_RUNNING state from the SCHED-

ULETABLE_RUNNING_AND_SYNCHRONOUS state.

1 Fr_SyncStateType CurrentSyncStatus;

3 if (FrIf_GetSyncState(Controller, &CurrentSyncStatus) == E_OK) {

5 if (CurrentSyncStatus == FR_ASYNC ) {

6 SetScheduleTableAsync(Table);

7 }

9 }

327 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Of course, other actions are possible here, like stopping the ScheduleTable, as best

fits user requirements.

12.6 Migration from OIL to XML

This version of the AUTOSAR OS specification does not directly support the config-

uration via OIL. The support for OIL was dropped in favour of XML because XML is

the standard configuration language in AUTOSAR and is essential if configuration data

has to be imported / exported from / to other AUTOSAR modules or between different

tools during development.

Since OIL and XML are both ASCII formats a tool vendor may offer a possibility to

import (old) OIL files and to store them as (AUTOSAR OS) XML files. Currently all

known vendors support at least the import of existing OIL configurations.

Note that for showing conformance to the OSEK OS specification, each OSEK OS ven-

dor must support OIL. This means that practically each AUTOSAR OS vendor will offer

some sort of import of OIL configurations - at least to show the OSEK OS conformance.

12.7 Debug suppor t

For the AUTOSAR OS the following information may be useful for users and should be

considert for debug support (and may be published, e.g. in the BSWMD):

• General information about how to retrieve the current (active) Task or ISR and

their (current) priority and (current) stack.

• For ISRs: Information about the name of interrupts, their mapping to the ISR

identifier, the associated hardware and the used stack(s).

• For Tasks: Information about the name of the Task, its identifier, the task

state, the possible priorities, the event mask (if its an extended Task), the OS-

Application to whom the Task belongs (if existant) and the used stack.

• For Resources: Information about the name of the Resource, its mapping to

the identifier, its priority and the current owner (the Task/ISR which currently

holds the Resource)

• For Alarms: Information about the name of the Alarm, its mapping to the identi-

fier, the Counter to whom it belong, the action which is executed on expiry and

the current state (running or stopped). In running state the next expiry in ticks

and the possible cycle time shall be also published.

• For Counters: Information about the name of the Counter, its mapping to the

identifier, its associated alarms and the current counter value.

328 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

• For SchduleTables: Information about the name of the ScheduleTable, its

mapping to the identifier, its current state and the next expiry point (if the table is

running).

• For OS-Applications: Information about the name of the OS-Application, its map-

ping to the identifier, its current state and the memory sections assigned to it (if

memory protection is used).

ARTI implements mechanisms to retrieve the described information (see [9]).

User documentation should contain information about the implemeted debug features.

12.8 Integration hints for peripheral protection

Peripheral protection requires configuration on the core level usually conditioned by a

supervisor access. For this reason the task of the peripheral protection is assigned to

the OS module.

Peripheral protection may be implemented in two ways

- using MPU

- using dedicated peripheral protection units of the target MCU.

When using the memory protection unit, it is reasonable if two or more protected region

descriptors are available for peripheral protection mechanism. The region descriptors

shall be programmed to allow access to those peripherals the current OS-Application

shall work with. The defined regions shall cover all memor y mapped configuration

registers for the periphiherals to be protected. The advantage of using the MPU is that

the configuration is the same as for memory protection. One of the disadvantages of

this method is that it could be impossilbe to cover all peripheral control registers with

available MPU region descriptors. The number of such descriptors is typically low.

Beware that using this method may have implication to the linker file of the project

software configuration.

Second method is using a dedicated register protection schema. This method shall

allow to precisely select peripherals for every OS Application. However the number of

peripherals may make the register protection implementation rather bulky. Therefore it

is advisable to reduce the number of protected peripherals to a reasonable value.

For both methods the configuration shall be placed into custom OS Application prop-

erties. The configuration shall be active when a Task (or ISR) of a particular OS

Application is running.

329 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

12.9 Termination of OS-Applications

Inconsistencies may occur when an OsApplication is ter minated and restarted, de-

pending on its state at the termination.

• A notification from an asynchronous job started before the termination of OsAp-

plication can occur after the restart of OsApplication.

• An asynchronous memory read or wr ite started before the termination of OsAp-

plication can occur after restart, and cause data inconsistency.

• A requested mode or state to another OsApplication (e.g. from a SW-C to

A BSW) can lead to unsynchronized state machines after an OsApplication

restart.

Therefore some measures shall be taken to avoid these inconsistencies and guaranty

a correct behavior.

Integration code shall stop all signals and signalgroups during its OsApplication

restart. This ensures that no late asynchronous notification will occur after the OsAp-

plication restart. These signals and signalgroups can be then safely restarted if

needed.

A SW-C shall cancel jobs on all its memory blocks with a call to NvM_CancelJobs

during the restart of its OsApplication. As the job might have already been started,

the call to NvM_CancelJobs can return an error; in that case, the OsApplication

shall wait until end of the job to continue. After all jobs are ensured to be cancelled, then

all memory blocks shall be reset to their initial value, in order to avoid inconsistency of

data which might have been written before the cancellation.

Any SW-C having responsible for requesting mode or state to BSW mode managers

shall always request a default mode upon a restart of its OsApplication. Thus the

BSW mode manager would not be stuck into a mode previously requested by the

OsApplication before its termination. To support this task, note that RTE offers

mechanisms to handle partition stop and restart wrt. mode machines. For mode man-

agers an "error mode" to be set by RTE can be identified. For mode user partition

the behaviour can also be selected. Furthermore an interaction to BswM to trigger an

action list in case of partition restart can be initiated. Refer to RTE specification for

details.

As a global hint, in any non-trusted OsApplication, which could be terminated, there

shall always be a restart Task which does the following actions:

• Cancel all jobs which can result in an asynchronous notification or shared mem-

ory, I/O access.

• Reset all shared memory with a default value.

• Reset any mode or state residing in another OsApplication and controlled by

this given OsApplication to a default value.

330 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

Please note that some of these actions need to be performed even if an OS-Application

is merely terminated and not restarted. For example, it may still be necessary to stop

all signals and signal groups used by the OsApplication. Otherwise, it may happen

that a bus never goes to sleep.

Consequently, in such a case it is necessary to activate the restart Task to perform

the necessary cleanup even if the OS-Application is only terminated and not restarted.

Calling TerminateApplication(<ownappid>,NO_RESTART) in the restart Task will

finally set the OS-Application to APPLICATION_TERMINATED.

331 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

13 AUTOSAR Service implemented by the OS

13.1 Scope of this Chapter

This chapter is an addition to the specification of the Operating System. Whereas

the other parts of the specification define the behavior and the C-interfaces of the OS

module, this chapter formally specifies the corresponding AUTOSAR Service in terms

of the SWC Template. The interfaces described here will be visible on the VFB and are

used by the RTE generator to create the glue code between the application software

(SWC) and the OS.

13.1.1 Package

The following definitions are interpreted to be in

ARPackage AUTOSAR/Services/Os

13.2 Overview

The AUTOSAR Operating System is normally not used directly by SWCs. Even the

other BSW modules which are below the RTE are using the BSW Scheduler to have

access to OS services. The BSW Scheduler of course uses the OS to implement its

features, e.g. critical sections.

Nevertheless there is one case where it makes sense to allow SWCs access to ser-

vices of the OS:

• Timer services

Since the number of timers in an ECU is limited it make sense to share these units

across several SWCs. The functionality of the timer services of the OS which are

offered to the SWCs are:

• A service to get the current value of a - hardware or software - Counter

• A service which calculates the time difference between the current timer value

and a given (previouls read) timer value

• Both services will return real time values instead of ticks. This limits the access

to the services to those counters which are counting time. Other counters e.g.

counting errors or angles are not accessible.

13.3 Specification of the Ports and Port Interfaces

The detailed port interface can be found in chapter 8.8.

332 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

The notation of possible error codes resulting from server calls follows the approach in

the meta-model. It is a matter of the RTE specification [10], how those error codes will

be passed via the actual API.

333 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

14 Outlook on Memory Protection Configuration

As stated before, memory protection configuration is not standardized yet. Neverthe-

less it seems helpful to contribute a recommendation in this chapter, how the configu-

ration might work.

14.1 Configuration Approach

Both, SW-Components and BSW modules, map code and variables to dedicated, dis-

joined memory sections (see meta-class ObjectFileSection in chapter 7.3 of Software

Component Template [[11]], Version 2.0.1, and module specific sections in chapter 8.2

of Specification of Memory Mapping [[12]], Version 1.0.1).

This essential precondition (avoid an inseparable conglomeration of variables in the

default section) can be used to support configuration of memory protection domains:

• The generator can save for each OS-Application a (processor-specific) maximum

number of output sections for data in a file (to be used in the linker file).

• The generator can uniquely identify the address spaces of the data output sec-

tions with symbols using the naming convention (see memory allocation key-

words _STOP_SEC_VAR and _START_SEC_VAR for start and stop symbols) in

the specification mentioned above.

The input data sections in the object files of an OS-Application can then be assigned to

the output sections (with potential tool support). Usually, this is one segment for global

data, and one segment for code.

To archieve portability, the user shall group all variables belonging to a private data

section (Task/ISR or OS-Application) in separate files.

334 of 335 Document ID 34: AUTOSAR_SWS_OS

Specification of Operating System

AUTOSAR CP R22-11

A Not applicable requirements

[SWS_Os_NA_00767] dThese requirements are not applicable to this specifica-

tion.c(SRS_BSW_00344, SRS_BSW_00404, SRS_BSW_00405, SRS_BSW_00170,

SRS_BSW_00419, SRS_BSW_00383, SRS_BSW_00384, SRS_BSW_00375, SRS_-

BSW_00406, SRS_BSW_00168, SRS_BSW_00407, SRS_BSW_00423, SRS_-

BSW_00337, SRS_BSW_00369, SRS_BSW_00339, SRS_BSW_00422, SRS_-

BSW_00417, SRS_BSW_00409, SRS_BSW_00385, SRS_BSW_00386, SRS_-

BSW_00437, SRS_BSW_00161, SRS_BSW_00162, SRS_BSW_00415, SRS_-

BSW_00325, SRS_BSW_00342, SRS_BSW_00007, SRS_BSW_00413, SRS_-

BSW_00347, SRS_BSW_00441, SRS_BSW_00305, SRS_BSW_00307, SRS_-

BSW_00310, SRS_BSW_00373, SRS_BSW_00327, SRS_BSW_00335, SRS_-

BSW_00350, SRS_BSW_00410, SRS_BSW_00411, SRS_BSW_00314, SRS_-

BSW_00301, SRS_BSW_00302, SRS_BSW_00328, SRS_BSW_00312, SRS_-

BSW_00006, SRS_BSW_00439, SRS_BSW_00357, SRS_BSW_00377, SRS_-

BSW_00378, SRS_BSW_00306, SRS_BSW_00308, SRS_BSW_00309, SRS_-

BSW_00358, SRS_BSW_00414, SRS_BSW_00440, SRS_BSW_00330, SRS_-

BSW_00009, SRS_BSW_00401, SRS_BSW_00172, SRS_BSW_00010, SRS_-

BSW_00333, SRS_BSW_00374, SRS_BSW_00379, SRS_BSW_00003, SRS_-

BSW_00318, SRS_BSW_00321, SRS_BSW_00334, SRS_BSW_00005, SRS_-

BSW_00331, SRS_BSW_00343, SRS_BSW_00388, SRS_BSW_00389, SRS_-

BSW_00390, SRS_BSW_00392, SRS_BSW_00393, SRS_BSW_00394, SRS_-

BSW_00395, SRS_BSW_00396, SRS_BSW_00399, SRS_BSW_00403, SRS_-

BSW_00416, SRS_BSW_00425, SRS_BSW_00432, SRS_BSW_00448, SRS_-

BSW_00449, SRS_BSW_00452, SRS_BSW_00453, SRS_BSW_00454, SRS_-

BSW_00456, SRS_BSW_00457, SRS_BSW_00458, SRS_BSW_00461, SRS_-

BSW_00462, SRS_BSW_00466, SRS_BSW_00469, SRS_BSW_00470, SRS_-

BSW_00471, SRS_BSW_00472, SRS_BSW_00473, SRS_BSW_00478, SRS_-

BSW_00479, SRS_BSW_00481, SRS_BSW_00482, SRS_BSW_00483, SRS_-

BSW_00484, SRS_BSW_00485, SRS_BSW_00486, SRS_BSW_00487, SRS_-

BSW_00490, SRS_BSW_00492, SRS_BSW_00494, SRS_Frt_00032)

335 of 335 Document ID 34: AUTOSAR_SWS_OS