Results

In order to be more confident about the electrical signals transmitted by the MCU over the CAN network, a further optional step can be performed: it consists in observing the electrical signals transmitted over the CAN bus by means of an oscilloscope. This step is not fundamental in case all the tests are passed, but can be useful as debugging approach or redundant check.

time rates, and data frame lengths were set according to the defined CAN database.

After being configured, the message sending from the PCAN-USB point of view was started and the correspondence between the data frames sent and the ones received by the MCU checked. As suggested by the test procedure, the test was repeated with different data frames changed at run-time. The results are reported in Fig. 4.32, and as can be seen by the figure, the receiving of CAN messages worked as expected. Therefore, the test was considered passed.

Figure 4.32: Screenshot representing the correspondence between the messages sent by the PCAN-USB node and the ones acquired by the MCU node.

Then, as done previously, the Receive/Transmit windows was restored maintain-ing the same settmaintain-ings for the RX messages 03 and 04. Test 4 was started re-enablmaintain-ing the periodic sending of the CAN messages both by MCU and PCAN-USB nodes.

Also in this scenario, the correspondence between the sent data frames and the received ones was maintained. Indeed, the test was considered passed and the results are reported in Fig. 4.33.

As already explained, these conditions are as close as possible to the nominal operating ones and this scenario simulates the behaviour of the system when it will be connected to the external test bench through CAN network. The bus load was measured by means of the PCAN-View software to estimate the traffic over the network in nominal operating conditions. The results are reported in Fig. 4.34.

The measured mean bus load is equal to 2.4%, and as expected, it is very low. This means that the CAN database designed for the network can be implemented in the system without any issues.

After all the tests were successfully executed, the electrical signals transmitted

Figure 4.33: Screenshot representing the correspondence between the messages exchanged between the PCAN-USB node and the MCU node.

Figure 4.34: Measurement of the bus load in conditions as close as possible to the nominal operating ones.

through the CAN bus were analyzed using the oscilloscope to perform a redundant check about the sent messages and verify their integrity. A screenshot of the acquired signals is reported in Fig. 4.35.

Figure 4.35: Screenshot of the acquisition of the TX message 02 sent by the MCU node.

Software Integration Process

System integration is defined in engineering as the process of bringing together the component sub-systems into one system (an aggregation of subsystems cooperating so that the system is able to deliver the overarching functionality) and ensuring that the subsystems function together as a system, and in information technology as the process of linking together different computing systems and software applications physically or functionally, to act as a coordinated whole[8].

In the context of this thesis, the whole software is composed by the different software components, which constitute the firmware, and the application software obtained through a code generation process in Matlab/Simulink environment. The first step was to integrate together the software components constituting the low-level software. Then, the code generated from the application software was run on the target platform to check the presence of differences with respect to the simulated environment. Lastly, the integration of these two software layers was performed. In detail, the overall integration process was constituted by the steps listed in the following:

1. Software components integration

The software components composing the firmware were tested one at a time as described in chapter 4. This approach was motivated by the absence of communication between the different peripheral drivers with the only exception of Pin Management, which functions are called by the firmware itself to configure the related MCU pins. For this reasons, before to perform the integration between the firmware and application software, it was necessary to integrate all the software components together to verify that all their features continue to work according to their requirements in such conditions. This integration process is described in section 5.1 and the previously developed

The application software was developed through a model-based approach.

Therefore, its behaviour was verified and validated in simulation. Once its code was generated through Embedded Coder in Matlab/Simulink environment, a further verification step was required to check that no errors occurred in the code generation process. Indeed, the application software went through software-in-the-loop (SIL) and processor-in-the-loop (PIL) simulations. In this thesis, only the PIL simulation was analyzed. It was fundamental not only to validate the behaviour of the application software, but also to demonstrate the feasibility of its implementation into the specific target platform measuring its worst case execution time (WCET).

3. Firmware and application software integration

Once both the application and firmware were verified separately as whole, a final integration process was performed. In detail, a new software component was developed to allow the application software to access to the firmware global variables through specific get and set functions. As it will be described in section 5.3, these functions are also responsible to map the firmware variables into variables with the correct unit measurements required by the application and vice-versa. Then, a dedicated environment was developed to run the tasks representing the motor control algorithm of the application on the low-level software layer.

The integration process was carried on using the same laboratory instrumentation described in section 4.2. Furthermore, the trace features provided by Lauterbach Trace32 were fundamental to compute a statistical figure about the worst case execution time of the task related to the application software.

5.1 Software Components Integration

The software components, constituting the firmware of the target platform, were developed following a modular approach. Indeed, as described in chapter 3, the firmware architecture was structured grouping together similar features which use the same peripherals. As result of this approach, each software component was developed and tested maintaining its independence with respect to the others.

Therefore, at this point of the development, an integration process was required before to prepare the software environment that will host the application software.

Since all the software components were already developed and their functions verified, the integration process was strictly related to repeat the already executed tests merging the different test programs in a single executable file. In such a way, all the tests can be repeated to verify if the different peripherals and features interfere each other when they work simultaneously.