diff --git a/health-and-safety/media/system-overview.png b/health-and-safety/media/system-overview.png new file mode 100644 index 0000000..7411fb3 Binary files /dev/null and b/health-and-safety/media/system-overview.png differ diff --git a/health-and-safety/photosensitive_epilepsy.md b/health-and-safety/photosensitive_epilepsy.md index 01ae266..660b4ed 100644 --- a/health-and-safety/photosensitive_epilepsy.md +++ b/health-and-safety/photosensitive_epilepsy.md @@ -1,8 +1,7 @@ - # Return to Ritherdon: Photosensitive Epilepsy -This document is to be used as part of the health and safety risk -assessment for the Return to Ritherdon exhibition. +This document is part of the health and safety risk assessment for the +'unnamed' artwork in the Return to Ritherdon exhibition. ## Summary of Assessment @@ -10,9 +9,9 @@ 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 with *approximately* 8 to 9 hours on usage, on the -23/04/2021. This falls outside the **3-30 Hertz** claimed by Epilepsy -Society (link below). +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). ## Information About Photosensitive Epilepsy @@ -20,9 +19,7 @@ According to [Epilepsy Society](https://epilepsysociety.org.uk/photosensitive-epilepsy), a flashing/flicker light between 3-30 hertz can trigger a seizure. -> What rate of flashing light can trigger seizures? - -> > Between 3-30 hertz (flashes per second) are the common rates to +> Between 3-30 hertz (flashes per second) are the common rates to trigger seizures but this varies from person to person. While some people are sensitive at frequencies up to 60 hertz, sensitivity under 3 hertz is not common. @@ -39,19 +36,168 @@ More information can be found at: 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 to -be reviewed as part of the health and safety risk assessment. - -## Viewing the Raw Data +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. + +## Overview of How the System Works + +This is not a complete overview of how the system works. That is +outside the scope of this document. Instead, this is a simplified +version for the sake of brevity. For a more thorough overview, please +use the following (documentaton) links: + +- [Light Meter](https://git.abbether.net/return-to-ritherdon/rtr-docs/src/branch/master/light-meter) +- [Relay](https://git.abbether.net/return-to-ritherdon/rtr-docs/src/branch/master/light-meter) +- [Midpoint](https://git.abbether.net/return-to-ritherdon/rtr-docs/src/branch/master/midpoint) + +The system consists of five devices but only the server (Midpoint) +interacts with all its counterparts. There are two 'Light Meters' +which reside in Ritherdon (factory) and two 'Gallery Lights' which +communicate with each others opposite via the server. 'Each others +opposite' refers to the two pairings between the light meters and +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 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 +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 determine 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: + +- [Light + Meter](https://git.abbether.net/return-to-ritherdon/rtr-docs/src/branch/master/light-meter) + +## Accessing the Data This document will only provide a summarised view of the data because -of the size of it. If you would like to review the raw data please -head to: +of the size of the raw files and databases are rather large and +cumbersome. If you would like to review the data used in this +assessment please head to: - [data](data) -- [raw-data/results](data/results) (for the data after it's been - processed and used for this risk assessment) + +Otherwise, the more complete set of test data is available at: + +- the + [Flicker](https://git.abbether.net/return-to-ritherdon/flicker/src/branch/stable/src/data) + project (takes you to the 'data' part of the repository) + +How I've broken down the data files/directory is as follows: + +```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 + +1 directory, 6 files +``` + +As you can see, the `test-data.csv` and `test-data-lite.csv` reside in +the top most directory. And, these are the files which I passed +through +[Flicker](https://git.abbether.net/return-to-ritherdon/flicker) in +order to get the files in `results`. Technically, I used only +`test-data.csv` but `test-data-lite.csv` is a subsection of its larger +counter part. If your computer is stuggling to open the full-sized +`test-data.csv` file, I recommend falling back onto +`test-data-lite.csv` -- where you can see what the data at least looks +like. + +I've omitted all databases used throughtout the project in the `data` +directory because of their unweildy size and niche use (outside +specialised environments/industries). Access to the SQLite databases +are available if needed. + +## Reading the Data + +If you would like to see the data in situ, click on the following: + +- [test-data-lite.csv](https://git.abbether.net/return-to-ritherdon/rtr-docs/src/branch/unstable/health-and-safety/data/test-data-lite.csv) + +The data consists of three columns: + +1. `Id` +2. `Time Stamp` +3. `Reading` + +*Sampe of readings taken from `test-data.csv`* + +| Id | Time-Stamp | Reading | +|---------|----------------------------|--------:| +| 7780379 | 2021-04-23 07:00:20.000000 | 5 | +| 7780380 | 2021-04-23 07:00:21.000000 | 11 | +| 7780381 | 2021-04-23 07:00:22.000000 | 11 | +| 7780382 | 2021-04-23 07:00:24.000000 | 11 | +| 7780383 | 2021-04-23 07:00:25.000000 | 11 | +| 7780384 | 2021-04-23 07:00:26.000000 | 11 | +| 7780385 | 2021-04-23 07:00:27.000000 | 11 | +| 7780386 | 2021-04-23 07:00:29.000000 | 11 | +| 7780387 | 2021-04-23 07:00:30.000000 | 12 | +| 7780388 | 2021-04-23 07:00:31.000000 | 12 | +| 7780389 | 2021-04-23 07:00:32.000000 | 12 | + +For this assessment, you can ignore the `Id` column. I've kept it to +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 +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 +recorded at that speficied time. For example, at `2021-04-23 +07:00:26.000000` (row `7780384`), the amount of light recorded was +`11`. I should point out here, the time-stamp format is as follows: + +- `YYYY-MM-DD Hr:Min:Sec:MicroSec` (`Hr` is 24-hour) + +On top of that, every time-stamp has their `MicroSec` values set to +`.000000`. The code used to generate this data is responsible for +this. It just doesn't record it and is not a data conversion +issue. I've kept the data as close to its raw form as I can and the +`.000000` is a consequence of that. The [Light +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 +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 +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 +reading and the time it recorded it. ## How the Data was Processed/Reviewed @@ -92,16 +238,17 @@ 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). -| Time-Stamp (YYYY-MM-DD Hr:Min:Sec:MicroSec) | Reading | -|---------------------------------------------|---------| -| 2021-04-23 07:02:50.000000 | 17 | -| 2021-04-23 07:02:51.000000 | 17 | -| 2021-04-23 07:02:51.000000 | 17 | -| 2021-04-23 07:02:52.000000 | 17 | -| 2021-04-23 07:02:53.000000 | 17 | -| 2021-04-23 07:02:54.000000 | 17 | -| 2021-04-23 07:02:55.000000 | 17 | -| 2021-04-23 07:02:55.000000 | 17 | +| 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: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 @@ -170,5 +317,5 @@ 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 +Society](https://epilepsysociety.org.uk/photosensitive-epilepsy) (more references/links at the top of this file).