Ultra-Wideband Wireless Vibration Monitoring of Off-Highway Vehicles

Transcription

1 Ultra-Wideband Wireless Vibration Monitoring of Off-Highway Vehicles Nikola Cveticanin, María Luisa Ruiz de Arbulo Gubía, Frederik Petré, Marc Engels Flanders Mechatronics Technology Centre (FMTC) Celestijnenlaan 300D, B-3001 Leuven, Belgium Abstract Vehicle-to-infrastructure communication applications are more and more common in automotive and off-highway vehicle testing. To perform online wireless vibration monitoring of off-highway vehicles, high-end wireless accelerometers are required that combine a high data rate with a low communication latency. However, such high-end wireless sensors are not easy to find in the market. To address this market need, we have developed a prototype of a high-end wireless vibration sensor node. Our sensor node consists of a digital accelerometer, a Field Programmable Gate Array (FPGA) that acts as the central processing and control unit, and a short-range ultra-wide band (UWB) radio. The sensor node was validated in our lab by performing throughput and latency measurements. As a result we have demonstrated that our high-end wireless sensor node achieves a high throughput of 180Mbps and a low latency of 1ms, while still offering the flexibility to be adapted to different applications. Keywords: wireless sensors, vibration monitoring, ultrawideband (UWB) radio, off-highway vehicles, vehicle-toinfrastructure communication I. INTRODUCTION The class of off-highway vehicles comprises a wide range of machinery: forklifts, cranes, backhoes, tractors, combine harvesters, etc. Although the specific requirements and utilities of each of them can be quite different, they have some common needs, for instance, to monitor vibration levels on the machine when in active state. One of these reasons for knowing the vibration levels on an off-road vehicle is monitoring and improving the comfort of the driver of the vehicle. The driver is exposed to so-called whole-body vibrations, which cause backache, stress to the body joints and, in consequence, reduction of the working efficiency. Therefore regulations [1] put an upper limit to this vibration levels. From an economic perspective, getting information about the vibration level on different parts of the vehicle is also important to calculate some key factors about the performance of the machine. For instance, grain loss is one of the damages caused by vibration of a combine harvester [2]. Thus, monitoring vibration levels on a combine harvester is critical to estimate and eventually minimize these losses. Due to the intrinsic characteristics of off-highway vehicles, a realistic vibration level can only be measured while the machine is moving, preferably in an environment similar to its working environment. This is why test tracks, which try to simulate the real working conditions, are commonly used in practice. While driving on the track vibration data on different locations of the vehicle are measured and stored locally. Currently data of multiple laps to the track are stored on the machine and transferred to the controller when the test is finished [3]. This entails a limitation on the use of the test itself: the limited memory inside the vehicle implies a tradeoff between the measurements accuracy and the sampling rate of the sensor. In addition, data analysis and system adaptation will only be made afterwards; fine tuning is not possible unless the processing unit and controller are installed inside the vehicle. To avoid the mentioned problems after each lap the recorded data should be transferred to a controller on the fixed world for further processing and analysis. To avoid time consuming and costly disturbances due to stopping and restarting the vehicle this data transfer should be performed wirelessly while the vehicle is moving next to the controller on the fixed world (see Figure 1). This process implies transmitting big quantities of data in very short periods of time, in other words, high throughput transmission. This is the underlying idea of so called vehicle-to-infrastructure communication: At a fixed point next to the test track, a wireless receiver is placed that collects all data of the current lap when the vehicle passes close to it. The motivation for this work comes from the fact that there are no commercial solutions which accomplish very high data rates to measure rapid motions or vibrations and at the same time provide high resolution that will capture these motions precisely. In addition, the acquired acceleration data should be transmitted in a very short time slot, what makes high throughput a priority. To tackle this need, we have developed a prototype of a high-end wireless vibration sensor node that achieves a high throughput and a low latency based on WiMedia ultra-wideband (UWB) radio technology [4]. The paper is outlined as follows. Section II describes the application requirements imposed on the system. Section III defines the system architecture along with its key components

