1. System Specification

1.1. Initial situation

The HTL Leonding is a HTL in the central region of Upper Austria. Groups of students often take part in the CanSat competition where the goal is to shoot a satellite the size of a tin can at a height of 500 meters.

1.2. Actual state

This satellite is equipped with various sensors and sends telemetry data (sensor data such as ambient temperature, altitude, etc.) to one or more ground stations.

1.3. Problem definition

The participating students currently do not have a uniform, easily transportable way to control a rocket or the satellite and to receive or record telemetry data (see actual state). Launching device and control unit are currently not connected to each other. The Launching device is currently a small handheld, connected by wire to a small electronic detonator inside the rocket. Ebay link. Each student group always has its own non-unified design.

1.4. Task definition

Based on an externally delivered control unit, software for the implementation on the problem statement given above will be delivered by the project team. The results which will be described in this section are divided into the prerequisites, the functionality and other aspects which derive from the functionality, each in a separate subsection.

1.4.1. Prerequisites

In the following requirements we assume that the hardwareparts are delivered externally. Moreover we assume that all delivered software APIs come together with the documentation.

1.4.2. Functional requirements

  • The user should be able to set the software mode of operation

    • The trigger for the change of software mode is the delivered suitcase key

    • The software should be able to chose between user-mode, readonly-mode and admin-mode by the movement of the suitcase key

      • readonly-mode: In this mode it should only be possible to observe telemetry data

      • user-mode: In this mode it should be possible to observe telemetry data, initiate the countdown and control an actuator

      • admin-mode: In this mode the system may be configured(e.g. set the Countdown and activate an actuator)

  • The software in user-mode should be able to initiate the ignition of the rocket

    • The ignition should be possible by wire or wirelessly

  • Communication capabilities should be delivered

    • The suitcase should be able to communicate by standard API with competition administration system. The standard API documentation must be delivered by the competition administration.

  • It should be possible to communicate wirelessly with several branch offices simultaneously.

1.4.3. Non-functional requirements

  • Easy usability

    • Due to user with limited software knowledge the UI has to be easy to use

  • Ignition current may only flow, if this is really wanted by the user

  • The control unit should function without internet or cloud access

    • As currently known the internet access is only required for downloading settings for the launch, so the user has to download them beforehand

1.4.4. Class-Diagram

classdiagram

1.4.5. ERD

erd

1.4.6. Use-Case-Diagramm

usecasediagramm

1.4.7. Deployment-Diagramm

Failed to generate image: PlantUML image generation failed: [From <input> (line 2) ]

@startuml

^^^^^
 Empty description

1.5. Goals

The goal is to make it easier for future students to participate. As there is already an existing design for the ground station.

1.6. Quantity structure

Currently not foreseeable. Will be added as soon as possible.

2. Concept

2.1. System architecture

systemarchitecture