It’s not easy to have a good strategy for software. Things change so rapidly, what is important one day is totally forgotten a day later. Like AUTOSAR. There are 2 main streams, Classic and Adaptive.
Of course, as usual, we decide to concentrate on one and the next day customers start to ask about the other and vice versa.
So, no worries, we will do both!
For Adaptive we are preparing a Beagle Bone with Yocto Linux to get the first samples running, for Classic we have an STM Board that should work with a basic example.
We have already been doing a lot of work in getting a Classic AUTOSAR environment running. There were some examples with it but it still took us 2 days to get LED’s to blink on a board.
There is still a lot of “Voodoo power”involved in our opinion. Some stuff is totally incomprehensible for mere mortals as we are. It does not help when the documentation says: “The do a rebuild, just in case”…. Confidence sounds different.
What also _really_ surprised us is the size of the executable. We always thought that Automotive apps must be small. A blinking LED in 15k is not what I call small… Our UML generated stuff uses less than 1k for that. And we have trouble convincing people that the 1k is worth the increase in understandabilily.
During debugging we noticed lots of layered calls to abstract the Hardware. I think that is a great idea but we seriously doubt if any Automotive Companies is willing to pay the hardware price for that.
We also created Rhapsody models to generate code from that must be run in an AUTOSAR environment. We will then integrate the Rhapsody generated code with the AUTOSAR RTE generated code
I will be on vacation the next 2 weeks. I will still be writing, no worries!
Happy modeling with Rhapsody!
Walter van der Heiden (firstname.lastname@example.org)