Specification of Operating System Interface

AUTOSAR AP R20-11

Specification of Operating
Document Title System Interface
Document Owner AUTOSAR
Document Responsibility AUTOSAR
Document Identification No 719

Document Status published

Part of AUTOSAR Standard Adaptive Platform
Part of Standard Release R20-11

Document Change History

Date Release Changed by Description
• Uptrace update
AUTOSAR • Clarified Execution Management
2020-11-30 R20-11 Release description
Management • Removed undefined mention of
Unrecoverable State
• Added description of startup and
shutdown of OSI.
AUTOSAR • Clarified that Operating System
2019-11-28 R19-11 Release must allow calling getenv() from C++
Management constructors.
• Document template upgrade.
• Changed Document Status from
Final to published.

AUTOSAR • Clarified that PSE51 following

2019-03-29 19-03 Release POSIX-1003.1-2003 is the
Management currently-targeted version.
• Minor changes in tracing, clean up
AUTOSAR
2018-10-31 18-10 Release • Add Resource Control
Management • Added Shared object support
AUTOSAR
2018-03-29 18-03 Release • Minor changes
Management
AUTOSAR
2017-10-27 17-10 Release • Minor changes, document clean up
Management

1 of 23 Document ID 719: AUTOSAR_SWS_OperatingSystemInterface

 Specification of Operating System Interface
AUTOSAR AP R20-11

AUTOSAR
2017-03-31 17-03 Release • Initial release
Management

2 of 23 Document ID 719: AUTOSAR_SWS_OperatingSystemInterface

 Specification of Operating System Interface
AUTOSAR AP R20-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.

3 of 23 Document ID 719: AUTOSAR_SWS_OperatingSystemInterface

 Specification of Operating System Interface
AUTOSAR AP R20-11

Table of Contents
1 Introduction and Functional Overview 6

2 Acronyms and Abbreviations 7

3 Related Documentation 8
3.1 Input Documents & Related Standards and Norms . . . . . . . . . . . 8
3.2 Further applicable specification . . . . . . . . . . . . . . . . . . . . . . 8
4 Constraints and assumptions 9
4.1 Known Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5 Dependencies to Functional Clusters 10
5.1 Protocol layer dependencies . . . . . . . . . . . . . . . . . . . . . . . . 10
6 Requirements Tracability 11
6.1 Non-applicable requirements . . . . . . . . . . . . . . . . . . . . . . . 12
7 Functional specification 13
7.1 Functional Cluster Lifecycle . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1.1 Operating System Overview . . . . . . . . . . . . . . . . . . 13
7.1.2 Process Handling . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1.3 Scheduling Policies . . . . . . . . . . . . . . . . . . . . . . . 15
7.1.4 Time Triggered Execution . . . . . . . . . . . . . . . . . . . . 15
7.1.5 Device Support . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1.6 Resource control . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.2 Startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.3 Shutdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8 API Specification 19
8.1 C++ language binding Operating System . . . . . . . . . . . . . . . 19
8.1.1 Application Interface C (POSIX PSE51) . . . . . . . . . . . . 19
8.1.2 Application Interface C++11 . . . . . . . . . . . . . . . . . . 20
8.2 API Common Data Types . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.3 API Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9 Service Interfaces 21
9.1 Type definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.2 Provided Service Interfaces . . . . . . . . . . . . . . . . . . . . . . . . 21
9.3 Required Service Interfaces . . . . . . . . . . . . . . . . . . . . . . . . 21
9.4 Application Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
A Appendix 22
A.1 Mentioned Manifest Elements . . . . . . . . . . . . . . . . . . . . . . . 22
A.2 Interfaces to other Functional Clusters (informative) . . . . . . . . . . . 22

4 of 23 Document ID 719: AUTOSAR_SWS_OperatingSystemInterface

 Specification of Operating System Interface
AUTOSAR AP R20-11

