{%hackmd theme-dark %}

# Questions
- What do we get sent to the ACMS - raw data or good/bad
- Astronaut tracking, different timer?
- Level of perms for commander - can override adjacent gates??

# Assumptions
* Astronauts know about conditions, safety procedures / have had extensive training and "know what to do".
* The astronauts are healthy, no underlying health conditions.

# Important Outlining Points
* When the external door is closed, the airlock is flooded with air until normal atmospheric conditions are restored. Emptying (or refilling) an airlock takes 10 seconds.
* A gate takes 5 seconds to fully open and 5 seconds to close (from a fully open state).

# Management System Requirements Notes

* Ambient Pressure Management System
* Reads the air pressure very small intervals from a sensor.
* When a air pressure value "fails" (under a certain amount or over), ACMS receives a signal
* When pressure drops, O2 drops, so 2 ALL_CLEAR's handled by the ACMS - testing

|ID|Functional requirement|Description|Test|
|-|-|-|-|
|1|React to bad readings|- Set value for bad readings <br> - Wait 20 seconds before lockdown room||
|2|React to good readings|- Set value for good readings <br> - If room is in lockdown because of air quality, send message to ACMS||

* Air Quality Management System
* Reads air quality (O2, CO2, CO, fire suppressent) through sensor
* Bad levels = alarm, request 20 second delay to ACMS, then lockdown
* Levels restored, stop alarm, ALL_CLEAR to ACMS, gates unlock

|ID|Requirement|Description|Test|
|-|-|-|-|
|1|Read data from sensor|The system should be able to read and understand the data sent from the sensor<br>Includes O2, CO2, CO||
|2|React to bad readings|- Set value for bad readings <br> - Wait 20 seconds before sending request to ACMS to lockdown room||
|3|React to good readings|- Set value for good readings <br> - If room is in lockdown because of air quality, send message to ACMS||

* Fire Detection and Suppression System
* In event of fire, request 20 second delay to ACMS, then lockdown
* Fire suppressant pumped into chamber
* When fire extinguished, chamber purged of suppressant, O2 pumped back in
* Fire alarm deactivated, **AIR QUALITY GIVE ALL_CLEAR**

| ID | Requirement | Description | Test |
| --- | ----------- | ----------- | ---- |
|1|Read data from sensor|The system should be able to read and understand the data sent from the sensor||
|2|React to bad readings|- Set value for bad readings <br> - Wait 20 seconds before sending request to ACMS to lockdown room||
|3|React to good readings|- Set value for good readings <br> - If room is in lockdown because of air quality, send an all clear message to the ACMS||

* Biohazard Detection System
* In the event of a biohazard being detected, an immediate lockdown is initiated and an alarm is raised
* The affected pod is then purged of air / the pod is put through a cleaning process
* The astronauts have access to manually override the doors so they can access the airlock system to save their own life. - Training assumed here.

aleks wuz ere

| ID | Requirement | Description | Test |
| ---- | ----------- | ----------- | ---- |
|1|Monitor "biohazard levels" per room |This system must be able to constantly monitor a room for detection of a biohazard event, through some hypothetical sensor dedicated for it. | |
|2|Send alert when biohazard levels reach critical |The system should send an alert of some form to the ACMS and therefore the GCU, to request a lockdown of the local rooms. | |

