Using of Virtual Instrumentation in the Teaching of Autotronics

Abstract

This chapter presents using of virtual instrumentation for improvement of teaching and demonstration of communication of one of the most popular automotive buses CAN BUS. Virtual instrumentation is used in several ways for easier understanding of communication by using the automotive bus. The first way is a demonstration by visualization of data of programable gateway. The second way of using virtual instrumentation is the visualization of the instrument cluster which is controlled by the student’s development kit with the microprocessor. The visualization is also used for the demonstrational panel which consists of a development kit, instrument cluster, turbocharger, and accelerator pedal. The communication with these components is also visualized. The last usage of virtual instrumentation is controlling real instrument clusters from Skoda and VW vehicles using LabVIEW and CAN BUS interfaces. In both, controlling and visualizing of instrument cluster are used the same messages as in real vehicle, so it is easier for students to understand the structure of communication through automotive buses of the real vehicle.

1. Introduction

The faculty of Electrical Engineering and Information Technology at the University of Žilina (UNIZA) is one of the oldest parts of the entire university (since the university’s origin in 1953). For more than a half of century, this faculty is following novel trends in electrical engineering, electronics, industry, and science.

Last decade, several car manufacturers or manufacturers of car equipment and devices (e.g. KIA, Land Rover, Volkswagen, and Brose) established their factories and also R&D departments in the region of Žilina (northwest part of Slovakia). At this time, we can see decreased demand from mentioned companies for employees in this field. Department of Mechatronics and Electronics (DME) at the University of Žilina immediately started a new study program “Autotronics” to bring the specialists focused on car parts and sensors functionality, electrical devices in vehicles, supplying systems in hybrid or electrical vehicles, programming the car control units, and understanding the auxiliary infrastructure and economic aspects of car manufacturing and transportation.

As we can see in Figure 1, the interdisciplinary character of the entire Department of Mechatronics and Electronics is fully integrated into the Autotronics program.

Figure 1.

Mutual cooperation between divisions of DME.

Following the modern trends in education, adapting to the demands of manufacturers and the industrial environment, and also finding the educational methods during the specific situation caused by COVID-19, we would like to introduce the educational model for selected autotronics courses provided by our department DME. As we will see in the next sections, the model composed of various parts is joined into the functional complex system through the development system LabVIEW from the NI company. Even though LabVIEW was dedicated to creating virtual instruments in a practical environment, it was attractive for education from 1980s as documented in [1]. The studies [2, 3] focus on the advantages of virtual instrumentation in LabVIEW in the engineering education process and the creation of a remote laboratory. NI responded to this trend (usage of LabVIEW in the teaching process) and now we can find many articles, forums, and recommendations for teachers and students directly on NI websites [4]. Researching the internet sources, we can find several complex systems for the education of automotive programs and courses [5, 6]. But these simulators are the systems which contain only real parts of vehicles, so customization is not possible. Also, these simulators are not delivered with visualization software. In [7], the vehicle CAN BUS simulator that is programmed in C language is presented. In [8, 9], systems where CAN BUS interface is controlled and visualized by the original software of the interface or in combination with MATLAB are presented. Thus, these systems are not fully open systems, and customization is more difficult than customization of the LabVIEW application which is used for control and visualization at the same time. This advantage of easy customization led to the cooperation of teachers and students in development: the results of selected bachelor or diploma theses can be integrated to extend the existing model.

