Skip to content

Design Documentation

Philipp Kramer edited this page Feb 6, 2023 · 11 revisions

1. Introduction

This document contains information about the software architecture of the SOSCI application. It contains details about design decisions, implementation structure and details as well as information about hosted environments as well as dependencies.

References as well as the bill of matierals can be also found here.

1.1 Scope

This document applies to the software project SOSCI and the default configuration.

This document does not cover information about developer guidelines, CICD details or future changes.

1.2 Definitions, Abbreviations

Abbreviation Definition
SOSCI Project name, Software Oscilloscope
GUI Graphical User Interface
CICD Continuous Integration Continuous Deployment

1.3 References

Reference Description
Design / Architecture Documentation This document Contains information about design & architecture details about SOSCI and it's components
User Documentation Contains information about how to use SOSCI
Build Documentation Contains information about how to locally build SOSCI and the CICD environment

1.4 Bill of materials

Context Name Version License
OS Docker 20.1 Apache 2.0
Generator tokio 1.21.2 MIT License
UI Svelte 3.52.0 GPLv3
UI svelte-toggle 3.1.0 MIT License
UI sveltestrap 5.10.0 MIT License
UI WebGL 2.0 Mozilla Foundation (Free License)
UI sass 1.56.2 MIT License
Testing Cypress 11.0.1 GPLv2
Interfaces axios 1.2.1 MIT License
Interfaces express-openapi 3.2.0 MIT License
Interfaces ws 8.11.0 MIT License
UI clsx 1.2.1 MIT License
SAST Sonarqube 9.2.4 (build 50792) LGPL v3
Backend Testing sinon 15.0.1 BSD License
Backend Testing chai 4.3.7 MIT License
Backend Testing connect 3.2 MIT License
Backend Testing Jest 29.4.1 MIT License

2. Requirements

There is a set of requirments formulated by the client and initiator of the project idea.

The application shall:

  • Handle at least 10.000 samples per second
  • Provide a GUI including data visualization
  • Allow for enabling/disabling and repositioning channels
  • Allow the adaption of the sweep speed
  • Display the data using WebGL
  • Be provided in a microservice architecture with three services
    • Frontend: Displays information
    • Generator: Simulates data signals
    • Backend: Provide data to frontend
  • Be tested across all components

3. Architecture

3.1 Architectural Goals and Constraints

Due to the client requirements SOSCI has to achieve two major goals.

  1. The first goals is to provide an application to meet the required performance of handling at least 10.000samples/second
  2. The second one is to provide all normal features of a normal hardware osciloscope

There are also a set of constraints for the architecture

  1. It shall be designed as microservice application with three services
  2. Data signal visualization at the frontend should use WebGL techniques

3.1 Architectural Representations

Overview

Generator: The Channel Signal Simulator

The generator acts as a simulator for signals. He sends continuously signals for 10 channels to the connected backend via an UDP data stream. Sample rate and frequency is changeable.

It's implemented as RUST service using tokio for network communication.

Backend: The Oscilliscope Backend

The backend accepts the incoming channel data from the generator and prepares it for transmission to the frontend. It also provides a REST API for loading & storing channel configurations like enabled channels, offset and amplitude settings.

It's implemented using NodeJS with a plain websocket for channel transmissions and express with a OpenApi3 specification for the REST interface.

Frontend: The Oscilloscope User Interface

The frontend provides a graphical user interface including the plotted channels and detailed information about min & max values. Via the control panel it's also possible to adapt the sweep speed, amplitude and offset for each individual channel. The settings page provides access to pre-configured channel properties and gives also the ability to create new presets.

The Svelte Framework is used for basic web implementation whereas WebGL is used for rendering the channel data and additional information. WebGL is used to take advantage of optimized GPU calculations and increase the frontends performance to match required performance constraints.

3.1.1 Use Case View

Use Case View

3.1.2 Logical View

Logical View

3.1.3 Process View

Process View

3.1.4 Deployment View

The application contains three services which run as Docker containers. As the Generator has no requirement for beeing public available it exchanges data with the Backend using an internal Docker network. The Frontend has be available from the Internet therefore it publishes it's port 80 in a bridge network. As the REST API has to be public available, the Backend is also part of the bridge network and the REST API port can be mapped freely.

Deployment View

3.1.5 Implementation View

The source code for each service is located at:

  • repository root
    • Apps
      • Backend
      • Frontend
      • Generator
  • ...

Implementation View