1

I have been tasked with creating a (python) script that will disable a feature in our source code. The code is generated via third party configure software, through which a gui allows changes in settings to disable this feature. These changes take effort, and time to generate, hence the script. Theoretically, there are a bunch of flags in the header files (i.e #define thisFeature STD_ON) which I can flip easily with the script.

The part that is more difficult is changes in the source files, for which some functions are added/removed by the third party configuring software. These may change in the future, so I need to think of a solution that will remain usable. I cannot change the code for the third party application, as I need to avoid the generation process which takes time. I need to make changes so that when we build the product, the required changes are made and compile. Any suggestions would be great.

Clifford
  • 88,407
  • 13
  • 85
  • 165
fordGuy112
  • 23
  • 3

1 Answers1

0

You will either introduce assumptions, which turn into future errors when they fail, or end up reimplemeting the AUTOSAR generator. Their point is to allow a implementation of a configured system under complete control of the supplier of the combination of the static code and the generated code.

Either way, when you need an update of the supplied component you will have much more trouble than when using what is delivered.

So I am afraid the answer is "There is none." (i.e. no alternative).
You can make assumptions on your system and create something which within those assumptions achieves your goal short term.
But long term, whoever decided on using AUTOSAR in your project did that for the reasons which fail when you go around the official generator.
So in sooner or maybe later, the effort you spend now is lost and might finally cause more damage than the benefits you might harvest short term.

Yunnosch
  • 26,130
  • 9
  • 42
  • 54
  • yeah, this is kind of what I figured. Thanks. I think we will be making some well documented short term changes, which will raise errors if any changes are made to what needs to be changed – fordGuy112 Mar 04 '20 at 18:06
  • 1
    That seems a reasonable mitigation to the problem of possible error at updates. Consider making your own answer with that concept. – Yunnosch Mar 04 '20 at 18:08
  • 1
    Note, we considered an alternative, which is to archive the generated files and reuse them as long as the input files (config, SWCD, generators, ...) do not change. We did however not do that, because our analysis pointed to more severe error potential and harder debugging should we ever get the input files and the archived generated files inconsistent. Our risk/effort/speed balance pointed to always generate, never archive. I do not consider this part of the answer, because I am convinced of our decision. But thought to mention it down here. – Yunnosch Mar 04 '20 at 18:12
  • The tools we use for AUTOSAR somehow support workflows and scripts to automate tasks and even allow to execute this from command line. Maybe it's much easier to enable/disable the features per script in the ARXML / config files and then regenerate and compile from command line e.g. by CI system build. – kesselhaus Mar 06 '20 at 00:33
  • @kesselhaus That is true, and usually true for all toolsets (though some put up quite some resistance). The point is however, that no matter how you do the changes (from GUI or via script or via simply using different versions of input files) the generation is afterwards always necessary. The duration of that generation is the problem. – Yunnosch Mar 06 '20 at 06:07
  • @Yunnosch My point here is: a) if they start with such a script, it will last forever, and the actual problem is never solved. b) you might loose any qualification especially regarding ASIL from your vendor. c) a proper CI buidl system (farm) might have no problem with the regeneration and build. d) a lot of issues are usually related to misunderstanding of AUTOSAR concepts.and features. --- Unfortunately, he did not give more details about his problem. – kesselhaus Mar 07 '20 at 00:36
  • @kesselhaus You do realise however, that you are arguing in favor of what I wrote, don't you? If you don't mind however, I will take your contribution into my answer (giving credit to you of course). – Yunnosch Mar 07 '20 at 06:28