2 and interfaces. Section IV details the design of the prototype in terms of both hardware and software. Section V analyzes the performance results obtained with the prototype in our lab. Finally, Section VI summarizes our conclusions and proposes some ideas for future research. II. APPLICATION REQUIREMENTS As mentioned in the previous section, the goal of this work is developing a high-end wireless sensor node for vibration monitoring of off-road vehicles on a small test track. The sensor node should allow a fast transmissionn of large amounts of data in a very short time period for a wide range of applications. To achieve this goal, the sensor node should meet the following requirements: Short connection time. The time during which transmitter and receiver are in range is limited and, in consequence, also the communication time. Thus the synchronization process should be minimum in order to maximize the data transmission time. High sampling rate. It is advisable that the sensor be capable of measuring high frequencies, for that a high sampling rate is mandatory. High throughput. As the target is a fast update rate, it is expected that large quantities of dataa will be generated. Sending all these data with a low latency also requires a high throughput. Flexibility. As the target is not a specific application but a range of industrial applications, the system should provide sufficient flexibility to be able to vary the measurement procedures and processing algorithms relatively easily. One particular example is vibration monitoring of a forklift on a straight test track with a typical length of 1 km (Figure 1). This will be taken as a reference to calculate the required update rate and throughput of the sensor node; it will be done in next sections since some parameters involved in the calculation are technology or component dependent. For safety reasons some speed limitations are imposed on forklifts used in real applications: maximum speed of 13 km/h in case no pedestrians are present and 5 km/h in case pedestrians are present. A scenario where the vehicle runs at 13 km/h (3.6 m/s) will be considered. Hence, one lap will take 277 seconds. It will be assumed that the vehicle passes 3 meter far from the master node (Figure 2). Then, once we know the communication range of the wireless link we will be able of calculating the range region. The range region is defined as the distance that the vehicle can cover during which sensor node and master node are in range. With the value of the range region and the speed of the vehicle it is possible to calculate the time during which master node and sensor node are in range or maximum connection time. The communication range is a parameter which depends on the wireless technology selected, so we have to wait until the technology is selected to do the calculations. Figure 1. Application scenario Figure 2. Application scenario, plant view III. SYSTEM ARCHITECTURE When all the aforementioned requirements are taken into consideration, the system architecture can be defined more precisely. The architecture of the system is shown in Figure 3. It consists of two nodes: one master node and one sensor node. The sensor node integrates an accelerometer with a data processing block and a radio, while the master node integrates a radio and a data processing block which sends the received data to a PC. Three main parts must be selected: the wireless technology for communicationn between the master and the sensor node, the data processing blocks, and the type of accelerometer to be used. PC Data processing Radio Wireless link Radio Figure 3. System architecture Data processing Sensor There are four dominant standard protocols for short-range wireless communication. Thesee are Bluetooth (IEEE ), WiMedia UWB (ECMA-368), ZigBee (IEEE ) and Wi-Fi (IEEE ). Table 1 summarizes the features of these protocols [5].

