This section presents a validation scenario for the edge device. This scenario was based on the FactoRIS project, whose development highlighted the importance of integrating smart sensors in a plug-and-play approach to reduce the development time. In the context of this validation scenario, performance tests were realized to verify the limits of the edge device, concerning the registration and discovery time and read/sampling time.
4.1. FactoRIS Validation Scenario
The validation scenario for the developed edge device was the FESTO Modular Production System used to create a learning factory under the FactoRIS project, hosted by the DIGI2 Laboratory and supported by EIT-Manufacturing.
The FactoRIS project (“Learning Factories for Digital Transformation of SMEs”) intends to contribute to the digital transformation of SMEs by creating learning factories where new technological advances can be used to solve digitalization challenges [
27]. One of the solutions developed in the FactoRIS project was a condition monitoring system to monitor a production line composed of FESTO stations (more information on the FESTO Modular Production System is available at
https://www.festo.com (accessed on 31 July 2022)) [
28].
Part of the actuating system of the FESTO stations is composed of pneumatic actuators, whose components degrade over time. To cope with this degradation, air flow and pressure analog sensors were installed in the pneumatic system to monitor and detect any air leak or other abnormal behaviors (as suggested in Figure 2a) from article [
28]).
The integration of those sensors in the application was done manually, using an ADC for Raspberry Pi, developing custom function blocks to read and convert the analog values, and manually adding the function blocks in the 4diac IDE.
With the edge device proposed and developed in this work, the integration of those sensors in the condition monitoring application can be done faster and with much less human effort. To test the edge device, we considered the following situation:
Two flow sensors and two pressure sensors needed to be connected to the application. Thus, each one of the sensors was connected to a different TIM, which resulted in the connection of four TIMs in the same CAN bus.
This scenario is illustrated in
Figure 7:
When a new transducer (or TIM) was added to the network, the NCAP read its TEDS and, based on the type of transducer, added a new function block to the application editor (4diac IDE). Internally, when the function block was executed, it accessed the NCAP services to read/actuate the respective transducer. In this scenario, the flow and pressure blocks in
Figure 7 were integrated in a plug-and-play approach, being automatically added to the IDE and becoming readily available to be used by the application (represented in
Figure 8).
4.2. Performance Tests
The performance tests consisted of determining how a system performed in terms of speed, responsiveness, and stability under different workloads. In this work, we developed an NCAP that, integrated with DINASORE, constituted an edge device to integrated smart transducers in industrial applications.
To test the plug-and-play feature, we performed tests on the registration and discovery of TIMs available on the network. Furthermore, once a TIM was connected to the NCAP, their interaction was based on the exchange of commands, then we also tested the sending of a Read Data command. These performance tests could be used to compare different communication protocols implemented between the NCAP and TIMs. In this particular case, it was tested with CAN ISO-TP.
The performance tests were based on measuring and analyzing the total time of the action with multiple TIMs in parallel, i.e., with more and less workload in the system. Due to hardware stock limitations on the TIM side, the tests were only performed with up to four TIMs. Further tests should be performed in order to make conclusions on a regression analysis and tendency functions. Each measured time interval presented in the following sections is in fact an average of 20 samples.
4.2.1. Registration Time Tests
When a TIM is turned on, it needs to register itself in the NCAP. The registration process follows the following steps:
The TIM sends a Register command to the NCAP. The NCAP registers the TIM and responds with the new destId (CAN address).
The NCAP sends a Read TEDS command to get MetaTEDS;
If the MaxChan (number of implemented TransducerChannels) field of MetaTEDS is greater than zero, the NCAP sends Read TEDS commands to get the TransducerChannelTEDS of each transducer channel from that TIM. The NCAP registers each transducer channel with the associated TEDS;
The NCAP interprets the TransducerChannelTEDS of each transducer channel to get the physical units;
The NCAP adds the corresponding function block to the 4diac IDE workspace file.
This test intended to analyze the impact of the registration of multiple TIMs at the same time, i.e., when multiple TIMs were turned on simultaneously. The considered measurement interval started with the reception of the first CAN message and ended with the last closing of the workspace file. The results are presented in
Table 1.
In this interval, depending on the length of each TEDS, a lot of CAN messages could be exchanged between the NCAP and the TIM, which led to a higher time interval.
As expected, there was a growth in the registration time when multiple TIMs were registered at the same time. Besides the large number of CAN messages that were exchanged in one registration process, when multiple TIMs were being registered, there were also CAN conflicts once multiple devices were trying to transmit a message.
However, even with registration times up to 2 s (with four TIMs), this value was very low compared to the time needed to manually develop, add and configure function blocks in the 4diac IDE.
4.2.2. Discovery Time Tests
After the registration process, a TIM does not change its destId (CAN address) unless it is restarted. Therefore, when the NCAP is turned on, it needs to discover the TIMs available in the network that were already registered in an NCAP. The discovery process follows the following steps:
The NCAP sends a Discover command in broadcast to the network;
Each TIM that is already registered responds to the Discover command with its destId;
The NCAP registers internally a new TIM with the given destId;
The NCAP sends a Read TEDS command to get MetaTEDS for each TIM;
If the MaxChan (number of implemented TransducerChannels) field of MetaTEDS is greater than zero, the NCAP sends Read TEDS commands to get the TransducerChannelTEDS of each transducer channel from that TIM. The NCAP registers each transducer channel with the associated TEDS;
The NCAP interprets the TransducerChannelTEDS of each transducer channel to get the physical units;
The NCAP adds the corresponding function block to the 4diac IDE workspace file.
In this case, we measured the time to discover and register internally in the NCAP up to four TIMs available in the network. The considered measurement interval started with the start of the discovery process and ended with the last closing of the workspace file. The results are presented in
Table 2.
Similarly to the results in the registration process, the presence of multiple TIMs had a high impact on the discovery process, which could also be explained by the large number of messages that needed to be sent at the same time. Comparatively to the values of the registration process, these values were higher once the process began in the NCAP and the time included a command message to the TIM, the processing of that message in the TIM, and the response to the NCAP.
These values (up to less than 2.5 s with four TIMs) were still a good time with respect to the plug-and-play functionality.
4.2.3. Read Sensor Time Tests
After the registration of a TIM in the NCAP, its interaction is based on the exchange of commands defined by the IEEE 1451.0 standard. These commands are requested from the NCAP via its transducer services interface. During the normal operation of a TIM, the most common and essential command for a sensor-type transducer is the Read Data command. Therefore, tests were performed concerning this command.
The following tests measured the impact of the read of multiple sensors (transducer channels) in parallel, each one on a different TIM. These tests were divided into two measurements: (1) the time needed to execute a read service and (2) the maximum cycle time between consecutive reads. These two measurements were also measured in two different conditions: (1) with direct access to the transducer services, i.e., a thread was launched inside the NCAP’s main thread to each transducer channel, and (2) using DINASORE, i.e., using the complete edge device and the developed function blocks.
The results from the direct access to the transducer services inside the NCAP’s main thread are presented in
Table 3 and
Table 4.
Regardgin the read time, it is clear that a simultaneous operation led to a higher read time, explained by the same reason presented in the previous tests, i.e., because of the conflicts in the CAN transmission and more concurrent processing in multiple threads.
The read cycle time corresponded to the maximum sampling time and was close to the read time, once the next read operation was immediately started. Its inverse gave the maximum samples that could be read in one second, which with four TIMs was only approximately five samples per second. This value was low with respect to real-time applications, but could be sufficient for applications with few time restrictions.
It should be noted that in a read operation, the returned information is in fact a data set, i.e., reading a data set can result in one or more measuring values. Therefore, the real measuring rate should be obtained by multiplying the maximum number of samples per second by the number of values present in a data set (defined in TransducerChannelTEDS). However, the transmission of larger data sets may also impact the read and read cycle times.
Once the NCAP was integrated into a wider edge device that used DINASORE as a runtime environment, the behavior of the read operation using the complete edge device was also tested. The results are presented in
Table 5 and
Table 6.
With the use of DINASORE, the read time increased compared to the read time obtained with a direct access to the transducer services. With the use of DINASORE, more threads were running at the same time, which together with the NCAP threads and CAN communication, increased the read time up to approximately 250 ms with four TIMs.
Regarding the read cycle time, in contrast to the previous case, its value was not similar to the read time. This could be explained by the event trigger mechanism that was executed internally by DINASORE, which was slower than the simple while cycle used in the direct access to the transducer services. Thereby, the maximum number of samples obtained was 3.6 in the case of reading simultaneously the values from four TIMs.
As soon as a TIM is available that implements the referred data sets and provides them in read data operations, additional performance tests must be done to measure the impact of transmitting a larger data set in the CAN network and to analyze the respective cost-benefit ratio.
4.2.4. Tests Summary
The validation scenario provided a real-case test bed where it was necessary to incorporate airflow and pressure sensors into a pneumatic actuation system and connect them automatically (plug and play) to a condition-monitoring application.
Regarding the concrete tests performed, it was concluded that the registration and discovery time (even for the connection of four sensors) was enough to favor a plug-and-play solution, reducing significantly the integration time of these sensors in the application.
In contrast, the read cycle time that could be obtained with this implementation was not very low, which yielded a maximum of 4.9 samples/s (without DINASORE) and 3.6 samples/s (with DINASORE), when considering the simultaneous read of four TIMs. However, these values were presumably overcome with the reading of data sets instead of single values, also defined in the IEEE 1451.0 standard.