Evaluation Environment for AUTOSAR-Autocode in Motor Control ...

Chapter 4
Goals
This chapter first describes the background for this diploma thesis. Afterwards, it
discusses the idea, why this diploma thesis was arisen and then it addresses the topic
and the requirements.
4.1 Background of the Topic
Chapter 2 gives a short introduction to AUTOSAR, a new standard which is becoming
more important for automotive software development. On the other hand, there is
a lot of existing and not AUTOSAR compliant software in form of the MEDC17
environment, which should not be discarded. But their are two requirements for
supporting AUTOSAR:
• suppliers deliver AUTOSAR compliant software, which should be integrated in
several projects
• a conversion to AUTOSAR should be performed step by step
So the first step, which is agreeable with both, is to integrate AUTOSAR compliant
software in MEDC17. With this, a new follow–up platform for MEDC17 can be
developed according to AUTOSAR and the old can be kept for current projects. So
the migration to AUTOSAR can be done stepwise.
4.1.1 Differences of MEDC17 and AUTOSAR
AUTOSAR and MEDC17 differ in a lot of cases. Here are described some points,
which cause issues by using MEDC17 and AUTOSAR together. This enumeration is
not complete, because not all are identified yet.
Extended tasks
In section 3.1 the operating system ERCOSEK is described, on which the BOSCH
architecture MEDC17 is based. It does not support the from OSEK–OS defined extended
tasks. However, there exist some mechanisms of AUTOSAR, which result in an
extended task after generating the RTE. E.g. a runnable can explicitly use a WaitPoint
to wait for an RTE event. This causes the usage of an extended task.
29