3 Table 1. Comparison of wireless technologies Standard Bluetooth UWB ZigBee Wi-Fi Specification ECMA Frequency band 2.4 GHz GHz 868/915 Mhz; 2.4 Ghz 2.4 GHz; 5 GHz Max signal rate 1 Mb/s 480 Mb/s 250 kb/s 54 Mb/s Nominal range 10 m 3 10 m Nominal Tx power Number of RF channels Channel bandwidth Max number of cell nodes Data protection 0-10 dbm dbm/mhz m (-25)-0 dbm MHz 500 MHz 0.3/0.6 MHz;5 MHz m dbm 14 (2.4 GHz) 22 MHz 8 8 ± bit CRC 32-bit CRC 16-bit CRC 32-bit CRC When looking at UWB s technical capabilities and comparing them with other protocols, several features stand out. First of all, UWB is able to achieve very high data rates, 480 Mb/s at 3 m and 100 Mb/s at 10 m while reducing the latency to the order of ms [6]. The second principal asset is its low cost. Because of the low emitted power level authorized for UWB it is not necessary to use external power amplifier as part of the radio design. Additionally, since the design of the UWB radio is largely digital, the costs of the device decline proportionately to the silicon area consumed. Finally, one of the most important advantages of UWB for indoor applications is its robustness against multi-path fading. For all these reasons UWB has been selected to be the communication protocol between the nodes of the system. For the data processing block, a field programmable gate array (FPGA) has been selected rather than a microcontroller. FPGAs offer an important advantage over microcontrollers: their flexibility. This property allows us to implement efficient application-specific structures, custom routing and even memory blocks [8]. Thanks to this flexibility FPGAs are completely configurable and reprogrammable, what will make possible to adapt our platform to different applications and add functionalities if necessary. Because of the high parallel processing capabilities, it is also well suited for real time signal processing applications. The FPGA device selected for our system belongs to the Altera Cyclone II family [9]. Acceleration is measured using a small digital microelectromechanical (MEMS) sensor, the LIS3Dh from STMicroelectronics [10]; which is a high performance 3-axis linear accelerometer. The choice of the sensor was influenced by several parameters: a digital sensor that avoids having to implement the A/D converter on the board, output data rate, resolution of at least 4 digits, and 3 measurement axes to measure acceleration in x, y and z. These factors will determine the required throughput; the higher the data rate the more samples are taken and the better the resolution the more bits per sample are needed. The selected accelerometer provides a digital 16-bit data output per axis (what means 48 bits per sample), and a maximum sampling rate of 5.4 khz. IV. PROTOTYPE DESIGN To validate the system architecture a prototype of the sensor node was designed. This section consists of two subsections: the first one provides an overview of the hardware design while the second one focuses on the software design. A. Hardware design The top-level block diagram of the system is shown in Figure 4. It consists of two low-latency wireless sensor platforms developed by FMTC, from now on referred to as FMTC prototype boards, two ultra-wideband WiMedia compliant radios based on the Wisair chipset [7], one accelerometer and a PC. FMTC prototype board comprises Cyclone II FPGA, SSRAM and FLASH memory, a serial and an Ethernet port, several GPIOs and a connector for Wisair UWB radio module. Both boards are powered using external power supplies. The accelerometer belongs to a group of MEMS digital output motion sensors and is powered using the power supply pin on the prototype board. Figure 4. Top level system architecture Figure 5 shows a more detailed architecture of the sensor node. The accelerometer is connected to the FPGA via a 4-wire SPI interface. Figure 5. Sensor node Wisair radio modules support several interfaces for data transmission. The Direct CPU interface (DCI) is used for this sensor application. It enables an external device to directly send and receive data over the UWB media. The DCI uses a simple synchronous 8 bit parallel interface. Its key feature is that it can achieve the throughput of up to 200 Mb/s. It supports packet sizes of 5 to 2047 bytes. Both in sensor node and master node, the DCI interface management blocks are implemented in the FPGA by hardware programming in VHDL. The architecture of the master node is shown in Figure 6. Figure 6. Master node

