Session Storing and Loading

[MarkDannemiller]

We want our applications built off of this library to store data about the devices that they connect to while running. In industry, this is referred to as "sessions"

With this, we need to migrate our log storing system to fit within this session narrative. The eventual goal of building these session structures is to transmit them to a server. Creating a robust implementation of sessions will allow us to track, test, and collect ThermoFlex data on the cloud database server.

Please refer to the following conversation with ChatGPT where it lines out a good method for implementing this structure:

---

Mark's Prompt

"I am building an application that runs on a PC and will communicate with an embedded device over serial. The application is written in python and handles sending commands and receiving responses and log data to and from the embedded device. The purpose of this application is to view configured settings of the device, change these settings, execute tests of the device's functions, and flash new firmware.

It is important that this system stores data about the device when connected to it. The device will provide logs about the state of sensors, systems, and settings back to the computer. I would like to store this data in files on the computer somewhere, and I want to separate each group of files by "session"

What I am looking for from you is a good description based on industry standards on how to handle these sessions. My thought is that each session is named based on the date and time that it occured. New sessions begin when a device is newly connected and the desktop application has been launched. If multiple devices are connected on different usb ports, then one session is maintained at a time. When device context is switched, that also triggers a new session.

Is there a common pattern/language for the system that I am describing?"

ChatGPT 4o Response

What you are describing aligns closely with the industry-standard approach to managing session-based interactions in embedded systems and desktop applications. The concept of "sessions" is often used to group related data exchanges between a PC and an embedded device. Here's a high-level breakdown of how to approach this pattern, along with common terminology and practices:

Common Session Pattern for Embedded Systems

1. Session Definition

• Session Start: A session begins when the PC application detects a connected device and establishes a communication link over the serial interface.
• Session End: A session ends when the device is disconnected or a manual stop command is triggered from the PC application.
• Device Context Switch: If multiple devices are connected, switching to a different device will end the current session and start a new one.

2. Session Identification

• Naming Convention: Use a standardized naming convention for sessions. A common practice is to base the session name on the device ID (serial number or another unique identifier), combined with the date and time. For example:

  Session_<DeviceID>_<YYYYMMDD>_<HHMMSS>
  

• This approach ensures that each session is uniquely identified and easy to locate based on both the device and the time of interaction.

3. Session Directory Structure

• Session Directories: Each session can have its own directory in a defined base location (e.g., /logs/sessions/). Inside each session directory, files can be saved with a consistent naming pattern. For example:

  /logs/sessions/Session_<DeviceID>_<YYYYMMDD>_<HHMMSS>/
     - settings_<timestamp>.json
     - log_<timestamp>.txt
     - firmware_update_<timestamp>.bin
  

• Files in Each Session: The directory contains separate files for logs, settings, and any other data (like firmware updates) that might be specific to that session.

4. Session Metadata

• Metadata File: Each session can store a small JSON or XML metadata file with key details about the session, such as:
  • Device ID
  • Firmware version
  • Start and end times
  • Test results summary (if applicable)
• This allows for easy retrieval of session details for later review without parsing the entire session log.

5. Session Lifecycle Management

• Session Start Event: Triggered when a new device is detected on the serial port. The application creates a new session directory, opens log files, and begins capturing data.
• Session Termination: When the device disconnects or the user manually switches contexts, the session files are closed, and the session is marked as complete. If errors occur, the session metadata can store the reason for an incomplete session.

6. Session Context with Multiple Devices

• Single Active Session Rule: In environments where multiple devices are connected, ensure that only one session is active at a time. Switching contexts should gracefully close the current session and open a new one.
• Device Identification: Use unique identifiers for each device (e.g., a serial number retrieved over the serial connection) to differentiate the sessions, even when switching between devices.

Implementation Tips

• Error Handling and Recovery: Ensure that the application handles device disconnection and communication errors gracefully. If a session ends unexpectedly, log the event in the session metadata or logs.
• Data Consistency: Use file locking or transaction mechanisms if multiple threads or processes might interact with session files to prevent corruption.
• Session Archiving: Implement a system to automatically compress or archive old sessions to manage disk space effectively.

This structure aligns with typical practices for embedded devices in industries like automotive, industrial controls, and medical devices, where maintaining clear records of interactions is crucial. It is also well-suited for compliance with regulatory requirements in environments that demand audit trails or traceability.