return-to-ritherdon
/
rtr-docs
Archived
1
0
Fork 0
Code Releases Activity
Browse Source

update photosensitive epilepsy assessment.

master
Craig Oates 3 years ago
parent
deb5549dc7
commit
e3e7461270
1 changed files with 264 additions and 112 deletions
Whitespace
Show all changes Ignore whitespace when comparing lines Ignore changes in amount of whitespace Ignore changes in whitespace at EOL
Split View
Diff Options
Show Stats Download Patch File Download Diff File
  1. 376
      health-and-safety/photosensitive_epilepsy.md

376
health-and-safety/photosensitive_epilepsy.md
Unescape View File

@ -1,17 +1,59 @@
# Return to Ritherdon: Photosensitive Epilepsy
This document is part of the health and safety risk assessment for the
'unnamed' artwork in the Return to Ritherdon exhibition.
artworks *Personal Flash in Real Time (Ross)* and *Personal Flash in
Real Time (Tony)* which are part of the Return to Ritherdon
exhibition. If you would like to know more about how the artwork and
the exhibition, head to [Return to Ritherdon
Doc's](https://git.abbether.net/return-to-ritherdon/rtr-docs).
This assessment was produced by [Craig
Oates](https://git.abbether.net/craig.oates).
## Summary of Assessment
The rate of flashes the lighting system produces is not of a higher
enough rate to cause a photosensitive epileptic seizure -- according
to the referenced sources below. Based on the **live test** data, the
system produce a flash rate of **1 Hertz** through out the course of
one day between **06:57 and 16:00** (9 hours), on the
**23/04/2021**. This falls outside the **3-30 Hertz** claimed by
Epilepsy Society (link below).
The amount of flashes the artworks ('*Personal Flash in Real Time
(Ross)*' and '*Personal Flash in Real Time (Tony)*') produce are not
of a high enough rate to cause a photosensitive epileptic seizure --
according to the referenced sources below ('between 3-30 hertz').
The two main reasons why the artworks don't produce a high enough
flicker/flash rate are as follows:
1. The devices controlling the lights in the gallery cannot receive
enough new readings-per-second to reach the Hertz required to cause
a seizure (according the reference sources below); And,
2. The welders in the factory do not alter the light levels (in their
welding booths) at a high enough rate to trigger a seizure.
The majority of this assessment will focus on the second point. The
reason why is because I can refer you to the link below to address the
first point:
-
[Relay](https://git.abbether.net/return-to-ritherdon/relay/src/branch/unstable/relay.py#L51)(the
software controlling the lights in the gallery)
The highlighted line (on the linked page) indicates the gallery lights
must wait 0.3 seconds until it receives the latest light reading
(I.E. process three readings-per-second). This means **the lights (in
the gallery) can change states (I.E. off to on) at a rate of two
hertz, at most**.
To expand on the second point, I have analysed and reviewed a
days-worth of **live test** data, collected on the
**23/04/2021**. *Personal Flash in Real Time (Ross)* (the light meter
part of the artwork) took the light readings from **06:57 to 16:00**
(approx. 9 hours). Also, the test was conducted in the intended
environment and under real-world conditions.
The overall assessment of the data is the light meter took readings at
a rate of four readings-per-second for approximately two
(non-consecutive) hours. Within that time, the light meter *produced
readings* which could trigger a flash rate of two hertz, at most, if
the gallery light wasn't already limited to three
readings-per-second. And, it reached this 'peak' for a total of three
non-consecutive seconds throughout the nine hours.
## Information About Photosensitive Epilepsy
@ -32,13 +74,15 @@ More information can be found at:
- [National Health Service](https://www.nhs.uk/conditions/epilepsy/)
(NHS)
## How This Relates to the Return to Ritherdon Project
## How Risk Assessment Relates to the Return to Ritherdon Project
The project (unnamed at time of writing) this document refers to is
one artwork in a much bigger project (called Return to
Ritherdon). Within **'unnamed project'**, is flashing lights. Because
of that, the rate of flashing/flickering the artwork produces needs
reviewing as part of the health and safety risk assessment.
The artworks *Personal Flash in Real Time (Ross)* and *Personal Flash
in Real Time (Tony)* this document refers to are two artworks which
are, in effect, one system and part of a much bigger project (called
Return to Ritherdon). Within these two artworks are flashing
lights. Because of that, the rate of flashing/flickering the artworks
produce needs reviewing as part of the health and safety risk
assessment.
## Overview of How the System Works
@ -60,10 +104,8 @@ gallery lights. Below is a diagram to help explain.
![System Overview](media/system-overview.png)
The diagram shows the two pairings which consists of one 'Light Meter'
and one 'Gallery Light'. The 'Gallery Light' is usually referred to as
'Relay' but I've changed it here to highlight the *factory-gallery*
relationship.
The diagram above shows the two pairings which consists of one 'Light
Meter' and one 'Gallery Light'.
**The important thing to note here is the lights in the gallery only
turn on when welding is occuring in any of the welding booths in the
@ -72,15 +114,16 @@ factory.** If no one is welding, the lights remain off.
### Why the Readings-per-Second Rate is Fluxtuates
As you work your way through this assessment, you will notice the
system produces inconsistent amounts of light readings per second. The
reason it fluxtuates throughout the day is because of how the system
measures the light. The quick version is the light meter is timing how
long the light sensor (within the light meter) takes to charge, based
on the amount of light hitting it. The more light hitting the sensor,
the quicker it charges and reaches its limit. If there is no or little
light hitting the sensor, it will take longer to charge which means it
can't determine what the current light level is. The amount of light in
Ritherdon (factory) changes throughout the course of the day hence the
system produces inconsistent amounts of (light)
readings-per-second. The reason it fluxtuates throughout the day is
because of how the system measures the light. The quick version is the
light meter is timing how long the light sensor (within the light
meter) takes to charge, based on the amount of light hitting it. The
more light hitting the sensor, the quicker it charges and reaches its
limit before it discharges. If there is no or little light hitting the
sensor, it will take longer to charge which means it will take longer
to calculate what the current light level is. The amount of light in
Ritherdon (factory) changes throughout the course of the day, hence the
inconsistent readings-per-second rates. For more information on how
the light meters measure the light levels, head to:
@ -166,7 +209,7 @@ help preserve the nature of the data in its raw form -- after
converting it to a comma-seperated-value (CSV or .csv) file. I
converted the data because of the specialised nature of databases (in
this case a SQLite database). Essentially, the `Id` column refers to
the 'row Id' for a particular reading. It makes it easier to refer to
the 'row Id.' for a particular reading. It makes it easier to refer to
a reading via its `Id` that its `Reading` value and/or `Time-Stamp`.
The `Time-Stamp` and `Reading` columns refer to the level of light
@ -184,8 +227,8 @@ issue. I've kept the data as close to its raw form as I can and the
Meter](https://git.abbether.net/return-to-ritherdon/rtr-docs/src/branch/master/light-meter/rtr-light-meter.md)
project is responsible for generating the data.
How the values stored in `Reading` are out of scope for this
assessment (see [Light
How the values calculates and stored in `Reading` are out of scope for
this assessment (see [Light
Meter](https://git.abbether.net/return-to-ritherdon/rtr-docs/src/branch/master/light-meter/rtr-light-meter.md)
for more information) but the main take-away is the more light in the
welding booth, the higher the number. There are two welding booths in
@ -193,15 +236,15 @@ the factory which this system monitors ('Light Meter 1' and 'Light
Meter 2' in the diagram above) and each one has their own threshold to
indicate when welding is occuring. For example, when the light level
for 'Light Meter 1' goes above `39` (at time of writing), this
indicates a staff member in the 'first' welding booth is welding which
triggers the light to turn on in the gallery ('Gallery Light
1'). Throughout the course of the day (factory operating hours are
07:00-16:00), the system repeats this process and documents every
indicates a staff member (Ross) in the 'first' welding booth is
welding which triggers the light to turn on in the gallery ('Gallery
Light 1'). Throughout the course of the day (factory operating hours
are 07:00-16:00), the system repeats this process and documents every
reading and the time it recorded it.
## How the Data was Processed/Reviewed
The data was analysed using the code in the
I analysed using the code in the
[Flicker](https://git.abbether.net/return-to-ritherdon/flicker)
repository. Please review the code/repository there for more
information on how the code works -- it is outside the scope of this
@ -209,70 +252,161 @@ document.
## Breakdown of Data Analysis
The sample of data reviewed for this assessment was taken from the
Light Meter readings produced by `factory1` running the software
provided by
[Light-Meter](https://git.abbether.net/return-to-ritherdon/light-meter),
on the **23/04/2021**. Overall, there was **84,294** light readings
taken over the course of **between 8 to 9 hours**. Also, this was a
**live test** with readings taken from the **intended environment**,
under **real-world conditions**. Of those readings, the number of
readings taken is as follows,
Within the [data](/data) directory, the [results](/data/results)
directory contains four files. These files are the result of the data
analysis.
*Note: Minutes and Hours are approximate values.*
```console
data
├── results
│   ├── filtered_flicker_entries.csv
│   ├── flicker_list.csv
│   ├── readings_above_threshold.csv
│   └── readings-per-sec.csv
├── test-data.csv
└── test-data-lite.csv
| Readings-per-Second | Seconds | Minutes | Hours |
|---------------------|---------|---------|-------|
| 1 | 5,344 | 89 | 1.5 |
| 2 | 2,955 | 49 | 0.8 |
| 3 | 13,284 | 221 | 3.5 |
| 4 | 8,297 | 138.28 | 2 |
|---------------------|---------|---------|-------|
| Total | 29,880 | 498 | 8.3 |
1 directory, 6 files
```
Let's say you have the following readings (sample taken from
`test-data.csv` stored in [raw-data](raw-data),
These four files are the results of the analysis conducted for this
assessment. And, each file will have its own subsection below.
**Note: The '.000000' is a artefact from the code's formatting of the
data.** You can ignore it. I've only kept it in to keep the data here
aligned as close as possible with the raw and computed data
[data](data).
### readings-per-sec.csv
- [readings-per-sec.csv](/data/results/readings-per-sec.csv)
Overall, the test data recorded **84,294** readings over the course of
about nine hours. With that said, the readings-per-second rates
fluctuated throughout those nine hours. To help explain, please review
the table below,
(*data taken from `test-data.csv`*)
| Time-Stamp (YYYY-MM-DD Hr:Min:Sec:MicroSec) | Reading | Readings/sec |
|---------------------------------------------|---------|--------------|
| 2021-04-23 07:02:50.000000 | 17 | 1 |
| 2021-04-23 07:02:51.000000 | 17 | ----------- |
| 2021-04-23 07:02:51.000000 | 17 | 2 |
| **2021-04-23 07:02:51.000000** | **17** | |
| **2021-04-23 07:02:51.000000** | **17** | **2** |
| 2021-04-23 07:02:52.000000 | 17 | 1 |
| 2021-04-23 07:02:53.000000 | 17 | 1 |
| 2021-04-23 07:02:54.000000 | 17 | 1 |
| 2021-04-23 07:02:55.000000 | 17 | 1 |
| 2021-04-23 07:02:55.000000 | 17 | 1 |
**Note: I've omitted the `Id` column from the example above because is
not relevant for this assessment.** If you review the raw data, you
will come across that column. More often than not, you can ignore it
if you're not looking to review/work with the code written for main
the system.
**Note: The '.000000' is a artefact from the code's formatting of the
data.** You can ignore it. I've only kept it in to keep the data here
aligned as close as possible with the raw and computed data
[data](data).
If you look at the time-stamp `2021-04-23 07:02:51.000000`, you will
see there are two readings recorded. This sample is very small but you
can see the remaining time-stamps have only one reading per each
second intervals. With this in mind, please note there are eight
reading spread across a five-second time-span. That is why the /first/
table above is broken down into time and not just hard frequency
totals. For 5,344 seconds on 23/04/2021, the system took a light meter
reading at one reading-per-second.
see there are two readings recorded. This sample is small but you can
see the remaining time-stamps have only one reading per each second
intervals. With this in mind, please note there are **seven reading
spread across a five-second time-span**.
When you calculate the amount of readings-per-second rates for all the
readings in `test-data.csv`, you will get the following results,
*(Minutes and Hours rounded to nearest .5)*
| Readings-per-Second | Seconds | Minutes | Hours |
|---------------------|---------|---------|-------|
| 1 | 5,344 | 89 | 1.5 |
| 2 | 2,955 | 49 | 1.0 |
| 3 | 13,284 | 221 | 3.5 |
| 4 | 8,297 | 138 | 2 |
|---------------------|---------|---------|-------|
| Total | 29,880 | 498 | 8.0 |
The way to read to table is as follows:
- for 5,344 seconds, the system operated at a rate of one
reading-per-second
- for 2,955 seconds, the system operated at a rate of two
readings-per-second
- for 13,284 seconds, the system operated at a rate of three
readings-per-second
- for 8,297 seconds, the system operated at a rate of four
readings-per-second
According to the sources listed above, 'between 3-30 hertz (flashes
per second) are the common rates to trigger seizures'. This means the
number of readings to review can be reduced to those operating at four
readings-per-second. This is because the lights in this system need to
go from an off-state (1) to an on-state (2) and back to an off-state
(3). The extra (fourth reading) is needed because there needs to be a
starting state (a zero if you will). Below is a sample of a moment
when four readings were taken in a one second period,
per second) are the common rates to trigger seizures'. To reach this
rate, the system needs to have a readings-per-second rate of four or
more. In this instance, the data shows the system can reach a rate of
four-readings-per-second. This means the light meters can
(technically) take enough readings-per-second to could trigger a
seizure. I nullified this, though, by limiting the number of new
readings the gallery lights can receive in a one second time period.
The reason why the rate needs to be four readings-per-second or higher
-- and not three -- is because of the need for a 'starting state'. For
example, let's say the first reading is 'off' and the second reading
is 'on'. There is only one change in state but two readings. If you
continue the process, you will require four readings to reach the
minimum threshold of three changes in state (I.E. off to on) per
second before you reach the quoted hertz limit to trigger a seizure:
1. off (starting state -- no change)
2. on (first state change)
3. off (second state change)
4. on (third state change)
What the data in `readings-per-sec.csv` shows is the system can
technically record enough readings-per-second to potentially trigger a
seizure. Although, it cannot do it at a constant rate. This result
meant I needed to expand my analysis of the data
(`test-data.csv`). But, I could limit the scope to the 8297 seconds of
recordings and not all of it.
### readings_above_threshold.csv
- [readings_above_threshold.csv](/data/results/readings_above_threshold.csv)
To review the time periods were the light meter was recording above
three hertz, I needed to know there timestamps. This file is a list of
those times. If you would like to manually review each time period
where the light meter recorded at three hertz, you can cross-reference
the times in `readings_above_threshold.csv` with `test-data.csv`. This
file is an artefact of the filtering process and needed to generate
`flicker_list.csv`. **For the most part, you can ignore this file**.
### flicker_list.csv
- [flicker_list.csv](/data/results/flicker_list.csv)
This file lists all the moments the light meter recorded at four
readings-per-second and the light levels at those times. I should note
here the gallery light paired with this light meter only **turns on**
if the light level is **above 39**. Upon reading this list, it is
apparent the gallery light does not always change its state (I.E. on
to off) for every time frame. This meant I could reduce the list even
more.
To help explain how to interpret the data, please consider the follow
sample from `flicker_list.csv`,
*Note: The '.000000' is a artefact from the software's formatting of
the data.*
| Timestamp | Readings |
|----------------------------|--------------------------|
| 2021-04-23 09:04:07.000000 | ['41', '37', '36', '36'] |
| 2021-04-23 09:04:11.000000 | ['36', '38', '40', '37'] |
| 2021-04-23 09:04:14.000000 | ['36', '36', '37', '36'] |
| 2021-04-23 09:04:18.000000 | ['36', '36', '36', '36'] |
| 2021-04-23 09:04:22.000000 | ['36', '36', '36', '36'] |
| 2021-04-23 09:04:26.000000 | ['37', '37', '37', '37'] |
What it shows is the light level recordings taken at the specified
moment in time. For example, for the one second period at `2021-04-23
09:04:11.000000`, the amount of light recorded in the welding booth
(in the factory) was `36`, `38`, `40` and `37`. What's important to
note here is the light changed state only once during this time frame
(when above `39`).
To expand on the point about noting the change in state, please
consider the following table (an expansion of the `2021-04-23
09:04:07.000000` timestamp),
| Time-Stamp (YYYY-MM-DD Hr:Min:Sec:MicroSec) | Reading | State |
|---------------------------------------------|---------|-------|
@ -281,41 +415,59 @@ when four readings were taken in a one second period,
| 2021-04-23 09:04:07.000000 | 36 | Off |
| 2021-04-23 09:04:07.000000 | 36 | Off |
**Note: The light paired with `factory1` is set to turn on (in the
gallery `gallery1`) when the reading is above 39.**
In the table above, you will see the light changes state (on to off)
once. For it to reach the noted rate of 'between 3-30 hertz', the
third reading in the table will need to have been above `39` to
trigger the light back on. This would have made the light change from
on to off three times, taking into account the need for a 'starting'
state.
Referring back to the table listing the various rates of
readings-per-second (the first table), there are only **8,297**
readings (technically it's seconds but 'readings' is easier to
process) instead of **84,294**. This can be filtered down even more,
though. This is because not all four readings-per-second occurrences
cause the light to change its current state (I.E. it doesn't go from
off to on). With this in mind, the number of entries to review drops
to **8** when you list just the times when the light changes its
state. They are,
It shows, for the one-second period at `2021-04-23 09:04:07.000000`,
the gallery light changed its state (from on to off) once. It does this
when the light level is above `39`. This, in effect, demonstrates the
system flash rate was one hertz for that second.
### filtered_flicker_entries.csv
- [flicker_entries.csv](/data/results/flicker_entries.csv)
The data in this file filters the data in `flicker_list.csv` down to
eight time periods. These are the times the light recorded at four
readings-per-second and cause the gallery light to change state at
least once. The format in this table is the same as
`flicker_list.csv`, so refer to that section for information on how to
read the data in `flicker_list.csv`.
The three main points to take away from this file are:
1. The system never managed to reach the three hertz threshold;
2. The system couldn't sustain the rate to *potentially* reach the
three hertz threshold beyond one second; And,
3. The system reached the readings-per-second rate to *potentially*
reach the three hertz threshold for eight seconds over an
*approximate* nine hours period.
What's important to note about the last point is eight seconds over
nine hours is **less than one second-per-hour**. That's even if the
system manage to cause the gallery light to flash at three hertz. To
help explain the above, please see the table below,
*Note: This is an expansion of
`flickered_flicker_entries.csv`. 'States' and 'Hertz' and not included
in the .csv file.*
| Time-Stamp | Readings | States | Hertz |
|----------------------------|----------------|------------------|-------|
| 2021-04-23 09:04:07.000000 | 41, 37, 36, 36 | on, on, off, off | 1 |
| 2021-04-23 09:04:11.000000 | 36, 38, 40, 37 | off, on, on, off | 1 |
| 2021-04-23 09:04:11.000000 | 36, 38, 40, 37 | off, on, on, off | 2 |
| 2021-04-23 10:54:05.000000 | 39, 39, 40, 40 | on, on, on, on | 0 |
| 2021-04-23 10:54:07.000000 | 39, 39, 39, 40 | on, on, on, on | 0 |
| 2021-04-23 10:56:46.000000 | 40, 40, 39, 39 | on, on, on, on | 0 |
| 2021-04-23 10:57:13.000000 | 40, 41, 40, 39 | on, on, on, off | 1 |
| 2021-04-23 10:58:13.000000 | 39, 46, 44, 39 | off, on, on, off | 1 |
| 2021-04-23 11:00:11.000000 | 39, 42, 46, 39 | off, on, on, off | 1 |
This tables shows the limitations of the system to trigger a
photosensitive epileptic seizure. The system produced **at most** a
flash rate of **1 Hertz** over the course of **approximately 8 to 9
hours** of activity.This is below the '3 to 60 Hertz' claimed by
[Epilepsy
Society](https://epilepsysociety.org.uk/photosensitive-epilepsy) (more
references/links at the top of this file).
| 2021-04-23 10:58:13.000000 | 39, 46, 44, 39 | off, on, on, off | 2 |
| 2021-04-23 11:00:11.000000 | 39, 42, 46, 39 | off, on, on, off | 2 |
### The Human Element in The System
A point I haven't touched on yet is the involvement of the two members
of staff, in Ritherdon (factory), operating the welders. Overall, it
is the welders who trigger the gallery lights on and off. This means
they would need to cause their welders to flicker/flash above three
hertz which does not align with the types of jobs they are tasked
with. Granted, this is a point without any *immediate and explicit*
data recorded data to demonstrate this as fact. I can only imply it
through the data analysis above. This section/point is more about
providing extra context to the assessment.