AUTOSAR OS

Via the system service CallTrustedFunction (service ID 0x02), a trusted or non-trusted OS-Application can call a defined trusted function for execution [SWS_Os_00097]. The interface is provided via the header Os.h [SWS_Os_00097].

The call requires passing two input parameters [SWS_Os_00097]:

• FunctionIndex (type TrustedFunctionIndexType): Designates the index of the function to be called [SWS_Os_00097].
• FunctionParams (type TrustedFunctionParameterRefType): Passes a pointer to the parameters of the target function; if no arguments are required, a NULL pointer must be passed [SWS_Os_00097].

With regard to timing behavior, execution depends on the target routine: If the called function is synchronous, the service behaves synchronously as well [SWS_Os_00097]. The function is implemented reentrantly, but may cause rescheduling of the operating system during execution [SWS_Os_00097].

As return value, the service provides a status value of type StatusType [SWS_Os_00097]:

• E_OK: Execution was successful and error-free [SWS_Os_00097].
• E_OS_SERVICEID: No valid function is assigned to the passed index [SWS_Os_00097].

The function CheckISRMemoryAccess is a synchronous and reentrant system service of the OS module ([SWS_Os_00512]). It serves to check the memory access rights of a specified ISR for a specific memory area at runtime.

Usage and Parameters

The call of CheckISRMemoryAccess expects three input parameters ([SWS_Os_00512]):

• ISRID: Reference to the ISR to be checked (ISRType).
• Address: Start address of the memory area to be examined (MemoryStartAddressType).
• Size: Size of the memory area (MemorySizeType).

As return value, the service provides the type AccessType. This return value contains the access rights (read, write, execute) to the specified area and additionally indicates whether the memory area is part of the stack area ([SWS_Os_00512]).

Concurrency and Integration

According to the specification, the function has the service ID 0x03 and is declared as reentrant ([SWS_Os_00512]). It is available via header Os.h ([SWS_Os_00512]). Specific error codes or explicit feedback to DET/DEM are not listed in the present specification excerpt.

The function CheckTaskMemoryAccess represents a synchronous service of the operating system that is provided via the header Os.h and has the service ID 0x04 [SWS_Os_00513]. It serves to query the memory access rights of a specific task for a particular memory segment [SWS_Os_00513].

Parameters and Return Values

When called, the service accepts three input parameters [SWS_Os_00513]:

• Task ID (of type TaskType): Reference to the task whose access rights are to be checked.
• Address (of type MemoryStartAddressType): The start address of the memory area to be checked.
• Size (of type MemorySizeType): The size of the memory area to be checked.

As a return value, the service returns a variable of type AccessType [SWS_Os_00513]. This return value contains information as to whether the specified memory area is accessible to the task with write, read, or execute permissions, and additionally indicates whether the area is part of the stack area [SWS_Os_00513]. Additional error codes or DET notifications are not specified for this service.

Concurrency and Interaction

The service is specified as reentrant and can therefore be used safely in concurrent execution contexts [SWS_Os_00513]. While CheckTaskMemoryAccess queries the permissions for memory areas at runtime, the AUTOSAR standard defines interfaces and data structures in ARTI module descriptions through which debugging tools can acquire and evaluate states and attributes of operating system objects [SWS_Os_00829].

Usage and Semantics

The function CheckObjectAccess ([SWS_Os_00256]) synchronously determines whether a specific OS-Application has the authorization to use the ID of an operating system object in API calls. The input parameter ApplID of type ApplicationType ([SWS_Os_00256]) serves to identify the application. ObjectType (type ObjectTypeType) defines which type of object is to be checked; Task, Resource, Counter, Alarm, and Schedule Table are supported ([SWS_Os_00256]). The third parameter is the object to be examined itself via the variable parameter list ... ([SWS_Os_00256]).

As a return value, the function provides the type ObjectAccessType: If access by the application to the object is permitted, ACCESS is returned, otherwise NO_ACCESS ([SWS_Os_00256]). The service is declared via the header Os.h and has the service ID 0x05 ([SWS_Os_00256]).

Concurrency, Error Handling, and Interaction

The service is specified as reentrant and can therefore be called in concurrent execution contexts ([SWS_Os_00256]). Specific error codes, return values for error states, or notifications to DET or DEM are not provided for this function in the specification ([SWS_Os_00256]).

Interpretation: The variable argument ... is likely to pass the concrete identifier of the object matching ObjectType in the implementation. Question Q-5cb52ff94bb07826 (open) The checked operating system objects are also reflected in the ARTI debugging information, which captures and evaluates attributes and states of operating system objects ([SWS_Os_00829]).

use

The synchronous system function CheckObjectOwnership serves to determine which OS-Application a specific operating system object belongs to [SWS_Os_00017]. Objects queryable via this service include tasks, interrupt service routines (ISRs), counters, alarms, and schedule tables [SWS_Os_00017].

The function is available via the header file Os.h and has the service ID 0x06 [SWS_Os_00017]. When used, the function accepts two input parameters:

• ObjectType: As an input parameter of type ObjectTypeType, identifies the type of the subsequently passed operating system object [SWS_Os_00017].
• ...: Passes the concrete object to be examined to the service [SWS_Os_00017].

As a return value, the function provides the data type ApplicationType [SWS_Os_00017]. This contains the identifier of the OS-Application to which the checked object is assigned [SWS_Os_00017].

Error Handling and Execution Properties

If the queried object does not exist in the system, the service returns the return value INVALID_OSAPPLICATION [SWS_Os_00017].

With regard to concurrency behavior, CheckObjectOwnership is specified as reentrant and operates completely synchronously [SWS_Os_00017]. Input and output parameters (inout or out) do not exist besides the return value [SWS_Os_00017].

Usage and Parameters

