SW-C Description. AUTOSAR SW-C n SW-C 3. Virtual Functional Bus. Deployment tools ECU2 AUTOSAR SW-C 3 AUTOSAR SW-C 2 AUTOSAR SW-C 1 RTE

Size: px

Start display at page:

Download "SW-C Description. AUTOSAR SW-C n SW-C 3. Virtual Functional Bus. Deployment tools ECU2 AUTOSAR SW-C 3 AUTOSAR SW-C 2 AUTOSAR SW-C 1 RTE"

Julia Hoover
6 years ago
Views:

1 Architecture SW-C Description SW-C Description SW-C Description SW-C Description SW-C n SW-C 3 SW-C 2 SW-C 1 Virtual Functional Bus ECU Descriptions Deployment tools System Constraint Description ECU1 ECU2 ECU3 SW-C n SW-C 3 SW-C 2 SW-C 1 RTE Basic Software RTE Basic Software RTE Basic Software Gateway

2 Etherogeneous models + separationbetweenthe functionalmodel and and the the architecture model model Functional design System-level Functional design Component model(s) UML/SysML ADL 4.0? Architecture selection Architecture model(s) Function-to-Architecture (deployment) model(s) 4.0? Module design Behavioral model(s) SR models (Simulink) Coding Task model(s) Code implementation

3 and timing SW-C Description SW-C Description SW-C Description SW-C Description SW-C 1 SW-C 2 SW-C 3 periodic periodic AUTOSA R SW-C 1 AUTOSA R SW-C 2 AUTOSA R SW-C 3 AUTOSA R SW-C n 1A 1B 1C 2A 2B 3A 3B Virtual Functional Bus ECU1 ECU2 SW-C 3 SW-C 2 SW-C 1 RTE Basic Software RTE Basic Software Sampling delay periodic BSW RTE 1B periodic CAN msg 1A Interference 1A BSW 1C RTE BSW CAN msg BSW RTE 2A 2B

4 and timing SW-C 1 SW-C 2 SW-C 3 10ms Tasks 50ms 20ms 10ms S1 v1 r11 r12 r13 S2 v2 r21 r22 r23 S3 v3 r31 r32 r33 20ms r11 r12 v1 r21 r31 r32 r22 p3 50ms p3 v1 p3 p1 p2 p3 p4 p5 p6 p7 p8 p9 r13 r23 r33 There may be consistency issues when mapping runnables into tasks: Runnables in the same component share variables in the component s state and are activated at different rates. One runnable makes use of state variables and needs to be executed in response to multiple events at different rates or multiple asynchronous events. There is (data-oriented) communication using ports with non-atomic data between runnables activated at different rates.

5 and timing SW-C 1 SW-C 2 SW-C 3 10ms Tasks 50ms 20ms 10ms S1 v1 r11 r12 r13 S2 v2 r21 r22 r23 S3 v3 r31 r32 r33 20ms r11 r12 v1 r21 r31 r32 r22 p3 50ms p3 v1 p3 p1 p2 p3 p4 p5 p6 p7 p8 p9 r13 r23 r33 Different type of mechanisms to ensure consistency can be used with tradeoffs between time and memory: Use timing analysis to demonstrate safe cooperation Avoid preemption among runnables Use wait-free buffers Use semaphores The best solution may involve a combination of the above

6 Wait-free solutions: RT blocks Rate Transition blocks added buffer space and added latency/delay relax the scheduling problem by allowing to drop the feedthrough precedence constraint The mechanism can only be implemented if the rates of the blocks are harmonic (one multiple of the other) Otherwise, it is possible to make a transition to the gcd of the blocks periods, at the price of additional space and delay

RT blocks: High rate/priority to low rate/priority COST space: 1 additional set set of of variables for for each link link time: overhead of of RT RT implement.

7 RT blocks: High rate/priority to low rate/priority COST space: 1 additional set set of of variables for for each link link time: overhead of of RT RT implement. performance: none Output update only High rate/ priority pri=1 T=1 pri=2 T=2 Low rate/ priority pri=2 T=2 Consistency here is guaranteed by proving there is no preemption