One of the most important parts of modern vehicles is the communication between many different systems used in vehicles [7, 8]. There are several automotive buses that can be divided by transmitting speed, the medium and maximum length of the bus, or devices connected to the bus. Real-time control of the internal combustion engine (ICE) of the converter of the electric drive is needed high-speed communication with high reliability. For a less important system like comfort systems, the speed of the bus can be slower, and the transmission media can be simplified. Based on this division, each automotive bus is suitable for the connection of a specific group of devices. Because of its properties, the CAN BUS is used in various systems which make it one of the most common and well-known automotive buses. For purpose of teaching how this automotive bus works, the workbenches of the laboratory were modified. Every workbench contains a connector for connecting students’ evaluation boards with the microprocessor and proposed systems to CAN BUS. Workbenches are connected between each other and to the programable gateway which is connected to the superior workbench. This programable gateway is one of the proposed LabVIEW applications, which is used during the teaching process. During the operation of this gateway, the structure of CAN BUS is demonstrated, which means that there are different frames, the content of each type of frame, and the processing of messages. Following LabVIEW applications are used with components from real vehicles mainly instruments cluster, because on this vehicle component it is easy to see the correctness of communication. These applications serve for demonstration of transmitting data by using scaling and offset which are necessarily high and negative values that can be transmitted directly. From selected vehicle components, demonstration panel which is used as the source of communication for the proposed LabVIEW application with visualization of the instrument cluster was created. The last proposed application generates messages/signals for controlling instrument clusters.

2. CAN BUS

The CAN (Controlled Area Network) bus was developed by BOSCH company as a multimaster messaging system. The CAN BUS specifies a maximum speed up to 1 megabit per second (1 Mbps). The CAN BUS network sends small data blocks point to point from node A to node B under the supervision of a central bus, instead of large blocks like traditional networks such as USB or Ethernet. In CAN bus, data are sent and received in many short messages like temperature, engine speed, pressure, etc. This system of many short messages ensures data consistency for every node in the system [10, 11].

CAN BUS utilizes differential transmission of signals, which results in robust noise immunity and fault tolerance. The transmission of differential signals reduces noise coupling and enables high transmission speed by using twisted pair of wires. The differential transmission utilizes current flowing in each signal wire with the same amplitude but in the opposite direction, which results in a field cancelation effect. This is key for low emission of electromagnetic noise and also for high immunity of the electromagnetic noise.

The CAN protocol defines two logic states of the bus, dominant and recessive states. ISO-11898 defines a differential voltage which represents dominant and recessive state, respectively, bits as shown in Figure 2. In the dominant state (a logic ‘0’), the differential voltage between CANL and CANH must be greater than the minimum threshold value (under 0.5 V for receiver input and under 1.5 V for transmitter output). In the recessive state (a logic “1”), the differential voltage across CANH and CANL must be greater than the minimum threshold. The dominant bit wakes up the recessive bit on the bus to achieve non-destructive bit arbitration [11, 12].

Figure 2.

Differential voltage defined by ISO-11898.

The CAN BUS is a serial communication bus defined by the International Organization for Standardization (ISO), which was developed for the automotive industry for the replacement of a complex wiring harness with a simple two-wire bus. The ISO specification requires high immunity against the electromagnetic interference and the ability to self-diagnostic and the possibility of data error corrections. These features helped to increase the popularity of CAN BUS in various fields of industries like manufacturing, building automation, medicine, etc. The communication protocol CAN BUS by ISO-11898:2003 describes how information is transferred between network devices and corresponds to the OSI (Open Systems Interconnection) model. This model is defined in terms of layers. The physical layer defines communication between nodes that are connected by physical media. The two lowest layers of the seven-layer OSI/ISO model which are the physical and data-link layers are defined by ISO 11898 [11, 13].

Figure 3 shows the application layer that establishes a communication link with a specific higher-level application protocol, such as the vendor-independent CANopen protocol. This protocol is supported by an international group of users and manufacturers from all over the world. Many protocols are designed for the specific applications such as industrial automation, diesel engines, or aerospace [9]. Other examples of CAN-based industry standard protocols are CAN KVASER and CAN from Rockwell Automation’s DeviceNet [13, 14]. Even though ISO 11898 defines the electrical specification of wires and connector, it does not define wires and connector directly. ISO 11898 defines the requirement for termination resistors at each end of the bus with a value of 120 Ω, which can be seen in Figure 4. Most often, this termination resistor is part of hardware dedicated to CAN BUS, so a simple connection of two devices is necessary for the establishment of the communication. The disadvantage of the fact that most devices contain termination resistors is that, if lots of devices are used, the resistance of the bus will be too low. In this case, the termination resistor of some devices must be removed [12, 15].

