Image Processing Reference
In-Depth Information
Src
ID
Dst
ID
Op
code
Data
FIGURE .
OSEK NM message format.
(substate
NmReset
). Once the new ECU has joined the ring, it participates in transmission of the
ring messages (substate
NmNormal
). In case an ECU fails to receive any ring messages while residing
in
NmNormal
state, the ECU NM module transits into
NmLimpHome
state, where the ECU sends
“limp home messages” until ring messages are received again.
Figure . depicts the message format of OSEK NM's messages. A “source” and a “destination ID”
field uniquely identify the sending and the receiving ECU in the network. he “OP code” field defines
whether the message is a ring message, a limp home message, or an alive message. An optional data
field may carry additional data from higher layers that this transferred along the ring.
18.3.3 OSEK COM
OSEK COM [] provides a uniform communication environment for automotive control unit appli-
cations by offering services for data transfer among tasks and/or ISRs. Hereby, tasks and ISRs can
be located on either the same ECU (internal communication) or on different ECUs (external com-
munication). OSEK COM supports both “cyclic time-driven communication” and “event-driven
communication.” Additionally OSEK COM provides mechanisms for transmission and reception
timeout monitoring (e.g., in case the transmission of a signal triggered by the call of an OSEK COM
application programming interface (API) service does not take place within a statically configurable
interval, a transmission timeout is signaled to the layers located on top of OSEK COM).
In case of external communication, the “interaction sublayer” of OSEK COM takes care of the
representational issues of signals like byte ordering and alignment. On the sender's side, this layer
converts signals from the byte order of the sending ECU into the network byte order. Further-
more, the interaction layer packs multiple signals into a single communication frame to reduce
communication bandwidth consumption.
18.3.4 OSEKtime OS
OSEKtime OS [] is designed as a statically configured time-driven single chip-operating system for
distributed embedded systems. Just like OSEK OS, OSEKtime OS provides two entities of execu-
tion, namely, “ISRs” and “tasks.” ISRs execute interrupt-related services. Tasks, however, are started
at defined points in time and have one of three different states. In the
Running
state, the CPU is
assigned to the task and its commands are executed. Only one task can reside in this state at any point
in time while all other states can be adopted simultaneously by several tasks. he
Preempted
state
is reached by a task that has been in the
Running
state and was preempted by another task that is
to be activated. A task can leave the
Preempted
state only if the preempting task changes into the
Suspended
state. An inactive task that can be activated is in the
Suspended
state. hese state
changesaredepictedinFigure..
The activation times of the tasks are stored in a “dispatcher table” before compile time. The dis-
patcher is the central component of the OSEKtime OS and is responsible for activating the tasks
according to their activation times. he processing of the dispatcher table is done cyclically. A com-
plete cycle of the dispatcher table is called a “dispatcher round.” If a time-driven task is still in the state
Running
when the activation time of another time-driven task is reached, the first task passes over