A.3 Specification Item History of this document compared to AUTOSAR

R19-03. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
A.3.1 Added Traceables in R19-11 . . . . . . . . . . . . . . . . . . 22
A.3.2 Changed Traceables in R19-11 . . . . . . . . . . . . . . . . . 22
A.3.3 Deleted Traceables in R19-11 . . . . . . . . . . . . . . . . . 23

5 of 23 Document ID 719: AUTOSAR_SWS_OperatingSystemInterface

 Specification of Operating System Interface
AUTOSAR AP R20-11

1 Introduction and Functional Overview

This document is the software specification of the Operating System Interface within
the AUTOSAR Adaptive Platform.
AUTOSAR Adaptive Platform does not specify a new Operating System for highly
performant microcontrollers. Rather, it defines an execution context and programming
interface for use by Adaptive Applications.
Note that this Operating System Interface (OSI) specification contains application in-
terfaces that are part of ARA, the standard application interface of Adaptive Ap-
plication. The OS itself may very well provide other interfaces, such as creating
processes, that are required by Execution Management to start an Application.
However, the interfaces providing such functionality, among others, are not available
as part of ARA and it is defined to be platform implementation dependent.
The OSI provides both C and C++ interfaces. In case of a C program, the applica-
tion’s main source code business logic include C function calls defined in the POSIX
standard, namely PSE51 defined in IEEE1003.13 [1]. During compilation, the compiler
determines which C library from the platform’s operating system provides these C func-
tions and the application’s Executable must be linked against at runtime. In case of
a C++ program, application software component’s source code includes function calls
defined in the C++ Standard and its Standard C++ Library.

6 of 23 Document ID 719: AUTOSAR_SWS_OperatingSystemInterface

 Specification of Operating System Interface
AUTOSAR AP R20-11

2 Acronyms and Abbreviations

The glossary below includes acronyms and abbreviations relevant to the Operating
System Interface that are not included in the [2] AUTOSAR Glossary.

Abbreviation / Acronym: Description:

OSI Operating System Interface
Operating System Interface A Functional Cluster within the Adaptive Platform
Foundation
AUTOSAR Adaptive Platform see [2] AUTOSAR Glossary
Adaptive Platform Foundation see [2] AUTOSAR Glossary
Adaptive Application see [2] AUTOSAR Glossary
Execution Management The element of the AUTOSAR Adaptive Platform responsi-
ble for the ordered startup and shutdown of the AUTOSAR Adap-
tive Platform and Adaptive Applications.
Application see [2] AUTOSAR Glossary
Operating System Software responsible for managing Processes on a Machine
and for providing an interface to hardware resources.
Process see [2] AUTOSAR Glossary
Initial Process A process with management rights, e.g. to determine exit status,
for all processes within the AUTOSAR Adaptive Platform.
Foundation see [2] AUTOSAR Glossary
Machine see [2] AUTOSAR Glossary
Process see [2] AUTOSAR Glossary
Executable see [2] AUTOSAR Glossary
Functional Cluster see [2] AUTOSAR Glossary

7 of 23 Document ID 719: AUTOSAR_SWS_OperatingSystemInterface

 Specification of Operating System Interface
AUTOSAR AP R20-11

3 Related Documentation

3.1 Input Documents & Related Standards and Norms

[1] IEEE Standard for Information Technology- Standardized Application Environment

Profile (AEP)-POSIX Realtime and Embedded Application Support
https://standards.ieee.org/findstds/standard/1003.13-2003.html
[2] Glossary
AUTOSAR_TR_Glossary
[3] Requirements on Operating System Interface
AUTOSAR_RS_OperatingSystemInterface

3.2 Further applicable specification

None.

8 of 23 Document ID 719: AUTOSAR_SWS_OperatingSystemInterface

 Specification of Operating System Interface
AUTOSAR AP R20-11

4 Constraints and assumptions

4.1 Known Limitations