4 In the master node an FMTC prototype board is connected to the PC using a serial interface. B. Software design Both on the master and sensor node Nios II soft-core processor is implemented on the FPGA device. On this processor, a software program was realized. On the sensor side the processor acquires data from the accelerometer and writes it to a specially allocated memory from which it is transferred to the radio module via the DCI interface. On the master side received packets are transferred to the allocated memory for the received packets from which they can be accessed by Nios for further processing. In order to minimize the delays and latencies added by the FPGA design, the Nios II processor has been left outside of the data path for the DCI interface. The flow of the application that runs on Nios II processor is shown in Figure 7 and described in the following paragraphs separately for the master and the sensor nodes. Sensor device: 1. After the power-up, the device (FPGA and radio module) is initialized. 2. Next the sensor node waits for the command by the user application to send a trigger packet to the sensor device. 3. After sending the trigger packet, the sensor node waits for the acknowledge packet sent by the master node. 4. Shortly after receiving the acknowledge packet, the sensor starts sending packets with the real acceleration data 5. While it transmit data, the sensor node also checks if a command has been issued by the user application to stop the transmission 6. When the stop command from the application has been received, a stop packet is sent to the master device 7. The transmission stops when the stop packet has been received and the application jumps back to step 3 and waits for a new trigger command coming from the user. Master device: 1. After the power-up, the device (FPGA, radio module and the accelerometer) is initialized. 2. The master node waits for the trigger packet by the sensor device. 3. Once it has received the trigger packet the master node sends back the acknowledge packet. 4. Once it has received the trigger packet from the sensor node, the master node becomes ready to receive packets containing the information about the acceleration. 5. There are two options for processing the received data on the master side; the data can be either stored in the external SSRAM memory or it can be sent to the PC using the serial interface; both options have a drawback, the first one limits the quantity of acceleration data that can be acquired because of the memory limits; the second one limits the throughput because of the low maximum data rate of the serial interface. 6. As soon as an acknowledge is received for this stop package, the application jumps back to step 2 and waits for a new trigger from the user application. MASTER TRIGGER DATA STOP ACK TRIGGER ACK STOP Figure 7. Application flow SENSOR After the transmission, if the acceleration data was stored in the external SSRAM memory, it is also possible to visualize the received data in text file format. In our set-up trigger and stops signals have been implemented for testing and demonstrating purposes. However, in the real vehicle-to-infrastructure application the two signals can be omitted. In every lap, when the sensor node enters the region where it is in range with the master node they will synchronize. Then the sensor node will start to send the sampled data until all data is transmitted. Finally, when the sensor node leaves the range region, synchronization will be lost. In addition to the Nios software, a graphical application that runs on the PC was developed in LabView in order to allow the user to control the system and retrieve the measured values. When the user presses the Start button on the LabView interface the master sends the trigger signal and the transmission begins. V. PERFORMANCE RESULTS This section describes the tests that were performed with the prototype in our lab to verify the functionality of the developed wireless sensor node. Three tests were carried out in total. The aim of the first two tests was to examine the capabilities of the DCI radio interface in terms of throughput and latency, respectively. For these tests the accelerometer was excluded from the system and dummy data were sent instead. The third test involved testing the whole system with real acceleration data being sent over the wireless link. During the first test for measuring the throughput the sensor node sends a certain number of data packets to the master node which captured the time when each packet is received. From these time stamps the actual throughput is calculated based on the following parameters: physical data rate, superframe

