The maximum error is configurable on a parameter basis. We have found that .... This parameter represents a transponder's X-band transmitter current. As with ...
Enabling visualization of large telemetry datasets Henrique Oliveira1 Solenix Deutschland GmbH, Darmstadt, Germany Alexander Lais2 Solenix Deutschland GmbH, Darmstadt, Germany Tiago Francisco3 Telespazio Deutschland GmbH, Darmstadt, Germany and Alessandro Donati4 European Space Agency, Darmstadt, Germany
In spacecraft operations, it is often necessary to analyze long-term trends in telemetry and find correlations over extended periods of time. This is done in a multitude of situations, such as when searching for the root cause of on-board anomalies or relaxing current operational constraints based on past telemetry readings.
Many tools exist at ESA for supporting this process, including rich clients for displaying telemetry in visual charts. However, telemetry time series, due to potentially very high sampling rates (and consequently very large amounts of data), are challenging to plot in a performing and dependable manner with the currently available tools. Moreover, the behavior over time of telemetry can vary among different parameter categories, rendering visualization techniques that show potential for some types not so efficient for others.
In this paper, we present a selection of techniques developed to enable visualization of large telemetry data sets, and analyze their benefits and disadvantages through a series of tests and benchmarks. These techniques include aggregation of data over fixed intervals of time, compression and more advanced methods such as Viewport Resolution Aggregation, a visually lossless aggregation algorithm. The use of these techniques brings advantages such as rendering speed improvements, network bandwidth savings and removes limitations on the user when attempting to visualize years of data. The validation and feedback provided by the ESA spacecraft operators is included as part of the assessment of these techniques.
1
Software Engineer, Future Studies Section, European Space Operations Centre, Robert-Bosch-Strasse 5, 64293 Darmstadt, Germany. 2 Solutions Architect Robert-Bosch-Strasse 7, 64293 Darmstadt, Germany. 3 Spacecraft Operations Engineer, Venus Express Flight Control Team, European Space Operations Centre, RobertBosch-Strasse 5, 64293 Darmstadt, Germany. 4 Advanced Concepts and Technologies Manager, Future Studies Section, European Space Operations Centre, Robert-Bosch-Strasse 5, 64293 Darmstadt, Germany. 1
S
I. Introduction
pacecraft operations depend on the monitoring and analysis of spacecraft data, or “telemetry”. Spacecraft telemetry typically comes in the form of time series, where the value of a given on-board parameter is measured at uniformly spaced time intervals, and made available to operators and tools in the form of a series of (timestamp, value) tuples. These tuples can be plotted in simple line charts. Tools providing easy and efficient access to such line charts are an essential component in spacecraft operations. Telemetry data is very often sampled at very high rates: it is not uncommon for parameters to be sampled every few seconds. Such high sampling rates result in great amounts of points per time series, leading to challenges in efficient storage and in plotting of data. The latter problem, and techniques to address it, is the focus of this paper. At the European Space Operations Centre of the European Space Agency, several tools have been developed with the goal of supporting flight control teams when plotting telemetry data graphically. Many of these tools have at their core MUST – the Mission Utilities and Support Tools database [1, 2]. The goal of MUST is to provide fast and efficient access to spacecraft telemetry and other types of auxiliary mission data. This is achieved by preprocessing and storing the parameter data extracted from the Mission Control System telemetry packets in a relational database. Many clients have been developed at ESA for the MUST database. Grains, originally developed for the SMART1 mission and later adopted by many other ESA missions, is a MATLAB based graphical client allowing for the plotting of spacecraft data. JavaGrains is another such client, based on more modern and robust technologies, including Eclipse RCP and JFreechart as the plotting engine. Its most important benefit is the support of various data sources and handling of data in a generic way. JavaGrains can be seen in Figure 1. Both Grains and JavaGrains are rich clients, requiring the installation of a desktop application in order to access the telemetry data available in MUST. Recently, a trend has emerged where many applications traditionally requiring a desktop client have become available as highly interactive web applications. Some examples of these applications include webmail and productivity tools, such as text editors and word processors. These applications are often “good enough” for their purposes, and offer several advantages over traditional native applications, such as cross-platform compatibility, and availability Figure 1. JavaGrains showing data for three spacecraft parameters. everywhere, without the need to install a binary executable (besides a web browser). This trend has been made possible due to advances in web technology, arguably started with the introduction of Ajax (Asynchronous JavaScript and XML). More recently, HTML5 was introduced, including support for typical rich client features such as client-side 2D drawing via JavaScript (canvas), video/audio support or multi-threading via the Web Workers API. Due to these advances, more specifically the introduction of the canvas drawing API introduced in HTML5, a new MUST client has been made possible: WebMUST, seen in Figure 2.
2
WebMUST is purely web based, and leverages technologies such as HTML, CSS and JavaScript (with jQuery) to provide graphical representations of several types of spacecraft mission data, including telemetry data. While HTML5 is clearly an enabler for this class of applications, having greatly matured in the last few years, it is not yet finalized as a standard, and browser implementations and performance are not consistent across the board. With the Figure 2. WebMUST showing a multi-plot. A multi-plot in WebMUST is a series development of WebMUST, of plots with a shared time axis. there was therefore the motivation for researching and comparing several techniques to address the efficient plotting of great amounts of telemetry data. This paper focuses on presenting these techniques, with a series of benchmarks, as well as spacecraft operator user feedback on the advantages and disadvantages of each one.
II. Techniques for visualization Several techniques were tried during the development of JavaGrains and WebMUST. This section presents the three most important ones: fixed time interval aggregation, fractal compression and viewport resolution aggregation. A. Fixed time interval aggregation This type of aggregation is very simple: given a fixed set of time ranges (e.g. “Minutes” or “Hours”), divide the whole time span of a telemetry plot in chunks of these sizes. For each chunk, using the original telemetry time series’ values as input, compute the result of an aggregation function such as average, minimum or maximum. Applying this algorithm to a telemetry time series results in a new time series with one sample per chunk, which can be used to plot with a much reduced amount of points. Ideally, if storage space is not an issue, aggregated values can be pre-computed and stored in a database for faster retrieval at runtime. This is the approach followed by many information systems, such as the Space Weather Information System for Operations (SEISOP [3, 4]) which, at the time of insertion, aggregates and stores spacecraft and space weather data on a data warehouse. In practice, storing pre-aggregated data roughly requires double the amount of storage, which is very often not acceptable for an already flying spacecraft mission. For WebMUST, aggregated values are therefore computed on the fly. We have found that, while having pre-computed data would obviously be more time-efficient, computing aggregation on the fly has good enough performance from an end user point of view. It is worth noting that, in the case of WebMUST, the aggregation results are computed using the database’s native aggregation functions. During development, it was found that calculating aggregation in this fashion was much faster than loading the full set of samples into application memory and calculating the aggregation then. The benchmarks below correspond to this implementation. By using multiple aggregated time series (e.g. minimum and maximum), a complete envelope of the time series can be identified in order to show all peaks of the time series as a fast approximation to actual sample values. B. Fractal-inspired re-sampling The fractal re-sampling algorithm [5] is a lossy compression method which produces a set of samples, not necessarily at regular interval, that resembles the original time series behavior guaranteeing a given maximum error when using linear interpolation to connect the samples. The resulting data set samples are in fact real values, and for the ones that aren’t present it is guaranteed that the resulting error is below the given maximum error. The algorithm 3
is inspired by how fractals are used to create terrain in certain video games. It was developed with performance in mind and with the intention of allowing it to be run on-board a spacecraft. The maximum error is configurable on a parameter basis. We have found that setting it to 1% is sensible for most cases (the range [maximum – minimum] is considered 100%). WebMUST uses the fractal inspired compression algorithm with a default error of 1%, allowing the engineer to override it if necessary. C. Viewport resolution aggregation (VRA) The general idea behind VRA is that processing of data in memory is significantly faster than issuing draw calls for each of the samples and interpolation lines between them. This is particularly true for the default renderer as it is used in the library JFreeChart, which is the core of JavaGrains’ plot rendering. Resolutions of viewports, i.e. height and width of plots, are limited by the pixel density of the display device. If more samples are available over time than pixels are displayable on screen, this leads to overdraw which is not visible but has measureable processing impact. VRA approaches the reduction of overdraw by only drawing the actually visible data points and lines, while providing an automated fallback for low-density time series. Two rendering cycles are necessary to draw the connecting interpolation lines between samples and the data point indicators for additional information. Consequently, both cycles need to be considered in overdraw handling and reduction. Each pixel coordinate on the X scale can be mapped to a small time interval. For the connecting lines on the same X pixel coordinate, results are collected during that interval in terms of four values: max last max last max 1) First sample value min first max 2) Minimum value during the interval 1 2 1 3) Maximum value during the interval last 4) Last sample value 2 These values represent an adaptive, dynamic first first aggregation using multiple algorithms for each of the 2 horizontal coordinates, which needs to be adapted for 1 last each change of the currently shown viewport, but min allows a simplification of the “filled pixels” in a pixelbased representation of a highly detailed time series, min where multiple samples fall on the same X coordinate first min or even exact pixel. As shown in Figure 3, samples are usually positioned at sub-pixel precision and it may occur that Figure 3. Coordinate to visible pixel mapping. for the actual rendering a single pixel contains multiple samples. The core idea of VRA is to reduce the overdraw, where it is necessary to draw all lines between each subsequent sample to a simpler representation, i.e. drawing with a “broader stroke” of 1 pixel, which is the minimum visible line width. Using this approach, only two draw calls are necessary to reliably draw a line that represents a pixel-perfect approximation of the visible plot line: 1) line to: last value (previous) → first value 2) line: min → max Both lines are drawn in discrete pixel coordinates between the respective points. The light blue shading in the background represents the filled pixels. This algorithm is executed for the complete list of aggregated pixels across the X axis. For high numbers of samples, the result is a visual envelope of the connecting lines between the respective samples. This is visually equal to drawing each connecting line individually and accumulating the resulting overdraw. The information about specific samples is lost with this approach however. In order to still provide information about the actually existing sample positions and their data point indicators, which are linked to sample inspection tools (e.g. tooltip), usually a data point is rendered by using a shape (e.g. a circle, triangle, square, etc.). Drawing such a shape for each sample requires even more effort than drawing interpolation lines between samples. In order to reduce the amount of shapes to be drawn, only a single shape is drawn for a distinct (X,Y) coordinate, which requires aggregation for each (X, Y) position. For pixels where many samples are located on the same position, only a single such data point shape needs to be drawn, significantly reducing the amount of drawing instructions. Only in the worst case, all of the sample shapes need to be drawn and as soon as multiple samples share the same (X,Y) position, a reduction in necessary drawing is already achieved. 4
In order to determine the respective sample for each (X, Y) coordinate, for each X pixel coordinate, a bin of sample positions is created. This bin is a map for the corresponding Y coordinates, which makes the specific (X,Y) coordinate tuple identifiable. Each sample mapping to a specific X and Y coordinate is gathered in the respective bin. During the 2nd rendering pass, which is responsible for drawing the data point indicators (e.g. circles, squares, crosses, etc.) on actual sample locations, such indicators are only drawn if a Y-coordinate bin exists and contains samples for the respective X coordinate. The data inspection information contains a reference to the bin, which makes all relevant samples on a specific pixel accessible for detailed inspection. This approach is particularly useful with extremely dense or extremely large Tooltip for Pixel (2,0): 3 samples NACW9281 (millions of samples) time series, as it 2012‐05‐11 11:32:53.231 – 3.04210 reduces the number of draw calls for the 2012‐05‐11 11:34:09.127 – 3.07212 line rendering pass to a maximum of 2x 2012‐05‐11 11:35:24.981 – 3.04490 viewport width in pixels. For the data point rendering pass, this number is (0,0) (1,0) (2,0) (3,0) (viewport width x number(used Y coordinate pixels)). Once the number of samples in the data set is larger than 2x (0,1) (1,1) (2,1) viewport width, this approach is remaining close to constant in terms of drawing performance. (0,2) (2,2) At the same time, the approach provides similar or even better visible overview of all samples currently displayed in the plot. Particularly for samples that are overlaid on the same Figure 4. Data point binning approach and result. coordinates, the binning allows an inspection of all samples sharing this coordinate. To date, two implementations of VRA have been done, in JavaGrains and in WebMUST. Some differences exist between the two implementations, more specifically: 1) In JavaGrains, the algorithm is implemented at the rendering engine level, whereas in WebMUST it is done at the data model level. The reason behind this design choice is that, since WebMUST is a web application, it is desirable to reduce as much as possible the amount of data transferred over the network, between the web server and the client’s browser. Additionally, we found that the computation of the statistics required for the algorithm (minimum and maximum) is much more efficient if done at the database level, instead of in application memory. 2) In WebMUST, only two points are computed per pixel chunk: the minimum and the maximum. The result is however similar to the approach described above for JavaGrains, since these points are ordered by date, and a line is drawn between the second point of each chunk and the first of the next one. The implementation in WebMUST does not provide the binning of samples for sample point aggregation and thus doesn’t allow to identify local minima or maxima for the same pixel in the time series. Section III shows benchmarks for both implementations. It is worth noting that since JavaGrains and WebMUST are two completely different applications (the former is a rich client application, while the latter is a web application), no conclusions should be drawn from a direct comparison between the two. It is however worth including both approaches when comparing them with the default case (i.e. no down-sampling algorithm).
III. Benchmarks and results In order to better assess the performance of each of the techniques described above, several tests and comparisons were performed during the development of the JavaGrains and WebMUST applications. Some of these benchmarks can be formalized through metrics, with numerical results that can be directly compared. Others are more subjective, and depend on each user’s perceptions and expectations. These metrics and parameters are described below. Algorithmic time efficiency. This metric corresponds to the time taken to apply the technique in question, i.e., for a given parameter and time range, the time (in seconds) it takes to produce an output based on the parameter’s 5
samples. It does not consider the actual plot rendering time, only the time taken to extract the data from the database, process the parameter data and produce an output. The lower the value of this metric, the better the algorithm performs. In order to measure this parameter more accurately, the algorithms were executed 10 times each. The values presented are the average time for these runs. User time efficiency. This metric attempts to capture not only the complexity of the algorithm, but the actual time, in seconds, a user must wait between issuing a request for a plot and having it completely rendered on screen. It includes all factors, such as the speed of the rendering engine and network time. This metric was taken using the WebMUST tool with the Firefox 12 web browser, except in the case of the VRA algorithm, where it was taken with both WebMUST and JavaGrains. Once again, the lower the value of this metric, the better the algorithm performs. Sample count efficiency. This metric is defined as the ratio between the input and the output sample count. It measures the efficiency of the algorithm when it comes to lowering the amount of samples that must be plotted, therefore increasing rendering performance. The higher the value of this measurement, the better the algorithm is in this regard. Visual fidelity. The visual fidelity parameter states whether a plot rendered after applying one of the benchmarked techniques “looks” the same as a plot using the full, unaltered, set of parameter samples. An important point considered in this metric is any loss of extrema after applying a down-sampling algorithm, which compromises the visual accuracy of the resulting rendering. Sample value fidelity. Sample value fidelity considers any ancillary points that may be introduced as part of applying a down-sampling technique. In general, it is desirable to use the time series’ actual sample values in an algorithm’s output, instead of introducing artificial values. These can lead to user confusion when utilizing tools that allow visual inspection of the exact sample values (which is the case of JavaGrains and WebMUST). Output count predictability. An algorithm is defined as having a predictable output count if we can accurately know, prior to applying it, the resulting amount of samples. This is an important aspect when automatically selecting which algorithm is best for which parameter. If it is necessary to actually apply the algorithm in order to obtain the resulting sample count, the algorithm is not considered predictable. Many different telemetry parameters were tested during the development of the JavaGrains and WebMUST applications. For the purposes of this paper, we have selected four real spacecraft parameters from the Venus Express mission, and have measured the performance of the fixed time interval aggregation, fractal compression and viewport resolution aggregation algorithms, according to the above metrics, when applied to them. These parameters are the following: 1) BATT 1 VOLTS (NPWD1134). This parameter represents the voltage of a battery at any given moment. Since the Venus Express spacecraft doesn't experience that many eclipses, the values tend to be very stable. Whenever there is an eclipse, it tends to be of short duration. 2) RW1_SWR estimat friction (NACW0G05). This parameter represents the estimated friction of one of the reaction wheels from the spacecraft. It is normally very noisy and normally follows the same "trend". This is a parameter with a very high sampling rate, so plotting has always been tricky. 3) TRSP2- X-Bnd TX DC Curr (NTTAX280). This parameter represents a transponder’s X-band transmitter current. As with the battery parameters, it tends to be very stable. 4) ASPERA-DPU Temp (NASA0102). This parameter represents the temperature of the digital processing unit of Aspera. Aspera is a payload in Venus Express, and the DPU’s task is to control the sensors and mechanical scanner. We selected the whole year of 2011 as time range for these parameters’ benchmarks. The total sample count in this period for these parameters before applying any down-sampling method, as well as the time necessary for a user to obtain a plot using the WebMUST and JavaGrains tools, is presented in Table 1:
6
Table 1. Test parameters with total sample counts. Parameter Sample User time efficiency (seconds) name count WebMUST JavaGrains NPWD1134 1882284 106.554 89.514 NACW0G05 7457393 N/A N/A NTTAX280 1869380 86.425 47.164 NASA0102 1869377 70.194 41.765 For the case of NACW0G05, it was not possible to create a plot with both tools due to the large amount of data, highlighting the need for the type of techniques presented in this paper. The benchmark results for these techniques, a short evaluation of each by a spacecraft operator, are presented in the following subsections. A. Fixed time interval aggregation The performance of the aggregation algorithm depends on the aggregation level applied (i.e. the size of each time interval). For this reason, we present results for the average aggregation function and two different aggregation levels: hours and days. Table 2. Benchmark results for fixed time interval aggregation. Parameter Aggregation Algorithmic User time Sample name Level time efficiency count efficiency efficiency NPWD1134 Hours 17.064 29.902 214.873 Days 0.911 5.211 5156.942 NACW0G05 Hours 17.670 51.095 851.301 Days 1.847 28.074 20431.214 NTTAX280 Hours 16.932 51.323 213.400 Days 0.854 4.232 5121.590 NASA0102 Hours 16.632 63.705 213.400 Days 0.957 5.172 5121.581
Sample value fidelity
Output predictability
No. The fixed time interval aggregation does not preserve the original sample values.
Yes. For a given time range, the amount of resulting samples is always the same.
As expected, performance depends on the aggregation level, due to the variable number of chunks. If the aggregation level was set to minutes, performance would be even worse. When using the Hours aggregation level, the sample count efficiency is very good. However, as seen in the figure below, visual fidelity suffers greatly. In both cases, many extrema are lost in the aggregated plot. User assessment: As an extra functionality to plotting of data, filtering can be done by using aggregation, which is useful for analysis of data. The ability to plot only maximums or minimums using aggregation is welcome, but at the same time important or relevant data can be lost if the aggregation settings are wrongly chosen by the user. For instance, if a user decides to use the average aggregation function with “hours” aggregation, this will cause the maximum values in that hour to be filtered out and not shown in the plot, potentially causing confusion. Another example is choosing an inadequate aggregation period. If a user chooses to aggregate the data per day, only one value will be presented, possibly hiding important data samples.
7
Figure 5. Aggregation applied to parameter NASA0102. The top chart shows the plot with the full amount of samples for comparison. While visual fidelity is at first glance good with “Hours” aggregation, the values for extrema do not correspond to reality. With aggregation level “Days”, the plot is completely different (even though the general trend for the parameter is still observable). B. Fractal inspired resampling For the fractal resampling benchmarks, we selected two different compression levels: 1 and 10%. An error of 1% is the default setting in WebMUST, which can be overridden by the user. Table 3. Benchmark results for fractal resampling. Parameter Compression Algorithmic User time name Error time efficiency efficiency NPWD1134 1% 17.631 29.024 10% 16.750 31.352 NACW0G05 1% 82.020 170.809 10% 90.655 179.812 NTTAX280 1% 17.342 28.049 10% 14.935 24.262 NASA0102 1% 23.423 25.715 10% 24.491 22.321
Sample count efficiency 265.672 583.654 27.015 826.0295 221.648 1063.356 135.227 963.100
Sample value fidelity
Output predictability
Yes. The fractal compression algorithm guarantees that the output values were part of the original input series.
No. The compression ratios vary depending on time series behavior and are not strictly dependent on the amount of input samples.
Fractal resampling sample count efficiency is decent when the error is set to 1% and good with error 10%. The sample count efficiency is very low in the case of NACW0G05, a noisy parameter. With a higher error, the algorithm discards most of the noise, making efficiency better. It is worth nothing that the large times in the time efficiency column are not due to the algorithm itself, but in no small part to the actual loading of the parameter data from the database (for NACW0G05 for example, each query takes in the order of 60 seconds, while running the fractal compression itself takes 2 to 3 seconds). While other approaches are able to take advantage of the database’s built-in aggregation calculations, this is not possible with the fractal re-sampling, which must load the full set of samples to memory in order to produce results. We have nevertheless decided to include the database loading times in the benchmark in order to reproduce as much as possible a real word situation. 8
User assessment: The fractal inspired resampling technique can best be described as a “lossy compression tool”, since it is based on discarding information (samples in this case) that is deemed not needed. The user can define what is to be considered important data by choosing a maximum allowed error. As such, the resulting set of samples will have an error, but this error will be below what the user chose. This allows for very good compression results in data sets. Figure 6. Compression applied to parameter NASA0102. The top chart shows There are however the plot with the full amount of samples for comparison. Visual fidelity is good certain data sets where the with compression error 1%. With a 10% error, some issues are present because compression isn’t as evident. the values for some samples were within the specified acceptable error and were Data sets that have periods therefore discarded by the algorithm. where the values fluctuate above the selected maximum error, won’t compress as well as others. Additionally, it is impossible to predict the resulting number of samples of this technique. With experience, an engineer can guess how the solution will “compress”, but knowing ahead of time the resulting number of samples is impossible. The user can select an error that allows the system to only plot a certain range of values. This is useful for analysis, since this will eliminate the samples that aren’t of interest and keep the ones that are needed, with their real values. C. Viewport Resolution Aggregation Two different implementations of VRA were benchmarked as part of this work: WebMUST and JavaGrains. 1) WebMUST For the VRA benchmarking results in Table 4, we used the WebMUST implementation (see section II for details). Two viewport widths were selected: 800 and 2048 pixels. The first case is close to the width of a WebMUST chart when viewed in a 1024x768 resolution screen. The second width is currently less applicable to reality, but may become an important use case in the near future with the ubiquity of high-dpi displays. Table 4. Benchmark results for WebMUST VRA. Parameter Viewport Algorithmic User time name width time efficiency efficiency NPWD1134 800 2.394 10.104 2048 4.674 9.48 NACW0G05 800 3.439 28.631 2048 5.406 40.224 NTTAX280 800 2.004 10.687 2048 4.278 16.167 NASA0102 800 1.718 3.56 2048 4.153 16.606
Sample count efficiency 1176.428 459.318 4660.871 1819.764 1168.363 456.169 1168.361 456.168
9
Sample value fidelity Yes. Output sample values are part of the original time series.
Output predictability Yes. The total amount of output samples is a fixed value depending on viewport resolution.
As with the fixed time interval aggregation, time efficiency for VRA, although in the same order of magnitude, depends on the number of chunks – in this case the number of horizontal pixels in the viewport. In terms of sample count efficiency, the greater the resolution the lower the efficiency is, since the number of output points will be greater. The difference is however not as large as with the fixed time interval aggregation. It is also worth noting that, the “harder” the input time series (as with NACW0G05) is, the better VRA’s performance in terms of sample count efficiency is: while the input count can vary a lot, output count will always be the same. Figure 7. VRA applied to parameter NASA0102. The top chart shows the plot with the full amount of samples for comparison. The bottom chart correspond to VRA with a viewport width of 912 pixels. There is no visual difference between the two, but individual samples cannot be seen. 2) JavaGrains The table below shows a different set of benchmarks for the implementation of VRA in JavaGrains. In this tool, VRA is implemented at the rendering engine level, and therefore on the client’s machine, instead of on the server side as with JavaGrains. Sample value fidelity and output predictability are not included since they are the same as for WebMUST above. The sample count efficiency metric does not apply here since, in this case, the rendering algorithm works in terms of lines and not “samples”. For each horizontal pixel, two lines are drawn – resulting in 1600 lines in our 800 pixel benchmark. Since the amount of work to draw these lines remains constant, the actual rendering of connecting lines remains at constant time. For 800 pixels width, the task was completed below 1ms reliably over the course of tests. For these results, we considered two separate modes of the VRA algorithm: one with binning of sample values and one without. Binning sample values requires more time and consumes more memory. It is however still significantly faster than rendering all of the sample points and gathering information about each of them. Table 5. Benchmarks for JavaGrains VRA. Parameter Viewport Algorithmic time User time efficiency name width efficiency Binning No binning Binning No binning NPWD1134 800 0.967 0.624 19.469 25.146 NACW0G05 800 5.522 2.325 118.807 116.769 NTTAX280 800 1.825 0.546 45.256 35.708 NASA0102 800 0.873 0.530 36.536 37.955 The algorithm is very fast on the rendering level, which is particularly important for the user’s analysis of the data once it is in memory. It makes zooming and panning on the requested data set fluent for tens of thousands of samples, working for hundreds of thousands of samples and bearable for millions of samples. A classic renderer 10
becomes a significant hindrance to the user’s workflow with a hundred thousand samples and beyond. The most important bottleneck from request to rendering is the database performance and retrieval time of samples. In this case, performance of the user’s machine is very significant because all the samples are kept in memory and the alignment to the number of viewport pixels is done for each update and rendering cycle of the graph. In contrast to the WebMUST implementation, all data is loaded upfront, which requires an initial delay but no further communication with the server after that. This is particularly important for the scalability of the server, as the processing takes place on the client, leaving more processing time for the server to handle more user requests. The use of binning for full representation of all sample point indicators reduces the amount of items to be drawn and thus rendering time significantly, compared to the classic approach.
Figure 8. VRA with binning applied to parameter NPWD1134. The chart on the left shows the plot with the full amount of samples for comparison. The chart on the right corresponds to VRA with binning. There is no visual difference between the two, even with samples visible, but rendering time is significantly shorter with VRA. User assessment: VRA allows for fast, accurate and effortless visual representation of telemetry data sets. It shines when it is necessary to plot large data sets. With VRA, it is currently possible to plot over 6 years of Venus express data in a web browser, without a big performance impact. Not only does it allow the data to be plotted, it also keeps the plotted data visually accurate. It takes the user’s screen resolution into account, producing the best representation of the data possible. However VRA can only be used visually. If the user intends to use the solution for something other than visualizing the overall “shape” of the data, VRA has some shortcomings. As per the latest implementation of this solution in WebMUST, samples are “lost”. Of course one could argue that having the ability to plot millions of samples overshadows this problem, but it has happened that users complain that they cannot find a specific sample (usually a local extreme that falls on the same pixel as an absolute extreme when using this solution). Hopefully this will be addressed in future implementations of VRA in WebMUST. A drawback of the nature of this solution is that whenever a user zooms or pans on a plot using VRA, it is necessary to “rerun” VRA on the new time range, in order to accurately resample the displayed data. While the time this takes is usually very short, this introduces some delays when browsing data. The plot resulting from using VRA’s current implementation is a representation of the real data and does not contain the full set of samples, so the user has to have this in mind when using it. For plotting of large telemetry datasets, and for situations when what is important is the visual aspect of the plotted data (trend analysis, printing, reports, etc.), this solution is a good bet. Most of these issues are not applicable to the VRA implementation in JavaGrains, as the processing is done in the client application itself and all of the data to be displayed is stored in the client’s memory. With the fast execution times of the sample preparation and significantly accelerated rendering, VRA increases the responsiveness and rendering capabilities of JavaGrains. This makes the exploration of data much more fluid and thus more efficient for the users.
IV. Conclusions The use of web technologies for visualization of large amounts of telemetry data is a challenge, due to resource constraints and constantly evolving standards and browsers. A high amount of samples requires a high amount of memory on clients, and compromises the user experience, by introducing delays when first rendering a plot, and when changing the viewport via panning or zooming. The solutions described in this paper address the problem from different perspectives. Aggregation and the Fractal Inspired Compression strive to reduce the overall transmitted data to the client, using the usual one-request approach, which provides all necessary data to the client immediately. 11
The Viewport Resolution Aggregation (VRA) is instead aiming at improving the rendering performance while retaining as much visual fidelity and sample accuracy as possible. For a desktop application, which is easily capable of fetching and retaining large amounts of data, this approach can be easily integrated into the graphics rendering subsystem. With its significantly faster overall rendering based on the same set of data, it improves performance and the client’s capabilities, compared to the normal renderer. Changes in the viewport and thus necessary re-rendering of the plot can be completed quicker, resulting in a more fluent workflow for the users. A web client has different requirements in terms of data amounts to be transferred and kept in memory. All of the compression and data reduction approaches are thus executed on the server. The client only receives the effective outputs of the respective algorithms, as the usual web clients would not be able to cope with the required amounts of data reliably. Each of the users’ interactions requires a request to the server and an appropriate response, which inevitably introduces a delay in responsiveness. Depending on the implementation and amount of data to be shown, it may be necessary to re-load data from the database, which may take a significant amount of time depending on the time period in question, as shown in the benchmarks. The stress on the web client is significantly lower using this solution, as only a minimum of data needs to be transferred. The concept of fractal inspired compression is significantly different from VRA, as it does not try to retain complete visual accuracy, but instead express the overall characteristics of the time series to be shown within an allowable error using a minimum of samples. This approach is highly effective for non-noisy parameters, where many samples can be omitted, as they are close to linear interpolation between adjacent samples. Noisy time-series will however still require a high level of samples in order to express their nature faithfully. Considering the amounts of entropy for both cases, this is the classic observation for any kind of compression. This paper is not concerned with the application of classic compression, e.g. gzip compression, which can be integrated in the transport protocol between client and server, as usually all necessary specifics are handled transparently by the underlying transport implementations used on both ends of the communication. The general conclusion is that it is important to be able to reduce the amount of data to be transferred and the effort required of the plot renderers to achieve a more fluent use, higher responsiveness and better workflow for the users analyzing time series data. The approaches can be categorized in two domains, namely data reduction and efficient data representation. Ideally data reduction should happen on the server side before being sent to a client, but should retain all of the critical information, on which users rely during their analysis. Approaches for efficient data representation should ideally be moved to the client application side, which handles the visual representation of data. A combination of both approaches, considering their respective trade-offs ensures the appropriate use of bandwidth, memory and processing resources between client and server, considering the applicable resource constraints and fidelity implications. With the current evolution in terms of performance and capability of modern web browsers, a next version of the WebMUST client side could carry more responsibility for an efficient rendering of the time series, with less server interaction and by keeping more of the data in memory. An ideal combination of all approaches needs to be determined in order to find the right balance between bandwidth use for mobile devices, visual fidelity and resource consumption in a web browser environment. The evaluated and presented approaches provide a solid foundation for identifying this balance, and work will continue in this direction.
References 1
Martinez-Heras, J., Baumgartner, A., Donati, A., “MUST: Mission Utility and Support Tools”, DASIA 2005 2 Baumgartner, A., Martinez-Heras, J., Donati, A., Quintana, M., “MUST – A platform for Introducing Innovative Technologies in Operations”, ISAIRAS 2005 3 Donati, A.; Pantoquilho, M.; di Marco, F.; Oliveira, H.; “Space Weather Services for Space Mission Operations”; Proceedings SpaceOps 2010 Conference, Huntsville, USA, June 25-30 2010 4 Parrilla, E.; Enriquez, M. J.; Negrin, S.; Donati, A.; Oliveira, H.; “SEISOP: A System Enabling Space Weather Services for Space Missions”, Proceedings SpaceOps 2010 Conference, Huntsville, USA, June 25-30 2010 5 Martínez-Heras, J.; Francisco, T.; Donati, A.; "More Observability for Less Bandwidth …Where’s the Trick?"; Proceedings SpaceOps 2012 Conference, Stockholm, Sweden, June 11-15 2012 (to be published)
12
