AUTOSAR
Posts 1-10 of 11
- Back
- Next
-
Oliver MeiliThe 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
- 12 Nov 2008, 10:19 pm
-
Allen ZhongThe 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.
- 03 Jul 2009, 04:06 am
-
Oliver MeiliThe 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
- 03 Jul 2009, 08:27 am
-
Akhilesh Misra Group moderatorThe 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
- 06 Jul 2009, 08:13 am
-
Allen ZhongThe 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
- 06 Jul 2009, 11:06 am
-
Pascal Gula Premium Member Group moderatorThe 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.- 06 Jul 2009, 11:45 am
-
Oliver MeiliThe 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
- 06 Jul 2009, 12:37 pm
-
Andreas Graf Premium MemberThe 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
- 06 Jul 2009, 5:03 pm
-
Akhilesh Misra Group moderatorThe 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
- 06 Jul 2009, 7:45 pm
-
Oliver MeiliThe 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
- 07 Jul 2009, 08:50 am
- Back
- Next
