Image Processing Reference
In-Depth Information
EcuM
Dem
WdgM
Det
Fim
OS
Wdglf
SchM
Gpt
Mcu
Wdg
Hardware
FIGURE .
AUTOSAR—system services substack.
AUTOSAR. he
Os
module is configured and scaled statically, provides a priority-based scheduling
policy and protective functions with respect to memory and timing at run-time, and is designed to
be hostable on low-end controllers.
Similar to the OSEKtime dispatcher tables (see Section ..), AUTOSAR
Os
provides so-called
“schedule tables” consisting of one or more “expiry points.” Hereby, each expiry point is assigned an
offset measured in
Os
ticks from the start of the schedule table. Once an expiry point is reached,
the action corresponding to the expiry point (e.g., the activation of a task or the setting of an event)
is processed. At runtime, the
Os
iterates over the schedule table, processing each expiry point in
turn. The iteration is driven by an
Os
counter. To facilitate the execution of tasks synchronous to
external events (e.g., synchronous to the FlexRay communication schedule), schedule tables can be
synchronized to external time sources (e.g., FlexRay's global time).
As far as protection against timing violations is concerned, AUTOSAR
Os
does not provide dead-
line monitoring (as does OSEKtime OS), but provides the facility to track the execution time of each
task and ISR and to raise an error in case either exceeds its statically assigned execution time bud-
gets. Regarding memory protection, AUTOSAR
Os
uses (similar to the protected OSEK defined by
HIS [see Section ..]) the memory protection unit of the MCU to provide coarse-grained memory
protection of the different tasks against each other.
Basic software
(BSW)
scheduler
(
SchM
): he BSW Scheduler module provides means to embed other
AUTOSAR system software module implementations into the context of an AUTOSAR
Os
task or
ISR, triggers main processing functions of the system software modules, and applies data consistency
mechanisms for these modules. Just like the
Rte
providestheinfrastructureforsotwarecomponents
by embedding runnable entities in a task context, the
SchM
module “provides the infrastructure for
the other system sotware modules” by embedding their main processing functions in a task context.
∗
ECU State Manager
(
EcuM
):heECUStateManagermodulemanagesallaspectsoftheECUrelated
to the
Off
,
Run
,and
Sleep
states of that ECU and the transitions between these states like
“start-up and shutdown.” In detail, the ECU State Manager is responsible for the initialization and
de-initialization of all basic software modules including
Os
and
Rte
,cooperateswiththe
ComM
,and
hence indirectly with
Nm
, to shut down the ECU when needed, manages all wake-up events, and con-
figures the ECU for
Sleep
state when requested. To fulfill all these tasks, the EcuM provides some
important protocols: the “run request protocol,” which is needed to coordinate whether the ECU
must be kept alive or is ready to shut down, the “wakeup validation protocol” to distinguish “real”
wakeup events from “erratic” ones, and the “time-triggered increased inoperation protocol,” which
allows to put the ECU into an increasingly energy saving sleep state.
∗
Usually the main processing functions of multiple system software modules are embedded into a single task to keep the
number of tasks required for execution of the whole AUTOSAR system software low.