Figure 3.

Physical and data-link layer definition by ISO 11898 Standard Architecture.

Figure 4.

Connection of nodes to bus with termination resistors.

The CAN communication protocol is a multiple access protocol in terms of the carrier signal with the detection of collision and the message priority decision (CSMA/CD + AMP). CSMA means that each bus node must wait a defined time of inactivity before attempting to send a message. CD + AMP means that collisions of the transmission of more nodes are solved using bit arbitration based on the priority of each message. This priority is defined in the identifier field of each message. The access to the bus and transmission is always given by the identifier field with the higher priority [11, 14]. The communication via CAN BUS is realized with a different type of message or frame with two lengths of identifier. The identifier can be standard with a length of 11-bit or extended with a 29-bit length. The first is the data frame which is used for the transmission of data between nodes of the bus. The second type of frame is the remote frame which is transmitted to the bus for the request of data transmission of a specific node. The third type of frame is the error frame, which is transmitted by the node, which detects the error. The last type of frame is the overload frame which is transmitted by a node to delay the transmission data of the bus to get extra time to process data.

Transfer speed defined by the ISO-11898 standard are from 125 kbps to 1 Mbps. This standard defines standard 11-bit identifier an extended 29-bit identifier [9, 16]. The content of standard 11-bit identifier is shown in Figure 5. This identifier provides up to 2048 different message identifiers, while the extended 29-bit identifier, which is shown in Figure 6 provides up to 537 million identifiers [11, 17].

Figure 5.

Standard CAN BUS frame with an 11-bit identifier.

Figure 6.

Extended CAN bus frame with a 29-bit identifier.

The meaning of the bit fields in Figure 5 is as follows:

• SOF – one dominant Start of Frame (SOF) bit indicates the start of a message and is also synchronized bus nodes after being idle.

• Identifier – the standard 11-bit CAN identifier determines the priority of the message, the lower value in binary form means a higher priority.

• RTR – the single remote transfer request (RTR) bit is dominant when information is requested from another node. All nodes of the bus receive this request, but the identifier defined the specified node of the bus. Corresponding data are also received by all nodes and used by all involved nodes. In this way, all data used in the system are uniform.

• IDE – the single Identifier Dominant Extension (IDE) bit means that a standard CAN identifier is transmitted without an extension.

• r0 – reserved bit (for possible of future supplementation of standard).

• DLC – the 4-bit field of Data Length Code (DLC) defined the number of data bytes to be transmitted.

• Data – up to 64 data bits can be transmitted.

• CRC –15 bits with delimiter used for Cyclic Redundancy Check (CRC) contains a checksum of previous application data for error detection.

• ACK – each node receiving an accurate message overwrites this recessive bit in the original message with a dominant bit, indicating that an error-free message has been sent. If the receiving node detects an error and leaves this bit recessive, it discards the message, and the sending node retries the message after rebitting. In this way, each node acknowledges (ACK) the integrity of its data. ACK is 2 bits, one is for the acknowledgment bit and the other is used as the delimiter.

• EOF – this 7-bit end-of-frame (EOF) field marks the end of a CAN (message) frame and disables bit padding, indicating a padding error when dominant. When 5 bits of the same logic level occur in a row during normal operation, a bit of the opposite logic level is inserted into the data.

• IFS - this 7-bit inter-frame space (IFS) contains the time it takes for the controller to move a correctly received frame to its correct position in the message buffer area.

As shown in Figure 6, the Extended CAN message is the same as the standard message with the addition of:

• SRR – the Surrogate Remote Request (SRR) bit replaces the RTR bit in the standard message location as an extended format placeholder.

• IDE – a recessive bit in the identifier extension (IDE) indicates that more identifier bits follow. The 18-bit extension follows the IDE.

