Autosar -- for software developer

Question

Can you suggest on this points related to Autosar, taking into consideration I am a software developer who can write some software in C?

Now I Develop a functionality in C, that has to read some ECU specific data, process it & update some ECU specific data (which can be some variable or i/o signal).

1. Now how I will be using Autosar RTE & virtual functional bus? What will be there use to a software developer?

2. Also, as Autosar says "standardization of interfaces" what does it mean? Does it mean that if some else anywhere around the world is also developing same functionality (in C language, like me) we both will be using same name of the API's for those I/O signals?

3. How RTE will be helpful for me in Unit testing? Or what really RTE is doing from software developer point of view?

http://www.autosar.org/gfx/AUTOSAR_TechnicalOverview_b.jpg

I read a lot technical terms... but being a software developer these points are important for me to know. Can you explain it a bit to me.

Your reply will be appreciated.

Answer 1

I don't think it is going to be that easy... I believe that you are developing Autosar SWC (software component). I would recommend for you to develop a portable C module. That has very clear inputs, outputs and req. on execution (check Autosar runnables). Remember Autosar ECU includes RTOS, therefore your module will be part of a OS task. When and if you come to the point of building an Autosar ECU, you will be able to wrap the module and connect ins/outs with Autosar virtual functional bus signals. For that you will need Autosar framework and probably configuration tools. These are complex and expensive. Unit test the module the usual way you test C module. Good luck.

P.S. RTE is just the "glue" code generated automatically by configuration tools according the configuration of ECU BSW and System Extract for that ECU. You will worry about it during wrapping.

Answer 2

The Idea behind dividing the functionality in AUTOSAR SWC and Basic software is to make the application SW development independent of any platform. To answer your questions.

1. RTE is giving the application a signal based interface, hence you expect the other SW components (inter-ECU /intra-ECU) to provide the required data in the form of signals, you dont care about the platform or type of communication medium
2. Yes by standardizing the interfaces (all kind of interactions), a software component or any Basic software module can be Fixed into the SW architecture. Read more about the different type of AUTOSAR interfaces.
3. Refer to answer 1

Answer 3

1. RTE is there as a layer to 'abstract' the inner components of the system. For example, if you need to get access to the system's installed flash memory, you have to use the RTE-related memory functions.

2. You are correct. You only need to read the specifications and use the corresponding functions to get your desired result in an AUTOSAR system.

3. RTE makes sure that the developers of the software components and the middle-layer systems would work properly with minimal interaction between them. SWC developers just need to read the AUTOSAR standard and follow it to ensure compatibility with the middle-layer systems, since it is expected that the middle-layer system developers would follow that same standard in providing functionalities on their side. It also helps developers with the portability of their software.

I think all your questions can be answered by reading the AUTOSAR standard documents at the AUTOSAR website. Most of my limited knowledge in development of AUTOSAR systems (started reading about it for close to a month already), I got there.

Answer 4

I am a Software developer who Developed a Console Application Tool for Autosar RTE, Test Case Generation for RTE, and wrote Unit Testing Scripts for the tool I created. I Developed these using C# and NUnit Framework. Same can be Developed using C or a java or any other language. Ultimate goal is to generate AUTOSAR modules (.c and .h files) based on the requirement.

1. Software Developer Scope

As a Software Developer, i had a task to implement complete RTE and Test Applications for the Implemented RTE code.

Inputs and Outputs: Basically our inputs were Software Component files and ECU Extract which were in ARXML format and Outputs were Rte and test application source and header files (.c and .h) which were created based on the requirements.

Tasks as a developer: Here, as a developer, we need to perform Input parsing from AXXML to our own data structure, Schema Validation, Modal Validation, File generation etc.

2. Standardization

Yes, AUTOSAR Architecture provides standardized interface. Irrespective of the implementation strategy, API structure remains same which eases the usage. This acts as a generalised library where you can use already developed Module or you can implement the module in your own way by considering API specification. All you need is to follow the specifications provided for every module you use. Requirement varies from Company to Company but the way of using APIs remains same.

3. Unit Testing

Unit Testing has nothing to do with RTE or AUTOSAR modules. You will be testing the Uints of Your Code. When i say your code, it is the one which you used to develop any particular module (eg. Rte.c) and not testing the generated module itself. You will be testing the Source code you developed to generate the specfic module. Your source code is not part of RTE or any other module implementation but is tool which generates the module implementation.

Overview:

Software developer have various scope in generating AUTOSAR modules depends on the Requirement. You can develop a tool which will generate AUTOSAR modules. You can develop an Editor which will is used to edit/create AUTOSAR XML files. (Eg: Artop) Developing might sound complex as we do not get direct resources other than specifications. Once you are in, you will learn a lot.

Answer 5

To answer your question If you will go through the Layered Architecture of AUTOSAR, you will come to know this architecture is followed to minimize the dependency of the each module (layer) with lower layer.

1. Again, RTE is a like wrapper to separate the lower layered dependency, this enables to work on each layer independently. Most of the virtual buses are mapped with RTE, in my experience I have worked on IOC which is allowed to map with RTE and which communicates with other SWC's with memory and core boudary. To OS Developer its via to the application layer and Mapped software partitions.

2. The standard is used to maintain uniformation in all software layers, however to meet the requirements the developers may have different way of implementation and design, but the API's and requirements will be universal.
   This is useful for standardised intefacing too.

3. For Unit testing of the developers OS design and implementation RTE works as abstract module.

Reading Specs for different module will resolve most of doubts.