Dynamic Architecture 1 Part

Temario:

Dynamic Architecture Overview

Dynamic Architecture

Dynamic Architecture

Intro:
CPUs are expensive, customer always demand more functionality, which leads to high CPU loads. However, correct timing: Misbehavior in the timing behavior can lead to system failures. Known examples are reset problems, functional degradation, like misfire, wrong timing or dropped frames on the network On the other hand, only well-balanced systems can reach very high CPU loads, while at the same time being robust against all kind of disturbances.

Dynamic Architecture

Intro:

Software is implemented in functions Normally, a CPU can only do one calculation after the other All calculations must be put in a sequence Some sequences are fixed (or even required from functional view) Other sequences are decided on-the-fly by the operating system. Such sequences change permanently, and normally no assumption can be made for the order of calculations. Functions are called by other functions, but who calls the "top-level" function? All activities in our software are started by an hardware interrupt or a task activation

Dynamic Architecture

Dynamic architecture mainly deals with tasks and interrupts, their sequencing and their timing behavior

Dynamic Architecture

Dynamic Architecture Dynamic Properties

The dynamic properties are very important for an ECU! The OS scheduler bases the task switches on the priority of the task (High priority first) In case of equal priority, on the order of activation (First-in, first-out) Only a well-balanced system is efficient and robust; on the other hand, wrong priorities can lead to task losses and resets!
1 ms

5 ms

10 ms

40 ms

100 ms

1000 ms

Dynamic Architecture
The dynamic architecture has to fulfil a set of quality objectives: Correctness: A treatment is done in the right recurrence and sequence. Efficiency: The SW must make an efficient use of the HW resources.

Robustness: The SW behaviour is correct in case of CPU overload or unexpected event.

Adaptability: The SW must be standardized to ease portability and adaptability of operations. Maintainability/testability: The correct SW behaviour must be easy to verify.

Dynamic Architecture

Dynamic architecture can be classified in 4 major parts:

Triggers Management Priority Management

Sequencing Management
Timing Management

Dynamic Architecture
Triggers Management

A trigger is a point in time, where a treatment is activated

Dynamic Architecture
Triggers Management Triggers can be classified using different criteria's: Periodicity of the trigger: Sporadic triggers are detected only once or few times between 2 resets. They are due to a transition of the system (i.e reset), and must be used (instead of polling) to initiate strategies. Due to this, they are also called initialisations. Cyclic triggers are recurrent, and may have a time recurrence (i.e. 10ms base time), or an external activation (i.e. LIN message).

Dynamic Architecture
Triggers Management Triggers can be classified using different criteria's (Cont.)

Root cause of the trigger: Change in the electrical state of the ECU (i.e. button transition)
Change in the operating state of the system (i.e. Turn left, turn right Stalk switch transition) Change in a functional state of the system (i.e. engine operating state transition)

Reception of an external signal (i.e. LIN message, electrical edge, ...)

Time triggers

Dynamic Architecture
Triggers Management On recurrence:

Slow (> 40ms, sporadic)

Fast (20ms, 10ms) Very fast (< 5ms, seg). The speed of a functionality influences its design: For fast functions, the design has to focus on CPU load consumption, whereas for slow functions the design has to focus on RAM and ROM consumption.

Dynamic Architecture
Triggers Management

A correct understanding of the behaviour of these triggers is necessary in order to understand the behaviour of the SW.

Dynamic Architecture
Triggers Management Activity:
Indentify Triggers and map it in the time (includes RTOS) for:
CES (Cow Entertainment System) Code. Mathematical Operations Code .

Dynamic Architecture
Priority Management

Dynamic Architecture
Priority Management

Scheduling policies In general, 2 scheduling policies are possible: Preemptive: a high priority task may interrupt the current one at any point. Non-preemptive: a high priority task has to wait the end of the current one.

Dynamic Architecture
Priority Management

Scheduling policies (pre-emptive) The main advantage of a pre-emptive scheduling is that a high priority task will be executed in a very short delay. But its main drawback is the difficulty to ensure consistency of data, as the high priority task may start in the middle of the update of a data.

Dynamic Architecture

Scheduling policies (pre-emptive)

Priority Management

Dynamic Architecture
Priority Management

Scheduling policies (non pre-emptive)

The main advantage of a non-preemptive scheduling is that

data consistency is easily ensured, as no task is started before

the end of the previous one. But its main drawback is the reaction time.

Dynamic Architecture
Priority Management

Scheduling policies (non pre-emptive)

Dynamic Architecture
Priority Management

Scheduling policies
High priority task waits until end of current task Advantages

Non preemption

High priority task interrupts current task at any time before end Advantages

Preemption

*
* *

(only at end of tasks) (maximum of all tasks stack usage) (data locked in the complete task)
Drawbacks * * * Easy data consistency * Reduced stack consumption *

Less task switches

(high priority task starts immediately) (changing the tasks priority) (one task cannot block the system)
Drawbacks * * * Independent dynamics of tasks Flexible architecture

