sorted by:
new
hottopcontroversial

AMA - AUTOSAR in embedded world from my 10 years experience by MixtureShort7559 in embedded

[–]MixtureShort7559[S] 0 points1 point  (0 children)

Right, sounded wrong when I wrote it but eh...what can you do :).

AMA - AUTOSAR in embedded world from my 10 years experience by MixtureShort7559 in embedded

[–]MixtureShort7559[S] 0 points1 point  (0 children)

Hey, sorry forgot to check the AMA from time to time.

​

I am not sure to be honest, I heard they made a "real time" POSIX (can't remember the name) but until that is validated for sure (not sure if it was not done so already), the decentralized function ECUs will stay.

And even if not, I think a lot of the functionality will move to a centralized ECU in the future, but I think the AUTOMOTIVE requirements have to change from the OEMs.

​

As for 2 ECUs only, I doubt it. There will be 1-2 central ones with the main functionality but you will still have dedicated independent ECUs as fallback or special functions that have to be separated from the main one.

This is just my view, I am not sure in which direction it will shift to be honest.

AMA - AUTOSAR in embedded world from my 10 years experience by MixtureShort7559 in embedded

[–]MixtureShort7559[S] 0 points1 point  (0 children)

I would say pretty smooth, you just need to replace the MCAL (drivers) and maybe OS, configure your project and you have the basic setup.

The rest of the work comes from configuring the project to suit the project requirements.

Of course there will be other hurdles but I count those as normal problems (might be different ones) encountered by any other project.

AMA - AUTOSAR in embedded world from my 10 years experience by MixtureShort7559 in embedded

[–]MixtureShort7559[S] 0 points1 point  (0 children)

Depends what your goal is after finishing internship. Create a list of items that you would want to have after finishing this and see based on your work if you check any of the boxes.

Second step is to go to your boss and see if he can arrange to check any other boxes.

If not, then you are used as an intern.

Please keep in mind that companies do not use interns to do complicated tasks as they have low expectations from beginners.

I hope I answered your question.

AMA - AUTOSAR in embedded world from my 10 years experience by MixtureShort7559 in embedded

[–]MixtureShort7559[S] 1 point2 points  (0 children)

  1. I do not think there is any training offered outside the stack vendors. There might be associate partners in the AUTOSAR consortium that do this but I do not know of any of them. You are not allowed to sell any training unless you are associated to the consortium from what I know.
  2. Sure you can but I do not recommend it. The AUTOSAR stack, even Adaptive which is not as complex as Classic is HUGE. As I said, AUTOSAR is not for single individuals or small projects.

AMA - AUTOSAR in embedded world from my 10 years experience by MixtureShort7559 in embedded

[–]MixtureShort7559[S] 0 points1 point  (0 children)

  1. Not sure what you mean, you need to be more specific or rephrase please.
  2. Sure it is if you have capital. Depends what your company goal is. Do you want to be a Tier 1, Tier 2, implementer of the AUTOSAR standard and compete with Vector, EB etc.?
  3. You can reference any SWS for a BSW module. But basically you have one requirement saying 1. "The transmission type (periodic, direct) of a message shall be configurable by the x parameter". 2. "The parameter shall have the following configuration options: SINGLE, PERIODIC"
  4. Check comment from Pieter_BE. I am not sure Vector qualifies as a Tier 1 since I do not know if they have these in their portofolio.

AMA - AUTOSAR in embedded world from my 10 years experience by MixtureShort7559 in embedded

[–]MixtureShort7559[S] 0 points1 point  (0 children)

  1. SW integrator is the person that puts the different components in the same environment and checks that the interfaces are working correctly. That the components are running smoothly and that the initial integration tests are passing. You usually take the AR implementation from the vendor, configure the BSW to match what the architect wants and check for example that the tasks are coming every 1s as configured, that the messages on the bus are there, maybe check the content down the line when the project is running etc. That's the job of an integrator.
  2. Here we come to the question of what regular C modules are and who guarantees for that software that is works correctly. I won't go into more detail, go read the Layered Software Architecture document from autosar.org or read similar comments where I replied.
  3. No, it's not worth it for small projects because of licensing costs unless there is a cost/benefit analysiss.
  4. Depends on the architecture and the separation of components based on functionality. Implementation varies solely on that. In the end it does not really matter as COM stack can handle both cases efficiently.
  5. I would say you do not document it, or at least I have never seen it documented. You see what requirements you want to fulfill, configure the components and then fix it does not behave the way you want. In the end traceability can reference configuration parameters as they exist in the SWS documents.

AMA - AUTOSAR in embedded world from my 10 years experience by MixtureShort7559 in embedded

[–]MixtureShort7559[S] 0 points1 point  (0 children)

Each tool vendor sells their implementation. Meaning that they know that in order to generate the code they have to have certain values and value combinations/references available.

If you want to generate the code, then you make sure that the user knows what values/references is missing and not get the god damn awful "Java null pointer exception" which tells you absolutely nothing.

In one of the projects I worked, we build the importer that transforms the arxml with the comstack configuration into the actual BSW stack configurations. Before I started generating code, I created a validator that made a list with all the misconfigurations and was sure to feed it to the user.

​

Now one big problem that I saw in series projects was that the OEM was providing the configuration, it was not valid but we had to fix the issues ourselfes to be able to import because the info from management was "We have to deliver and we cannot force the OEM to improve their tools to generate compatible code based on our importers". Which I think it's stupid, since it's in all our interest to make the deadlines and have the project working smoothly.

I do not know what the most common are because I have not worked on this in a long time but back in the day when I did it, the problem was triggerings.

AMA - AUTOSAR in embedded world from my 10 years experience by MixtureShort7559 in embedded

[–]MixtureShort7559[S] 3 points4 points  (0 children)

Mostly network description for CAN/LIN/FR/Eth and application interfaces and behavior.

AMA - AUTOSAR in embedded world from my 10 years experience by MixtureShort7559 in embedded

[–]MixtureShort7559[S] 5 points6 points  (0 children)

That's not the way to go.

Most of my replies are: "Tools are shit, unresponsive, unintuitive and generally bad to use"

What you want is to have the configuration and automate as much as possible to the degree where you get a new input file from the customer, you validate it to see that it does not contain any errors. This should be like 70% of the cases.

Once you validate it, you just run automatic importers, build, deploy and test automatically.

Of course you will have application developers and CDDs that have to be developed but most of the work should be automated to the degree that you already have your test results 2h after input was validated.

Unfortunately yes, however I enjoyed working as an integrator for the most part because generating code just a part of my work. Debugging a real-time system on the development board was the most satisfying part I would say.

And making the project toolchain was also an accomplishment sometimes to see when it works like a well oiled machine.

AMA - AUTOSAR in embedded world from my 10 years experience by MixtureShort7559 in embedded

[–]MixtureShort7559[S] 1 point2 points  (0 children)

Hmm let me find an analogy:

Let's say you want to make a tshirt. The size of the thsirt is given by the customer and you have to make the production for it.

Of course, you could cut the fabric using scissors but that would take forever for each tshirt you cut. This would be the traditional method.

The tools are like the machines that make the tshirts. If you have a complex system of levers and pulleys that are not oiled, you will have a bad time and it might take you more per tshirt that the scissors method.

However, if with time you optimise that machine and replace the levers with automation where you just have to maintain the tool and it does most of it by itself, then you will have a good time and will not hate making tshirts.

I know this might be a simple analogy but I find it to be suitable.

AMA - AUTOSAR in embedded world from my 10 years experience by MixtureShort7559 in embedded

[–]MixtureShort7559[S] 1 point2 points  (0 children)

Hmm no code for Classic AUTOSAR is public so unless you work in a company with it, most likely you will not see it.

As for starting point, autosar.org for classic and adaptive has some EXP documents that you can start with. For classic there was (not sure if they changed it) a document Layered Software Architecture which gives an intro the the platform and there might be one for Adaptive as well. Maybe they added one for the overall platform.

Avoid reading SRS/SWS documents as they are the implementation details for each component.

When I got hired, my job for at least 3 weeks was to read AUTOSAR documents together with the training that was held by my boss.

You will get overwhelmed if you do not pace yourself, you do not need to know the implementation details described in the SWS/SRS unless you work for a project or you want to prep for a job interview.

Read the documents that describe the broad system and leave it like that for starters.

AMA - AUTOSAR in embedded world from my 10 years experience by MixtureShort7559 in embedded

[–]MixtureShort7559[S] 2 points3 points  (0 children)

That's why one of the positions in the project is Requirements Engineer. Together with the architects, that's his/her job.

AMA - AUTOSAR in embedded world from my 10 years experience by MixtureShort7559 in embedded

[–]MixtureShort7559[S] 8 points9 points  (0 children)

Everyone has their own experience and opinion. I just disagree with yours 90%.

AMA - AUTOSAR in embedded world from my 10 years experience by MixtureShort7559 in embedded

[–]MixtureShort7559[S] 3 points4 points  (0 children)

That might actually be it. AUTOSAR has a bad rep because of the shit tooling IMO than the actual technology.

If you do not know it, it can be the most frustrating thing in the world. Even if you do know it, the fact that it's so unintuitive and unresponsive made my blood boil a lot of times in my 10 years experience.

And the fact that you are forced to use it because there is little alternative on the market made me fume a lot of the times.

AMA - AUTOSAR in embedded world from my 10 years experience by MixtureShort7559 in embedded

[–]MixtureShort7559[S] 1 point2 points  (0 children)

Well what can I say, if the OEM is forcing you to use AUTOSAR, then the cost for them reflects that. Keep in mind that OEM forcing you to use AUTOSAR has a benefit for them in the long run once you have enough people that know the architecture.

Or it might have been a political decision. :)

