QA Status and Schedule Status

QAWeb Enterprise represents the current state of workstations and displays in terms of Quality assurance using two closely related statuses:

• The QA Status: Indicates the most recent result of a QA test. This status indicates whether the task passed or failed the criteria - the last time it ran. It also indicates if the task has never run to completion.

• The Schedule Status: Indicates whether the QA tests are running according the expected schedule (determined by the configured frequency for the QA test in the policy)

Both QA status and Schedule status are tracked for each display, and are aggregated at the workstation level. This is described below:

QA Status of individual tasks

The QA Status indicates whether the QA test has passed the criteria defined in the QA policy. It refers to the most recently completed execution of a QA test. Note that when a task was aborted (due to user interaction or technical issues), it is not considered as having run to completion. The QA status can have one of three values:

• Compliant: The most recent QA test execution has produced a ‘pass’ result because the measured values meet the criteria defined in the policy.

• Not compliant: The most recent QA test execution has produced a ‘failed’ result because the measured values do not meet the criteria defined in the policy.

• Pending: There is no result available yet for this QA test. This is the initial status. Most commonly this occurs when installing the agent on a new workstation, when attaching new displays or when applying a modified policy with new QA tests or QA tests with different criteria.

Schedule Status of individual tasks

The Schedule Status indicates whether the QA test has been executed according to the configured schedule in the policy. For this indicator, there is no distinction of whether a positive or negative result was returned; it only gives information about when the last task execution was. Note that a task is only considered as being executed when it succesfully completed (aborted tasks due to a user’s actions or technical difficulties can prevent the execution of a task). The Schedule Status can have one of three values:

• On time: The task has been executed at least once within the current schedule interval. For example, if a display with a policy that requires a Luminance Response Test with a monthly schedule has executed that test in the current month, then the Schedule Status is considered On Time.

• Due: The task has not yet been executed in the current schedule interval, but there was a task execution in the previous schedule interval. This example also applies to a monthly task: if a task with a monthly frequency has not yet executed in the current month, but there was an execution in the month before, then the Schedule status is Due. The status will switch back to On time whenever a task execution completes. However, if an entire interval expires without any execution, the status will transition to Outdated.

• Outdated: The task was not executed in the previous interval and has not yet been executed in the current schedule interval. In our example of a task with monthly schedule, the Schedule Status will become outdated from the moment that an entire calendar month has passed without any execution of that task. The status will remain Outdated until a task execution completes, at which point it will become On Time again.

An agent with Due or Outdated tasks will try to automatically execute these tasks if the conditions are met - which is described further in this chapter.

How the task schedule determines the execution time of tasks

In the QA policy, each task is configured with a schedule that determines the frequency at which the tasks are run by the QAWeb agent. The QAWeb agent will determine that a task is due for execution when it has not yet been executed in the current schedule interval (including when it has never run before). At this point, the Schedule Status of a task becomes ‘Due’. If the entire interval passes without execution, the Schedule Status becomes ‘Outdated’.

The following table summarizes how the interval is determined by the schedule.

Schedule	Intervals start (at 00:00)	Intervals end (at 23:59)
Daily	Every day	At the end of each day
Weekly	Every Monday	At end of Sunday
Biweekly	Every 1st and 15th of the month	At end of last day of the month and the end of the 14th of the month
Monthly	Every first day of the month	At end of last day of the month
Quarterly	Every first day of each quarter	At end of last day of the quarter
Half yearly	Every first day of each semester	At end of last day of the semester
Yearly	Every 1st of January	At end of the year
Custom	At start of period set by schedule	At start of the next period set by schedule - 1 minute

