The Big Picture
This system connects people, accounts, school terminals, payments, and physical access devices. It is not only a website or a POS screen. It also opens gates and talks directly to hardware.
One-sentence explanation
ePass is a campus card platform: a student card can identify a person, validate access, pay for products, recharge balance, enter a canteen, and trigger physical equipment.
flowchart LR
People["Students, staff, parents, operators"]
subgraph UserApps["User-facing applications"]
POS["POS / kiosk application"]
GateUI["Gate monitor screen"]
CanteenUI["Canteen screen"]
BackOffice["Back-office website"]
Portal["Parent / user portal"]
end
subgraph Backend["Backend services"]
DSCore["DSCore<br/>business brain"]
DSComm["DSCommServer<br/>hardware translator"]
CloudSync["Cloud sync service"]
end
subgraph Data["Data"]
DB[("Local ePass database")]
Cloud["Cloud / web sync database"]
end
subgraph LocalHardware["Local kiosk hardware"]
Coin["Coin acceptor"]
Bill["Bill validator"]
Printer["Receipt printer"]
LocalCard["USB card reader"]
Camera["Webcam"]
Barcode["Barcode scanner"]
end
subgraph NetworkHardware["Network access-control hardware"]
Readers["RFID access readers"]
Gates["Door / gate controllers"]
Vending["Vending controllers"]
end
People --> UserApps
UserApps --> DSCore
POS --> LocalHardware
GateUI --> DSCore
DSComm --> DSCore
DSCore --> DB
BackOffice --> DB
Portal --> DB
DSComm --> Readers
DSComm --> Gates
DSComm --> Vending
CloudSync --> Cloud
User-facing applications
Cashier screens, self-service kiosks, gate monitors, canteen screens, back-office, and parent/user portals.
Backend services
Background programs decide business rules, expose services, and coordinate commands to hardware.
Hardware layer
Physical card readers, gates, coin/note acceptors, vending controllers, printers, barcode scanners, and webcams.
Plain Language Roles
These analogies are intentionally simple. They help non-technical readers understand the main moving parts.
DSCore = the business brain
DSCore answers business questions: is this student allowed through this gate, can this account pay, what product was sold, and what should be recorded in history?
DSCommServer = the device translator
DSCommServer speaks the language of physical devices. It receives reader messages, sends gate open commands, and translates hardware events into software requests.
COM port = named cable/channel
A COM port is a Windows name such as COM3. It is how Windows lets software talk to a plugged-in device, similar to saying "send this message through cable/channel COM3".
Windows Service = background program
A Windows Service runs even when no user is sitting at the computer. DSCore, DSCommServer, and CloudSync are designed for this type of background operation.
Database = official memory
The database stores users, cards, accounts, sales, device configuration, access history, meal validation, and other records the business depends on.
Protocol = agreed device language
A protocol is the agreed set of messages between software and hardware. For example, one message can mean "coin inserted" and another can mean "open gate".
System Parts
The codebase contains multiple applications that work together. The same platform supports kiosks, access control, school sales, canteen workflows, websites, and cloud synchronization.
User-facing applications
DigiSchool.POS is the Windows kiosk/POS application. It can run as a cashier POS, self-service top-up kiosk, gate monitor, or canteen screen.
Backend services
DigiSchool.DSCore hosts the core business services. DigiSchool.DSCommServer handles network hardware. DigiSchool.CloudSync synchronizes with cloud endpoints.
Database
DigiSchool.Data and DigiSchool.DataEntity contain database access, business data stores, and shared data objects.
Local kiosk hardware
Coin/note devices, USB card readers, receipt printers, barcode scanners, and webcams are controlled from the POS/kiosk machine.
Network access hardware
RFID readers, door/gate controllers, and vending controllers are handled by DSCommServer over network protocols.
Cloud and web components
BackOffice, WebPortal, WebAPI, Cloud, and Cloud.WSSync provide admin, parent/user, integration, and cloud synchronization functions.
| Area | Main projects | Plain-language role |
|---|---|---|
| User applications | DigiSchool.POS, DigiSchool.POS.KeyPad | What users and operators see on touch screens, POS machines, gate monitors, and canteen terminals. |
| Backend decisions | DigiSchool.DSCore | The service that applies business rules and records events. |
| Hardware communication | DigiSchool.DSCommServer | The service that talks to physical access-control and vending hardware. |
| Data | DigiSchool.Data, DigiSchool.DataEntity | The database layer and shared information models. |
| Web and cloud | BackOffice, WebPortal, WebAPI, Cloud, Cloud.WSSync, CloudSync | Administrative screens, portals, integrations, and cloud synchronization. |
| Testing and deployment support | Emulators, updater projects, installer projects | Tools for simulating readers, packaging services, deploying updates, and configuring machines. |
What Happens When...
These flows show how a real-world action moves through the system. Each flow starts with a person or physical device and ends with a business result.
A student taps an RFID card
The reader detects the card
The card reader gets a token from the student's RFID card.
The message reaches software
A local USB reader sends the token to the POS, or a network reader sends it to DSCommServer.
DSCore validates the event
The business service checks card ownership, host/device rules, direction, schedules, and permissions.
The result is recorded and shown
The database is updated. Gate/canteen screens can receive a live notification.
sequenceDiagram
autonumber
participant Student
participant Reader as RFID reader
participant Comm as DSCommServer or POS
participant Core as DSCore business brain
participant DB as Database
participant UI as Gate/canteen screen
Student->>Reader: Taps card
Reader->>Comm: Sends card token
Comm->>Core: Asks "is this allowed?"
Core->>DB: Checks user, card, rules, and history
DB-->>Core: Returns matching data
Core-->>Comm: Allowed or denied
Comm-->>Reader: Accept or reject response
Core-->>UI: Live activity update
A user inserts a coin or note
sequenceDiagram
autonumber
participant User
participant Device as Coin or note device
participant POS as POS / kiosk app
participant Core as DSCore sales service
participant DB as Database
participant Printer as Receipt printer
User->>Device: Inserts money
Device->>POS: Sends hardware message
POS->>POS: Converts device code into amount
POS->>Core: Records top-up or sale
Core->>DB: Saves transaction
DB-->>Core: Confirms save
Core-->>POS: Transaction result
POS->>Printer: Prints receipt if configured
A gate opens
sequenceDiagram
autonumber
participant Operator as Operator or authorization result
participant Core as DSCore
participant Comm as DSCommServer
participant Controller as Gate controller
participant Gate as Physical gate
participant DB as Database
Operator->>Core: Requests or triggers open gate
Core->>DB: Records authorization or manual action
Core->>Comm: Sends open-door command
Comm->>Controller: Translates to hardware command
Controller->>Gate: Opens physical gate
Comm-->>Core: Reports activity/status
A kiosk starts
flowchart LR
Windows["Windows starts"]
Services["Background services start"]
POS["POS/kiosk application opens"]
Config["Loads local settings"]
Devices["Connects local devices"]
Core["Connects to DSCore"]
Ready["Ready for sales, access, or canteen use"]
Windows --> Services
Services --> POS
POS --> Config
Config --> Devices
POS --> Core
Devices --> Ready
Core --> Ready
Confirmed Findings vs Assumptions
The source document separates what the code clearly proves from what must be inferred because physical hardware models and deployment documentation are not present.
Confirmed from code
- DSCore hosts WCF business services.
- DSCommServer communicates with network readers and UDP controllers.
- POS controls local devices such as card readers, bill validators, coin acceptors, printers, barcode input, and webcams.
- The solution uses .NET Framework, WPF, WCF, WebForms, ASMX, Entity Framework, PostgreSQL, serial ports, TCP, and UDP.
- Cloud sync and web portal components exist.
Inferred or uncertain
- Exact physical models of readers, bill validators, coin acceptors, and gate controllers are not identified in the code.
- Turnstiles are inferred from gate/door access-control behavior.
- Cashlogy support exists in code, but some POS usage appears optional or partially disabled.
- Vending behavior exists, but raw MDB bus communication is not clearly implemented directly in C#.
Why This System Is Complex
From a management perspective, the complexity comes from combining business software with real-world physical devices and older Windows deployment patterns.
It controls real hardware
Software bugs may not just show an error screen. They can prevent a gate from opening, stop money acceptance, or fail to print a receipt.
Many communication styles
The system uses normal database/web calls plus serial ports, TCP, UDP, printer drivers, keyboard scanners, and webcam capture.
Old but business-critical technology
WPF, WCF, WebForms, ASMX, and Windows Services are stable but legacy. They require specialized knowledge.
Configuration matters a lot
Wrong COM port, IP address, service port, printer name, firewall rule, or host configuration can break a workflow.
Timing and reliability matter
Devices send short messages and expect timely acknowledgements. Delays or missed messages can create failed transactions.
Several brands and generations
Project names, installer names, and technologies show signs of long-term evolution across DigiSchool and SafeSchool branding.
Risks in Business Language
These are not reasons to panic. They are the areas that need deliberate management, support preparation, and staged modernization.
Old .NET Framework stack
The platform relies on older Microsoft technologies. They can still run, but hiring, maintenance, security posture, and future compatibility become harder over time.
Hardware dependency
The product depends on exact devices, drivers, cables, ports, and local machine configuration. A software release cannot be treated like a normal website release.
Fragile serial communication
Coin, note, and local card devices depend on COM port settings and message timing. Loose cables, driver changes, or partial messages can create field issues.
Limited observability
Logging exists, but there is no clear single health dashboard showing every device, last message, last error, and current status.
Old threading model
The code uses older background-loop patterns. This can make shutdown, reconnect, and error recovery less predictable.
Deployment drift
Service names, project names, target frameworks, and installer behavior are not perfectly uniform. This increases support and upgrade effort.
Good News
The system has several strong foundations. Modernization should build on these instead of replacing everything.
Clear DSCore / DSComm split
The business decision service and the hardware communication service are separate. This is a good architectural boundary and should be preserved.
Hardware is partially separated
Network access-control hardware is mostly handled by DSCommServer instead of being buried inside the UI.
Existing logging
The code already uses logging in important areas. This provides a base for better health checks and support tools.
Existing emulators
The card reader emulator is valuable. Hardware systems need simulation tools for development, support, training, and regression testing.
Recommended Roadmap
The safest path is not a big rewrite. Stabilize and observe the current system first, then introduce modern interfaces and APIs around it.
flowchart LR
A["1. Document current runtime"]
B["2. Build diagnostics tool"]
C["3. Improve logs and health checks"]
D["4. Introduce hardware interfaces"]
E["5. Add modern API facade"]
F["6. Modernize UI/runtime gradually"]
A --> B --> C --> D --> E --> F
Document the current runtime
Record service names, ports, COM settings, IP addresses, firewall rules, installer behavior, and device configuration.
Build a hardware diagnostics tool
Give support and developers a safe way to test readers, gates, coin/note devices, printers, and service connectivity.
Improve logs and health checks
Create a clear view of device status, last message, last error, current service status, and transaction flow.
Introduce hardware interfaces
Place stable software boundaries around card readers, cash devices, printers, and gate controllers.
Add a modern API facade
Expose safer HTTP endpoints while still calling the existing DSCore and DSComm logic behind the scenes.
Only then modernize UI/runtime
After diagnostics, health checks, and interfaces exist, consider web/Electron UI, modern services, or .NET upgrades.
Technical Details for Interested Readers
These sections are collapsed by default so the page remains usable in management meetings.
What technologies are involved?
| Technology | Plain-language explanation | Where it appears |
|---|---|---|
| .NET Framework | Older Microsoft application runtime used by the desktop apps, services, and web apps. | Most projects in the solution. |
| WPF | Windows desktop UI technology for the POS/kiosk screens. | DigiSchool.POS. |
| WCF | Legacy service communication technology used for POS, DSCore, and DSComm communication. | DigiSchool.DSCore and ServiceModel. |
| WebForms / ASMX | Older ASP.NET web page and SOAP service technology. | BackOffice, WebPortal, WebAPI, Cloud.WSSync. |
| SerialPort / COM | Windows device communication used for local card, coin, and note devices. | DigiSchool.POS device classes. |
| TCP / UDP | Network communication used by readers, access controllers, vending controllers, and Cashlogy. | DSCommServer and POS cash device integration. |
| PostgreSQL / EF6 | Database and data access framework. | DigiSchool.Data. |
Which devices are visible in the code?
| Device | Business purpose | How software talks to it |
|---|---|---|
| RFID/card readers | Identify students, staff, and users. | Local serial COM or network TCP/UDP paths. |
| Door/gate controllers | Open or deny access at physical entry points. | UDP messages through DSCommServer. |
| Coin acceptor | Accept coin top-ups/payments. | Serial COM text messages. |
| Bill validator | Accept banknote top-ups/payments. | Serial COM binary messages with CRC checking. |
| Vending controller | Authorize vending balance and record sale delivery. | UDP messages through DSCommServer. |
| Cashlogy | Cash handling/recycling device. | TCP messages from POS. Usage appears optional. |
| Printer, barcode scanner, webcam | Receipts, product scanning, and visitor photos. | Windows printer queue, keyboard input, and webcam capture wrapper. |
Why serial communication needs special care
Serial devices send small byte streams through named COM ports. The application must know the correct port, speed, parity, and message format. If one setting is wrong, the device may appear broken even when the hardware is physically fine.
The bill validator is especially sensitive because it accepts money. It uses a CRC check, which is a small calculated value used to detect corrupted messages. The coin acceptor uses simpler text messages.
How DSCore and DSComm work together
DSCore owns the business decision. DSComm owns the hardware communication. When a card is read at a network reader, DSComm asks DSCore whether the access is allowed. When DSCore wants a gate opened, it sends a command to DSComm, and DSComm translates that command into the controller's device language.
flowchart LR
Reader["Card reader"]
DSComm["DSCommServer<br/>device translator"]
DSCore["DSCore<br/>business brain"]
DB[("Database")]
Gate["Gate controller"]
Reader --> DSComm
DSComm -->|"ask for authorization"| DSCore
DSCore --> DB
DSCore -->|"open-door command"| DSComm
DSComm --> Gate
One-Page Executive Summary
A short version suitable for the end of a meeting or project briefing.
What the system is
DigiSchool / SafeSchool ePass is a school campus platform for POS sales, account top-ups, RFID/card identity, canteen validation, vending, access control, and web/cloud administration.
How it is organized
The WPF POS/kiosk application is the user-facing desktop system. DSCore is the central business service. DSCommServer is the translator between software and physical access-control hardware. The database stores users, accounts, cards, products, transactions, device configuration, and history. Web and cloud projects provide portals, integrations, back-office screens, and synchronization.
Why it is complex
It combines normal business software with physical devices. It must coordinate databases, Windows Services, local COM devices, network controllers, printers, scanners, webcams, cloud sync, and legacy .NET technologies. Small configuration or timing problems can create real-world operational failures.
Main risks
The largest risks are legacy .NET Framework dependencies, fragile hardware communication, limited health visibility, older threading patterns, and deployment/configuration drift.
Good news
The most important architectural boundary already exists: DSCore handles business decisions and DSCommServer handles network hardware communication. Logging and emulators also exist, which gives the team a practical foundation for safer modernization.
Recommended direction
Do not rewrite immediately. First document the runtime, build a diagnostics tool, improve logs and health checks, introduce hardware interfaces, add a modern API facade, and only then modernize the UI and runtime.