This chapter lists known limitations of this software specification. The intent is to not
only provide a specification of the current state of the Operating System interface
but also an indication how the AUTOSAR Adaptive Platform will evolve in future
releases.
The following functionality is mentioned within this document but is not fully specified
in this release:
• The currently known limitations are the requirements which are listed within
Chapter 6.1.

9 of 23 Document ID 719: AUTOSAR_SWS_OperatingSystemInterface

 Specification of Operating System Interface
AUTOSAR AP R20-11

5 Dependencies to Functional Clusters

There are no dependencies to other AUTOSAR Adaptive Platform standard mod-
ules. Any underlying modules required by OS such as bootloader, BSP (Board Support
Package), HAL (Hardware Abstraction Layer), BIOS (Basic Input/Output System), and
etc., are specific to the Operating System and voluntarily not standardized.

5.1 Protocol layer dependencies

There are no protocol layer dependencies, although low-level protocol support (e.g.
TCP/IP) may be introduced in the future.

10 of 23 Document ID 719: AUTOSAR_SWS_OperatingSystemInterface

 Specification of Operating System Interface
AUTOSAR AP R20-11

6 Requirements Tracability
The following table references the features specified in [3] and links to the fulfillments
of these.
Feature Description Satisfied by
[RS_AP_00111] The AUTOSAR Adaptive Platform shall support [SWS_OSI_01001]
source code portability for AUTOSAR Adaptive [SWS_OSI_01002]
applications.
[RS_AP_00113] No description [SWS_OSI_NA]
[RS_AP_00114] C++ interface shall be compatible with C++14. [SWS_OSI_01002]
[RS_AP_00115] Namespaces. [SWS_OSI_NA]
[RS_AP_00116] Header file name. [SWS_OSI_NA]
[RS_AP_00119] Return values / application errors. [SWS_OSI_NA]
[RS_AP_00120] Method and Function names. [SWS_OSI_NA]
[RS_AP_00121] Parameter names. [SWS_OSI_NA]
[RS_AP_00122] Type names. [SWS_OSI_NA]
[RS_AP_00124] Variable names. [SWS_OSI_NA]
[RS_AP_00125] Enumerator and constant names. [SWS_OSI_NA]
[RS_AP_00127] Usage of ara::core types. [SWS_OSI_NA]
[RS_AP_00128] Error reporting. [SWS_OSI_NA]
[RS_AP_00129] Public types defined by functional clusters shall be [SWS_OSI_NA]
designed to allow implementation without dynamic
memory allocation.
[RS_AP_00130] AUTOSAR Adaptive Platform shall represent a rich [SWS_OSI_NA]
and modern programming environment.
[RS_AP_00132] noexcept behavior of API functions [SWS_OSI_NA]
[RS_AP_00133] noexcept behavior of move and swap operations [SWS_OSI_NA]
[RS_AP_00134] noexcept behavior of class destructors [SWS_OSI_NA]
[RS_AP_00135] Avoidance of shared ownership. [SWS_OSI_NA]
[RS_AP_00136] Usage of string types. [SWS_OSI_NA]
[RS_AP_00137] Connecting run-time interface with model. [SWS_OSI_NA]
[RS_AP_00138] Return type of asynchronous function calls. [SWS_OSI_NA]
[RS_AP_00139] Return type of synchronous function calls. [SWS_OSI_NA]
[RS_OSI_00100] The Operating System Interface provided to [SWS_OSI_01001]
processes shall provide a PSE51-compliant API. [SWS_OSI_01002]
[SWS_OSI_01003]
[SWS_OSI_01006]
[RS_OSI_00103] The Operating System Interface shall support C++. [SWS_OSI_01002]
[SWS_OSI_01015]
[RS_OSI_00104] The Operating System Interface shall support the [SWS_OSI_01001]
reaction on process-external stimuli from devices.
[RS_OSI_00105] The Operating System Interface shall support the [SWS_OSI_01040]
start of Execution Management.
[RS_OSI_00201] The Operating System shall provide mechanisms [SWS_OSI_02000]
for system memory budgeting. [SWS_OSI_02001]
[RS_OSI_00202] The Operating System shall provide mechanisms [SWS_OSI_02000]
for CPU time budgeting. [SWS_OSI_02002]
[RS_OSI_00203] The Operating System should provide [SWS_OSI_01006]
mechanisms for binding processes to CPU cores. [SWS_OSI_01012]

