AUTOSAR

AUTOSAR

Posts 1-3 of 3
  • Jesper Melin
    Jesper Melin
    The company name is only visible to registered members.
    AUTOSAR benefits, but how about the tradeoffs?
    I’m currently working on my master thesis in computer engineering and the thesis is about AUTOSAR.

    During my research I have found a lot of papers and articles that mention all the benefits this new standard offers. What I’m looking for is papers or articles that present some of the tradeoffs that surely must exist.

    Overhead, executing time, memory usage…

    In this article <http://www.newelectronics.co.uk/article/22677/Model-behaviou... the author says:

    “Research shows code size and memory requirements tend to be up to 20% more. But clear statements have been made confirming that Autosar is a good way to reduce complexity.”

    This cannot be only text in the world that mentions this, but is feels like that is the case.

    If you have any links or tips for good articles that handles tradeoffs and not only the benefits, it would be great if you could post them in this post :)
    • 13 Oct 2010, 3:13 pm
  • Jesper Melin
    Jesper Melin
    The company name is only visible to registered members.
    Re: AUTOSAR benefits, but how about the tradeoffs?
    Anyone?
    • 21 Oct 2010, 12:10 pm
  • Yannick Moreaux
    Yannick Moreaux
    The company name is only visible to registered members.
    Re^2: AUTOSAR benefits, but how about the tradeoffs?
    ( a snowy afternoon... )

    Hello,

    AUTOSAR is a standard, and a standard is a kind of tradeoff.

    The best solution is always the specific solution. The standard is always the more powerful solution.

    A standard can only be compared with another standard : there is a performance comparison with JASPAR on Autosar.org.

    Before benefits, first you have to invest... .AUTOSAR said “Cooperate on standards, compete on implementation”, you can add “ and buy the tools and COTS !”.
    The AUTOSAR market is new and small, the tools and COTS offers from different AUTOSAR suppliers are not easy to compare, it seems like a telephone subscription. You have to pay between 200K€ to 300K€ in case of a production project just for AUTOSAR Core and Tools. If you also buy some configuration services and else, the bill increases. For your first project, don't wait for direct benefits. You have to increase your project budget, and you have to consider it as an invest for next projects...if you have them. In automotive world, the software added value is not really well estimated in the value chain of the electronic product, this invest will be seen just as an extra cost by your managers. ( Don't speak them about all your legacy software that you can not reuse... ).

    AUTOSAR is a little bit complicated. You have also to invest in skill and knowledge. Some aspects of this technology are new compared to previous traditional software development in software automotive world. Your old C developers will be disoriented. Changes are difficult, an a first reject of this new technology is the normal way.

    AUTOSAR is a very parameterized architecture. There is a lot of configuration parameters, every where, in BSW but also in AUTOSAR Profile Descriptions. There are some problems : first you have to input these parameters, of course, but you have also to choose the good value ( between several ), to justify it, to test it. The count of parameters could be estimate to more than 50000 for a serious project. A great part of these parameters comes from communication stacks. Luckily, they can be imported and partially generated by automatic tools from a Fibex file, for example. But we need powerful tools able to generate and to verify the coherence between all this parameters. All these parameters generate also a 'testability' problem of BSW.

    AUTOSAR reveals explicitly the software complexity which was previously hidden. The profusion of the parameters is an aspect of that. This complexity can only be managed by tools. We are waiting for a new AUTOSAR tools generation. Some current tools are just simple editors, we need more clever tools able to do more powerful verifications and analysis.

    Currently we have in production AUTOSAR R2.1, AUTOSAR R3.0, AUTOSAR R3.1, and more corresponding .xsd schema versions. Some times, it is a little difficult. It is the price of the permanent improvement...and the never ending story of the standard.

    It is difficult to manage changes in .arxml AUTOSAR Profile files. Our Changes Management Tools are designed to manage with text changes. Some text changes are not relevant in an .arxml file.

    My RTE is fantastic ! It seems there are no limits in the imagination of VFB specifiers. All kind of communication and synchronization paradigms are possible. Luckily I have not to implement the RTE, but just to use it. Some synchronization constructions consume too more OS resources. In a multi suppliers SW-Cs development scenario, strict limitation rules need to be defined by ECU integrator. I'm waiting for new MISRA rules for limiting all these dangerous RTE constructions, I 'm sure there will be an automatic tool to buy for that. Seriously, it is certainly a problem to provide an RTE Generator fully compatible with the complex RTE and OS SWS Release R4.0. Release R4.0 SWS are published since last year, and only EB starts to provide the market with Release R4.0 ?

    Safety Concepts have been introduced ( too ? ) lately in AUTOSAR Release R4.0. A partitionment mechanism based on OS-Applications, IOC, (RTE) Partition is defined. But for the moment, the partitionment of BSW is not defined by AUTOSAR. All BSW stacks are considered Trusted and are not isolated between them. It seems not realist, nor realizable, that all BSW can be considered as a Trusted Computing Base. Some solutions are provided outside AUTOSAR with paravirtualization ( pikeOS from SYSGO ).

    But all the AUTOSAR benefits are widely superior to all these tradeoffs which will be solved in near future years.

    In AUTOSAR we trust.

    Best regards,
    • 03 Dec 2010, 5:34 pm