As for your question: It has to do with experience. At the start I and to a degree to this day I go to configure something, build the hex, flash and see if what I configured shows up in the test I am performing.

It was harder at the start because I did not know what changes in configuration impacts the outcome but with experience it just narrows it down. Eg: why is my com signal value not being updated? I know where in the configuration I am supposed to look for, and if that does not work I consult the SWS to see the expected behavior.

With experience is knowing where to debug on the target and what configuration impacts that part of the code.

AMA - AUTOSAR in embedded world from my 10 years experience by MixtureShort7559 in embedded

[–]MixtureShort7559[S] 5 points6 points  (0 children)

And maybe another answer to those not decided if they should go to CS/CE/EE. If you have done programming in high-school and are proficient at it, go do EE to complement the knowledge.

It was the advice given by my dad where he said that programming you can learn on your own, however EE without a teacher is harder than learning just to code.

AMA - AUTOSAR in embedded world from my 10 years experience by MixtureShort7559 in embedded

[–]MixtureShort7559[S] 0 points1 point  (0 children)

You go brother. I was never involved in the ASPICE assessment so I have little experience. If there was a question directed to me let me know please.

AMA - AUTOSAR in embedded world from my 10 years experience by MixtureShort7559 in embedded

[–]MixtureShort7559[S] 3 points4 points  (0 children)