11 of 23 Document ID 719: AUTOSAR_SWS_OperatingSystemInterface

 Specification of Operating System Interface
AUTOSAR AP R20-11

[RS_OSI_00204] The Operating System shall support authorized [SWS_OSI_NA]

operating system object access for the software
entities which are allowed to do so.
[RS_OSI_00206] The Operating System shall provide multi-process [SWS_OSI_01006]
support for isolation of applications. [SWS_OSI_01008]
[SWS_OSI_01009]
[SWS_OSI_01010]
[SWS_OSI_01013]
[SWS_OSI_01014]
[RS_OSI_00207] The Operating System shall provide the [SWS_OSI_01013]
capability to share code and data in an implicit
manner.
[RS_OSI_00208] The Operating System shall only allow [SWS_OSI_NA]
processes to access required functionality.
[RS_SEC_05006] No description [SWS_OSI_02001]

6.1 Non-applicable requirements

[SWS_OSI_NA]{DRAFT} dThese requirements are not applicable as they are not
within the scope of this release.c(RS_OSI_00204, RS_OSI_00208, RS_AP_00113,
RS_AP_00115, RS_AP_00116, RS_AP_00119, RS_AP_00120, RS_AP_00121, RS_-
AP_00122, RS_AP_00124, RS_AP_00125, RS_AP_00127, RS_AP_00128, RS_-
AP_00129, RS_AP_00130, RS_AP_00132, RS_AP_00133, RS_AP_00134, RS_AP_-
00135, RS_AP_00136, RS_AP_00137, RS_AP_00138, RS_AP_00139)

12 of 23 Document ID 719: AUTOSAR_SWS_OperatingSystemInterface

 Specification of Operating System Interface
AUTOSAR AP R20-11

7 Functional specification

7.1 Functional Cluster Lifecycle

7.1.1 Operating System Overview

The real-time Operating System in an embedded automotive ECU offers the foun-
dation for dynamic behavior of the software applications. It manages the scheduling of
processes and events, the data exchange and synchronization between different pro-
cesses and provides features for monitoring and error handling. This chapter describes
requirements addressed to the Operating System. Applications, in particular
Adaptive Applications may not have the system rights to fully use or configure
these aspects directly.

7.1.2 Process Handling

[SWS_OSI_01040] Start Execution Management as Initial Process. dThe Oper-

ating System shall allow starting the Execution Management as the Initial
Process of the AUTOSAR Adaptive Platform.c(RS_OSI_00105)
[SWS_OSI_01006] Multi-Threading Support dThe Operating System shall allow
running multiple execution contexts (threads) such that the process can execute multi-
ple code flows.c(RS_OSI_00100, RS_OSI_00203, RS_OSI_00206)
On multi-core platforms, multiple threads permitted by [SWS_OSI_01006] may execute
concurrently on different cores. All the threads belong to some process, so it is possible
that multiple threads in the same process may execute on multiple cores concurrently.
Additionally, Execution Management requires the ability to bind a specific Process
to a core as part of resource management [SWS_EM_02104].
[SWS_OSI_01012] Specification of Core Affinity dThe Operating System shall
provide mechanisms for binding processes to CPU cores.c(RS_OSI_00203)
In general, a process provides at least the following:
• A main() function as the entry point of the first execution thread of the process.
• A local memory context (address space), providing local, non-shared memory,
that includes at least the code, data and heap of the process.
• Some level of memory protection, such that incorrect or invalid memory accesses
are detected by the underlying Operating System.
• Operating System descriptors permitting access to OS managed resources.
[SWS_OSI_01008] Multi-Process Support dThe Operating System shall support
multiple processes.c(RS_OSI_00206)

