Image Processing Reference
In-Depth Information
The so-called “ Runtime Environment ( Rte )” acts as an interface between application software
components and the system software modules as well as the infrastructure services that enable
communication to occur between application software components.
18.7.1 Application Software Architecture
Application software in AUTOSAR consists of “application software components,” which are ECU
and location independent and “sensor-actuator components” that are dependent on ECU hardware
and therefore location dependent. Whereas instances of application software components can easily
be deployed to and relocated among different ECUs, instances of sensor-actuator components must
be deployed to a specific ECU for performance/efficiency reasons.
Application software components as well as sensor-actuator components are interconnected via
so-called connectors. These connectors represent the exchange of signals or the remote method
invocations among the connected components.
18.7.1.1 Runnable Entities
Software components are composed of one or more “runnable entities,” which are executed in the
context of operating system tasks. hese runnable entities are invoked by a dedicated system software
module named “ Runtime Environment ( Rte ).” Depending on whether or not runnable entities have
wait-points, AUTOSAR distinguishes between “category  runnable entities” (without wait-points)
and “category  runnable entities” (with wait-points). The former can be assigned to basic tasks of
the operating systems (which are not allowed to invoke any blocking system calls), whereas the latter
have to be mapped to extended tasks (which are allowed to use blocking system calls).
18.7.1.2 Communication
To enable communication between different software components in AUTOSAR, the components
are equipped with a communication interface, that consists of several ports. Hereby, ports have
defined interface types. AUTOSAR distinguishes between “sender-receiver port interfaces,” which
provide message passing semantics, and “client-server port interfaces,” which provide remote pro-
cedure call semantics. AUTOSAR further distinguishes between the following domains of com-
munication: “intratask communication” (communication between runnable entities of components
that are assigned to the same task on the same ECU), “intertask communication” (communica-
tion between runnable entities of components that are assigned to different tasks on the same
ECU), and “inter-ECU communication” (communication between runnable entities of compo-
nents that are assigned to different tasks on different ECUs). Each of the previously described
communication semantics is supported for these three communication domains. As far as multi-
plicity is concerned, AUTOSAR supports :, :n, and n: communication for sender-receiver port
interfaces and : and n : communication (multiple clients, single server) for client-server port
interfaces.
18.7.2 System Software Architecture
In addition to the application software components, AUTOSAR also defines a layered architecture of
system software modules [], which provides the basic platform for the execution of the application
software components. Figure . provides a coarse grained overview of the major layers of these
system software modules.
Microcontroller abstraction layer : This is the lowest software layer of the system software in
AUTOSAR. his layer contains sotware modules, which directly access the microcontroller's internal
 
Search WWH ::




Custom Search