The system service StartScheduleTableRel starts the processing of a schedule table relative to the current counter value (\"Now\") of the underlying counter [SWS_Os_00347]. The call is executed synchronously and is available via interface Os.h with service ID 0x07 [SWS_Os_00347].

• ScheduleTableID (input, ScheduleTableType): Identifier of the schedule table to be started [SWS_Os_00347].
• Offset (input, TickType): Relative number of counter ticks on the counter before processing of the table begins [SWS_Os_00347].

Return Values and Error Handling

The function returns a status code of type StatusType [SWS_Os_00347]:

• E_OK: The schedule table was started without error [SWS_Os_00347].
• E_OS_STATE: The specified schedule table has already been started [SWS_Os_00347].
• E_OS_ID (only with status EXTENDED): The specified ScheduleTableID is invalid [SWS_Os_00347].
• E_OS_VALUE (only with status EXTENDED): The parameter Offset is equal to 0 or exceeds the value (OsCounterMaxAllowedValue - InitialOffset) [SWS_Os_00347].

Concurrency and Limitations

The function is specified as reentrant [SWS_Os_00347]. No output or input/output parameters exist [SWS_Os_00347].

The synchronous and reentrant function StartScheduleTableAbs serves to start a Schedule Table at a specified absolute counter value on the underlying counter ([SWS_Os_00358]). The service is available via header Os.h and is identified via service ID 0x08 ([SWS_Os_00358]).

Two input parameters are passed upon the call ([SWS_Os_00358]):

• ScheduleTableID: Identifier of the Schedule Table to be started.
• Start: Absolute counter tick value at which the Schedule Table is started.

As return value, the function provides the status of type StatusType ([SWS_Os_00358]):

• E_OK: The start operation was successful.
• E_OS_STATE: The specified Schedule Table was already started previously.
• E_OS_ID: The passed ScheduleTableID is invalid (only returned in status EXTENDED).
• E_OS_VALUE: The value of Start exceeds the maximum permitted counter value OsCounterMaxAllowedValue (only returned in status EXTENDED).

Regarding interaction, the state and dynamic attributes of operating system objects such as Schedule Tables can be evaluated and displayed by connected debugging tools via ARTI module descriptions ([SWS_Os_00829]). Interpretation: The call context is likely to comprise primarily task levels, since no explicit restriction is stated in the specification excerpt. Question Q-213de28d0345ccb1 (open)

The synchronous system function StopScheduleTable ([SWS_Os_00006]) immediately aborts the processing of a running schedule table at any processing point. The service is declared in header Os.h and has the service ID 0x09 ([SWS_Os_00006]). The only input parameter is ScheduleTableID of type ScheduleTableType, which specifies the schedule table to be stopped; input/output or pure output parameters do not exist ([SWS_Os_00006]).

The synchronous call provides a status code of type StatusType as return value ([SWS_Os_00006]):

• E_OK: Processing of the schedule table was stopped without error ([SWS_Os_00006]).
• E_OS_NOFUNC: The specified schedule table was already in the stopped state ([SWS_Os_00006]).
• E_OS_ID: The passed identifier ScheduleTableID is invalid. According to the specification, this return value is only generated in status EXTENDED ([SWS_Os_00006]).

The function is defined as reentrant ([SWS_Os_00006]). Interpretation: Given the declared reentrancy, the synchronous call is likely permissible from multiple OS contexts, although specific context restrictions are missing in the present specification excerpt. Question Q-9cb147c4bc7dba7e (open) For runtime monitoring, the state and dynamic attributes of OS objects such as schedule tables can be transmitted to connected debugging and analysis tools via ARTI description files ([SWS_Os_00829]).

The function NextScheduleTable serves to synchronously switch processing from a running schedule table to a next schedule table [SWS_Os_00191]. The service is designed to be reentrant and is declared via header Os.h [SWS_Os_00191].

Parameters and Call

Two input parameters of type ScheduleTableType are passed to the call [SWS_Os_00191]:

• ScheduleTableID_From: Identifier of the currently processed schedule table [SWS_Os_00191].
• ScheduleTableID_To: Identifier of the schedule table that provides the subsequent sequence of expiry points [SWS_Os_00191].

Return Values and Error Handling

The function returns a status value of type StatusType [SWS_Os_00191]:

• E_OK: The switch request was issued without error [SWS_Os_00191].
• E_OS_ID: Returned exclusively when EXTENDED status is configured, if at least one of the passed table identifiers is invalid [SWS_Os_00191].
• E_OS_NOFUNC: The source table ScheduleTableID_From is not in the started state [SWS_Os_00191].
• E_OS_STATE: The target table ScheduleTableID_To is already actively started or already marked as next schedule table [SWS_Os_00191].

Interaction and Diagnosis

For observation and analysis of the operating system, ARTI module descriptions support corresponding ORTI containers, allowing debugging tools to evaluate and display, among other things, dynamic states of operating system objects [SWS_Os_00829].

use

The system service StartScheduleTableSynchron serves to synchronously start an explicitly synchronized schedule table [SWS_Os_00201]. The function is declared in header file Os.h and has the service ID 0x0b [SWS_Os_00201]. As its only passed parameter, the function expects the input parameter ScheduleTableID of type ScheduleTableType, which uniquely references the table to be started [SWS_Os_00201]. Input/output or pure output parameters are not present [SWS_Os_00201]. Processing is synchronous and returns a return value of type StatusType [SWS_Os_00201].

Error handling

In the error-free execution flow, the function call returns the status code E_OK [SWS_Os_00201]. In the event of errors, the following return values are specified:

• E_OS_STATE: The specified schedule table is already in the started state and cannot be synchronously started again [SWS_Os_00201].
• E_OS_ID: The passed ScheduleTableID is invalid [SWS_Os_00201]. This error check and error message is active exclusively in EXTENDED status [SWS_Os_00201].

Concurrency and Limitations

The function is specified as reentrant [SWS_Os_00201]. Since repeated calls for an already active table are rejected with E_OS_STATE, the caller must ensure that the target table is not already running prior to the call [SWS_Os_00201].

Interaction

State transitions and dynamic properties of operating system objects can be tracked for test and diagnostic tools via ARTI module description files and ORTI containers [SWS_Os_00829]. External debuggers use these descriptions to evaluate the internal status of OS objects at runtime [SWS_Os_00829].

The synchronous and reentrant operating system service SyncScheduleTable serves to pass a counter value to a schedule table and start the synchronization process ([SWS_Os_00199]). The function is provided via header file Os.h ([SWS_Os_00199]).

Parameters and Return Values

The function expects two input parameters ([SWS_Os_00199]):

• Schedule Table ID: Identifier of the schedule table to be synchronized of type ScheduleTableType ([SWS_Os_00199]).
• Value: Current counter value of the synchronization counter of type TickType ([SWS_Os_00199]).

The return value of type StatusType indicates error-free execution with E_OK ([SWS_Os_00199]).

Error Handling and Boundary Conditions

If the table is in state SCHEDULETABLE_STOPPED at the time of the call, the error E_OS_STATE is returned ([SWS_Os_00199]). If the operating system is configured in EXTENDED status, further checks take effect ([SWS_Os_00199]):

• E_OS_ID: The specified table ID is invalid, or the table cannot be synchronized because Os Schedule Tbl Sync Strategy is unconfigured or set to IMPLICIT ([SWS_Os_00199]).
• E_OS_VALUE: The passed counter value Value is outside the permitted range ([SWS_Os_00199]).

Interaction and Diagnosis

States and dynamic attributes of operating system objects such as schedule tables can be evaluated by connected debugging and diagnostic tools via ARTI module descriptions and ORTI containers ([SWS_Os_00829]).

use

The synchronous operating system function IncrementCounter serves to explicitly advance a software counter [SWS_Os_00399]. It expects the identifier CounterID of type CounterType as an input parameter, modifies no further parameters, and is available via the header Os.h [SWS_Os_00399]. It must be noted that the call can cause an immediate rescheduling of the operating system [SWS_Os_00399].

Error handling

The return value of type StatusType provides information about the success of the operation: In normal operation, E_OK reports error-free execution [SWS_Os_00399]. When extended status checking (EXTENDED status) is activated, the service returns E_OS_ID if an invalid counter ID was specified or if the referenced counter is implemented in hardware and therefore cannot be incremented by software [SWS_Os_00399].

Concurrency and Diagnostics

The function is designed as reentrant and may thus be called concurrently [SWS_Os_00399]. Possible rescheduling is likely to Interpretation: occur when advancing the counter triggers dependent actions such as alarm expiries or task activations. Question Q-9004b5ced9b96230 (open) For observing operating system objects such as counters as well as their dynamic state, ARTI module descriptions support connected analysis tools during runtime monitoring [SWS_Os_00829].

The synchronous and reentrant function TerminateApplication serves to terminate an OS-Application and is available via header file Os.h [SWS_Os_00258]. The call is permitted from the context of a task, a category 2 ISR, as well as an application-specific error hook [SWS_Os_00258].

The identifier of the target application (Application) and the restart behavior (Restart Option) are passed as input parameters [SWS_Os_00258]:

• If the caller itself belongs to the application specified in Application, the execution leads to self-termination [SWS_Os_00258].
• Via Restart Option, it is defined whether the OS-Application is to be restarted subsequently (RESTART) or not (NO_RESTART) [SWS_Os_00258].

The function returns a status value of type StatusType [SWS_Os_00258]:

• E_OK indicates error-free termination [SWS_Os_00258].
• E_OS_STATE indicates that the current state of Application does not allow termination [SWS_Os_00258].
• In EXTENDED status, additional error checks are performed: E_OS_ID for an invalid application ID, E_OS_VALUE for an invalid parameter value for Restart Option, and E_OS_ACCESS if the caller lacks permission to terminate Application [SWS_Os_00258].

use

The synchronous system service AllowAccess (service ID 0x13) serves to set the state of the caller's own OS-Application from APPLICATION_RESTARTING to APPLICATION_ACCESSIBLE ([SWS_Os_00501]). The function is available via the header file Os.h, expects no parameters, and returns a status value of type StatusType ([SWS_Os_00501]). Upon successful execution of the state change, the call returns the return value E_OK ([SWS_Os_00501]).

Error Handling and Concurrency

If the calling OS-Application is not in the state APPLICATION_RESTARTING, execution fails and the function returns the error value E_OS_STATE ([SWS_Os_00501]). Specific DET or DEM notifications are not defined in the specification for this service. With regard to concurrency behavior, the function is classified as reentrant and can therefore be executed safely in parallel sequences ([SWS_Os_00501]).

Interaction and Diagnosis

Interpretation: The call is likely to take place typically at the end of an application's restart phase, as soon as all preparations are completed and other applications are permitted to access the resources again. Question Q-f43a3f702d5d2428 (open) Within the scope of system diagnostics, the dynamic states of the operating system and the associated OS objects can be evaluated and visualized via standardized ARTI description files and associated debug tools ([SWS_Os_00829]).

The synchronous function StartCore starts the processor core specified via parameter Core ID [SWS_Os_00676]. The function has no direct return value, but instead passes the result of the execution to the caller via the OUT parameter Status [SWS_Os_00676]. If a core was started using this function, Start OS must subsequently be called on the core concerned [SWS_Os_00676].

Fixed restrictions apply to the call context and concurrency: StartCore is specified as non-reentrant (Non Reentrant) [SWS_Os_00676]. A call after starting the operating system via Start OS() is not supported [SWS_Os_00676]. The service is implemented synchronously and is provided via header file Os.h with service ID 0x17 [SWS_Os_00676].

Error handling is performed via parameter Status, which can take the following values depending on the status configuration [SWS_Os_00676]:

• In standard status, E_OK indicates error-free execution [SWS_Os_00676].
• In extended status (extended status), E_OK likewise confirms a successful start [SWS_Os_00676].
• E_OS_ID reports that the passed Core ID is invalid [SWS_Os_00676].
• E_OS_ACCESS indicates an impermissible call after the start of the operating system [SWS_Os_00676].
• E_OS_STATE indicates that the requested processor core is already activated [SWS_Os_00676].

Usage and Call Context

The synchronous and non-reentrant function StartNonCore starts the processor core specified via the parameter CoreID [SWS_Os_00682]. It may be called after the start of the operating system via StartOS() and is available via the header file Os.h [SWS_Os_00682]. Via the output parameter Status, the caller can check whether the startup procedure was successful [SWS_Os_00682].

Error Handling and Status Values

The function has no direct return value, but reports the result of the execution back via the pointer parameter Status [SWS_Os_00682]:

• E_OK: The operation was executed successfully and without error [SWS_Os_00682].
• E_OS_ID: The specified CoreID is invalid (in standard status) [SWS_Os_00682].
• E_OS_STATE: The specified processor core is already activated (in standard status) [SWS_Os_00682].

Restrictions and Sequence Conditions

As a non-reentrant interface, StartNonCore must not be executed concurrently [SWS_Os_00682]. In addition, there is a strict requirement that StartOS must under no circumstances be called on processor cores that have been activated via this function; otherwise, system behavior is unspecified [SWS_Os_00682].

The synchronous and reentrant operating system function GetSpinlock ([SWS_Os_00686]) serves to occupy a spinlock variable via the passed parameter SpinlockId (type SpinlockIdType). During execution, the function uses an active polling mechanism (\"busy waiting\") without triggering de-scheduling of the calling task ([SWS_Os_00686]).

The function returns only after the lock has been successfully acquired or an error has occurred. As return value, GetSpinlock provides the StatusType ([SWS_Os_00686]):

• E_OK: The lock was occupied without error (in standard and extended status).
• E_OS_ID: The passed SpinlockId is invalid (only in extended status).
• E_OS_INTERFERENCE_DEADLOCK: A task attempts to occupy the spinlock while it is already occupied by a task on the same Core (only in Extended status).
• E_OS_NESTING_DEADLOCK: A task attempts to request the spinlock while a task of the same core already holds another spinlock, which could cause a deadlock (only in extended status).
• E_OS_ACCESS: The specified spinlock cannot be accessed (only in extended status).

In the context of system monitoring and error analysis, the operating system provides dynamic status information about OS objects, which, according to [SWS_Os_00829], can be evaluated for debug tools via ARTI and ORTI containers; spinlock blocking situations can presumably also be traced in this way. Question Q-bac194d4132f6e88 (open)

The synchronous and reentrant function ReleaseSpinlock releases a previously occupied spinlock variable ([SWS_Os_00695]). The spinlock instance to be released is specified via the input parameter SpinlockId of type SpinlockIdType ([SWS_Os_00695]).

Sequence Conditions and Restrictions

Strict timing and structural requirements apply to the call ([SWS_Os_00695]):

• Before terminating a task, all spinlock variables previously occupied using GetSpinlock() must be released again ([SWS_Os_00695]).
• Before calling WaitEvent, all held spinlocks must be released without exception ([SWS_Os_00695]).
• The release must take place in the correct nesting order; an attempt to release while superior spinlocks or resources are still occupied fails ([SWS_Os_00695]).

Return Values and Error Handling

In case of success, the service returns E_OK in both standard and extended status ([SWS_Os_00695]). In extended status, specific error codes are defined ([SWS_Os_00695]):

• E_OS_ID: The passed SpinlockId is invalid ([SWS_Os_00695]).
• E_OS_STATE: The spinlock is not occupied by the calling task ([SWS_Os_00695]).
• E_OS_ACCESS: The spinlock cannot be accessed ([SWS_Os_00695]).
• E_OS_NOFUNC: Attempt to release the spinlock while another spinlock or resource must still be released first ([SWS_Os_00695]).

The function is available via the header Os.h ([SWS_Os_00695]). ARTI description files support ORTI containers for the dynamic status and performance evaluation of operating system objects ([SWS_Os_00829]).

The synchronous and reentrant operating system function TryToGetSpinlock serves to occupy a spinlock instance non-blockingly via the header Os.h [SWS_Os_00703]. It provides the same basic functionality as GetSpinlock, but does not busy-wait if the requested spinlock is already occupied by a TASK on another Core [SWS_Os_00703].

Parameters and Return Values

• SpinlockId (input): References the specific spinlock instance to be locked [SWS_Os_00703].
• Success (output): Indicates via type TryToGetSpinlockType* whether the lock could be occupied or not [SWS_Os_00703]. If the lock is occupied on another Core, the function sets this parameter accordingly and returns with E_OK [SWS_Os_00703].
• Return value: Returns E_OK in standard and extended status if no error is present [SWS_Os_00703].

Error Handling and Boundary Conditions

In extended status, the operating system checks for invalid calls and deadlock scenarios [SWS_Os_00703]:

• E_OS_ID: The passed SpinlockId is invalid [SWS_Os_00703].
• E_OS_ACCESS: The spinlock cannot be accessed [SWS_Os_00703].
• E_OS_INTERFERENCE_DEADLOCK: A TASK attempts to occupy the lock while the same lock is already held by a TASK on the same Core [SWS_Os_00703].
• E_OS_NESTING_DEADLOCK: A TASK attempts to occupy a spinlock while already holding another spinlock, which could lead to a deadlock [SWS_Os_00703].

The synchronous system function ShutdownAllCores with the service ID 0x1c serves the controlled and complete shutdown of the AUTOSAR operating system across all available processor cores ([SWS_Os_00713]). As soon as the service is called, the function forces a shutdown on all other Cores, so that the operating system is shut down on all AUTOSAR cores ([SWS_Os_00713]).

Call Context and Concurrency

The function is declared in the header Os.h and specified as reentrant ([SWS_Os_00713]). Calling ShutdownAllCores is unrestricted and permitted both at task level (TASK level) and at interrupt level (ISR level) ([SWS_Os_00713]). In addition, the service can also be executed internally by the operating system directly through the AUTOSAR OS ([SWS_Os_00713]).

Parameters and Control Flow

The interface expects Error of type StatusType as its only input parameter ([SWS_Os_00713]). A valid error code supported by the AUTOSAR operating system must mandatory be passed for this parameter ([SWS_Os_00713]). Output or input/output parameters do not exist ([SWS_Os_00713]). Since the function never returns to the caller after triggering the system-wide shutdown, it has no return value (void) ([SWS_Os_00713]).

The synchronous function ControlIdle allows the caller to define the action that is executed during the idle time of the operating system (when neither a task nor an ISR is active) [SWS_Os_00769]. This primarily serves to implement energy saving measures. The actual idle modes are hardware-dependent and not standardized; the default mode on each processor core is IDLE_NO_HALT [SWS_Os_00769]. The interface is provided via the header file Os.h [SWS_Os_00769].

The function expects two input parameters:

• CoreID (of type CoreIdType): Selects the processor core whose idle mode is to be set [SWS_Os_00769].
• IdleMode (of type IdleModeType): Determines the mode to be executed during the idle time [SWS_Os_00769].

If valid parameters were passed and no error occurred, the function returns E_OK [SWS_Os_00769], [SWS_Os_00770]. If the specified CoreID or IdleMode is invalid—for example because the referenced core does not exist or the mode is unknown—the call in the EXTENDED status returns the error code E_OS_ID [SWS_Os_00769], [SWS_Os_00771]. On single-core systems, the check of parameter CoreID is omitted [SWS_Os_00771].

Regarding concurrency, the function is specified as non-reentrant (Non Reentrant) [SWS_Os_00769]. Interpretation: Callers must therefore ensure that calls to ControlIdle do not occur simultaneously or uncoordinated from different execution contexts. Question Q-7f239cb54752e826 (open)

use

The function ReadPeripheral (listed in the declaration as ReadPeripheral8) serves to synchronously read out a memory address within a defined hardware peripheral area [SWS_Os_91013]. The interface is available via the header file Os.h [SWS_Os_91013]. As input parameters, the service expects the area reference Area of type AreaIdType and the destination address Address as a pointer to const uint8 [SWS_Os_91013]. The read content of the memory location is provided via the output parameter ReadValue [SWS_Os_91013].

Error handling

The service returns a status code of type StatusType, where E_OK indicates error-free execution [SWS_Os_91013]. When extended status checking (EXTENDED status) is activated, erroneous calls are differentiated on the basis of specific error values [SWS_Os_91013]:

• E_OS_ID: The passed area identifier Area lies outside the valid range [SWS_Os_91013].
• E_OS_VALUE: The specified memory address Address does not belong to the specified peripheral area [SWS_Os_91013].
• E_OS_CALLEVEL: The call was made from an inadmissible context [SWS_Os_91013].
• E_OS_ACCESS: The calling task or ISR is likely not to have the required permission to access the area (interpretation) [SWS_Os_91013]. Question Q-19e2c22110352ebb (open)

Concurrency and Limitations

The API service has the service ID 0x28, operates synchronously, and is designed to be reentrant [SWS_Os_91013]. Calls are only permitted from permissible task or ISR contexts; inadmissible calls are rejected in extended status with E_OS_CALLEVEL [SWS_Os_91013].

The synchronous and reentrant operating system function ReadPeripheral16 serves to read the 16-bit value of a specified memory address within a defined peripheral area [SWS_Os_91015]. The system service is defined under service ID 0x29 and available via the header file Os.h [SWS_Os_91015].

Usage and Parameters

The reference to the hardware peripheral area (Area of type AreaIdType) as well as the target address in memory (Address of type const uint16*) are passed to the service as input parameters [SWS_Os_91015]. The 16-bit content determined at the memory address is provided via the output parameter Read Value of pointer type uint16* [SWS_Os_91015]. Upon error-free execution, the function returns the return value E_OK of type StatusType [SWS_Os_91015].

Error Handling and Access Restrictions

In EXTENDED status, the operating system checks the validity of the call and reports errors via specific status codes [SWS_Os_91015]:

• E_OS_ID: The passed area identifier Area lies outside the valid range [SWS_Os_91015].
• E_OS_VALUE: The specified memory address Address does not belong to the specified peripheral area Area [SWS_Os_91015].
• E_OS_CALLEVEL: The call was made from a context not permitted for the API function [SWS_Os_91015].
• E_OS_ACCESS: The calling task or interrupt service routine (ISR) is not authorized to access the specified area [SWS_Os_91015].

use

The synchronous and reentrant function ReadPeripheral32 reads the content of a specified memory address ([SWS_Os_91014]). The caller passes the reference to the hardware peripheral area via the parameter Area and the desired memory address via Address ([SWS_Os_91014]). The 32-bit value read at this address is provided synchronously via the output parameter ReadValue ([SWS_Os_91014]). The interface is made available via the header Os.h ([SWS_Os_91014]).

Error handling

The service returns a status value of type StatusType. Upon error-free execution, it returns E_OK ([SWS_Os_91014]). If the extended status is configured (EXTENDED status), the following error codes are returned ([SWS_Os_91014]):

• E_OS_ID: The passed area identifier Area is outside the valid range ([SWS_Os_91014]).
• E_OS_VALUE: The specified address Address does not belong to the specified area Area ([SWS_Os_91014]).
• E_OS_CALLEVEL: The function was called from an invalid call context ([SWS_Os_91014]).
• E_OS_ACCESS: The calling task or calling ISR does not have the required access permission; according to interpretation, this likely refers to the peripheral area ([SWS_Os_91014]). Question Q-e5893b29acc5133a (open)

Concurrency and Limitations

ReadPeripheral32 is specified as reentrant and can be called in parallel by multiple control flows ([SWS_Os_91014]). Since the service operates synchronously, the call only returns after the read operation is complete ([SWS_Os_91014]). Callers must pass valid memory pointers and ensure that the call originates from a context permitted for the OS API ([SWS_Os_91014]).

use

The function WritePeripheral (also referred to in the specification as Write Peripheral8) is a synchronous and reentrant service of the operating system to write a value to a specified memory address of a peripheral area [SWS_Os_91010]. The declaration is provided via the header file Os.h [SWS_Os_91010]. The call expects as parameters the reference to the hardware peripheral area (Area of type AreaIdType), the memory address (Address of type uint8*), and the value to be written (Write Value of type uint8) [SWS_Os_91010]. Interpretation: Although Write Value is listed in tabular form among the output parameters in the specification text, based on the pass-by-value in the signature and the description it is likely the input value to be written. Question Q-619c69ba7a85ed92 (open)

Error handling

The function returns a status of type StatusType [SWS_Os_91010]:

• E_OK: The write operation was performed without error [SWS_Os_91010].
• E_OS_ID: The passed area ID is outside the valid range (in extended status) [SWS_Os_91010].
• E_OS_VALUE: The target address does not belong to the specified area (in extended status) [SWS_Os_91010].
• E_OS_CALLEVEL: Invalid call context of the API function (in extended status) [SWS_Os_91010].
• E_OS_ACCESS: The calling task or ISR does not have access permission for the area [SWS_Os_91010].

Concurrency and Limitations

The call is processed synchronously and is reentrant [SWS_Os_91010]. Callers must ensure that the executing task or ISR acts from a valid context and has the necessary access rights for the addressed peripheral area [SWS_Os_91010].

The synchronous and reentrant operating system function WritePeripheral16 ([SWS_Os_91012]) serves to write a 16-bit value to a memory address of a peripheral area. The service is provided via the header Os.h and has the service ID 0x2c.

Usage and Parameters

When calling WritePeripheral16, the caller passes the identifier of the target hardware area (Area of type AreaIdType), the destination address (Address of type uint16*), and the value to be written (Write Value of type uint16, which, despite being designated in tabular form as an out parameter in the signature, presumably serves as pass-by-value) according to [SWS_Os_91012]. Question Q-2edc50ae2e7fd0b0 (open) The service is executed synchronously and returns a status value of type StatusType.

Error handling

In case of success, the function returns E_OK. Under status EXTENDED, the following error codes are specified ([SWS_Os_91012]):

• E_OS_ID: The passed area identifier (Area) lies outside the valid range.
• E_OS_VALUE: The destination address (Address) does not belong to the specified peripheral area.
• E_OS_CALLEVEL: The function was called from an inadmissible context.
• E_OS_ACCESS: The calling task or ISR presumably does not possess permission to access the specified area. Question (open)

Restrictions and Interaction

The function is reentrant ([SWS_Os_91012]), but requires compliance with the permissible call context (task or ISR) to avoid error states such as E_OS_CALLEVEL. For monitoring and analyzing operating system objects, AUTOSAR provides for the provisioning of ARTI description files ([SWS_Os_00829]).

The synchronous and reentrant function WritePeripheral32 from module Os serves to write a 32-bit value to a specified memory address of a peripheral area [SWS_Os_91011]. The service is available via the header Os.h and has the service ID 0x2d [SWS_Os_91011].

Parameters and Call

To execute the write access, the function requires three input parameters [SWS_Os_91011]:

• Area (AreaIdType): Reference to the target hardware peripheral area [SWS_Os_91011].
• Address (uint32*): Memory address to which the value is to be written [SWS_Os_91011].
• Write Value (uint32): The concrete 32-bit value that is transferred to the destination address [SWS_Os_91011].

Return Values and Error Handling

The call returns a status value of type StatusType [SWS_Os_91011]. In the event of success, E_OK is reported [SWS_Os_91011]. When EXTENDED status is active, E_OS_ID signals an invalid area ID, E_OS_VALUE an address not belonging to the area, and E_OS_CALLEVEL an inadmissible call context [SWS_Os_91011]. If the calling task or ISR does not possess access permission for the area, E_OS_ACCESS is returned [SWS_Os_91011].

Concurrency

Since WritePeripheral32 is reentrant, the service can be used in concurrent execution contexts provided that the respective caller possesses the required access permission at runtime [SWS_Os_91011].

Usage and Semantics

The synchronous and reentrant operating system function ModifyPeripheral8 ([SWS_Os_91016]) modifies a byte at a specified memory address Address. In doing so, the existing memory content is updated bitwise via the mask Clearmask by AND operation and via the mask Setmask by OR operation according to the formula *Address = ((*Address & Clearmask) | Setmask) ([SWS_Os_91016]). As input parameters, the function expects the peripheral area reference Area of type AreaIdType, the target address Address (type uint8*), and the two mask values of type uint8. The function is provided via the header file Os.h and has the service ID 0x2e ([SWS_Os_91016]).

Error Handling and Return Values

The return value of type StatusType indicates the success of the operation with E_OK ([SWS_Os_91016]). When extended status is enabled, specific error conditions can occur:

• E_OS_ID: The passed area identifier Area is outside the valid range ([SWS_Os_91016]).
• E_OS_VALUE: The target address Address does not belong to the specified area Area ([SWS_Os_91016]).
• E_OS_CALLEVEL: The service was called from an invalid call context ([SWS_Os_91016]).
• E_OS_ACCESS: The calling task or ISR has no access permission for the target area ([SWS_Os_91016]).

Concurrency and call conditions

Since ModifyPeripheral8 is specified as reentrant, the call can be made safely in parallel executions ([SWS_Os_91016]). Callers must ensure that both the context and the access rights for Area and Address are valid in order to avoid error states ([SWS_Os_91016]).

The synchronous and reentrant function ModifyPeripheral16 modifies a 16-bit memory location within a defined peripheral area according to the calculation formula *Address = ((*Address & Clearmask) | Setmask) [SWS_Os_91018]. The peripheral area reference Area (type AreaIdType), the target address Address (type uint16*), and the bitmasks Clearmask for a bitwise AND and Setmask for a bitwise OR are passed as parameters [SWS_Os_91018]. The declaration is available via the header Os.h [SWS_Os_91018].

In the regular success case, the service returns the return value E_OK [SWS_Os_91018]. When extended status checking (EXTENDED status) is activated, erroneous calls are detected and rejected based on specific error codes [SWS_Os_91018]:

• E_OS_ID: The passed area identifier Area is outside the valid value range [SWS_Os_91018].
• E_OS_VALUE: The passed memory address Address does not belong to the specified area Area [SWS_Os_91018].
• E_OS_CALLEVEL: The service was called from an invalid context [SWS_Os_91018].
• E_OS_ACCESS: The calling task or calling ISR does not have access permission for the specified area [SWS_Os_91018].

Prior to execution, callers must ensure that both the context and the permissions for the referenced area are present in order to avoid access violations [SWS_Os_91018].

The synchronous and reentrant operating system function ModifyPeripheral32 serves, according to [SWS_Os_91017], for the targeted bitwise manipulation of a 32-bit memory address. Provided via the interface Os.h, the function applies the fixed calculation formula *Address = ((*Address & Clearmask) | Setmask) to the target address Address. In this process, bits are first reset via the bitmask Clearmask using an AND operation and subsequently set via Setmask using an OR operation.

As input parameters, the service expects the peripheral area reference Area, the address pointer Address, and the two 32-bit masks [SWS_Os_91017]. Upon error-free execution, the status code E_OK is returned. In EXTENDED status, the function performs plausibility checks and reports the following error codes:

• E_OS_ID: The passed Area is outside the valid value range [SWS_Os_91017].
• E_OS_VALUE: The target address does not belong to the specified peripheral area [SWS_Os_91017].
• E_OS_CALLEVEL: The function was called from an impermissible context [SWS_Os_91017].
• E_OS_ACCESS: The calling task or ISR has no authorization for the access [SWS_Os_91017] (interpretation: missing access permission to the peripheral area). Question Q-b4d959765dc59c72 (open)

Concurrent calls are permitted thanks to reentrancy, provided that the call context is maintained [SWS_Os_91017]. In the overall system, this direct register modification differs from calculation formulas for dynamic data determination that are evaluated, for example, within the scope of ARTI debug information according to [SWS_Os_00829].

The synchronous and reentrant system function EnableInterruptSource enables an interrupt source by modifying the registers of the interrupt controller [SWS_Os_91020], [SWS_Os_00811]. The operating system provides this service for each configured category 2 interrupt source [SWS_Os_00808].

Parameters and Call

The identifier of the category 2 ISR is passed via the parameter ISRID [SWS_Os_91020]. The boolean parameter ClearPending determines whether a pending interrupt flag is to be cleared upon activation (TRUE) or remains unchanged (FALSE) [SWS_Os_91020], [SWS_Os_00811]. The function is available via the header file Os.h [SWS_Os_91020].

Error Handling and Return Values

If no error is detected, the call returns E_OK [SWS_Os_91020], [SWS_Os_00810]. If the operating system detects an error, it returns the corresponding status code of type StatusType and calls the ErrorHook() [SWS_Os_00810]. The following error states are defined:

• E_OS_ID: The parameter ISRID is not a valid identifier of a category 2 ISR (in status EXTENDED) [SWS_Os_91020].
• E_OS_CALLEVEL: The function was called from an invalid call context (in status EXTENDED) [SWS_Os_91020].
• E_OS_ACCESS: Within the scope of service protection, the calling application does not own the specified ISRID [SWS_Os_91020].

Interaction

Together with DisableInterruptSource and ClearPendingInterrupt, the function forms the API trio for the targeted control of individual category 2 interrupt sources (OsIsrCategory == CATEGORY_2) in the operating system [SWS_Os_00808], [SWS_Os_00810].

use

The synchronous and reentrant function DisableInterruptSource disables a specific interrupt source directly via the registers of the interrupt controller [SWS_Os_91019], [SWS_Os_00812]. It is available via the header file Os.h and is provided for each category 2 interrupt source (OsIsrCategory == CATEGORY_2) [SWS_Os_91019], [SWS_Os_00808]. The identifier of the relevant ISR (ISRID) is passed as a parameter. Upon successful execution, the service returns E_OK [SWS_Os_91019], [SWS_Os_00810].

Error handling

If the operating system detects an error during execution, the corresponding StatusType is returned and the ErrorHook() is called [SWS_Os_00810]. Possible error codes are:

• E_OS_ID: The passed ISRID is not a valid identifier of a category 2 ISR (in EXTENDED status) [SWS_Os_91019].
• E_OS_CALLEVEL: Invalid call context of the API function (in EXTENDED status) [SWS_Os_91019].
• E_OS_ACCESS: The calling OS-Application does not own the specified ISR (service protection) [SWS_Os_91019].
• E_OS_NOFUNC: The requested interrupt source is already disabled (in EXTENDED status with nested calls) [SWS_Os_00809].

Interaction and Boundary Conditions

Together with EnableInterruptSource and ClearPendingInterrupt, the function forms the API trio for controlling category 2 interrupt sources [SWS_Os_00808]. Concurrent or repeated calls are secured in the extended status by returning E_OS_NOFUNC, whereby redundant disablements remain controllable [SWS_Os_00809]. Callers must also have the appropriate access rights to prevent runtime errors caused by service protection [SWS_Os_91019].

Usage and Call Context

The function ClearPendingInterrupt serves to clear a pending interrupt for category 2 sources [SWS_Os_00808]. It takes the identifier ISRID of a category 2 ISR as its only input parameter and directly modifies the associated registers of the interrupt controller [SWS_Os_91021], [SWS_Os_00813]. The call is processed synchronously and is available via the header file Os.h [SWS_Os_91021].

Error Handling and Return Values

In the error-free case, the status code E_OK is returned [SWS_Os_91021]. If the operating system detects an error during execution, the service returns the corresponding error code of type StatusType and mandatorily calls the ErrorHook() [SWS_Os_00810]. The following error states are specified for the interface [SWS_Os_91021]:

• E_OS_ID: The passed parameter ISRID is not a valid identifier of a category 2 ISR (returned in status EXTENDED) [SWS_Os_91021].
• E_OS_CALLEVEL: The function was called from an invalid call context (returned in status EXTENDED) [SWS_Os_91021].
• E_OS_ACCESS: Within the scope of service protection, the calling application is not authorized as the owner of the passed ISR [SWS_Os_91021].

Concurrency and interaction in the operating system

The interface is defined as reentrant and can thus be called safely concurrently [SWS_Os_91021]. The operating system provides ClearPendingInterrupt for each category 2 interrupt source (OsIsrCategory == CATEGORY_2) as an integral part of the control APIs, which also include DisableInterruptSource and EnableInterruptSource [SWS_Os_00808].

The function ActivateTaskAsyn (service ID 0x33) represents the asynchronous variant for task activation and is provided via the header file Os.h ([SWS_Os_91022]). It is primarily intended for cross-core task activation in multicore systems ([SWS_Os_91022]).

id of type TaskType is passed as the only input parameter, specifying the task to be activated ([SWS_Os_91022]). The interface has no return value (void) and defines neither input/output nor pure output parameters ([SWS_Os_91022]).

Possible errors during activation are not reported back to the caller ([SWS_Os_91022], [SWS_Os_00816]). Instead, occurring errors are reported exclusively via the global error hook, provided that one is configured ([SWS_Os_00816]).

With regard to concurrency, the function is reentrant and operates completely asynchronously ([SWS_Os_91022]), whereby the calling context does not block on execution. The operating system is required to provide this interface in accordance with [SWS_Os_00816].

Usage and Operation

The function Ioc Init (marked as draft in release R20-11) initializes the internal data structures of the Inter-OS-Application Communication (IOC) [SWS_Os_91026]. The call is synchronous, accepts no input parameters, and has no return value [SWS_Os_91026]. If the operating system generator is executed in "IOC mode", it exclusively generates the IOC code in the source file Ioc.c and declares the associated interfaces in the header file Ioc.h [SWS_Os_00834], through which Ioc Init is also provided [SWS_Os_91026].

Error Handling and Concurrency

For Ioc Init, the specification defines neither specific error return values nor error notifications to DET or DEM [SWS_Os_91026]. The service is explicitly defined as non-reentrant (Non Reentrant) [SWS_Os_91026]. Interpretation: Due to the lack of reentrancy and its initialization task, the service likely has to be called sequentially during the system startup phase before concurrent communication accesses take place. Question Q-47f99a4725b57c89 (open)

Interplay with IOC Communication Functions

Proper initialization of the data structures is the prerequisite for using the generated IOC communication interfaces:

• Sending and writing: Senders transmit data asynchronously via single-value services such as Ioc Send [SWS_Os_00718] and Ioc Write [SWS_Os_91003] or group functions such as Ioc Send Group [SWS_Os_00728] and Ioc Write Group [SWS_Os_91004].
• Receiving and reading: Receivers retrieve data synchronously via Ioc Receive [SWS_Os_00738], Ioc Read [SWS_Os_91005], or corresponding group services [SWS_Os_00746] [SWS_Os_91006].
• Queue management and notification: If buffered communication is configured, the contents of an internal queue can be emptied synchronously with Ioc Empty Queue [SWS_Os_00754]. Additionally, upon data reception, a configured receiver callback <Receiver Pull CB> can be executed on the target core [SWS_Os_00757].

The callback function <Receiver Pull CB> can optionally be configured for the receiver of a communication and is declared via the header Os.h [SWS_Os_00757]. If this callback is configured, the IOC (Inter-OS-Application Communicator) calls the function synchronously on the receiving Core upon each data reception [SWS_Os_00757]. The specific identifier of the callback function is defined on the receiver side via the configuration attribute OsIocReceiverPullCB [SWS_Os_00757].

The following specifications apply to the call and interface properties:

• Signature and parameters: The function has the prototype void <Receiver Pull CB> ( void ); it takes no parameters (neither input, in-out, nor output parameters) and returns no value [SWS_Os_00757].
• Synchronicity and reentrancy: The call by the IOC takes place with synchronous semantics directly on the receiver Core [SWS_Os_00757]. In addition, the callback function is specified as reentrant [SWS_Os_00757].
• Error handling: The specification provides neither return values nor specific error codes or error notifications for this function [SWS_Os_00757].

Since the signature does not pass any payload data, the call is likely to serve primarily as a notification signal to inform the receiver about the arrival of new data and trigger the subsequent retrieval of the payload data. Question Q-2365bb46ad77a476 (open) Developers should note that execution occurs synchronously on the receiver Core [SWS_Os_00757].

The function ProtectionHook serves as a central callback of the operating system and is always called synchronously when a fatal error occurs [SWS_Os_00538]. As typical error scenarios, the specification explicitly cites exceeding the worst-case execution time (Worst Case Execution Time) as well as memory protection violations [SWS_Os_00538]. The declaration of the interface is provided via header Os_Externals.h [SWS_Os_00538].

As input parameter, the routine accepts Fatalerror of type StatusType, which passes the triggering cause of the hook call [SWS_Os_00538]. Additional input/output parameters or pure output parameters are not defined in the signature [SWS_Os_00538].

Via the return value of type ProtectionReturnType, ProtectionHook bindingly determines which action the operating system shall initiate for further error handling after execution of the hook [SWS_Os_00538]. The following actions are available as return values [SWS_Os_00538]:

• PRO_IGNORE [SWS_Os_00538]
• PRO_TERMINATETASKISR [SWS_Os_00538]
• PRO_TERMINATEAPPL [SWS_Os_00538]
• PRO_TERMINATEAPPL_RESTART [SWS_Os_00538]
• PRO_SHUTDOWN [SWS_Os_00538]

With respect to concurrency and execution behavior, ProtectionHook is specified as reentrant and synchronous [SWS_Os_00538]. The call occurs immediately upon occurrence of the fatal error, whereupon the operating system executes the defined action [SWS_Os_00538].

The enumeration type AppModeType is defined in the header file Os.h and is used to define the application mode in the operating system [SWS_Os_91007]. In multi-core systems, this type allows the application mode of a processor core to be inherited from another Core [SWS_Os_91007].

The value DONOTCARE is specified for the range of values [SWS_Os_91007]. Interpretation: This value is likely intended to explicitly configure a Core so that it does not start an independent mode, but instead adopts the behavior of the parent Core. Question Q-2b7d9f1c8e5f1a3f (open) Specific error codes or return values are not defined for the type itself.

With regard to diagnostics and system state, the interaction with analysis tools is relevant. According to [SWS_Os_00829], the ARTI module description file must support all ORTI containers in order to enable connected debug tools to evaluate and display information about the operating system and its objects. The ARTI debug information provides dynamic attributes that are resolved via formulas [SWS_Os_00829]. Interpretation: The state of the application mode is therefore likely mapped and read at the tool level via corresponding ARTI object attributes. Question Q-410d011cbcf1b158 (open)

The data type ApplicationStateType is used in the Classic AUTOSAR operating system for uniquely identifying the state of an OS-Application [SWS_Os_00773]. It is specified as a scalar base type and is provided via the header file Os.h [SWS_Os_00773].

The permissible value range of ApplicationStateType comprises three discrete states for an OS-Application [SWS_Os_00773]:

• APPLICATION_ACCESSIBLE: Indicates that the OS-Application is ready for operation and its resources can be accessed [SWS_Os_00773].
• APPLICATION_RESTARTING: Signals that the OS-Application is currently in a restart phase [SWS_Os_00773].
• APPLICATION_TERMINATED: Indicates that the OS-Application has been terminated and performs no further actions [SWS_Os_00773].

Regarding usage and interaction with other components, the type is presumably likely to serve as a return value or output parameter in corresponding OS system services for state monitoring to inform callers about the current lifecycle status of an application. Question Q-9a4f2254f4013853 (open) Since it is an elementary type definition, the standard specifies no dedicated error codes, DET or DEM messages for it, and formulates no separate restrictions regarding call context or reentrancy [SWS_Os_00773].

The data type ApplicationStateRefType is part of the operating system (module Os) in the AUTOSAR Classic Platform and is made available via the header file Os.h [SWS_Os_00774]. The type is derived from a pointer and points directly to a memory location where a state of an OS application (Application State) can be stored [SWS_Os_00774].

With regard to practical usage, this pointer type serves to reference application states: Interpretation: As a pointer type, ApplicationStateRefType is likely primarily used as a reference or output parameter in operating system query functions via which the state of an OS application is conveyed to the caller. Question Q-948bb914d3672a38 (open) Callers must therefore ensure that a valid, writable memory area is reserved for the destination state prior to parameter passing in order to avoid erroneous pointer accesses at runtime.

Specific error handling mechanisms, error codes for DET or DEM, as well as separate requirements for reentrancy and concurrency are not designated separately for this base type in the specification [SWS_Os_00774]. Any restrictions regarding the permitted call context or synchronization duties to be observed arise exclusively from those operating system interfaces that use this type in their function signatures.

According to [SWS_Os_00784], the type ScheduleTableStatusType maps the current execution and synchronization status of a schedule table in the AUTOSAR operating system. It is provided via the header file Os.h and is based on an implementation-specific range of values.

The following status values are specified:

• SCHEDULETABLE_STOPPED: The schedule table is not started.
• SCHEDULETABLE_NEXT: The schedule table is started after expiry of the currently active schedule table (Interpretation: this occurs after handover to the service NextScheduleTable()). Question Q-8cbcfc83969eea23 (open)
• SCHEDULETABLE_WAITING: The schedule table uses explicit synchronization, has already been started, and is waiting for synchronization with the global time.
• SCHEDULETABLE_RUNNING: The schedule table is running, but is currently not synchronous with a global time source.
• SCHEDULETABLE_RUNNING_AND_SYNCHRONOUS: The schedule table is running and is synchronized with the global time source.

As a pure status data type, ScheduleTableStatusType defines no runtime errors or DET/DEM notifications of its own. In interaction with analysis tools, the type serves according to [SWS_Os_00829] for the ARTI-supported evaluation and display of dynamic operating system objects, allowing state and synchronization deviations in the system to be captured transparently.

Usage and definition

According to [SWS_Os_00785], the data type ScheduleTableStatusRefType is defined as a pointer type to a variable of the data type Schedule Table Status Type. The type is provided via the header Os.h and serves in the AUTOSAR operating system as a reference type for the status of a schedule table [SWS_Os_00785].

Usage and Boundary Conditions

In typical operating system calls, this pointer type is likely to act as an output parameter via which an OS system function reports the current state of the referenced schedule table back to the caller. Question Q-53364f3a9953dae3 (open) Because the specification merely defines the type definition, calling components must observe the following when using it:

• Memory provisioning: Before passing a reference of this type, the caller must ensure that the pointer points to a valid and writable memory area that remains valid throughout the entire call.
• Validity and null pointer: Passing a null pointer (NULL) is likely to result in corresponding error responses from the called OS services, depending on the operating system configuration (Standard or Extended status). Question Q-63d77f8c7857e6c4 (open)
• Memory protection: In safety-critical multicore or memory-protected OS environments, the referenced memory area must be accessible to the calling task or OS instance.

Since [SWS_Os_00785] designates no further runtime properties or specific error codes for the base type, reentrancy and call context result from the respective OS services that use this pointer type as a parameter.

Usage and Value Range

The enumeration type TryToGetSpinlockType is provided via the header file Os.h and serves as a status indicator of whether a spinlock could be successfully occupied by the caller or not [SWS_Os_00792]. It defines the result of corresponding occupation operations in the operating system [SWS_Os_00792].

The value range comprises exactly two specified literals [SWS_Os_00792]:

• TRYTOGETSPINLOCK_SUCCESS: Signals that the spinlock could be successfully occupied [SWS_Os_00792].
• TRYTOGETSPINLOCK_NOSUCCESS: Indicates that the spinlock could not be occupied [SWS_Os_00792].

Concurrency and System Context

The type is used for synchronization in multi-core systems. Interpretation: The caller is likely to evaluate the return value synchronously to determine immediately whether the protected critical section may be entered or whether an alternative program branch must be chosen in the case of TRYTOGETSPINLOCK_NOSUCCESS without blocking wait [SWS_Os_00792]. Question Q-a04e72802dc41325 (open) Dedicated error codes or error messages via DET or DEM are not specified for this type [SWS_Os_00792].

Interaction with Diagnostic Tools

In the context of tool connections, the ARTI module description file supports all ORTI containers to display information about the operating system, its states, and operating system objects and to determine dynamic values [SWS_Os_00829]. Interpretation: Spinlocks and their occupation states are also likely to be visualizable for debugging and tracing tools via such interfaces [SWS_Os_00829]. Question Q-a488e055eb7d402e (open)

Usage and Value Range

The scalar data type IdleModeType is provided via the header Os.h and serves to specify the behavior of a processor core in idle mode [SWS_Os_00793]. In the defined value range, the mode IDLE_NO_HALT is established, upon selection of which the processor core performs no special actions during idle time [SWS_Os_00793].

Interpretation: Since IdleModeType is derived from a scalar base type, it is likely to serve in the operating system context as a configuration value or call parameter for control services of the core idle behavior. Question Q-911a39efb537f1bc (open) Interpretation: In addition to the standard value IDLE_NO_HALT, concrete operating system implementations or microcontroller architectures are likely to potentially provide additional halt or power-saving modes, even though the specification excerpt merely mentions the absence of specific actions. Question Q-b6688f74cacbab45 (open)

Restrictions and Error Handling

For IdleModeType, no specific error codes, DET or DEM notifications, or requirements regarding reentrancy or call contexts are identified in the present scope of the specification [SWS_Os_00793]. Any functional restrictions or preconditions therefore result exclusively from the higher-level operating system interfaces that process this type.