In this section you will understand how to develop scripts to automate log analysis. Understanding how the Log Processor executes scripts is essential when developing custom analyses.

The Log Processor can process one or more TeamCAMS CSV log files in a single execution. Internally, the processor iterates over the selected files and executes the JavaScript script separately for each file.

For every input file, the following sequence occurs:

• A new JavaScript engine is created.
• The selected script is loaded and evaluated.
• The global object 'proc' is registered.
• The 'init()' function is called once.
• The CSV file is read line by line.
• The 'parse()' function is called for every row in the CSV file.
• After the last row has been processed, the 'cleanup()' function is called.
• The processor moves on to the next file and repeats the entire process.

In other words, global variables defined in a script are reset for every input file, since a new JavaScript engine is created for each processed log.

The execution flow can be represented as:

for each input CSV file
    create JavaScript engine
    load script

    init(filename)

    for each row in CSV file
        parse(...)
    end

    cleanup()

end

This design allows scripts to maintain internal state while processing a single session but guarantees that data from one session cannot accidentally affect another.

Each TeamCAMS session log is stored as a CSV file. Every row represents a single event generated during the simulation.

Internally, the Log Processor reads each CSV row and extracts the relevant fields before calling the JavaScript parser.

The following information is made available to the script:

parse(timestamp, tag, sender, text, status)

These values are extracted from the CSV row and converted into JavaScript objects.

Every script may define three functions:

function init(name) {
}
 
function parse(timestamp, tag, sender, text, status) {
}
 
function cleanup() {
}

Called exactly once before the first row of a CSV file is processed.

Parameter:

name

The filename currently being processed.

Example:

function init(name) {
    proc.initOutputFile("results_" + name)
}

Typical uses:

• Opening output files.
• Initializing counters.
• Creating data structures.
• Writing CSV headers.

Called once for every row contained in the TeamCAMS CSV file.

This is where almost all data-processing logic is implemented.

Example:

function parse(timestamp, tag, sender, text, status) {
 
    if(tag === "message:sent") {
        proc.writeLine(
            timestamp + ";" +
            sender + ";" +
            text
        );
    }
 
}

Called after the last row of the current CSV file has been processed.

Typical uses:

• Writing summary information.
• Flushing buffered data.
• Completing unfinished calculations.
• Closing output files.

Example:

function cleanup() {
    proc.closeOutputFile()
}

Type:

Number

Simulation time, expressed in seconds from the beginning of the session.

Example:

154.732

represents an event that occurred 154.732 seconds after session start.

Type:

String

The identifier of the event.

Examples:

secondary:n2.notify
secondary:n2.response
secondary:transmission.notify
secondary:transmission.response
secondary:transmission.invalid

Most scripts use the tag to determine which events need to be processed.

Example:

if(tag === "secondary:transmission.response") {
    // Process response
}

Type:

String

Identifies the source that generated the event.

Examples:

operator1
operator2
manager
AFIRA

Type:

String

Additional event data.

Many TeamCAMS events store structured information in JSON format.

Example:

{
    "responseTime": 812,
    "logged": 40,
    "real": 41
}

To access the values:

var data = JSON.parse(text);
 
var rt = data["responseTime"];

Both the N₂ logging script and the Transmission Check script use this technique.

Type:

Object

Contains a snapshot of the simulation state at the time the event occurred.

The Log Processor automatically builds this object from the CSV columns before invoking the script.

The status object contains:

status["ticks"]
status["o2"]
status["pressure"]
status["temperature"]
status["co2"]
status["humidity"]
status["o2tank"]
status["n2tank"]
status["fault"]
status["index"]

Description of each field:

Example:

if(status["fault"] !== "") {
    proc.writeLine(
        timestamp + ";" +
        status["fault"]
    );
}

The Log Processor exposes a special object called 'proc' to every script.

This object provides the interface between the JavaScript code and the Log Processor application.

Creates a new output file.

Example:

proc.initOutputFile("transmission_results")

If another output file is already open, it is automatically closed first.

Typically called from:

init()

Writes a line to the currently opened output file.

Example:

proc.writeLine(
    timestamp + ";" +
    sender + ";" +
    responseTime
)

Each call appends a newline automatically.

Closes the currently opened output file.

Example:

proc.closeOutputFile()

Normally called from:

cleanup()

Because the script is loaded once per input file, all global variables remain available throughout the processing of that file.

Example:

var responseCounter = 0;
 
function parse(timestamp, tag, sender, text, status) {
 
    if(tag === "secondary:transmission.response")
        responseCounter++;
 
}

The value of 'responseCounter' is preserved across all calls to 'parse()' for the current CSV file.

However, when the next file is processed:

• A new JavaScript engine is created.
• The script is reloaded.
• Global variables are reinitialized.

This means that variables never persist between separate session logs.

Most TeamCAMS processing scripts follow the same pattern:

• Open an output file in 'init()'.
• Detect important events using the 'tag' field.
• Store temporary information in global variables.
• Collect data across multiple events.
• Generate one or more output rows using 'proc.writeLine()'.
• Write summaries in 'cleanup()'.
• Close the file.

The provided Transmission Check and N₂ Logging examples are representative of this approach: they detect the start of a trial, track participant responses across multiple events, and generate a single summary record for each completed task.