Developer / Engineering Architecture

Technical Architecture - DigiSchool / SafeSchool ePass

Onboarding-oriented architecture reference for developers, support engineers, DevOps/sysadmins, and future maintainers. It specializes the generated architecture portal using docs/system-architecture-overview.md and docs/architecture-portal.html as source context.

DSCore WCF business service host and access/sales decision point.
DSCommServer Network hardware gateway for readers, doors, gates, and vending controllers.
POS WPF kiosk/POS UI plus local COM, printer, scanner, webcam, and cash device handling.
Legacy runtime .NET Framework, WPF, WCF, WebForms, ASMX, EF6, PostgreSQL, Windows Services.

1. Technical Overview

ePass is a service-oriented legacy .NET system that combines school identity, POS, self-service top-up, canteen validation, access control, vending, web portals, and physical device communication.

Confirmed from code
Primary architecture map
flowchart LR
    subgraph UI["User-facing applications"]
        POS["DigiSchool.POS WPF"]
        BackOffice["BackOffice WebForms"]
        Portal["WebPortal WebForms"]
        WebAPI["WebAPI ASMX"]
    end

    subgraph Services["Local/server services"]
        DSCore["DigiSchool.DSCore"]
        DSComm["DigiSchool.DSCommServer"]
        CloudSync["DigiSchool.CloudSync"]
    end

    subgraph Data["Data stores"]
        DB[("PostgreSQL ePass database")]
        CloudDB[("Cloud database")]
    end

    subgraph Hardware["Hardware"]
        Local["Local kiosk devices: COM, printer, camera, scanner"]
        Network["Network readers, gates, vending controllers"]
    end

    POS -->|"net.tcp WCF"| DSCore
    POS --> Local
    DSComm -->|"net.tcp WCF duplex"| DSCore
    DSComm --> Network
    DSCore --> DB
    BackOffice --> DB
    Portal --> DB
    WebAPI --> DB
    CloudSync -->|"ASMX SOAP"| CloudDB
          

Confirmed findings

  • DSCore hosts WCF business services over localhost-oriented endpoints.
  • DSCommServer acts as the hardware gateway for networked readers/controllers.
  • POS controls several local devices directly from the WPF process.
  • The database and shared data stores are central to most modules.

Assumptions and uncertainty

  • Exact physical hardware models are not visible in the repository.
  • Turnstile support is inferred from gate/door controller behavior.
  • Cashlogy code exists, but current production usage appears configuration-dependent.
  • Vending support is present, but raw MDB bus handling is not clearly implemented in C#.

2. Solution and Project Structure

The solution is a distributed monolith: separate processes and projects share DTOs, data access, configuration assumptions, and the same business database.

Project-level map
Project Type Role Notes for maintainers
DigiSchool.POS WPF WinExe POS, self-service kiosk, gate monitor, canteen monitor, local hardware host. Contains both UI and local device integration. Treat UI changes as potentially hardware-affecting.
DigiSchool.POS.KeyPad WPF library Virtual keypad and on-screen keyboard. Touch/kiosk input support.
DigiSchool.DSCore Exe / Windows Service WCF host for Products, Security, Users, Sales, Gates, GateEntries, Apps. Business decision point. Validate endpoints and service startup first when POS cannot function.
DigiSchool.DSCommServer Exe / Windows Service Hardware gateway for network RFID readers, doors/gates, and vending controllers. Despite the UDP naming, it also runs a TCP listener.
DigiSchool.Data Class library EF6/Npgsql data access and business data stores. ePassCore is the main facade used by services and web apps.
DigiSchool.DataEntity Class library Shared DTOs, entities, enums, and contracts. Changes here can affect many processes.
DigiSchool.ServiceModel Class library WCF contracts, callback interfaces, and service host helpers. Contains DSServiceManagerBase and GateEntries contracts.
DigiSchool.Common Class library Logging, config, serialization, crypto, utility helpers. Cross-cutting dependency. Avoid unrelated changes.
DigiSchool.BackOffice ASP.NET WebForms Administrative website. Likely configures users, cards, products, hosts, devices, reports.
SafeSchool.WebPortal ASP.NET WebForms Parent/user portal. Includes account, meal, authorization, order, and wallet-related flows.
DigiSchool.WebAPI ASMX web service SOAP integration API. Legacy integration surface, not REST.
DigiSchool.Cloud* WebForms, ASMX, service Cloud portal and synchronization. CloudSync calls cloud ASMX endpoints.
DigiSchool.Emulators.CardReader WinForms Card reader/gate emulator. Useful for development and support without hardware.