13 of 23 Document ID 719: AUTOSAR_SWS_OperatingSystemInterface

 Specification of Operating System Interface
AUTOSAR AP R20-11

[SWS_OSI_01009] Multi-Process Isolation dThe Operating System shall isolate

each process from one another such that an incorrect or invalid memory access is
detected by the Operating System.c(RS_OSI_00206)
[SWS_OSI_01014] Multi-Process Creation Capability Restriction dThe Operat-
ing System shall allow configuring a process to be forbidden from creating other
processes.c(RS_OSI_00206)
[SWS_OSI_01010] Virtual Memory dOperating System shall execute each pro-
cess in a dedicated address space.c(RS_OSI_00206)
Each process has its own logical address space where the code and data are located.
The address may or may not correspond to their underlying physical address space
as the process’s address space is virtualized. In particular, multiple instances of the
same Executable running in different logical address spaces may share the physical
address for its code and read-only data, as they are read-only, to save some physical
memory. The rewritable data, on the other hand, need to be separate, so they are
mapped to different physical addresses.
Shared objects (also sometimes called DLLs) usually consist of code and data usable
from multiple processes simultaneously. When multiple processes use a shared object,
code and read-only data of the shared object is usually mapped in each process but
present only once in system memory, while shared data may be duplicated immediately
or when needed (Copy-on-Write, or CoW).
Shared objects can be used in mainly two ways:
• Implicit loading: at build time, an Executable may be linked against a shared
object ; later on, at load time, the Operating System and its loading framework
enable the mapping and use of the shared object code and data in the process of
the application. This is mainly used for space saving and ease of deploying fixes
in shared code, but sometimes also for licensing reasons. The process itself does
not require any specific capability or knowledge of this shared library existence to
make use of it.
• Explicit loading: at run time, the Process requests the Operating System and
its loading framework to open and load a shared object on the target, and to let it
resolve symbol names and load its code and data. This is usually done for plu-
gin mechanisms where all plugins expose the same shared symbols. The Exe-
cutable itself has no knowledge of the plugins at link time, and typically uses the
dlopen()/dlsym()/dlclose() to enable using the plugin-style loaded shared
object.
[SWS_OSI_01013] Implicit shared object support dThe Operating System shall
allow the use of Implicit loading of shared objects for Executables.c(RS_OSI_00207,
RS_OSI_00206)
Note that for safety, security or other reasons, an Executable may be built fully
statically-linked, and therefore not use the capability to use shared objects.

14 of 23 Document ID 719: AUTOSAR_SWS_OperatingSystemInterface

 Specification of Operating System Interface
AUTOSAR AP R20-11

7.1.3 Scheduling Policies

The Operating System Scheduler is designed to keep all system resources busy allow-
ing multiple software control flows to share the CPU cores in an effective manner. The
main goals of the scheduling mechanisms may be one or more from the following:
• Maximizing throughput in terms of amount of work done per time unit.
• Maximizing responsiveness by minimizing the time between job activation and
actual begin of data processing.
• Maximizing fairness in terms of ensuring appropriate CPU time according with
priority and workload of each job.
• Assuring a timelined and ordered activation of jobs according to some policy-
dependent job execution eligibility (e.g. priority, deadline, tardiness, etc).
In real life these goals are often in conflict, implementing the scheduling mechanisms
is therefore always a compromise.
[SWS_OSI_01003] Default Scheduling Policies dThe AUTOSAR Adaptive Plat-
form Operating System shall support the following scheduling policies defined
in the IEEE1003.1 POSIX standard: SCHED_OTHER, SCHED_FIFO, SCHED_RR.c
(RS_OSI_00100)
In order to overcome the above mentioned conflicts and to achieve portability between
different platforms, the AUTOSAR Adaptive Platform Operating System pro-
vides the following scheduling policies categorized in two groups:
• Fair Scheduling Policies
– SCHED_OTHER
• Real-time Scheduling Policies
– SCHED_FIFO
– SCHED_RR
Since the above mentioned default scheduling policies may not guarantee proper ex-
ecution for all real-time scenarios, the Adaptive Application vendor may provide
additional scheduling policies to fulfill any execution requirement. For example, addi-
tional non-POSIX scheduling policies like SCHED_DEADLINE (Earliest Deadline First
algorithm) could be introduced to satisfy hard real-time requirements.

