Skip to content

Software Architecture Description

Company: Nikted
Document Name: Software Architecture Description (Client App)
Document Number: HAD-RPT-152-Rev1
Author: Khebrati
Date (Persian Calendar): 1404/06/30

Revision History

Rev. no. Description Author(s) Reviewers Date (Persian) Authors' Signature Reviewers' Signature
1. Initial Draft khebrati Ghafar nosrati

1. Regulatory References

Regulatory references:

IEC 62304, para. 5.3.1 and 5.3.2 [class B, C]

Relevant other documentation:

  • SOP Software Development
  • User needs / stakeholder requirements
  • Design input / software requirements

2. Software Systems

In compliance with DIN EN 62304, the software is subdivided into software systems, software components, and software units. The application is a mobile client that communicates directly with hearing aid devices (HADs) via Bluetooth Low Energy (BLE).

A detailed class diagram is available in here, which illustrates the relationships between the different software units.

2.1. UI System

  • Function: This system is responsible for displaying the user interface and handling user interactions. It is built with modern declarative UI patterns. It observes state from the Core Logic System and forwards user events to it. Key components include HomeTabContent and BluetoothTabContent.
  • Software safety classification and rationale: Class B (Assumed). This system displays critical device status and provides controls to the user. Failures could lead to incorrect device configuration, although not directly to serious injury.
  • Runtime: Android Runtime (ART)
  • Deployment: Android Application Package (APK)
  • User groups: End-users (hearing aid wearers), Audiologists, Production Team.

2.2. Core Logic & Communication System

  • Function: This system acts as the central hub of the application. It manages the application's state, business logic, and data flow between the UI and the hearing aid device. It orchestrates data exchange, including reading device status and sending configuration commands. Key components include MainScreenModel, BluetoothManager, BleDataHandlerUseCase, and various data codecs.
  • Software safety classification and rationale: Class B (Assumed). This system is responsible for all communication and configuration of the medical device. A failure in this system could result in the device operating with incorrect parameters.
  • Runtime: Android Runtime (ART), Kotlin Coroutines for concurrency.
  • Deployment: Included within the main Android Application Package (APK).
  • User group: N/A (Internal system component).

3. Software Units

The software is composed of several distinct, testable units with specific responsibilities. The main units are defined by interfaces and their implementations:

  • MainScreenModel: A ViewModel that holds the UI state and handles all UI-related business logic. It coordinates actions between the UI and the lower-level service units.
  • BluetoothManager: An abstraction for all BLE operations, including scanning, connecting, disconnecting, reading, writing, and observing characteristics. It manages the connection state with the left and right hearing aids.
  • BleDataHandlerUseCase: Handles the application-level logic for reading and writing specific data fields to the hearing aid, such as volume, mute status, and environment settings. It uses the BleDataTransmit unit.
  • BleDataTransmit: Responsible for the transmission of data packets over BLE. It uses the BluetoothManager for raw communication and the BleDataCodec for packet formatting.
  • BleDataCodec: Encodes and decodes data packets. It orchestrates the SmpCodec and ProtoCodec to construct the final payload for transmission.
  • SmpCodec: Implements the Simple Management Protocol (SMP) framing, adding the required SMP header to the data payload.
  • ProtoCodec: Encodes and decodes the core data structures using Google's Protocol Buffers (Protobuf). This ensures efficient and strongly-typed data serialization.
  • DeviceVersionReader: Responsible for reading hardware, firmware, and DSP version information from the connected devices.
  • SystemService: Manages interactions with underlying operating system services like Bluetooth and Location, handling state checking and providing access to system settings pages. It uses a delegate pattern (BluetoothServiceDelegate, LocationServiceDelegate).
  • PermissionsController: A wrapper around a third-party library (moko-permissions) to handle runtime permission requests required for BLE operations.

4. Database

The application does not utilize a local or remote database for storing persistent user or medical data. All configuration and state information is read directly from the hearing aid devices upon connection.

5. IT Security

5.1. Encryption of data

5.1.1. Data at rest

No sensitive patient or medical data is stored at rest on the mobile device.

5.1.2. Data in transit

Read more about it in our gitlab repository.

Template Copyright openregulatory.com. See template license.

Please don't remove this notice even if you've modified contents of this template.