"ISO 17356标准化的OSEK_VDX操作系统规范2.2.2详解"

需积分: 5 164 浏览量更新于2023-12-26 收藏 896KB PDF 举报

OSEK_VDX_Operating System(OS)_V2.2.2_2004.pdf is a document that outlines the specifications for the OSEK/VDX Operating System Version 2.2.2. It is an official release that replaces all previously distributed documents, and it is noted that the OSEK group retains the right to make changes to the document without notice. The document is divided into several parts, some of which have been standardized by ISO 17356. ISO 17356 consists of the OSEK Glossary, OSEK Binding Specification, OSEK OS, OSEK COM, OSEK NM, and OSEK OIL. The OSEK Glossary, which is part of ISO 17356-1, includes an ISO-style introduction and a glossary of terms related to OSEK. The OSEK Binding Specification, outlined in ISO 17356-2, serves as the foundation for the OSEK Binding 1.4.1, excluding the glossary. The OSEK OS, as detailed in ISO 17356-3, is based on OSEK OS 2.2.1. The OSEK COM, specified in ISO 17356-4, is based on OSEK COM 3.0.2. The OSEK NM, as per ISO 17356-5, is based on OSEK NM 2.5.2. Lastly, the OSEK OIL, described in ISO 17356-6, is based on OIL 2.4.1. It is important to note that the document states that no part of it may be reproduced in any form or by any means without permission in writing from the OSEK group. Additionally, the group does not accept any liability for errors in the document. Overall, the OSEK/VDX Operating System Specification 2.2.2 is a comprehensive document outlining the specifications for the OSEK/VDX Operating System. It serves as a vital resource for individuals and organizations working with or seeking to understand the OSEK/VDX Operating System. Additionally, the standardization of certain parts of OSEK by ISO 17356 further emphasizes the importance and relevance of these specifications in the field of operating systems.

OSEK/VDX

Operating System

Specification 2.2.22

OSEK OS 2.2.22 © by OSEK 15

3.3 Relationship between OSEK OS and OSEKtime OS

OSEKtime OS is an operating system especially tailored to the needs of time triggered

architectures. It allows OSEK OS to coexist with OSEKtime OS. Conceptually, OSEKtime

assigns its idle time to be used by OSEK. OSEK OS interrupts and tasks have less importance

(lower priority) than similar entities in OSEKtime OS.

The OSEK interfaces, and the definition of system calls, do not change if OSEK coexists with

OSEKtime. There are minor exceptions with respect to system startup and shutdown due to

the fact that OSEKtime is responsible for the overall system whereas OSEK is only locally

responsible. These deviations are specifically mentioned within this specification.

On top of this, there is functionality defined within OSEKtime which imposes restrictions on

the implementation of OSEK OS if it is intended to coexist with OSEKtime OS. For more

information, please refer to the specification of the OSEKtime OS.

OSEK/VDX

Operating System

Specification 2.2.22

16 © by OSEK OSEK OS 2.2.22

4 Task management

4.1 Task concept

Complex control software can conveniently be subdivided in parts executed according to their

real-time requirements. These parts can be implemented by the means of tasks. A task

provides the framework for the execution of functions. The operating system provides

concurrent and asynchronous execution of tasks. The scheduler organises the sequence of task

execution.

The OSEK operating system provides a task switching mechanism (scheduler, see chapter

4.4, Task switching mechanism), including a mechanism which is active when no other

system or application functionality is active. This mechanism is called idle-mechanism. Two

different task concepts are provided by the OSEK operating system:

• basic tasks

• extended tasks

Basic Tasks

Basic tasks only release the processor, if

• they terminate,

• the OSEK operating system switches to a higher-priority task, or

• an interrupt occurs which causes the processor to switch to an interrupt service routine

(ISR).

Extended Tasks

Extended tasks are distinguished from basic tasks by being allowed to use the operating

system call WaitEvent, which may result in a waiting state (see chapter 7, Event mechanism,

and chapter 13.5.3.4, WaitEvent). The waiting state allows the processor to be released and to

be reassigned to a lower-priority task without the need to terminate the running extended task.

In view of the operating system, management of extended tasks is, in principal, more complex

than management of basic tasks and requires more system resources.

4.2 Task state model

The following text describes the task states and the transitions between the states for both task

types.

A task has to change between several states, as the processor can only execute one instruction

of a task at any time, while several tasks may be competing for the processor at the same time.

The OSEK operating system is responsible for saving and restoring task context in

conjunction with task state transitions whenever necessary.

4.2.1 Extended tasks

Extended tasks have four task states:

running In the running state, the CPU is assigned to the task, so that its instructions

can be executed. Only one task can be in this state at any point in time,

while all the other states can be adopted simultaneously by several tasks.

OSEK/VDX

Operating System

Specification 2.2.22

18 © by OSEK OSEK OS 2.2.22

4.2.2 Basic tasks

The state model of basic tasks is nearly identical to the extended tasks state model. The only

exception is that basic tasks do not have a waiting state.

running In the running state, the CPU is assigned to the task, so that its instructions

can be executed. Only one task can be in this state at any point in time,

while all the other states can be adopted simultaneously by several tasks.

ready All functional prerequisites for a transition into the running state exist, and

the task only waits for allocation of the processor. The scheduler decides

which ready task is executed next.

suspended In the suspended state the task is passive and can be activated.

runnin g

suspended

start

activate

terminate

preempt

ready

Figure 4-3 Basic task state model

Transition Former

state

New

state

Description

activate

suspended

ready

A new task is set into the ready state by a system

service. The OSEK operating system ensures that the

execution of the task will start with the first

instruction.

start

ready running

A ready task selected by the scheduler is executed.

preempt

running ready

The scheduler decides to start another task. The

running task is put into the ready state.

terminate

running suspended

The running task causes its transition into the

suspended state by a system service.

Figure 4-4 States and status transitions for basic tasks

4.2.3 Comparison of the task types

Basic tasks have no waiting state, and thus only comprise synchronisation points at the

beginning and the end of the task. Application parts with internal synchronisation points have

to be implemented by more than one basic task. An advantage of basic tasks is their moderate

requirement regarding run time context (RAM).

Task activation will not immediately change the state of the task in case of multiple activation requests. If the

task is not suspended, the activation will only be recorded and performed later.

剩余86页未读，继续阅读

汽车电子助手

粉丝: 1w+
资源: 124

"ISO 17356标准化的OSEK_VDX操作系统规范2.2.2详解"

OSEK_VDX_Operating System(OS)_V2.2.0_2001.pdf

汽车电子行业专业技术文档，OSEK/VDX的Specification的所有资料文档，英文。

OSEK_VDX_Network_Management_Concept_and_API(NM)_V2.5.2_2003.pdf

OSEK_VDX_Operating System(OS)_V2.2.1_2003.pdf

OSEK_VDX_Operating System(OS)_V2.2.3_2005.pdf

OSEK_VDX_Operating System(OS)_V2.1.0_R1_2000.pdf

OSEK_VDX.zip_OSEK VDX _OSEK_VDX_flame92l_osek_osek os

OSEK_VDX_Time-Triggered_Operating_System_V1.0_2001.pdf

OSEK_VDX_Binding_Specification_V1.4.2_2004.pdf

OSEK_VDX_Communication(COM)_V3.0.3_2004.pdf

最新资源