Examples

PET examples

We describe here the experiments we have set up to validate the functionality and important aspects of the PERICLES Extraction Tool.

In all the PET experiments, some common background steps are assumed:

1. The PET tool is installed, configured and started on the machine where the digital objects are used.

2. The user interacts with the system while PET collects environment information in the background.

3. The environment information, digital object events and changes are stored for future use and analysis.

Example 1: PET used for space science operations to extract anomaly dependency information

As described on the scenario page, operators dealing with anomalies usually find their solution searching through a multitude of documents. This can include, for example, solutions from previous anomalies, telemetry, console logs, meeting notes, emails, etc. Such data, although present in the storage, requires experience and its selection is a task that requires specific knowledge that is usually passed from operator to operator. For this reason we are addressing the collection of such dependencies between anomalies and mission documentation, in order to preserve useful information that is otherwise not captured.

In more detail, when an anomaly occurs, the issue is recorded on the 'handover sheet'. Different procedures are executed to solve the issue, and very frequently the operators need to access the relevant documentation. We have set up a simplified experiment to demonstrate what types of significant environment information can be collected in this scenario.

In order to support this scenario, we set up a PET profile that tracks the use of relevant software on specific files, using the PET software monitor; this enables us to have a trace of the documents that have been used at a given moment in time, as illustrated timeline. The image shows a trace of document use (based on open and close times) collected from process monitoring (blue) with anomaly solving time (red) collected using file change monitoring.

At the same time, it is possible to observe the ‘handover sheet’ and track the reporting of an anomaly start and end times. The screenshot shows changes in the 'handover sheet' tracked by the PET tool.

The connection between the documentation track and the ‘handover sheet’ tracking can allow us to infer the ‘anomaly solving time span’ (indicated in red in the timeline) and assume there is a dependency between the solution to the anomaly and the documentation that was used between the start and end of the anomaly.

Example 2: PET on extracting results of scientific calculations

The following experiment illustrates how SEI extraction can be useful for examining scientific calculations. This experiment uses an extraction module that extracts whole lines from files. It is configured to monitor an output directory of the open source tool GNU Octave and to extract calculation results with the aid of a regular expression. The extraction module is originally intended for the extraction of particular log messages from a log directory. The scientist uses PET to track the resulting development of an Octave-script execution over time and in relation to the script lines that are relevant for the result. This enables the possibility to understand the resulting changes in relation to script formula changes. First, the user configures the module by specifying the output directory and the regular expression to search the result line, which is, similar to the name of the result variable, just “B” at this example. Then the sheer curation mode of PET is started, to monitor the directory, which triggers an initial extraction. At the time of this first extraction the script wasn’t executed. We used the following simple Octave script for this experiment:

Then the scientist starts his normal octave workflow and executes the script. The PET detects the file changes in the configured output directory and triggers a new extraction of the selected module. The following screenshot displays the results of the first and second extraction:

The result of the first extraction shows the locations of the script’s result variable B in the not yet executed script, which also lies in the observed output directory. At the result of the second extraction the line of the output file with the result variable B and its line number can be seen. This is the extracted result of the scientific calculation.
Since also the location of the result variable at the original script was extracted, an easier understanding of the dependencies between results and locations at the script is enabled. A continuous extraction over long periods of time makes an observation of result changes in relation to changes of the script formulas possible. PET indeed needs highly customised configurations for the example, but these enable it to adapt to specialised scenarios.

Example 3: Software Based Artwork system information and dependencies

This experiment is about collecting dependencies for a Software Based Artwork, as described on the scenario page. The PET tool is executed on the files of the Software Based Artwork and will extract a series of information useful for the understanding and future use of the artwork. For the Software Based Art scenario, PET is especially useful in capturing a snapshot of the system specification and graphical configurations. Furthermore, the system resource usage can be monitored and extracted in the sheer curation mode to be used for a comparison of behavior patterns between different artwork installations. However, PET has its limits for this scenario, as it won't provide analyzing mechanisms for such patterns. Also, information that lies outside of the computer system environment of the artwork is not reachable for the PET, such as the actual artwork installation details that are manually captured (for example model of display, how it is installed, ...).

System information snapshot

Various information pertinent to the scenario of emulating an environment of a Software Based Artwork can be extracted by the PET with a snapshot extraction. This mainly includes information that doesn't change continuously, such as the system’s hardware specification or installed graphic drivers.

It follows an extract of the result of a snapshot extraction executed by the PET. The significant information includes system hardware specifications, CPU, system graphic settings (e.g. installed fonts and display information), and information about the operating system and the development toolkit used to program the artworks software.

Extraction Module: CPU specification snapshot

model: _Intel Core(TM)i5-3470CPU@ 3.20GHz _

totalCores: 4

Extraction Module: Graphic System properties snapshot

font_family_names: “Bitstream”, “Charter", "Cantarell", ...

displayInformation: isDefaultDisplay=true, refreshRate=60 ..

Extraction Module: Operating System properties

user_language: En

os_name: Linux

Extraction Module: Java installation information

java_home: /opt/java/jre

java_vendor: Oracle Corporation

java_version: 1.7.0_15

In addition to this, information that changes constantly has to be captured continuously in PET’s sheer curation mode. For the Software Based Artworks scenario this is mainly the use of system resources. A measurement of resource usage values over a long period of time can be analysed to identify behaviour patterns, which can be used to validate the correct behaviour of a new software installation. Other examples of measurements are those of CPU usages, executed by PET's “CPU usage monitoring”-module, whereby the changes over time can be traced.

Another example of such runtime information that can be collected and be useful for assessing the dependencies of a SBA is the file-system and network usage information (all the files and network connections used during the execution of the Software Based Artwork) that can be collected by the PET tool with a specific extraction profile.

The extraction results enable the configuration and emulation of a new environment for a Software Based Artwork, as described on the scenario page.

Example 4: Extraction of font dependencies

The PDF format gives the ability to embed the font types used in a document, to guarantee faithful reproduction of the document even when the digital object is moved to an environment that does not include them. However, it is still possible to create PDF documents without including the necessary fonts (for example, it can be a user choice or a the font can be blacklisted in the PDF creating application). To recognize such external font dependencies, that are particularly relevant in the case of a PDF file used in a Software Based Artwork, the module will analyse PDF files and extract a list of used but not embedded fonts. This list determines dependencies between the digital object and the listed fonts, relevant for accurate rendering