* Radiation Monitoring System
* In the event that radioation levels pass a safe level, a 20 second delay is requested to the ACMS and the pod is locked down
* The affected pod is then purged of air / the pod is put through a cleaning process (outside of ACMS' scope)
* Once the radiation returns to a safe level, alarms are deactivated and **RADIATION GIVE ALL_CLEAR**

| ID | Requirement | Description | Test |
| ---- | ----------- | ----------- | ---- |
|1| ACMS inteprets warning signal from RMS|When ACMS recieves a warning signal from RMS, it waits 20 seconds before launching local lockdown procedure|Send ACMS warning signal from RMS; Expected behaviour sees ACMS begins lockdown procedure in the relevant pod after 20 seconds|
|2|ACMS inteprets all clear signal|When ACMS recieves all clear for the relevant pod, lockdown procedure ends|Send ACMS all clear signal from RMS; Expected behaviours sees ACMS end lock down procedure in the relevant pod |

* Central Access Management System
* Each Astronaut has Personal Locator Device (PLD)
* Sends location and biometric data to gate sensors
* Short Range sensors detect PLD, send astronauts details to ACMS

|ID|Requirement|Description|Test|
|-|-|-|-|
|1|Take in PLD information|The CAMS can take PLD information from the ACMS||
|2|Take in biometric / vitals information |The CAMS can take biometric / vitals information about the astronauts from the ACMS|

* Airlock Control Management System (ACMS)
* No 2 adjacent gates open same time
* IF hazardous event, 30 secs, then lock room
* Every open, check safe room other side
* Standard Limits, Extreme Limits
* ACMS checks constantly that there are 5 different ALL_CLEAR's if an ALL_CLEAR is missing then the lockdown procedure for that room is deployed depending on how each machine works.
* Send sensor information in packet to CAMS(?)

|ID|Functional requirements|Description|Test|
|-|-|-|-|
|1|ACMS shouldn't allow adjacent (connected) gates to open|No connected gates should be able to open at the same time.<br> There shouldn't be more than one door in any given room open at any point.<br>Flag overrides this feature, flag triggered by emergency.|Test by opening 2 adjacent gates at once via the ACMS for it to hopefully fail.|
|2|If hazardous event, lock room after buffer period|If the ACMS receives an alarm signal, wait an amount of time (different for each system) and then lockdown the affected pods doors.||
|3|Prevent an astronaut from entering an unsafe pod|The ACMS should lock as many gates as necessary to seal off and prevent an astronaut from traversing a pod that unduly threatens the astronaut or the facility. ||
|4|A PLD is required for a door request|An astronaut using the door control button must be wearing an authorised Personal Locator Device in order for the request to be processed.||
|5|Any gate can be locked administratively|Any gate in the facility can be locked remotely by an administrator on the ACMS console.||
|6|Manual overide system|There must be manual overide capability to allow locked gates to be opened by astronauts manually.||
|7|ACMS needs to be able to read data sent from management systems|The ACMS needs to be able to take in data from the sensors||
|8|Door must close in around 5 seconds (not instantly)|Door must close in around 5 seconds, OPEN = 135 degrees, CLOSED = 0 degrees||
|9|ACMS needs to be able to send data| The ACMS needs to be able to send data to the GCU|GCU receives data from ACMS by reading registers<br>GCU reads the flags which the ACMS sets.||

**Write parser requirements**

# Requirements
* Safety of the facility if an extreme event occurs. A pods must have its own life support system so that it can support 3 astronauts for 3 days. B pods should also have a life support system so that it can support 1 astronaut for 3 days.
* Security of the facility and PLDs. Usage of the PLDs should allow for only astronauts with correct identification and access rights can access the facility and gates.
* Reliability when a user does an event which triggers a function.

## Functional Requirements for the simulation
These requirements define what the system should accomplish without fail in the final simulation.

Involves:

- Business rules
- User interfaces
- System interfaces
- How does it support authentication, identification etc

## Non-Functional Requirements for Simulation
Non functional requirements:

These requirements define how the system should operate in the final simulation.

Measures of non-functional requirements include:

Speed
- Eg: processed transactions/second, user/event response time, screen refresh time, etc

Size
- Eg: megabytes, number of ROM chips, etc

Ease of use
- Eg: training time, number of help frames, etc

Reliability
- Eg: mean time to failure, probability of unavailability, rate of failure occurrence, availability, etc

Robustness
- Eg: time to restart after failure, percentage of events causing failure, probability of data corruption on failure, etc

Portability
- Eg: percentage of target dependent statements, number of target systems, etc

Involves:

- Compliance
- Support
- Availability
- Performance
- Business Continuity & disaster recovery

| Number | Requirement | Description | Example Test |
|-|-|-|-|
|1|Should be written in python3| Python code | test if python |
|2|UI should be done using Django|Django used to display data||
|3|UI receive and output data every second|UI receives data from ACMS ||
|4|The software must take a maximum of one hour to train a user in|||
|5|The software must have helpful and informative error messages|||
|6|The software must take under 30 seconds to restart|||
|7|The software must allow for the addition of more pods and airlocks to the moon base|||

# (Currently DESIGN) Tasks

### Whole modules / components diagram - Lewis
- All components shown in an abstract diagram
- How they interact with eachother
- Data transfer between each module


- The UI will select and initialise a test scenario, loading it into the parser.
- The scenario can then be started
- The parser will pass data to the ACMS which will in turn process it and pass appropriate data to other modules
- A results processor will receive (from ACMS) the parser data, the processed data sent out by the ACMS and data received by the ACMS. This will be stored and be available to view later.

### UI (Design, Develop) - Lewis
- Wireframes / Design
- Central Access Management System will be our UI
- It will contain: Map / model, location of astro, test scenario button, alerts
- Done in tkinter
- Takes information, DOES NOT PROCESS / NO CONFIG
- Step through time - sim split into blocks rather than sim in real time

### Develop Parser - JJ
- Decide what data format
- Develop code for parser

### Develop Airlock Control Management System -Alex, Adam
- Design: What it needs to accomplish
- Translate to Code
- Transit of Data to GCU, CAMS
- https://docs.google.com/document/d/1RVhFJXphzc9Ik3KjFWyJEiitV75bX7B-6yf5CNwywyw/edit?usp=sharing

### Develop Gate Control Unit - James K
- Design: What it needs to accomplish
- Translate to Code
- Transit of Data to GCU, CAMS

### Design Test Data - Owen
- General overview of the format of data
- Test Cases (Edge,Erroneous etc)

### Simulator Overall
Test Definition -> Test Parser -> Execution -> UI

# OWASP ASVS Requirements
https://raw.githubusercontent.com/OWASP/ASVS/v4.0.3/4.0/OWASP%20Application%20Security%20Verification%20Standard%204.0.3-en.pdf

> we could do this for each section and thing such as PLD for project