Remote Debugging with Networked Bus Analyzers
Total Page:16
File Type:pdf, Size:1020Kb
Special ANALYZERS Remote debugging with networked bus analyzers By Leif Erik Laerum Remote debugging of VMEbus systems has in the past been unreliable and difficult. Now, new developments such as the inclusion of a network interface within VME bus analyzer technology have made remote analysis far easier and more reliable. This makes deploying test instruments into remote and inaccessible systems more achievable. Many innovations have been made in the VMEbus market dur- Some network security departments will view connection to the ing the last two years. The so-called VMEbus “renaissance” has analyzer over the Internet as making the whole system available developed new standards with new protocols and infrastructure over the Internet. This is a misconception if configured correctly; such as VITA 41 VXS. Some are completely new and others offer however, it may be tough to win this battle, especially since mak- backwards compatibility with existing systems. In addition, the ing a direct connection to a bus analyzer over the Internet requires time to market and development cycle have continued to shrink, the IT group to configure routers to allow IP forwarding and allo- demanding the test and development tool vendors to innovate. cate a public IP address. New developments within VME bus analyzer technology have Another easier method to connect over the Internet is that of uti- made remote analysis much easier and more reliable, which lizing a VPN tunnel. An example of this can be seen in Figure 1. makes deploying test instruments into remote and inaccessible The VPN tunnel provides a secure, encrypted connection between systems more achievable. Improvements in software, commu- two networks. This uses well-established means of communica- nication, and triggering make it easier for users to hone in on tions without jeopardizing security. There are numerous VPN trouble spots without being in the lab right next to the analyzer. protocols used today, and even small, inexpensive routers have support for one or more protocols. Establishing a remote connection To use a powerful bus analyzer tool while not actually being onsite opens up many possibilities for a system integrator or vendor. Placing a bus analyzer in systems delivered to the end customer in certain cases has proven to be a wise investment. This is especially true for field testing and trials of a new design or if the system is located in an area that is difficult to access. Shipping the bus analyzer to the location and installing it in a des- ignated analyzer slot provides the customer with faster response time. The service call may also be far less expensive. Often the end customer does not have the expertise on-site for debugging a problem. For a system integrator and hardware vendor, remote analysis means the engineering team will be able to troubleshoot the issue from any location. The key element making remote debugging possible is the pres- ence of the Ethernet interface on the bus analyzer. The analyzer Figure 1 can be connected to the same network as the other boards in the system as well as PCs, workstations, and switches. The analyzer has a full TCP/IP stack, making it capable of handling DHCP, Terminal server technology is also a way to remotely connect to fixed IP, and other common TCP/IP settings. In a situation where a system. The analyzer GUI application will then be executed on the analyzer is to be used in a local area network, it is easiest to the remote computer. The remote users will log on to the remote use the IP address assigned by the DHCP server. computer from their office using the company’s existing security protocols. To access the analyzer with a WAN approach from the other side of a router, a fixed IP address is better since the address of the Another way to connect to the analyzer is via USB. USB lim- analyzer will not change. If using a fixed IP on a network with a its the connection length to five meters. However, USB provides DHCP server, the analyzer IP address should be reserved to avoid an extremely easy way of connecting a laptop to a bus analyzer conflicts. Remote debugging also includes situations where the already installed in the system. In the lab where network connec- lab is located in another building or floor where there are differ- tivity to the analyzer has a security impact, USB provides a fast ent subnets and networks. and efficient way of communicating with the analyzer. Reprinted from VMEbus Systems / October 2005 Copyright 2005 Special ANALYZERS Although our discussion focuses on the use of bus analyzers, a The analyzer’s power supply voltage monitor continuously reports remote connection to a system also allows remote software debug- the status of the voltages in the system. Alarm thresholds can be ging and upgrading as part of the debugging and repair process. set to report if the voltage is outside a specified range. Figure 2 demonstrates an example of the 5 V supply dropping below the Sharing the bus analyzer user-defined level of 4.80 V. Similarly, temperature measurements There are Web-based services available that allow remote users to can be obtained using a probe attached to the analyzer via a cable. see the screen of an analyzer at the local site. These services are Systems never have uniform temperature throughout so the tem- extremely easy to use and secure and will work on any network perature sensor (“Ext Temp” in Figure 2) can be placed anywhere with http Internet access. Users connected to the analyzer can use in the system for monitoring a particular critical area. The “Brd either USB or Ethernet. They then share the analyzer GUI and Temp” indicator is the temperature of the VMEbus analyzer itself. any other application windows to a website that the engineering team can see as well. Effectively, this will bring the entire engi- neering team to the remote site as well as any third party vendor. Engineers familiar with the system will recognize the source of the problem far quicker when they are able to see the screens, error messages, and live data. Users can configure the analyzer setup with their settings. The Figure 2 GUI implements a workspace allowing each user to save settings and link all analyzer setups and saved data files. When the work- space is saved, it will open the same set of files next time. The user To control a system remotely, the most obvious method is to does not have to reconfigure the analyzer hardware from the previ- build and utilize software and network applications. However, ous user’s settings, thus enabling easy analyzer tool sharing. the VME analyzer can provide a redundant control unit that does not rely on a functional system. One example is the ability to Analysis can also be done offline once a trace file or performance reboot a malfunctioning system by asserting SYSRESET from log is saved. In situations where users have a specific time slot to an analyzer GUI. Using the bus analyzer to assert SYSRESET is debug their part of the system, offline trace viewing makes for identical to pushing the front panel reset button on the slot one more efficient use of the analyzer tool. Users collect trace, log, controller. The analyzer does not have to be in a system controller and performance data during their time slot and view the results slot to perform this function. back in the office. In a remote debugging situation, users can col- lect data from the remote site and bring the files back to the engi- The VMEbus analyzer also has I/O pins that can be toggled from neering team for analysis. The results can also be e-mailed from the GUI. These can be connected to other signals elsewhere in the remote site to the engineering headquarters or third party ven- the system. If a particular device in the system needs to be reset, dors for consultation. all that’s required is to run a wire from the analyzer header to the unit’s reset circuitry. These pins are controlled by the Exerciser Downloading data from the analyzer User Interface and can also be part of Exerciser scripts. Using Ethernet facilitates faster trace buffer download time from the analyzer to the computer than was previously available. Performance monitoring Downloading trace files and other data from the analyzer is not A bus analyzer also offers performance monitoring in a remote something that the user has to wait for like in the past. The ana- setting. This can be used as an early warning system of problems lyzer downloads data around the trigger point first. Thus, the user to come and hopefully reduce or prevent the cost of such a fail- can start viewing the result immediately, while the remainder of ure. The system architect can define real-time monitoring of cer- the trace data is downloaded in the background. Once the user has tain indicators. Statistics gathered and saved prior to deployment determined that the trace results are worth keeping, the tempo- can be used to compare to the deployed situation by replaying rary file can be saved with no download time. The networked bus saved results. analyzers offer user-scalable buffer sizes, reducing the download time even further. In most situations, the activity of interest is The most important VMEbus metrics are Bus Transfer Rate and found among the 1,000 samples before or after the trigger. Bus Utilization. Figure 3 shows a measurement taken in an exam- ple system. The utilization is measured to be 9.2 percent with System monitoring and control a max of 22.6 percent.