Write process level

To understand the cause of the 6 bytes difference at the write-process level in Figure 7-31 on page 100, a closer look at the executed write functions is needed.

Write function V1_0 Size in Byte V2_0 Size in Byte Difference Rte_Write_SwcEvent04_P_Swc04_DataStruct_Event_... 80 78 2 Rte_IWrite_Runnable_Swc03_Event_Impl_DataStruct_Out_... 22 22 0 Rte_Write_SwcIoHwPeriod06_P_Swc06_DataDIN3_Period_... 36 34 2 Rte_IWrite_Runnable_Swc05_Period_Impl_DataDIN2_Out_... 01 01 0 Rte_Write_SwcPeriod02_P_Swc02_DataStruct_Period_... 80 78 2 Rte_IWriteRef_Runnable_Swc01_Period_Impl_DataStruct_... 22 22 0 Write process 241 235 6

Table 7-7: Overview of the write-process and its ROM consumption for both implementations

Table 7-7 provides such detailed overview of the write-process and its ROM consumption for both implementations. It shows that the explicit write function in SingleCoreV1_0 needs more ROM memory to be executed compared to the amount of memory that is needed for SingleCoreV2_0. Whereby, Source code 7-3 and Source code 7-4 on following page illustrate that the need of more ROM memory is caused from the generated notification function in line 3. SingleCoreV1_0 calls the SetEvent function to start the notification process, while in SIngleCoreV2_0 the function ActivateTask, is used. The implementation of the function SetEvent (422 bytes) takes more memory space than the implementation of ActivateTask (408 bytes). The higher ROM consumption of the function ActivateTask can be traced/drawn back to the fact that by fetching the this task more ROM memory is needed.

ROM size in byte ROM size in byte 0: Rte_Write_SwcEvent04_P_Swc04_DataStruct_Event_Expl_DataStruct 0: Rte_Write_SwcEvent04_P_Swc04_DataStruct_Event_Expl_DataStruct 1: { 8 1: { 8 2: Rte_SwcEvent04_P_Swc04_DataStruct_Event_Expl_DataStruct = *(data); 54 2: Rte_SwcEvent04_P_Swc04_DataStruct_Event_Expl_DataStruct = *(data); 54 3: (void)SetEvent(Task_Event_Expl_Swc4to3, Rte_Ev_Run_SwcEvent03_Runnable_Swc03_Odr_Expl_DataStruct_In); 8 3: (void)ActivateTask(Task_Event_Expl_Swc4to3_In); 6

4: return ret; 2 4: return ret; 2

5: } 8 5: } 8

Total: 80 Total: 78

Source code 7-3: Source code of the Rte_Write of SWCIoHwPeriod06 in

SingleCoreV1_0 with its ROM memory consumption

Source code 7-4: Source code of the Rte_Write of

SWCIoHwPeriod06 in SingleCoreV2_0 with its ROM memory consumption

RAM consumption

7.3.2.

The RAM consumption of both implementations differs in only one aspect. Figure 7-32 shows that the RAM consumption has an additional write buffer compared to SingleCoreV1_0.

Figure 7-32: RAM consumption of SingleCoreV1_0 vs. SingleCoreV2_0

0 20 40 60 80 100 120 140 Swc variable Function parameter

Rte buffer Implicit read buffer Implicit write buffer

SingleCoreV1_0 90 90 90 45 0

SingleCoreV2_0 90 90 90 45 45

Byte

ROM consumption

Verification of the analyses of the memory consumption

7.3.3.

The analysis of the memory consumption indicates that the intra-task communication in SingleCoreV1_0 takes 674 Bytes more ROM space than the inter-task communication of SingleCoreV2_0. This large amount of ROM difference between both implementations can be traced back to the implementation of both communication types. In SingleCoreV1_0 is the write and read process implemented in one extended task. Whereas, in SingleCoreV2_0 the write and read process were generated in two separated basic tasks. Not only has the extend task of SingleCoreV1_0 a greater amount of instructions, which is caused through the fact that it includes both communication processes, it also has more instructions because of its ability to transfer into the state “WAIT”. The ability of an extended task to wait for an event to get executed again lead to a longer (more instructions) notification process compared to the notification process of inter-task communication in SingleCoreV2_0. As a result, the implemented intra-task communication of SingleCoreV1_0 takes 674 more bytes of ROM than the inter-core communication in SingleCoreV2_0.