8 RT blocks: Low rate/priority to high rate/priority COST space: 2 additional set set of of variables for for each link link time: overhead of of RT RT implement. performance: 1-1- unit unit delay (low (low rate rate period) Low rate/ priority pri=3 T=2 State update pri=4 T=2 RT-equivalent High rate/ priority pri=1 T=2 pri=2 T=1 Consistency here is guaranteed by proving there is no preemption Output update Output update

9 Limitations in the use of RT blocks (1)

10 Tradeoffs and design cycles RT blocks are not a functional entity but an implementation device RT Blocks are only required because of the selection of the RM scheduling policy in slow to fast transitions because of the possibility of preemption in both cases In both cases, time determinism (of communication) is obtained at the price of additional memory In the case of slow to fast transitions, the RT block also adds a delay equal to the period of the slowest block This is only because of the Rate monotonic scheduling Added delays decrease the performance of controls

11 Consistency issues Consistency issues in the 1-1 communication between blocks with different rates may happen: When blocks are executed in concurrent tasks(activated at different rates or by asynchronous events) When a reader may preempt a writer while updating the communication variables (reader with higher priority than writer) When the writer can preempt the reader while it is reading the communication variables (writer with higher priority). Necessary condition for data inconsistency is the possibility of preemption reader writer or writer reader Also, we may want to enforce time determinism (flow preservation)

12 Consistency issues b 1 b 3 b 2 T=1 T=2 Also, a relaxed form of time determinism may be required Input coherency: when inputs are coming from multiple blocks, we want to read inputs produced by instances activated by the same event

13 Guaranteeing data consistency Demonstrate impossibility of preemption between readers and writers Appropriate scheduling of blocks into tasks, priority assignment, activation offsets and using worst-case response time analysis Avoid preemptionbetween readers and writers Disabling preemption explicitly among tasks (blocks) (condividere RES_SCHEDULER in OSEK) Allow preemption and protect communication variables Protect all the critical sections by Disabling interrupts Using (immediate) priority ceiling (semaphores/osek resources) Problem: we need to protect each instance of use of a communication variable. Advantage (does not require extra buffer memory, but only the additional memory of the protection mechanism) Lock-free/Wait-free communication: multiple buffers with protected copy instructions: Typically w. interrupt disabling Or kernel-level code - Problem:requires additional buffer memory (How much?). Advantage: it is possible to cluster the write/read operations at the end/beginning of a task, with limited change to existing code. - The best policy may be a mix of all the previous, depending on the timing contraints of the application and on the communication configuration.

14 Demonstrating impossibility of preemption Assign priorities and offsets and use timing analysis to guarantee absence of preemption Input data: Mapping of functional blocks into tasks Order of functional blocks inside tasks Worst-case execution time of blocks (tasks) Priorities assigned to tasks Task periods (relative) Offset in the activation of periodic tasks (o wr = minimum offset between writer and reader activations, O wr maximum offset between the activations) Computed data Worst case response time of tasks/blocks (considering interferences and preemptions) R r for the writer R w for the reader Two cases: Priority writer > priority reader Priority reader > priority writer

15 Absence of preemption/high to low priority Condition for avoiding preemptionwriter reader (no assumptions about relative rates of reader/writer) High priority Low priority w r O wr T w R r R rr T w -O -O wr wr

16 Absence of preemption/low to high priority Condition guaranteeing absence of preemption or reader to writer (reader writer) Low priority High priority w w r r R w o wr o wr wr R w R w O wr wr =o =o wr wr =0 =0 T r R w T rr Both conditions are unlikely in in practice

17 Absence of preemption/low to high priority These conditions are ultimately used by the Rate Transition block mechanisms!! Low priority High priority pri=3 T=2 pri=4 T=2 pri=1 T=2 pri=2 T=1 Output update Output update w r O wr =o wr =o wr =0 wr =0 R w R R w T w T r r T r

18 Avoiding preemption Disabling preemption High priority Low priority Low priority High priority The response time of of the high priority block/task is is affected, need to to check real-time properties

Simulink, simulation, code generation and tasks. Marco Di Natale Associate Professor, Scuola S. Anna - Italy, UTRC Visiting Fellow

Simulink, simulation, code generation and tasks Marco Di Natale Associate Professor, Scuola S. Anna - Italy, UTRC Visiting Fellow Simulink model Many things A network of blocks Workspace variables Type