7.1.4 Time Triggered Execution

POSIX PSE51 provides a means to do time-based periodic processing, using the timer
API (e.g. timer_settime()) along with POSIX signals. However, signals are some-
times discouraged for safety-critical applications, because they disrupt the execution
flow.

15 of 23 Document ID 719: AUTOSAR_SWS_OperatingSystemInterface

 Specification of Operating System Interface
AUTOSAR AP R20-11

Using C++, std::future::wait_until() can be used to realize periodic process-

ing. The TimeSync specification may also be used along with std::future to provide
event generation. However, both of these APIs only allow single-shot, relative alarms,
and efficient, low-overhead requires recurring and/or absolute alarms.
Therefore, these APIs may be extended in the future.

7.1.5 Device Support

The OSI shall support device access as defined in POSIX PSE51.

7.1.6 Resource control

While correct behavior is expected from each application, intentional or unintentional

misbehavior must be contained for system stability. Simultaneously, some level of dy-
namic behavior must be allowed. From a feature perspective, applications can be as-
sembled in groups such that they can follow a similar usage pattern, sharing memory,
CPU time, and in general resources.
[SWS_OSI_02000] ResourceGroup minimum requirement dThe Operating
System shall support the configuration of at least 8 groups of processes in the sys-
tem.c(RS_OSI_00201, RS_OSI_00202)
Depending on the Operating System, the number of usable ResourceGroups may
vary. Furthermore, when OS-level-virtualized containers are used, some Operating
Systems may additionally constrain the number of usable ResourceGroups, with an
extreme of just 1 available ResourceGroup.
[SWS_OSI_02001] Memory ResourceGroups dThe Operating System shall sup-
port a mechanism to define groups of processes that may dynamically allocate memory
from a configuration-defined limit.c(RS_OSI_00201, RS_SEC_05006)
The memory taken in consideration for the limit covers:
• Code and read-only Data from the Executable
• Modifiable Data from the Executable
• Memory used for thread stack for each thread of the process
• Heap
• System memory that is used by the Operating System for holding the kernel
resources allocated to the process (e.g. thread control block, semaphore, page
table entries for MMU mapping, etc)
• Shared memory between processes of the same group
• Implicitly loaded shared objects between processes of the same group

16 of 23 Document ID 719: AUTOSAR_SWS_OperatingSystemInterface

 Specification of Operating System Interface
AUTOSAR AP R20-11

