Can an AUTOSAR BSW stack (eg. for CAN Communication) be developed based on the specifications provided on their website without purchasing any of the expensive vendor tool? What would be the steps that can be followed? I have been asked to explore this possibility.
AUTOSAR Development
Yes and no. The tooling is a necessary part of the equation in AUTOSAR.
Assuming you're working for an automotive supplier, you'll get ECU-specific set of config files (ECU extract?) that is vaguely similar to, but far more extensive than various exchange formats for CAN messaging. These are typically a bunch of XML files of a format defined by the AUTOSAR consortium. A fairly complex chain of "expensive vendor tools" then converts this into something that can generate code. All the specs are open so you could write your own tools in theory.
On top of the tools, you also need the OS, which could possibly built on top of an open source OSEK system as a starting point. Then there's the MCAL.
Can it be done... Yes. If you work for a huge company (e.g. Bosch) it might be in long-term in your best interest to develop your own solution. But if you work for a smaller scale supplier with a project deadline, you'll probably have to bite the bullet and write the massive check. Hopefully this was factored in when your company bid on a job for an AUTOSAR-based system.
To give you an idea of the scale of such an undertaking, it would be a bit like saying, "I'm writing a cool game, do I need to use Windows, OSX or Linux, or can I write my own operating system too?". Ok, maybe not quite that extreme, but significantly harder than writing your own RTOS and vehicle bus stacks (CAN, LIN, etc). If writing your own RTOS + CAN stack sounds prohibitively complex/difficult, don't even think about it.
Obviously I cannot make the decision for you, but if you're taking opinions from random people on the internet of unstated qualifications, I'd highly recommend against it as a "my first autosar" project, but keep it on the table as a possible internal R&D project with possible long-term savings if you're at a top 50+ automotive supplier doing multiple autosar projects every year. I doubt you could build it for less than it would cost to license everything once. But maybe 5-10 big projects down the road it might pay off.
Complete BSW stack development is handful job, after development of all the modules to integrate the stacks you must have to go for some of the tools and licensed compilers.
To meet the compliance of QM and ASIL, a stack owner must provide the list of compliant tool list along with the whole stack. e.g. for Requirements documentation you have IBM Doors, for Design you have IBM Rhapsodhy or Enterprise architecture, source code management Tools like IBM RTC/PTC Integrity etc. These are the Tools which are compliant and listed in ISO26262. If you are going for QM only, they you have to take overhead to maintain and update all documentation in excel or doc format, which is OK if you cant affort these tools.
Regarding modules like OS, Comasso from Bosch is one of the option with some registration fees you can get a basic level of OS working for your other modules. OS again has to be modified as per the controller which you are going to use. OSEK-based RTOS ERIKA is another opensource option, which can be very much useful if you are doing everything on Linux.
Later comes MDT, PDF and Vender specific parameter files which are base of configurations. Perl is vastly used language for dynamic code generation / Configuration based code generation. Beside all of these you have to have good knowledge of XML, as you dont have to spend on configuration tools, in the background XML should be known to change all types of parameters. I have seen some small vendors in Germany who do the stuffs directly in XML without using configuration TOOL.
Repository will not be an issue SVN you could use for free.
But personally I believe that, all expensive tools are used for person independent system and stack maintenance. I have seen small players who generally can not spend on costly tools, they also do the good business.
In broader way, stack BSW Code) is made up of static code (coming from Concept and SWS's of Each module of Autosar) and Dynamic of configuration dependent code ( which is configurable by End User) and based on the Module Description Template (MDT) configuration parameters of each BSW Module need to be provided in universal extension, most popular is XML format and then you have both configuration based code along with Static code being complete stack. –
Synaesthesia
You might want to take a look at COMASSO. It provides development tools and BSW as well.https://www.comasso.org/
Take a look at MOPED project from Swedish ICT. We use it in our company's projects. It is relatively cheap to reproduce as the MOPED uses Raspberry Pi and easily available mechanical parts.
The pure software part definitely yes! but what would you do with that if you do not have a stack along with the tooling !! That is the catch.
To be able to do business of developing and selling AUTOSAR BSW Stack, you must have to have it scaleable for multiple configurations, this is only possible with the tooling part.
For your internal research and development, you can still develop the software modules, their design and architecture by hard-coding the configuration data in C and visualizing the config structures using any open source xml tool. (AUTOSAR Schema is based on XML)
PM me for more details
Yes you can do on your own by following the Autosar specification. But it takes lot of effort. You need to design the static code and dynamic(configuration) code. For dynamic code you can use any open source xml editors. Parameter definition files can be taken from Autosar portal as well. Lastly you need to be the member of Autosar consortium as well.
I'm afraid of that you can't do it alone by yourself. coz, it's a long history that classical AutoSAR had been in many revisions in the last 20 years, and lots of tricks and specs on the way to be becoming too complex to implements in modern car industry. current autosar vendors had their own close customer partner who have no willing to change another tool for their products.
© 2022 - 2024 — McMap. All rights reserved.