• r1 – After the RTR and r0 bits, an additional reserve bit was included before the DLC bit.

3. Analysis and processing of CAN BUS messages using programable gateway

Data transfer of CAN BUS using fully programable gateway is demonstrated. During the operation of this gateway, the structure of CAN BUS communication is demonstrated, which means that there are different frames, the content of each type of frame, and the processing of messages. A gateway, in general, is a device that is used for the connection of two different buses with the different transmission protocols or buses with the same protocol but with different speeds. A gateway is used for two main reasons: the first reason is the length of the bus at a maximum speed of 1 mbit/s which is only 40 m. With the existing arrangement, it is not possible to connect all students’ workbenches with a superior workbench or teacher’s workbench with one bus. The second reason is the connection of this superior workbench which is used for remote access to students’ workbenches. By using the gateway, it is possible to connect these two CAN BUSES which can use different speeds and is possible to filter messages and resend them from the first bus to the other and vice versa. This gateway can be controlled from a superior workbench with LabVIEW. From this workbench, the message of both parts of the laboratory CAN BUS is visualized. Also, the filtering of messages is controlled from this workbench. This gateway, which block diagram is shown in Figure 7, utilizes NI CompactRIO 9082 as the main part. It is the system that combines a real-time processor for processing and monitoring and FPGA for high-speed logic and precise timing [18]. This system can use up to eight modules; however, this gateway utilizes only two modules. The first of the modules is CAN BUS module NI9853 which disposes of with two high-speed ports with standard DB9 connectors. The second module is the module for SD card NI9802 which is used for transferring data logs to SD cards.

Figure 7.

Block diagram of the connection of gateway.

As mentioned before, the system CompactRIO combines real-time operation using a processor and FPGA; therefore, the programming approach is different from programming other NI measuring and communication cards, NI hardware, or third-party hardware. LabVIEW project is divided into three programs, each for one level of processing – FPGA, real-time, and host computer as we can see in Figure 8. The main program for the acquisition or transmission of data (signals) is based on the usage of specific modules, because some modules are dedicated for usage with FPGA processing and some modules for processing with the processor of CompactRIO. Both used modules, for CAN BUS communication and data transmission to SD cards, are dedicated to the FPGA level. At this level, the FPGA program is used for the acquisition and transmission data of CAN modules like identifier, type of frame, DLC, and an array of data. This main FPGA program is also used for saving data logs to SD cards. This program use mainly functions from the FPGA library. The next level is a real-time program that can be used for processing and visualization, but it is limited in the computation power of the CompactRIO processor. Instead of processing, this level is used for update of shared variables which are used for transmitting data to the host computer. In the host computer data, processing and visualization are limited by the computation power of the PC that is used. This approach is suitable where for visualization a large number of indicators, graphs, etc., like virtual instrument clusters application were used. Also, the complex calculation is easier with this approach because FPGA uses only fixed-point number, so some functions of libraries are missing. In this last level, data from the first or second bus are visualized.

Figure 8.

Block diagram of three programs, each for one level of message processing, top left for FPGA, top right for real time, and bottom for the host computer.

Using front panel controls, it is possible to control the gateway as shown in Figure 9, a basic setting like the speed of each port and the way how the gateway works. The default mode of the gateway is resending data from the first to the second bus without filtering, so the gateway works as a repeater. This mode work with buses with the same speed or resending data from the bus with a lower speed to a bus with a higher speed. To keep the gateway simple, no buffer is needed. In this mode, data are resending when are available on the bus. The next mode is when the gateway sends data on the bus periodically and data are updated when data on the first bus were changed. This mode is used for communication with real hardware because this hardware needs precise periodic communication. The control unit controls the time between messages, and if this time is smaller or greater than the defined time control unit evaluates it as an error in the communication. From the front panel, the size of the log and the start of logging are controlled. The last mode of the operation of the gateway is the filtering work with the same speed of bus or from lower speed bus to higher speed bus because of buffering. This mode of operation has no preset filtering, and filtering is realized in the block diagram individually depending on devices connected to buses.

