# CCSE Requirements
Functional requirement - What the system should do.
Non-functional requirements - How the system functionality works.

:::warning
What happens if ACMS goes offline?
:::
:::warning
What happens if any lower systems go offline?
:::
:::warning
How does the 5 second door open/close time affect things?
:::


## ACMS Airlock Control Management System - Daniel

Main system. Receives, interprets, and responds to all signals in the system, as shown in the above diagram. Controls all gates and airlocks.
Makes use of a set of internal registers

#### Functional Requirements
- The ACMS must have a UI, that displays important information about the status of the base.
- The UI should display a simple representation of the base, indicating pods, connecting gates and airlocks.
- The UI should display the location of all 10 astronauts.
- The UI should display the status of each gate and each pod.
- Can be test-based or a single page web application (SPA)
- The ACMS should prevent dangerous events from taking place
- Ensure no two adjacent gates are open at the same time
- This can be overrided if the emergency manual override feature has been set
- Once a signal has been received alerting the ACMS to a hazardous event within a pod or ailock, after a short period of time (20 seconds) gates connecting to the affected location will be locked
- Signals should be accepted form the APSMS, AQMS, FDSS, BDS, RMS, CAMS, GCU.
- By locking one or more gates the ACMS should prevent an astronaut from traversing a gate into a pod that unduly threatens either the astronaut or the facility
- Any gate should be able to be administratively locked from the ACMS console
- A manual override capability enables locked gates to be opened manually

#### Non-Functional Requirements
- The system should be able to be easily extended to allow for more pods and gates.
- The system should be up constantly
- The system should be maintainable
- The system should be able to run with little to no maintainance

### Air Pressure Sensor Management System - Tommy
The APMS monitors the current state of the ambient pressure within the pods. If the pressure within a pod should deviate from the 'safe' conditions, it sets off a warning klaxon. This is followed by an alarm signal to the ACMS requesting a 20 second delay before a lockdown is initiated for the pod with the failure.

If 'safe' conditions return then an 'ALL_CLEAR' signal is sent back to the ACMS.

The only exception to this is if the pressure is lost within in airlock following an external door request. This is normal as the air must be extracted from the airlock prior to opening the external door. In this case, a warning light is active until pressure returns to 'safe' levels.

The external door only enters the 'GATE_OPENING' state once the air has been withdrawn from the airlock.
#### Non-Functional
* The system is always active and reliable
* Resilient to failures in the system itself (faulty sensor etc.)
* Easy to integrate within the ACMS

#### Functional
* Monitors air pressure within the airlocks and pods
* Distinguishes between airlocks and pods
* Can communicate signals with the ACMS
* Able to detect air pressure failures
* Sets off warning klaxon in event of a failure

### Air Quality Management System (AQMS) - Daniel
Detects concentrations O₂ gases present in the atmosphere, as well as harmful gases, such as CO₂. If oxygen levels fall below a certain limit, or levels of harmful gases rise above a certain limit, a signal is sent to the ACMS requesting a 20 second delay prior to initialising local lockdown procedures.
When air-quality levels have returned to normal, air quality alarms are de-activated and an "ALL_CLEAR" signal is sent to the ACMS.
In the case of an airlock, if the external door control button is pressed, no alert is created as the air is extracted from the airlock.

#### Non-Functional
* The system needs to be available around the (moon) clock
* The results it collects need to be accurate within a certain margin
* It needs to be able to communicate with other modules present on the base
* It needs to be maintainable
* The system needs to run efficiently without constant maintenance

#### Functional
* If gas concentrations exceed certain safe limits, a signal should be sent to the ACMS
* This signal should not be sent if the airlock is open, as the O₂ will be 0.
* When air quality levels return to normal the AQMS should send an "ALL_CLEAR" signal to the ACMS

### Fire Detection and Suppression System - Alex
The FDSS detects fires in pods/airlocks. Upon detection a signal is sent to the ACMS requesting a 20 second delay before initiating lockdown. Fire suppressant gas is pumped into the chamber. When sensors show fire is extinguished, pod is purged of suppressant and pumped back full of O2. Fire alarms are then deactivated.
#### Functional
- Can detect input from sensor and send signal to ACMS
- Can release fire suppressant gas when fire
- Can purge suppressant when fire extinguished
- Can deactivate fire alarm when fire extinguished
#### Non-Functional
- Can handle multiple pods having a fire alarm at once.
- Can easily be implemented in new pods
- Should reliably act as planned, no random mis-detection, no off-spec actions