Fast response time

(wait until end of task) (a long task may be incompatible) (a task may block the entire system)
Dependency of tasks Less flexible than preemptive

Large response time

(task switch and resource locking) (Worst case stack = max (each task)) (difficult data flow between tasks)
Difficult data consistency Increased stack consumption

Increased overhead

Dynamic Architecture
Priority Management

Priority Scheme

Dynamic Architecture
Priority Management

Determination of a task priority

Because of its major impact on the global dynamic behaviour, the priority of a task has to be carefully chosen. The three main characteristics to be taken into consideration are: Frequency: If the task has a high frequency, it must have a high priority level: All tasks of higher priority will get executed before, or even interrupt it, and therefore generate a delay in its start. Deadline: If the task has a strong deadline, it must have a high priority level: All tasks of higher priority will be executed before, or interrupt it, and then generate a delay in its completion. The choice of priority is a balance between these characteristics Runtime: If the task has a long runtime, it must have a low priority level: Its execution will delay the execution of all lower priority tasks. The choice of priority is a balance between these characteristics.

Dynamic Architecture
Priority Management

Data consistency

An application could have a big number of data and a big data flow: static data flow between (sets of) modules, and dynamic data flow between tasks, task sections, or interrupts (a data is used by a task as soon as it is used by one operation of the complete call graph of the task).

Dynamic Architecture
Priority Management

Data consistency
The static data flow is usually well mastered: Formalisation is easy: it is "immediate" to determine which module produces which data. Applying the principle of encapsulation = hide as much data as possible. Assuming one single producer module, for various consumers. Access to a data outside a module is done using extern declaration and

header files.
A failure will hardly generate a bug at runtime, but will be detected by the linker.

Dynamic Architecture
Priority Management

Data consistency
The dynamic data flow is more complex to master: Formalisation is complex: it is not immediate to determine which tasks produce

one data .
Encapsulation impossible : there are few cases of data used in one single task or task section. Assuming a single producer is very difficult: a lot of data need at least an initialisation, in addition to the nominal calculation. Nothing on coding level allows restricting access of a data to a (set of) task(s). A failure may generate a serious malfunctioning of the SW, as one data

suddenly gets a completely inconsistent value.

Dynamic Architecture
Priority Management

Data consistency
Errors on the dynamic data flow are nearly impossible to detect by dynamic testing due to their sporadic and indeterminist occurrence. Once an inconsistent data value is detected, it is difficult to identify whether this data is the origin of the problem or the result of another inconsistent data. This kind of errors may happen on ISR level as well as preemption or cooperation level.

Dynamic Architecture
Priority Management

Data consistency
Example (Low read, High write):
(A) In cooperative task (low prio):
/* 32 bit counter */ u16 shared_data[2]; u16 temp_lo, temp_hi; temp_hi = shared_data[1]; /* wrong if preempted here! */ temp_lo = shared_data[0];

(B) In preemptive task (high prio):

/* increment 32 bit counter */ if( shared_data[0]==0xFFFF ) {shared_data[0] = 0; shared_data[1]++; } else shared_data[0]++;

Dynamic Architecture
Priority Management

Data consistency
Example (Low write, High read):
(A) In cooperative task (low prio): /* 32 bit counter */ u16 shared_data[2]; if( shared_data[0]==0xFFFF ) {shared_data[0] = 0; /* wrong if preempted here! */ shared_data[1]++; } else shared_data[0]++; (B) In preemptive task (high prio): /* read 32 bit counter */ u16 temp_lo, temp_hi; temp_hi = shared_data[1]; temp_lo = shared_data[0];

Dynamic Architecture
Priority Management

Data consistency
Example (Long or complex data):

(A) In cooperative task (low prio):

(B) In preemptive task (high prio):

i64 data; data = 0xFFFFFFFFFFFFFFFF; data = 0xCCCCCCCCCCCCCCCC;

i64 temp_data; temp_data = data; /* what's in temp_data now? */

Dynamic Architecture
Priority Management

Data consistency
Example (Multiple data access):
(A) In cooperative task (low prio): /* read shared flag */ if( lv_shared_flag ) {/* flag is true */ ... } ... /* wrong if preempted here! */ ... if( lv_shared_flag ) {/* flag is true */ ... } ... (B) In preemptive task (high prio): /* modifies shared flag */ flag lv_shared_flag; lv_shared_flag = !lv_shared_flag;

Dynamic Architecture
Priority Management

Data consistency
Example (Data sets):
(A) In cooperative task (low prio):
/* changes state from lv_is to lv_pl */ lv_is = false; /* wrong if preempted here! */ lv_pl = true; state_engstate = NC_STATE_PL;

(B) In preemptive task (high prio):

/* needs to know the state of engine */ if( lv_is || lv_pl ) {/* action in idle speed or part load */ } else {/* default action */ }

Dynamic Architecture
Priority Management Activity: Force the mathematical calculus software to create an data consistency issue (one of each example)
51