5 duration, duty cycle, packet length and guard interval. This test shows that when the DCI interface is used with the appropriate radio parameters selected, the maximum achievable throughput is close to 180 Mb/s. As previously mentioned, the theoretical maximum throughput of this interface is 200 Mb/s. The difference can be explained by the overhead in the packet structure and the fact that a superframe is split between a transmitting and a receiving device. Table 2 summarizes some of the throughput measurement results. Table 2. Throughput measurement results Superframe Packet PHY Data Rate Duty Cycle Throughput duration Length [Mbps] [%] [Mbps] [ms] [bytes] experiment was repeated for different superframe lengths. It is observed that, as expected, there is a strong dependency between the superframe length and the measured latency. Figure 9 shows the latency measured when transmitting 64 bytes packet at 53.3 Mbps and with a superframe length of 1 ms. The latency follows a uniform distribution with mean value equal to the superframe length, which is 1ms For the latency measurement test, the dependence of the latency on the superframe structure (Figure 8) is taken as the starting point. If data packets to be transmitted arrive to the MAC layer during the master node s transmission time, then, they will have to wait until the sensor node transmission slot starts. If, on the contrary, they arrive during the sensor node s transmission slot, the packets will be sent immediately. Thus, the transmission latency can be reduced by reducing the master node s transmission time, that is, by reducing the superframe length. To prove this theory it is important to have some control over the instant at which the packets arrive to the MAC layer. The DCI interface allows us to set the superframe length and the duty cycle; however, it doesn t provide any information about the packet arrival time. To circumvent this problem we performe the test using another interface available in the Wisair radio chip, the RMII interface. Figure 8. Superframe structure The RMII interface allows to transmitt a set of packet whose arrival is precisely known and follows a uniform distribution along the superframe length. This set of packets is sent over the air and its latency is measured. The same Figure 9. Measured latency with 1 ms of superframe duration 64 bytes of packet size and data rate of 53.3 Mbps The measured latency is the time that lapses from the instant when data packet arrives to the MAC layer on the sensor node to be transmitted and the instant when it arrives to the MAC on the master node. Thus, the communication interface between the radio on the master side and between the PC and the radio and the accelerometer on the sensor side does not intervene in the measurements. In consequence, since the selected interface does not have any influence in the measured latency this result can be applied to our high-end wireless sensor node. The aim of the third test is to evaluate the whole system performance with real acceleration data being transmitted. The measured throughput of the device when no time constraints are applied is roughly 260 kb/s. This value is derived from the following parameters: the accelerometer measures vibrations in 3 axes with a bit resolution of 16 bits and at a maximal sampling rate of 5.4 khz. However, in our specific vehicle-towireless sensor node samples and infrastructure application, the records vibration data during one complete lap on the test track which lasts for 277 seconds. This results in a large chunk of data of roughly 72 Mb. These data can only be sent to the fixed controller station during the time period when the vehicle is close enough to the fixed controller station. As mentioned in Section III the communication range of WiMedia is 10 m at a data rate of 53.3 Mbps. From this value and with a truck speed of 13 km/h we can derive a range region of 19 m covered by the vehicle in more than 5 seconds. During the connection time period, first, the master node (located on the fixed controller station) and the sensor node (located on the vehicle) should resynchronize; second, the sensor node should send the trigger signal and wait for the