3. Runtime Architecture

At runtime, the platform is a collection of Windows desktop apps, Windows Services, IIS-hosted web apps, PostgreSQL, and physical devices.

Runtime view
Typical runtime process topology
flowchart TB
    subgraph Kiosk["POS / kiosk Windows machine"]
        WPF["DigiSchool.POS"]
        LocalDevices["Local COM/printer/scanner/webcam devices"]
    end

    subgraph ServiceHost["Service host / server machine"]
        DSCoreSvc["DSCore Windows Service"]
        DSCommSvc["DSComm Windows Service"]
        CloudSyncSvc["CloudSync Windows Service"]
        IIS["IIS web applications"]
        PG[("PostgreSQL")]
    end

    subgraph NetworkDevices["LAN hardware"]
        ReaderTCP["Network RFID readers"]
        GateUDP["Door/gate controllers"]
        VendingUDP["Vending controllers"]
    end

    WPF --> LocalDevices
    WPF -->|"WCF net.tcp localhost/LAN"| DSCoreSvc
    DSCommSvc -->|"WCF duplex"| DSCoreSvc
    DSCoreSvc --> PG
    IIS --> PG
    CloudSyncSvc -->|"SOAP over HTTP"| IIS
    ReaderTCP --> DSCommSvc
    DSCommSvc --> GateUDP
    DSCommSvc --> VendingUDP
          
Runtime unit Likely execution mode Primary dependency
POS/kiosk Interactive WPF process DSCore WCF endpoints, local device drivers, local settings.
DSCore Windows Service or manual console Database, WCF ports, service configuration.
DSCommServer Windows Service or manual console DSCore GateEntries endpoint, hardware IPs/ports, database host config.
CloudSync Windows Service Cloud ASMX endpoint and database cloud URL settings.
BackOffice / WebPortal / WebAPI IIS-hosted ASP.NET Database, IIS app pool, HTTP/HTTPS configuration.

4. DSCore Internals

DSCore is the central business-service host. It starts WCF services, builds caches, validates access, processes sales, and sends gate commands.

Business service host
DSCore services and dependencies
flowchart LR
    DSCore["DSCore Program / Service"]
    Manager["DSServiceManager"]
    Products["ProductsService"]
    Security["SecurityService"]
    Users["UsersService"]
    Sales["SalesService"]
    Gates["GatesService"]
    GateEntries["GateEntriesService"]
    Apps["AppsService"]
    Core["ePassCore data facade"]
    DB[("PostgreSQL")]

    DSCore --> Manager
    Manager --> Products
    Manager --> Security
    Manager --> Users
    Manager --> Sales
    Manager --> Gates
    Manager --> GateEntries
    Manager --> Apps
    Products --> Core
    Security --> Core
    Users --> Core
    Sales --> Core
    Gates --> Core
    GateEntries --> Core
    Core --> DB
          

Important internals

  • DSServiceManager starts/stops WCF service managers.
  • GateEntriesService is a duplex WCF service with callbacks.
  • GatesService handles gate validation and manual open commands.
  • Program.BuildCache() refreshes access-control/system caches and notifies gate clients.

WCF endpoints

  • Products: port 5150.
  • Security: port 5151.
  • Users: port 5152.
  • Sales: port 5153.
  • Gates: port 5154.
  • GateEntries: port 5155 plus named pipe.
  • Apps: port 5157.
GateEntries callback model

GateEntriesService supports duplex callbacks. DSComm subscribes as a command processor so it can receive commands such as open-door. POS gate/canteen screens can subscribe as activity consumers so they receive live access events.

This is a reasonable legacy design for push notifications, but support engineers should treat disconnected callbacks as a common failure mode when live UI updates or hardware commands stop working.

5. DSCommServer Internals

