APPLICATION LEVEL COMPONENT DEVELOPMENT

Name of the employee: Employee number:

ARYA R 99008069

Project Mentor BW: Project mentor CU/LTTS:

Title of the project : Application level software component development in

Autosar
Introduction :

One of the goals of the AUTOSAR concept is the support of re-usability on the
level of application software. In other words: it should be possible to re-use
existing artifacts to create further model elements instead of being forced to
create every single modeling detail from scratch. One of the consequences of
this approach is the application of the so-called type-prototype pattern. Among
other things, this concept allows for creating hierarchical structures of software
components with arbitrary complexity. However, the creation of hierarchical
structures itself does not have an impact on the run-time behavior of the overall
system. The actual behavior is completely defined within the individual
software-components. This conclusion is backed by the understanding that
software-components are developed against the so-called Virtual Functional
Bus (VFB), an abstract communication channel without direct dependency on
ECUs and communication buses. The VFB does not provide any means for
expressing a hierarchy of software-components. Of course, the usage of the
VFB has further consequences on the design of software components which
shall not directly call the operating system or the communication hardware. As
a result, software-components can be deployed to actual ECUs at a rather late
stage in the development process.

In AUTOSAR, “application” software is conceptually located above the

AUTOSAR RTE and consists of “AUTOSAR application software-components”
that are ECU and location independent and “AUTOSAR sensor-actuator
components” that are dependent on ECU hardware and thus not readily
relocatable for reasons of performance/efficiency. This means that, subject to
constraints imposed by the system designer, an AUTOSAR
software-component can be deployed to any available ECU during system
configuration. The RTE is then responsible for ensuring that components can
communicate and that the system continues to function as expected wherever
the components are deployed. Considering sensor/actuator software
components, they may only directly address the local ECU abstraction.
Therefore, access to remote ECU abstraction shall be done through an
intermediate sensor/actuator software component which broadcasts the
information on the remote ECU. Hence, moving the sensor/actuator software
components on different ECUs, may then imply to also move connected
devices (sensor/actuator) to the same ECU. The RTE supports both AUTOSAR
software-components.
An “AUTOSAR software-component” cannot directly access basic software
modules – all communication is via AUTOSAR interfaces and therefore under
the control of the RTE.

Literature scope:
Methodology:
Autosar Software component development have 3 levels, as show below

Fig 1: Levels of software component

The highest (most abstract) description level is the Virtual Functional Bus (VFB
level).

The middle level allows for behavior description of a given

AtomicSwComponentType. This so-called SwcInternalBehavior is expressed
according to AUTOSAR RTE concepts, e.g. RTEEvents and in terms of
schedulable units, so-called Runnable Entitys. For instance, for a
ClientServerOperation defined in the scope of a particular ClientServerInterface
on the VFB, the behavior specifies which RunnableEntity is activated as a
consequence of the invocation of the specific ClientServerOperation.
The lowest level of description specifies the implementation (i.e. in terms of the
AUTOSAR meta-model: the SwcImplementation) of a given
SwcInternalBehavior description. More precisely, the RunnableEntitys of such a
behavior are mapped to code (source code or object code). There may be
different SwcImplementations that reference a specific SwcInternalBehavior
description, e.g. in different programming languages, or with differently
optimized code.

In this project it is going to create different application level software

components of the given system, its ports and interfaces(sender-receiver,
client-server) by dividing it into different ecu instances using mentor graphics
VStar Stack and Mapping of these divided ECUs instances.

Fig 2: Graphical representation of software-components in AUTOSAR

Fig 2 shows the ports and interference symbol representation in an Autosar based
project.

Tools: Stack - Mentor Graphics VStar Stack.

 Microcontroller-TC999 from infineon.
Debugger- Lauterbach.
Compiler : Itech.

Project Plan
April : Software Component development
May : Configuration
June : Testing

References
Austosar released documents.