### Biohazard Management System - Eleanor

Monitors biohazard levels in pods and airlocks.

When biohazard levels in a pod or airlock exceed a set limit, an alarm is triggered, and a signal is sent to the ACMS requesting an immediate local lockdown. Once the biohazard indicators recognise safe levels again, an "ALL CLEAR" signal is sent to the ACMS. This will indicate the pod or airlock has been successfully purged of harmful biohazards using the external vents.

Biohazard sensors detect biohazard levels above-set limit -> Signal sent to ACMS and alarm is sounded -> ACMS receives lockdown signal -> All gates in affected pod are locked

Affected pod/airlock is purged using external air vents -> biohazard levels return to normal -> "ALL CLEAR" signal sent to ACMS -> gates resume normal operation

#### Functional Requirements

- Can interpret sensor input to read biohazard level.
- Can send a signal to ACMS and sound alarm when biohazard is above a set level.
- Signal sent to ACMS triggers all doors in the affected pod/airlock to lock.
- Can detect when biohazard level returns to normal.
- Can send "ALL CLEAR" signal to ACMS once normal biohazard levels are detected.
- Can disable alarm once normal biohazard levels are detected.
- Can handle multiple system events simultaneously.

#### Non-Functional Requirements

- Scalable, to allow the compound to grow and the system to be implemented in new pods.
- The system should be able to change state and send alerts without human interaction.
- System abides by SpaceLaw101.
- The system needs to consider human error as a factor. Biohazard levels should be available to allow for human intervention.

### Radiation Monitoring System - Dayyan

If radiation levels exceed the preset safety limit in a pod or airlock, an alarm will be raised and a signal should be sent to the ACMS requesting a 20 second delay before initiating local lockdown procedure. After normal radiation levels are restored (maybe through removal of radiation inside the pod through cleanup), then alarms are deactivated and and an "ALL CLEAR" signal should be sent to the ACMS.

#### Non-Functional
- 24/7 uptime
- Availability to monitor the different types of space radiation independetly of one another
- All functions should happen automatically without human input

#### Functional
- can interpret sensors to monitor and read radiation levels
- Alarm is raied and signal sent to ACMS once radiation levels exceed normal levels
- 20 second delay signal sent to ACMS before inititating lockdown
- When radiation levels are returned to normal, alarms are deactivated and "ALL CLEAR" signal is sent to the ACMS.

### Central Access Management System
The Central Access Management System uses Personal Location Devices on all astronauts to convey precise information about their location and biometrics throughout the facility. Short range sensors are used at both sides of a gate to detect the PLD of an astronaut in proximity and send their details to the ACMS for authorisation to interact with the door control button.

#### Non-Functional
* The system is always active and reliable
* Resilient to failures in the system itself (faulty sensor etc.)
* Easy to integrate within the ACMS

#### Functional
* Can communicate with the ACMS
* Can communicate with the short range sensors
* Grants authorisation for a door to operate when given by the ACMS

## Gate Control Unit

:::info
TO BE ADDED
Bullet point summary of how the GCU works
Can include diagrams to help with this
:::

## Output parser
* Can parse output from system
* Can show user current state of system
* Can show user whether the current configuration has passed or failed set goals

## Pods

### non-functional requirements
* Scalable, allow for the addition of new pods in the facility
*
*
*

### functional requirements
* 'A'pods can connect to a maximum of 4 other pods
* 'B' pods can connect to a maximum of 2 other pods
* Pods connect to each other via air tight gates, however pods leading to the external lunar landscape or Bio-research pod require airlocks to be used instead
* 'A' type pods to contain independent life support system that can support 3 astronauts for a period of 3 days
* 'B' type pods to contain independent life support system that can support 1 astronaut for a period of 3 days

## Airlocks

### non-functional requirements
* Scalable, allow for new airlocks to be added to new pods
* can communicate with ACMS
*
*

### functional requirements
* prior to the opening of an external door of an airlock, extraction units that link back to the life support pod will reclain the air within the airlock
* When the external door is closed, airlock is refilled with air until normal atmospheric conditions are reached
* Emptying or refilling an airlock with air is to take 10 seconds