Figure 9.

Front panel of the program for control of the gateway.

4. Demonstration panel of CAN BUS communication of control unit with instrument cluster and VNT turbocharger actuators and its visualization

For the demonstration of real-time communication of the control unit with sensor and actuator, a demonstration panel was created. This panel with visualization is shown in Figure 10. This demonstrational panel consists of a development kit with a processor with a CAN BUS module which simulated some messages between the control unit of the internal combustion engine and some sensors and actuators based on the position of the accelerator pedal. In Figure 11, we can see block diagram with connection of these components. This communication demonstrates the communication of real components which used scaling and offset for transmission of negative values and values greater than 255, which is the maximum value for the transmission.

Figure 10.

Demonstration panel with the accelerator pedal, simulated control unit, instrument cluster, and turbochargers.

Figure 11.

Block diagram of demonstration panel and its visualization.

The accelerator pedal is connected to two channels of development kit ADC. Two channels are used in the vehicle because of safety reasons. Both signals from the accelerator position sensor are voltage signals in the range from 0 to +5VDC and are equivalent to the position of the pedal. Most often one signal is the half-value of the other signal, or signals have opposite values. This secures that it is possible to check the validity of the signal from the accelerator pedal position sensor. If signals are not in the right relation, the signal is not valid, and the control unit works in safe mode. The next parts of the demonstration panel are two VNT turbochargers. These turbochargers use vanes to regulate boost pressure. These vanes are powered by the electric actuator, and in modern vehicles, actuators are controlled directly by CAN BUS. The last part of this demonstrational panel is the instrument cluster which shows engine speed, coolant temperature and speed of the vehicle, and some indicators. Some signals like fuel-level indicators and some warning indicators are still analog in vehicles.

For communications PC with demonstration panel USB-CAN interface, Kvaser Leaf semi-pro was chosen because of the support of the driver for LabVIEW [19]. LabVIEW drivers contain a library with functions for programming applications with this interface. Function of this library and math library are used most often in this application. This interface is capable of having speed up to 1 mbit/s and supports standard and also extended data frames. For the measurement of analog signals like accelerator pedal position, myRIO was used. For visualization, which can be seen in Figure 12, a virtual instrument cluster was created using gauges and some decorative elements as much as a real instrument cluster.

Figure 12.

Visualization of demonstration panel as virtual instrument cluster and positions of the accelerator pedal and turbochargers actuators.

The virtual instrument clusters show engine speed, vehicle speed, coolant temperature, and odometer as a trip which is calculated from vehicle speed. As mentioned before, fuel level is an analog value and on the demonstration panel, the fuel level sensor is not used (Figure 13).

Figure 13.

Block diagram of visualization of demonstration panel as virtual instrument cluster and positions of the accelerator pedal and turbochargers actuators.

As previously mentioned, visualization must process data as a real instrument cluster (Figure 14). The values of engine speed and vehicle speed are processed with offset and scale, similarly, as shown in Figure 15. The processing of coolant temperature is respective value on indicator that is different from other indicators. It is caused by hysteresis of the thermostat of ICE cooling, so during operation the temperature rises and falls repeatedly. This means that without modifying of processing temperature, indicator will show the temperature the same way. Temperature is processed to indicator to show 90°C in the operating range of temperature (85–110°C) as shown in Figure 13. This means that up to operating temperature, indicator shows real temperature and in the interval of operating temperature shows 90°C. It is a temperature higher than the operating temperature, and the temperature on the indicator rises with a greater slope.

Figure 14.

Nonlinearized curve of temperature indicator.

Figure 15.

Structure of real CAN BUS message [12].