Because memory accounting may differ between Operating Systems, some ele-
ments can be considered inside or outside the memory usage limit of the process
group, in an implementation-specific manner:
• Shared memory between processes of different groups
• Memory-mapped files
• Implicitly loaded shared objects between processes of different groups
[SWS_OSI_02002] CPU ResourceGroups dThe Operating System shall support
a mechanism to define groups of processes that may use a maximum configured
amount of CPU time over a defined period of time.c(RS_OSI_00202)
Because scheduling is done in very different ways depending on the Operating
System, the specific algorithm for scheduling as well as limiting the CPU usage is
not described here.
Example valid group scheduling schemes include (but not limited to):
• Fixed-periodic enablement of processes over a fixed range of time, in a manner
similar to what the ARINC 653 standard defines.
• Processes use time from a quota of time allocated to the group. If no time re-
mains, no thread from the processes in the expired group can be scheduled.
Each period, the quota is replenished to allow more time to be used and corre-
sponding threads to be scheduled again.
• Processes accumulate time usage. Each period or each context switch, time
usage accumulated over a certain count of past periods is calculated. Processes
of each group that used time over a threshold are disabled, and processes of
each group that used time under a threshold are enabled.
Most notably, on some Operating Systems, idle time, which by definition is not re-
quested to be used by any process group, may be distributed to any process, including
those belonging to a group that is considered to be using time over the defined limit.
This is a worthy optimization, but is currently not considered in the specification as a
requirement.

7.2 Startup
The startup steps of an Operating System have to be executed in an
implementation-specific way. These steps include starting any Operating System-
related middleware, including device-drivers and services handling low-level middle-
ware, as well as starting Execution Management.
As an important remark, it is expected that Execution Management will be started
early on during the system boot, ideally as the first process, in order to allow booting
all the required Processes. However, depending on the Operating System, other
system services and supporting middleware may be started before or in parallel. An

17 of 23 Document ID 719: AUTOSAR_SWS_OperatingSystemInterface

 Specification of Operating System Interface
AUTOSAR AP R20-11

example may be a filesystem service, if the Operating System has one that is not
part of its kernel.

7.3 Shutdown
Similarly, shutdown steps for an Operating System are implementation-specific.
They may include flushing some middleware buffers, shutting down some peripherals,
and optionally turn off the entire system, depending on the system configuration.

18 of 23 Document ID 719: AUTOSAR_SWS_OperatingSystemInterface

 Specification of Operating System Interface
AUTOSAR AP R20-11

8 API Specification
The AUTOSAR Adaptive Platform does not specify a new Operating System for
highly performant microcontrollers. Rather, it defines an execution context and pro-
gramming interface for use by Adaptive Applications.

8.1 C++ language binding Operating System

8.1.1 Application Interface C (POSIX PSE51)

[SWS_OSI_01001] POSIX PSE51 Interface dThe OSI shall provide OS functionality

with POSIX PSE51 interface, according to the 1003.13-2003 specification.c(RS_OSI_-
00100, RS_OSI_00104, RS_AP_00111)
Note that PSE51 requires C99 as specified in the standard.
There are several Operating Systems on the market, e.g. Linux, that provide POSIX
compliant interfaces. However Applications are required to use a more restricted
API to the Operating Systems as compared to the platform services and founda-
tion. In particular, the starting assumption is that an Adaptive Application may
use PSE51 as OS interface whereas platform-specific Application may use full
POSIX.
The implementation of platform Foundation and platform services functionality may
use non-PSE51 APIs, even OS specific ones. The use of specific APIs will be left open
to the implementer of the AUTOSAR Adaptive Platform and is not standardized.
In case of a C program, the applications main source code business logic includes
C function calls defined in the POSIX standard. During compilation, the compiler de-
termines which C library from the platforms Operating System provides these C
functions and the applications executable must be linked against at runtime. This Op-
erating System provided C library can implement the POSIX-compliant C function
in two ways:
• The provided C library implements the behavior as part of the library. Then,
the execution of this C function causes no further invocation of the Operating
System with a system call.
• The provided C library implements the behavior through a suitable system call
of the Operating System kernel. In many cases, the function name and be-
havior of the Operating System kernel system call match very closely to the
Operating System provided C library and to the POSIX-specified function def-
initions. For example, in the case of typical Linux distributions, these functions
are provided by glibc library, and by default, the gcc compiler links the glibc
library dynamically.

19 of 23 Document ID 719: AUTOSAR_SWS_OperatingSystemInterface

 Specification of Operating System Interface
AUTOSAR AP R20-11

[SWS_OSI_01015] Availability of environment variables dThe POSIX function