However, a closer look at the RAM consumption shows that in contrast to the previous ROM consumption the intra-task communication in SingleCoreV1_0 takes 45 bytes less of RAM than the inter-task communication of SingleCoreV2_0. This result can be drawn back to the implementation of the implicit inter-task communication of SingleCoreV2_0. This communication is generated under the approach of “Copy strategy” as described in section 3.3 on page 29. This approach includes that each implicit write and read-process is provided with its identical copy of the RteBuffer. Figure 7-34 on page 107 demonstrates this implementation. A comparison of the implementation of inter-task communication in Figure 7-34 with the intra-task communication of SingleCoreV1_0 in Figure 7-33 shows that both communication types are implemented with the same approach. The only difference between both implementations is that in intra-task communication a struct variable (ImpBuffer) with two members, member Out for the write and member IN for the read process, is used as the identical copy of the RteBuffer. While in inter-task communication, due to two separated tasks, two separate variables are used, which cause the additional 45 more Bytes in RAM.

The previous conducted studies, see section 3.5 on page 33, do not provide any information of the memory consumption. Therefore, with the analysis of the memory consumption a new aspect is introduce to analyse communication between tasks.

4. Task_Out SCW_W RunnableOut RTE Rte_Call_Switch Switch status Rte_IWrite(data) OS OsSetEvent(TaskID) 1. SCW_R Schedule E_OK OsGetEvent(TaskID,Event) E_OK Rte_IRead(lvar) Lvar = ImplBuffer.In 2. Copy from ImplBuffer.Out to RteBuffer E_OK OsWaitEvent(Mask) E_OK OsGetEvent(TaskID,Event) E_OK ClearEvent(Mask) E_OK 3. Copy from RteBuffer to ImplBuffer.In RunnableR ImplBuffer.Out = data SingleCoreV1_0_Implicit_Communication

Figure 7-33: Sequence diagram of SingleCoreV1_0 implicit communication

with focus on the copy process

Task_Out SCW_W RunnableOut RTE Rte_Call_Switch Switch status Rte_IWrite(data) OS 1. Task_In StartTask SCW_R RunnableR 3. Copy from RteBuffer to ImplReadBuffer 2. Copy from ImplWriteBuffer to RteBuffer OsActivateTask(TaskID) E_OK TerminateTask() Enable Interrupts osSchedulePrio osDispatcher Rte_IRead() SingleCoreV2_0_Implicit_Communication ImplWriteBuffer = data

Figure 7-34: Sequence diagram of SingleCoreV2_0 implicit communication

8. Summary and conclusion

This section provides a summary of this work by addressing each objective and how these were archived.

1. Objective: To be able to conclude possible speed up gain of a heterogonous multi-core ECU, it is necessary first to investigate the current solution for inter-core communication.

The literature review in section 3 on page 27, presented conducted studies in this field and highlighted the possible bottlenecks of inter-core communication such as synchronization strategy, resource management and notification. Moreover, possible mechanism to tackle these challenges were presented and analysed. The investigation of current solution for inter-core communication also pointed out that it would be beneficial to put the theory of analysed mechanism into practice in the real use case study in automotive industry using a heterogeneous multi-core microcontroller.

2. Objective: The implementation of the mechanism to improve the inter-core communication requires appropriated hardware and software.

Therefore, the requirements for an appropriated system and the most suitable hardware were presented in section 5 on page 42. The investigation of possible hard- and software concluded that the hardware supplied already provided multi-core ECUs, but the software only supported AUTOSAR 3.2, supporting the single-core software architecture. The universal ECU VC121-12 from Vector featuring a heterogeneous dual- core microcontroller was used in this project. This ECU provided the opportunity to investigate the current state of intra-core communication regarding to synchronization strategy, resource management and notification.

