AUTOSAR

AUTOSAR

Posts 1-10 of 11
  • Oliver Meili
    Oliver Meili
    The company name is only visible to registered members.
    Short Introduction
    Hello all,

    I've been active in the AUTOSAR world since summer 2005 in different roles.

    I started at the time as project manager and systems engineer at Vector Informatik with the development of the AUTOSAR 1.0 communication and diagnostics stack including the RTE and the tooling which is need around. My task consisted of coordinating all the involved parties (tooling and embedded software development) and finally making the different BSW modules and the RTE run together. This task already gave a thorough understanding of the involved specifications and algorithms.

    Along with the advent of AUTOSAR 2.0 and the acquisition of the 4m Division of Micron Electronics, I was responsible for the first projects which included the complete AUTOSAR 2.0 functionality from Vector Informatik. Training and supporting the customers broadened the understanding of the AUTOSAR basic software significantly. Alongside I helped set up a first training day for a general introduction for colleagues and customers.

    My focus shifted more and more from the development to the customer projects and so I ended up, with the experience from the previous releases of the standard, consulting customers and coaching software developers in the use and development of AUTOSAR compliant software. This not only included the embedded software, but also explaining the not so obvious parts of the AUTOSAR templates and again supporting the colleagues responsible for the extended training.

    At GIGATRONIK I continue in the AUTOSAR world with consulting and software development projects. So in case you need any assistance in porting existing software or setting up new projects, don't hesitate to contact me.

    Best regards

    Oliver eMili
  • User photo
    Allen Zhong
    The company name is only visible to registered members.
    Re: Short Introduction
    Do you have some training PPTs about Autosar ? I want to get some very much.
    thanks.
  • Oliver Meili
    Oliver Meili
    The company name is only visible to registered members.
    Re^2: Short Introduction
    Hello,

    what exactly are you looking for?

    Have you had a look at the official AUTOSAR homepage (http://www.autosar.org). It provides all specifications as well as some very good primers to get you started:

    For a brief overview, what AUTOSAR is all about:
    - http://www.autosar.org/download/specs_aktuell/AUTOSAR_Techni...

    For an overview of all the basic software modules, to get an idea what infrastructure AUTOSAR provides:
    - http://www.autosar.org/download/specs_aktuell/AUTOSAR_Layere...

    Or have a look at the AUTOSAR methodology, i.e. how automotive ECUs are supposed to be developed using AUTOSAR:
    http://www.autosar.org/download/specs_aktuell/AUTOSAR_Method...

    If you have a specific need, please let me know.

    Regards

    Oliver
  • Akhilesh Misra
    Akhilesh Misra    Group moderator
    The company name is only visible to registered members.
    Re^3: Short Introduction
    Dear Mr. Oliver,

    Its good to know about your experience in AUTOSAR.

    My first question is about the model based development of autosar modules. I know the advantages of using model based implementation but what I want to ask is below.

    Q1. I have been working on autosar CAN stack development. CAN driver and interface and I have been pushed to use the raphsody tool to do the CAN driver and Interface development. All that auto code generation etc features.

    Would you suggest to use any model based tool to generate the code automatically for a software which is of driver or CAN interace level? I mean I dont find many classes in driver or many states in driver which I can put in tool. So I am not finding it suitable to use any model based tool for CAN driver or CAN interface. I feel it would be a good idea to use these kind of tools in application layer.

    Q2. Do we need to stick to file structure mentioned in every spec? What if we deviate from the file structure?

    Thanks
    //AK
  • User photo
    Allen Zhong
    The company name is only visible to registered members.
    Re^3: Short Introduction
    I want an example, especially the source code about a SW-C.
    I read a lot about these logic concept such as SW-C,Port...
    ,but what exactly do they mean? I can not map them to program code level (Such as C language)
    Hope you can help me out, thanks
  • Pascal Gula
    Pascal Gula    Premium Member   Group moderator
    The company name is only visible to registered members.
    Re^4: Short Introduction
    Hi Allen,

    as you might have read, a SWC is defined in term of model and implementation. The model of a SWC is decomposed in three levels:
    - interface
    - behaviour
    - implementation

    At the interface level, you are defining the SWC itself (with "mySWC" as short name for example), its ports (let's assume you defined a providing port named "outPort"), and the interface you connect to the port which will gather the data exchanged (let's asume "mySRI" as Sender-Receiver interface and "myData" for the data contained)

    At the behavior level, you defined the semantic of execution of your SWC, with the definition of element like Runnable, Event, IRVs, etc... Let's assume you have defined "myRunnable" as a unique runnable with a symbol of value "my_run" and a timing event. This will lead to the periodic activation of this runnable. You have then to describe the access of your runnable to the data. Several type of access exists, implicit or explicit (refer to the specification for more detail). Let's assume a implicit send for the data contained in the interface of our providing port.

    All those definition will enable you to implement your SWC in C code. You will also use the header generated by the RTE generator to use the RTE API that is necessary for your SWC to communicate with the outside world. My example would look like this:

    "
    #include "Rte_mySWC.h"

    void my_run(void) {
    int aData;

    aData = 1;

    Rte_IWrite_myRunnable_outPort_myData(aData);
    }
    "

    For more information on RTE API that a SWC is able to use depending on the interface and behaviour definition, please have a look at the RTE specification:
    http://www.autosar.org/download/specs_aktuell/AUTOSAR_SWS_RT...

    If you need further help, it would be maybe interesting to have a dedicated training.

    Also, if you have further technical questions, please start a new thread in an appropriate forum section.

    Cheers,
    Pascal
    This post was modified on 06 Jul 2009 at 11:47 am.
  • Oliver Meili
    Oliver Meili
    The company name is only visible to registered members.
    Re^5: Short Introduction
    Hello Akilesh,

    Q1: I personally wouldn't consider model-based design for AUTOSAR basic software modules. They are typically not well suited as specified. Also it never was the intention of AUTOSAR to develop the BSW modules using model-based design. Rather than the BSW modules, the Software Components and thus the applications are meant to be developed using the model-based approach. This is why the corresponding tools support the SW-C template, which only has relevance for the service layer in the basic software.

    Q2: As far as I am aware, the specified files have to be present in a basic software module, so yes, the intention is to stick to the proposed file structure. All the implementations of BSW modules I've seen so far may contain additional files, which should not be a problem as long as the interfaces (<Msn>.h) and Callbacks (<Msn>_Cbk.h) are kept in the corresponding files.

    Regards

    Oliver
  • Andreas Graf
    Andreas Graf    Premium Member
    The company name is only visible to registered members.
    Re^4: Short Introduction
    Allen 你好,

    basically the ports and interface descriptions map to interfaces as described in the RTE spec.
    The behavior shows aspects of the behavior (events and runnables) but it is named a bit misleading IMHO, since the actual behavior ("business logic") is not specified within AUTOSAR. AUTOSAR behavior just points to .c files that contain your behavior.

    Those .c files might come from different sources:

    - ASCET/SD
    - ML/SL
    - other MDSD tools
    - manually written code.

    Hope this helps,

    Andreas
  • Akhilesh Misra
    Akhilesh Misra    Group moderator
    The company name is only visible to registered members.
    Re^6: Short Introduction
    Dear Oliver,

    Thanks for your nice explanation. I had been thinking of the same approach about application and BSW.

    I have almost done CAN If and CAN driver with the file structure intact but finding it difficult to integrate without doing some changes in file structures. Of course I am retaining the basic file structure.

    I thought of doing Can If and CAN driver as separate library but finding it little difficult. Is it really needed to keep them as separate library ?

    Regards
    AK
  • Oliver Meili
    Oliver Meili
    The company name is only visible to registered members.
    Re^7: Short Introduction
    Hello Akilesh,

    AUTOSAR leaves you some degrees of freedom as far as packaging your software is concerned. For one there is the idea of integration conformance classes. According to that idea you either package your software as ICC3 modules, which means each module has to be a library (or source files) in its own right, or you package your software as ICC2 cluster, in which case you build a CAN-cluster library. For the division of the BSW into ICC2-clusters please refer to http://www.autosar.org/download/specs_aktuell/AUTOSAR_BasicS... chapter 3.

    Additionally there is an unpublished proposal for a Makefile concept in AUTOSAR which also defines a directory structure.

    Best regards

    Oliver