getenv() should return valid values as soon as non-Operating System-provided
functionality can be called, and specifically from within C++ static initializer code.c(RS_-
OSI_00103)

8.1.2 Application Interface C++11

[SWS_OSI_01002] Use of C++ Language dThe OSI shall provide OS functionality

with C++11 Standard Library for Applications written in C++.c(RS_OSI_00100,
RS_OSI_00103, RS_AP_00111, RS_AP_00114)
In case of a C++ program, application software components source code can include
function calls defined in the C++11 Standard and its Standard C++ Library. The C++
Standards defines C++ Standard Library (http://en.cppreference.com/w/cpp), and it
includes Thread support library, Input/output library and others that provide most of
PSE51 functionalites through these C++ interfaces. Some PSE51 functions, such as
setting thread scheduling policies, are not available yet through these C++ Standard
Library and C++ applications need to use PSE51 C interface in conjunction with these
C++ libraries.
In case of Linux and the gcc C++ compiler (g++), the compiler links the libstdc++
library, which provides the defined Standard C++ library functions. The libstdc++ li-
brary itself depends on the glibc library, i.e., the libstdc++ implementation includes
function calls to the glibc library.

8.2 API Common Data Types

There are no additional data types specific to the AUTOSAR Adaptive Platform
defined in this document. Please refer to the SWS_AdaptiveCore document for base
AUTOSAR Adaptive Platform definitions.

8.3 API Reference

There are no additional APIs specific to the AUTOSAR Adaptive Platform defined
in this document. Please refer to the SWS_AdaptiveCore document for base AUTOSAR
Adaptive Platform definitions.

20 of 23 Document ID 719: AUTOSAR_SWS_OperatingSystemInterface

 Specification of Operating System Interface
AUTOSAR AP R20-11

9 Service Interfaces
Operating System does not define any AdaptivePlatform Service Interface.

9.1 Type definitions

Operating System does not define any AdaptivePlatform Service Interface type
definitions.

9.2 Provided Service Interfaces

Operating System does not define any AdaptivePlatform Service Interface.

9.3 Required Service Interfaces

Operating System does not require any AdaptivePlatform Service Interface.

9.4 Application Errors

Operating System provides error reporting through its C/C++ Application Interface.

21 of 23 Document ID 719: AUTOSAR_SWS_OperatingSystemInterface

 Specification of Operating System Interface
AUTOSAR AP R20-11

A Appendix

A.1 Mentioned Manifest Elements

This section contains the Manifest Elements mentioned in this documentation. It also
contains a set of class tables representing meta-classes mentioned in the context of
this document but which are not contained directly in the scope of describing specific
meta-model semantics.
Class ResourceGroup
Package M2::AUTOSARTemplates::AdaptivePlatform::PlatformModuleDeployment::AdaptiveModule
Implementation
Note This meta-class represents a resource group that limits the resource usage of a collection of processes.
Tags:atp.Status=draft
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
cpuUsage PositiveInteger 0..1 attr CPU resource limit in percentage of the total CPU
capacity on the machine.
memUsage PositiveInteger 0..1 attr Memory limit in bytes.

Table A.1: ResourceGroup

A.2 Interfaces to other Functional Clusters (informative)

Other Functional Clusters use the standard C/C++ as well as POSIX APIs to
provide their public APIs. They may additionally use Operating System-specific
APIs to implement their functionality.

A.3 Specification Item History of this document compared to

AUTOSAR R19-03.

A.3.1 Added Traceables in R19-11

none

A.3.2 Changed Traceables in R19-11

none

22 of 23 Document ID 719: AUTOSAR_SWS_OperatingSystemInterface

 Specification of Operating System Interface
AUTOSAR AP R20-11

A.3.3 Deleted Traceables in R19-11

none

23 of 23 Document ID 719: AUTOSAR_SWS_OperatingSystemInterface