Whenever the agent detects that a task needs to be executed (when the status is Due or Outdated, it will try to have the QA tests executed. When the task can execute depends primarily on whether the task can be performed without user intervention.

• Automatic tasks: When the task can be completed with the internal sensor of the Barco display without any user interaction, it will try to execute it as soon as possible. This requires the workstation to be powered on, QAWeb agent to be started, and for the displays to be active and correctly connected.

• Manual tasks: When the task requires manual interaction (e.g. an external sensor is required - or a visual test questionnaire needs to be entered), the task cannot be executed automatically and it is expected that a user starts execution using the agent user interface on the workstation. The QAWeb agent will generate user notifications in the Windows system notification area, as a reminder that the task should be launched.

Note that the scheduling system is such - that the time of execution of QA tests of multiple workstations will eventually synchronize to the start of each time interval. This is independent of when the workstation or the display was installed.

This means that for a given schedule, twice the schedule interval will pass before the task becomes outdated. As an extreme example, a QA test scheduled yearly that was executed on the first of January in year one, will still be in a ‘Due’ status on December 31st of year two. Despite almost two year passing, it will not be marked as ‘Outdated’. However, QAWeb will have indicated the task was due for the entire period.

Note on custom schedules

The application supports setting a custom schedule for a task. This allows a lot of possibilities like ‘run every Wednesday at 8:00’ or ‘become due in March and October’. The schedule marks the calendar with moments where the next moment makes the task due. The moment after that will make it outdated.

Configure power management of automatable tasks

Automatic tasks can run without interaction of the workstation users. It can be configured how such tasks deal with displays which are in power saving mode / DPMS. This does not apply to Manual tasks which can only be triggered by a user in front of the workstation. To configure this, navigate to the _Preferences_ page of the _QA_ section.

By default, tasks require active displays to run. Typically displays are put to standby after a period of workstation inactivity. This behavior is directed by the workstation’s power saving settings. QAWeb requires an active display in order to perform its tasks. This means that QAWeb cannot run display tasks at that moment and waits until a person is in front of the workstation again.

Alternatively, QAWeb can be configured to wake the displays when tasks become due. During the run of the task, the displays are keps awake. This happens at the start of the schedule interval mentioned in the paragraph above. This is typically at midnight. This function requires the workstation to remain switched on.

Note that tasks which rely on physical aspects of the display typically wait for 10 minutes after display cold boot. During this period the internal temperature of the equipment and light output reaches a point to perform the optimal measuring results.

Workstation-level QA Status and Schedule Status

For each workstation, the QA status and Schedule status of all applicable QA tests are aggregated at the workstation level. To determine which QA tests are applicable, the policy engine looks at a combination of the use of the connected displays and the assignment of QA policies to the organizational structure.

The QA status on workstation level is aggregated as follows:

• Not compliant: At least one applicable QA test has a Not compliant QA status.

• Pending: At least one applicable QA test has a Pending QA status AND there is not a single Not compliant task

• Compliant: All applicable QA tests have a compliant QA status.

Note that Not compliant is ‘stronger’ than the Pending status.

The Schedule status on workstation level is aggregated as follows:

• Outdated: At least one applicable QA test has an Outdated schedule status.

• Due: At least one applicable QA test has an Due schedule status AND there is not a single Outdated task

• On time: All applicable QA tests have an On time schedule status.

Some tasks are only applicable to displays that have a specific technical feature or property. When the display does not meet these prerequisites, the task will be marked as Not Applicable. These Not Applicable tasks are ignored for calculating and aggregating the QA Status and Schedule status. For example, the SteadyColor Response Test becomes Not Applicable on displays that do not support the SteadyColor technology.

Summary: How to interpret QA Status and Schedule Status

The primary intention of splitting the status of QA tests into the ‘QA Status’ (last result) and the ‘Schedule Status’ is to provide the following workflow for users responsible for tracking QA:

1. To achieve a situation where all QA tests are Compliant and On Time

2. If able, tasks with Pending QA status should execute automatically. If there are tasks that require manual intervention, then these tasks must be executed in order to achieve a Compliant or Not compliant status.

3. Whenever a Not compliant result appears, immediate inspection is recommended. If the task is executed again and the result remains Not compliant, take appropriate action (e.g. replace the display, or use the display for purposes with less stringent requirements for example by changing the use or moving the display to a room with a less strict policy)

4. Whenever an Outdated schedule status appears, it should be investigated as soon as possible. If automated tasks are out-of-date, it is possible that technical issues (such as the workstation has not yet come online or the displays are turned off or have become disconnected) are responsible. If it concerns task requiring manual execution, ensure they get executed on time. Ultimately, the severity of Outdated statuses should be judged by the QA responsibles within the context of the effective QA regulations or guidelines.

5. When tasks are Due, the QA responsibles should follow up and ensure that these tasks are completed in a timely manner. Due tasks can be considered less urgent in comparison to Outdated tasks.