DSCommServer bridges DSCore and network hardware. Its naming is historical: UDPManager also contains a TCP listener for newer readers.

Hardware gateway
DSCommServer internal components
flowchart TB
    Program["Program / DSCommService"]
    Manager["DSCommManager"]
    GEManager["GateEntriesManager"]
    GEController["GateEntriesController callback client"]
    UDPManager["UDPManager"]
    TCPListener["TCP listener for readers"]
    ChannelLoop["Channel refresh loop"]
    UDPChannels["UDPChannel instances"]
    DSCore["DSCore GateEntriesService"]
    Readers["Network RFID readers"]
    Doors["Door/gate controllers"]
    Vending["Vending controllers"]

    Program --> Manager
    Manager --> GEManager
    Manager --> UDPManager
    GEManager --> GEController
    GEController <-->|"WCF duplex"| DSCore
    UDPManager --> TCPListener
    UDPManager --> ChannelLoop
    ChannelLoop --> UDPChannels
    Readers --> TCPListener
    UDPChannels --> Doors
    UDPChannels --> Vending
    UDPManager --> GEManager
          
Component Responsibility Operational notes
DSCommManager Starts and stops GateEntries and gate-controller services. Startup order matters: hardware and WCF callbacks both need to be healthy.
GateEntriesManager DSComm-side wrapper for GateEntries WCF calls. Used for authorization requests and activity/canteen notifications.
GateEntriesController Duplex callback client that receives commands from DSCore. Contains retry/backoff and pending command queue behavior.
UDPManager TCP listener for network readers plus lifecycle manager for UDP channels. Name is misleading because it is not only UDP.
UDPChannel One communication channel to a door/gate or vending controller. Parses access/vending messages, sends keep-alive and open/deny commands.

6. Communication Layers

The system combines service communication and hardware communication. Bugs often come from confusing these layers.

WCF + TCP/UDP + COM

WCF

POS and DSComm talk to DSCore through WCF. GateEntries uses duplex callbacks, which means the service can call back to subscribed clients.

TCP/UDP

Network readers use TCP messages to DSCommServer. Door/gate/vending controllers use UDP channels managed by DSCommServer.

COM/Serial

Local POS hardware such as RFID readers, bill validators, and coin acceptors communicate through Windows COM ports.

Communication layer separation
flowchart LR
    POS["POS WPF"]
    DSCore["DSCore WCF"]
    DSComm["DSCommServer"]
    COM["Local COM devices"]
    TCP["TCP readers"]
    UDP["UDP gate/vending controllers"]
    DB[("Database")]

    POS -->|"WCF service calls"| DSCore
    POS -->|"SerialPort"| COM
    DSComm -->|"WCF duplex"| DSCore
    TCP -->|"TCP messages"| DSComm
    DSComm -->|"UDP messages"| UDP
    DSCore --> DB
          
WCF implementation notes
  • Endpoints are primarily net.tcp with security mode configured as none.
  • GateEntries includes duplex callbacks for DSComm command processing and POS activity updates.
  • Bindings use large message sizes and long timeouts, which should be reviewed during hardening.
  • If POS cannot reach core services, check service state, port binding, firewall, endpoint URLs, and config files.

7. Hardware Protocols

Hardware code is implemented directly in C#. Protocols are a mix of binary serial, ASCII serial, TCP, and UDP message formats.

Implementation-aware
Device Transport Protocol style Main class
Local RFID reader Serial COM, default 9600 N 8 1 ASCII token frames such as #TOKEN* COMCommunicationManager
Bill validator Serial COM, 9600 E 8 1 Binary messages with CRC-16/Kermit, ACK, status, escrow, stack BillMachine
Coin acceptor Serial COM, 38400 N 8 1, DTR enabled ASCII frames such as #ACON*, #ACOFF*, #AC-OK* CoinMachine
Network reader TCP Text/key-value message including reader id and card serial UDPManager
Door/gate controller UDP ASCII commands such as SON, V?, A1G UDPChannel
Vending controller UDP Controller-specific ASCII messages for balance, sale, delivery success/fail UDPChannel
Cashlogy TCP ASCII #...# framed messages CashlogyMachine

Polling loops

Device code often loops while checking status or reading buffers. This is common in hardware integrations but needs careful cancellation and logging.