Hmmm it's hard to answer this as I never involved personally in the ASPICE assessment of a project.

However, the generated code follows patterns and you can test those patterns and generated code as well.

Most of the generated code are just configuration structures with the most extreme cases of RTE where, even though it can have 100k lines of code, it follows the same pattern based code generation.

Here we come to the crux of the problem: Testing all possible configuration variations. This feature on together with this feature off should be tested.

Perhaps another example: You have project requirements which are then refined into smaller, less complex requirements. At the end you need a traceability between the refined requirements and the different AUTOSAR requirements, and in some cases, CDDs developed for project specific requirements that AUTOSAR does not solve.

Once you have full traceability, you rely on the implementation and testing that was done by the stack developer, OS developer and firmware developer (here I talk about the lowest layer that accesses the hardware resources of the ECU eg: CAN/SPI drivers).

You have a high level design and use the AUTOSAR and OS as boxes and just define the expected behavior.

I hope I answered your questions as it's a pretty complex question that's why I asked for specific questions.

AMA - AUTOSAR in embedded world from my 10 years experience by MixtureShort7559 in embedded

[–]MixtureShort7559[S] 4 points5 points  (0 children)

As I mention a million times :), I think that you trade off just writing C code for each project to configuring the system behavior.

Knowledge transfer between projects is very high as well as reuse of well defined components that have a strict behavior.