3. Objective: For the investigation of the intra-core communication suitable experiments for intra-core and inter-core communication should be design. In addition, these experiments should represent software that is used in automotive industry and includes two different communication technics (explicit and implicit) defined in AUTOSAR standard.

These experiments were designed based on the finding from the review of existing systems, and information on ECU software in the automotive industry. These resources and the design of the experiment were presented section 4.

4. Objective: Before any possible improvements could be conducted the designed experiments has to be implemented by using the AUTOSAR methodology.

Therefore, the implementation and the detailed procedure of the hardware setup as well as the software tool sequence are provided in section 6. In addition, the output of the implementation is described and visualized.

5. Objective: The evaluation of the implemented experiments is mandatory to achieve improvements regarding to performance and memory consumption.

The implemented experiments were evaluated in section 7. The results of the evaluation are as follows: Scheduling

- The implicit read process of SingleCoreV1_0 is executed regardless of whether new data was written by the writing process. This incorrect scheduling of the implicit reading process is due to that the notification process (SetEvent function) is placed outside the implicit write function. Therefore, the implicit reading process in SingleCoreV1_0 is invoked regardless of whether the writing process was executed or not.

- The evaluation of the scheduling process of SingleCoreV2_0 also showed an unexpected behaviour. Two write processes are called sequentially before one read process is triggered. An analyses of the scheduling mechanism resulted in that this behaviour is caused due to the fact that both writing tasks that have the same priority have to be called in the order of their activation, (AUTOSAR, 2014a p. 82 - 83).

Performance analyses

The results of the conducted scheduling analysis have also an impact on the performance of both communication types, intra-task communication and inter-task communication. The results of the performance analysis are as follows:

- In addition to the missing SetEvent function in the implicit write process of SingleCoreV1_0, the performance analysis highlighted that also each implicit communication is missing the second GetEvent function after the writing runnable was executed, as show in Figure 6-8 on page. Such an implementation lead to the implicit notification process structure so that is consists of the functions: WaitEvent, GetEvent, CleaEvent. That means the implicit notification process includes two more functions (WaitEvent and the first GetEvent) then the explicit notification process.

- Nevertheless, the execution time of the notification process in SingleCoreV1_0 is not as great as the execution time of the notification process in SingleCoreV2_0. The incorrect scheduling of SingleCoreV2_0, which was identifies in the scheduling analysis, caused the execution time of the second write function to be included in the calculation of the notification process of the first write-read communication. Finally, the disorder of the write process in SingleCoreV2_0 causes 153 % higher inter-task communication time than the intra-task communication of SingleCoreV1_0.

Memory consumption

The analysis of the memory consumption indicates that the implementation of SingleCoreV1_0, has a higher ROM consumption compared to the implementation of SingleCoreV2_0. The write and the read process are implemented in one extended task in SingleCoreV1_0, whereby the write and read process of SingleCoreV2_0 are implemented in two separate basic tasks. The extended task has the ability to wait for an event and to continue its execution as soon as the corresponded event occurs. Therefore, the extended task needs more instructions to perform this function. Furthermore, the number of instructions that are needed to execute the notification process of the intra-task communication in SingleCoreV1_0 are higher compared to SingleCoreV2_0. Therefore, the intra-task communication of SingleCoreV1_0 takes 674 Bytes more ROM space than the inter-task communication of SingleCoreV2_0.

In contrast to the ROM consumption, the intra-task communication in SingleCoreV1_0 takes 45 Bytes less of RAM than the inter-task communication of SingleCoreV2_0. This result is due to the fact that the implicit communication of the inter-task communication in SingleCoreV2_0 is implemented with an implicit Buffer.

6. Objective: Propose possible improvements in multi-core software design, especially for intra and inter-core communication, in order to improve execution time and memory consumption.