ACK messages

ACK means the receiver accepted the previous message. Missing ACKs can cause duplicate messages, stalled devices, or rejected transactions.

CRC checks

CRC is used by the bill validator to detect corrupted binary frames before accepting money events.

8. End-to-End Flow Traces

Use these as mental models when debugging. A failure can happen at any hop in the sequence.

Trace diagrams
How to trace a network card read end-to-end
sequenceDiagram
    autonumber
    participant Card as RFID card
    participant Reader as Network reader
    participant UDPManager as DSComm UDPManager
    participant GEManager as GateEntriesManager
    participant GateEntries as DSCore GateEntriesService
    participant AccessStore as AccessControlDataStore
    participant DB as PostgreSQL
    participant POS as Gate/canteen POS subscriber

    Card->>Reader: Token is read
    Reader->>UDPManager: TCP message with serial and device number
    UDPManager->>UDPManager: Resolve host and direction
    UDPManager->>GEManager: RequestAutorization(token, direction, host)
    GEManager->>GateEntries: WCF authorization request
    GateEntries->>AccessStore: Validate token, host, rules
    AccessStore->>DB: Read rules and write history
    DB-->>AccessStore: Data and save result
    AccessStore-->>GateEntries: Authorization result
    GateEntries-->>GEManager: Result
    GEManager-->>UDPManager: Result
    UDPManager-->>Reader: Accept or deny response
    UDPManager->>GEManager: NotifyActivity
    GateEntries-->>POS: Callback activity update
          
Money insertion flow
sequenceDiagram
    autonumber
    participant User
    participant Device as Bill/Coin device
    participant Driver as BillMachine/CoinMachine
    participant POSVM as PosViewModel
    participant Sales as DSCore SalesService
    participant DB as PostgreSQL
    participant Printer

    User->>Device: Inserts money
    Device->>Driver: Serial event
    alt Bill validator
        Driver->>Driver: Validate CRC and status
        Driver->>Device: ACK / HOLD / STACK
    else Coin acceptor
        Driver->>Driver: Parse coin code
        Driver->>Device: #AC-OK*
    end
    Driver->>POSVM: onDataInbound amount code
    POSVM->>POSVM: Map code to value and update cart/top-up
    POSVM->>Sales: Create or update transaction
    Sales->>DB: Persist sale/recharge
    DB-->>Sales: Saved
    Sales-->>POSVM: Result
    POSVM->>Printer: Print receipt when configured
          
Gate open command flow
sequenceDiagram
    autonumber
    participant UI as Gate UI or business rule
    participant GatesService as DSCore GatesService
    participant AccessStore as AccessControlDataStore
    participant GateEntries as GateEntriesService
    participant DSComm as DSComm callback client
    participant UDPManager
    participant Channel as UDPChannel
    participant Controller as Door/Gate controller

    UI->>GatesService: Open door command
    GatesService->>AccessStore: Create manual authorization/history
    GatesService->>GateEntries: SendCommand(open-door)
    GateEntries-->>DSComm: Duplex Execute(command)
    DSComm->>UDPManager: Execute open-door
    UDPManager->>Channel: OpenDoor(direction)
    Channel->>Controller: UDP open-door command
          

9. Debugging and Support Guide

Hardware issues should be debugged by walking the chain from physical device to service to database.

Operational guidance

How to debug hardware issues

  • Confirm the physical device has power, cable/network link, and no vendor error state.
  • Confirm Windows sees the COM port, printer, network adapter, or USB camera.
  • Confirm application settings match the actual COM port, printer name, IP, and host id.
  • Confirm DSCore and DSCommServer services are running.
  • Check logs around the exact timestamp of the failed hardware event.
  • Check database host/device configuration for the affected terminal.

How to trace a card read end-to-end

  • Identify whether the reader is local COM or network TCP/UDP.
  • For local COM, verify POS receives NotifyNewToken.
  • For network readers, verify DSCommServer receives the reader message.
  • Verify host lookup by reader/device number.
  • Verify DSCore receives RequestAutorization.
  • Verify access history is created and a UI callback is sent.

