Hello Readers,
My name is Santosha S Chikkur, and I work at Luxoft India as a Junior Software Developer. Luxoft has given me several opportunities to work on various projects, which has inspired me to learn the essential processes involved in developing AUTOSAR Modulеs and Add-Ons in AUTOSAR OS Part-3
OSEK OS. Resource management
Internal Resources
• Internal resources are resources which are not visible to the user and therefore cannot be addressed by the OS services Get/ReleaseResource()
• These resources are restricted to tasks. A maximum of one internal resource can be assigned to a task during system creation.
• The resource is automatically enabled when the task enters the running state. As a result, the priority of the task automatically becomes the maximum priority of the resource.
• At rescheduling points, the resource is automatically released.
Predefined resource RES_SCHEDULER
• It locks the scheduler to prevent rescheduling of tasks - the scheduler is treated like a resource which is accessible to all tasks.
OS services: GetResource() and ReleaseResource()
• TerminateTask(), ChainTask(), Schedule(), WaitEvent() must not be called when the resource is reserved.
• Interrupt service routine shall not be completed with a resource occupied
OSEK OS. Error handling, tracing and debugging
The OS offers two levels of error checking:
• extended status for the development phase
• standard status for the production phase
Example
StatusType ActivateTask (TaskType )
The service returns:
• If Standard status configured: No error, E_OK
Too many task activations of , E_OS_LIMIT
• If Extended status configured: Task is invalid, E_OS_ID
Hook routines
The OS provides hooks routines to allow user-defined actions within the OS internal processing. Hooks are
• called by the OS
• higher prior than all tasks
• not interrupted by category 2 interrupt routines.
• part of the OS
• applied by the user with user-defined actions.
• standardized in interface, but not standardized in functionality
• only a subset of API functions are allowed
In the OS hook routines may be used for:
• system start-up. StartupHook is called after the OS start-up and before the scheduler is running.
• system shutdown. ShutdownHook is called when a system shutdown is requested by the application or by the OS in case of a severe error.
• tracing or application dependent debugging purposes as well as user defined extensions of the context switch: PreTaskHook and PostTaskHook
• error handling ErrorHook
ErrorHook
• ErrorHook() is called if a system service returns a StatusType value not equal to E_OK.
• The user is allowed to call several OS services inside the hook to obtain an additional information(OSErrorGetServiceId, GetTaskId() .. etc ..)
• The hook routine ErrorHook() is not called when the system service is called from within ErrorHook() itself (ie, an error hook is never called recursively).
• ErrorHook() also is called if an error is detected during task activation or event setting, for example upon alarm expiration or message arrival.
OSEK OS. Alarms
• Counters
• Alarm management
The OS provides a two-stage concept to process recurring events
• Such events (sources) are registered by implementation specific counters.
• Based on counters, the OS offers alarm mechanisms to the application software.
OSEK OS. Counters
• A counter is represented by a counter value measured in "ticks" and some counter-specific constant.
• The OSEK operating system takes care of the necessary alarm handling operations, when the counter has progressed and how the counter has progressed.
• The OSEK operating system provides at least one (hardware or software) timer-derived counter.
OSEK OS. Alarm management
The ALARM mechanism of the OS provides services to:
• activate TASKs (OSEK/AUTOSAR)
• set EVENTs (OSEK/AUTOSAR)
• increment COUNTERs (AUTOSAR)
• call an ALARM callback (OSEK, AUTOSAR SC1)
An alarm will expire when a predefined counter value is reached. This counter value can be defined as:
• relative to the actual counter (relative error)
• an absolute value (absolute alarm)
OS alarm services:
StatusType
SetRelAlarm ( AlarmType , TickType , TickType )
StatusType
SetAbsAlarm ( AlarmType , TickType , TickType )
AUTOSAR OS. Schedule Tables
The OS manages multiple schedule tables. Schedule table consists of a list of defined time-based actions expiry points.
Each expiry point defines:
• one or more operations that must occur while processing it.
An action is the activation of a task or the setting of an event.
• The deviation marks from the beginning of the schedule table. Each schedule table has a duration in ticks. The duration is measured from zero and defines the module of the schedule table.
At runtime, the OS will iterate over the schedule table, processing each expiry point in turn. The iteration is driven by an OSEK counter.
AUTOSAR OS. Schedule Tables Diagram
AUTOSAR OS. Schedule Tables working
Schedule table synchronization
The duration of ST need not be equal to the counter modulus.
If ST repeats, then it’s not guaranteed that the absolute counter value at which the initial expiry point was first processed is the same count value at which it is subsequently processed.
In many cases, it may be important that schedule table expiry points are processed at specific absolute values of the underlying counter.
This is called synchronization.
Typical use-cases include:
Synchronization of aging points with angular rotation steps for motor control.
• Synchronization of calculations to the global (network) time base.
AUTOSAR OS supports synchronization in two ways:
• Indirect synchronization - the counter controlling the schedule table is the counter with which synchronization is required.
States of an implicit synchronized ST
States of an explicit synchronized ST
AUTOSAR OS. Differences from OSEK OS
The AUTOSAR OS
• imposes some restrictions on OSEK OS:
- alarm callbacks allowed only in SC1
- AUTOSAR OS handles RES_SCHEDULER as any other resource. This means that the RES_SCHEDULER is not automatically created. • eliminates some undefined behavior in OSEK OS (for example, StartOS() cannot return). • Add some extensions to OSEK OS (for example, add ‘increment counter’ alarm action, allows to autostart absolute alarms, etc ).
Conclusion
OSEK OS and AUTOSAR OS are two operating systems widely used in the automotive industry. Both operating systems provide a comprehensive set of features for resource management, error handling, monitoring, debugging, task scheduling, and managing alarms and counters. AUTOSAR OS is a newer and more versatile operating system than OSEK OS, but it is also more complex. The choice of operating system to use depends on the specific needs of the application.
Top comments (0)