How to determine the (real) cycle time of an AUTOSAR Runnable

Question

I have seen quite a lot of code that uses the cycle time of the Runnable for implementing some timer/timeout. The problem is that if someone decides to change the cycle time of this Runnable, the timer will be incorrect. Example:

#define FOO_TIMER_100MS_REACHED (10U)

FUNC(void, FOO_CODE) FOO_Cycle_10ms( void )
{
  static uint8 t = 0;

  if( t < FOO_TIMER_100MS_REACHED )
  {
    t++;
  }
  else
  {
    ; /* 100ms elapsed - do whatever is necessary */
  }
}

So, how can I determine the cycle time of periodically triggered function FOO_Cycle_10ms from inside this Runnable? In respect to the example above I'm looking for something like:

#define FOO_TIMER_100MS_REACHED ((uint8)(100U / CYCLE_TIME_FOO_Cycle_10ms))

score 0 · Answer 1 · answered Sep 13 '16 at 18:23

The problem is that if someone decides to change the cycle time of this Runnable, the timer will be incorrect.

But can that actually happen? The software component description (SWCD) is always strongly coupled with the implementation. If somebody would change e.g. the runnable name in the SWCD or remove an access point, the code wouldn't compile too.

Other parameters like the runnable to task mapping can be changed by the integrator in a later development stage, but the period is part of the SWCD and thus also coupled with the implementation.

So, IMHO the described issue should not occour. If this does't answer your question, please provide more information about the actual use case.

Here are some use-cases: 1. The person creating the SWCD and the person implementing the code might not be the same. The implementer very often even has no access to the configuration tool. (Of course he/she can view the ARXML) 2. Cycle times may change during the project E.g. because of optimization efforts. Then you have to adjust the code. Best case, only the define - here FOO_TIMER_100MS_REACHED - is affected, but more likely you need to analyze the complete code. 3. You are writing code for some SW-C that should be re-used in other projects. — Oliver Scheid, Sep 19 '16 at 07:54

score 0 · Answer 2 · answered Jul 18 '17 at 03:20

0

Well, the SWCD is actually your contract, that should be discussed on changes with the responsible of the SWCD and the developer. If not, then your process is flawed.

On the other side, there are some ways:

Maybe you can create an Constant value from your SWCD Timing Event period
Create a ClientServer Interface to the TimeService (Tm) Module and let it setup. The Tm allows some handy SW timers backed by some GPT Predef Timers
Create a ClientServer interface with StbM-ServiceNeeds to your SWCD. Then you should be able to access the Synchronized Time Base.

answered Jul 18 '17 at 03:20

kesselhaus

1,241
8
9

In the other answer I mentioned sone use-cases for this problem. The "Constant value from your SWCD Timing Event period" is actually what I am looking for... – Oliver Scheid Jul 18 '17 at 21:22
I know what you mean with the use-cases, since I encounter them all the day. As a SW Architect, I'm supposed to create these SWCD from the outside, but some things should also most likely come from the SWC Developer. But at least the scheduling part is one of the points, the SW Architect has to define to the SW System and changes to that definiton should be clarified by reviews .. yeah I know, the processes can be hard to handle :) And the tooling is the other thing, since these tools cost a fortune and there is no real free/OSS (artop is a rudimentary one, but you still need an company email – kesselhaus Jul 18 '17 at 23:54

score 0 · Answer 3 · answered Nov 17 '21 at 12:32

I had the same discussion ones, because this actually happened for a hot-fix. We saw a potential solution in feeding Os_Service, see SWS_Os_00560, into the components measuring time, but never really tried it.

The Stbm solution we saw also, because we did not have the module in the respective project.

How to determine the (real) cycle time of an AUTOSAR Runnable

3 Answers3