How to diagnose COM port issues

  • Use Windows Device Manager to confirm the COM port name.
  • Confirm baud/parity/data bits/stop bits match the device class.
  • Make sure no other process has the COM port open.
  • Unplug/replug the device and confirm the COM port did not change.
  • Check whether the POS settings store the correct configured reader/cash device port.
  • Use a serial terminal or diagnostics tool to observe raw bytes if available.

How to debug money devices

  • Confirm the self-service flow enabled the acceptor before inserting money.
  • For bills, look for CRC/status/escrow/stack messages.
  • For coins, look for #aCIN-... and #AC-OK*.
  • Check idle timers that may disable acceptors before the user finishes.
  • Verify POS maps the device amount code to the expected euro value.

10. Reconnect Behavior

Reconnection exists, but it is distributed across WCF callback clients, UDP channel loops, keep-alive timers, and device reader threads.

Behavioral risk area

How devices reconnect: WCF callbacks

GateEntriesController handles subscriptions, retry/backoff, and pending command behavior. If DSCore restarts, DSComm may need to resubscribe.

UDP channels

UDPManager periodically refreshes managed channels from database host configuration. UDPChannel uses keep-alive/status checks.

Local COM devices

POS opens configured serial ports. Device unplug/replug, port name changes, or another process holding the port can prevent reconnect.

Maintainability note

Current reconnect behavior relies on older loops, timers, static state, and Thread.Abort() in several areas. Modernization should replace these incrementally with explicit lifecycle state, cancellation tokens, and device health reporting.

11. Typical Runtime Dependencies

A working deployment depends on more than binaries. Field issues often come from local environment drift.

Deployment checklist

Machine dependencies

  • .NET Framework runtime.
  • Windows service registration.
  • IIS for web applications.
  • PostgreSQL connectivity.
  • Printer, serial, webcam, and cash device drivers.

Network dependencies

  • WCF service ports in the 5150 range.
  • HTTP metadata ports in the 8150 range.
  • Hardware IP addresses and UDP/TCP ports.
  • Firewall rules and URL ACLs from installer custom actions.
  • Cloud sync endpoint availability.

Configuration dependencies

  • Host id and host type.
  • COM port names and serial settings.
  • Printer names.
  • Access-control config and managed hosts.
  • Database connection strings and app settings.
Installer/runtime setup

The repository includes Windows Service installer classes and WiX installer/custom-action projects. Confirmed setup responsibilities include installing background services, configuring IIS/web applications, setting firewall rules, and creating URL ACLs for service metadata endpoints.

  • DigiSchool.DSCore has a service installer for the core provider service.
  • DigiSchool.DSCommServer has a service installer for the communications host.
  • DigiSchool.CloudSync has a service installer for cloud synchronization.
  • WiX packaging uses SafeSchool-oriented service/executable names, so support teams should verify the installed service names on each machine.
  • SafeSchool.Server.ServicesCA/CustomAction.cs is important for machine-level setup such as URL ACLs and firewall-related configuration.

12. Device Inventory

Devices inferred from the codebase and where their integrations live.

Inventory
Device Purpose Transport Implementation Certainty
Local RFID/card reader Read tokens at POS/gate/canteen/login terminals. Serial COM CommunicationManager.cs High
Network RFID/access reader Read tokens at fixed access points. TCP to DSCommServer UDPManager.cs High
Door/gate/turnstile controller Open/deny physical passage. UDP/IP UDPChannel.cs High for door/gate, inferred for turnstile
Vending controller Authorize balance and record vending sale outcome. UDP/IP UDPChannel.ProcessMessageVendingMachine High
Coin acceptor Accept coin payments/top-ups. Serial COM CoinMachine.cs High
Bill validator Accept note payments/top-ups. Serial COM BillMachine.cs High
Cashlogy Cash recycler/payment device. TCP/IP CashlogyMachine.cs Medium
Printer, barcode scanner, webcam Receipts, product scanning, visitor/accompanied-exit photos. Windows printer queue, keyboard input, webcam capture POS view models/windows and WebcamPlayer High

13. Technical Debt and Reliability Risks

These are implementation risks for maintainers. They should drive testing, diagnostics, and staged refactoring priorities.

Risk area

Threading model

