diff --git a/health-and-safety/photosensitive_epilepsy.md b/health-and-safety/photosensitive_epilepsy.md index 4843887..07dcc2d 100644 --- a/health-and-safety/photosensitive_epilepsy.md +++ b/health-and-safety/photosensitive_epilepsy.md @@ -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.