6 acknowledgement to start the transmission; and third, the sensor node should send all data recorded on the vehicle. Synchronization: The synchronization procedure in the WiMedia standard is as follows. One of the nodes will detect a new neighbor (the other node). Normally, the superframe timing of the neighbor node will be shifted with respect to the timing of the detecting node. The detecting node will try to align the timing of its beacon to the superframe of the neighbor node. The detecting node will wait and listen to the channel for as many superframes as necessary; typically a couple. In order to be conservative, we will assume a process which lasts 10 superframes of 10ms each (or 100ms in total). Trigger: The latency added by this step corresponds to the system latency measured in our second test, which turned out to be 1 ms. As previously explained this step is only relevant for testing purposes, but unnecessary for the real application implementation. Although it was taken into account for the calculations, its impact is negligible. Data transmission: Since the time for synchronization and triggering is negligible with respect to the total connection time, most of it can be effectively used to transmit the recorded data. To transfer 72 Mb of data in 5 seconds, an effective application throughput of 14.4 Mb/s is needed. Referring back to Table 2, a throughput higher than 15 Mb/s is achieved with a raw PHY data rate of 53.3 Mb/s, a superframe duration of either 10 ms or 1 ms, a duty cycle of 10% and a packet length of 64 bytes. In the case we would like to work at a maximum data rate, 480 Mbps, we would have to take into account that the range decreases to only 3 meters. In addition, to calculate a realistic range region we would have to assume that the minimum distance between master node and vehicle is 2 meters instead of 3. In that case the range region would be 4.5 meters long and it would be covered by the vehicle in 1.24 seconds. This means that we need a throughput of 58 Mbps, to transmit the 72 Mb of data in 1.24 seconds. Referring back again to Table 2 a higher throughput is achieved when transmitting with a packet length of 2 kbits. In this case it could be still possible to increase the duty cycle so that the master node is able of sending some feedback data to the vehicle. Notice that we are working at maximum speed of the vehicle, 13 km/h. If this is reduced, for instance by a factor of two, the time spent to cover a lap will also increase by a factor of two and so the quantity of data to be transmitted. However, also the available transmission time will increase by the same factor. Thus, the resulting throughput will be the same. VI. CONCLUSIONS This paper presents our high-end wireless vibration sensor node which has been developed to fulfill the requirements of vehicle-to-infrastructure communication specifically applied to off-highway vehicle testing. This has been possible by means of integrating different technologies: (1) FPGA technology, which provides us with the required flexibility to easily adapt our sensor node to different industrial applications; (2) high sampling rate MEMS-based digital accelerometers adapted to the more and more demanding applications; and (3) high throughput UWB radio technology which allow us to transmit huge quantities of data in very short periods of time. Our high-end wireless vibration sensor node has been tested and, as a result, very good performance has been demonstrated. The sensor node reaches a high maximum throughput of 180 Mb/s, which is close to the theoretical throughput of the high-speed DCI radio interface, and a low latency of 1 ms, mainly determined by the superframe duration. These features make it ideal for (off-highway) vehicle-to-infrastructure communication applications that are characterized by the need for transferring large amounts of data during short connection periods. More specifically, it has been proved useful for vibration monitoring of a forklift truck on a small test track, requiring a throughput of around 15 Mb/s to transfer 48 Mb of recorded vibration data during a connection period of only 3 seconds. The performance at higher data rate has been proved to be even better; it allows to use a higher duty cycle, what means that some feedback information can be send back to the sensor node during the test. REFERENCES [1] Directive 2002/44/EC of the European Parliament and of the Council of 25 June 2002 on the minimum health and safety requirements regarding the exposure of workers to the risks arising from physical agents (vibration) (sixteenth individual Directive within the meaning of Article 16(1) of Directive 89/391/EEC) - Joint Statement by the European Parliament and the Council. [2] Geert Craessaerts, Wouter Saeys, Bart Missoten, et al., A genetic input selection methodology for identification of the cleaning process on a combine harvester, Part II:Selection of relevant input variables for identification of material other than grain (MOG) content in the grain bin. Biosystems Engineering, 2007, 98(2): P [3] Frederik Petré, Frank Bauwens, Steven Gillijns et a. Wireless vibration monitoring on human machine operator IEEE Symposium on communication and vehicular technology in the Benelux, SCVT 2010 [4] WiMedia Alliance, Distributed Medium Access Control (MAC) for Wireless Networks MAC Specification: Release 1.5, December [5] Jin-Shyan Lee, Yu-Wei Su and Chung-Chou Shen, A comparative study of wireless protocols: Bluetooth, UWB, ZigBee and WiFi, 33 rd Annual Conference of the IEEE Industrial Electronics Society, Taipei, Taiwan, Nov5-7, [6] Michele Paselli, Frederik Petré, Olivier Rousseaux et al., A highperformance wireless sensor node for industrial control applications, Third International Conference on Systems (ICONS 2008), April 2008 [7] Wisair 531, UWB PHY, Data Sheet; Wisair doc. Version DS R1.2; Wisair 2006 [8] M. Shelburne, C. Patterson, P. Athanas et al., MetaWire: using FPGA configuration circuitry to emulate a network-on-chip, Special Issue on selected papers from the 18 th International Conference on Field Programmable Logic and Applications, IET Comput. Digit. Tech., 2010, Vol. 4, Iss. 3, pp [9] Cyclone II Device Handbook, Volume 1. Altera corporation, 2008LIS3DH, MEMS digital output motion sensor ultra low-power high performance 3-axes nano accelerometer; Doc ID Rev 1, May 2010