Multiple classes use raw threads, infinite loops, sleeps, static state, and abort-based shutdown. This can make service stop/restart and device reconnect behavior unpredictable.

Hardware inside UI

POS owns local device protocols directly. Payment device changes can affect UI behavior and vice versa.

Observability gaps

Logging exists, but there is no single current-state dashboard for device health, last message, last error, and service callback state.

Legacy communications

WCF, ASMX, WebForms, and .NET Framework are supportable but require specialized knowledge and careful hardening.

14. Modernization and Diagnostics Strategy

The safest modernization path is to wrap and observe before replacing. Do not start with a full rewrite.

Recommended strategy
Incremental modernization strategy
flowchart LR
    A["Document runtime contracts"]
    B["Protocol parser tests"]
    C["Diagnostics tool"]
    D["Device health and logs"]
    E["Hardware interfaces/adapters"]
    F["Modern local/API facade"]
    G["Gradual UI/runtime modernization"]

    A --> B --> C --> D --> E --> F --> G
          

Diagnostics tooling proposal

  • List COM ports and open them with selected serial settings.
  • Show raw device bytes as text and hex.
  • Test card reader token parsing.
  • Send coin/bill enable/disable/status commands safely.
  • Validate bill CRC sample frames.
  • Test DSCore and DSComm connectivity.
  • Ping network controllers and send controlled open-door tests.

Hardware interfaces to introduce

  • ICardReader for local and network reader abstraction.
  • ICashAcceptor for coin, bill, and Cashlogy style devices.
  • IDoorController for gate/door open/deny actions.
  • IPrinter for receipt/report output.
  • IDeviceHealthReporter for current state and telemetry.

15. Important Files and Classes

Start here when onboarding or debugging a specific subsystem.

Code map
Core services and contracts
  • DigiSchool.DSCore/App.config
  • DigiSchool.DSCore/Program.cs
  • DigiSchool.DSCore/DSCoreProvider.cs
  • DigiSchool.DSCore/Services/DSServiceManager.cs
  • DigiSchool.DSCore/Services/GateEntries/GateEntriesService.cs
  • DigiSchool.DSCore/Services/Gates/GatesService.cs
  • DigiSchool.ServiceModel/Services/GateEntries/IGateEntriesService.cs
  • DigiSchool.ServiceModel/Services/GateEntries/IGateEntriesServiceCallback.cs
Hardware gateway
  • DigiSchool.DSCommServer/Program.cs
  • DigiSchool.DSCommServer/DSCommManager.cs
  • DigiSchool.DSCommServer/DSCommService.cs
  • DigiSchool.DSCommServer/Server/UDPManager.cs
  • DigiSchool.DSCommServer/Server/UDPChannel.cs
  • DigiSchool.DSCommServer/Client/GateEntriesService/GateEntriesManager.cs
  • DigiSchool.DSCommServer/Client/GateEntriesService/GateEntriesController.cs
POS and local devices
  • DigiSchool.POS/ViewModels/HostViewModel.cs
  • DigiSchool.POS/ViewModels/PosViewModel.cs
  • DigiSchool.POS/ViewModels/GatesViewModel.cs
  • DigiSchool.POS/Code/CommunicationManager.cs
  • DigiSchool.POS/Code/GateEntriesConnectionManager.cs
  • DigiSchool.POS/Code/CashInterfaces/BillMachine.cs
  • DigiSchool.POS/Code/CashInterfaces/CoinMachine.cs
  • DigiSchool.POS/Code/CashInterfaces/CashlogyMachine.cs
  • DigiSchool.POS/Code/CashInterfaces/Crc16CcittKermit.cs
  • DigiSchool.POS/Code/WebcamPlayer
Data, web, cloud, and installers
  • DigiSchool.Data/ePassCore.cs
  • DigiSchool.Data/DataStores/AccessControlDataStore.cs
  • DigiSchool.Data/DataStores/HostsDataStore.cs
  • DigiSchool.WebAPI/WSData.asmx.cs
  • DigiSchool.CloudSync/Program.cs
  • DigiSchool.Cloud.WSSync/WSSynData.asmx.cs
  • SafeSchool.Server.ServicesCA/CustomAction.cs
  • SafeSchool.Installer