At the task of creating messages, students learn about scale and offset in the calculation of data through CAN BUS. Scaling and offset are necessary because of the structure of the data protocol of CAN BUS. In the description of the protocol was mentioned that it is possible to transmit only unsigned 8-bit numbers. That means to transmit negative values, like temperatures, usage of offset is required. For transmission of a number higher than 255, which is a maximum of one byte, scaling is needed. The second way of transmission of high values is like the speed of the engine, and the 16-bit number is split into two 8-bit numbers and these numbers are transmitted to the bus.

Figure 14 shows the structure of the real message where we can see the usage of two bytes for transmission and usage offset and scale. This message is defined by Fleet Management System (FMS) which is the protocol used in trucks of the main European manufacturers like Scania, Man, Volvo, etc. [20]. This protocol is used as an example because it is one of the few publicly available protocols. Almost all manufacturers of passenger vehicles, respectively, concern of vehicles manufacturer use their own protocols which are not usually publicly available.

This virtual instrument cluster can be used also with students’ development kits not only with the demonstration panel. It is easier for students to debug their program with real communication using this visualization instead of using a real instrument cluster which is quite big in the workspace and does not need a power supply. When students control this virtual instrument cluster, they must use defined messages to control the tachometer, speedometer coolant gauge, and other messages, for example warning indicators are defined by our visualization.

5. Control of instrument clusters using LabVIEW

Visualization of instrument clusters can be modified to be used for controlling real instrument clusters. Gauges are used as controls, so the value is chosen with the position of the gauge needle. Based on the position of the needle of gauges, data of CAN BUS messages are calculated. Data are calculated opposite as for visualization, for example for visualization of engine speed, data from the bus are divided by 4, and for control, data are multiplied by 4. Block diagram for calculation of data with visualization is shown in Figure 16. For demonstration and easier understanding of calculation of message data, subresults and results are shown in decimal and also hexadecimal form, as shown in Figure 17. For communication, CAN-USB interface Kvaser Leaf semi-pro is used. This control of the instrument cluster by using virtual instrumentation serves for the analysis of communication with the real instrument cluster. With this analysis, it is easier for the student to program their own development kit for controlling the real instrument cluster or its visualization.

Figure 16.

Block diagram of LabVIEW program for control of VW instrument cluster through visualization with the calculation of values in decimal and hexadecimal format.

Figure 17.

Control of VW instrument cluster through visualization with the calculation of values in decimal and hexadecimal format.

For the demonstration of the advantages and disadvantages of using the bus in the vehicle, an instrument cluster from an old BMW was used, which was constructed without any automotive bus. Processing signals are shown in Figure 18.

Figure 18.

Block diagram of the connection of the control instrument cluster with CAN BUS (top) and using analog signals (bottom).

On this BMW cluster, all indicators and gauges are controlled by an analog signal. The front panel of the program for control of which cluster is shown in Figure 19. For indicator, it means control with connection +12VDC or GND. For engine speed and vehicle speed, the hall sensor or the inductive sensor is used within the circuit for the signal processor, so the signal is a square wave with a duty cycle of 50%. NTC thermistor serves as the coolant temperature sensor, so the output signal is resistance. The potentiometer is used as a fuel-level sensor, so the output is resistance as well. These two gauges are controlled by PWM with fixed frequency and variable duty cycle.

Figure 19.

Control of BMW instrument cluster through visualization with the generation of analog signals.