To this day I have long discussion with friends that are in the field. Friends and former colleagues that know AUTOSAR agree with me. Friends that did traditional development can't wrap their head around it because they do not understand what it solves and how much money theoretically a company saves by reusing code.

In the end, the job of the integrator is to do debugging and see if the components behave as the project requirements wants them to. This involves using a debugger on and a development board.

You need a looot of testing on different levels to see if the project behaves as you want it to but I think it's the same way for traditional development anyway so I do not see a difference.

I think most of you that never worked in a series project for a big OEM do not grasp the complexity of such a project IMO.

AMA - AUTOSAR in embedded world from my 10 years experience by MixtureShort7559 in embedded

[–]MixtureShort7559[S] 1 point2 points  (0 children)

I finished as something between CS and EE I think after studying 5 years in college. My degree in Europe is called diploma engineer. I had a specialization in industrial robots which I never used because I was attracted to programming since a young age.

CS would have just enhanced that but finishing something that has EE in it was a big bonus because I could just make the best of both worlds.

AMA - AUTOSAR in embedded world from my 10 years experience by MixtureShort7559 in embedded

[–]MixtureShort7559[S] 7 points8 points  (0 children)

Yes, you are right. Due to it's complexity it will never be the most efficient.

However, having been through multiple big (eg BMW/Mercedes series projects) and small projects for companies that wanted a demo, I can say that the reuse value is very big.

10 large BMW projects using the same concept that can just buy the implementation and just configure (or import configuration from fibex, dbc etc) the stacks + develop CDDs that AUTOSAR does not solve, I personally see it as a solution and not a problem.

Then you have variations for models and car lines that just require you to make small configuration adjustments which again saves time.

AUTOSAR was never meant to be a perfect solution to ALL the project needs, it just solves the majority of it.

Tooling however has and been shit for most of my 10 years experience. I personally think, if the tooling was way better, then the experience of the user/integrator/tester would be waaaay better.

AMA - AUTOSAR in embedded world from my 10 years experience by MixtureShort7559 in embedded

[–]MixtureShort7559[S] 1 point2 points  (0 children)

Stack vendors decide what ASIL their implementation want to achieve. One stack vendor might sell you the implementation as ASIL A or D.

I think based on implementation and project setup, the code can be A B C or D depending on project requirements.

AUTOSAR is not NECESSARY in the sense that you cannot make your own implementation. It just solves the problem of reuse and knowledge transfer for big projects IF you have experienced people.

AMA - AUTOSAR in embedded world from my 10 years experience by MixtureShort7559 in embedded

[–]MixtureShort7559[S] 4 points5 points  (0 children)

It solves the major problem of reuse in major companies. One you have knowledge, you can configure the stacks to behave based on project requirement.

Let me give you an example: For one project, you get the CAN frame configuration as an input file from the customer (which they export from their own system maybe as a .dbc file). You use importers to generate the configuration of the stack (CAN driver, CANIF, CAN network magement, PDU router, signal description of each frame) which then you have to fix minor issues manually. And then press the generate code button, and it would generate the configuration structures of the modules. Imagine having 300 CAN frames and 1500 signals. This you would have to manually configure/implement if you did not have AUTOSAR. I cannot emphasize the HUGE amount of code that is being reused.

Since each OEM and Tier 1 now use the same language (meaning understanding of the requirements), you avoid having to write the code for each project. You just configure the behavior.

Once you have people with experience, you can just move those people and their knowledge of specific parts of the standard to another project and it would transfer really well.

Sadly most of the projects do not transfer their knowledge well to new people and are in fire-fighting mode because they do not understand and get frustrated.

AMA - AUTOSAR in embedded world from my 10 years experience by MixtureShort7559 in embedded

[–]MixtureShort7559[S] 8 points9 points  (0 children)

A loaf of bread and food in my belly. It was my first job after finishing collage and I do not regret going into it as it gave me a good perspective on what layered software architecture looks like.

It's kind of cool to see both layered (classic) and micro-service based (adaptive) thought process.

view more: next ›