For generating PWM signal and logic levels for indicator, myRIO was used. MyRIO is a portable device dedicated for students to the design of control, robotics, and mechatronics system. MyRio contains two identical 34-pin connectors, connectors A and B, with 16 digital inputs/outputs, three 0–5 V analog inputs, and one analog output, 3.3 V and 5 V power output. Two voltage levels are available, because this compact device can use as digital input logic of both voltage levels, but the output has 3.3 V voltage only. Digital inputs/outputs have internal pullup resistors to 3.3 V, and this means that the state of this input without a signal will be always logic 1. Thus, these inputs are controlled by logic 0 (connection to ground). This device also contains a third 20-pin connector C with two ±10 V differential analog inputs and two outputs, eight digital input/outputs, 5 V, +15 V/ -15 V power outputs. Digital inputs/outputs of this connector have internal pulldown resistors to ground, and this means that the state of this input without a signal will be always logic 0. Thus, these inputs are controlled by logic 1 (connection to power output). Each of the analog outputs of all three connectors has its own digital-to-analog converter (DAC), so all analog outputs can be updated simultaneously. All digital-to-analog converters of analog outputs are controlled from FPGA by two serial buses, one for connectors A and B and the second for connector C [21]. This hardware was chosen because of the need to generate four PWM channels and eight GPIO pins in a compact package. With myRIO is used a small board with logic-level transistors to shift logic levels from 3.3 V (myRIO) to +12 V (instrument cluster). Since, myRIO contains FPGA and a processor like cRIO, the programming approach is similar. In Figure 20, we can see part of the block diagram of the program for generating PWM signals. For communication with CAN BUS, Kvaser Leaf semi-pro interface was used, as in other applications. Here, students may realize how CAN BUS can simplify communication and save cabling. For controlling this instrument cluster, theoretically, one message will be enough but with analog control, 22 analog signals (we use only 8 indicators and 12 signals total) would be needed.

Figure 20.

Block diagram of myRIO FPGA application for generating PWM for control of BMW instrument cluster.

6. Conclusions

This chapter is focused on the usage of virtual instrumentation, respectively, LabVIEW to make understanding of autotronics easier for students. Due to the growing amount of electronics in modern cars, where control units, sensors, and actuators communicate with buses, we aim for automotive bus CAN BUS. This bus was chosen because this is one of the most popular automotive buses which is now also used in various fields of industry. A demonstration panel and several applications were created to demonstrate the structure and possibilities of the communication, advantages, and disadvantage of using the bus. The first application is the programable gateway which is implemented in CompactRio with a CAN BUS module and SD card module. This programable gateway can work in different modes. In all working modes, data are transferred from the bus with a lower speed to the bus with a higher speed, or bus with the same speed because of using no buffers. In the first mode, the gateway is only resending CAN BUS frames from one bus to another like a repeater. The data are transferred only when are data available on the bus. In the next mode, data are periodically sent on the second bus, and data are refreshed when data appear on the first bus. This mode is more suitable for usage with real hardware, because real hardware measures the time between messages, to detect the error in communication. That means if the time between messages is greater or smaller than defined, the control unit evaluates corrupted communication. The last mode is the mode with filtering where filtering is implemented in a block diagram based on connected hardware, and there are no preset filters. Settings of the gateway are on the front panel of the application, like the speed of both ports, the working mode of the gateway, and the start of the log to the SD card. The students working with this gateway can better understand the frames of CAN BUS protocol, the structure of frames, etc. The second application is the visualization of the demonstration panel which consists of a development kit (control unit), accelerator pedal, and two turbochargers. The development kit simulates the control unit and based on the position of the accelerator pedal sends messages to actuators of turbocharges and to the instrument cluster. The visualization of this panel visualizes the instrument cluster, the position of actuators of both turbochargers, and the position of the accelerator pedal. This visualization can be used with students’ development kits; therefore, the debugging is easier, and no additional hardware is needed. The CAN BUS communication needs scaling and offset to transmit negative values and values greater than 255, which is a maximum of one byte. With this visualization, students adopt the calculation of data for messages to control the instrument cluster. The last application controls the instrument cluster from the vehicle which instrument cluster communicates with CAN BUS and the second instrument cluster which needed analog signals. Students can see the difference in complexity of wiring with analog signals compared to simple wiring of CAN BUS.

Acknowledgments

This publication was realized with the support of Operational Program Integrated Infrastructure 2014–2020 of the project: Innovative Solutions for Propulsion, Power and Safety Components of Transport Vehicles, code ITMS 313011 V334, co-financed by the European Regional Development Fund and grant no. VEGA 1/0593/20: Research on power flow control in the network using a smart transformer.

Conflict of interest

The authors declare no conflict of interest.